Серверы Hyper-V присоединены к домену

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

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

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

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

Является ли описанная выше ситуация с DC в качестве виртуальной машины серьезной проблемой? Может ли длительное время простоя контроллера домена создать ситуацию, о которой я упоминал, когда вы даже не можете войти на хост, чтобы запустить или восстановить контроллер домена?

Единственный контроллер домена может быть гостем на виртуальной машине Hyper-V, а хост может быть членом домена.

Более фундаментальный вопрос: может ли организация принять такой уровень доступности в худшем случае. Выполните упражнение по обеспечению непрерывности бизнеса, демонстрирующее возможность восстановления AD DS и влияние такого сбоя.

• Подтвердите учетные данные локального администратора на хосте.
• Выключите DC и притворитесь, что он сломан.
• Создайте тестовый гость DC, используя любое дополнительное оборудование, если необходимо, рабочий стол. Полностью изолируйте его от сети в соответствии с рекомендациями AD DS для тестовой лаборатории.
• Восстановите контроллер домена из любых доступных резервных копий на тестовый контроллер домена.
• Тестируйте приложения на реальном DC, инвентаризируйте, что сломалось. Кэшированные пароли должны работать, но не изменения пользователей или поиск в каталогах. Если DNS не работает, многие вещи не будут работать.
• Отключите тестовый DC, включите производственный DC.

Один гостевой контроллер домена может подойти. Легко управлять. Экономия на издержках. Несколько часов простоя, если случится худшее и домен будет уничтожен, при условии, что резервные копии в порядке.

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

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

Я видел множество сценариев и лично я не считаю это чем-то особенным.

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

Сценарий домена упрощает управление, но сама идея домена контроллер выходит из строя кажется проблематичным.

Нет, совсем нет. На самом деле это поддерживаемый сценарий, который был представлен в одной из более ранних версий, даже для кластеризации (и ЭТО было проблематично, поскольку кластер не мог запуститься без контроллера AD - теперь они могут).

На нем нет абсолютно ничего, что не поддерживается в качестве стандартной конфигурации уже много лет.

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

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

У большинства небольших сайтов нет бюджета на покупку второго физического сервера.

Извините, это плохой аргумент. Это те самые сайты, которые ноют как сумасшедшие - в тот момент, когда первый сервер выходит из строя, и оборудование ДЕЙСТВИТЕЛЬНО выходит из строя. Если ваш бизнес зависит от сервера, насколько быстро второй сервер дороже, чем оплата труда людей или аренда не для бизнеса? Тот же уровень аргументации, что и "мы не делаем бэкапы" - ничего общего с корпоративным (у ТЕХ много запасного), но со здравым смыслом.

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

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

Является ли описанная выше ситуация с DC в качестве виртуальной машины серьезной проблемой?

Прошу прощения, но это задокументированный стандартный сценарий... который сводится к "насколько вы знаете машины, с которыми работаете". Когда-то это был хак, с тех пор он стандартизирован.

Может ли длительное время простоя ЦОД создать ситуацию, как я уже упоминал, когда вы не мог даже войти в хост, чтобы запустить или восстановить DC?

Если вы не будете достаточно осторожны и отключите пароль локального администратора, который может служить точкой аварийного доступа (и который никогда не следует отключать в сценарии без большого количества резервных копий) и который ДЕЙСТВИТЕЛЬНО существует в тот момент, когда вы не запускаете AD на машине .... риска нет.