Введение в Microsoft Cluster Service (MSCS) семейства Windows Server 2003

Введение в Microsoft Cluster Service (MSCS) семейства Windows Server 2003

В статье рассказывается о простом способе проверки работоспособности приложения в кластерной среде без внесения изменений в код приложения. Основное внимание уделяется Cluster Service - одной из трех серверных технологий, предлагаемых Microsoft и поддерживающих кластеризацию.

Аннотация

Содержание

Введение
Три технологии кластеризации
Применение Microsoft Cluster Service для восстановления после сбоя
Архитектура Cluster Service
Приложения без поддержки кластеров
High Availability Notepad
Заключение

Введение

Не всегда достаточно разработать качественное приложение с богатой функциональностью - все чаще требуется, чтобы приложение еще и удовлетворяло критерию высокой доступности (high availability). Не приходилось ли вам отказываться от вывода приложения на очередной уровень масштабирования из-за того, что кластерные технологии казались слишком сложными в освоении и применении? Microsoft^® Cluster Service - служба, введенная в Windows^® NT™ 4 и доступная в семействе Windows Server 2003, - предоставляет разработчикам простые средства развертывания приложений в кластерной среде. В частности, она позволяет указать, что приложение является общим для кластера (generic application), и управлять конфигурацией приложения через сценарии Windows.

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

В этой статье основное внимание уделяется Cluster Service, одной из трех серверных технологий кластеризации, предлагаемых Microsoft. Мы покажем, что в кластерной среде легко проверить работоспособность приложения, не внося никаких изменений в его код.

Три технологии кластеризации

В серверах Microsoft для используются три технологии кластеризации: NLB (Network Load Balancing), CLB (Component Load Balancing) и MSCS (Microsoft Cluster Service).

Network Load Balancing

Network Load Balancing действует как кластер клиентского интерфейса (front-end cluster) и распределяет входящий IP-трафик по серверам кластера. NLB идеально подходит для поддержки Web-сайтов электронной коммерции, где масштабирование и высокая доступность крайне важны. Можно объединить до 32 компьютеров под управлением операционной системы из семейства Windows Server 2003 и настроить их на работу под одним и тем же виртуальным IP-адресом. NLB обеспечивает масштабирование, распределяя клиентские запросы между несколькими серверами кластера. При увеличении трафика можно добавить в кластер дополнительные серверы; в каждый кластер может входить до 32 серверов. Кроме того, NLB обеспечивает высокую доступность: сбой сервера определяется автоматически, и клиентский трафик в течение 10 секунд перераспределяется между оставшимися серверами, не прерывая обслуживания пользователей.

Component Load Balancing

Component Load Balancing распределяет нагрузку между несколькими серверами, на которых выполняется бизнес-логика сайта. Эта технология обеспечивает динамическое балансирование компонентов COM+ в группе, в которую может входить до восьми идентичных серверов. В CLB компоненты COM+ размещаются на серверах отдельного кластера COM+. Вызовы, активизирующие компоненты COM+, сбалансированно распределяются между серверами кластера COM+. CLB дополняет NLB и Cluster Service, работая на промежуточном уровне многоуровневой сети с кластерами. CLB входит в состав Application Center 2000. CLB и Microsoft Cluster Service могут выполняться на одной и той же группе компьютеров.

Cluster Service

Cluster Service используется для создания кластера серверной части (back-end cluster); эта служба обеспечивает высокую доступность таких приложений, как базы данных, сервисы обмена сообщениями или доступа к файлам и принтерам. MSCS стремится свести к минимуму потери от сбоя системы, когда какой-либо узел выходит из строя или переходит в офлайновый режим.

Рис. 1. Три серверные технологии кластеризации, предлагаемые Microsoft

{
Рисунок:
Clients - Клиенты
Network Load Balancing (NLB) - Network Load Balancing (NLB)
IP-balancing - Балансирование IP-трафика
Component Load Balancing (CLB) - Component Load Balancing (CLB)
COM+ Balancing - Балансирование вызовов компонентов COM+
Cluster Service - Cluster Service
Failover protection - Восстановление после сбоя
Data - Данные
}

Применение Microsoft Cluster Service для восстановления после сбоя

В MSCS восстановление после сбоя возможно благодаря избыточности: в кластер объединяется несколько компьютеров, работоспособность каждого из которых не зависит от других. Для обеспечения избыточности необходимо установить приложение на нескольких серверах кластера. Однако в любой момент приложение находится в онлайновом режиме только на одном узле кластера. При сбое приложения или остановке этого сервера приложение перезапускается на другом узле. В Windows Server 2003 Datacenter Edition в кластер может входить до 8 узлов.

