Вячеслав Елагин, статья опубликована в журнале "Открытые системы", июнь 2002

Сколько времени должен посвятить системный администратор для защиты критически важных данных от наводнения, если офис расположен на 20-м этаже? 

В 1994 году в Чикаго бригада рабочих проводивших профилактические работы пробила дыру в тоннеле, проходившем под рекой. В тоннеле проходили электрические и телекоммуникационные кабели, которые были залиты водой. В результате происшествия 7 зданий в деловой части города оказались без связи и на некоторое время без электричества. Нормальное функционирование было восстановлено лишь на 4-ый день. Суммарные потери всех фирм, офисы которых находились в башнях, составили около 150 млн. долл.

Сегодня важность информации для бизнеса как нельзя актуальна. Если в конце прошлого века информация была для бизнеса, то в начале нового — информация и есть бизнес. С изменением концепции информационно технологического обеспечения предприятий, изменяется сам подход к обработке и хранению данных. Многие предприятия, для которых обработка информации в масштабе реального времени является ключевой (банки, телекоммуникационные компании и др.) всерьёз озабочены сохранностью и доступностью для обработки своих данных. И особое место в стратегии построения высокодоступной системы занимает обеспечение катастрофоустойчивости информационно-технологической структуры.

Катастрофоустойчивость — способность к восстановлению работы приложений и данных за минимально короткий период времени после катастрофы. Под катастрофами понимается не только пожар, наводнение или землетрясение, но также и возможные непредвиденные сбои в работе служб, разрушение данных или повреждение всего центра обработки в результате разных причин, например телекоммуникационных линий в результате проведения ремонтных работ, в результате умышленной диверсии или саботажа. Катастрофоустойчивая архитектура предполагает защиту от незапланированных простоев во время и после катастрофы в географически распределённых узлах кластера, так, чтобы отказ одного узла не приводит к отказу в работе всей системы (рис. 1).

Рассматриваемые в статье решения базируются на использовании оборудования и технологий компании Hewlett-Packard. Помимо излагаемой в статье архитектуры, все виды кластеров от HP включают еще и специальные компоненты управления производительностью, ресурсами, инфраструктурой и т.д. Кроме этого поддержка катастрофоустойчивой конфигурации не ограничивается развертыванием только аппаратно-программных решений, а должна включать специальные виды сервиса, предоставляемые производителем, третьей компанией или выполняемыe самим заказчиком: мониторинг работоспособности (в терминах HP — это обсерватория высокой доступности HAO), подсистему резервного копирования и т.д.

Типы кластеров

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

Локальный кластер

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

Кампусный кластер

Такой кластер (рис. 3) используется во многих центрах как альтернативный способ размещения узлов обработки и хранения данных, которые распределяются по территории предприятия и сбой в одном здании не приводит к простою всей системы. Расстояния между узлами ограничены использующейся технологией реплицирования данных, а сами такие кластеры обычно используют:

• избыточные диски со средствами реплицирования данных;

• избыточные сетевые кабели, проложенные по разным маршрутам;

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

Метрокластер

У такого кластера (рис. 4) (класса города или района) имеются дублирующие узлы, расположенные в разных частях города или в пригородах. Разнесение узлов на большие расстояния уменьшает вероятность выхода из строя дублирующего узла в результате катастрофы. Архитектура метрокластера очень похожа на кампусный с той разницей, что значительно увеличены расстояния между узлами. Соответственно, предполагается наличие разрешения местных властей на прокладку сетевых кабелей и кабелей репликации данных, что может усложнить процедуру разработки и развёртывания кластера.

Метрокластер также предполагает наличие средств синхронизации работы. Обычно для выполнения этой задачи используется площадка-арбитратор, содержащая дополнительный узел, состоящий из выделенного сервера, выполняющего связующую и синхронизирующую роль для всех узлов кластера. Арбитраторы — это полнофункциональные системы, являющиеся составными частями кластера, но не подсоединённые к дисковым массивам SureStore XP. В метрокластере поддерживаются конфигурации с одним или двумя арбитраторами, однако, конфигурации с двумя арбитраторами более предпочтительны, так как они обеспечивают больший уровень доступности.

