Семь поставщиков предлагают решения для репликации, совместного использования памяти и построения отказоустойчивых систем
В Microsoft Cluster Server (MSCS, ранее Wolfpackу) впервые была реализована концепция серверных кластеров, обеспечивающих высокую отказоустойчивость приложений в среде Windows NT 4.0. С тех пор кластеры проделали большой путь. Сегодня многие поставщики предлагают зрелые продукты кластеризации, с помощью которых стало гораздо проще развернуть решение с высокой степенью отказоустойчивости. Какие же архитектуры и технологии используются в продуктах независимых поставщиков?
Архитектуры высокой отказоустойчивости
Общая черта серверных кластеров с высокой степенью отказоустойчивости — наличие нескольких серверов, каждый из которых связан со всеми остальными и работает как узел кластера. Если приложение дает сбой в результате выхода из строя одного узла, то задача выполнения программы возлагается на другой узел кластера, и конечные пользователи могут продолжить работу. Это возможно, если приложение корректно выполняется как на первичном узле (до отказа), так и на резервном узле (после отказа). Для функционирования каждого приложения необходимы соответствующие данные, и ключевое отличие различных архитектур высокой отказоустойчивости — метод, используемый для доступа первичного и резервного узлов к данным приложения.
В службе Microsoft Cluster и некоторых конкурентных продуктах применяется общее хранилище (shared storage). В такой конфигурации узлы кластера подключены к одним и тем же системам дисковой памяти, как правило SAN (Storage Area Network). Служба Microsoft Cluster поддерживает также двухузловые кластеры на базе SCSI, в которых оба узла подключены по одной шине SCSI. Как в конфигурациях на базе SAN, так и в SCSI каждый узел «видит» и может использовать тома, определенные в подключенном хранилище данных, так, как будто эти тома находятся на локально подключенном диске. Если первичный узел отказывает, то резервный берет на себя управление томом данных (и другими ресурсами, связанными с приложением, такими как IP-адреса, имена NetBIOS и имена общих ресурсов) и запускает приложение. Эти системы должны разрешать конфликтные ситуации между владельцами дисковых томов, чтобы в данный момент времени только один сервер мог записывать данные на том. Для успешной работы кластера с общим хранилищем данных необходимы безупречно совместимые друг с другом аппаратные компоненты. Microsoft сертифицирует определенные аппаратные конфигурации и публикует их в разделе кластеров каталога Windows Catalog (для Windows Server 2003) или в списке Hardware Compatibility List (HCL — для Windows 2000 Server). Ссылки на эти списки опубликованы по адресу http://www.microsoft.com/whdc/hcl/default.mspx. Для некоторых других кластерных продуктов, представленных в данном обзоре, также требуются сертифицированные Microsoft аппаратные устройства (но не всегда еще и сертифицированные кластерные конфигурации).
В конфигурациях с общими хранилищами данных проблем согласования и целостности данных не возникает, так как все узлы работают с одними и теми же данными. Однако стоимость систем с общими хранилищами, как правило, выше, чем систем с репликацией (которые будут рассмотрены ниже), а длина общей шины SAN или SCSI ограничена. Если не используется аппаратура SAN высокого класса с функциями зеркалирования по WAN, то все узлы должны находиться в одном сайте; поэтому вероятны сбои, которые затрагивают не только один узел кластера.
В решениях с высоким уровнем отказоустойчивости на базе репликации зеркалирование и репликация используются для копирования данных приложений через сеть в хранилища, управляемые другим сервером. Данные передаются по сети, поэтому транзакции занимают время и создают дополнительную нагрузку на сетевой канал связи; таким образом, могут возникать проблемы с согласованием и целостностью данных. Достоинства решений с репликацией — отсутствие обязательной сертификации аппаратных средств для работы в составе кластеров и возможность участия реплицированных узлов кластера в восстановлении после аварии.
Репликация, зеркалирование и синхронизация — различные способы копирования данных из источника в место назначения, но порой эти термины употребляются не совсем точно. Репликация всегда означает текущее копирование данных запроса на запись на резервный том. Термины «зеркалирование» и «синхронизация» часто относятся к единичной операции копирования данных из устройства-источника в целевое хранилище данных. Но иногда зеркалированием называют текущий процесс согласования данных в источнике и целевом хранилище в ходе обычной работы приложения. Ресинхронизация — процедура обновления зеркальной копии после прерывания связи между двумя серверами; например, в процессе обратной передачи функций резервного устройства основному после устранения аварии. Частичная ресинхронизация может потребоваться, если сервер, выполняющий приложение, отслеживает изменения блоков данных на томе — на зеркальный том необходимо пересылать только изменившиеся блоки. Частичная ресинхронизация производится гораздо быстрее и меньше загружает глобальные каналы связи WAN, чем полное зеркалирование тома.
Термины «синхронная репликация» и «асинхронная репликация» обозначают собственно процедуру записи данных на целевой том. При синхронной репликации драйверы ввода/вывода перехватывают запросы на запись, направленные к тому-источнику, и посылают копии запросов в целевую систему. Только получив подтверждение, что данные успешно записаны в хранилище на целевой системе, система-источник записывает информацию в собственное хранилище. Такой подход гарантирует, что целевая система всегда будет располагать полной и точной копией данных системы-источника. Процесс синхронной репликации может выполняться медленно, особенно если целевая система расположена на другом конце соединения WAN. Малая скорость ввода/вывода замедляет реакцию приложения, поэтому администраторам и программистам необходимо тщательно оценить эффективность синхронной репликации при определении стратегии высокой отказоустойчивости.
За повышенную скорость асинхронной репликации приходится платить неопределенностью состояния данных на целевом томе. При асинхронной репликации том-источник завершает запись немедленно, не дожидаясь сообщения об успешном выполнении процедуры записи на целевой системе. Команды записи посылаются на целевой том в соответствии с правилами, реализованными в механизме репликации. Многие механизмы репликации посылают данные и завершают запись на целевой том с максимальной скоростью, которую обеспечивают ресурсы сервера и пропускная способность сети. В других механизмах репликации можно ограничить полосу пропускания канала связи, выделяемую для трафика репликации, или составить расписание репликации. VERITAS Storage Foundation for Windows компании VERITAS Software обеспечивает «мягкую» (soft — по терминологии поставщика) синхронную репликацию, в рамках которой синхронная репликация применяется до тех пор, пока сетевой канал, используемый для репликации, не отказывает, а затем организует очередь запросов на запись, обеспечивая дальнейшую работу приложения.
Какие данные пересылаются на целевой том в процессе репликации? Дисковые тома делятся на блоки данных одинакового размера. Файловая система (например, NTFS или FAT) определяет способ использования блоков данных. В некоторых блоках хранятся данные файлов. В других содержатся метаданные — имена файлов, атрибуты безопасности, указания на местонахождение файловых блоков данных. В блоках третьего типа хранятся метаданные тома, в частности имя тома, сведения о свободных и занятых, испорченных и непригодных к использованию блоках. Некоторые механизмы репликации перехватывают запросы на запись к тому на блочном уровне. В блочных механизмах репликации не учитывается, какие данные хранятся на томе, и даже не принимаются во внимание особенности организации тома. Их цель — добиться поблочной идентичности исходного и целевого томов. Этот сравнительно простой метод репликации гарантирует, что все данные тома будут реплицированы на целевом томе. Однако приложение часто не использует все данные тома и их пересылка создает дополнительную нагрузку на канал связи.
От этого недостатка свободны файловые системы репликации, которые перехватывают запросы записи на уровне файловой системы, а не на уровне блоков тома. Механизмы репликации, работающие на этом уровне, распознают измененные части файла и пересылают по сети только соответствующие фрагменты. Такие механизмы могут оценивать имена файлов, и администратор может составить списки файлов, подлежащих или исключенных из репликации, снижая нагрузку репликации на сетевые соединения.
Все продукты на базе репликации обеспечивают передачу функций отказавших узлов кластера узлам, расположенным на удаленном сайте. О проблемах, возникающих при таком подходе, и решениях, реализованных в продуктах с высокой степенью отказоустойчивости, рассказано во врезке «Проблемы удаленных кластеров».
Как уже отмечалось, решения с высокой отказоустойчивостью быстро перезапускают приложения после системных отказов. Другая категория решений — нечувствительных к сбоям (fault-tolerant) — обеспечивает продолжение работы приложений после отказа даже без моментального перерыва. В данном обзоре рассматриваются решения высокой отказоустойчивости от шести поставщиков и одно нечувствительное к сбоям решение.
Продукты с высоким уровнем отказоустойчивости
В таблице перечислены продукты с высоким уровнем отказоустойчивости и применяемые в них технологии. У решений высокой отказоустойчивости есть общие черты, но каждое из них уникально.
BrightStor High Availability компании Computer Associates (CA) обеспечивает переключение узлов с репликацией. В продукте реализованы репликация на базе файловой системы, быстрая репликация при переключении узлов и технология мониторинга процессов, заимствованная из пакета управления предприятием Unicenter компании CA.
Co-Standby-Server AAdvanced компании LEGATO Software поддерживает двухузловые конфигурации с общим хранилищем данных и репликацией данных и располагает функцией подготовки отчетов об отказоустойчивости приложений. LEGATO Automated Availability Manager (AAM) поддерживает до 100 узлов и располагает системой правил и триггеров для автоматической обработки различных ситуаций.
Marathon Endurance Virtual FTserver компании Marathon Technologies — единственное поистине отказоустойчивое решение из представленных в данном обзоре. Два сервера с одинаковой конфигурацией объединяются в одну отказоустойчивую систему. Endurance совместим почти со всеми стандартными приложениями для Windows.
В продукте Double-Take компании NSI Software используется файловый механизм репликации, с помощью которого можно сократить объем пересылаемых по сети данных по сравнению с аналогичными блочными механизмами репликации. Возможны режимы репликации «многие к одному», «один ко многим», по цепочке и с одинаковой серверной конфигурацией. GeoCluster компании NSI Software расширяет службу Microsoft Cluster, поддерживая в дополнение к встроенным в Microsoft Cluster режимам разделения данных конфигурации с репликацией данных. GeoCluster+ обеспечивает отказоустойчивость удаленных данных в любых хранилищах, в том числе узлах, отличных от узлов службы Microsoft Cluster.
PolyServe Matrix Server — продукт для кластеров с общим хранилищем данных и 16 узлами. От других продуктов его отличает файловая система PolyServe SAN File System, которая обеспечивает нескольким узлам кластера одновременный доступ для чтения/записи к одному экземпляру общих данных.
LifeKeeper for Windows 2000 компании SteelEye Technology поддерживает кластерные конфигурации как с общим диском, так и с репликацией данных. Главные достоинства SteelEye — простота в эксплуатации и совместимость с многочисленными приложениями, достигаемые благодаря процедурам конфигурирования на базе мастеров и механизму автоматизированной установки приложений, реализованному в пакетах восстановления конкретных приложений.
VERITAS Storage Foundation HA 4.1 for Windows поддерживает широкий диапазон конфигураций кластеров, от базовых вариантов с репликацией данных и общими хранилищами до систем, в состав которых входят высокоуровневые продукты управления хранилищами данных. Гибкие параметры безопасности обеспечивают детализированное делегирование административных полномочий.
Джон Грин (john@nereus.cc) — президент компании Nereus Computer Consulting
Проблемы удаленных кластеров
В ходе процедуры переключения серверов резервный сервер присваивает себе IP-адрес отказавшего первичного сервера. Маршрутизаторы подсети распознают адрес MAC сетевого адаптера, которому теперь принадлежит IP-адрес, и сетевые пакеты пересылаются на новый активный сервер. Однако процесс переключения усложняется, если новый сервер расположен в другой подсети.
Возможное решение — обновить DNS-серверы таким образом, чтобы имя узла, к которому подключаются пользователи, соответствовало адресу нового сервера. Данный подход применим, если все пользователи находятся в частной сети, а задержка при обновлении DNS минимальна. Но если пользователи подключены через Internet, то время ожидания нового адреса для имени узла может превысить несколько часов, а попытки уменьшить задержку путем сокращения временного промежутка Time to Live (TTL) для имени узла увеличивают трафик DNS-серверов.
Можно также использовать технологию виртуальных локальных сетей (Virtual LAN — VLAN) для направления запросов приложений к удаленному сайту. При таком подходе серверы удаленного сайта работают так, как будто они находятся в локальной подсети и используют ее IP-адреса.
Другие варианты зависят от возможностей конкретного маршрутизатора. BrightStor High Availability компании Computer Associates (CA) явно поддерживает два метода переключения IP-адресов серверов: Local Area Mobility (LAM) и Floating Subnet. В LAM используются функциональные особенности некоторых маршрутизаторов Cisco Systems, и данный метод применяется в основном в конфигурациях с маршрутизаторами. Floating Subnet также может работать с маршрутизаторами других компаний. В основе этого метода лежит возможность настройки маршрутизатора через Telnet при переключениях узлов; как правило, она реализуется путем обновления файлов конфигурации маршрутизатора с помощью сценариев.