Собственно MSCS – это составная часть Windows NT Server, Enterprise Edition (NTS/E), представленная в виде законченного набора. Кроме того, разработчики Microsoft включили кластерную поддержку в операционную систему Windows 2000 Advanced Server и Datacenter Server. Кластер Windows 2000 MSCS практически идентичен версии кластера для NTS/E, за исключением того, что в новой редакции MSCS поддерживает в кластере более двух узлов (Datacenter будет поддерживать четырехузловой кластер). Большая часть информации, изложенной в данной статье, с равным успехом может быть отнесена и к кластерам NT, и к кластерам Windows 2000, хотя некоторые проблемы, не рассмотренные здесь, присущи только лишь кластерам на базе Windows 2000.Для реализации кластерного решения от Microsoft я рекомендую использовать NTS/E.
Подготовка
Кластер, реализованный Microsoft в продукте MSCS, способен обеспечить высокую степень готовности, хотя и не с таким коэффициентом, как при использовании специализированных промышленных систем от других производителей, к слову, более дорогих. Также надо понимать, что используя решения, основанные на NT, всегда имеешь дело с проблемами, связанными с обеспечением безопасности, вынужденными перезагрузками после установки программных заплаток (hotfix) и ресурсоемкой аппаратуры. Все вышесказанное означает, что техническим специалистам прежде чем устанавливать MSCS следует тщательно проанализировать требования, предъявляемые к кластерной системе, и ясно представить, в какой среде кластер будет работать. Принятие решения следует обосновывать, исходя из степени соответствия MSCS указанным требованиям.
Оцените потребности бизнеса. Если бизнес организации требует готовности системы 24 часа в сутки 7 дней в неделю (схема 24х7), то решение на базе NT не годится. В том случае, когда кластерная система время от времени может останавливаться для непродолжительного профилактического обслуживания, или же для компании пятиминутный незапланированный простой один раз в году – не потеря, MSCS вполне подойдет.Системы, работа которых для бизнеса не критична, тоже могут считаться хорошими кандидатами для установки кластера от Microsoft. Из описания особенностей MSCS известно, что каждый сервер в составе кластера может запускать самые разные приложения и обеспечивать выполнение процедуры восстановления (failover) в случае возникновения проблем на одном узле кластера - на другом узле. Безопасность, достигаемая обслуживанием системы с горячим резервированием для каждого сервера, может быть уравновешена ростом затрат на конфигурирование двух отдельно стоящих серверов в кластерную систему.
Оцените приложения. Одни приложения более приспособлены для работы в кластерной среде, нежели другие. Предположим, на оба узла кластера установлено одно и то же приложение. Приложение запущено на одном узле и до поры до времени простаивает на другом. Если активный сервер дает сбой, то приложение должно запуститься на втором сервере. Но некоторые приложения (например, системы управления базами данных, которые не поддерживают функции автоматического восстановления целостности) не способны автоматически восстановить свою работу и поэтому не могут рассматриваться в качестве оптимального выбора для работы в кластерной среде.Администратору системы, который решил установить на кластер приложение, не способное автоматически восстанавливаться после сбоя, придется самому выполнять определенные действия для восстановления. Необходимые для этого шаги нужно обязательно документировать и со всей возможной тщательностью провести испытания процедуры восстановления. Или же можно написать специальный сценарий и оформить его в среде MSCS таким образом, чтобы он исполнялся всякий раз перед тем, как после сбоя на одном узле кластера приложение попытается стартовать на другом. И снова – чрезвычайно важно провести всестороннее тестирование решения с использованием сценария. Если в процессе исполнения сценарий выдает ошибку, то остается лишь использовать протестированный ранее ручной механизм возобновления работы приложения.
Некоторые приложения в процессе работы записывают в системный реестр определенную информацию. В кластерной среде служба MSCS реплицирует эти данные из реестра одного узла кластера в реестр другого. Но в то же время, при создании кластерного ресурса системный администратор обязан вручную явным образом указать все параметры реестра, связанные с данным приложением. Эту задачу можно выполнить, только зная все особенности работы приложения или располагая соответствующей документацией. Поэтому я бы не рекомендовал ставить на кластер приложения, которые могут что-то записывать в системный реестр.
Наилучшими кандидатами для кластерной работы являются такие приложения, в которых предусмотрено хранение конфигурационных настроек и текущего состояния на общем (кластерном) диске. Пример: совместный доступ к файлам и принтерам, Microsoft IIS, Microsoft SQL Server, СУБД Oracle. Если предполагается использовать Oracle, я настоятельно рекомендую дополнительно установить на кластер продукт Oracle Fail Safe, который «понимает» кластерную сущность системы, добавляет к имеющимся типам кластерных ресурсов новый тип - Oracle Database - и предоставляет администратору СУБД удобный инструмент для интеграции баз данных Oracle в MSCS.
Оцените аппаратное обеспечение. Специалисты Microsoft утверждают, что для организации кластера допустимо использовать различающиеся по комплектации серверы. Я не советую так поступать и рекомендую всегда, когда возможно, применять серверы одинаковой конфигурации и от одного и того же изготовителя. В этом случае процесс конфигурирования и обслуживания обоих узлов кластера будет тождественным для обоих случаев, администрирование всей системы будет проще, вероятность успешного отката после сбоя – значительно выше.Чтобы более полно задействовать ресурсы кластера системы, администратор может распределить работу различных приложений по разным узлам кластера. Вместе с тем, учтите, что каждый сервер системы должен обладать достаточным потенциалом на тот случай, когда при сбое одного из узлов кластера второй узел смог бы справиться с исполнением всех приложений. В противном случае, администратору следует изменить настройку времени отклика кластерного приложения и снизить число пользователей на период времени, когда все программы запущены на одном-единственном сервере (т.е. на время восстановления).
С точки зрения архитектуры, система хранения данных в кластере от Microsoft может быть либо SCSI-устройством, либо Fibre Channel. Решение использовать SCSI более экономичное; второе – дорогое и относительно новое. Но с другой стороны Fibre Channel - многообещающее решение с точки зрения производительности операций ввода/вывода и надежности. Разработчики Microsoft полагают (по крайней мере, это утверждается в презентации TechNet), что Fibre Channel вызовет интерес компаний, внедряющих кластерные решения. Мне остается только порекомендовать использовать именно Fibre Channel, если это позволяет бюджет организации.
Реализация кластерной системы совсем не означает, что администратор может почить на лаврах и пренебречь мониторингом сервера и подсистемы хранения данных. Всегда найдется ряд факторов (например, устойчивость системы к сбоям на уровне аппаратных компонентов), которые и будут определять общую готовность системы. К построению системы надо подойти с позиций использования как можно более надежного отдельного аппаратного компонента – нельзя полагаться на то, что кластерное программное обеспечение придет на помощь во время сбоя сервера. Сделайте инвестиции в относительно недорогое избыточное решение, какую бы подсистему ни рассматривать, - источник питания, кондиционеры, сетевые карты, - при покупке современного сервера все это может быть включено в комплектацию. Защитите локальную дисковую подсистему сервера от сбоев с помощью зеркалирования (используйте возможности внутреннего RAID-контроллера, или же программные средства самой NT).
Общая дисковая стойка, вообще говоря, заставляет вспомнить поговорку насчет «всех яиц в одной корзине»: если она вдруг станет недоступной – то же произойдет и со всей системой. Реализуйте дисковые контроллеры как избыточные пары, работающие как единое целое. Обеспечьте избыточное питание и кондиционирование для дисковой стойки. Дополнительно защитите диски – в идеале для каждого из них должно быть создано свое зеркало.
Реализация
Запомните: устанавливая кластер, вы разворачиваете не просто два отдельно стоящих сервера и дисковую стойку – вы устанавливаете нечто целое, имя которому - кластер. Администратору системы потребуются особые знания и опыт, чтобы добиться от кластера должной производительности. Я рекомендую предварительно прочитать как можно больше материалов от разработчиков оригинальных кластерных решений. Список необходимой литературы приводится во врезке «Ресурсы MSCS».
Ресурсы MSCSКниги
Windows NT Microsoft Cluster Server
Автор: Richard Lee
Издательство: (McGraw Hill, 1999)
Статьи Microsoft"Cluster Server Troubleshooting and Maintenance White Paper"
http://support.microsoft.com/support/ kb/articles/q238/6/27.aspНе нужно полагаться на документацию Microsoft для NTS/E , поскольку она по многим ключевым вопросам отстала от жизни. С пристрастием исследуйте предмет, не довольствуйтесь только теоретическими знаниями о кластерах, но и разберитесь, как кластерная среда будет сосуществовать с уже имеющимися в организации вычислительными технологиями. Например, вполне может быть, что как часть общей стратегии безопасности применяются некоторые утилиты из программного пакета Resource Kit - Rdisk или Regback. Специфичный для кластера куст реестра, Clusdb, расположенный в каталоге \winnt\cluster, ни та, ни другая утилита не копируют автоматически. Не скопировав вручную с помощью той же Regback означенный куст, можно попасть в ситуацию, когда бесполезными окажутся и диск Emergency Repair Disk (ERD), и заранее сделанная копия каталога repair.
Реализация MSCS. Процесс развертывания кластера состоит из нескольких стадий. Основная цель – сконфигурировать все кластерные элементы максимально грамотно, оставляя в стороне те моменты, которые выходят за рамки административного управления, например, поддержка работоспособности системы в целом. Выполните и протестируйте каждую стадию развертывания кластера, и обязательно разрешайте все возникающие трудности перед тем, как переходить к следующему этапу работ – не доводите до того, что после завершения установки кластера придется решать накопившийся ворох проблем. Я предлагаю продвигаться через процедуру установки в соответствии с описанными ниже шагами (подробный анализ всех элементов процесса установки кластера приводится в документации на программный продукт MSCS).1. Установите все относящиеся к развертываемому кластеру аппаратные компоненты (то есть серверы, контроллеры, диски).
2. Установите на каждый сервер – узел кластера - операционную систему NTS/E и пакет обновлений Service Pack 3 (SP3). Обновление SP3 входит в поставку NTS/E на CD-ROM, поэтому установка пакета обновлений выполняется как один из этапов в процессе инсталляции сервера. Если нужно, впоследствии можно установить пакет обновлений более высокого уровня.
3. Из соображений удобства восстановления всей системы после нетривиального сбоя, создайте на каждом сервере вторую инсталляцию NT, базовую в некотором смысле: без постороннего программного обеспечения – только лишь то, что нужно для активизации сетевого оборудования, ленточных накопителей и системы хранения. Постарайтесь разместить аварийную инсталляцию на диск, физически отличный от первичной (рабочей) установки. Выполните программу обновления SP3.
4. Установите другие дополнительные драйверы для доступа к общей дисковой стойке.
5. Используя внешнее подключение (например, через последовательный порт) сконфигурируйте контроллеры кластера. Выделите одно устройство в качестве кворумного диска.
6. Установите кластерное программное обеспечение, MSCS, на первый узел. В это же самое время второй узел должен быть в состоянии выбора меню начальной загрузки операционной системы. Теперь перезагрузите первый узел и убедитесь в том, что приложение MSCS Cluster Administrator успешно взаимодействует с кластерными службами и выводит информацию о состоянии ресурсов кластера.
7. Установите кластерное программное обеспечение, MSCS, на второй сервер-узел (первый сервер загружен полностью, кластерные службы успешно стартовали). Теперь перезагрузите второй узел и убедитесь в том, что приложение MSCS Cluster Administrator успешно взаимодействует с кластерными службами и выводит информацию о состоянии кластерных групп, ресурсов и т.д., для обоих серверов – узлов кластера.
8. Проверьте, что две группы, устанавливаемые по умолчанию, Cluster Group и Quorum Disk Group, могут успешно перемещаться между серверами кластера как при ручной инициации, так и в результате выключения одного из серверов.
9. Начиная с этого момента, можно при желании установить более поздний пакет обновлений (включая и установку программных заплаток - hotfix).
10. Если имеется несколько кластерных дисковых стоек и есть желание их сконфигурировать в одном кластере, это можно сделать сейчас. Следуйте методике, изложенной в "MS Cluster Server Administrator`s Guide" (http://www.microsoft.com/technet) и в материалах TechNet. Включите дополнительные устройства в состав кластерных групп, после чего протестируйте эти устройства на предмет успешного восстановления с одного узла на другой.
11. Кластер полностью подготовлен к запуску приложений.
Установка приложений на кластер. Установка приложений на кластер требует планирования. Как уже отмечалось, следует избегать использования приложений, которые модифицируют реестр во время работы. Разберитесь с файлами, которые приложение читает, обновляет или записывает. Это могут быть файлы конфигурации, файлы журналов и статистики. Все они должны размещаться на кластерных дисках и при «переезде» приложения с сервера на сервер «следовать» за ним.Внимательно изучите взаимозависимость различных ресурсов кластерного приложения. Например, невозможно перевести приложение в активное состояние до тех пор, пока не будут переведены в это состояние диски с данными, сетевое имя для клиентского доступа и не будет активизировано имя виртуального сервера по заранее прописанному IP-адресу. С помощью интерфейса администратора кластера можно описать зависимости между различными ресурсами в пределах только одной и той же группы. Следовательно, все ресурсы так или иначе связанные с приложением, следует размещать в одной и той же группе вместе с приложением. Если несколько приложений или их копий (например, базы данных) совместно используют некоторый ресурс, все эти приложения или копии также обязаны быть в одной и той же группе. Это требование ограничивает возможности администратора в плане распределения нагрузки на кластер между его узлами. Когда на обоих серверах – узлах кластера - администратор намеревается запустить одно и то же приложение, предварительно он должен спланировать ресурсы приложения на дисках обоих узлов. А в том случае, когда приложение использует любой из ресурсов, принадлежащий группе Cluster Group (в данном случае имеется в виду группа, в состав которой входит виртуальный сервер), администратору системы надлежит внести в нее все ресурсы приложения. Для установки и проверки функционирования типового приложения или его копии следуйте таким рекомендациям:
1. Создайте группу для ресурсов приложения. Определите для этой группы диски кластера. Опишите все остальные ресурсы, относящиеся к работе приложения (сетевое имя, IP-адрес виртуального сервера). Убедитесь, что группа переводится в активное состояние с обоих узлов кластера.
2. Переведите группу в активное состояние на одном из серверов, скажем, на сервер А. Установите приложение на сервер А и настройте параметры приложения таким образом, чтобы были задействованы диски кластера. Убедитесь, что приложение на узле А работает так, как ожидается (то есть стартует, работает, корректно останавливается).
3. Опишите службы и программы приложения как кластерные ресурсы. Для начала установите параметр запуска служб приложений вручную. Убедитесь, что в среде Cluster Administrator приложение штатно стартует и останавливается.
4. Переместите группу на другой узел кластера (сервер В). Установите приложение на сервер А и настройте параметры приложения таким образом, чтобы были задействованы диски кластера; будьте внимательны – не перепишите настройки кластерных дисков, произведенные ранее, когда приложение располагалось на сервере А. И снова установите параметр запуска служб приложения вручную. Убедитесь, что в среде Cluster Administrator приложение штатно стартует и останавливается.
5. Убедитесь, что приложение восстанавливается с одного сервера на другой как по команде администратора, так и в случае сбоя на сервере.
6. Описанные действия выполните и для других кластерных приложений. После каждой установки убеждайтесь в работоспособности приложения.
Можно сконфигурировать вспомогательное программное обеспечение, например, приложения резервного копирования или системного мониторинга, таким образом, чтобы кластер воспринимался как единое целое, или, напротив, как два отдельно стоящих сервера. Решение зависит от характеристик и назначения программы. Рассмотрим использование простейшей утилиты системного мониторинга для наблюдения за состоянием некоей кластерной службы. Эта утилита посылает сигнал тревоги по SNMP в программу сетевого менеджмента, когда интересующая служба перестает работать. Но в кластерной среде в каждый момент времени эта самая служба на одном узле работает, а на другом – нет. Если наблюдение будет настроено не на кластер, а на каждый отдельный сервер, то программа-монитор не сможет «понять», что на самом-то деле служба запущена на одном узле и именно из-за этого остановлена на другом, и, как следствие, постоянно будет генерировать сигналы тревоги.
Одно из возможных решений этой проблемы состоит в том, чтобы включить в программу сетевого менеджмента логику, рассматривающую оба сервера как нечто взаимосвязанное, и выставляющую сигнал тревоги только тогда, когда оба сервера сообщают об остановке службы. Другое решение – интегрировать системный монитор в кластер и создать ресурс для копии приложения, запускающейся в работу и использующей возможности команды cluster (утилиты командной строки) для проверки состояния службы кластера.
Обслуживание
С одной стороны, администраторам необходимо создать исключительно устойчивую, с очень высоким коэффициентом готовности, систему. А с другой стороны, если что-то в системе не так, нужно уметь быстро исправить положение. Посмотрим, как этого можно добиться.
Если возникает потребность выполнить программные или аппаратные мероприятия по обслуживанию кластерной системы, можно переместить все ресурсы с одного сервера – узла кластера - на другой узел, после чего заняться обслуживанием первого узла. При этом услуги приложений, ранее предоставляемых кластером, как единым целым, по-прежнему будут доступны. В то же время, я бы порекомендовал всегда, когда это только возможно, выполнять обслуживание серверов кластера при остановленных приложениях, во время, отведенное для технической профилактики. Тогда можно избежать неприятной ситуации, связанной с внезапной остановкой приложения, спровоцированной проблемами при проведении обслуживания. За примером далеко ходить не надо: прочитайте описание процесса обновления операционной системы NT при установке самого последнего Service Pack 6а - в варианте специалистов Microsoft. Прочитайте, и, как говорится, сделайте наоборот, если не хотите неприятностей: нужно дождаться, пока обновление операционных систем на обоих серверах окончательно завершится – при этом все приложения кластера должны быть остановлены.
В MSCS разработчики не предусмотрели никаких функций, связанных с работой распределенного менеджера блокировок - Distributed Lock Manager (DLM); а это, в свою очередь, означает, что в каждый момент времени только один сервер может обращаться к диску. По умолчанию в MSCS правом обращения к кластерному диску обладает только тот сервер, которого служба Cluster Service определяет как собственника данного диска. Из этого следует, что служба Cluster Service обязательно должна быть запущена, и либо нужно сформировать новый кластер на основе данного сервера, либо подключить сервер в качестве равноправного узла к уже существующему кластеру, до того, как будет выполнено самое первое обращение к дискам кластера. Если проблемы, связанные с диском (например, разрушение файла кворума - quorum log) вызывают сбой в работе Cluster Service, то невозможно добраться до диска для корректировки проблем. Если файл кворума испорчен, Cluster Service записывает сообщение об ошибке в системный журнал NT перед тем, как остановить службу. Для решения возникшей проблемы можно воспользоваться параметром -noquorumlogging, чтобы была возможность вручную запустить Cluster Service из приложения Services панели управления. Задание этого параметра позволит Cluster Service стартовать без открытия существующего кворумного файла. Затем удалите файл кворума (он находится по умолчанию в каталоге \mscs\quolog.log) на диске. Остановите и снова запустите Cluster Service. Будет создан новый файл кворума.
Еще одна трудность – просто так запустить программу Chkdsk на диске кластера нельзя. Служба Cluster Service блокирует диски, так что Chkdsk не в состоянии до них «достучаться». Диски становятся доступны только после того, как стартует Cluster Service, а значит программа Chkdsk не получит к ним доступ во время загрузки системы. Для того, чтобы запустить программу Chkdsk на кластерном диске, нужно остановить один сервер, а затем вторично установить NT. Поскольку данная инсталляция не использует программное обеспечение кластера, то не будет и ограничений на доступ к дискам. На проблемном диске теперь можно обычным образом запустить программу Chkdsk, а затем перезагрузить оба сервера в режим кластера.
Не все имеющееся программное обеспечение одинаково хорошо спроектировано для работы в среде кластера. Перед тем как модифицировать кластер, сохраните содержимое системы на ленту и обновите диск аварийного восстановления (ERD). Выполните намеченные изменения, убедитесь, что все операции в кластере работают нормально, а ресурсы как обычно «переползают» с места на место. Процедуры, связанные с резервированием данных, могут быть затруднены, поскольку диски кластера могут оказаться подсоединенными как к одному, так и к другому узлу кластера. Составьте простую процедуру, которая была бы рассчитана на типичные условия работы, после чего напишите более сложную процедуру для отработки сценария сбоя на кластере.
Адриан Инглесон – Технический специалист из компании - системного интегратора Softlab в Великобритании. Имеет сертификат MCSE и специализируется в проектировании и реализации высоконадежных систем для разных платформ. С ним можно связаться по адресу: adrian.ingleson@softlab.co.uk.