Как вернуть к жизни кластер Exchange с помощью средств VMware
В центре по проблемам аварийного восстановления нашей компании недавно проводились учения по обеспечению бесперебойной деятельности. Исходные условия: в результате катастрофы мы потеряли целое здание (и все серверы) и должны восстановить нормальную работу компании в течение 72 часов. Учения, подготовка к которым длилась не один месяц, прошли успешно. При тестировании разработанного плана нам пришлось столкнуться со множеством проблем и преодолеть их. И надо сказать, что один из самых неприятных сюрпризов подстерегал нас, когда мы взялись за восстановление активно-пассивного кластера Exchange Server 2003 Service Pack 2 (SP2): под руками не оказалось кластерного оборудования. Оперативно оценив обстановку, мы решили эту проблему путем формирования кластера в виртуализированной среде. В итоге данные Exchange были восстановлены.
Неудачные попытки
Поскольку в нашей организации я выполнял обязанности администратора Windows и Exchange, мне приходилось документировать процесс восстановления для каждого сервера. Я много раз восстанавливал автономные серверы Exchange с помощью команды Setup и переключателя /disasterrecovery; опыт подсказывал, что на восстановление нашего кластера Exchange должно уйти совсем немного времени. Как же я ошибался!
За пару недель до начала учений я решил на всякий случай еще раз пролистать документацию. Я восстановил в тестовой сети службу Active Directory (AD) и перешел к установке Exchange с помощью переключателя /disasterrecovery. Представьте мое удивление, когда уже через несколько секунд после запуска программа Setup выдала сообщение Operation Successful! Не было сомнений, что произошел какой-то сбой. Я быстро просмотрел регистрационный файл установки и увидел сообщение, показанное на экране. 1. Сразу стало ясно, что в моем плане зияет огромная брешь. Восстановить хранилище Exchange с кластера на автономном сервере было просто невозможно.
Сначала я хотел создать кластер из одного узла. Ведь если бы у меня был второй контроллер SCSI, я смог бы «убедить» службу Cluster в том, что использую разделяемый диск. К сожалению, в комплект каждого сервера в нашем центре аварийного восстановления входила только одна плата SCSI. И как я ни старался, служба Cluster так и не сумела ничего создать, кроме локального кворума. В отчаянии я попытался установить Exchange с использованием локального кворума. Но судьбе было угодно, чтобы и эта попытка не увенчалась успехом: в системе Windows Server 2003 SP1 существует известная проблема с кластерным ресурсом Microsoft Distributed Transaction Coordinator (MS DTC). Более подробную информацию об этом можно найти в статье «FIX: The MSDTC service does not start in a stand-alone cluster after you install Windows Server 2003 with SP1», опубликованной по адресу http://support.microsoft.com/?kbid=900426.
Я оказался в тупике. Необходимым оборудованием мы не располагали, а установка системы Exchange на кластере с локальным кворумом была сопряжена с трудностями, на преодоление которых у меня просто не было времени.
Вся надежда на VMware
Требовалось найти решение, причем очень быстро. До начала учений оставалось несколько дней, а о том, чтобы оставить нашу центральную коммуникационную систему в неисправном состоянии, не могло быть и речи. Я должен был изыскать способ восстановить Exchange.
Первое, что пришло мне в голову, — установить и запустить кластер Exchange в виртуальной машине (VM) с помощью средств VMware. Вероятно, аналогичное решение можно было создать, используя Microsoft Virtual Server вместо VMware. В феврале 2006 г. Компания VMware присвоила своему продукту GSX Server новый брэнд VMware и предоставила его пользователям для бесплатной загрузки по адресу http://www.vmware.com/products/server. В прошлом мне доводилось создавать кластеры Microsoft с помощью VMware. Если я сталкивался с проблемами, то знал, куда обратиться за помощью, — на форум, в работе которого я активно участвовал (это читательский форум Марка Минаси по адресу http://www.minasi.com/forum).
Средства VMware я использую для тестирования почти ежедневно и поэтому держу наготове копии всех используемых ныне версий Windows, обработанных с помощью программы Sysprep. Windows-утилита Sysprep извлекает уникальный идентификатор SID, назначаемый каждой системе Windows при ее создании. Когда систему копируют и затем запускают вновь, в ходе мини-операции установки генерируется новый SID. Только таким образом Microsoft обеспечивает копирование или «клонирование» Windows-систем, и данный метод работает великолепно. Поскольку эти копии операционных систем у меня всегда под рукой, мне не приходится устанавливать операционную систему на виртуальную машину «с чистого листа», что позволяет существенно экономить рабочее время. Я просто копирую машину в новую папку и запускаю ее. Операционная система быстро выполняет программу установки, запрашивая такие данные, как имя пользователя, имя сервера, IP-адрес и лицензионный ключ.
Скопировав Windows Server 2003, Enterprise Edition в новую папку, я начал настраивать сервер таким образом, чтобы он поддерживал кластер Microsoft. Здесь самое важное — проследить за тем, как создаются жесткие диски. Восстановительный сервер должен иметь ту же конфигурацию, что и производственный. К примеру, наши двоичные файлы Exchange (D:Program FilesExchsrvr) установлены на диске D, а не на C. Information Store (IS) и журналы транзакций тоже размещаются на разных накопителях. Такие сведения о конфигурации хранятся в AD, так что, если упустить важную деталь вроде тех, о которых шла речь выше, процесс установки закончится неудачей.
Чтобы убедить службу Cluster в том, что сервер работает с разделяемыми накопителями, мне пришлось настраивать накопители кластера для использования второго контроллера SCSI (по умолчанию VMware Server комплектуется четырьмя контроллерами SCSI). Для этого при создании виртуального накопителя я выбрал в окне мастера Add Hardware Wizard настройки Advanced. И хотя накопитель с разделами C и D сконфигурирован для SCSI ID 0:0, диски для кворума, журналов регистрации, а также для IS должны быть сконфигурированы для SCSI ID 1:0, 1:1 и 1:2 соответственно, как показано на экране 2. Если пропустить этот важный этап, мастер Custer Setup Wizard выберет локальный кворум.
Далее я запустил новый сервер, зарегистрировался на нем и отформатировал жесткие диски, уделяя особое внимание емкости накопителей и их буквенным обозначениям. Важно, чтобы буквенные обозначения в точности соответствовали обозначениям, применяемым на производственных серверах Exchange, иначе установка Exchange в кластере закончится неудачей. По завершении установки сервера я с помощью VMware сделал его моментальный снимок — на случай, если мне придется выполнять всю операцию сначала. Моментальный снимок VMware фиксирует состояние всех дисков виртуальной машины, содержимое ее памяти и настройки VM.
Теперь, когда я получил в свое распоряжение необходимые (виртуальные) аппаратные средства, пришло время настроить кластер под сервер Exchange. Процедура установки кластера в системе Windows 2003 стала гораздо более удобной, нежели в системе Windows 2000. В версии Windows 2003 Enterprise уже не нужно устанавливать службу Cluster с помощью оснастки Add/Remove programs; эта служба уже установлена и готова к настройке. Я присвоил кластеру имя Standby и соответствующий IP-адрес. Эти IP-адреса не должны в точности повторять IP-адреса производственного сервера.
Для создания кворума мастер Cluster Configuration Wizard должен выбрать накопитель Q. Если вместо одного из накопителей SCSI он выберет локальный кворум, значит, где-то допущена ошибка. Необходимо проверить настройки SCSI жестких дисков, внести необходимые изменения и повторить попытку. Кроме того, мастер предупредит вас о том, что отсутствует вторая плата сетевого адаптера, как показано на экране 3. Эту ошибку можно проигнорировать, поскольку у нас не будет необходимости устанавливать синхронизирующее соединение со вторым сервером.
Если бы я создавал кластер в производственной сети, теперь было бы самое время добавить второй узел и попытаться перемещать ресурсы с одного сервера на другой для обеспечения корректной работы кластера. Но я готовился к учениям по восстановлению после аварийного сбоя. Мне нужно было лишь убедиться в том, что я могу воссоздать исходную среду и восстановить данные. Создавать второй узел не было необходимости.
Установка Exchange в виртуальном кластере
Я был уже почти готов к тому, чтобы приступать к установке Exchange, но прежде мне нужно было развернуть несколько компонентов — ASP.NET, Microsoft IIS 6.0, Network News Transfer Protocol (NNTP), SMTP и MS DTC-кластерный ресурс MS DTC.
Если вам доводилось устанавливать Microsoft SQL Server в кластерной конфигурации, вы знаете, что MS DTC — это важный компонент, предполагающий установление отдельных зависимых соединений. Эти зависимые соединения показаны на экране 4 в том виде, в каком они перечислены среди свойств кластерных ресурсов MS DTC. Но в Exchange мы можем работать, используя в качестве зависимых соединений MS DTC IP-адрес кластера, имя кластера и диск кворума. В размещенном по адресу http://msexchangeteam.com/archive/2005/01/17/354497.aspx. блоге занимающихся разработкой Exchange сотрудников Microsoft читатели могут познакомиться с подробным обсуждением проблем, связанных с ресурсом MS DTC и Exchange.
Итак, я был готов к установке Exchange. В ходе первой попытки установки я воспользовался маршрутом C:Program FilesExchsrvr, который программа установки предложила мне по умолчанию; при этом я совершенно упустил из виду то обстоятельство, что ранее мы установили файлы Exchange на накопителе D производственного сервера. К сожалению, осознание того, что я совершил эту ошибку, пришло лишь тогда, когда я попытался в Cluster Administrator Tool создать ресурс System Attendant Cluster Resource (о чем я расскажу чуть позже), как показано на экране 5. Данный пример демонстрирует, почему целесообразно сделать моментальный снимок в процессе установки. Так вы сэкономите массу времени, ибо вам не придется в случае совершения ошибки начинать все с самого начала. Когда я устанавливал Exchange во второй раз, то уже не забыл установить его в нужный каталог на соответствующем диске. Совет: помните, что вы не обязаны запускать программу Forestprep или Domainprep. Если вы восстанавливали службу AD с резервной копии, этой службе уже известно все о вашей системе Exchange. Нужно только реанимировать сервер.
После установки Exchange я смоделировал производственный кластер Exchange: создал два кластерных ресурса — IP-адрес и имя сети. Это имя сети и IP-адрес — те же, что указаны в нашем профиле пользователя Outlook. Я мог бы задействовать и другой IP-адрес, но имя сети должно повторять имя сети, использованное в производственном кластере, поскольку оно приводится в AD. Я обнаружил, что, если задействовать другой IP-адрес, некоторые службы Exchange (такие, как SMTP или POP) либо не запускаются, либо перестают функционировать. Если вы столкнетесь с такой ситуацией, следуйте указаниям, приведенным в статье Microsoft «Events are logged after an IP address change on an Exchange cluster» (http://support.Microsoft.com/?kbid=315691).
Памятуя о том, как был настроен производственный кластер Exchange, я знал, что предстоит создать множество ресурсов Exchange. К счастью, эту работу берет на себя Exchange System Attendant. Чтобы обратиться к данному компоненту, в окне Cluster Administrator я выбрал пункты File, New и Resource, а затем в раскрывающемся списке щелкнул на элементе Exchange System Attendant. Далее я следовал всем указаниям мастера, не забывая выбирать IP-адрес, сетевое имя и физические диски так, чтобы они были указаны в числе зависимостей.
Применение сервисного пакета и восстановление
Теперь для того, чтобы иметь возможность восстановить данные, мне оставалось только применить пакет Exchange 2003 SP2. Перед тем как пытаться размонтировать базы данных, важно применить тот же пакет обновлений, что и на сервере Exchange, поскольку физическая структура страниц баз данных иногда различается от пакета к пакету. Если же вы попытаетесь восстановить базу данных Exchange с сервера Exchange 2003 SP2 на сервер, где пакет обновлений не установлен, ничего не получится.
Я загрузил Exchange 2003 SP2 и попытался запустить из него файл update.exe, но получил сообщение об ошибке, показанное на экране 6. Мне сразу же пришла в голову мысль о том, что придется создавать второй узел. Но потом я подумал: «А нельзя ли просто перевести кластер в автономный режим и применить пакет обновлений в этом режиме?» Я перевел узел в автономный режим и, разумеется, смог запустить файл update.exe и успешно применить SP2.
Завершив установку и запустив виртуальную машину, я открыл окно Cluster Administrator и модернизировал Exchange, щелкнув правой клавишей мыши на ресурсе Exchange и выбрав элемент Upgrade Exchange Virtual Server. Теперь я располагал точной копией нашего производственного кластера, которая выполнялась в виртуальной машине и была готова принять восстановленную информацию базы данных.
У этой истории счастливый конец. Наши учения по восстановлению данных после сбоя прошли без сучка и задоринки, и теперь руководство чувствует себя спокойнее, зная, что мы в состоянии восстановить центр обработки данных. Этот пример иллюстрирует лишь одну из многих ситуаций последних лет, когда технология виртуализации выручала меня. Если вам еще не доводилось работать с программными средствами виртуализации, рекомендую поэкспериментировать с ними — при решении задач тестирования программного обеспечения, консолидации серверов, продлении сроков эксплуатации старых операционных систем или при восстановлении данных после аварийного сбоя, как в нашей компании. Теперь, когда и Microsoft, и VMware бесплатно распространяют средства виртуализации, у нас появился отличный повод испытать возможности этой технологии.
Эрик Ракс (ebrux@mvps.org) – старший администратор сети Windows в крупной консалтинговой компании