inneks если вы собираете raid из SSD, то убедитесь что либо SSD мегакрутые, либо этот чипсет у интела прямо поддерживает trim в raid режиме. Уже попадал на такую проблему. Диски убивались за год.
Drno , возможно. Сколько не вынимал диски с софтовых виндовых рейдов зеркальных (и аппаратных тоже), всегда данные можно было просто считать.
Drno, возможно у вас попался какой-то очень специфический чипсет. Во времена W7 все уже так же работало.
Софтовый рейд силами винды на системном диске.. Ну не знаю. Оно обычно не дает нормально грузить при сбое одного диска. Или если у одного из дисков много бедов он все равно будет пытаться грузиться с него. Он не переключится на второй, это уже проходили.
Если собирать не системные диски, то там да, чисто софтовый у винды сейчас отличный вариант.
можно. И через прокси и через любой ваш файрвол.
На прокси/файрволе просто даете доступ ко всяким там сайтам MS типа catalog... Есть у мс где-то список ресурсов которые нужны для обновлений.
Сдается мне что вы не полностью задачу озвучили.
Дмитрий, тогда у вас нет вариантов кроме как R10. То есть потери половины емкости. И то может не хватить.
Ведь R10 из 12 дисков это по сути, если я правильно помню, по скорости 6 дисков обычных. Представили как работает сервер на одном обычном диске (не ссд) по скорости? Вот тут на 6 таких не очень быстрых дисков приходится 10 серверов.
И будет еще пенальти на файловую систему кластерную, и на сеть.
Если у вас там сервера которые просто файлопомойки, то хватит производительности. Если там есть БД, то сразу ищите способы докупить SSD.
10G не всегда поднимаются в режиме хост-хост. Может потребоваться коммутатор, учтите эти затраты. Кроме того, серверам для нормального общения друг между другом тоже потребуется сеть. Можно и 10г.
BlinCT, посмотрите сетевые карты и главное - коммутаторы на 2,5G. Есть вероятность что передумаете по поводу 2,5. Выбор 2,5 резко сужает выбор оборудования и повышает бюджет. Там до 10G ethernet по цене недалеко.
ИБП должен быть с выходами для подключения - usb|rs232. Ну и должна быть хоть какая-то информация о совместимости с системой на которой вы собираете. Обычно есть информация о совместимости. ИБП можно и потом докупить.
Возможности расширения емкости зависят от того чем именно и какой именно рейд соберете. Если это зеркало, то расширить его можно будет как минимум двумя такими же дисками. Если R5, то можно диски докидывать обычно. Но опять же - смотрим чем собираем и читаем мануал. Но тут возникает новая проблема - R5 не рекомендуется для емких дисков (4тб и более), т.к. очень большое время ребилда. Так что приходим к R6, а это уже много дисков и потеря емкости (на 4 дисках 50% емкости в трубу)... Короче - для домашнего R5 и ставим свечку )
Saboteur, добавлять диски что в lvm/zfs , что в mdadm будет проблематично. Есть риски и там и там нажать что-нить не так. Системы NAS типа Truenas вроде умеют это делать через красивый гуй, с минимальными требованиями к квалификации юзера.
информация теряется обычно при пересборке raid'а аппаратного, если у аппаратного рейда нет функции расширения емкости без потери данных. А она обычно сейчас везде есть, но может не хватить гибкости. Например raid5 можно будет диск добавить, но перейти с raid5 на R6 уже никак без полного разрушения.
BlinCT, так то мысль хорошая. Если бюджет позволяет.
- 2,5 гигабитные коммутаторы уже есть или просто в планах?
- кеш при чтении фильма не поможет, т.к. чтение все равно будет с медленного диска. Вот на запись кеш может помочь.
- на такую хранилку было бы неплохо накатить plex или jellyfin.
- ОС и приложения лучше на ssd ставить. И уже программным рейдом собирать массив из hdd.
- сейчас странная ситуация. Стоимость hdd улетает в космос, а ssd дешевеют. Возможно, уже можно собирать массивы Raid 5 из емких SSD бытовых. Скорость в разы выше, деньги почти те же, надежность выше если учесть что hdd - SMR. Это если данные большую часть времени просто лежат и не перезаписываются постоянно.
Уже посоветовали freenas/truenas - поддержу.
Можно еще навернуть ZFS (она позволит кеширование, дедупликацию), но будет значительно сложнее, требования к железу выше и ломучесть... Наверное оно того не стоит под видосики.
Saboteur, Synology/QNAP NAS не включает в себя аппаратных raid контроллеров. По крайней мере те модели которые мне попадались. И корп версии тоже включают в себя обычно HBA, то есть решение построено на программном рейде.
Но работает из коробки и не нужно ничего выдумывать, настраивать, читать, мучать себя.
inneks, там есть megaraid CLI и megaraid storage manager GUI.
CLI - консольные инструменты. Можно при большом желании ограничиться этим. Но графический интерфейс конечно визуально удобнее.
В readme указаны требования для установки. Версия java тоже должна быть указана.
Уж имя прежнее точно не стоит оставлять. Можно потом огрести всяких неудобств в виде останков от старого DC в каталоге и непонятно будет это от старого или от нового.
Если по варианту 2, то убедитесь что есть прям самые новые и хорошие бэкапы DC и что их можно быстро развернуть если что. Так-то вероятность потерять единственный DC за несколько часов что поднимается новый - крайне низкая.
ответ на вопрос "зачем?" вполне очевиден. Там лежат бэкапы, задача которых спасти данные. Если бэкапы будут доступны для ОС в момент работы шифровальщика, то данные не спасти.
Тут ниже уже написали, но хотелось бы еще раз указать. Выставлять наружу rdp опасно. Количество случаев когда по rdp открытым наружу вламывались и наносили ущерб сложно подсчитать - очень много.
Пробуйте прикрутить хотя бы:
vpn server - даже в домашних роутерах есть.
port knocking - есть в некоторых роутерах
постоянные последние апдейты на ОС
ts gateway - но это уже не про домашний вариант
Посмотрите загрузку через диспетчер задач и через монитор производительности. Нагрузку на каждый из дисков во время копирования, нагрузку на CPU.
Вероятность того что сеть загружают настолько что для rdp не хватает пропускной способности крайне низка.
по корпусам тогда разбивку можно не делать.
Для NVR я бы выделил больше одной сети, т.к. 200 это уже близко к 250 шт.
Если серверов уже 9, то можно в отдельную подсеть.
Выделив ИБ и руководство вы на уровне сетей сможете предоставить им доступ, а остальным закрыть.
Под телефонию зарезервировать подсеть сразу.
Если у вас много hyper-v серверов, сложная структура vlan'ов, со вложенностью как в матрешке, вот тогда вам нужна данная функция на нескольких выделенных hyper-v серверах.
самое самое простое что можно придумать и быстро сделать это зайти в папку пользователи и посмотреть там профили. Будет видно какие пользователи заходили на ПК, а самый последний по дате изменения скорее всего будет тот кто последний заходил. Ничего кроме проводника не нужно открывать в этом случае.
Это можно и с любого другого ПК посмотреть через \\pcname\c$\users - как-то так.
В тех задании прописана неплохая надежность. Raid 0 на 4 дисках дает грубо 12% вероятность выхода из строя массива в год, при вероятности сбоя каждого диска в 3%. Это полное отсутствие надежности. Технически R0 можно сделать на дисках разного объема, это не должно быть проблемой. Да и LVM это по сути R0. И лучше так не делать.
Скорости с такими дисками вообще не получить. Хотя мы же не знаем о каких скоростях идет речь.
Drno , возможно. Сколько не вынимал диски с софтовых виндовых рейдов зеркальных (и аппаратных тоже), всегда данные можно было просто считать.