Основное различие между кампусным и городским (метро) кластером в технологии реплицирования данных. Кампусный использует соединение FC и средство операционной системы MirrorDisk/UX для реплицирования данных, которые накладывают ограничения на расстояния между центрами обработки. Метрокластер использует репликацию данных, основанную на возможностях дисковых массивов HP SureStore XP и EMC Symmetrix, позволяющие разносить эти дисковые массивы на большие расстояния.

Остальные архитектурные требования для метрокластера такие же как и у кампусного. Архитектура метрокластера реализована компанией HP в двух продуктах: MetroCluster with Continuous Access XP и MetroCluster with EMC SRDF.

Континентальный кластер

Такой кластер (рис. 5) представляет собой совокупность дублированных кластеров, разнесенных на значительные расстояния, причем так, чтобы между ними не использовались технологии локальных сетей. В архитектуре континентального кластера каждый входящий в него кластер является полностью правомочным, поэтому площадка-арбитратор не используется. Для соединения кластеров, в этой архитектуре используются глобальные сети на базе TCP/IP, однако, для репликации данных могут понадобиться и высокоскоростные соединения такие как выделенные или коммутируемые линии T1 или T3/E3.

Катастрофоустойчивый кластер

Сегодня всё больше предприятий начинает предъявлять повышенные требования к своей информационной структуре, и всё больше приложений переходит в разряд критически важных. Увеличивается число организаций (среди которых есть и российские), для которых словосочетание «непрерывность бизнеса» становится уже не просто красивым словосочетанием, употребляемым в компьютерной литературе.

Невозможность получить наличные деньги из банкомата в течении часа, подвигло около 3000 клиентов крупнейшего английского банка перевести свои денежные средства в конкурирующие. Суммарные потери за час простоя составили, таким образом, около 6 млн. фунтов.

Всё более или менее серьёзное оборудование подразумевает некоторую степень избыточности. Серверы и дисковые массивы оснащаются резервными источниками питания, вентиляторами, дублирующими контроллерами, процессорами, зеркалированной кэш памятью и ещё многими другими избыточными устройствами. Все эти усилия направлены на устранение единой точки отказа (SPOF) внутри оборудования. Для построения отказоустойчивой системы это необходимо, но для катастрофоустойчивой еще недостаточно. Если отказоустойчивая система способна сохранять работоспособность в случае выхода из строя отдельных компонентов, то катастрофоустойчивая способна сохранять работоспособность в случае одновременного множественного выхода из строя её составных частей или узлов в результате действий непредвиденного характера.

Работоспособность отказоустойчивой системы обеспечивают компоненты, которые уже входят в нее: данные со сбойного диска восстанавливаются по чётности, микросхема памяти может локально отключаться (ChipKill), питание осуществляется с резервного источника. Функционирование катастрофоустойчивой системы достигается за счет распределения компонентов, разнесения её узлов на значительные расстояния. Это позволяет подключать систему к разным подстанциям или электростанциям, исключая точку отказа по сбою в подаче питания и обеспечивая непрерывность бизнеса в случае выхода из строя не только узла кластера, но и всей площадки. Однако, увеличивает роль каналов связи между узлами кластера и если риск повредить проводку внутри здания невелик и можно применять дешёвые решения (изначально считая, что проводка более надёжна компонентов), то в метрокластере канал связи становится полноправным членом всей архитектуры. При построении катастрофоустойчивого кластера необходимо предусмотреть и обеспечить прокладку основного и резервного каналов связи по разным маршрутам.

