Отказоустойчивый кластер (Kmtg[krvmkwcnfdw tlgvmyj)

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

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

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

Требования к архитектуре приложения

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

Должен быть относительно простой способ запуска, остановки, принудительной остановки, и проверки состояния приложения. На практике это означает, что приложение должно иметь интерфейс командной строки или скрипты для управления им, в том числе для работы с несколькими запущенными экземплярами приложения.
Приложение должно уметь использовать общее хранилище данных (NAS / SAN).
Очень важно, что приложение должно хранить в неразрушаемом общем хранилище максимально возможное количество данных о своём текущем состоянии. Соответственно, столь же важна возможность приложения быть перезапущенным на другом узле в состоянии, предшествующем сбою, с использованием данных о состоянии из общего хранилища.
Приложение не должно повреждать данные при падении или восстановлении из сохранённого состояния.

Схемы построения

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

Active / active — Часть трафика, обрабатывавшаяся отказавшим узлом, перенаправляется какому-либо работающему узлу или распределяется между несколькими работающими узлами. Такая схема используется в случае, когда узлы имеют однородную конфигурацию программного обеспечения и выполняют одинаковую задачу.
Active / passive — Имеет полное резервирование (работоспособную копию) каждого узла. Резерв включается в работу только тогда, когда отказывает соответствующий основной узел. Эта конфигурация требует значительных избыточных аппаратных средств.
N + 1 — Имеет один полноценный резервный узел, к которому в момент отказа переходит роль отказавшего узла. В случае гетерогенной программной конфигурации основных узлов дополнительный узел должен быть способен взять на себя роль любого из основных, за резервирование которых он отвечает. Такая схема применяется в кластерах, обслуживающих несколько разнородных сервисов, работающих одновременно; в случае единственного сервиса такая конфигурация вырождается в Active / passive.
N + M — Если один кластер обслуживает несколько сервисов, включение в него единственного резервного узла может оказаться недостаточным для надлежащего уровня резервирования. В таких случаях в кластер включается несколько резервных серверов, количество которых является компромиссом между ценой решения и требуемой надёжностью.
N-к-1 — Позволяет резервному узлу включаться в работу временно, пока отказавший узел не будет восстановлен, после чего исходная нагрузка возвращается на основной узел для сохранения исходного уровня доступности системы.
N-к-N — это сочетание active / active и N + M кластеров. В N-к-N кластере сервисы, экземпляры систем или соединения от отказавшего узла перераспределяются между остальными активными узлами. Тем самым устраняется (как в схеме active / active) необходимость отдельного резервного узла, но при этом все узлы кластера должны обладать некоторой избыточной мощностью сверх минимально необходимой.

Термины логический хост или кластерный логический хост используются для обозначения сетевого адреса, который используется для доступа к сервисам, предоставляемым кластером. Идентификатор логического хоста не привязан к одному узлу кластера. Это на самом деле сетевой адрес / имя, которые связаны с сервисом (ами), предоставленным кластером. Если узел кластера с, например, работающей базой данных выходит из строя, база данных будет перезапущена на другом узле кластера, и сетевой адрес, по которому пользователи получают доступ к базе данных, сохранится для любого нового узла, так что пользователи сохранят доступ к базе данных.

Надежность отдельного узла

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

Резервирование и репликация дисков: отказ части внутренних дисков не приводит к сбоям системы. DRBD является одним из примеров.
Резервирование внешних сетевых соединений: повреждения кабеля, отказ коммутатора или сетевого интерфейса не приводят к полному отключению от сети.
Резервирование внутренних соединений cети хранения данных (SAN): повреждения кабеля, сбой коммутатора или сетевого интерфейса не приведут к потере соединения серверов с хранилищем (это нарушило бы неразделяемую архитектуру).
Избыточные схемы электропитания различного оборудования, как правило, защищённого источниками бесперебойного питания, и резервируемые блоки питания: отказ единичного ввода, кабеля, UPS или БП не приводит к критическому отказу питания системы.

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

Алгоритмы восстановления при отказах

Системы, которые обрабатывают ошибки в распределенных компьютерных системах, используют разные стратегии устранения последствий сбоя. Например, Apache Cassandra API Hector (API) предусматривает три варианта обработки ошибок:

Fail Fast, в скрипте — «FAIL_FAST», просто возвращает клиенту ошибку при недоступности узла.
On Fail, Try One — Next Available, в скрипте — «ON_FAIL_TRY_ONE_NEXT_AVAILABLE», означает, что система при сбое узла пробует перевести запрос на другой узел, наиболее свободный, и после первой неудачной попытки возвращает ошибку.
On Fail, Try All, в скрипте — «ON_FAIL_TRY_ALL_AVAILABLE», означает, что система после первой неудачной попытки последовательно пробует все имеющиеся узлы, и только потом возвращает ошибку.

Для контроля работоспособности узлов в кластере обычно используется передача непрерывного периодического сигнала («пульса», англ. heartbeat) во внутренней сети кластера от каждого из узлов, по наличию которого управляющее ПО судит о нормальной работе соседних узлов. С этим связана неочевидная, но серьёзная проблема «разделённого мозга» (англ. split-brain_(computing)) — в случае одновременного разрыва множества соединений во внутренней сети кластера по причине сбоя питания, неисправности сетевого оборудования и т. п., узел, не способный корректно обработать данную ситуацию, начинает вести себя так, как будто все остальные узлы кластера вышли из строя, запуская дубликаты уже работающих в кластере сервисов, что может привести к повреждению данных в общем хранилище.

См. также

Примечания

Ссылки