У каждого узла собственные память, системный диск, операционная система и подмножество ресурсов кластера. При сбое узла его ресурсы передаются во владение другому узлу - эта операция называется преодолением последствий после сбоя (failover), или восстановлением после сбоя. Затем Microsoft Cluster Service регистрирует сетевой адрес ресурса на новом узле, поэтому клиентский трафик направляется на доступную систему, в данный момент владеющую ресурсом. Когда ресурс, давший сбой, снова станет доступным в онлайновом режиме, можно настроить MSCS так, чтобы ресурсы и клиентские запросы перераспределились соответствующим образом, - эта операция называется возвратом к состоянию до сбоя (failback). Чтобы приложение могло возобновить работу с точки, в которой пришлось выполнить восстановление после сбоя, узлы должны иметь доступ к совместно используемому хранилищу, где содержится информация о состоянии приложения.

Заметьте: Microsoft Cluster Service предназначена для обеспечения высокой доступности (high availability), но не настоящей отказоустойчивости (fault tolerance). Термин "отказоустойчивость" обычно используется для описания технологии, обеспечивающей более высокий уровень устойчивости и восстановления. Отказоустойчивые серверы, как правило, отличаются высокой избыточностью оборудования и данных и используют специализированное программное обеспечение, что гарантирует почти мгновенное восстановление при любой одиночной программной или аппаратной ошибке. Эти решения стоят значительно дороже, чем кластерные, так как приходится платить за избыточное аппаратное обеспечение, простаивающее в ожидании ошибки, после которой потребуется восстановление. Microsoft Cluster Service позволяет создавать очень удачные решения с высокой доступностью на основе недорогого стандартного аппаратного обеспечения и в максимальной мере задействует имеющиеся вычислительные ресурсы.

Microsoft Cluster Service основана на модели кластеризации "ничего общего" (shared-nothing). В такой модели несколько узлов могут иметь доступ к устройству или ресурсу, но в любой момент только одна система владеет ресурсом и управляет им. (В MSCS-кластерах под ресурсом понимается любой физический или логический компонент, управляемый в кластере; этот компонент можно переводить в онлайновый или офлайновый режим, но единовременно он принадлежит только одному узлу, и его можно перемещать между узлами.)

Рис. 2. Microsoft Cluster Service {
Рисунок:
Client PCs - Клиентские компьютеры
Intranet - Интрасеть
Cluster Servers - Серверы кластера
Fibre-Channel Switches - Коммутаторы Fibre Channel
RAID disk sets - Дисковые RAID-массивы
}

Архитектура Cluster Service

Microsoft Cluster Service содержит три ключевых компонента: Cluster Service, Resource Monitor и Resource DLL. Кроме того, Cluster Administrator позволяет разрабатывать DLL расширений, используемых при управлении.

Cluster Service

Cluster Service - базовый компонент, выполняемый как высокоприоритетный системный сервис. Cluster Service управляет работой кластера и выполняет такие функции, как уведомление о событиях координации, взаимодействие между компонентами кластера, восстановление после сбоя и управление конфигурацией. На каждом узле кластера выполняется собственный компонент Cluster Service.

Resource Monitor

Resource Monitor - это интерфейс между Cluster Service и ресурсами кластера, выполняемый как независимый процесс. Cluster Service использует Resource Monitor для взаимодействия с ресурсными DLL. DLL осуществляют все взаимодействие с ресурсами, и выполнение DLL под управлением Resource Monitor изолирует Cluster Service от ресурсов, которые не работают или работают неправильно. На одном узле может выполняться несколько копий Resource Monitor, что позволяет изолировать ресурсы с непредсказуемым поведением от других ресурсов.

Когда Cluster Service нужно выполнить операцию над ресурсом, он отправляет запрос Resource Monitor, назначенному для этого ресурса. Если в процессе этого Resource Monitor нет DLL, работающей с таким типом ресурса, то в соответствии с регистрационной информацией загружается DLL, связанная с данным типом ресурса. Ресурсная DLL выполняет операцию над ресурсом в соответствии со специфическими требованиями этого ресурса.

Ресурсные DLL

Третий ключевой компонент Microsoft Cluster Service - ресурсные DLL. Resource Monitor и ресурсные DLL взаимодействуют с помощью Resource API, который представляет собой набор точек входа, функций обратного вызова и относящихся к ним структур и макросов, применяемых при управлении ресурсами.

