И так, начнем! Вы решили использовать кластерную систему для критически важного бизнес-приложения (например, корпоративной базы данных на базе Microsoft SQL Server), и теперь перед вами стоит задача правильно спроектировать и реализовать данное решение. Какие же правила при этом потребуется выполнить?

Правило 1. Определитесь с рисками и бюджетом

Кластерные системы — дело не дешевое. Цена сильно зависит от сложности системы и степени защиты от отказов. Поэтому в первую очередь надо определиться с количеством и степенью рисков, для защиты от которых предполагается использовать кластерное решение. Желательно хотя бы приблизительно посчитать, сколько времени займет восстановление работоспособности приложений при самом серьезном сбое, если не будет кластерного решения, и во сколько обойдется фирме простой. Следует определиться, нужен ли вам географически распределенный кластер, и стоит ли располагать систему хранения данных в том же помещении, что и узлы кластера.

Самое дешевое решение — взять все, что называется, «в одном флаконе», когда два сервера и внешний SCSI-массив конструктивно выполнены как одно целое. Такие решения есть у ведущих фирм-производителей серверов, например HP ProLiant DL380 G4 Packaged Cluster with MSA500 G2, и они, как правило, удовлетворяют требованиям к кластерным системам небольших и некоторых средних предприятий. Недостатки данного решения напрямую связаны с недостатками интерфейса SCSI — не самая высокая скорость передачи данных, нет возможности географически разнести компоненты кластерной системы и т. п.

Самую высокую степень защиты от разнообразных сбоев можно обеспечить только при условии полного резервирования всех компонентов кластерной системы и устранения тем самым всех точек отказа. Далее изложены требования к серверам и системе хранения данных для получения решения с максимальной отказоустойчивостью:

  • в кластере должно быть минимум два сервера;
  • каждый сервер должен иметь два соединения с системами хранения данных;
  • каждый сервер должен иметь два сетевых адаптера;
  • система хранения данных должна иметь по два соединения с каждым сервером;
  • общие данные кластера должны храниться на отказоустойчивом RAID-томе, и система хранения данных должна поддерживать горячую замену и горячий резерв дисков;
  • в системе хранения данных должно быть два контроллера жестких дисков;
  • все серверы и системы хранения данных должны иметь по два блока питания;
  • желательно, чтобы операционные системы серверов также были установлены на отказоустойчивый RAID-том, дисковые подсистемы серверов поддерживали горячую замену и горячий резерв.

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

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

Правило 2. Active Directory

Кластер на основе MSCS может функционировать, только если в сети развернуты службы Active Directory. Если это не так, придется либо отказаться от перспективы применения MSCS, либо заняться внедрением Active Directory.

Правило 3. Необходимые сетевые службы

Наличие Active Directory подразумевает наличие DNS. Это также необходимая служба для функционирования MSCS, поскольку сам кластер и каждый виртуальный сервер имеют собственные IP-адреса и имена хостов.

Несмотря на заявления Microsoft о скорой замене устаревшего протокола NetBIOS новыми технологиями, для MSCS в Windows 2000 Server и Windows Server 2003 NetBIOS является основным средством сетевого взаимодействия. Имя сетевого ресурса MSCS в этих версиях Windows по умолчанию является именно NetBIOS-именем, и только на следующем этапе в нем можно включить регистрацию в DNS и аутентификацию Kerberos. Так что для правильного функционирования MSCS в корпоративной сети очень желателен WINS-сервер.

Подробно эта тема освещена в статье базы знаний Microsoft, которую можно найти по ссылке: http://support.microsoft.com/kb/302389/.

По сведениям специалистов Microsoft, в Windows Server 2008 Failover Cluster этого «тяжелого наследия» NetBIOS больше нет.

Правило 4. Будьте реалистами

