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

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

Имеем небольшую контору - 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.8K подписчиков

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

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

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

AlexKatz

2 года назад

Правильно говорили про то, чтобы не вводить в домен хост и\или оставить активной встроенную учетку админа. Или вообще развернуть виртуализацию на XCP-NG или Proxmox.

Вообще неплохо бы старый сервер оставить под резервный контроллер домена (физический или виртуальный). Лежачий контроллер домена может доставить очень дохера проблем, а резервный хотя бы не даст парализовать работу полностью.

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

opertung

2 года назад

Вообще неплохо бы старый сервер оставить под резервный контроллер домена (физический или виртуальный).

Спасибо! Наверное так и сделаю.

показать ответы

psyac1d

2 года назад

Скорее всего какие то важные вопросы я, по незнанию, вообще не задал

main_server (windows server 2016 с гипервизором)
- virtual_server01
- virtual_server02
- virtual_server03
.........................
- virtual_serverNN

да, например про лицензирование NN+1 серверов)

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

opertung

2 года назад

А вот есть! ;) в наследство досталось

показать ответы

Shinokama

2 года назад

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

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

opertung

2 года назад

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

Shinokama

2 года назад

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

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

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

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

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

opertung

2 года назад

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

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

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

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

показать ответы

alko999

2 года назад

Друзья, много красивых и интересных решений вами здесь предложено. Понятно, что каждый топит за то в чем прокачал скилы. Только я не пойму, какого хрена в нынешней мировой обстановке топить за лицензирование? Вас что, кто-то по этому поводу все ещё напрягает? По мне так абсолютно дохлое и не нужное в н.в. направление...

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

opertung

2 года назад

Да. Согласен с предыдущим оратором. В УК, грубо говоря, две статьи - за нелицензионный софт и за распространение вредоносного ПО. На лицензионность ПО сейчас плевать, а вот за кряки к нему - нет.

К сожалению уже проходили это...

mrskytis

2 года назад

"можно ли так делать? Конкретно - можно ли домен и AD пихать на виртуальную машину?"

Можно. Только бэкапы этой вм не делайте. Лучше иметь два контроллера, и выводить упавший из домена, взамен поднимая новый.

"Надо ли вводить потом main_server в домен?"

Не надо и нельзя. После перезагрузки гипервизора из-за того что вм контроллера еще не запущена, на гипервизоре могут не стартануть службы, соответственно вм контроллера может вообще не запуститься. Если до кучи на гипервизоре отключить локальные УЗ с административными правами, то ситуация может стать еще веселее при попытке залогиниться на нем.

"Насколько такая конструкция будет отказоустойчива?"

Отказоустойчивость отсутствует, если гипервизор в единственном экземпляре.

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

opertung

2 года назад

Отказоустойчивость отсутствует, если гипервизор в единственном экземпляре.

Спасибо! Не знал...