Компьютер-Информ || Архив || Рубрики || Поиск || Подписка || Работа || О "КИ" || Карта

Кластеры на ОС Linux как системы высокой доступности

1. Кластеры как база построения систем высокой доступности.

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

1.2. Принципы построения систем высокой доступности.
    Основное правило при создании серверных систем высокой доступности - использование избыточных компонентов там, где они необходимы. В отдельном сервере должны быть продублированы все подсистемы, которые могут быть "критическими точками отказа" (Single Points Of Failure, SOPF), - CPU, источник питания, материнская плата, ОЗУ, адаптер ЛВС и т.д., т.е. все подсистемы, отказ которых приводит к отказу системы в целом.
Единственная сетевая карта в сервере, взаимодействующим с клиентами по ЛВС, является "критической точкой отказа" для него. Аналогично "критической точкой отказа" является SCSI адаптер, подключенный к внешней RAID системе. Если некоторый сервер входит в группу серверов, и при отказе он не может быть легко и быстро заменен другим, то этот сервер является "критической точкой отказа" для группы серверов или кластера.
    Решение таких проблем очевидно. Адаптер ЛВС можно продублировать (внести избыточность), поставив второй и обеспечив его активность при отказе первого.
    CPU, источник питания и другие компоненты сервера можно сделать избыточными, но это требует специальных компонентов, не слишком распространенных в мире ПК, а значит, дорогих. Кроме того, эти специальные компоненты тоже подвержены отказам.

1.3. Кластеры как перспективное направление построения систем высокой доступности.
    Одним из перспективных направлений создания системы высокой доступности является создание кластеров. Собственно кластер можно определить как совокупность нескольких (двух или более) компьютерных систем (узлов), управляемых и используемых как единое целое.
    Кластеры можно разделить по цели объединения компьютеров (наращивание вычислительной мощности, повышение доступности, то и другое одновременно), по способу объединения узлов (c общей физической памятью, с общими дисковыми подсистемами и т.п.). Мы будем рассматривать кластеры, цель создания которых - обеспечение высокой доступности исполняемых на них приложений, сформированных с использованием общих дисковых подсистем.
    В таком кластере при помощи специального "ПО обеспечения высокой доступности" (ПО ВД, HA software) два или более серверов могут быть сконфигурированы так, чтобы заменять друг друга при остановке некоторых узлов кластера.
    Обеспечение высокой доступности в кластере, - неполное решение проблемы обеспечения высокой доступности вычислительной системы. Другие компоненты, такие, как сетевое оборудование, системы силового электропитания тоже должны обеспечивать высокую доступность.
    Серверы кластера, стоящие рядом, одинаково отключатся при пропадании силового электропитания. Кроме того, здание, квартал и даже город могут быть "критической точкой отказа" (и даже страна!).
    При обеспечении высокой доступности в кластере не обеспечивается полной устойчивости к отказам с реакцией за доли секунды и полной маскировкой всех отказов для пользователей. После остановки узла возникает небольшой перерыв в обслуживании, необходимый для передачи другому узлу (узлам) ресурсов, таких, как IP адреса, внешние устройства массовой памяти и др. и перезапуска приложений. Обычно это занимает от нескольких секунд до нескольких минут. Время, требуемое на перезапуск приложений, не определяется ПО ВД, а зависит от приложений.

1.4. Кластерные решения известных фирм.
    Уже достаточно давно известны кластерные решения производителей коммерческих UNIX систем:

    Кроме того, в последнее время с кластерными решениями высокой доступности на рынок вышли такие производители сетевых ОС, как:


2. Linux как ОС для систем высокой доступности.
    ОС Linux приобретает все большую популярность. Особенно явно преимущества Linux проявляются при организации на ней серверных служб Интернет. Производительность Linux систем в этом случае обычно вполне достаточна даже при использовании не самых мощных и не самых современных технических средств. Для организаций на первый план выходит надежность работы серверов, потому весьма привлекательным представляется создание на базе ОС Linux систем высокой доступности по кластерной технологии.
    Ядро Linux версии 2.0 обладает особенностями, необходимыми для построения систем высокой доступности программным путем. Для их получения должны быть добавлены некоторые функции или подсистемы. Среди них, кроме самого ПО ВД, можно отметить устойчивую, ориентированную на транзакции, файловую систему, имеющую небольшое время проверки целостности и восстановления в случае отказа узла кластера и передаче ресурсов другому узлу.

