Главная Virtualization, Без рубрики, Новое Полностью виртуальная инфраструктура на Hyper-V
  • Полностью виртуальная инфраструктура на Hyper-V

     

    В этой небольшой статье хотелось бы рассказать про свой опыт использования виртуализации инфраструктуры на базе Hyper-V из состава Windows Server 2008 R2. Статья будет также применима и к Windows Server 2008 (R1). А если конкретно, то хотелось бы рассказать про проблему полной виртуализации инфраструктуры. Под полной виртуальной инфраструктурой я подразумеваю среду, где Hyper-V развернут в конфигурации Failover Cluster и все серверы, включая контроллеры доменов, виртуализируется.

    Чтобы было более понятно, рассмотрим следующую инфраструктуру. Есть группа хостов с Windows Server 2008 R2. Вы из этих хостов собрали кластер и хотите перенести всю вашу серверную инфраструктуру из физического состояния в виртуальное. Но встает дилемма. Среди физических серверов, которые вы хотите перенести в среду виртуализации, есть контроллеры доменов. Тут вы вспоминаете, что кластер зависит от службы каталогов и получается, что вам нельзя создавать взаимозависимость: кластер виртуализации от службы каталогов и наоборот.

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

    Решение.

    Failover-кластеру без службы каталогов очень плохо. Хотя бы по той причине, что служба каталогов используется для аутентификации узлов в кластере.

    Вернемся к нашей инфраструктуре. Мы все-таки развернули кластер Hyper-V, перенесли все серверы, в том числе и контроллеры доменов, в виртуальную среду. Физические серверы либо задействовали в качестве узлов кластера, либо полностью вывели из эксплуатации. Виртуальные машины разместили на Cluster Shared Volume (CSV), дабы задействовать замечательную функцию Live Migration.

    Получилось следующее:

    В один прекрасный момент выключается электричество, а вместе с ним через некоторое время выключаются ваши физические хосты и виртуальные машины.

    Включают электричество, хосты Hyper-V начинают грузиться, а вот виртуальные машины не стартуют. Это происходит по следующей причине. Виртуальные машины являются ресурсами кластера, служба ClusterSvc должна, в соответствии с зависимостью ресурсов, поочередно их поднять (перевести в online-режим). Но служба кластеров сама зависит от службы каталогов, контроллеры доменов которой являются ресурсами кластера. Получается замкнутый круг.

    Есть традиционные способы решения данной проблемы:

    Использовать хотя бы один физический сервер для контроллеров доменов. Согласитесь, что при текущей производительности серверов, не совсем целесообразно потратить на контроллер доменов 5-10 тыс. долларов (с последующей утилизацией раз в 3-5 лет). Для инфраструктур, характеризующих себя как централизованные и средние по размерам, хотелось бы максимально утилизировать вычислительные ресурсы, абстрагироваться от аппаратного обеспечения, и все это сделать с минимальными затратами. Децентрализованные инфраструктуры могут такой проблемы не ощущать.

    Использовать хост Hyper-V как контроллер доменов. То есть, развертываем роль ADDS на одном из узлов Hyper-V. Это уже лучше, чем первый случай, но все же есть некоторые проблемы:

    Проблема безопасности и проблема делегирования полномочий. Если развернуть RWDC на Hyper-V хосте, то трудно будет ограничить администратора среды виртуализации от возможности воздействовать на службу каталогов. Сразу скажу, что здесь можно долго спорить на эту тему, поскольку можно сказать, что если есть физический доступ к хосту, то без проблем можно получить доступ к виртуальным машинам. И это верно. Поэтому оставлю тему безопасности за рамками данной статьи. Возьмем за веру, что проблема с безопасностью все же есть в этом случае. Также можно установить RODC и это решит некоторые проблемы с безопасностью, но возникают другие проблемы. Update: чуть позже накопал, что RODC не поддерживается на узлах кластера.  http://support.microsoft.com/kb/281662/en-us

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

    Проблема с лицензированием. Конечно, с лицензированием проблем здесь нет, но вот у вас проблемы появятся. Если хост Hyper-V выполняет какую-либо роль кроме виртуализации, то вы лишаетесь возможности в полной мере покрыть хостовой лицензией запущенные экземпляры виртуальных машин. Например, в случае с Standard-лицензией вообще лишаетесь возможности использовать хостовую лицензию для лицензирования одной запущенной виртуальной машины, а в случае с Enterprise – одной. То есть с Enterprise-лицензией можете лицензировать запуск не 4х виртуальных машин, а только трех.

    В оригинале это звучит так:

    * Если запущено максимально разрешенное количество экземпляров, экземпляр в физической операционной среде может использоваться только для запуска программного обеспечения виртуализации устройств, обеспечения служб виртуализации устройств или для запуска программного обеспечения для управления операционными средами и их обслуживания на лицензированном сервере.

     

    А теперь, как я решал данную проблему.

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

    Тем самым вы решаете проблему взаимозависимости. Теперь контроллеры доменов живут в виртуальных машинах и эти виртуальные машины не являются ресурсами кластера. При отключении электричества все прекрасно стартует.

    Правда в этом случае мы привязываем контроллер домена к конкретному хосту и он (контроллер домена) не может быть перемещен на другой хост с помощью Quick Migration или Live Migration (хотя может быть перемещен другими способами). Но это не беда. Высокая доступность контроллеров доменов достигается совершенно другим способом – избыточностью. На необходимое количество контроллеров доменов могут повлиять многие факторы, здесь мы их обсуждать не будем.

     

    Некоторые рекомендации (и даже требования):

     

    1. Создавайте виртуальные машины с контроллерами доменов на дисках, не являющихся кластерными ресурсами. Это могут быть как локальные диски (DAS), так и диски с СХД.
    2. Режим запуска виртуальных машин: Always Automatically Turn On The Virtual Machine или Automatically Turn On The Virtual Machine If It Was Running When The Physical Server Was Stopped
    3. Для службы кластеров (ClusterSvc) необходимо произвести настройки восстановления. Те, что на вкладке «Восстановление» свойств службы ClusterSvc оснастки Services.msc. Для всех сбоев необходимо указать перезапуск службы. Не могу сказать какие конкретно значения для «Перезапуск служб через:» вам подойдут, необходимо подбирать их индивидуально. Я использовал 3 минуты.
    4. Сократите интервал отображения меню восстановления. Настроить можно с помощью апплета «Система» панели управления.На самом деле я слукавил, когда чуть выше сказал, что все прекрасно стартует. Не совсем. Может возникнуть дополнительная проблема.

    Проблема №2.

    Дело в том, что есть еще одна взаимозависимость: служба каталогов от DNS и DNS от службы каталогов.

    Возникает она по следующей причине. Контроллер домена, при старте, пытается произвести репликацию своих контекстов именования (это при условии, что контроллер в лесу не один): пока не произведет репликацию, не будет выполнять свои функции. Служба DNS, желая при старте работать с самыми актуальными данными, откладывает загрузку интегрированных в AD зон, до момента, когда служба каталогов реплицирует данные и оповестит об этом службу DNS. Репликация AD, как известно, зависит от DNS: контроллер домена пытается получить IP-адреса своих партнеров по репликации с помощью DNS. А DNS в это время не работает, поскольку ждет AD. AD ждет DNS, DNS ждет AD. В свою очередь от DNS также зависит кластер и аутентификация. Через какое-то время служба каталогов все-таки даст добро службе DNS и та загрузит зоны. Этот timeout зависит от количества разделов, которые обслуживает контроллер доменов и примерно составляет 20 минут для 5 разделов (для контроллеров с 2008 R2 я наблюдал намного меньшую задержку – 5 минут).

    20 минут для кого-то могут быть вполне допустимы, а для кого-то нет. Попробуем решить эту проблему.

     

    Способы:

     

    1. Использовать в качестве DNS сервера сервер с другой площадки. Скорее всего, в этом случае у вас не должно возникнуть и первой проблемы.
    2. Установить дополнительный физический сервер с ролью DNS. Этот сервер будет обслуживать вторичную зону для _msdcs корневого домена и доменную зону локального домена (главная задача разрешить DSAGUID партнера по репликации в FQDN и FQDN в IP-адрес) Этот способ конечно не подходит. Мы вернулись опять к проблеме с физическим сервером. В этом случае проще сразу развернуть физический контроллер доменов.
    3. Установить роль DNS на хосте Hyper-V? Можно, но получаем те же проблемы, что и обсуждались чуть выше.
    4. Отключить начальную репликацию. Это делается установкой значения Repl Perform Initial Synchronizations в 0 для ключа:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.  Можно, но не рекомендуется. Не рекомендуется хотя бы по той причине, что таким образом происходит попытка решить проблему с существованием в лесу (или домене) нескольких FSMO. Лучше такой способ не использовать.

    Использовать не интегрированные в AD зоны (полностью или частично). Знаете да, какие преимущества дает хранение зон в AD? Если вам эти преимущества не нужны, то можете использовать и этот способ.

     

    Сделать так, чтобы имя партнера по репликации разрешалось без участия DNS-сервера. Как это можно сделать? Способов много. Дополнительно стоит сказать, что, начиная с Windows Server 2003 SP1, появилась функция name resolution fallback, на тот случай если не удастся разрешить DSAGUID контроллера домена. Цепочка следующая: GUID -> FQDN -> NETBIOS-имя. То есть, если не удается разрешить CNAME GUID, то происходит попытка разрешить FQDN, если и это не удается сделать, то происходит попытка получить IP по NETBIOS-имени.

     

    Поэтому проблему можно решить:

     

    • Использованием HOSTS-файла. В хост файл можно внести запись о партнере по репликации. Можно добавить как GUID._msdcs.<имя_корневого_домена>, так и FQDN:

    <IP-адрес партнера по репликации> <DSA GUID>._mcdcs.<имя корневого домена>
    <IP-адрес партнера по репликации> <FQDN партнера по репликации>

     

    • Использованием файла LMHOST. Внести в файл соответствующую запись NETBIOS.
    • Использованием WINS-сервера. Наверное, наиболее предпочтительный способ.
    • Использованием NETBIOS-широковещания для разрешения имени. Если контроллеры доменов в одном широковещательном домене и Netbios-over-TCPIP не отключен (включен по умолчанию), то с проблемой №2 вы вообще не должны столкнуться.

     

    Внося записи в файлы HOSTS и LMHOSTS, необходимо отдавать себе отчет в том, что такие изменения в скором времени вами забудутся, и, при возникновении проблем с разрешением имен, вы потратите дополнительное время на поиск причины. Поэтому тщательнейшим образом документируйте вносимые изменения. То же самое касается локального изменения реестра: лучше делать изменения централизовано, например, с использованием групповых политик, а иначе концов не сыщете.

    Надеюсь, что представленные в этой статье рекомендации, помогут вам.

     

    Как установить Hyper-V кластер: http://lmgtfy.com/?q=how+to+install+hyper-v+cluster

    О первоначальной репликации: http://support.microsoft.com/kb/305476/en-us

    О проблеме загрузки DNS-зон: http://support.microsoft.com/kb/2001093/en-us

    LMHOSTS: http://support.microsoft.com/kb/101927/en-us

    Ефимов Геннадий, MCP

