С тех пор, как кластеризация впервые появилась в Windows NT 4.0 Enterprise Edition, пользователи жаловались, что ее сложно создавать и еще сложнее обслуживать. Администрирование кластера требовало от администратора не только понимания самой кластеризации – администратору также было необходимо отлично знать технологии хранения и то, как служба кластера будет взаимодействовать с различными решениями хранения. Чтобы довести высокодоступное решение до рабочего состояния и затем его обслуживать, требовался исчерпывающий набор умений, который непросто было найти во многих организациях.
С течением лет кластеризация улучшилась, но всё же она во многом оставляла желать лучшего, когда корпорация Майкрософт начала работу над Windows Server® 2008. Учитывая все это, группа разработчиков взялась за переработку кластеризации, в первую очередь имея целью простоту. В Windows Server 2008 службы кластеризации Майкрософт (Microsoft® Cluster Services – MSCS) подверглись полному обновлению и теперь носят название отказоустойчивой кластеризации.
Это не значит, что простота является единственным, что предоставляет новая отказоустойчивая реализация кластеризации. За прошедшие годы корпорация Майкрософт усвоила много уроков по мере того, как организации предоставляли ценные отзывы о том, что они хотели бы видеть в прослушиваемом решении кластеризации. Новая функциональность безопасной кластеризации решает многие из основных проблем, о которых сообщали пользователи, а также добавляет некоторые интересные новые функции, делающие ее весьма привлекательной. Так что в этой статье я хотел бы представить некоторые из замечательных новых функций, которые можно обнаружить в отказоустойчивой кластеризации Windows Server 2008.
Новый интерфейс управления
После установки отказоустойчивой кластеризации доступ к интерфейсу управления отказоустойчивыми кластерами можно получить через боковое приложение «Администрирование» или путем запуска Cluadmin.msc. Оснастка управления отказоустойчивыми кластерами, подобно другим интерфейсам управления в Windows Server 2008, является консолью управления Майкрософт (MMC) версии 3.0. Для ветеранов кластеризации открытие оснастки управления отказоустойчивыми кластерами в первый раз может показаться подобным неожиданному переносу в чужую страну без карты под рукой.
Новый интерфейс разделен на три отдельные области, как показано на рис. 1. В левой области перечислены все отказоустойчивые кластеры Windows Server 2008 в организации. Центральная область предоставляет сведения о части состава кластера, выбранной в левой области, когда как в правой области показаны действия, которые можно выполнить.
Рис 1. Оснастка управления отказоустойчивыми кластерами
Скажем, для примера, в левой области выбрано «Хранилище». В центральной области после этого появятся сведения о хранилищах, предоставленных в кластере, и о том, какие из них доступны в настоящий момент. Как можно увидеть на рис. 1, кластер содержит часть хранилища, поддерживающую диск-свидетель, хранилище, предоставленное для сервера файлов, и некоторый объем свободного места. В правой области перечислены связанные с хранилищем действия, такие как добавление к нему места. Обратите внимание, что оснастка управления отказоустойчивыми кластерами не может быть использована для администрирования предыдущих версий служб кластеризации Майкрософт.
Улучшенные процессы настройки
Настройка отказоустойчивого кластера довольно проста. Для многих действий по настройке, перенастройке и обслуживанию кластера имеются мастера. Благодаря этим мастерам администратору больше не нужно думать о том, какие ресурсы настроены верно, или о том, в верном порядке ли они подключатся.
На рис. 2 показан мастер высокой доступности. В данном конкретном примере был настроен файловый сервер. Слева можно увидеть список этапов, через которые мастер провел администратора. По завершении процесса отображается страница сводки, на которой можно просмотреть отчет.
Рис 2. Мастер высокой доступности
Встроенная процедура проверки
В предыдущих версиях Windows Server поддерживаемыми решениями кластеров считались лишь комплекты оборудования, занесенные как решения кластеров в каталог Windows Server. Это касалось и кластеров с узлами в нескольких филиалах, которые перечислялись отдельно в категории географически распределенных. Чтобы попасть в каталог, производители оборудования должны были провести набор тестов лабораторий Windows Hardware Quality Lab (WHQL) и предоставить результаты в корпорацию Майкрософт. Это требовало затрат от производителя и базу данных каталога Windows Server было сложно поддерживать на уровне.
В Windows Server 2008 в состав отказоустойчивой кластеризации входит встроенный процесс проверки. Этот процесс состоит из ряда тестов, сгруппированных в четыре основных категории, как показано на рис. 3.
Рис 3. Категории проверочных тестов отказоустойчивых кластеров
Можно заметить, что категория «Сеть» развернута, чтобы показать выполняемые тесты; каждая категория содержит ряд тестов. В категорию «Хранилище», являющуюся, вероятно, наиболее важной из четырех, входят тесты, обеспечивающие соответствие решений хранилищ новым требованиям отказоустойчивых кластеров Windows Server 2008.
Говоря конкретнее, поставщики оборудования теперь должны использовать драйверы, основанные на драйвере Microsoft Storport, а также поддерживать постоянное резервирование SCSI-3. Вдобавок, программные модули с несколькими путями, зависящие от устройств, при использовании должны быть основаны на стандарте ввода/вывода Microsoft Multi-Path Input\Output.
В результате появления процесса проверки изменилась модель поддержки. Все оборудование должно теперь иметь логотип Windows Server 2008, и все проверочные тесты должны быть успешными. Единственным исключением являются кластеры с узлами в нескольких филиалах, имеющие два отдельных и различных пространства хранилищ, по одному в каждом филиале, и реализация непрерывной репликации кластера в Exchange Server 2007, которая не использует общих хранилищ.
Новая модель кворума
В отказоустойчивой кластеризации Windows Server 2008 изменилась и модель кворума. В более старых системах при слове «кворум» администратор думал об общем диске, где находились настройка кластера и некоторые реплицированные файлы. Он был слабым звеном для всего кластера. В случае сбоя диска кворума служба кластера прекращала работу, и высокая доступность терялась.
Кластеры серверов Windows Server 2003 предлагали второй тип кворума, именуемый кворумом набора узлов большинства. Этот тип кворума обычно применялся на кластерах с несколькими узлами и не требовал общих хранилищ. Кворум набора узлов большинства состоял из общего файлового ресурса, находящегося на системном диске каждого узла кластера. Подключения к этому типу кворума проводились по протоколу SMB (Server Message Block). Опять же, для функционирования кластера требовалось участие большинства узлов.
Затем с появлением непрерывной репликации кластера (cluster continuous replication – CCR) в Exchange Server 2007 к кластерам серверов Windows Server 2003 была добавлена возможность файлового ресурса-свидетеля (File Share Witness – FSW). Это позволяло единственному узлу кластера CCR Exchange 2007 (или любому кластеру с несколькими узлами) продолжать предоставлять услуги, пока подключение к FSW позволяло достигнуть большинства.
В безопасной кластеризации Windows Server 2008 концепция кворума теперь действительно означает консенсус. Кворум (или консенсус) теперь достигается путем наличия достаточного числа голосов для ввода кластера в эксплуатацию. В зависимости от состава кластера, достаточное число голосов может быть достигнуто различными путями. В отказоустойчивой кластеризации Windows Server 2008 доступны четыре режима кворума, они показаны на рис. 4. Из четырех перечисленных режимов только первые два (большинства узлов и большинства узлов и дисков) могут быть автоматически выбраны в ходе процесса создания кластера. Следует использовать следующую логику:
- Если в кластере настраивается нечетное число узлов, выберите режим большинства узлов.
- Если в кластере настраивается четное число узлов, а общее хранилище подключено и доступно, выберите режим большинства узлов и дисков.
Рис 4. Режимы кворума в мастере настройки кворума кластера
Чтобы выбрать диск-свидетель из доступного хранилища, выберите первый диск размером не менее 500 мегабайт, на котором есть раздел NTFS. Оставшиеся режимы кворума можно установить вручную, запустив мастер настройки кворума кластера. Режим большинства узлов и общих файловых ресурсов обычно используется в составах кластеров с узлами в нескольких филиалах или в кластере CCR Exchange 2007. Последний режим – отсутствие большинства и использование только диска – эквивалентен модели общего кворума в старых кластерах. Он представляет из себя слабое звено, и обычно его не следует использовать.
Существуют лишь два типа ресурсов-свидетелей (физический диск и общий файловый ресурс), которые можно настроить в кластере для помощи в достижении консенсуса.
Диск-свидетель – это часть хранилища, которую служба кластера может вывести в оперативный режим. Этот диск расположен в группе основных ресурсов кластера вместе с сетевым именем кластера и связанными ресурсами IP-адреса. Когда диск-свидетель настроен, на диск помещается папка кластера и полная копия настройки кластера (куст кластера или копия).
FSW – это общий сетевой ресурс, который, в идеале, расположен на сервере в сети, не являющейся частью кластера. К FSW производится подключение по протоколу SMB, и FSW поддерживает копию файла журнала свидетеля, содержащую информацию о версиях настройки кластера.
В кластере может быть настроен лишь один ресурс-свидетель. Этот ресурс предоставляет дополнительный голос, если таковой понадобится ресурсу для достижения кворума. Другими словами, если кластеру не хватает одного голоса (и, следовательно, одного узла) для достижения консенсуса, то для достижения кворума подключается ресурс-свидетель. Если для достижения кворума кластеру не хватает более чем одного голоса, ресурс-свидетель оставляется в покое, а кластер остается в неактивном состоянии, ожидая присоединения еще одного узла кластера.
Улучшенные возможности безопасности
В отказоустойчивых кластерах появилось несколько новых усовершенствовании безопасности. Вероятно, наиболее значительное из них связано с устранением требования наличия учетной записи службы кластеров (Cluster Service Account – CSA). В предыдущих версиях службы кластеров Майкрософт в ходе процесса настройки требовалась учетная запись пользователя домена. Эта учетная запись, которая использовалась для запуска службы кластеров, добавлялась к группе локальных администраторов на каждом узле кластера и давала учетные права локального пользователя, чтобы обеспечить верное функционирование службы кластера. В качестве учетной записи пользователя домена CSA подпадал под ряд политик уровня домена, которые могли быть применены к узлам кластера. Эти политики могли отрицательно повлиять на высокую доступность, вызывая сбой службы кластера.
Теперь служба кластера работает, используя учетную запись локальной системы с определенным набором прав на локальном узле кластера, которые позволяют ей правильно функционировать. Контекст безопасности для кластера перенесен на объект имени кластера (Cluster Name Object – CNO), являющийся объектом компьютера, создаваемым по умолчанию в контейнере «Компьютеры» Active Directory® в момент создания кластера. После того, как кластер успешно создан, и CNO существует в Active Directory, учетная запись пользователя, использовавшаяся для установки и настройки кластера, более не нужна.
Дополнительные объекты компьютера, создаваемые в контейнере «Компьютеры» Active Directory, связаны с отказоустойчивым кластером. Эти объекты, именуемые объектами виртуальных компьютеров (Virtual Computer Object – VCO), приравниваются к ресурсам сетевого имени кластера, создаваемыми как часть точек доступа клиента (Client Access Points – CAP) в кластере. CNO, ответственный за создание всех VCO в кластере, добавляется к системному списку управления доступом (System Access Control List – SACL) объекта в Active Directory (см. рис. 5).
Рис 5. Безопасность на объекте виртуального компьютера (VCO) в Active Directory
CNO также берет на себя ответственность за синхронизацию паролей домена со всеми созданными им объектами VCO. Этот процесс выполняется в соответствии с настроенной для домена политикой ротации паролей. Вдобавок, поскольку объект CNO ответственен за создание всех компьютерных объектов в кластере, связанных с объектами VCO, объект CNO (учетная запись компьютера) должен иметь права уровня домена для создания объектов компьютера в контейнере, где создаются объекты VCO (по умолчанию, это контейнер «Компьютеры»).
Другое изменение состоит в том, что Kerberos теперь используется как метод проверки подлинности по умолчанию. Эта улучшенная функция безопасности становится возможной благодаря наличию учетных записей компьютеров в Active Directory. Но кластер имеет возможность использовать проверку подлинности протокола NT LAN Manager (NTLM), если приложению, не способному использовать для проверки подлинности Kerberos, понадобится доступ к ресурсам кластера.
Также более безопасна связь между узлами кластера, напрямую имеющими дело с процессом кластера. По умолчанию, все сообщения внутри кластера подписываются. Через интерфейс общего языка (CLI) cluster.exe это свойство кластера может быть изменено так, чтобы для предоставления дополнительного уровня безопасности шифровались все сообщения между узлами.
Расширенные функции сети
Новые возможности работы с сетью в отказоустойчивых кластерах делают возможной большую гибкость при разработке решений высокой доступности и аварийного восстановления. В то же время, эти усовершенствования работы с сетью предоставляют более надежную связь между узлами кластера.
Вероятно, наиболее запрашиваемой клиентской функцией была возможность обнаруживать узлы кластера на разделенных сетях. Теперь это возможно. Драйвер сети кластеров полностью переписан, так что теперь он предоставляет весьма надежную и отказоустойчивую связь между различными узлами в кластере при условии, что каждый узел подключен минимум к двум отдельным и различно маршрутизируемым сетям.
Драйвер сети кластеров собирает собственную таблицу внутренней маршрутизации в зависимости от информации о подключении, предоставленной в процессе запуска кластера. В ее состав входят сведения о локальном подключении, а также информация, предоставляемая в базе данных настройки кластера (кусте реестра кластера).
Частью процесса проверки кластера является процесс обнаружения связи по сети. Возможность обнаруживать узлы кластера в различных маршрутизируемых сетях сделала менее жесткими требования к работе сети для кластеров с узлами в нескольких филиалах. Это упрощает и удешевляет развертывание их организациями. Это также позволяет использовать хранилища iSCSI, более привлекательное решение хранения для отказоустойчивых кластеров.
Узлы кластеров также могут получить информацию о IP-адресе через протокол DHCP. Это может снизить нагрузку на сетевых администраторов, если они способны принять использование динамической адресации для серверов в своей среде.
Настройка сетевых интерфейсов узла кластера определяет, какие сети будут использовать статические или динамические IP-адреса. Даже если ресурс IP-адреса в кластере получен от сервера DHCP, он может быть изменен на статический IP-адрес в оснастке управления отказоустойчивыми кластерами.
В прошлом вся связь в кластере использовала широковещательную и порой многоадресную передачу по протоколу пользовательских датаграмм (User Datagram Protocol – UDP). Поддержка многоадресности прекращена, и связь в кластере теперь использует одноадресную передачу UDP. (Порт 3343 остается общим портом, используемым кластерами Майкрософт.) Многих сетевых администраторов очень обрадует исчезновение широковещательной передачи. Но реальная отдача для кластера связана с новым процессом обмена сообщениями, внутренними для самой службы кластера. (Это, однако, выходит за рамки данной статьи.) Связь внутри кластера теперь имеет характеристики более надежной связи TCP, хотя и теперь в качестве механизма передачи используется UDP.
Повышенная надежность при взаимодействии с хранилищем
Способ взаимодействия отказоустойчивых кластеров с хранилищем радикально отличается от прежнего. Драйвер диска кластера (clusdisk.sys) был полностью переписан и теперь является настоящим драйвером Plug and Play (PnP), а способ его взаимодействия с хранилищем изменен.
В Windows Server 2003 драйвер диска кластера находился на прямом пути к хранилищу. Но в Windows Server 2008 драйвер диска кластера сообщается с драйвером диспетчера раздела (partmgr.sys), чтобы взаимодействовать с хранилищем. Эти два подхода проиллюстрированы на рис. 6.
Рис. 6. Как изменен стек хранилища в Windows Server 2008
Основной обязанностью диспетчера раздела является защита дисковых ресурсов кластера. Все диски на общей шине хранилища автоматически помещаются в автономное состояние при первой установке соответствия с узлом кластера. Это позволяет одновременно установить соответствие хранилища со всеми узлами в кластере, даже до создания самого кластера. Больше не нужно загружать узлы по одному, готовить диски на одном, отключать этот узел, загружать другой, проверять настройку диска и т.д.
Однако всё ещё существуют тесты хранилища, выполняемые как часть процесса проверки кластера и требующие инициализации дисков. Они могут быть проделаны на одном из узлов в кластере перед выполнением процесса проверки. После того, как хранилище добавлено к кластеру, в интерфейсе управления дисками диски будут показаны как зарезервированные и не останутся в незащищенном состоянии.
Другое изменение имеет отношение к командам SCSI. В Windows Server 2003 команды SCSI-2 «Зарезервировать\Освободить» использовались для драйвера диска кластера, записывающего на секторы самого диска. В Windows Server 2008 требуются команды постоянного резервирования SCSI-3. Узлы кластера должны зарегистрироваться, прежде чем им будет позволено резервировать свое хранилище; они также периодически защищают свои резервирования, используя протокол защиты регистрирования.
Один из тестов хранилищ из процесса проверки проверяет эту функцию. Если решение хранилищ не поддерживает команды постоянного резервирования SCSI-3, оно не поддерживается отказоустойчивыми кластерами.
Многие организации используют программы с несколькими путями для избыточности при подключении к хранилищу. Это поддерживается и даже поощряется как лучший вариант. Однако, программные решения с несколькими путями от сторонних производителей или модули конкретных устройств должны быть переписаны с использованием стандарта Microsoft Multi-Path Input\Output, чтобы поддерживаться отказоустойчивыми кластерами. Это гарантирует, что все команды постоянного резервирования SCSI-3 одновременно отправляются по всем путям в хранилище независимо от того, активен ли путь или нет. Эта функциональность также проверяется в рамках процесса проверки.
В число дополнительных улучшений хранилищ входят улучшенный процесс проверки диска (chkdsk.exe), встроенные функции восстановления дисков, ранее бывшие частью программы восстановления Cluster Server Recovery Utility, и самовосстанавливающиеся диски. В отказоустойчивых кластерах и подпись диска, и идентификатор LUN используются при определении ресурса диска кластера. Если что-то из них изменилось, настройка кластера обновляется. Это вызывает снижение числа ошибок просто потому, что изменение атрибута на ресурсе физического диска ведет к большему уровню высокой доступности.
Встроенные процессы аварийного восстановления
Ранее упомянутое восстановление диска, очевидно, является одной из встроенных возможностей аварийного восстановления. Еще одной из них является возможность восстановления Active Directory. Если объект компьютера, представляющий CNO, удален, создавать объекты компьютера, связанные с клиентскими точками доступа кластера, станет невозможно. Однако первой проблемой, с которой придется столкнуться, вероятно будет невозможность для высокодоступных приложений и ресурсов получить доступ к ресурсам за пределами кластера из-за невозможности получить маркер безопасности
Восстановление после удаления объекта CNO идет в две стадии. Сперва необходимо, чтобы администратор домена восстановил удаленный объект компьютера из контейнера DeletedObjects в Active Directory. Затем, после того, как объект был восстановлен и заново включен, выполняется процесс восстановления объекта Active Directory в оснастке управления отказоустойчивыми кластерами.
В кластерах серверов Windows Server 2003 имелась возможность того, что файл настройки кластера, расположенный в подкаталоге %systemroot%\cluster, будет поврежден, и его понадобится заменить. В отказоустойчивых кластерах может помочь возможность самовосстановления. Если служба кластера запускается на узле, а база данных настройки повреждена, будет загружен минимальный шаблон настройки с использованием информации, содержащейся в разделе реестра HKLM\System\CCS\Services\ClusSvc\Parameters. Узел попытается присоединиться к уже сформированному кластеру, и, если попытка успешна, свежая копия куста реестра кластера будет направлена на узел. Если узел не сможет присоединиться к кластеру, служба кластера будет завершена.
Новые функции резервного копирования и восстановления
Отказоустойчивая кластеризация имеет собственный модуль записи службы теневого копирования томов. Это играет ключевую роль в резервном копировании и восстановлении базы данных кластера и данных, находящихся на ресурсах физического диска. Резервное копирование настройки кластера довольно незамысловато. Пока состояние системы является частью резервной копии, настройку кластера можно восстановить. Но обратите внимание, что резервное копирование кластера возможно только при наличии кворума у кластера. Это гарантирует наличие резервной копии самой последней настройки кластера.
Существует два различных типа восстановлений кластера: полномочное и неполномочное. При неполномочном восстановлении используется программа архивации данных Windows Server или приложение резервного копирования от стороннего производителя для выполнения восстановления из выбранной резервной копии. Полномочное восстановление узла кластера, с другой стороны, может быть выполнено лишь с помощью интерфейса командной строки программы архивации данных Windows Server (wbadmin.exe).
Полномочное восстановление, по сути, «отматывает назад» настройку кластера до момента создания резервной копии. Для выполнения полномочного восстановления служба кластера останавливается на всех узлах, кроме узла, на котором исполняется восстановление. После того, как восстановление завершено и служба кластера запущена на восстановленном узле, восстановленная настройка кластера становится новой, определяющей настройкой кластера. Затем, когда служба кластера запущена вновь на оставшихся узлах в кластере, восстановленная настройка направляется им в ходе процесса присоединения.
В определенных случаях это может существенно сэкономить время и деньги. Предположим, что у нас имеется кластер печати, размещающий несколько ресурсов диспетчера очереди печати, каждый из которых поддерживает 1 500 принтеров, и один из этих ресурсов случайно удален. Теперь большое число пользователей не может выполнять печать. Вместо того, чтобы вручную добавлять все эти принтеры обратно к настройке кластера, гораздо быстрее будет выполнить полномочное восстановление настройки кластера. Это, конечно, зависит от наличия основательной стратегии резервного копирования и восстановления.
Переход с кластеров серверов Windows Server 2003
В силу всех изменений архитектуры в отказоустойчивой кластеризации Windows Server 2008, обновления поверх существующей системы Windows Server 2003 и поэтапные обновления не поддерживаются. При переходе с кластеров Windows Server 2000 на Windows Server 2003 многие организации систематически исключали узлы в кластере по одному, выполняли чистую установку операционной системы и затем добавляли узел обратно в кластер. Этот подход нельзя использовать для перехода на Windows Server 2008, поскольку узлы кластера Windows Server 2003 и Windows Server 2008 не могут быть частью одного кластера.
К счастью, для облегчения перехода добавлен процесс перехода на основе мастера. Все же переход на отказоустойчивый кластер Windows Server 2008 требует некоторого планирования. Вот три базовых варианта перехода:
- Использование тех же серверов и хранилища.
- Использование тех же серверов, но с новым хранилищем.
- Использование новых серверов и хранилища.
В любой из этих вариантов входит проверка того, что оборудование прошло проверку по программе использования логотипа Windows Server 2008 и что все тесты процесса проверки отказоустойчивого кластера завершились успешно. По выполнении этих действий может начаться процесс перехода.
Не все ресурсы в кластере серверов Windows Server 2003 могут быть перенесены. Могут быть перенесены сетевые имена, IP-адреса, физические диски, общие файловые ресурсы, распределенный общий файловый ресурс, DHCP и WINS. В ограниченной степени можно также перенести универсальные службы, универсальные приложения и универсальные ресурсы сценариев.
В то же время, такие приложения, как Microsoft Exchange и SQL Server®, имеют свои процедуры по переносу на отказоустойчивый кластер. Принтеры могут быть перенесены на Windows Server 2008 посредством использования оснастки управления печатью (которая устанавливается с ролью сервера печати) для экспорта и последующего импорта принтеров на свеженастроенный высокодоступный сервер печати. Типы ресурсов от сторонних производителей не могут быть перенесены.
В процессе перехода данные не переносятся. В этом процессе происходит перенос параметров настройки кластера с Windows Server 2003 на Windows Server 2008.
Все перенесенные ресурсы по завершении процесса переноса первоначально помещаются в автономное состояние. Это выполняется в силу возможной необходимости дополнительных действий. Следовательно, важно проверить отчет по итогам переноса, чтобы увидеть, какие дополнительные действия (помимо переноса данных при переходе на новое хранилище) могут потребоваться перед началом работы кластера. Например, при переносе сервера DHCP на всех узлах в кластере должна быть установлена роль сервера DHCP, а при переносе сервера WINS на всех узлах в кластере должен быть установлен компонент сервера WINS.
