Введение
Кластеры высокой доступности (также известные как кластеры HA, failover-кластеры) — это группы компьютеров, обеспечивающих поддержку серверных приложений, которые могут надежно использоваться с минимальным временем простоя. Они функционируют за счет использования программного обеспечения высокой доступности, которое объединяет избыточные компьютеры в группы или кластеры, обеспечивая непрерывность обслуживания при сбое компонентов системы. Без кластеризации, если сервер, на котором запущено определенное приложение, выходит из строя, приложение становится недоступным до устранения неисправности сервера. Кластеризация HA решает эту проблему, обнаруживая аппаратные или программные сбои и немедленно перезапуская приложение на другом узле без вмешательства администратора, процесс, известный как переключение при отказе (failover). В рамках этого процесса программное обеспечение кластеризации может настроить узел перед запуском на нем приложения. Например, может потребоваться импортировать и смонтировать соответствующие файловые системы, настроить сетевое оборудование, а также запустить некоторые вспомогательные приложения. Кластеры HA часто используются для критически важных баз данных, организации сетевого обмена файлами, бизнес-приложений и обслуживания клиентов, таких как веб-сайты электронной коммерции. При реализации кластеров HA стремятся обеспечить избыточность, устраняя единые точки отказа, включая несколько сетевых соединений и хранилище данных, избыточно подключенное через сети хранения данных (SAN). Кластеры HA обычно используют частную сеть связи (heartbeat) для мониторинга состояния и работоспособности каждого узла в кластере. Одной из тонких, но серьезных проблем, которую должно уметь обрабатывать любое кластерное программное обеспечение, является состояние «разделенного мозга» (split brain), которое возникает, когда все частные каналы связи одновременно выходят из строя, но узлы кластера продолжают работать. В этом случае каждый узел кластера может ошибочно решить, что все остальные узлы вышли из строя, и попытаться запустить службы, которые уже запущены на других узлах. Наличие дубликатов служб может привести к повреждению данных на общем хранилище. Чтобы избежать этого сценария, кластеры HA часто также используют хранилище свидетелей кворума (локальное или облачное). Свидетельское устройство не может быть совместно использовано двумя половинами разделенного кластера, поэтому, если все члены кластера не могут взаимодействовать друг с другом (например, из-за сбоя heartbeat), узел, не имеющий доступа к свидетелю, не сможет стать активным.
High availability clusters (also known as HA clusters, fail over clusters) are groups of computers that support server applications that can be reliably utilized with a minimum amount of down time. They operate by using high availability software to harness redundant computers in groups or clusters that provide continued service when system components fail. Without clustering, if a server running a particular application crashes, the application will be unavailable until the crashed server is fixed. HA clustering remedies this situation by detecting hardware/software faults, and immediately restarting the application on another system without requiring administrative intervention, a process known as failover. As part of this process, clustering software may configure the node before starting the application on it. For example, appropriate file systems may need to be imported and mounted, network hardware may have to be configured, and some supporting applications may need to be running as well. HA clusters are often used for critical databases, file sharing on a network, business applications, and customer services such as electronic commerce websites. HA cluster implementations attempt to build redundancy into a cluster to eliminate single points of failure, including multiple network connections and data storage which is redundantly connected via storage area networks. HA clusters usually use a heartbeat private network connection which is used to monitor the health and status of each node in the cluster. One subtle but serious condition all clustering software must be able to handle is split brain, which occurs when all of the private links go down simultaneously, but the cluster nodes are still running. If that happens, each node in the cluster may mistakenly decide that every other node has gone down and attempt to start services that other nodes are still running. Having duplicate instances of services may cause data corruption on the shared storage. HA clusters often also use quorum witness storage (local or cloud) to avoid this scenario. A witness device cannot be shared between two halves of a split cluster, so in the event that all cluster members cannot communicate with each other (e. g., failed heartbeat), if a member cannot access the witness, it cannot become active.
Требования к разработке приложения
Не каждое приложение может работать в среде кластера с высокой доступностью, и необходимые решения по проектированию должны быть приняты на раннем этапе разработки программного обеспечения. Чтобы приложение работало в среде кластера с высокой доступностью, оно должно соответствовать, как минимум, следующим техническим требованиям, два последних из которых критически важны для его надежной работы в кластере и наиболее сложны в полной реализации: должен быть относительно простой способ запуска, остановки, принудительной остановки и проверки статуса приложения. На практике это означает, что приложение должно иметь интерфейс командной строки или скрипты для управления приложением, включая поддержку нескольких экземпляров. Приложение должно уметь использовать общее хранилище (NAS/SAN). Самое важное – приложение должно хранить как можно больше своего состояния в энергонезависимом общем хранилище. Не менее важно, чтобы приложение могло перезапускаться на другом узле в последнем состоянии перед сбоем, используя сохраненное состояние из общего хранилища. Приложение не должно приводить к повреждению данных при сбое или перезапуске из сохраненного состояния. Ряд этих ограничений можно смягчить, используя среды виртуальных серверов, в которых сам гипервизор поддерживает кластеры и обеспечивает бесшовную миграцию виртуальных машин (включая состояние оперативной памяти) между физическими хостами – например, Failover Clusters в Microsoft Server 2012 и 2016. Ключевое отличие этого подхода от запуска приложений, поддерживающих кластеры, заключается в том, что последние способны обрабатывать сбои серверных приложений и поддерживать обновления программного обеспечения в режиме реального времени, обеспечивая при этом доступ клиентов к сервису (например, базе данных), за счет того, что один экземпляр предоставляет сервис, пока другой обновляется или восстанавливается. Это требует от экземпляров кластера обмена данными, очистки кэшей и координации доступа к файлам при передаче управления. Организация отказоустойчивого кластера включает в себя планирование, создание, настройку и устранение неполадок.
There must be a relatively easy way to start, stop, force stop, and check the status of the application. In practical terms, this means the application must have a command line interface or scripts to control the application, including support for multiple instances of the application. The application must be able to use shared storage (NAS/SAN). Most importantly, the application must store as much of its state on non volatile shared storage as possible. Equally important is the ability to restart on another node at the last state before failure using the saved state from the shared storage. The application must not corrupt data if it crashes, or restarts from the saved state. A number of these constraints can be minimized through the use of virtual server environments, wherein the hypervisor itself is cluster aware and provides seamless migration of virtual machines (including running memory state) between physical hosts—see Microsoft Server 2012 and 2016 Failover Clusters. A key difference between this approach and running cluster aware applications is that the latter can deal with server application crashes and support live "rolling" software upgrades while maintaining client access to the service (e. g. database), by having one instance provide service while another is being upgraded or repaired. This requires the cluster instances to communicate, flush caches and coordinate file access during hand off. Failover clustering falls under planning, creating and configuring also troubleshooting.
Надежность узлов
Кластеры высокой доступности обычно используют все доступные методы для обеспечения максимальной надежности отдельных систем и общей инфраструктуры. К ним относятся:
Зеркалирование дисков (или избыточные массивы независимых дисков — RAID), чтобы отказ внутренних дисков не приводил к сбоям системы. Распределенное реплицируемое блочное устройство — один из примеров. Избыточные сетевые соединения, чтобы отказ одного кабеля, коммутатора или сетевого интерфейса не приводил к сетевым сбоям. Избыточные подключения к сети хранения данных (SAN), чтобы отказ одного кабеля, коммутатора или интерфейса не приводил к потере связи с хранилищем (что нарушило бы архитектуру "ничего не разделяется"). Избыточные входы электропитания на разных цепях, как правило, обе или все защищены источниками бесперебойного питания (ИБП), а также избыточные блоки питания, чтобы отказ одного источника питания, кабеля, ИБП или блока питания не приводил к потере питания системы. Эти функции помогают минимизировать вероятность необходимости переключения между системами в кластере. В случае такого переключения предоставляемая услуга недоступна хотя бы некоторое время, поэтому предпочтительнее принимать меры для предотвращения переключения.
Disk mirroring (or Redundant Arrays of Independent Disks—RAID) so that failure of internal disks does not result in system crashes. The Distributed Replicated Block Device is one example. Redundant network connections so that single cable, switch, or network interface failures do not result in network outages. Redundant storage area network (SAN) connections so that single cable, switch, or interface failures do not lead to loss of connectivity to the storage (this would violate shared nothing architecture). Redundant electrical power inputs on different circuits, usually both or all protected by uninterruptible power supply units, and redundant power supply units, so that single power feed, cable, UPS, or power supply failures do not lead to loss of power to the system. These features help minimize the chances that the clustering failover between systems will be required. In such a failover, the service provided is unavailable for at least a little while, so measures to avoid failover are preferred.
Стратегии перехода на более низкий уровень
Системы, обрабатывающие отказы в распределенных вычислениях, используют различные стратегии для восстановления после отказа. Например, API Apache Cassandra Hector определяет три способа настройки переключения при отказе:
"FAIL FAST" (Fail Fast, быстрый отказ) означает, что попытка устранить отказ будет прервана, если не удастся связаться с первым узлом. "ON FAIL TRY ONE NEXT AVAILABLE" (На неудачу, попробовать один следующий доступный) означает, что система попытается использовать один хост, наиболее доступный, прежде чем сдаться. "ON FAIL TRY ALL AVAILABLE" (На неудачу, попробовать все доступные) означает, что система попытается использовать все существующие доступные узлы, прежде чем сдаться.
Fail Fast, scripted as "FAIL FAST", means that the attempt to cure the failure fails if the first node cannot be reached. On Fail, Try One Next Available, scripted as "ON FAIL TRY ONE NEXT AVAILABLE", means that the system tries one host, the most accessible or available, before giving up. On Fail, Try All, scripted as "ON FAIL TRY ALL AVAILABLE", means that the system tries all existing, available nodes before giving up.