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

Трудности с установкой и эксплуатацией

Насколько мне известно, самая главная претензия к технологии кластеризации с обработкой отказа состоит в том, что кластеры трудно формировать и использовать. Это представление восходит к тем временам систем с высокой доступностью, когда Windows Server 2008 еще не появился на рынке. В те дни процедура формирования кластеров внушала трепет; для решения этой проблемы нужно было вводить данные на многих страницах мастера и задавать бесчисленные настройки конфигурации. Для формирования кластера необходимо было привлекать эксперта, причем задачи выполнялись на всех узлах кластера. После создания кластера возникала еще одна проблема — обслуживание, и здесь опять-таки трудно было обойтись без помощи специалиста по кластерам. И все это было возможно лишь при том условии, что вы могли получить оборудование, обеспечивающее функционирование кластеров.

Проектировщики Server 2008 начали все с начала и разработали «с чистого листа» многие элементы пользовательского интерфейса, включая те, что применяются для управления кластерами и для их создания. Кроме того, Microsoft снизила уровень требований к аппаратному обеспечению, вследствие чего перспективы работы с кластерами открылись для более широкого круга потребителей. В системе Windows Server 2003 реализован целый ряд моделей кворума для применения в различных ситуациях, таких как файловый ресурс-свидетель File Share Witness, необходимый для кластеров, не имеющих единого хранилища. Этот ресурс первоначально использовался для непрерывной репликации кластеров Exchange Server. В системе Server 2008 все модели кворумов были объединены в единую модель, которая может выполняться в различных режимах, но при этом гораздо доступнее для понимания.

Процедура создания кластера в среде Server 2008 состоит из следующих этапов: запуск мастера создания кластеров, перечисление серверов, которые войдут в состав кластера, указание имени нового кластера и IP-адреса, если для сетевых интерфейсных плат не задан режим получения параметров по DHCP. Вот и все. Пользователю приходится иметь дело лишь с тремя диалоговыми окнами. Процедура создания кластера производит анализ серверов, включаемых в состав кластера, удостоверяется в доступности общего хранилища, формирует корректный режим для кворума на основе объема устройств хранения и числа узлов, а также настраивает все узлы — и все это за один этап. Необходимость посещения всех серверов для подготовки к работе кластера исключается. Кроме того, в процессе создания кластера предусмотрена фаза проверки аппаратных компонентов, а также их настроек. И если проверка дает положительный результат (что весьма вероятно в случае, когда узлы кластера оснащены процессорами с идентичной архитектурой, если на них выполняется одна и та же версия Windows и т. д.), это значит, что ваш кластер поддерживается корпорацией Microsoft; сверять аппаратные компоненты кластера со списком Microsoft Hardware Certification List (HCL) при этом не требуется.

Ничуть не сложнее и текущее управление кластером. Всякий раз при возникновении необходимости внести то или иное изменение вы можете полагаться на помощь мастеров. При возникновении проблемы часто бывает достаточно еще раз выполнить процедуру проверки; в результате вы получаете указания на то, где искать причины проблемы. Качество этих сведений стало еще выше с выходом в свет версии Server 2008 R2, которая к тому же обеспечивает полную поддержку управления кластерами с помощью средств PowerShell.

Failover Clustering и проблема простоев

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

Кластеризация с обработкой отказа представляет собой набор возможностей, которыми могут так или иначе воспользоваться службы и приложения. В самом общем виде эта технология «присматривает» за всеми узлами кластера. Если один из узлов выходит из строя, failover clustering уводит службы и зависимые ресурсы с отказавшего узла и распределяет их по остальным компонентам кластера, то есть по оставшимся работоспособным узлам. На данном базовом уровне функционирования технологии в момент отказа узла, где размещается служба или приложение, наблюдается определенное время простоя. Это неудивительно, ведь отказ прежде всего необходимо обнаружить. Затем ресурсы, связанные с узлом, такие как тома LUN, должны быть подключены на новом целевом узле, а служба или приложение должны быть запущены повторно. Все это не делается мгновенно, поэтому в течение какого-то времени служба остается недоступной. Так обычно обстоят дела со службой файлов или службой печати, которая функционирует как компонент кластера. То же можно сказать о таких службах, как Exchange Server 2007 и кластер с единым хранилищем Exchange 2003 Single Copy Cluster. Технология failover clustering перезапускает службу и возвращает ее в строй за минимально возможное время, обеспечивая тем самым высокую — но не стопроцентную — доступность.