Нужно четко понимать, что все эти заявленные данные по максимальной скорости и пропускной способности, например, максимальная скорость передачи FC — 4 Гбайт/сек, отнюдь не означают, что все операции обмена данными в вашей системе будут происходить исключительно на таких скоростях. Это идеальные величины, полученные в лабораторных условиях при передаче единичной эталонной порции информации. К тому же 4 Гбайт/сек — скорость передачи данных исключительно на участке Fibre Chanel, а прежде чем попасть в него, ваши данные должны будут пройти по локальной сети и шинам сервера PCI илии PCI Express, где скорость значительно ниже, чем у Fibre Chanel, и это без учета времени на обработку данных процессорами сетевых карт, адаптеров HBA и контроллеров дисковых массивов. Также надо отметить, что полоса пропускания всех шин, через которые пойдут данные, будет разделена между пользователями системы, и скорость передачи у конечного пользователя будет в несколько раз меньше этих 4 Гбайт/сек.

Для увеличения скорости работы каждого приложения следует внимательно прочитать документацию по RAID-томам и рекомендации по организации дисковых хранилищ для самого приложения, если таковая имеется (как в случае Microsoft SQL Server). Стоит отметить, что в общем случае увеличение количества дисков в составном RAID-томе увеличивает и скорость работы с ним. Так что в случае применения в качестве внешнего хранилища данных дисковых массивов с большим количеством дисков лучше создать на всем массиве один большой RAID-том и нарезать его на логические диски для кворума и данных приложений.

Правило 5. Работайте вместе с интегратором

Разработка и внедрение кластерных систем — дело непростое. Здесь много нюансов, зависящих от конкретных аппаратных платформ, служебного программного обеспечения и самих используемых приложений.

Поэтому я бы не советовал системному администратору одному с нуля заниматься проектированием и последующим развертыванием кластера, лучше делать это совместно с компанией, системным интегратором. Она должна будет сдать вам решение, что называется, «под ключ», с полностью установленным и настроенным программным обеспечением, включая и бизнес-приложения.

При этом, скорее всего, придется отдельно заплатить за пуско-наладку, но в противном случае вы рискуете попасть в ситуацию, когда «к пуговицам претензий нет», но само решение либо не работает, либо работает не так, как надо.

Выбирать интегратора тоже следует тщательно. Хорошо сначала «прощупать почву», пообщаться с коллегами, чтобы узнать отзывы о тех или иных интеграторах. Не бойтесь требовать от компании-интегратора «послужного списка» с полным перечнем реализованных проектов и координатами клиентов.

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

Мне пришлось столкнуться с ситуацией, когда из-за некорректно работающих сетевых адаптеров узлов (причем встроенного сетевого адаптера на материнской плате дорогостоящего сервера производства очень известной компании) происходили регулярные сбои в работе развернутого на кластере приложения Microsoft SQL Server 2005. Служба технической поддержки интегратора, поставившего решение, долго не признавала проблему в аппаратной части, объясняя все сбоями в Microsoft SQL Server. Только после полного анализа журналов активного оборудования и привлечения независимых экспертов проблема была признана, и для узлов кластера были высланы дополнительные сетевые адаптеры (подробности — на форуме MSDN: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1724968&SiteID=1).

Правило 6. Не забывайте о резервном питании

Любой отказоустойчивый кластер при отсутствии резервного питания может дать сбой из-за банальной перегрузки электросети и отключения защитного автомата.

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

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

Правило 7. Документируйте весь процесс

Необходимо четко определить последовательность действий в процессе установки и настройки кластерной системы. Даже в случае, когда это будет делать специалист компании-интегратора, потребуйте предоставить подробный план по всем работам (если нужно, включите данное условие в договор).

Далее я приведу примерный план работ по настройке двухузловой кластерной системы на основе операционной системы Windows Server 2003 Enterprise с одним внешним хранилищем.

Каждый узел и внешнее хранилище имеют два HBA. Подключение осуществляется через два FC-коммутатора, с образованием двух линий связи каждого узла с хранилищем данных. Будем исходить из того, что все компоненты кластера монтируются в стандартные 19-дюймовые шкафы. Перед развертыванием необходимо всем узлам кластера присвоить соответствующие IP-адреса, а также узнать WWN всех HBA на узлах кластера и дисковом массиве.