Для Cluster Service ресурс - это любой физический или логический компонент, которым можно управлять. Примеры ресурсов - диски, сетевые имена, IP-адреса, базы данных, Web-сайты, прикладные программы и любые другие объекты, которые можно переключать в онлайновый или офлайновый режим. Ресурсы группируются по типам. Типами ресурсов являются аппаратное обеспечение (например диски) и логические элементы (например IP-адреса, общие файлы и обобщенные приложения).

Для работы с каждым ресурсом используется соответствующая ресурсная DLL - весьма пассивный уровень преобразования между Resource Monitor и ресурсом. Resource Monitor вызывает точки входа ресурсной DLL, чтобы определять состояние ресурса и переводить ресурс в офлайновый или онлайновый режим. Ресурсная DLL взаимодействует со своим ресурсом через любой IPC-механизм, подходящий для реализации этих методов.

Приложения, реализующие собственные ресурсные DLL для взаимодействия с Cluster Service и использующие Cluster API, чтобы запрашивать и обновлять информацию кластера, называются приложениями с поддержкой кластеров (cluster-aware applications). Приложениям и сервисам, не использующим Cluster или Resource API и функции управления кластером, ничего не известно о существовании кластера и Cluster Service. Этими приложениями обычно управляют как обобщенными приложениями или сервисами.

Приложения (как с поддержкой, так и без поддержки кластеров) выполняются на узле кластера и управляются как ресурсы кластера. Однако лишь приложения с поддержкой кластеров могут задействовать средства Cluster Service, вызывая Cluster API. При разработке приложений с поддержкой кластеров требуется создавать собственные типы ресурсов. Собственный тип ресурса позволяет разработчику добиться, чтобы приложение отвечало на различные события, происходящие в кластере, и при необходимости реагировало на них (например, если узел переходит в офлайновый режим, нужно закрыть соединение с базой данных).

Для большинства приложений, которые должны выполняться в кластере, желательно потратить время и силы на разработку собственного типа ресурса. Однако для начала можно проверить, как приложение работает в кластерной среде, не изменяя код приложения и не создавая новый тип ресурса. В семействе Windows Server 2003 такие приложения могут работать в кластере на базовом уровне как "приложения без поддержки кластеров". В Cluster Service имеется тип ресурса Generic Application, предназначенный специально для этой цели.

DLL расширения Cluster Administrator

DLL расширения Cluster Administrator предназначены для того, чтобы задавать в Cluster Administrator параметры, специфичные для приложения. С их помощью пользователи могут управлять приложениями одним и тем же образом, как бы ни выполнялось приложение - в кластере или вне его. Разработчики могут реализовывать средства управления приложением, работающие в инфраструктуре Cluster Administrator, или просто связывать Cluster Administrator с существующим средством управления.

Разработчики расширяют функции Cluster Administrator, создавая DLL расширения. Приложение Cluster Administrator взаимодействует с DLL расширения через определенный набор COM-интерфейсов. DLL расширения должна реализовать некий набор интерфейсов, и ее следует регистрировать на каждом узле кластера.

Рис. 3. Ключевые компоненты: Cluster Service, Resource Monitor и ресурсные DLL

{
Рисунок:
.NET Server Cluster Service - .NET Server Cluster Service
Resource Monitor - Resource Monitor
Physical Disk Resource DLL - Ресурсная DLL Physical Disk
IP Address Resource DLL - Ресурсная DLL IP Address
Generic Application Resource DLL - Ресурсная DLL Generic Application
Custom Resource DLL - Собственная ресурсная DLL
Disk - Диск
Network - Сеть
Cluster-Unaware Application - Приложение без поддержки кластеров
Cluster-Aware Application - Приложение с поддержкой кластеров
}

Приложения без поддержки кластеров

Приложения или сервисы, у которых нет собственных ресурсных DLL, все равно можно конфигурировать в кластерной среде. В Cluster Service семейства Windows Server 2003 для этой цели предназначены универсальные ресурсные DLL - Generic Application и Generic Service. Cluster Service рассматривает такие приложения или сервисы как обобщенные приложения или сервисы без поддержки кластеров.

Ресурсная DLL Generic Application обеспечивает управление только на самом элементарном уровне. Например, Generic Application проверяет, не было ли сбоя приложения, определяя, существует ли процесс приложения, и переводит приложение в офлайновый режим, завершая процесс. При этом не учитываются зависимости между ресурсами, зато используется простой способ проверки работоспособности приложения в кластерной среде.