Когда мы говорим об устойчивости к отказам, имеется в виду конфигурация, которая в случае отказа оборудования обеспечивает бесперебойное обслуживание конечных пользователей. Как правило, отказоустойчивые решения отличает гораздо более сложная архитектура, нежели архитектура типа failover clustering, поскольку в первом случае решения обеспечивают выполнение служб на нескольких узлах одновременно. Кроме того, им приходится поддерживать синхронизацию данных на различных узлах в режиме реального времени и управлять процессами выявления отказов, а также аварийного переключения, с тем чтобы сводить время простоев к минимуму, когда перерыв в работе практически незаметен. Решение кластеризации с обработкой отказа для входящей почты не в состоянии выполнять эти задачи для служб и приложений с помощью функций, реализованных только в Windows. Это объясняется теми различиями в реализации, которые необходимы с учетом различных режимов работы приложений.

Технология кластеризации с обработкой отказа предоставляет базовую инфраструктуру, на основе которой службы и приложения могут формировать отказоустойчивые решения, но это не значит, что приложения не могут быть отказоустойчивыми без использования технологии кластеризации с обработкой отказа. Многие службы являются отказоустойчивыми без использования кластеризации с обработкой отказа; это, к примеру Active Directory (AD) и фермы IIS, в которых реализованы механизмы балансировки сетевой нагрузки.

Хороший пример, иллюстрирующий сказанное, — группы доступности базы данных Database Availability Groups (DAG), представленные в Exchange 2010. В таких группах технология кластеризации с обработкой отказа применяется незаметно для пользователя с целью обеспечения определенных аспектов доступности ресурсов. Далее в дело вступает другая технология; она осуществляет репликацию данных из баз почтовых ящиков на несколько серверов и обеспечивает точки коммуникации клиентов в виде серверов клиентского доступа, которые предоставляют клиентам данные, полученные с серверов почтовых ящиков. Так что если в момент выхода из строя узла кластера вы наблюдаете короткие периоды простоя, скорее всего, о сбое речь не идет. Все так и задумано.

Формирование кластера из серверов, расположенных в разных местах, без использования сетевых решений

Службе, способной функционировать в кластерной конфигурации, обычно дается ряд ресурсов, включая IP-адрес. В одном месте может располагаться несколько узлов, подсоединенных к одному и тому же сетевому сегменту или, по меньшей мере, к нескольким сетевым сегментам, которые могут находиться в одной подсети IP. Это значит, что IP-адрес службы можно размещать на любом узле кластера, так как все они располагают одними и теми же средствами соединения с сетью. А теперь вообразите, что вам нужно построить кластер с разнесенными в пространстве узлами. Как правило, это значит, что вам придется иметь дело с различными сетевыми сегментами и подсетями IP. А это уже проблема: кластерный ресурс с IP-адресом 192.168.1.10 нельзя располагать в офисе, включенном в подсеть 192.168.10.0, — маршрутизация становится невозможной. Решение проблемы состоит в том, чтобы «растягивать» подсети на несколько офисов, а для этого обычно требуются дорогостоящие сетевые средства. Таким образом, применение технологии кластеризации в ситуации, когда организация размещается в нескольких офисах, оказывается доступным только для самых крупных компаний.