Для построения правильной архитектуры весьма важно определить, насколько уязвим бизнес и каково максимальное время простоя ИТ-инфраструктуры, при котором бизнесу еще не будет нанесён непоправимый ущерб. Для некоторых предприятий или подразделений внутри одного предприятия, это может быть день или два, для других простой в одну минуту уже несёт ощутимые потери. Возможно, что одни приложения нуждаются лишь в местной защите, например от сбоя узла, а другие, требуют как местной защиты, так и защиты от выхода из строя всей площадки. Так же важно определить какую роль играют каждые конкретные серверы в бизнесе. Например, быстрее требуется восстановить серверы, отвечающие за обслуживание сборочной линии, однако если они находятся неподалёку от сборочной линии и случается, например, землетрясение, то сборочная линия выходит из строя вместе с серверами и запуск приложений, управляющих сборкой на удалённой площадке не имеет смысла. С другой стороны система управления поставками может быть запущена на другой площадке, что обеспечит работу отдела продаж и непрерывность поставок продукции заказчикам. Итак, катастрофоустойчивость системы в аппаратной части обеспечивается:

• Географическим разнесением узлов;
• Реплицированием данных;
• Использованием нескольких источников питания (разные подстанции);
• Созданием высоконадёжной сетевой инфраструктуры.

MetroCluster/CA

Продукт MetroCluster with Continuous Access XP (MetroCluster/CA) представляет собой набор сценариев и файл среды (environmental file) для работы в программном пакете управления кластерами — MC/ServiceGuard. MetroCluster/СА обеспечивает автоматический переход на дублирующий узел, расположенный на другой площадке, в случае отказа в территориальном или городском кластере. Продукт устанавливается на всех узлах кластера, где запущен пакет MC/ServiceGuard, данные приложений расположены на дисковых массивах SureStore XP, а реплицирование на второй дисковый массив SureStore XP осуществляется программным обеспечением HP SureStore Continuous Access XP. В случае обнаружения отказа узла, MetroCluster/CA исключает простои между двумя удалёнными системами, к каждой из которых подключён свой массив SureStore XP.

Каждое решение MetroCluster создает один управляемый кластер высокой доступности, содержащий до 16 корпоративных серверов HP 9000, размещенных не более чем в 50 километрах друг от друга. Конфигурирование MetroCluster/CA должно быть выполнено на всех узлах кластера, так как это сделано для всех других узлов, использующих MC/ServiceGuard. Кроме этого на каждом сервере HP 9000, на котором предполагается запуск приложений, требуется установить RAID Manager XP — серверное ПО для управления и контроля за состоянием (monitor and status) массива SureStore XP. Программное обеспечение MetroCluster/CA разработано для использования в территориальном или городском кластере с ограничением на расстояние FDDI сети не более 100 км. Все узлы должны быть членами одного кластера MC/ServiceGuard. Поддерживаются две следующие конфигурации:

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

Катастрофоустойчивая система должна удовлетворять следующим требованиям:

• каждый центр обработки данных — самодостаточная структура, способная к самостоятельной работе. Важно, что в составе узла кластера отсутствует единая точка отказа;
• сеть между центрами обработки данных избыточна и существует несколько маршрутов передачи данных между центрами, что обеспечивает непрерывную связь между центрами в случае выхода из строя одного из маршрутов;
• все группы физических дисков (volume group), принадлежащих программному пакету и расположенных на дисковом массиве XP, должны активизироваться на узле кластера в эксклюзивном режиме. ПО MetroCluster/CA предполагает, что каждая группа физических дисков, принадлежащая кластеру, в любой момент времени может быть активизирована только одним из узлов кластера.

Единый центр обработки данных

MetroCluster/CA поддерживает архитектуру единого центра обработки данных, которая еще не обеспечивает катастрофоустойчивости. Если весь центр выйдет из строя, то вся площадка перестанет работать. Эта архитектура защищает данные посредством репликации, предохраняет от множественных отказов в узле и является наиболее распространённой среди всех кластерных архитектур. Единый центр данных предусматривает создание кластера по архитектуре «локальный кластер», что обеспечивает надёжную среду обработки данных, но о катастрофоустойчивости говорить не приходится. 

Три центра с площадкой-арбитратором

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

