...
...
...

Кластерные системы высокой готовности

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

что такое кластер?

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

основные виды кластеров

Объединение серверов в кластер чаще всего преследует цели повышения отказоустойчивости информационной системы (ИС) или ее устойчивости к пиковым нагрузкам, а также, значительного повышения производительности ИС.
В англоязычных терминах такие системы соответственно называются HA systems (High Availability) – системы высокой готовности и HPC (High performance computing) – высокопроизводительные системы.

решения для систем высокой готовности

Решения для систем высокой готовности -- это комплекс работ по проектированию, созданию и организации вычислительного центра, выработке регламентов и процедур эксплуатации, подготовке персонала. Лишь небольшую часть (по данным Gartner Group -- 20%) в общем списке причин простоя систем занимают сбои, связанные с оборудованием и программным обеспечением. Еще 40% -- причины, связанные с недостаточной проработкой процессов и процедур, и еще 40% -- причины, связанные с человеческими ошибками.
Несмотря на такую статистику, техническим вопросам обеспечения готовности все же уделяется гораздо больше внимания. Оно и понятно – это гораздо интереснее, чем разрабатывать скучные инструкции и правила.

компоненты понятия «высокая готовность»

Для того, чтобы систематизировать решения для систем высокой готовности и определить, где какое решение применимо, разделим работы по обеспечению готовности на этапы.
1. Готовность данных.Несмотря на привязанность к компьютерам, самым главным для нас все же являются данные, которые в них хранятся. При любых потерях, авариях, пожарах и наводнениях данные должны оставаться в целости и сохранности. Готовность данных должна быть обеспечена прежде всего, еще до того, как будет решаться вопрос установки кластера или организации резервного вычислительного центра. Бессмысленно строить кластер, пока не внедрена система резервного копирования и не организовано зеркалирование дисковых массивов.
2. Готовность систем.Принятые меры по обеспечению готовности данных спасают в случае аварии на дисковых массивах, неисправность же оборудования сервера может вывести систему из строя на несколько суток, до замены неисправных частей или всего сервера целиком. Для сокращения этого времени вплоть до нескольких минут применяются различные меры по обеспечению высокой готовности системы в целом, от склада запчастей до сложных кластерных схем с применением дополнительного системного программного обеспечения. Следует отметить, однако, что построение и эксплуатация таких схем требует высокой квалификации персонала и взвешенного подхода к определению требований и выбору архитектуры решения.
3. Готовность сервисов.Восстановление оборудования после сбоя - лишь половина дела. Пользователи должны получить доступ к приложениям и сетевым сервисам, именно это они воспринимают как "готовность системы". Поэтому кластерная конфигурация настраивается таким образом, чтобы восстанавливать не только базовую операционную и сетевую среду, но и прикладные сервисы, от электронной почты до системы управления предприятием. Помимо аппаратных сбоев большую опасность для приложений представляют недостаточно проработанные процессы реконфигурации и обновления ПО, на этот случай должны иметься "эталонные" копии ПО и конфигурационных файлов.
4. Готовность предприятия.На этом этапе проводятся работы по защите информационной системы предприятия от катастрофических сбоев и потерь, таких как пожары, затопления, масштабные отключения электропитания, террористические акты. Адекватной защитой от таких угроз является создание или аренда резервного вычислительного центра, который может предоставить предприятию набор необходимых приложений в случае утери основного ВЦ. Важно отметить, что работы по созданию программы защиты от катастроф (disaster recovery, business continuity) ни в коем случае нельзя смешивать с созданием системы высокой готовности в основном вычислительном центре - это совершенно разные проблемы, и их не решить "одним махом". Иначе может возникнуть ситуация, когда из-за сбоя одного диска вся информационная система будет "переезжать" в резервный центр за 15 километров от основного ВЦ, где в этот момент не окажется достаточно квалифицированного персонала, оборудования нужной производительности, чтобы взять на себя всю требуемую нагрузку.

высокопроизводительные системы

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

проектирование систем

Говоря об обеспечении надежности систем, начинать приходится "с самого начала": с определения требований. Какое время простоя системы допустимо? Какова допустимая частота сбоев? Во что обходится предприятию минута, час, день простоя информационной системы? Можно ли выделить приоритетные приложения, которые должны быть восстановлены в первую очередь? Какое количество транзакций может быть потеряно и на каких приложениях?
Задавая эти вопросы, часто слышишь в ответ: "ни секунды простоя", "сбои недопустимы", "все приложения должны быть доступны всегда и всем". Взвешенный подход впоследствии формирует более адекватную картину: в случае сбоя 3 приложения из 18 должны быть восстановлены в течение часа, остальные - до начала следующего рабочего дня. От этих данных уже можно отталкиваться как от реальных требований при разработке решения высокой готовности.
Точное определение требований к системе позволяет значительно снизить финансовые и иные затраты, связанные с построением адекватной системы (следует признать, что декларируемая адекватность, зачастую не имеет ничего общего с реальной, увы).

примеры реализаций кластерных систем

Internet-сервер

Аппаратно кластер выполнен на базе серверов начального уровня Dell PowerEdge 300 (две сетевые карты и по одному контроллеру Dell PERC2 /SC в каждом) и разделяемой дисковой стойке Dell Power Vault (ин-терфейс SCSI). В качестве операционной системы установлена ОС Linux с пакетом кластерного ПО Kimberlite (GNU GPL).
Предоставляемые сервисы – Apache и PostgreSQL. В качестве сервиса может рассматриваться практически любое серверное приложение, взаимодействие с которым осуществляется по TCP/IP.
Сервису назначается мигрирующий IP адрес, сервер, рабочая директория для данных (монтируется раздел дискового пространства стойки). Режим принудительного размонтирования разделов «упавшего» узла, предпочтительный узел для каждого из сервисов, политика возвращения на этот узел назначаются пользователем. Поддерживается управляемый перевод служб с активного на резервный узел.
Кластер обеспечивает уверенное детектирование критичных сбоев и своевременную миграцию сервисов на резервный узел. Промежуток ICMP таймаутов (ping) не превышает 5 секунд, после чего IP адрес успешно мигрирует.
Кластер эксплуатировался в сети ЗАО «НПП Белсофт».

сервер баз данных Oracle

Решение на базе серверов Dell PE2400 и разделяемой дисковой стойке Dell Power Vault. В качестве операционной системы установлена ОС Windows 2000 Advanсed Server.
Предоставляемые сервисы – многопользовательское коммерческое приложение на базе Oracle 8.1.6/Oracle FailSafe 3.0.
Кластер эксплуатировался в сети департамента прикладных программных решений ЗАО «НПП Белсофт», выполнявшего разработку, тестирование и сопровождение прикладной задачи.

сервер резервного ВЦ (проект)

Решение на базе сервера Sun Enterprise 3500 и внешней дисковой системы Sun StorEdge T3 Enterprise (2 дисковых массива с интерфейсом Fibre Channel). Сервер работает под управлением операционной системы Sun Solaris 8.
Высокая готовность системы обеспечена за счет кластеризации дисковой системы и особенностей многопроцессорной архитектуры серверов Sun серии Enterprise, таких как динамическая реконфигурация, выбор альтернативного маршрута и автоматическое восстановление системы.

Юрий Ганчаронок, ЗАО «НПП Белсофт»
В статье использованы материалы компании Sun Microsystems


© Сетевые решения