Кластеры высокой доступности (также известные как кластеры высокой доступности, сбой- над кластерами или Метрокластеры Активный / Активный ) - это группы компьютеров, которые поддерживают сервер приложения, которые можно надежно использовать с минимальное время простоя. Они работают, используя программное обеспечение высокой доступности, чтобы использовать избыточные компьютеры в группах или кластерах, которые обеспечивают непрерывное обслуживание при выходе из строя компонентов системы. Без кластеризации, если сервер, на котором запущено определенное приложение, выйдет из строя, приложение будет недоступно, пока неисправный сервер не будет исправлен. Кластеризация высокой доступности исправляет эту ситуацию, обнаруживая аппаратные / программные ошибки и немедленно перезапуская приложение в другой системе, не требуя вмешательства администратора, процесс, известный как аварийное переключение. В рамках этого процесса программное обеспечение кластеризации может настроить узел перед запуском на нем приложения. Например, может потребоваться импортировать и смонтировать соответствующие файловые системы, может потребоваться настроить сетевое оборудование, а также может потребоваться выполнение некоторых поддерживающих приложений.
Кластеры высокой доступности часто используются для критически важных базы данных, совместное использование файлов в сети, бизнес-приложения и службы поддержки клиентов, такие как электронная коммерция веб-сайты.
Реализации кластера высокой доступности пытаются создать избыточность в кластере для устранения единых точек отказа, включая несколько сетевых подключений и хранилище данных, которое подключается с резервированием через сети хранения данных.
HA-кластеры обычно используют частное сетевое соединение heartbeat, которое используется для мониторинга работоспособности и состояния каждого узла в кластер. Одно тонкое, но серьезное условие, которое должно уметь обрабатывать все программное обеспечение кластеризации, - это split-brain, которое возникает, когда все частные ссылки одновременно отключаются, но узлы кластера все еще работают. Если это произойдет, каждый узел в кластере может ошибочно решить, что все остальные узлы отключились, и попытаться запустить службы, которые все еще работают на других узлах. Наличие повторяющихся экземпляров служб может привести к повреждению данных в общем хранилище.
Кластеры высокой доступности часто также используют кворум хранилище свидетелей (локальное или облачное), чтобы избежать этого сценария. Устройство-свидетель не может использоваться совместно двумя половинами разделенного кластера, поэтому в случае, если все члены кластера не могут взаимодействовать друг с другом (например, из-за сбоя пульса), если член не может получить доступ к свидетелю, он не может стать активным.
Содержание
- 1 Требования к дизайну приложения
- 2 Конфигурации узла
- 3 Надежность узла
- 4 Стратегии аварийного переключения
- 5 Реализации
- 6 См. Также
- 7 Ссылки
- 8 Дополнительно чтение
Требования к дизайну приложения
Не каждое приложение может работать в кластерной среде с высокой доступностью, и необходимые проектные решения необходимо принимать на ранней стадии разработки программного обеспечения. Чтобы работать в кластерной среде с высокой доступностью, приложение должно удовлетворять по крайней мере следующим техническим требованиям, последние два из которых критичны для его надежной работы в кластере, и их сложнее всего удовлетворить в полной мере:
- Должен быть относительно простой способ запустить, остановить, принудительно остановить и проверить статус приложения. На практике это означает, что приложение должно иметь интерфейс командной строки или сценарии для управления приложением, включая поддержку нескольких экземпляров приложения.
- Приложение должно иметь возможность использовать общее хранилище (NAS / SAN ).
- Что наиболее важно, приложение должно сохранять как можно большую часть своего состояния в энергонезависимой общей памяти. Не менее важна возможность перезапуска на другом узле в последнем состоянии перед отказом с использованием сохраненное состояние из общего хранилища.
- Приложение не должно повреждать данные в случае сбоя или перезапуска из сохраненного состояния.
- Некоторые из этих ограничений можно минимизировать с помощью виртуального сервера среды, в которых сам гипервизор поддерживает кластер и обеспечивает плавную миграцию виртуальных машин (включая состояние оперативной памяти) между физическими узлами - см. отказоустойчивые кластеры Microsoft Server 2012 и 2016.
- Ключевое различие между этим подходом и запущенным кластерное приложение Это то, что последний может справляться с сбоями серверных приложений и поддерживать текущие "скользящие" обновления программного обеспечения, сохраняя при этом клиентский доступ к службе (например, база данных), когда один экземпляр предоставляет услуги, в то время как другой обновляется или ремонтируется. Для этого требуется, чтобы экземпляры кластера обменивались данными, очищали кеши и координировали доступ к файлам во время передачи обслуживания.
Конфигурации узлов
Схема сети кластера высокой доступности с двумя узлами
Наиболее распространенным размером кластера высокой доступности является двухузловой кластер, поскольку это минимум, необходимый для обеспечения избыточности, но многие кластеры состоят из гораздо большего числа, а иногда и из десятков узлов.
Прилагаемая диаграмма представляет собой хороший обзор классического кластера высокой доступности с оговоркой, что в нем не упоминаются функции кворума / свидетеля (см. Выше).
Такие конфигурации иногда можно отнести к одной из следующих моделей:
- Активный / активный - трафик, предназначенный для отказавшего узла, либо передается на существующий узел, либо выполняется балансировка нагрузки между оставшимися узлами. Обычно это возможно только в том случае, если узлы используют однородную конфигурацию программного обеспечения.
- Активный / пассивный - обеспечивает полностью резервный экземпляр каждого узла, который переводится в оперативный режим только при выходе из строя связанного с ним основного узла. Эта конфигурация обычно требует самого дополнительного оборудования.
- N + 1 - Предоставляет один дополнительный узел, который переводится в оперативный режим, чтобы взять на себя роль узла, вышедшего из строя. В случае разнородной конфигурации программного обеспечения на каждом первичном узле дополнительный узел должен иметь универсальную возможность принимать на себя любую из ролей основных узлов, за которые он отвечает. Обычно это относится к кластерам, в которых одновременно работают несколько служб; в случае одного сервиса это вырождается в активный / пассивный.
- N + M - В случаях, когда один кластер управляет множеством сервисов, наличие только одного выделенного узла аварийного переключения может не обеспечить достаточной избыточности. В таких случаях включается и доступно более одного (M) резервных серверов. Количество резервных серверов - это компромисс между стоимостью и требованиями к надежности.
- N-to-1 - позволяет резервному узлу аварийного переключения временно стать активным до тех пор, пока исходный узел не будет восстановлен или снова переведен в оперативный режим, в этот момент службы или экземпляры должны быть возвращены к нему, чтобы восстановить высокую доступность.
- N-to-N - комбинация активных / активных и N + M кластеров, N-N кластеров перераспределяют сервисы, экземпляры или соединения от отказавшего узла среди оставшихся активных узлов, таким образом устраняя (как и в случае с активным / активным) необходимость в «резервном» узле, но вводя потребность в дополнительной емкости на всех активных узлах.
Термины «логический хост» или «логический хост кластера» используются для описания сетевого адреса, который используется для доступа к службам, предоставляемым кластером. Этот логический идентификатор хоста не привязан к одному узлу кластера. Фактически это сетевой адрес / имя хоста, который связан с сервисом (ами), предоставляемым кластером. Если узел кластера с работающей базой данных выйдет из строя, база данных будет перезапущена на другом узле кластера.
Надежность узла
Кластеры высокой доступности обычно используют все доступные методы, чтобы сделать отдельные системы и общую инфраструктуру максимально надежными. К ним относятся:
- зеркальное отображение дисков (или избыточные массивы независимых дисков --RAID), чтобы сбой внутренних дисков не приводил к сбоям системы. Распределенное реплицированное блочное устройство является одним из примеров.
- Избыточное сетевое подключения, чтобы сбои одного кабеля, коммутатора или сетевого интерфейса не приводили к сбоям в сети.
- Избыточные подключения к сети хранения данных (SAN), чтобы сбои одного кабеля, коммутатора или интерфейса не приводили к потере подключения к хранилищу (это нарушило бы архитектуру без общего доступа ).
- Резервные входы электропитания в различных цепях, обычно оба или все защищенные блоками источника бесперебойного питания и дублированными блоками источника питания, так что один источник питания, сбои кабеля, ИБП или источника питания не приводят к отключению питания системы.
Эти функции помогают свести к минимуму вероятность того, что потребуется кластерное переключение между системами при отказе. В таком аварийном переключении предоставляемая услуга недоступна для хотя бы немного, поэтому меры по предотвращению аварийного переключения предпочтительны.
Стратегии аварийного переключения
Системы, которые Для устранения сбоев в распределенных вычислениях используются разные стратегии. Например, Apache Cassandra API Hector определяет три способа настройки аварийного переключения:
- Fail Fast, написанное как «FAIL_FAST», означает что попытка исправить сбой не удалась, если первый узел не может быть достигнут.
- При сбое, попробуйте один - следующий доступен, сценарий «ON_FAIL_TRY_ONE_NEXT_AVAILABLE» означает, что система пытается один хост, наиболее доступный или доступный, прежде чем сдаться.
- При неудаче, попробовать все, сценарий «ON_FAIL_TRY_ALL_AVAILABLE» означает, что система пробует все существующие, доступные узлы, прежде чем отказаться.
Реализации
Есть несколько доступны бесплатные и коммерческие решения, такие как:
См. Также
Ссылки
Дополнительная литература
- Грег Пфистер: В поисках кластеров, Прентис Холл, ISBN 0-13-899709-8
- Эван Маркус, Хэл Стерн: Чертежи для высшей Доступность: разработка отказоустойчивых распределенных систем, John Wiley Sons, ISBN 0-471-35601-8
- Чи-Вей Анг, Чен-Хонг Тхам: анализ и оптимизация обслуживания доступность в кластере высокой доступности с доступностью машины в зависимости от нагрузки, транзакции IEEE в параллельных и распределенных системах, том 18, выпуск 9 (сентябрь 2007 г.), страницы 1307-1319, ISSN 1045- 9219 [2]
Схема сети кластера высокой доступности с двумя узлами 