Хочу узнать мнение на что лучше записывать данные которые необходимо хранить 5 и более лет. То есть на серваке хранятся данные, которые периодически нужно записывать на носитель.
Условия такие:
1. Долгое время хранения (более 5 лет)
2. Обьем данных не большей (2-3 гига в месяц а может и меньше)
3. Желательно что бы трудно было убить эти данные под физическим воздействием или попыткой перезаписи.
4. Не обязательно что бы все данные хранились на 1 устройстве (даже лучше что бы на разных, то есть раз в месяц записал, в следующем записывать на другое устройство).
Пс: Заранее спасибо за помощь. Сорь если не в той ветке тему поставил.
Зеркало. Только зеркало.
Т.е. по поводу п.п.3-5 ни у кого возражений нету? Я рад, чесслово. Подрастают правильные, годные (ТМ) админы, есть нам смена... ;-)
PS: Забыл добавить к п.3 - если настраивать DFS, то _обязательно_ оную службу кластеризовать.
1) Два _одинаковых_ контроллера домена+леса (основной + резервный, роли FSMO раскидать самостоятельно, исходя из загрузки - у меня, к примеру, каждый компьютерный класс из четырех является дочерним доменом, обслуживаемым своим контроллером на виртуалке, т.е. загрузка ролей основных контроллеров понятна, а у кого-то может быть совсем иначе), оба-два также корневые серверы DNS, интегрированные в AD, только безопасное обновление.
2) На оных контроллерах ставится StarWind HA Storage, на коем создаются несколько мелких HA дисков (свидетель, всякие там DHCP/DFS/iSNS/пр.) и один большой - пул виртуальных машин.
3) На контроллерах устанавливается кластер (HA свидетеля мы уже сделали на шаг раньше), в кластер запихиваются всякие там сервисы DHCP/DFS/iSNS/пр. - см.выше; все подключаются через iSCSI с использованием MPIO.
4) Берутся еще три _одинаковых_ сервера, на которых также поднимается кластер (трехнодовый, без диска-свидетеля) и вешается сервис виртуальных машин (в данном случае через Hyper-V), диск для VM подключается как Cluster Shared Volume через iSCSI от StarWind HA Storage.
5) На втором кластере создается туева хуча VM для служебных целей, где брать место - понятно из п.4 (не забывать про распределение ресурсов процессоров и памяти! внимательно смотреть оснастку Hyper-V нынешней версии!).
6) Если есть еще пара серверов - не полениться настроить кластер 1С 8.х, очень способствует спокойному сну. ;)
7) Все это повесить на хороший бесперебойник, типа APC 10+ KVA, настроить на оном сетевой шатдаун (ну и соответственно, выключение на клиентах, включая виртуалки).
8) Не забыть про _хорошее_ сетевое оборудование - несколько портов на каждый физический сервер для LAN + несколько портов для iSCSI с MPIO (политику брать по желанию - я предпочитаю RoundRobin); свитчи ставить третьего уровня и выше, отдельно на LAN, отдельно на iSCSI, желательно все свитчи дублировать.
9) Оставшееся свободное место на всех серверах расшаривается под папки DFS (по паре источников на каждое корневое имя достаточно, главное чередовать серверы-источники, чтобы не получилось одновременного падения доступа к копиям папок).
Ну а далее из данного конфига можно делать все, что придумается, включая бэкапы... ;)
Если кто скажет, что я параноик, все можно сделать проще и дешевле, ну и т.п. - отвечу просто: поработайте с мое, а там посмотрим...
Накой л3 свичи там, где их задача сводится к свичеванию трафика в пределах одной подсети? :) л3 свичи вообще-то для маршрутизации между подсетями ставятся...
И да, не все л3 свичи одинаково полезны, поставит человек длинки какие-то, потом глюков с ними отгребет немеряно... Впрочем, старые киски немногим лучше в этом плане, их моск тоже имеет свойство вспухать от арп флуда/icmp флуда/мультикаст флуда/прочего, что идет на CPU.
И если уж зашла речь о бесперебойниках и т.п. - лучше 2 бесперебойника, и сервера с двумя БП. Мощность - не обязательно с 10-кратным запасом, хватит и 2-3 крат. Аккумы - лучше нештатные, к примеру, кучка 6СТ-180.
Забыл про это. Да, питальники на серверах минимум двухмодульные, а лучше (у меня так) - трехмодульные, работающие в режиме 2+1.
На второй бесперебойник размера стойки и самой серверной не хватило. ;)
Кста, действительно использую нештатные аккумы тоже... ;)
Да ты не поверишь! :)
1) Для обеспечения корректной работы MPIO даю всем портам карточек, используемых для iSCSI, номера _разных_ подсетей (типа, 192.168.100.х, 192.168.125.х, ну и пр.); при этом оные карты (4 порта) воткнуты в 4 разных свитча, общающихся между собой.
2) Почему общающихся - только на два из четырех свитчей еще идет по линии 10G от контроллеров домена, каждая из которых в свою очередь разбита на два VLAN'а, а вторая пара свитчей является расширением первой (аггрегировано шесть 1G-каналов).
3) Почему - да так получилось... ;)
4) В обще-пользовательской сети у меня еще пять подсетей через VLAN (4 компьютерных класса + все остальные) - так проще рулить.
Как-то так. ;)
Дык каждый интерфейс/подсеть - в свой влан, и делов... Накой их друг с другом маршрутизировать?
А прочие вланы, одновременно поднятые на нескольких физ. интерфейсах (если таковые имеются) - в бондинг (active-backup).
К слову, чем меньше фич свичей юзается, тем стабильнее работа (в идеале - только вланы + возможно снмп для мониторинга). И л2 свичи обычно менее критичны к всяким вещам типа колец/флуда/etc - даже если моск попух и ушел в себя из-за чрезмерной нагрузки на него, свич продолжает свичевать как ни в чем не бывало...
Каждый коммутатор (из 4-х) обеспечивает свою подсеть. При этом, таргеты iSCSI обеспечиваются с двух компов через 10G - по одному штука на два из четырех свитчей. Разбиты пополам, каждая половинка на своем Влане.
Это ты так "напряг" свой колледж на нормальное железо?