High Availability Notepad

Не все приложения эффективно работают в кластере. Лучший способ проверить это - реально развернуть приложение в кластере. Простейший метод такого испытания - настройка приложения на работу в кластере с помощью встроенного типа ресурса Generic Application. Тип ресурса Generic Application входит в состав Cluster Service семейства Windows Server 2003. Этот и другие типы ресурсов можно увидеть, запустив Cluster Administrator и выбрав подузел Resource Types узла Cluster Configuration (рис. 4).

Рис. 4. Узел Resource Types, показываемый в Cluster Administrator

В Cluster Administrator есть интерактивные мастера, позволяющие создавать ресурсы для любого из перечисленных в этом узле типов ресурса. Кроме того, Cluster Service предоставляет COM-интерфейсы, позволяющие программно создавать и администрировать ресурсы.

Примечание Последнюю версию Cluster Administrator и связанных с ним ресурсов разработки можно взять из Platform SDK.

Cluster Automation Server

Cluster Automation Server содержит набор Automation-объектов, который предоставляет языкам сценариев полнофункциональный интерфейс управления кластером и позволяет разрабатывать средства удаленного администрирования через Web. Cluster Automation Server упрощает создание приложений управления кластером.

Объектно-ориентированная природа Cluster Automation Server означает, что решение почти всех задач программирования для кластера состоит из следующих этапов:

Определение кластерной операции, которую требуется выполнить.
Поиск объекта Cluster Automation Server, у которого есть свойство или метод, предназначенные для выполнения этой операции.
Определение того, как получить объект, упомянутый в п. 2. Для этой цели подходит Object Hierarchy, доступная в MSDN^®.
Получение объекта и вызов свойства или метода.

Чтобы проиллюстрировать эти действия, мы программно создадим свой ресурс Generic Application с помощью Windows Scripting Host и Microsoft VBScript.

Объект Cluster

Cluster - это объект верхнего уровня. Вы можете создавать его экземпляры. ProgID объекта Cluster - "MSCLUSTER.CLUSTER":

    Set oCluster = CreateObject( "MSCluster.Cluster" )

Открытие объекта Cluster

Перед использованием любого метода кластера, нужно открыть соединение с этим кластером. Метод Open открывает соединение с кластером. Если методу Open передается пустая строка, он открывает соединение с кластером на localhost. Наш сценарий будет работать на сервере localhost:

    oCluster.Open( "" )

Создание группы

