Во-первых, я не очень разбираюсь в HyperV и материалах Microsoft, и это может быть сомнительный вопрос. Тем не менее, с тех пор, как я узнал о следующей ситуации, мне интересно, действительно ли это правильный путь или просто чепуха.
Компания собирается виртуализировать свою инфраструктуру. Выбранная компания, которая должна внедрить виртуализацию, планирует сделать это с помощью HyperV. Я визуализировал их план:
На мой взгляд, в этом есть несколько странностей:
Заранее спасибо.
Нет, это не конфигурация Best Practices.
Как правило, хост Hyper-V должен запускать только минимально необходимое программное обеспечение, чтобы быть хостом Hyper-V. Это означает роль Hyper-V, антивирус, службы хранения (iSCSI, дисковые пространства и т. Д.), Агенты резервного копирования и агенты системного мониторинга. На хосте Hyper-V не должны работать службы, ориентированные на пользователя.
Допускается запуск DC внутри виртуальной машины. В Windows 2012 R2 узел Hyper-V, присоединенный к домену, может успешно загружать и запускать виртуальную машину без доступного контроллера домена. До 2012 R2 хост Hyper-V должен был связаться с контроллером домена, прежде чем он сможет запустить виртуальные машины. Однако здесь есть особые требования к конфигурации. Лично я бы использовал выделенный физический контроллер домена только для простоты.
Я не догадываюсь, почему они так поступили. Для любого сервера Windows требуется минимум 8 стандартных лицензий, и каждая лицензия позволяет использовать 2 виртуальные машины. Таким образом, вы получите как минимум 16 виртуальных машин, просто лицензируя хост Hyper-V с минимальной лицензией. Нет никаких лицензионных причин ограничивать его до 4 виртуальных машин.
Ваш гипервизор должен быть гипервизором и ничем другим.
Если существует реальная потребность в поддержании невиртуализации SQL на основе производительности, то лучше будет получить второй сервер для запуска SQL. Однако, скорее всего, если это вся инфраструктура, вы можете обойтись виртуализацией SQL и разделением хранилища в Hyper-V, чтобы выделить часть для ваших баз данных, чтобы в этом хранилище больше не было ничего, конкурирующего за ввод-вывод. В зависимости от требований к производительности вам может даже не понадобиться это делать.
Пока вы используете Hyper-V 2016 и не присоединяете машину Hyper-V к домену, проблем с виртуализацией вашего контроллера домена не возникает. Если вы присоедините Hyper-V к домену, у вас могут возникнуть проблемы с подключением к серверу, если возникнет проблема с перезапуском вашей виртуальной машины DC. При наличии присоединенного к домену хоста Hyper-V размещение вашего единственного контроллера домена поддерживается с 2016, но я бы не стал этого делать. Независимо от того, что MS говорит в наши дни, безопаснее поддерживать хотя бы один физический DC в рабочем состоянии на случай, если возникнут проблемы с запуском виртуального, которые не позволят вам войти в систему Hyper-V для административных целей.
Однако вам не следует ставить WSUS на свой DC. К контроллерам домена следует относиться с той же спецификой, что и к гипервизорам. Выполняйте только то, что требуется, и ничего больше. В небольшом магазине очень распространено использование DNS / DHCP / DC на одном устройстве, просто изолируйте учетную запись службы DHCP. В большой сети лучше использовать DHCP на отдельном сервере.
Все это возможно и дешевле. С AVMA вы упростите активацию / лицензирование, если вы лицензируете все ядра на хосте. Я предполагаю, что вы используете Server 2016 Datacenter, и в этом случае добавление дополнительного сервера для WSUS покрывается вашей лицензией. Datacenter предоставляет неограниченное количество виртуализированных сред, когда лицензируется весь хост, поэтому лучше отделить WSUS от вашего DC.
Подробнее о настройке DHCP см. Здесь: https://blogs.technet.microsoft.com/stdqry/2012/04/03/dhcp-server-in-dcs-and-dns-registrations/
Дополнительные сведения о передовых методах работы с другими приложениями на Hyper-V см. Здесь: https://blogs.technet.microsoft.com/uspartner_ts2team/2014/01/15/if-im-using-hyper-v-what-other-services-should-run-in-the-host-os/
Для получения дополнительной информации об AVMA см. Здесь: https://blogs.technet.microsoft.com/hybridcloudbp/2016/01/29/windows-server-activation-best-practices/