3. Кластер высокой доступности на ОС Linux.

3.1. Общая структура кластера.
Кластер высокой доступности состоит из следующих компонентов.

    Узлы кластера в общем случае объединяются тремя информационными шинами - доступа к корпоративной магистрали (ЛВС), синхронизации и контроля работоспособности (по этой шине выполняется "сердцебиение" (Heartbeat)) и данных для доступа к разделяемым периферийным устройствам, в том числе и к разделяемым дисковым подсистемам.     В настоящий момент производители ПО ВД предлагают пять основных стратегий преодоления сбоя для групп ресурсов (у разных поставщиков они имеют разные названия).     Первичный узел является владельцем группы ресурсов. Резервный узел (в нормальном режиме) простаивает, выполняя только контроль работоспособности первичного узла. При остановке первичного узла резервный узел принимает группу ресурсов. Узлы имеют явно заданный приоритет - группой владеет "живой" узел с наибольшим приоритетом. При восстановлении узла с большим приоритетом (первичного узла) он становится владельцем группы, что приводит к короткому перерыву в обслуживании. Узлы могут иметь разную мощность.     В отличие от "Простаивающего резерва" узлы не имеют приоритетов. Узел, который включился первым, становится владельцем группы ресурсов, второй становится резервом. Преимущество этой стратегии - отсутствие перерыва в обслуживании при включении узла с более высоким приоритетом. Недостатки - может несколько смущать неопределенность: какой узел является активным в данный момент (особенно при количестве узлов больше двух) и то, что они должны иметь близкие мощности.     Первичный узел является владельцем критической группы ресурсов. Резервный - исполняет некритичные приложения (например, Web или FTP сервисы, служит для разработки или тестирования) и принимает критическую группу ресурсов при остановке первичного узла, но не наоборот. Если резервный узел не обладает достаточной мощностью для одновременного выполнения и критической группы ресурсов, и некритических приложений, то последние могут быть остановлены. Восстановление первичного узла приводит к передаче критической группы ресурсов на него.     Два узла конфигурируются так, что каждый может принять группу ресурсов другого. Подобным образом эта стратегия работает и в конфигурациях с количеством узлов больше двух.     Все узлы исполняют одну группу ресурсов (в параллельной группе ресурсов не может быть IP и/или MAC адресов). Для того, чтобы можно было использовать эту стратегию, приложение должно быть разработано специальным образом. В настоящий момент возможность применения такой стратегии имеет Oracle Parallel Server. Восстановление при остановке узла при этой стратегии сводится практически к нулю: может потребоваться передача IP адреса отказавшего узла другому узлу (а может и нет - в зависимости от интеллекта клиентов).

    Обычно сами приложения не взаимодействуют с ПО ВД. Оно способно обеспечить высокую доступность любому приложению, функционирующему без вмешательства оператора. Дополнительно может существовать API и библиотеки, позволяющие приложениям взаимодействовать с ПО ВД.

3.2. Пример аппаратной конфигурации кластера.
    Данные критических приложений должны размещаться на внешних устройствах массовой памяти, которые могут быть доступны резервному узлу при отказе активного. Обычно это достигается присоединением внешнего устройства массовой памяти сразу к двум (нескольким) узлам, например, по общей SCSI шине.
На рисунке - пример конфигурации кластера из двух узлов с общей SCSI шиной, подключенных к Ethernet.

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

    Можно выделить следующие типы событий:     Можно задать несколько основных правил, определяющих логику работы "менеджера кластера" на узлах: 3.4. Приложения, для которых обеспечивается высокая доступность.
    ПО ВД изначально может быть не ориентировано на какие-то конкретные приложения. Достаточным интерфейсом с приложением являются скрипты для запуска и останова приложения, запускаемые по событиям "start service" и "stop service" соответственно. Высокая доступность может быть обеспечена для любого приложения, не требует взаимодействия с оператором при запуске. Оно может быть запущено в фоновом режиме.
