Отказоустойчивый кластер (англ. High-Availability cluster, HA cluster — кластер высокой доступности) — кластер (группа серверов), спроектированный в соответствии с методом обеспечения высокой доступности и гарантирующий минимальное время простоя за счёт аппаратной избыточности. Без кластеризации сбой сервера приведёт к тому, что поддерживаемые им приложения или сетевые сервисы будут недоступны до восстановления его работоспособности. Отказоустойчивая кластеризация исправляет эту ситуацию, перезапуская приложения на другой системе без вмешательства администратора в случае обнаружения ошибок аппаратного или программного обеспечения. Процесс перезапуска известен как аварийное переключение. В рамках этого процесса программное обеспечение кластеризации может настроить узел перед запуском приложения на нём (например, импортировать и установить соответствующие файловые системы или перезапустить некоторые поддерживающие приложения). Отказоустойчивые кластеры обычно используют специальный сигнал («пульс», англ. heartbeat), который используется для мониторинга состояния и статуса каждого узла в кластере.
Отказоустойчивые кластеры часто используются для поддержки важных баз данных и бизнес-приложений обслуживания клиентов, таких как сайты электронной коммерции.
Требования к архитектуре приложения Не каждое приложение может работать в высокодоступной кластерной среде, и необходимые проектные решения должны быть проделаны в начале этапа проектирования программного обеспечения. Для запуска в высокодоступной кластерной среде, приложение должно соответствовать, как минимум следующим технические требованиям, последние два из которых имеют решающее значение для его надежной работы в кластере, и которые наиболее трудно в полной мере удовлетворить:
Должен быть относительно простой способ для запуска, остановки, принудительной остановки, и проверки состояния приложения. В практическом плане это означает, что приложение должно иметь интерфейс командной строки или сценарии для управления приложением, включая поддержку нескольких экземпляров приложения. Приложение должно иметь возможность использовать общее хранилище данных (NAS / SAN). Очень важно, что приложение должно хранить на энергонезависимом общем хранилище столько, от её состояния, сколько возможно. Не менее важным является способность перезапуска на другом узле в последнем состоянии до разрушения, с помощью сохраненного состояния из общего хранилища. Приложение не должно повреждать данные, если оно выходит из строя, или перезапускается с сохраненного состояния.
Конфигурации узла Наиболее распространенный размер для кластера HA является двухузловый кластер, так как это минимум, необходимый для обеспечения отказоустойчивости, но многие кластеры состоят из многих других, иногда десятков узлов. Такие конфигурации иногда можно разделить на одну из следующих моделей:
Active / active — Трафик предназначен для отказавшего узла либо перехода на работающий узел либо балансировка нагрузки между оставшимися узлами. Это обычно можно только тогда, когда узлы используют однородную конфигурацию программного обеспечения. Active / passive — Обеспечивает полное резервирование экземпляра каждого узла, который включается только тогда, когда, связанный с ним основной узел внезапно прекращает работу. Эта конфигурация обычно требует дополнительных аппаратных средств. N +1 — Предоставляет один дополнительный узел, который включается, чтобы взять на себя роль узла, которое вышел из строя. В случае гетерогенной программной конфигурации на каждом первичном узле, дополнительный узел должен быть способен универсально взять на себя роль любого из первичных узлов, за которые он несет ответственность. Это обычно относится к кластерам, которые имеют несколько служб, работающих одновременно; в случае одной службы, это вырождается в Active / passive. N + M — В случаях, когда один кластер управляет множеством сервисов, имеющий только один выделенный отказоустойчивый узел, не может предложить достаточную избыточность. В таких случаях более чем один (M) резервный сервер должен быть включен и доступен. Количество резервных серверов – это компромисс между стоимостью и требованиями к надежности. N-в-1 — Позволяет резервному отказоустойчивому узлу, становиться активным временно, пока исходный узел не будет восстановлен или включен, после чего услуги или экземпляры должны быть возвращены к нему для того, чтобы восстановить высокодоступность. N-к-N — это сочетание active / active и N + M кластеров. N к N кластеры перераспределяют сервисы, экземпляры или соединения от отказавшего узла среди остальных активных узлов, тем самым устраняя (как с active / active) необходимость для «ожидания» узла, но вызывают необходимость дополнительной мощности на всех активных узлах. Термины логический хост или кластер логического хоста используются для описания сетевого адреса, который используется для доступа к услугам, которые предоставляются кластером. Идентификатор логического хоста не привязан к одному узлу кластера. Это на самом деле сетевой адрес / имя хоста, который связан с сервисом (ами), предоставленным кластером. Если узел кластера с работающей базой данных выходит из строя, база данных будет перезапущена на другом узле кластера, и сетевой адрес, по которому пользователи получают доступ к базе данных, будет восстановлен на новом узле, так что пользователи могут получить доступ к базе данных снова.
Надежность узла HA кластеры обычно используют все доступные методы, чтобы сделать отдельные системы и общую инфраструктуру, надежной, насколько это возможно. К ним относятся:
Зеркалирование дисков, так что сбой внутренних дисков не приводит к сбоям системы. DRBD является одним из примеров. Резервные сетевые соединения, так что повреждения кабеля, сбой коммутатора или сетевого интерфейса не приводят к простоям сети. Резервные сети хранения данных (SAN) соединения, так что повреждения кабеля, сбой коммутатора или сетевого интерфейса не приведут к потере соединения к хранилищу (это нарушило бы неразделяемую архитектуру). Избыточные электрические энергозатраты на разных каналах связи, как правило, оба или все защищены источниками бесперебойного питания, и вторичным источником электропитания, таким образом источник питания, кабель, UPS, или сбой питания не приводят к потере мощности к системе. Эти функции помогают свести к минимуму вероятность, что потребуется отказоустойчивая кластеризация между системами. В случае сбоя, сервис становится недоступен, как минимум, на некоторое время, так что меры по предотвращению являются предпочтительными.
Алгоритмы восстановления при отказах Системы, которые обрабатывают ошибки в распределенных компьютерных системах, имеют разные стратегии, чтобы вылечить сбой. Например, Apache Cassandra API Hector (API) определяет три способа настройки ошибки:
Fail Fast, сценарий как "FAIL_FAST", означает, что попытка вылечить сбой терпит неудачу, если первый узел не может быть достигнут. Неудача, попробуйте следующий доступный, по сценарию, как "ON_FAIL_TRY_ONE_NEXT_AVAILABLE", означает, что система пробует один хост, самый доступный или свободный, прежде чем сдаться. Неудача, попробовать все, сценарий как "ON_FAIL_TRY_ALL_AVAILABLE", означает, что система пробует все существующие, доступные узлы, до отказа.
2018-2024 • WeniZAYCommunity • WeniZAYPowered by uCoz Запрещено использование материалов сайта без прямой ссылки на источник. Все права защищены. • • •
Отказоустойчивые кластеры часто используются для поддержки важных баз данных и бизнес-приложений обслуживания клиентов, таких как сайты электронной коммерции.
Не каждое приложение может работать в высокодоступной кластерной среде, и необходимые проектные решения должны быть проделаны в начале этапа проектирования программного обеспечения. Для запуска в высокодоступной кластерной среде, приложение должно соответствовать, как минимум следующим технические требованиям, последние два из которых имеют решающее значение для его надежной работы в кластере, и которые наиболее трудно в полной мере удовлетворить:
Должен быть относительно простой способ для запуска, остановки, принудительной остановки, и проверки состояния приложения. В практическом плане это означает, что приложение должно иметь интерфейс командной строки или сценарии для управления приложением, включая поддержку нескольких экземпляров приложения.
Приложение должно иметь возможность использовать общее хранилище данных (NAS / SAN).
Очень важно, что приложение должно хранить на энергонезависимом общем хранилище столько, от её состояния, сколько возможно. Не менее важным является способность перезапуска на другом узле в последнем состоянии до разрушения, с помощью сохраненного состояния из общего хранилища.
Приложение не должно повреждать данные, если оно выходит из строя, или перезапускается с сохраненного состояния.
Наиболее распространенный размер для кластера HA является двухузловый кластер, так как это минимум, необходимый для обеспечения отказоустойчивости, но многие кластеры состоят из многих других, иногда десятков узлов. Такие конфигурации иногда можно разделить на одну из следующих моделей:
Active / active — Трафик предназначен для отказавшего узла либо перехода на работающий узел либо балансировка нагрузки между оставшимися узлами. Это обычно можно только тогда, когда узлы используют однородную конфигурацию программного обеспечения.
Active / passive — Обеспечивает полное резервирование экземпляра каждого узла, который включается только тогда, когда, связанный с ним основной узел внезапно прекращает работу. Эта конфигурация обычно требует дополнительных аппаратных средств.
N +1 — Предоставляет один дополнительный узел, который включается, чтобы взять на себя роль узла, которое вышел из строя. В случае гетерогенной программной конфигурации на каждом первичном узле, дополнительный узел должен быть способен универсально взять на себя роль любого из первичных узлов, за которые он несет ответственность. Это обычно относится к кластерам, которые имеют несколько служб, работающих одновременно; в случае одной службы, это вырождается в Active / passive.
N + M — В случаях, когда один кластер управляет множеством сервисов, имеющий только один выделенный отказоустойчивый узел, не может предложить достаточную избыточность. В таких случаях более чем один (M) резервный сервер должен быть включен и доступен. Количество резервных серверов – это компромисс между стоимостью и требованиями к надежности.
N-в-1 — Позволяет резервному отказоустойчивому узлу, становиться активным временно, пока исходный узел не будет восстановлен или включен, после чего услуги или экземпляры должны быть возвращены к нему для того, чтобы восстановить высокодоступность.
N-к-N — это сочетание active / active и N + M кластеров. N к N кластеры перераспределяют сервисы, экземпляры или соединения от отказавшего узла среди остальных активных узлов, тем самым устраняя (как с active / active) необходимость для «ожидания» узла, но вызывают необходимость дополнительной мощности на всех активных узлах.
Термины логический хост или кластер логического хоста используются для описания сетевого адреса, который используется для доступа к услугам, которые предоставляются кластером. Идентификатор логического хоста не привязан к одному узлу кластера. Это на самом деле сетевой адрес / имя хоста, который связан с сервисом (ами), предоставленным кластером. Если узел кластера с работающей базой данных выходит из строя, база данных будет перезапущена на другом узле кластера, и сетевой адрес, по которому пользователи получают доступ к базе данных, будет восстановлен на новом узле, так что пользователи могут получить доступ к базе данных снова.
HA кластеры обычно используют все доступные методы, чтобы сделать отдельные системы и общую инфраструктуру, надежной, насколько это возможно. К ним относятся:
Зеркалирование дисков, так что сбой внутренних дисков не приводит к сбоям системы. DRBD является одним из примеров.
Резервные сетевые соединения, так что повреждения кабеля, сбой коммутатора или сетевого интерфейса не приводят к простоям сети.
Резервные сети хранения данных (SAN) соединения, так что повреждения кабеля, сбой коммутатора или сетевого интерфейса не приведут к потере соединения к хранилищу (это нарушило бы неразделяемую архитектуру).
Избыточные электрические энергозатраты на разных каналах связи, как правило, оба или все защищены источниками бесперебойного питания, и вторичным источником электропитания, таким образом источник питания, кабель, UPS, или сбой питания не приводят к потере мощности к системе.
Эти функции помогают свести к минимуму вероятность, что потребуется отказоустойчивая кластеризация между системами. В случае сбоя, сервис становится недоступен, как минимум, на некоторое время, так что меры по предотвращению являются предпочтительными.
Системы, которые обрабатывают ошибки в распределенных компьютерных системах, имеют разные стратегии, чтобы вылечить сбой. Например, Apache Cassandra API Hector (API) определяет три способа настройки ошибки:
Fail Fast, сценарий как "FAIL_FAST", означает, что попытка вылечить сбой терпит неудачу, если первый узел не может быть достигнут.
Неудача, попробуйте следующий доступный, по сценарию, как "ON_FAIL_TRY_ONE_NEXT_AVAILABLE", означает, что система пробует один хост, самый доступный или свободный, прежде чем сдаться.
Неудача, попробовать все, сценарий как "ON_FAIL_TRY_ALL_AVAILABLE", означает, что система пробует все существующие, доступные узлы, до отказа.