Локальный дисковый массив SureStore XP называется основным (Main Control Unit) для всех узлов в приведенном центре обработки данных. Удалённый дисковый массив SureStore XP, на котором осуществляется реплицирование данных, называется резервным (Remote Control Unit). Термины основной и резервный относительны — дисковый массив SureStore XP может быть основным для одного приложения и резервным для другого. На рисунке 6 основной дисковый массив в центре обработки A основной для приложений A и B, и резервный для приложений C и D в центре обработки B. Для приложений A и B данные записываются на основные тома в дисковом массиве центра обработки A и реплицируются на резервные тома дискового массива в центре B. Соответственно, резервный дисковый массив SureStore XP в центре обработки данных B является основным для приложений C и D, и резервным для приложений A и B. Для приложений C и D данные записываются на основные тома резервного дискового массива центра B и реплицируются на резервные тома основного дискового массива центра A.

Арбитратор обеспечивает такую же функциональность, как и диск захватов кластера (специальный диск, при помощи которого обеспечивается недоступность ресурсов дисковой системы для остальных узлов в то время как их использует один из узлов кластера) и вычисляет новый кластер-кворум в случае отказа одного или нескольких узлов. Диск захватов кластера (cluster lock disc) в территориально распределённой конфигурации не используется, так как он не может управляться средствами связей непрерывного доступа (Continuous Access).

Кластер-кворум — динамическая величина, вычисляемая всякий раз, когда узел кластера выходит из строя. Если, например, система использует 10 узлов, и все работают, то кластер-кворум равен 100%. Если в некоторый момент выходят из строя два узла, то кластер-кворум будет равен 80% и т.д. Каждый раз при выходе из строя одного или нескольких узлов, для переустановки размера кластера и его дальнейшей работы необходимо чтобы кластер-кворум был более 50% иначе оставшиеся узлы будут остановлены. Другими словами кластер способен к реконфигурации только когда число одновременно вышедших из строя узлов строго меньше половины работающих.

В среде территориального или городского кластера, в обоих центрах обработки, должно присутствовать одинаковое количество систем, подключённых к дисковому массиву SureStore XP и один или два арбитратора в центре С.

Использование двух арбитраторов обеспечивает:

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

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

• размещения критических приложений, не защищённых программным обеспечением восстановления после сбоя;
• выполнения управляющих средств таких, как IT/Operations или Network Node Manager;
• запуска приложений резервного копирования, например OmniBack или Veritas NetBackup;
• работы в качестве сервера приложений.

Дисковый массив SureStore XP

Каждый дисковый массив SureStore XP должен быть сконфигурирован с использованием избыточных Continuous Access связей, каждая из которых установлена с различными локальными и удалёнными платами. Для предотвращения образования единой точки отказа в каждом массиве SureStore XP должно быть не менее двух физических плат для Continuous Access связей. Каждая плата обычно имеет несколько портов. Тем не менее, избыточные Continuous Access связи должны быть установлены к портам на других физических платах, отличной от той, на которую установлена основная связь. Другими словами каждый дисковый массив должен иметь не менее двух физических плат для поддержания логических Continuous Access связей, при этом основная и избыточные Continuous Access связи к этому массиву должны устанавливаться на различные платы. При использовании двунаправленных конфигураций, когда центр обработки A является резервным для центра B, и центр B является резервным для центра A, должно быть установлено не менее четырёх Continuous Access связей, по две на каждое направление. Четыре связи должны использоваться и в случае однонаправленной конфигурации если требуется обеспечить восстановление системы после отказа, так как для обеспечения избыточности необходимо наличие не менее 2-х Continuous Access связей.

На пути к катастрофоустойчивости

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

Архитектура с одним арбитратором

Имеется два центра обработки данных и одна площадка-арбитратор (рис. 7). На этом пространстве работает кластер из 4-х узлов и арбитратора (всего 5). Каждый центр обработки данных содержит два узла кластера и один массив SureStore XP. На каждом узел имеется приложение, работающее с дисковым массивом. Между дисковыми массивами установлены связи Continuous Access, так что данные приложения А, расположенные на дисках А массива центра обработки данных А реплицируются на диски А1 дискового массива расположенного в центре обработки данных В. Тоже самое делается для приложений B, C и D, соответственно. Площадка-арбитратор содержит сервер-арбитратор.

