Как лучше организовать набор виртуальных серверов?⁠⁠

Никогда таким не занимался, но вот пришлось...

Имеем небольшую контору - 70 человек-пользователей в двух филиалах в разных городах, но численность будет расти. В одном из филиалов есть т.н. сервер с кучей ролей сваленных в кучу (домен, AD, LDAP, файлопомойка, WSUS, бэкап, kaspersky security center, и еще по мелочам).

В другой филиал был закуплен новый сервер supermicro, два ксеона по 10 ядер, оперативки 256 гб, и восемь больших винтов. И, соответственно, задача - переехать со старого сервера на новый.

Я думаю что чтобы все было красиво нужно все роли разнести по разным виртуальным серверам на базе Windows server 2016 с ролью Hyper-v. Таким образом, в моем понимании, получится такая структура:

main_server (windows server 2016 с гипервизором)
- virtual_server01 (windows server 2016 - домен+AD)
- virtual_server02 (windows server 2016 - WSUS)
- virtual_server03 (windows server 2016 - kaspersky security center)
.........................
- virtual_serverNN (windows server 2016 - что-то там)

И вот тут у меня начинаются сомнения, можно ли так делать? Конкретно - можно ли домен и AD пихать на виртуальную машину? Надо ли вводить потом main_server в домен? Насколько такая конструкция будет отказоустойчива?

Скорее всего какие то важные вопросы я, по незнанию, вообще не задал... Голова кругом, а сделать нужно естественно вчера. Короче, дайте мне пинка в нужном направлении, куда смотреть, чего читать, может кто поделится опытом?

126

Лига Сисадминов

2.3K постов18.9K подписчиков

Добавить пост

Правила сообщества

Мы здесь рады любым постам связанным с рабочими буднями специалистов нашей сферы деятельности.

Вы смотрите срез комментариев. Показать все

Shinokama

2 года назад

Ну, поехали. Начнем с того, как вообще это должно быть.

1. Два и более виртуальных сервера. В идеале в кластере. В идеале хранилка отдельно, третьим сервером. Но в современном сценарии можно и 10G линками их соединить и заебашить гиперконвергентный кластер. Виртуалки соответственно могут перетекать с сервака на сервер.

2. Лицензирование. Правила лицензирования MS меняются каждую редакцию. В последний раз, когда я этим занимался они хотели либо определенное количество лицензий за виртуалку, либо датацентр лицензии на железные серваки.

3. Виртуализация и ее проблемы. Есть проблема с часами. Часы гипервизора будут пробрасываться в виртуалку ад, потом обратно на гипервизор. Это будет плодить нефиговые проблемы. Так что либо гипервизор не в том домене, который обслуживает виртуалка на нем, либо еще один железный контроллер домена. И в принципе контроллеры домена должны быть как минимум по паре на сайт(локация, офис).

4. Надежность. Любые проблемы на виртуалках не должны аффектить на хосты виртуализации. DNS и DHCP, не должны аффектить проблемами на хосты. По сути ты должен мочь выключить всю виртуализацию и у тебя должны остаться рабочие хосты виртуализации.

Так же не стоит хранить диски виртуалок на системных дисках.

5. Резервное копирование. Должен быть отдельный сервак с дисками, который бы бэкапил твое хозяйство, в идеале по формуле 3 2 1 (3 копии, 2 типа носителей, 1 удаленно). Но кто ее эту формулу выаезет. К слову, отлично Hyper-V бэкапит Veaam.

Резюмируя отличия планируемого развертывания от эталонного.

Готовься к тому, что будет, когда твой сервер выйдет из строя, где и как ты будешь поднимать осиротевшие виртуалки.

Проработай лицензирование, сверившись с актуальной для твоей редакции методикой.

Разберись с резервным копированием. Помни, есть только 2 типа админов, те, кто бэкапы не делает, и тех, кто их уже делает. Из 1 категории во вторую переходят потому что "не понравилось".

Хосты виртуализации не должны зависеть от того, что они виртуализируют.

раскрыть ветку (10)