Комментарии

  1. Подозреваю, что для нормального датацентра не проблема держать один сервер DC на железе. Ну ПКшку можно поставить в крайнем случае.
    Плюсы:
    – Конфигурация будет без “костылей” для старта DC на виртуалках.
    – В случае проблем с запуском Hyper-V (аутентификации на них за отсутствие запустившегося DC) есть железка с живым DC.
    Минусы:
    – Железный сервер надо выделить

  2. to Дмитрий:
    – Понятие нормального датацентра очень растяжимо.

  3. В случае с кластером схема с лицензией Enterprise несколько отличается от стандартной 4:1, так что проблема с лицензированием несколько надумана. Как, впрочем, и с безопасностью. Это к тому, что схема с размещением контроллерами на узлах кластера тоже поддерживаема, но не рекомендуема.

    Если уж и делать контроллер виртуальным, то на отдельностоящем Hyper-V, на мой взгляд.

  4. Позволю пару комментариев с позиции архитектора Microsoft.
    Начну с главного и бесспорного – с лицензирования.
    Делая заявления по лицензиям, не читайте русский ширпотреб. Единственный верный вариант – английский документ Product Use Rights.
    В частности, про бесплатные экземпляры ОС он говорит:

    If you run the maximum permitted number of instances (physical and virtual), the instance of the server software running in the physical OSE may be used only to:
    • run hardware virtualization software
    • provide hardware virtualization services
    • run software to manage and service OSEs on the licensed server

    Заметим, что с русским бредом типа “Если запущено максимально разрешенное количество экземпляров, экземпляр в физической операционной среде может использоваться только для запуска программного обеспечения виртуализации устройств, обеспечения служб виртуализации устройств или для запуска программного обеспечения для управления операционными средами и их обслуживания на лицензированном сервере” есть разночтения по последнему пункту.
    В реалии я могу на узле установить всё что моей душе угодно – контроллер, DHCP, сервер антивируса, WSUS, итд – все что попадает под “manage and service OSEs” – с пониманием, что я должен обслуживать лишь OSEs, запущенные на данном сервере. Что легко достигается при помощи Firewall.

    Далее по сути архитектуры. Вариант с некластеризованной машиной с контроллером на узле кластера теоретически возможен (VMM2008R2 падает при попытке навести курсор на такую ВМ, но вариант таки возможен). Однако, теряется эквивалентность всех узлов кластера и их взаимозаменяемость.

    В своих проектах, если я имею небольшой branch office, где дано всего два физических узла, которые я хочу сделать членами кластера Hyper-V, я делаю их физическими контроллерами – и членами кластера одновременно. Это поддерживаемая конфигурация, хотя и имеет некие сложности.

    Если я встречаю заказчика, которых мне заявляет, что он хочет сделать 4+ узловой кластер на площадке, но не имеет сервера для контроллера, я ему объясняю, что он му.., что он не прав. И требую контроллер – пусть ставит ПК в качестве контроллера.

    Хорошая новость – в WS2012 кластер стартует, CSV работает, машины запускаются и при недоступности контроллера домена. Об этом я вскоре напишу отдельную заметку.

  5. to Денис Дягилев:
    ну в общем то, я это все и отметил: безопасность, поддержку…
    Про лицензирование: отличается, но эти отличия не влияют на написанное.

  6. to Alex A. Kibkalo:
    а что в последнем предложении про лицензирование не так?
    • run software to manage and service OSEs on the licensed server
    • запускать софт по управлению и обслуживанию OSEs на лицензируемом сервере

    Вас не смущает, что есть еще и “may be used only to”?
    Почему не написали: может использоваться для любых целей, кроме… ?

    С VMM2008R2 у меня проблем не было.

    Про взаимозаменяемость: тут необходимо рассматривать вопрос более тонко. Например, собрать требования по host fault toleranse. Если например два хоста, то развернуть по одному контроллеру на каждом. Если три, четыре и допустим отказ одного узла, то опять же будет достаточно развернуть на двух узлах. Мысль ясна? К тому же, виртуальные машины легче перенести с хоста на хост, чем если бы мы поставили контроллер домена физически.

  7. я-то думал что основная проблема со временем на виртуальных контроллерах 🙂
    а тут люди ПК жалеют…

  8. to Alex A. Kibkalo:
    🙂 я понял что имелось ввиду про неправильное толкование последнего предложения.
    Согласен что WSUS и антивирус можно причислить к management-сервисам, но контроллер и DHCP это скорее всего инфраструктурные сервисы. Если конечно у MS есть какая-то конкретная классификация продуктов, то хотелось бы ее увидеть.

  9. Изначально придерживался вашего способа решения проблемы с контроллерами домена, однако,
    у меня кластер из двух серверов и хранилища,по одному контроллеру домена на каждом узле (первичный и вторичный). При полном рестарте, после отключения питания, все кластер не стартует. Приходится отключать кластер на обоих узлах, перезапускать службы и после этого, с диким количеством ошибок в логах, кластер стартует.

  10. По поводу лицензирования. Имея W2008R2 Ent, поставив его в режиме core могу поставить 4 VM W2008R2 Ent + Linux VM. Так?

  11. to Андрей:
    Windows лицензии на Linux не нужны. Если только Linux этого не требует 🙂
    Получается, на Hyper-V можете запускать любое количество VM Guest с Linux.

  12. При использовании на производственной площадке Ubuntu Server – придется покупать (возможно, это странно звучит) в российской компании, с пакетом бумажек.

  13. to Vladislav Artukov:
    нужно будет покупать лицензии Ubuntu Server? или Windows? не совсем понятно что вы хотели этим сказать.

  14. Чтобы использовать “бесплатный” Linux, такой как Linux-ветка Ubuntu – предприятие должно его приобрести с юридически корректной передачей прав.

    А не просто “скачал и впееред!”.

  15. to Vladislav Artukov:
    да это понятно, тут нужно индивидуально подходить. Но Windows лицензия все таки не нужна. Я думаю просто Андрей спрашивал про необходимость лицензии Windows на запуск экземпляра виртуалки с Linux. В лицензионном соглашении этот вопрос трудно понимается.

  16. Да было время , намучался так сказать даже без кластера локально разместить виртуальный DC на Heper-V (то есть без предварительного ввода узла Hyper-V в домен). А что уж говорить о кластере.Все эти костыли конечно не приятная штука. Хотелось бы все по уму, пускай даже это будет отдельный простой ПК-хотя бы с простеньким RAID-ом для физического DC!
    С vmWare в этом отношении все проще.
    Но если Alex Kibkalo говорит что текущие проблемы исчезнут в Windows Server 2012, то хотелось бы послушать как такое сконфигурировать ?

  17. to restless:
    Ну не знаю, у меня проблем как таковых не было. Единственное конечно с DNS пришлось посидеть, потюнить.
    Я очень сомневаюсь что в 2012 проблемы исчезнут. А вернее так: исчезнут одни, появятся другие. Вряд ли MS на 100% переписал свои продукты. База никуда не денется, зависимость от AD и DNS тоже не денется. Что до VMWare, так у нее тоже есть свои приколы.

  18. Значит первым делом выносить DC, тем более, что во многих конторах он уже стоит, что бы не искать костыли!

  19. Да и ребята, если говорить об экономии, даже если брать отдельно стоящий физический DC с лицензией Windows Server 2008 R2 Std, то все равно это будет намноооого дешевле, нежели без выноса DC в vmWare ! У меня в конторе все на vmWare vSphere 5-уже, приходилось много поработать и с веткой infrastructure 3.5 и 4-й сферой, но по долгу службы стал еще и Hyper-V заниматься и намного глубже. И скажу я вам как ни крути , бабок мы за сферу отдали+ еще на этой сфере в виртуалках та же винда серверная стоит- на нее еще нужны дополнительно лицензии. Так что расклад очевиден! Хотя для рынка СМБ vmWare никчему

  20. to Restless:
    Нельзя точно сказать, что будет дороже. Нужно исходить из требований. А потом уже считать.
    Как-то проводили презентацию, специально просчитывали решение в целом (железо, схд, лицензии и т.д.). Разные сценарии. Для SMB цена была одинакова, +-1000$, с увеличением нагрузки и требований (например, для vSphere 4 увеличение количества ядер на сокет) hyper-v был дешевле на $10-15k. Сейчас конечно в 5ке изменилось лицензирование. Нужно посчитать.

  21. Требования бесспорно! Это яупустил сорри!
    Но вот все таки костыли в Hyper-V на предмет полной виртуализации-это минус!

  22. to restless:
    ну не знаю, удалить виртуалку как ресурс кластера… как-то не очень это похоже на костыль.

    проблема с dns будет в любом случае, даже если контроллер физически будет.. проблемы может не быть, если контроллер будет на другой площадке и при старте системы будет полностью функционировать сетевая инфраструктура. Наверняка отключение электричества затронет и сетевую инфраструктуру, а это дополнительное время на загрузку, инициализацию железа, софта, протоколов и т.д.. Прописать fqdn или dsaguid в Hosts, дело тоже не хитрое, главное внести сведения в документацию, чтобы потом можно было найти. Fqdn контроллера редко меняется, dsaguid вообще не меняется (кроме доменного имени конечно).

  23. Тут вот в принципе все написано http://technet.microsoft.com/ru-ru/library/dd348476(WS.10).aspx

  24. “проблемы может не быть, если контроллер будет на другой площадке и при старте системы будет полностью функционировать сетевая инфраструктура.”

    Сетевые железки надо запитывать от отдельного ИБП, даже в случае SMB – это баксов 300 на 3 года.

  25. Для небольшого [недорогого] кластера вполне можно рассмотреть вынос “DC для запуска” на нетбук. Вместо ПК. Заодно решатся проблемы из-за отключения электричества вечером в воскресенье часов этак на 8-10 (не каждый UPS столько протянет).

  26. Ну в общем сходятся некоторые мнения от том, что все таки, хотя бы простенький DC “в сторонке”, надо иметь. Единственное конечно это покупка лицензии-она все таки денег стоит, но иначе по моему мнению “городить костыли”, на мой взгляд если следовать рекомендациям производителя, то и геммороя не должно особого быть!

  27. Я думаю вендор бы не порекомендовал ставить серверные ОС на нетбуки 🙂 Не это ли костыли?
    А здесь вполне поддерживаемое и живое решение.
    Лучше задействовать лишний физический сервер скажем под сервер резервного копирования. Это и то полезнее будет.

  28. >gexeg
    Нет не про ноутбуки, а вообще логика построения виртуальной инфраструктуры на HYPER-V- которая не предусматривает виртуализацию всех DC- как это легко делает vmWare.
    А сервер резервного копирования можно на худой конец и на внешнем DC поднять и даже средствами Windows Server 2008 R2- очень хороший WSB! Добавил HDD дополнительно и бэкапь.
    Не я даже не против, данная статья мне очень понравилась в части не совсем стандартных решений,
    но вот то, что не рекомендует вендор, более того если проблемы все таки начнутся, то тут уже тех поддержка не станет даже в вашу сторону смотреть-это уже минус.

  29. to Имя:
    У VMware нет зависимости кластера от службы каталогов, но например зависимость от DNS все же есть. Также зависимость AD от DNS и наоборот никто не отменял.
    WSB не поддерживает резервное копирование данных на CSV. Можно конечно из guest делать резервные копии. В общем, резервное копирование это не тема одной статьи и не этой, и уж тем более не в комментариях ее описывать.
    Одно дело рекомендации, а другое дело поддержка со стороны вендора. Microsoft предложенное решение поддерживает, поэтому у тех поддержки не будет аргументов отказать вам.

  30. К слову о поддержке… с чего она будет воротить нос от нетбуков? Не встречал еще требований/рекомендаций/запретов НЕ устанавливать серверные ОС на них 🙂 То что “это и так всем понятно”… ничего не значит. Понятно было на 2к/2003 и в свое время. Все таки очень многое поменялось за последние годы – качество железа и ПО в частности.
    Если проблем с драйверами нет (eval версии никто пока не отменял) – то нетбук во многих случаях будет лучшим решением и в плане отказоустойчивости, и в плане удобства (all-in-one, мало места, сверхнизкое энергопотребление/тепловыделение + аккумулятор, цена), чем установка крайне слабонагруженного сервера на отдельный ПК, пускай даже “типа сервер” (что сплошь и рядом во многих конторах). Установка же такого DC на полноценный отдельный брэндсервер… эмм… ну жаба душит же, отсюда и закономерное желание накачать машину зачастую нерекомендуемым функционалом, и последующие обращения в техподдержку, где этому всегда невероятно рады 🙂
    Не знаю как вам, а мне так очень жаль, что пока нет аппаратных решений (и возможно специальных ПО лицензий, по типу бесплатного Hyper-V) предназначенных для старта и поддержки в-сетки.

  31. to Дмитрий Караваев:
    да оно по всякому бывает. Серверы иногда даже под столом стоят и кого-то это устраивает.
    А кто-то и ноутбуками не брезгует.
    Да и кстати, HCL еще никто не отменял 🙂

  32. Дмитрий, а че все верно сказал, а еще Hyper-V иожно поднять на ноутбуках и хранилище к нему поставить iSCSI на unix и все это на десктоп, получается даже мобильный цод!!! И дешево и в большой рюкзак поместиться если что, считаю что тема размещения контроллеров поднята зря и излишня, когда есть еще ноутбуки, айпады и т.д.

  33. HCL? Для небольшой конторы? Один к стам наверное…

    Юра, вы меня с кем-то попутали наверное. Задача DC-стартёра в автономной коробочке с клавой и экраном – всего лишь разово поддержать запуск рабочего виртуального окружения с нормальными DC внутри, после нештатной ситуации. Подобное в худшем/лучшем случае случается раз в два-три года, и по большому счету вообще для этого полноценный сервер избыточен. Так же как и костыли из статьи.

  34. Вопрос: А зачем нужна “Полностью виртуальная инфраструктура на Hyper-V”, если это не поддерживаемое вендором решение?

  35. Господа, иди вы совсем отошли от жизни или простите зажрались…
    Поясню почему.
    По рекомендациям MS должно быть как минимум 2 сервера с ролью АД. Класс. Рекомендация номер 2. На сервере АД ничего кроме днс. ну возможно ДНСП.. отлично…
    Для работы части сервисов а в будущем для всего нужна структура PKI класс тоесть 1 сервер в офлайне и 1 онлайне. И еще сервер вебМодры в ДМЗ…
    Что мы имеем?
    4 физ сервера только для поддержки инфроструктуры .. Охренеть… 100 тыс сервер… и что мы имеем? 400тыс мертвого груза?
    А на сколько человек в офисе это поднято??? да не бойтесь на 40…
    И того ????? лицензии + сервисы поддержки … + железо 600 тыс на 40 человек?????????
    Вот за подобный разворот мне чуть бошку не оторвали как-то раз.
    О прикладных сервисах я молчу. Т.к. почта требует 2сервера.. SQL 1 сервер.. Терминалы до 15 еще сервер.. А про 2 сервера Lync я тихо помолчу..

    Вернитесь на землю господа. Не во всех компаниях по 300 человек и 10-12 физических хостов..

    Если этот вопрос поднимался для дата центра то глупость это. В центре всегда есть 2 свободные железяки для AD GС и второго DNS сервера ..
    А вот оптимизация структуры для офиса в 50 человек это да.
    Только не надо в меня SBS плеватся.. у компании не 1 и не 2 офиса… и не в одном городе.

  36. To Дмитрий:
    >>> 4 физ сервера только для поддержки инфроструктуры ..
    у ms нет рекомендаций по части физических серверов.

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

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

  37. То Ефимов Геннадий
    Забудте что есть виртуальные сервера. Подумайте что нужен базовый набор без BI. Подумайте что нужно Почта. Телефония. База данных.
    И посмотрите на скольких хостах вы это все сделаете.
    А потом подумайте о модулях BI.
    Потом прочтите мой пост и поймите почему я возмущен фразами класса “нафиг нужна виртуализация” если она не поддерживается вендорами и т.д.

  38. to Дмитрий:
    ничо не понимаю.. кого забыть?! почему не поддерживаются?!

  39. Ага точно где я? кто я? это что вообще…

  40. to Дмитрий:
    Ну примерно так. Я просто пока не готов, видимо, на ваши комментарии отвечать 🙂

  41. По поводу “Хорошая новость — в WS2012 кластер стартует, CSV работает, машины запускаются и при недоступности контроллера домена. Об этом я вскоре напишу отдельную заметку.”
    Подскажите, где можно почитать про успешный запуск кластера без доступности DC.