В таблице 1 собраны сценарии, иллюстрирующие возможные последствия выхода из строя одного или более узлов в конфигурации с одним арбитратором. Сценарий 1– все узлы работают и отказывает арбитратор. Сценарий 2 – отказывает узел 1. Сценарий 4 не работают узлы 1, 2 и выходит из строя арбитратор.

Таблица 1. Сценарии отказов в конфигурации с одним арбитратором
Сценарий	Не работает	Отказ	Кластер- кворум	Осталось	Последствия
1		Арбитратор	80%	4 из 5	нет
2		узел 1	80%	4 из 5	приложение А запускается на другом узле кластера
3	Узел 1	узел 2	75%	3 из 4	приложения А и В запускаются на другом узле кластера
4	Узел 1, Узел 2	Арбитратор	67%	2 из 3	приложения А и В запускаются на другом узле кластера
5	узел 1, узел 2, арбитратор	узел 3	50%	1 из 2	кластер остановлен *
6	Арбитратор	узел 1	75%	3 из 4	приложение А запускается на другом узле кластера
* Кластер можно запустить вручную на оставшихся узлах.

Таким образом, кластер будет остановлен только в случае выхода из строя третьего узла при уже недоступных двух и арбитраторе. Во всех остальных случаях кластер будет способен произвести реконфигурацию. Понятно, что в обычном режиме приложение А работает на узле 1, в «спящем» виде присутствуя на других узлах кластера, будучи сконфигурировано так, что при остановке оно запускается на другом узле.

Другие сценарии иллюстрируют возможные последствия выхода из строя центра обработки данных в конфигурации с одним арбитратором. (Таблица 2).

Таблица 2. Сценарии отказов в конфигурации с одним арбитратором
Сценарий	Не работает	Отказ	Кластер- кворум	Осталось	Последствия
1		Центр А	60%	3 из 5	приложения А и В запускаются в центре В
2	центр А	Арбитратор	67%	2 из 3	приложения А и В запущены – ничего не происходит
3		центр А, арбитратор	40%	2 из 5	кластер остановлен *
4	центр А	арбитратор, узел 3	50%	1 из 2	кластер остановлен *
5	арбитратор	центр А	50%	2 из 4	кластер остановлен *
6	узел 3	центр А	50%	2 из 4	кластер остановлен *
7		центр В	60%	3 из 5	приложения C и D запускаются в центре А
8		площадка-арбитратор	80%	4 из 5	нет
* Кластер можно запустить вручную на оставшихся узлах.

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

Архитектура с двумя арбитраторами

Наличие двух арбитраторов обеспечивает повышенную защиту при остановке узлов и позволяет осуществлять планирование обслуживания арбитраторов без риска остановки кластера при обнаружении сбоя или катастрофе (Рис. 8).

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

Таблица 3. Сценарии отказов в конфигурации с двумя арбитраторами
Сценарий	Не работает	Отказ	Кластер- кворум	Осталось	Последствия
1		Центр А	67%	4 из 6	приложения А и В запускаются в центре В
2	центр А	Арбитратор 1	75%	3 из 4	приложения А и В запущены – ничего не происходит
3		центр А, арбитратор 1	50%	3 из 6	кластер остановлен *
4	центр А	арбитратор 1, узел 3	67%	2 из 3	приложения А, В, и С запущены на другом узле кластера
5	арбитратор 1	центр А	60%	3 из 5	приложения А и В запускаются в центре В
6	узел 3	центр А	60%	3 из 5	приложения А и В запускаются в центре В
7		центр В	67%	4 из 6	приложения C и D запускаются в центре А
8		площадка-арбитратор	67%	4 из 6	нет
* Кластер можно запустить вручную на оставшихся узлах.

 Минимальный ущерб для полностью функционирующего кластера, при котором он станет недоступен — одновременный выход из строя одного из центров обработки данных и одного арбитратора. Если одновременный ущерб будет больше, кластер будет остановлен. Во всех остальных случаях будет произведена реконфигурация и система продолжит работу на оставшихся узлах. Введение в конфигурацию второго арбитратора существенно повышает уровень доступности всей системы. Как видно из таблиц, сценарий 4 и 5 в конфигурации с одним арбитратором приведут к остановке системы, в то время как аналогичные сценарии (4 и 5) в конфигурации с двумя арбитраторами приведут лишь к реконфигурации кластера.