Serpentary

2 года назад

Как-то всё пессимистично и уж очень крупно-корпоративно. Best practice действительно около того, но давайте не будем пугать человека и будем реалистами?

раскрыть ветку (5)

Shinokama

2 года назад

На моей практике стреляло все, что я здесь перечислил. Виртуалки не могли подняться потому что негде. Бэкап был на другом разделе того же массива. Бэкап не делался перед тем, как отъебнул массив. На сервак нельзя было зайти, потому что контроллер домена приуныл. NTP служба сходила с ума до полной невозможности логина.

Замещать надежность системы авосем можно когда у тебя ставки небольшие. Но если несколько часов простоя повлекут за собой крупные финансовые и репутационные потери - выбор очевиден.

Я работал в разных по размеру и важности компаниях. И в принципе прошел нефиговый такой путь от "сервер после потопа горячей водой? сойдет." до "вы безумцы, если считаете, что вам не нужен резервный ЦОД".

если @opertung, более-менее обрисует масштабы нагрузок и что там вообще происходит, то не будет большой проблемой рассмотреть и предложить подходящее по доровизне-сложности-надежности решение.

раскрыть ветку (4)

opertung

2 года назад

Еще бы мне самому кто нибудь из руководства объяснил бы что они хотят.

Задача звучит так: вот тебе сервер - нужно что бы были расшаренные папочки для складирования всяких нужных документов по задачам, у всех разные права на доступ к этим папочкам. Все!

Начал осторожно уточнять что к чему. В итоге. Количество юзеров - 70, а может быть 500 наверное, когда нибудь. Вот еще почта должна быть своя, а к маилру запретить. А еще каспера и обновления обязательно, потому что по регламенту вышестоящей организации нужно. А еще удаленный доступ. А еще "облако", что бы это ни значило, для больших объемов инфы наверное, еще и защищенное поди...

В общем пытаюсь сам родить к себе требования. А ведь я не настоящий сварщик (с). :)

раскрыть ветку (3)

Shinokama

2 года назад

касательно облаков папочек и т.д. - посмотри в сторону nextcloud.

раскрыть ветку (2)

opertung

2 года назад

Спасибо! Похоже то что надо. Буду пробовать.

Serpentary

2 года назад

Owncloud?
https://freehost.com.ua/faq/articles/nextcloud-protiv-ownclo...

pfsenses

2 года назад

Лицензирование. Правила лицензирования MS меняются каждую редакцию. В последний раз, когда я этим занимался они хотели либо определенное количество лицензий за виртуалку, либо датацентр лицензии на железные серваки.

В последний раз менялись с 2012 R2. Там было лицензирования посокетно, сейчас поядерно. Принципы не менялись вообще.

Виртуализация и ее проблемы. Есть проблема с часами. Часы гипервизора будут пробрасываться в виртуалку ад, потом обратно на гипервизор.

Есть возможность отключить синхронизацию времени ВМ с хостом. Ну или наоборот, настроить синхронизацию времени хоста с контроллерами.

Разберись с резервным копированием. Помни, есть только 2 типа админов, те, кто бэкапы не делает, и тех, кто их уже делает. Из 1 категории во вторую переходят потому что "не понравилось".

Три типа. Есть еще те, кто проверяет работоспособность сделанных бэкапов. Причина перехода в эту категорию - та же.

blackmashine

1 год назад

> В идеале хранилка отдельно, третьим сервером

Кластера строятся путем дублирования компонентов. В такой конфигурации хранилка будет единой точкой отказа.

раскрыть ветку (2)

Shinokama

1 год назад

Если стоимость восстановления из бэкапа + простой ниже стоимости приобретения и обслуживания двухголовой хранилки, или двух серверов хранения с синхронной репликации и сопутствующим цирком, то это оверинжениринг

раскрыть ветку (1)

blackmashine

1 год назад

Есть способы сделать все на двух серверах. Дрбд тот же. И это будет дешевле и надежнее 2ухузлового кластера с внешней хранилкой на единственном сервере

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку