Когда системному администратору руководство компании ставит задачу обеспечить работоспособность того или иного приложения или сервиса 24 часа в сутки 365 дней в году, он наверняка задумается о развертывании таких критически важных для бизнеса вещей в кластерных системах. По опыту общения с коллегами могу сказать, что идеи развертывания кластерных систем у ИT-специалистов весьма популярны. Многие знают, что это прекрасный способ обеспечить отказоустойчивость и масштабируемость приложений, но мало кто имеет практический опыт внедрения таких систем. Кластеры — отнюдь не панацея от всех бед, и приведенный в эпиграфе закон Мерфи справедлив и в отношении кластерных систем.
Цель данной статьи — показать, на что стоит обратить внимание при проектировании отказоустойчивых решений, и рассмотреть подводные камни, на которые может натолкнуться специалист, планирующий развертывание решения на базе кластеров Windows Server.
Материал данной статьи относится именно к отказоустойчивым решениям, поэтому мы будем обсуждать кластеры, созданные на основе технологии Microsoft Cluster Service (MSCS)— технологии кластеризации Microsoft, появившейся еще в Windows NT Server 4.0 (в редакции Enterprise). Стоит отметить, что в Windows Server 2008 название данной технологии изменилось, теперь она называется Failover Clustering.
MSCS — не единственная технология отказоустойчивости Microsoft. Наряду с ней в Windows Server представлены Network Load Balancing (NLB), Component Load Balancing и Windows Compute Cluster Server 2003. Поскольку данные технологии служат для реализации других задач — обеспечения балансировки нагрузки сетевых приложений и выполнения распределенных вычислений, мы не будем их касаться в этой статье. Термин «кластер» здесь и далее относится исключительно к решениям на основе MSCS.
Компоненты кластерной системы
Любая отказоустойчивая система на основе MSCS включает в себя минимум два сервера, которые в терминологии кластеров называются узлами (node), и доступное обоим узлам внешнее хранилище данных (рис. 1).
На узлах кластера должна функционировать операционная система Windows Server той редакции, в состав которой входит MSCS. Традиционно компания Microsoft включает MSCS в редакции, предназначенные для крупных предприятий, такие как Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows Server 2003/2008 Enterprise и Datacenter Edition.
Каждый узел кластера должен иметь по два сетевых интерфейса, один из которых включается в общую сеть и используется для обслуживания клиентских подключений, а с помощью вторых интерфейсов серверы соединяются между собой для организации частной сети кластера. Частная сеть кластера применяется для обмена служебными сообщениями MSCS (именуемыми сигналами синхронизации, heartbeat) и для определения доступности каждого из узлов кластера. Стоить отметить, что в случае неисправности частной сети служебные сообщения могут передаваться и по общей сети.
На внешнем хранилище располагается служебный ресурс кластера, именуемый кворумом, и данные развернутых на кластере приложений. Например, если на кластерной системе работает Microsoft SQL Server, то его базы данных должны располагаться на внешнем хранилище (см. врезку «Приложения с поддержкой кластеризации»).
Приведенная модель кластера называется кластером с общим кворумом. Как мы видим, внешнее хранилище, на котором располагается кворум кластера, должно также быть реализовано как отказоустойчивое решение (например, как отказоустойчивый массив RAID). В противном случае при недоступности кворума, например из-за неисправности внешнего хранилища, ваш кластер также перестанет функционировать.
Существуют и другие модели кластеров — кластер с локальным кворумом и кластер типа Majority Node Set (MNS). Кластер с локальным кворумом не является отказоустойчивым решением и может использоваться только как платформа для разработки и тестирования приложений.
Кластер MNS компания Microsoft рекомендует применять как часть решения, предоставляемого поставщиком вычислительной техники или программного обеспечения, и не внедрять самостоятельно.
В данной статье мы будем рассматривать решения, созданные на основе модели кластера с общим кворумом. Информацию по остальным моделям можно получить на сайте Microsoft по ссылке: http://technet2.microsoft.com/windowsserver/ru/library/c20dd042–5d52–49b2–889f-f163e0e112751049.mspx?mfr=true.
В Windows Server 2008 модели кластеров претерпели значительные изменения. Появилась возможность объединить MNS и локальный кворум в одном кластерном решении. В этом случае выход из строя общего кворума не приводит к выходу из строя кластера.
Для связи внешнего хранилища с серверами используются следующие технологии:
1. Параллельный SCSI.
Традиционное решение для кластерных систем. В этом случае внешнее хранилище подключается к серверам с помощью обычных кабелей SCSI и внешних разъемов параллельных интерфейсов SCSI. Диски общего хранилища располагаются на общей шине SCSI и доступны, таким образом, обоим узлам кластера. Диски серверов, на которых установлена операционная система, не могут находиться на одной шине SCSI с дисками внешнего хранилища.
Основные недостатки данного решения напрямую связаны с недостатками интерфейса SCSI: максимальная длина кабелей составляет 25 метров, что не позволяет располагать компоненты кластерной системы на значительном удалении друг от друга, и максимальная скорость передачи данных составляет 320 Мбайт/с (в случае применения SCSI-3 SPI-4, при этом максимальная длина кабелей составит только 12 метров).
2. Сети хранения данных Storage Area Network (SAN).
Сети хранения данных представляют собой объединение устройств хранения с помощью технологий, построенных по принципу сетевого обмена данными. В протоколах SAN используется коммутация пакетов и различные технологии маршрутизации данных (рис. 2).
В большинстве случаев для построения сетей применяется технология Fibre Channel (FC). Для подключений FC используются оптические кабели или медные кабели (между прочим, наименование Fiber было заменено Fibre, чтобы показать, что данная технология не привязана только к оптическим средам передачи данных) и специальные адаптеры, в терминологии Fibrе Channel именуемые Host Base Adapters (HBA).
Внешние хранилища могут быть подключены к серверам напрямую (топология точка-точка) или через специальные коммутаторы. Каждый интерфейс в SAN имеет уникальное имя (как MAC-адрес в Ethernet-сетях), именуемое WWN (World Wide Name), по которому происходит идентификация интерфейса в сети хранения данных.
Максимальная скорость передачи данных в случае использования Fibre Channel на сегодня достигает 4 Гбайт/с, а максимальная длина кабелей может достигать десятков километров. Сети хранения данных могут включать большое количество устройств хранения данных, например, SAN при использовании коммутаторов связной архитектуры (fabric switch) теоретически может содержать около 15 млн портов.
Так что на основе Fibre Channel можно строить географически распределенные кластерные системы, с большим количеством внешних хранилищ, и на сегодня данная технология является наиболее перспективной для построения кластерных систем.
Для построения SAN технология Fibre Channel не является единственной. Сеть SAN может быть построена с применением других технологий, например iSCSI. Тема построения SAN очень обширна и выходит далеко за рамки использования продуктов Microsoft и данной статьи. Всем, кто планирует внедрение кластерных систем с использованием SAN в качестве внешнего хранилища, рекомендую обратиться к книге Дайлипа Наика «Системы хранения данных в Windows» (пер. с англ. — М.: Издательский дом «Вильямс», 2005).
Для подключения внешнего хранилища к серверам могут применяться и другие технологии, обычно предлагаемые как альтернатива уже устаревшему параллельному SCSI, такие как Serial SCSI (SAS) и Serial Storage Architecture (SSA). Однако кластерные системы на их основе мало распространены и уступают SAN на основе Fibre Channel по масштабируемости и скорости передачи данных.
Windows NT Server 4.0 и Windows 2000 поддерживают подключение внешнего хранилища только с помощью параллельного интерфейса SCSI. Начиная с Windows Server 2003 для реализации кластерных систем полностью поддерживаются технологии SAN.
Разные версии Windows Server поддерживают разное количество узлов в кластере. Кроме того, количество узлов зависит от используемой технологии подключения внешнего хранилища данных. Зависимость количества узлов от версий Windows Server и технологий подключения показана в таблице.
Как работает кластер
Любое приложение в кластерной системе в отдельный момент времени функционирует только на одном узле кластера. В случае выхода из строя этого узла MSCS запускает приложение на другом узле (происходит переключение приложения с нерабочего узла кластера на рабочий). Если во время сбоя к приложению были подключены пользователи, то эта связь у них пропадет, а все несохраненные данные будут потеряны. Во время переключения приложение также будет недоступно пользователям, они смогут к нему подключиться только после возобновления работы приложения на другом узле кластера. Время переключения сильно зависит от типа приложения и может составлять от долей секунды до нескольких минут.
Вы можете настроить свой кластер так, чтобы все приложения выполнялись на одном узле, а другой узел в это время «спал». Такая схема работы называется Active/Passive. В то же время, если у вас имеется несколько приложений, их можно распределить по всем узлам кластера, и в случае сбоя приложение с вышедшего из строя узла будет запущено на оставшемся узле. Такая схема работы называется Active/Active. По схеме Active/Active также могут работать несколько экземпляров одного приложения, например, можно распределить по разным узлам различные экземпляры Microsoft SQL Server.
Однозначных рекомендаций по применению схем работы кластерных систем дать нельзя. Это зависит от количества узлов в кластере, типа используемых приложений и требований к отказоустойчивости и производительности. Для одних приложений, например Microsoft Exchange Server, применение схемы Active/Active хоть и возможно, но не рекомендуется (подробную информацию можно найти в статье http://technet.microsoft.com/ru-ru/library/aa996872 (EXCHG.80).aspx). Другие приложения могут успешно работать как при одной, так и при другой схеме работы кластера.
Правила построения
Итак, вы решили использовать кластерную систему для критически важного бизнес-приложения (например, корпоративной базы данных на основе Microsoft SQL Server), и теперь перед вами стоит задача правильно спроектировать и реализовать данное решение. О том, как это сделать, будет рассказано в следующей части статьи.
Андрей Мишечкин — системный администратор, г. Тольятти
Приложения с поддержкой кластеризации
Для того чтобы приложение могло нормально функционировать в кластерной среде, оно должно иметь специальный механизм взаимодействия с программными компонентами кластерной системы.
Microsoft Cluster Service включает в себя три компонента: саму службу кластера Cluster Service, монитор ресурсов (resource monitor) и библиотеки динамической компоновки ресурсов; для краткости будем называть их ресурсными библиотеками DLL (resource DLL).
Служба кластера — это базовый компонент, обеспечивающий функционирование кластера и работающий как служба Windows. Эта служба должна функционировать на каждом узле кластера.
Монитор ресурсов используется службой кластера для взаимодействия с ресурсами приложений, а точнее — с ресурсными DLL. Монитор ресурсов не инициирует никаких операций, а только передает запросы службы кластера в соответствующие ресурсные DLL, что позволяет изолировать службу кластеров от неработающих или неправильно работающих приложений. На одном узле может выполняться несколько мониторов ресурсов, таким образом, различные ресурсы могут быть изолированы друг от друга.
Ресурсные DLL применяются для управления непосредственно ресурсами кластера. Примеры ресурсов — диски, IP-адреса, сетевые имена, службы, исполняемые приложения (exe-файлы) и т. п. Для работы с каждым ресурсом используется соответствующая ресурсная DLL.
Приложения, для которых созданы специальные ресурсные DLL, взаимодействуют со службой кластера с помощью специальных интерфейсов API — Cluster API, чтобы получать всю необходимую информацию о состоянии кластера. Такие приложения называются приложениями с поддержкой кластеризации (cluster-aware applications). Они управляются службой кластера как один или несколько ресурсов кластера. Для ряда приложений, таких как серверы DHCP и WINS, компания Microsoft предоставляет ресурсные DLL в составе MSCS.
В некоторых приложениях (например, Microsoft SQL Server 2005) уже на этапе установки заложена возможность организации работы в кластере. При этом в процессе установки продукта производится создание всех необходимых ресурсов кластера и установка экземпляров приложения на все узлы кластера. Это избавляет администратора от необходимости установки приложения на каждый узел и создания его ресурсов вручную. Другие приложения с поддержкой кластеризации (например, Miсrosoft Exchange Server 2003) при установке добавляют свои ресурсные DLL в набор ресурсных DLL кластера, и кластеризация приложения выполняется после его установки на все узлы.
Приложения, для которых нет собственных ресурсных DLL, также могут быть развернуты в кластерной системе, с помощью универсальных ресурсных DLL Generic Applications или Generic Service. Правда, данные ресурсные DLL предоставляют только базовый набор взаимодействия службы кластеров с приложением, например: определение наличия процесса приложения, запуск или завершение процесса приложения, остановка или запуск службы, развернутой с помощью Generic Service, и т. п.
У приложения, развернутого в кластере, как правило, имеется информация, которая должна быть доступна всем узлам кластера. Такая информация должна располагаться на внешнем хранилище кластера. Для работы с ней создается ресурс типа «физический диск». Перед развертыванием приложения необходимо создать логический диск для приложения на внешнем хранилище и убедиться, что данный диск доступен всем узлам кластера. В противном случае вам не удастся развернуть приложение в кластерной системе. Детали реализации приложений с поддержкой кластеров хорошо описаны в статье Моэн Рао Кавейл «Введение в Microsoft Cluster Service (MSCS) семейства Windows Server 2003». На русском языке эта статья доступна на сайте разработчиков http://www.gotdotnet.ru по ссылке: http://www.gotdotnet.ru/LearnDotNet/NETFramework/30627.aspx.