Защита данных реплицированием

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

• устойчивость данных. Реплицирование данных происходит упорядоченно — копия может быть доступна немедленно. Однако, устойчивые данные не всегда являются актуальными;
• актуальность данных. Процесс реплицирования на удалённую площадку протекает достаточно быстро, поэтому можно быть уверенным, что реплицированные данные содержат все изменения, которые вносились в основную базу;
• возможность восстановления данных. Существует множество способов восстановить данные, например с локальной или удалённой копии, с внешних носителей: оптических или магнитных лент.
• минимальная потеря данных. Обеспечивается тонкой настройкой конфигурации реплицирования, устойчивости, актуальности и возможности восстановления.

Существует два основных способа реплицирования данных: оперативный (on-line) и автономный (off-line). Выбор того или иного способа реплицирования зависит от индивидуальных потребностей и может сочетать оба метода.

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

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

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

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

HP MetroСluster/CA поддерживает оба способа оперативной репликации данных и обеспечивает для вычислительных сред под управлением ОС HP-UX катастрофоустойчивость, благодаря автоматическому переключению узлов и их восстановлению в случае сбоя, отказа оборудования или аварии. Для обеспечения катастрофоустойчивости в разнородных средах — с серверами под управлением Sun Solaris, IBM AIX и Windows 2000 необходимо использовать продукт SureStore Cluster Extension XP. В вычислительной среде Solaris решение Cluster Extension XP интегрируется с программным пакетом VERITAS Cluster Server, в IBM AIX — с программным обеспечением HACMP. В Windows 2000 Advanced Server и Datacenter Servers требуется интеграция с Microsoft Cluster Service. При работе это программное обеспечение взаимодействует с межсистемными связями, создаваемыми SureStore Continuous Access XP и операционной средой. 

Несколько лет назад компания Люфтганза проводила реорганизацию своей ИТ-инфраструктуры. Авиакомпания ежегодно продаёт более 45 млн. билетов по всему миру, каждый билет состоит как минимум из 2-х купонов (по одному на каждую часть полёта) и квитанции, которые содержат информацию о рейсе и пассажире. Люфтганза решила предоставить своим пассажирам гибкую систему скидок на авиабилеты в зависимости от частоты пользования её услугами. Была поставлена задача, использовать имеющуюся информацию для вычисления суммы предоставляемой скидки. Для достижения этой цели было критически важно, чтобы данные о клиентах хранились централизованно и были доступны всем региональным офисам, расположенным по всему миру. Такое решение предполагало обработку и анализ информации круглосуточно, независимо от часового пояса в котором находится региональное представительство.  В компании был развёрнут метрокластер на базе оборудования HP, в состав которого входили два дисковых массива SureStore XP512, способные поддерживать создание удалённых копий (Continuous Access) и содержащих 2,5 Тбайт данных. В кластере было установлено ПО MetroCluster/CA. Две зеркалированные системы гарантировали доступность в режиме 24х7. Это было также важно для обмена информацией с другими приложениями, использующимися внутри организации. В качестве СУБД применялась система Oracle и основанная на решениях SAP автоматизированная система бухгалтерского учёта. Люфтганза также использовала два дисковых массива SureStore XP 256 с 10 серверами производства HP: 4 были соединены через FC-SCSI мосты, а 6 через SAN. Имелось также три кластера MC/ServiceGuard для создания архивной инфраструктуры с высоким уровнем доступности и безопасности хранения данных: один для архива, один для базы данных Oracle и один для SAP/Oracle. Администраторы получили возможность постоянного наблюдения за производительностью дисковых массивов SureStore XP512, что позволяло избегать возможных отказов до их реального возникновения.

Заключение

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

Вячеслав Елагин, (yelagin@i-teco.ru) - руководитель направления компании i-Teco г.Москва.