Решения для виртуализации контроллеров домена (часть 6)
Введение
На протяжении всей этой серии статей я обсуждал плюсы и минусы различных методов организации контроллеров домена в виртуализированной среде. Моим первоначальным намерением было обсудить размещение контроллера домена в лесах, состоящих из нескольких доменов. Однако я хочу отложить эту тему до части 7 и использовать эту статью, чтобы рассказать о том, что недавно произошло со мной.
Около двух недель назад моя сеть была серьезно повреждена ударом молнии. Последовавший за этим процесс восстановления преподал мне очень ценный урок о размещении контроллера домена. Несмотря на то, что моя история, вероятно, выставит меня идиотом, я решил пойти дальше и поделиться ею с вами в надежде, что вы сможете извлечь пользу из моего опыта.
При этом мне нужно начать с предоставления вам небольшой справочной информации о конфигурации моей сети. Поскольку я работаю дома, пишу книги и статьи, чтобы зарабатывать на жизнь, я превратил весь второй этаж своего дома в центр обработки данных. Большинство моих компьютеров — это лабораторные машины, которые я использую, когда пишу на разные темы. Например, я только что написал статью для Microsoft о SharePoint 2010, поэтому развернул SharePoint 2010 на лабораторной машине, чтобы проверить техники, о которых писал.
Хотя большинство моих компьютеров — это лабораторные машины, у меня есть и производственная сеть. Моя производственная сеть содержит несколько контроллеров домена, файловый сервер (для хранения всех моих статей, счетов и т. д.) и пару серверов Exchange.
Как вы можете себе представить, все компьютерное оборудование, которое я использую, приводит к астрономическим счетам за электричество. Мало того, что компьютеры потребляют электроэнергию, кондиционеру приходится много работать, чтобы компенсировать все тепло, выделяемое компьютерами. Поскольку я живу на крайнем юге, зимой иногда даже приходится включать кондиционер.
Около двух лет назад я решил посмотреть, смогу ли я сократить свои счета за электроэнергию, виртуализировав серверы в своей производственной сети. Процесс прошел гораздо более гладко, чем я ожидал, и с тех пор мои виртуальные серверы доказали свою стабильность и надежность.
Однако пару недель назад в мой дом ударила молния. Несмотря на то, что я в полной мере использую устройства защиты от перенапряжений и ИБП, удар молнии нанес моей сети значительный ущерб. Некоторые повреждения сразу бросались в глаза. Взорвались несколько ИБП и 24-портовый гигабитный коммутатор. Однако некоторые повреждения были более тонкими.
После того, как я устранил наиболее очевидные повреждения, я решил проверить работоспособность каждого из своих серверов, чтобы увидеть, есть ли какие-либо проблемы, которые изначально остались незамеченными. При этом я обнаружил, что один из дисков массива хранения, используемого для нескольких производственных виртуальных машин, неисправен. Я знал, что мне нужно решить проблему, но я действительно не слишком беспокоился. Массив был настроен на использование RAID 5, а остальные диски все еще работали.
На следующий день я удалил неисправный диск из массива и заменил его новым. Мне уже приходилось заменять диски в массиве раньше, поэтому я ожидал, что процесс пройдет так же гладко, как и в прошлом. Однако когда я заменил диск, я получил сообщение об ошибке, в котором говорилось, что основной том массива поврежден и что синхронизация с новым диском невозможна.
Все виртуальные серверы, чьи виртуальные жесткие диски были расположены в массиве, по-прежнему работали нормально, поэтому я решил, что мне нужно сделать резервную копию, прежде чем все станет еще хуже.
Поскольку хост-сервер работал под управлением Hyper-V, я решил выключить виртуальные машины, а затем экспортировать их в блок NAS. Мой план состоял в том, чтобы удалить поврежденный том из массива, создать его заново, а затем импортировать виртуальные машины. Однако, как вы, наверное, уже догадались, все пошло не так гладко, как я планировал.
Рассматриваемый сервер содержал четыре виртуальных сервера. Два виртуальных сервера были экспортированы без происшествий, а на двух других возникли ошибки.
После дополнительной диагностики я определил, что один из виртуальных серверов, который не удалось экспортировать, можно сохранить. Эта виртуальная машина действовала как файловый сервер, и к ней было подключено три виртуальных жестких диска. Только один из виртуальных жестких дисков был поврежден, и у меня была резервная копия диска, поэтому я просто отсоединил поврежденный виртуальный жесткий диск, а затем экспортировал виртуальную машину. Когда пришло время импортировать эту виртуальную машину, я импортировал ее обычным способом, вручную воссоздал том и восстановил резервную копию.
Четвертая виртуальная машина оказалась не такой простой. Он работал под управлением Exchange Server, а также действовал как контроллер домена. Теперь я должен сказать вам заранее, что Microsoft настоятельно не рекомендует запускать Exchange на контроллере домена и делала это с самого начала. Однако, как вы помните, этот сервер когда-то работал на физическом оборудовании. Так как я работаю в одиночку, я просто не мог оправдать стоимость аппаратных и программных лицензий, необходимых для запуска Exchange на выделенном сервере. После того как я виртуализировал сервер, ничто не мешало мне перенести Exchange на выделенную виртуальную машину. В конце концов, у меня есть еще два производственных сервера Exchange, работающих на выделенных виртуальных машинах. Это была просто одна из тех задач, до которых я никогда не добирался.
Во всяком случае, виртуальный сервер, выполнявший функции контроллера домена и сервера Exchange, был полностью поврежден (хотя каким-то образом продолжал функционировать). Я пытался использовать несколько различных методов для резервного копирования сервера, но, учитывая степень повреждения, резервное копирование было невозможно. Поскольку у меня была резервная копия за день до удара молнии, я решил рискнуть и попробовать использовать CHKDSK для восстановления тома. Однако в конечном итоге CHKDSK сделал том не загружаемым.
В тот момент я знал, что мне придется прибегнуть к удалению виртуальной машины и восстановлению резервной копии. Я действительно не ожидал, что процесс восстановления будет иметь большое значение, но размещение моего виртуального контроллера домена в конечном итоге вызвало некоторые серьезные проблемы.
Не поймите меня неправильно… Кое-что я сделал правильно. У меня был еще один работающий контроллер домена, который работал на другом хост-сервере. Этот контроллер домена также выступал в роли DNS-сервера и сервера глобального каталога. У меня также была отличная резервная копия.
так в чем была проблема? Что ж, я использую Microsoft System Center Data Protection Manager 2007 (DPM) для резервного копирования своей сети. Я не включил инструмент восстановления системы (SRT), который облегчает восстановление «с нуля», поскольку я выполнял резервное копирование виртуальных серверов. Хотя даже это не должно было быть проблемой.
Когда сервер, защищенный DPM, выходит из строя и его необходимо восстановить без использования SRT, существует довольно простой и понятный способ восстановления резервной копии. Вы просто сбрасываете учетную запись компьютера сервера в Active Directory, устанавливаете Windows (используя то же имя машины, что и раньше), присоединяете машину к Active Directory, развертываете агент DPM на сервере, а затем начинаете восстановление. Проблема в том, что Windows не позволяет сбросить учетную запись компьютера для контроллера домена.
Если бы я планировал более тщательно, даже это не имело бы большого значения. Как я уже сказал, у меня был еще один контроллер домена. Я мог бы просто удалить учетную запись компьютера, развернуть новую копию Windows, а затем сделать машину контроллером домена.
Проблема заключалась в том, что контроллер домена также действовал как сервер Exchange. Exchange Server предназначен для хранения почти всей информации о его конфигурации в Active Directory. Если сервер Exchange выходит из строя до такой степени, что его приходится перестраивать вручную, вам необходимо сбросить учетную запись компьютера, установить Windows, присоединить его к домену (используя то же имя компьютера), а затем запустить программу установки Exchange с помощью специальной командной строки. переключатель, который указывает программе установки перестроить сервер, используя информацию из Active Directory.
Итак, возникла дилемма… Я не мог восстановить свою резервную копию, потому что для этого мне пришлось бы сбрасывать учетную запись компьютера в Active Directory. Я не мог переустановить Exchange (и спасти свою конфигурацию), потому что для этого мне пришлось бы сбрасывать учетную запись компьютера. Я не мог просто удалить и воссоздать учетную запись компьютера, потому что это уничтожило бы мои данные конфигурации сервера Exchange и не позволило бы мне восстановить мою резервную копию.
Как видите, я оказался в безвыходной ситуации, которой можно было бы легко избежать, если бы я более тщательно спланировал размещение своих виртуальных контроллеров домена. В конце концов, я смог решить проблему, но мое решение не было красивым. Прежде чем я расскажу вам, что я сделал, я должен сказать вам, что мое исправление не поддерживается Microsoft. На самом деле, они специально не одобряют мое решение, но у меня не было другого выбора, кроме как стать мошенником.
Мой Exchange Server не был настроен как сервер почтовых ящиков, поэтому мне не нужно было беспокоиться о потере каких-либо данных. В этом случае я отключил все свои серверы Exchange, а затем использовал ADSIEdit (находится в инструментах поддержки Windows), чтобы вручную удалить любые ссылки на сервер Exchange из Active Directory (у меня были резервные копии других моих контроллеров домена на случай что-то пошло не так). После этого я использовал консоль «Пользователи и компьютеры Active Directory», чтобы удалить учетную запись компьютера.
Предоставив оставшимся контроллерам домена достаточно времени для репликации, я создал новый виртуальный сервер с тем же именем, что и мой отказавший сервер, и присоединил его к Active Directory. После этого я установил Exchange на новую виртуальную машину и применил все исправления, которые ранее использовались на моем вышедшем из строя сервере. Как только новый сервер Exchange был установлен, я использовал свою сетевую документацию, чтобы вручную перенастроить его таким же образом, как и отказавший сервер. Наконец, я создал дополнительный виртуальный сервер и настроил его в качестве контроллера домена. Таким образом, Exchange больше не будет работать на контроллере домена.
Вывод
Я рад сообщить, что мой ремонт сработал так, как я надеялся, и моя сеть теперь работает так же хорошо, как и до удара молнии. Несмотря на то, что у этой истории счастливый конец, в ней также есть мораль (которую я усвоил на собственном горьком опыте). Мораль этой истории в том, что вы никогда не должны запускать приложения на своих контроллерах домена. Запуск приложений на контроллерах домена может иметь совершенно неожиданные последствия, если вам когда-нибудь придется восстанавливать сервер после сбоя. Поэтому, когда вы планируете размещение контроллера домена в своем виртуальном центре обработки данных, я настоятельно рекомендую убедиться, что ваши хост-серверы имеют достаточно ресурсов, чтобы выделить целую виртуальную машину для каждого контроллера домена.
В части 7 я хочу вернуться к своему первоначальному плану и завершить серию рассказом о размещении виртуального контроллера домена в более сложных сетях.