План развертывания:

  1. Монтаж компонентов кластерной системы в серверные шкафы.
  2. Подключение компонентов к сети. На данном этапе необходимо составить таблицу со всеми параметрами подключений для всех компонентов — номера портов активного сетевого оборудования, IP-адреса всех компонентов кластерной системы.
  3. Настройка дискового массива — очень важный этап.

    Здесь необходимо тщательно продумать структуру и тип RAID-массивов для кворума кластера и вашего приложения, а также структуру логических дисков. Нужно ознакомиться с документацией на приложение и с требованиями к дисковой подсистеме, а также с рекомендациями по типу применяемых RAID-массивов. Если массив содержит встроенные средства резервного копирования, то их тоже необходимо настроить на данном этапе. После настройки массива его конфигурацию требуется сохранить на внешний носитель и подробно документировать ее.

    ВНИМАНИЕ! Замена общих дисков в кластерной системе может привести к неработоспособности приложения, использующего данный диск, и потребовать сложной процедуры восстановления. Все общие диски в кластере имеют уникальную сигнатуру, и если вы при рабочем кластере измените конфигурацию логических дисков, то ваши новые диски не будут идентифицированы службой MSCS. Если же такое проделать с логическим диском кворума, то это наверняка приведет к неработоспособности всего кластера.

    Методика восстановления кластера после замены общих дисков в Windows NT Server 4.0 Enterprise Edition отличается от остальных версий Windows Server. Подробное описание для Windows NT Server 4.0 Enterprise Edition можно найти в базе знаний по ссылке: http://support.microsoft.com/kb/243195/en-us, для Windows 2000 и Windows Server 2003 — по ссылкам: http://support.microsoft.com/kb/305793/en-us и http://support.microsoft.com/kb/280425/.
     
  4. Планирование подключений узлов кластера и дискового массива к FC-коммутаторам. На данном этапе необходимо составить точную таблицу подключений всех HBA к портам FC-коммутаторов и таблицу соответствия WWN номерам портов FC-коммутатора.
  5. Настройка зон на FC-коммутаторах. Без правильно настроенных зон узлы кластера не смогут нормально работать с дисковым массивом. Необходимо правильно настроить зоны на коммутаторах. Подробное описание зонирования приводится в источнике [1], указанном во врезке «Литература», а инструкции по его настройке должны быть в документации на FC-коммутаторы.
  6. Установка и настройка операционной системы на один из узлов кластера. На данном этапе необходимо установить операционную систему, все пакеты обновления и исправления, все драйверы устройств и утилиты, поставляемые производителями дисковых массивов. Потребуйте от компании-интегратора отдельный носитель со всем необходимым программным обеспечением для выполнения инсталляции сервера. Это значительно облегчит работу и в дальнейшем.
  7. Подключение сервера к FC-коммутаторам, проверка доступности общих дисков.

    ВНИМАНИЕ! Нельзя подключать к общему хранилищу два или более сервера с операционными системами Windows 2000 Server и Windows Server 2003 одновременно без установленных и запущенных служб MSCS — это может привести к порче данных на общем хранилище. По информации специалистов Microsoft, при развертывании кластера на основе Windows Server 2008 этой проблемы уже нет.
  8. Настройка MSCS на одном узле. Организация кластера. Документируйте весь процесс. Подробно процесс развертывания MSCS описан в статье Microsoft Technet «Quick Start Guide for Server Clusters», которую можно найти по ссылке: http://technet2.microsoft.com/windowsserver/en/library/dba487bf-61b9–45af-b927-e2333ec810b61033.mspx?mfr=true.
  9. Установка и настройка операционной системы на второй узел кластера.
  10. Подключение второго узла кластера к FC-коммутаторам. Включение второго узла в состав кластера.
  11. Первичная проверка кластера. Необходимо убедиться в доступности всех внешних логических дисков обоим узлам кластера и возможности корректной работы с ними.
  12. Развертывание приложения. Перед этим обязательно следует прочитать соответствующую документацию по приложению.
  13. Проверка работоспособности кластерной системы. Я рекомендую смоделировать все ситуации — отключение питания на одном из блоков питания, на компоненте кластерной системы в целом, потеря связи по одному FC-подключению, выключение узла, изъятие дисков из узлов и дискового массива и т. п. В любой ситуации приложение должно оставаться работоспособным. Если это не так — требуйте объяснений от вашего интегратора и обеспечения полной отказоустойчивости. Пока этого не будет — не принимайте работу.
  14. Полное резервное копирование. Необходимо выполнить резервное копирование узлов кластера, кворума и данных на общих дисках (см. следующее правило).

    15. Правило 8. Резервное копирование — насущная необходимость

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

    В первую очередь хочу напомнить один закон Мэрфи: «Все, что может ломаться, сломается». Этот закон применим и к программному обеспечению хранилищ данных. В случае такого сбоя может пропасть вся конфигурация RAID-томов и вся информация, находящаяся на логических дисках хранилища. В такой ситуации не помогут даже теневые копии логических дисков (тем более что часто они располагаются на том же носителе). А чем грозит потеря всей информации критически важного для бизнеса приложения, например всех баз данных предприятия, — об этом лучше не думать.

    Также существует вероятность выхода из строя более чем одного узла, что в случае двухузлового кластера приведет к полной недоступности данных на внешнем хранилище. Я сам был в таком положении, когда через два дня после отправки на ремонт в сервис-центр одного из узлов кластера система Windows на втором узле выдала «синий экран смерти». Если кого-то из читателей интересуют подробности этой ситуации — пишите мне.

    Поэтому резервные копии просто необходимо будет вынести за пределы кластерной системы. Восстановление полностью настроенного узла с нуля при отсутствии резервных копий — дело долгое и кропотливое. Так что даже при наличии кластерных систем вопросы резервного копирования остаются одними из самых важных. Подробно резервное копирование кластерных систем описано в статье Microsoft, доступной по ссылке: http://technet2.microsoft.com/windowsserver/ru/library/64a561da-5318–489b-ab11-c25ad88e8f5a1049.mspx?mfr=true.

    Правило 9. Контролируйте загрузку узлов

    Это правило особенно актуально в случае схемы Active-Active. Каждый узел должен иметь необходимые свободные ресурсы для того, чтобы приложения с другого узла могли нормально начать функционировать на нем после сбоя. Иначе после выхода из строя одного узла вы получите перегрузку и, возможно, неработоспособность другого. Последствия, думаю, также очевидны.

    Правило 10. Освойте командную строку

    В работе администратора кластеров бывают случаи, когда необходимо остановить один или несколько узлов (например, для профилактики). Все приложения, функционирующие на таком узле, должны быть переведены на другие узлы кластера. Но перевод в течение рабочего дня критически важного приложения крайне нежелателен. Проделывать данную операцию ночью — значит потерять следующий рабочий день. В состав операционных систем Windows Server входит утилита командной строки cluster.exe, которая позволяет выполнять всю работу по созданию и обслуживанию кластеров так же, как через графический интерфейс MSCS.

    Администратору кластерной системы необходимо освоить работу с этим инструментом, чтобы потом, путем применения ее в командных файлах, автоматизировать рутинные операции управления кластером. Можно создать собственный набор командных файлов (своеобразный инструментарий) для наиболее часто выполняемых задач.

    Описание утилиты cluster.exe доступно на сайте Microsoft Technet по ссылке: http://technet2.microsoft.com/WindowsServer/ru/Library/552ed70a-208d-48c4–8da8–2e27b530eac71049.mspx?mfr=true.

    Правило 11. Ведите собственную базу знаний

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

    Не забывайте своевременно устанавливать обновления и исправления на операционные системы узлов кластера и обязательно ведите реестр всех установленных обновлений.

    Правило 12. Не торопитесь

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

    Андрей Мишечкин (andy_mishechkin@hotmail.com) — заместитель директора по ИТ и связи, группа предприятий «Полад», www.polad.ru, г. Тольятти. Имеет сертификат MCSE

    Литература

    1. Ресурсы Microsoft Technet по кластеризации Windows на русском языке
      http://technet2.microsoft.com/windowsserver/ru/library/64a561da-5318–489b-ab11-c25ad88e8f5a1049.mspx?mfr=true
    2. Windows Server 2003 R2 Enterprise Edition — Cluster Server Resource Center
      http://www.microsoft.com/windowsserver2003/technologies/clustering/resources.mspx
    3. Введение в Microsoft Cluster Service (MSCS) семейства Windows Server 2003
      http://www.gotdotnet.ru/LearnDotNet/NETFramework/30627.aspx