Одновременно с запуском приложение может запускаться и процесс, управляющий приложением и осуществляющий некоторые действия, необходимые для быстрой и корректной его передачи резервному узлу в случае необходимости. Для такого процесса разумно было бы предусмотреть взаимодействие с "менеджером кластера" и через него с другими узлами кластера при помощи соответствующего API.

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

4. Разделяемые подсистемы дисковой памяти.

4.1. SCSI.
    В первую очередь рассмотрим многохостовое подключение по интерфейсу SCSI. При использовании такого подключения одна или несколько подсистем дисковой памяти (или других внешних SCSI устройств) может быть подключена к двум или более узлам. Такое подключение требует наличия на концах SCSI шины внешних терминаторов. Для адаптеров необходимо выставить различные SCSI ID.
    Необходимо помнить, что дисковые подсистемы тоже могут быть "критическими точками отказа", поэтому оптимальным решением является использование нескольких дисковых подсистем с организацией зеркалирования информации.
    При использовании SCSI шины для подключения разделяемых подсистем необходимо позаботится о надежном заземлении (по крайней мере, - общем занулении) всех соединенных устройств.


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

4.3. Особенности доступа к разделяемым дискам.
    Для нормальной работы доступ к разделяемым дискам должен осуществляться только "активным" узлом. На данный момент невозможно безопасно использовать файловую систему, смонтировав ее на нескольких узлах одновременно, так как в существующих файловых системах отсутствует механизм блокировок.
    Для безопасного доступа необходимо, например, размонтировать/монтировать файловую систему при передаче группы ресурсов от узла к узлу.
    Необходимо также помнить, что стандартные драйверы /dev/sd* и /dev/hd* работают с буферизацией, которая положительно влияет на производительность, но может создать проблемы при аварийном завершении работы узла. Поэтому, если приложения имеют такую возможность (некоторые СУБД, например, Adabas D и Yard), лучше использовать raw disk devices.
    "Менеджер кластера" (или его подпроцесс) может выполнять постоянный контроль за состоянием разделяемого диска ("disk watchdog"), делая попытки чтения/модификации/записи некоторого небольшого блока данных на диск через короткие интервалы времени. Это также позволяет контролировать адаптеры, кабели, терминаторы шины и т.п.

4.4. Файловые системы.

4.4.1. Файловая система "Extended-2".
    Текущая, почти стандартная для Linux файловая система Extended-2 (ext2) вполне стабильна и работоспособна на одиночной машине. Однако в случае отказа узла файловая система не будет размонтирована корректно, что приведет к занимающей существенное время проверке файловой системы на узле, принимающим ее. Кроме того, нет гарантии, что автоматическая проверка и исправление файловой системы найдет и устранит все ошибки.
Все это плохо отражается на системы высокой доступности, когда пользователь ожидает, что принимающий узел запуститься через несколько секунд (в крайнем случае - минут) без ошибок и без вмешательства оператора.

4.4.2. Файловые системы, основанные на журнализации (Log-structured file systems).
    Таким образом, для обеспечения нормального функционирования системы высокой доступности необходима файловая система, работающая по механизму транзакций, основанная на журнализации (Log-structured file system). Сейчас для Linux можно отметить несколько решений, но ни одно из них пока не готово к практическому использованию.


5. Обеспечение высокой доступности подключения к ЛВС.

5.1. Передача IP адресов (IP Address Takeover, IPAT).
    Приложения на клиентах, как правило, не могут переключится "на лету" между несколькими IP адресами для получения доступа к приложениям на сервере. Поэтому при передаче группы ресурсов принимающий узел должен получить требуемый IP адрес до запуска критических приложений.
    Узел кластера запускается с собственным IP адресом на сетевом интерфейсе. При приеме данным узлом группы ресурсов на интерфейс дополнительно назначаются входящие в группу IP адреса.