Группа кластера - это контейнер для ресурсов кластера. Когда один из ресурсов группы дает сбой и необходимо перенести ресурс на другой узел, все ресурсы группы перемещаются. Кроме того, группы налагают ограничения на зависимости. Ресурс может установить зависимость от другого ресурса, только если это ресурс той же группы. В нашем тесте мы создадим уникальную группу "High Availability Notepad":

    Set oGroup = oCluster.ResourceGroups.CreateItem( "High Availability
      Notepad" )

Создание ресурса

У каждой группы имеется набор ресурсов. Метод CreateItem создает ресурс и добавляет его в набор группы. В нашем примере мы создадим ресурс "Notepad" типа "Generic Application":

    Set oResource = oGroupResources.CreateItem( "Notepad", "Generic 
      Application", 0 )

Задание свойств ресурса

У ресурса Generic Application есть два свойства, используемые при переводе в онлайновый режим: CommandLine и CurrentDirectory. CommandLine содержит команду, выполняемую, когда ресурс переводится в онлайновый режим; CurrentDirectory задает каталог файловой системы, из которого выполняется команда. Когда в нашем сценарии выполняется оператор, переводящий ресурс в онлайновый режим, запускается Notepad. Чтобы видеть Notepad на экране, мы присваиваем значение 1 свойству InteractWithDesktop.

    Set oProperties = oResource.PrivateProperties

    ´ Задаем свойства Generic Application
    oProperties.Item("CommandLine") = "notepad" 
    oProperties.Item("CurrentDirectory") = "c:\"
    oProperties.Item("InteractWithDesktop") = 1

    oProperties.SaveChanges

Перевод ресурса в онлайновый режим

Метод Online переводит ресурс в онлайновый режим. Онлайновый режим (online) - это состояние, в котором ресурс доступен кластеру. В нашем Generic Application перевод ресурса в онлайновый режим - это запуск Notepad.

    oResource.Online 10

Полный исходный код сценария

Option Explicit

Main
´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´ 
´  Подпрограмма Main
´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´
  Sub Main

    Dim oGroup
    Dim oCluster
    Dim oResource

    ´ Создаем объект Cluster
    Set oCluster = CreateObject( "MSCluster.Cluster" )

    ´ Открываем кластер. Пустая строка означает, что открывается
    ´ локальный кластер.
    oCluster.Open( "" )

    ´ Создаем или открываем группу
    AddGroup oCluster, oGroup

    ´ Создаем или открываем ресурс
    AddResource oGroup, oResource

    ´ Переводим ресурс в онлайновый режим и не более 10 секунд ожидаем
    ´ его перехода в онлайновый режим
    oResource.Online 10

End Sub

´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´
´ Подпрограмма, создающая или открывающая группу
´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´
Sub AddGroup( oCluster, oGroup )
    Set oGroup = oCluster.ResourceGroups.CreateItem( "High Availability 
      Notepad" )
End Sub

´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´ 
´ Подпрограмма, добавляющая ресурс в группу
´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´
Sub AddResource( oGroup, oResource )
    Dim oGroupResources
    Dim oProperties
    Dim oCLProperty
    Dim oCDPropery

    Set oGroupResources = oGroup.Resources
    Set oResource = oGroupResources.CreateItem( "Notepad", "Generic 
      Application", 0 ) ´ CLUSTER_RESOURCE_DEFAULT_MONITOR
    Set oProperties = oResource.PrivateProperties

    ´ Задаем свойства Generic Application
    oProperties.Item("CommandLine") = "notepad" 
    oProperties.Item("CurrentDirectory") = "c:\"
    oProperties.Item("InteractWithDesktop") = 1

    oProperties.SaveChanges
End Sub

´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´
´ Ожидаем в течение заданного времени
´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´
Sub Sleep( PauseTime )
    Dim Start

    Start = Timer

    Do While Timer < Start + PauseTime
    Loop

End Sub

При запуске этого простого сценария создается ресурс "Notepad", который помещается в собственную группу ("High Availability Notepad").

Проверка результатов

Мы можем проверить результаты с помощью Cluster Administrator и убедиться, что параметры заданы корректно, посмотрев свойства нашего ресурса Notepad в Cluster Administrator (рис. 5).

Рис. 5. Параметры ресурса Notepad

На вкладке Advanced показаны значения свойств по умолчанию, указывающие, что при сбое приложение перезапускается до 3 раз. Интервалы опроса LooksAlive и IsAlive по умолчанию имеют значения, определенные для данного типа ресурса, но эти значения можно переопределить. Поскольку приложение не содержит специального кода, превращающего его в приложение с поддержкой кластеров, оно считается работающим, если в операционной системе выполняется его процесс.

Рис. 6. Вкладка Advanced окна свойств ресурса Notepad

Тестирование приложения

При переводе ресурса Notepad в онлайновый режим на сервере запустится Notepad. Если процесс Notepad завершится, то приложение сразу же запустится снова. Это связано с тем, что Cluster Service стремится обеспечить, чтобы приложение постоянно выполнялось и было доступно. В случае ресурса Generic Application Cluster Service обнаруживает, что процесс приложения больше не выполняется, и предпринимает корректирующие действия согласно политике.

Что произойдет, если сбой приложения не связан с завершением процесса (например вызван сбоем сети, зависанием процесса или завершением фонового процесса)? К сожалению, для типа ресурса Generic Application реализуется лишь простейшее выявление сбоев. Большинство разработчиков приложений, предназначенных для выполнения в кластерной среде, предпочитают создавать собственные ресурсные DLL, способные решать специфические проблемы. Зато тип ресурса Generic Application отлично подходит, чтобы быстро оценить, как приложение будет работать в кластере.

Заключение

Microsoft Cluster Service обеспечивает высокую доступность с помощью стандартного недорогого оборудования и в то же время в максимальной мере использует имеющиеся вычислительные ресурсы. В Cluster Service семейства Windows Server 2003 предусмотрены мощные средства, позволяющие сделать приложение высоко доступным. Переход к написанию приложений с поддержкой кластеров может показаться некоторым разработчикам слишком дорогостоящим или трудным. Чтобы с минимальными предварительными затратами показать разработчикам преимущества кластеризации, в Cluster Service имеется тип ресурса Generic Application, с помощью которого легко настроить приложение на выполнение в кластере. Тип ресурса Generic Application не дает гибкости, необходимой для производственного приложения, зато позволяет увидеть, как ведет себя приложение в кластере.