Разработчики Server 2008 внесли в систему кардинальное изменение, благодаря которому возможность формирования рассредоточенных кластеров оказалась доступна каждому, и суть этого изменения можно кратко выразить одним английским словом: or. До появления системы Server 2008 была возможность назначать несколько IP-адресов службе или приложению как части группы ресурсов, но при этом должны были присутствовать все IP-адреса, ибо все они должны функционировать на всех узлах кластера. Введение в системе Server 2008 операции or означает, что мы можем назначать службе или приложению несколько IP-адресов и указывать отношение «или». Команда or позволяет назначать несколько IP-адресов, обслуживающих различные и расположенные в нескольких местах подсети IP, в которых может выполняться данная служба. IP-адрес, соответствующий офису, где служба функционирует сегодня, используется для подключения клиентов; в нынешних условиях это означает, что появилась возможность формирования рассредоточенных кластеров без применения дорогостоящих сетевых решений.

Но из того, что мы можем назначать несколько IP-адресов, связанных отношением «или», не следует, что все проблемы, вытекающие из наличия в организации нескольких офисов, будут решены как по мановению волшебной палочки. Когда той или иной службе назначается один IP-адрес, клиенты всегда знают, по какому адресу с этой службой можно связаться. Если же службе назначено несколько адресов, проблема усложняется. Возможно, вам придется прибегнуть к помощи служб, таких как DNS, с очень короткими значениями интервала жизни записей имен хост-систем, Time to Live (TTL), так что клиенты не сохраняют в кэшах старые IP-адреса и не используют эту функцию для регистрации всех поставщиков IP, и все IP-адреса регистрируются в DNS. Но, скорее всего, вы воспользуетесь неким средним уровнем коммуникации для клиентов, таким как серверная роль клиентского доступа (здесь мы возвращаемся к примеру с системой Exchange 2010).

Высокая доступность на уровне виртуализации или приложения

Простой совет поможет вам сделать выбор между высокой доступностью на уровне виртуализации и на уровне приложения. Ныне тенденция состоит в том, чтобы виртуализовать все, что только возможно, и мощные средства виртуализации обеспечивают службы высокой доступности, функционирующие как в запланированных, так и в незапланированных ситуациях. Возьмем пример запланированной ситуации. Допустим, вы хотите установить модуль коррекции, для чего требуется перезагрузка на сервере Hyper-V. Вы можете задействовать функцию Live Migration системы Hyper-V, с тем чтобы скопировать память и состояние функционирующих виртуальных машин на другой сервер Hyper-V и обеспечить их бесперебойную работу.

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

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

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

Средства высокой доступности, реализованные на уровне виртуализации (слева) и внутри гостевой операционной системы (справа)

Если же вместо этого вы пользуетесь средствами обеспечения высокого уровня доступности системы Exchange, показанными в правой части рисунка, где применяется технология кластеризации с обработкой отказа в гостевых операционных системах, вы можете задействовать два экземпляра роли сервера почтовых ящиков Exchange (при работе с системой Exchange 2010 в кластере или в группе DAG можно включать до 16 экземпляров). Очень важно, чтобы каждый экземпляр располагался на отдельном сервере: размещая оба экземпляра на одной физической системе, вы не получите больших преимуществ. Добиться того, чтобы экземпляры не выполнялись на одной системе, можно с помощью правил anti-affinity rules.

В каждом экземпляре выполняются программные средства Exchange. Журналы поступают с активной копии базы данных на пассивную копию и воспроизводятся там, что обеспечивает синхронизацию баз данных. В случае отказа сервера, на котором размещена активная копия, гостевая операционная система определит, что сервер почтовых ящиков Exchange перестал отвечать на запросы, и возьмет на себя ответственность за ресурсы IP и имени сервера. Операционная система попытается снять копии со всех недостающих журналов транзакций, сверит их содержимое с содержимым центрального транспортного сервера, дабы удостовериться, что ни одно сообщение не было потеряно, и начнет оказывать услуги почтовых ящиков со своей копии базы данных. Этот метод обеспечивает намного более высокую производительность и целостность по сравнению с методом обеспечения высокого уровня доступности с помощью уровня виртуализации.

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

Джон Сэвилл (jsavill@windowsitpro.com) — директор по технической инфраструктуре компании Geniant, имеет сертификаты CISSP, Security and Messaging MCSE для Windows Server 2003 и звание MVP