5.2. Передача MAC адресов (MAC Address Takeover).
    При выполнении передачи IP адреса клиенты могут быть дезориентированы тем, что IP адрес изменил свой MAC адрес. В соответствии с RFC 826 реализации IP должны обновлять свои ARP кэши, если выполнен ARP запрос, IP-MAC пара для которого есть в кэше. Таким образом, теоретически, достаточно очистить ARP кэш IP адаптера узла, который принял IP адрес, и выполнить ARP запрос для любого адреса в подсети.
    К сожалению, не все стеки IP соответствуют RFC 826, например, Windoze 3.11 WINSOCK.DLL является хорошим (плохим!) примером. Некоторые IP стеки для DOS тоже ведут себя так. Как Windows 95/98?
    Однако практически все адаптеры ЛВС позволяют задать MAC адрес. Поэтому имеет смысл для IP адресов, входящих в группу ресурсов, назначить MAC адреса и включить их в группу ресурсов.

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

6. Контроль работоспособности узлов кластера.
    В процессе работы кластера необходимо постоянно контролировать работу узлов и их взаимодействие с ЛВС. Для этого используется посылка специальных контрольных пакетов, содержащих информацию о состоянии узла, и подтверждающих функционирование узла. Процедуру обмена узлов кластера контрольными пакетами можно назвать "сердцебиением" (Heartbeat).
    "Сердцебиение" может выполняться через ЛВС или через другие интерфейсы (serial, SCSI и др.).
    Если от какого-либо узла не поступают контрольные пакеты, то запускается отсчет времени, и через некоторое время считается, что узел отказал. Для надежности "живые" узлы обмениваются информацией, и отказ узла принимается, только если он зафиксирован всеми "живыми" узлами.

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

7.1. Проект Linux-HA (Linux High Availability).
    Это некоммерческий проект, цель которого - разработать решение для создания систем высокой доступности на базе кластеров ОС Linux, обеспечивающее надежность, доступность и полезность (reliability, availability, and serviceability (RAS)).
    Этот проект находится в начальной стадии, но уже сейчас на сайте http://www.henge.com/~alanr/ha/ собрано много интересной информации и ссылок.
В рамках этого проекта действует лист почтовой рассылки, разрабатываются два различных компонента, выполняющие контроль узлов и некоторое управление кластером [вызов скриптов по событиям] (Heart и Heartbeat) и компонентов для передачи IP адресов (fake).

7.2. Проект Linux Virtual Server.
    Цель этого проекта (http://proxy.iinchina.net/~wensong/ippfvs/) - разработать высокопроизводительный и имеющий высокую доступность сервер, обеспечивающий хорошую масштабируемость, надежность и полезность (good scalability, reliability and serviceability).
    Виртуальный сервер - это масшабируемый сервер, построенный на кластере реальных серверов. Архитектура кластера прозрачна для пользователя, и он видит только один виртуальный сервер.
    Реальные серверы могут быть соединены высокоскоростной ЛВС или быть географически разнесенными и входить в территориальную сеть. "Лицом" этих серверов выступает "балансировщик нагрузки" (load balancer), который распределяет запросы между узлами и выглядит как виртуальный сервер с одним IP адресом. Высокая доступность достигается контролем за функционированием узлов и переконфигурацией кластера при его отказе.
Уже разработано ПО виртуального сервера v0.9, которое можно свободно загрузить.

       КОМПЬЮТЕР-ИНФОРМ 
          Главная страница || Статьи 10'1999 || Новости СПб || Новости России || Новости мира

Рубрики || Работа || Услуги || Поиск || Архив || Дни рождения
О "КИ" || График выхода || Карта сайта || Подписка

Рассылка анонсов газеты по электронной почте

Главная страница

Сайт газеты "Компьютер-Информ" является зарегистрированным электронным СМИ.
Свидетельство Эл 77-4461 от 2 апреля 2001 г.
Перепечатка материалов без письменного согласия редакции запрещена.
При использовании материалов газеты в Интернет гиперссылка обязательна.

Телефон редакции (812) 718-6666, 718-6555.
Адрес: 196084, СПб, ул.Заставская, д.23, БЦ "Авиатор", 3-й этаж, офис 307
e-mail: editor@ci.ru
Для пресс-релизов и новостей news@ci.ru