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