Группа компьютеров, работающих с минимальным временем простоя
Кластеры высокой доступности (также известные как кластеры HA , отказоустойчивые кластеры ) представляют собой группы компьютеров , которые поддерживают серверные приложения , которые могут надежно использоваться с минимальным количеством простоев . Они работают с использованием программного обеспечения высокой доступности для объединения избыточных компьютеров в группы или кластеры , которые обеспечивают непрерывное обслуживание при выходе из строя компонентов системы. Без кластеризации, если сервер, на котором запущено определенное приложение, выходит из строя, приложение будет недоступно до тех пор, пока не будет исправлен сбойный сервер. Кластеризация HA исправляет эту ситуацию, обнаруживая аппаратные/программные сбои и немедленно перезапуская приложение на другой системе без необходимости административного вмешательства, процесс, известный как отказоустойчивость . В рамках этого процесса программное обеспечение кластеризации может настраивать узел перед запуском приложения на нем. Например, может потребоваться импортировать и смонтировать соответствующие файловые системы, может потребоваться настроить сетевое оборудование, а также может потребоваться запустить некоторые вспомогательные приложения. [1]
Кластеры HA часто используются для критически важных баз данных , обмена файлами в сети, бизнес-приложений и клиентских служб, таких как веб-сайты электронной коммерции . Реализации кластеров HA пытаются встроить избыточность в кластер, чтобы исключить отдельные точки отказа, включая множественные сетевые подключения и хранилище данных, которое избыточно подключено через сети хранения данных .
Кластеры HA обычно используют частное сетевое соединение heartbeat , которое используется для мониторинга работоспособности и статуса каждого узла в кластере. Одно тонкое, но серьезное условие, которое все кластерное программное обеспечение должно уметь обрабатывать, — это split-brain , которое происходит, когда все частные соединения выходят из строя одновременно, но узлы кластера все еще работают. Если это произойдет, каждый узел в кластере может ошибочно решить, что все остальные узлы вышли из строя, и попытаться запустить службы, которые все еще работают на других узлах. Наличие дублирующих экземпляров служб может привести к повреждению данных в общем хранилище.
Кластеры HA часто также используют хранилище свидетелей кворума (локальное или облачное), чтобы избежать этого сценария. Устройство-свидетель не может быть общим для двух половин разделенного кластера, поэтому в случае, если все члены кластера не могут общаться друг с другом (например, сбой heartbeat), если член не может получить доступ к свидетелю, он не может стать активным.
Требования к дизайну приложения
Не каждое приложение может работать в среде кластера высокой доступности, и необходимые решения по проектированию должны быть приняты на ранней стадии проектирования программного обеспечения. Для работы в среде кластера высокой доступности приложение должно удовлетворять по крайней мере следующим техническим требованиям, последние два из которых имеют решающее значение для его надежной работы в кластере и являются наиболее сложными для полного удовлетворения:
Должен быть относительно простой способ запуска, остановки, принудительной остановки и проверки статуса приложения. На практике это означает, что приложение должно иметь интерфейс командной строки или скрипты для управления приложением, включая поддержку нескольких экземпляров приложения.
Приложение должно иметь возможность использовать общее хранилище ( NAS / SAN ).
Самое важное, приложение должно хранить как можно больше своего состояния в энергонезависимом общем хранилище. Не менее важна возможность перезапуска на другом узле в последнем состоянии перед отказом, используя сохраненное состояние из общего хранилища.
Приложение не должно повреждать данные в случае сбоя или перезапуска из сохраненного состояния.
Некоторые из этих ограничений можно свести к минимуму за счет использования виртуальных серверных сред, в которых сам гипервизор поддерживает кластеры и обеспечивает бесперебойную миграцию виртуальных машин (включая состояние рабочей памяти) между физическими хостами — см. Отказоустойчивые кластеры Microsoft Server 2012 и 2016.
Ключевое отличие между этим подходом и запуском приложений, поддерживающих кластер, заключается в том, что последний может справляться со сбоями серверных приложений и поддерживать живые "последовательные" обновления программного обеспечения, сохраняя при этом доступ клиента к сервису (например, к базе данных), за счет того, что один экземпляр предоставляет сервис, пока другой обновляется или ремонтируется. Для этого требуется, чтобы экземпляры кластера взаимодействовали, очищали кэши и координировали доступ к файлам во время передачи. Отказоустойчивая кластеризация относится к планированию, созданию и настройке, а также устранению неполадок.
Конфигурации узлов
Схема сети кластера высокой доступности из 2 узлов
Наиболее распространенным размером кластера высокой доступности является кластер из двух узлов, поскольку это минимум, необходимый для обеспечения избыточности, но многие кластеры состоят из гораздо большего числа узлов, иногда из десятков.
Прилагаемая диаграмма представляет собой хороший обзор классического кластера высокой доступности, с той оговоркой, что в ней не упоминается функциональность кворума/свидетеля (см. выше).
Такие конфигурации иногда можно отнести к одной из следующих моделей:
Активный/активный — Трафик, предназначенный для отказавшего узла, либо передается на существующий узел, либо балансируется по оставшимся узлам. Обычно это возможно только в том случае, если узлы используют однородную конфигурацию программного обеспечения.
Активный/пассивный — обеспечивает полностью избыточный экземпляр каждого узла, который подключается только в случае отказа соответствующего основного узла. [2] Такая конфигурация обычно требует большего количества дополнительного оборудования.
N+1 — Предоставляет один дополнительный узел, который подключается к сети, чтобы взять на себя роль отказавшего узла. В случае гетерогенной конфигурации программного обеспечения на каждом основном узле дополнительный узел должен быть универсально способен принимать на себя любую из ролей основных узлов, за которые он отвечает. Обычно это относится к кластерам, в которых одновременно работает несколько служб; в случае одной службы это вырождается в активно-пассивный.
N+M — В случаях, когда один кластер управляет многими службами, наличие только одного выделенного узла отказоустойчивости может не обеспечить достаточной избыточности. В таких случаях включается и доступно более одного (M) резервных серверов. Количество резервных серверов — это компромисс между стоимостью и требованиями к надежности.
N-to-1 — позволяет резервному узлу аварийного переключения временно стать активным, пока исходный узел не будет восстановлен или снова подключен к сети, после чего службы или экземпляры должны быть возвращены к нему для восстановления высокой доступности.
N-to-N — сочетание кластеров «активный/активный» и N+M. Кластеры N-to-N перераспределяют службы, экземпляры или соединения с вышедшего из строя узла между оставшимися активными узлами, тем самым устраняя (как и в случае с «активный/активный») необходимость в «резервном» узле, но при этом возникает необходимость в дополнительной емкости на всех активных узлах.
Термины логический хост или логический хост кластера используются для описания сетевого адреса , который используется для доступа к службам, предоставляемым кластером. Этот логический идентификатор хоста не привязан к одному узлу кластера. На самом деле это сетевой адрес/имя хоста, который связан с службой(ами), предоставляемыми кластером. Если узел кластера с работающей базой данных выходит из строя, база данных будет перезапущена на другом узле кластера.
Надежность узла
Кластеры HA обычно используют все доступные методы, чтобы сделать отдельные системы и общую инфраструктуру максимально надежными. К ним относятся:
Резервные входы электропитания в различных цепях, как правило, оба или все защищены источниками бесперебойного питания и резервными блоками питания , так что отказы одного источника питания, кабеля, ИБП или источника питания не приводят к потере питания системы.
Эти функции помогают минимизировать вероятность того, что потребуется кластеризация отказоустойчивости между системами. При таком отказоустойчивости предоставляемая услуга недоступна по крайней мере некоторое время, поэтому предпочтительны меры по предотвращению отказоустойчивости.
Стратегии отказоустойчивости
Системы, которые обрабатывают сбои в распределенных вычислениях, имеют разные стратегии для устранения сбоя. Например, Apache Cassandra API Hector определяет три способа настройки отказоустойчивости:
Fail Fast , скрипт которого обозначен как «FAIL_FAST», означает, что попытка устранения сбоя завершается неудачей, если первый узел не может быть достигнут.
В случае неудачи попробуйте один — следующий доступный , сценарий «ON_FAIL_TRY_ONE_NEXT_AVAILABLE» означает, что система пробует один хост, наиболее доступный или имеющийся в наличии, прежде чем отказаться от попытки.
При неудаче попробовать все , сценарий «ON_FAIL_TRY_ALL_AVAILABLE» означает, что система пробует все существующие доступные узлы, прежде чем отказаться от попытки.
^ ван Вугт, Сандер (2014), Кластеризация высокой доступности Pro Linux , стр.3, Apress, ISBN 978-1484200803
^ Bornschlegl, Susanne (2012). Железнодорожный компьютер 3.0: инновационный дизайн платы может произвести революцию на рынке (pdf) . MEN Mikro Elektronik . Получено 21 сентября 2015 г.
Эван Маркус, Хэл Стерн: Проекты высокой доступности: проектирование устойчивых распределенных систем , John Wiley & Sons, ISBN 0-471-35601-8
Чи-Вей Анг, Чен-Хонг Там: Анализ и оптимизация доступности сервисов в кластере высокой доступности с доступностью машин, зависящей от нагрузки , IEEE Transactions on Parallel and Distributed Systems, том 18, выпуск 9 (сентябрь 2007 г.), страницы 1307–1319, ISSN 1045–9219 [1]
