что такое отказоустойчивый кластер
Обзор вариантов реализации отказоустойчивых кластеров: Stratus, VMware, VMmanager Cloud
Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.
Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности.
Предисловие
В области защиты от сбоев на кластерах терминология в Интернете различается от сайта к сайту. Для того чтобы избежать путаницы, мы обозначим термины и определения, которые будут использоваться в этой статье.
На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.
Continuous availability / непрерывная доступность
Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.
Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности — vSphere от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.
В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:
Мы не стали расписывать конкретные конфигурации нод: состав комплектующих в серверах всегда зависит от задач кластера. Сетевое оборудование описывать также смысла не имеет: во всех случаях набор будет одинаковым. Поэтому в данной статье мы решили считать только то, что точно будет различаться: стоимость лицензий.
Стоит упомянуть и о тех продуктах, разработка которых остановилась.
Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.
Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.
Первый — Kemari, продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.
Второй — Micro Checkpointing, основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.
Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.
Итак, практика показывает, что несмотря на преимущества систем непрерывной доступности, есть немало трудностей при внедрении и эксплуатации таких решений. Однако существуют ситуации, когда отказоустойчивость требуется, но нет жёстких требований к непрерывности сервиса. В таких случаях можно применить кластеры высокой доступности, КВД.
High availability / высокая доступность
В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.
В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.
Таким образом, кластер высокой доступности делится на два подкластера:
VMmanager Cloud
Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.
В упрощённой форме алгоритм такой:
Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.
Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.
FirstByte
Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:
Отличительные черты кластера:
Данная конфигурация подходит для хостинга сайтов с высокой посещаемостью, для размещения игровых серверов и баз данных с нагрузкой от средней до высокой.
FirstVDS
Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.
К использованию VMmanager Cloud компания пришла из следующих соображений:
В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.
Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.
Эпилог
Подведём итог статьи. Если каждая секунда простоя сервиса приносит значительные убытки — не обойтись без кластера непрерывной доступности.
Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.
Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости — избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать — резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя.
Если вы решили, что для ваших задач больше подходит схема высокой доступности и выбрали VMmanager Cloud как инструмент для её реализации, к вашим услугам инструкция по установке и документация, которая поможет подробно ознакомиться с системой. Желаем вам бесперебойной работы!
P. S. Если у вас в организации есть аппаратные CA-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно 🙂
Отказоустойчивый кластер для балансировки нагрузки
Поговорим о горизонтальном масштабировании. Допустим, ваш проект вырос до размеров, когда один сервер не справляется с нагрузкой, а возможностей для вертикального роста ресурсов уже нет.
В этом случае дальнейшее развитие инфраструктуры проекта обычно происходит за счет увеличения числа однотипных серверов с распределением нагрузки между ними. Такой подход не только позволяет решить проблему с ресурсами, но и добавляет надежности проекту — при выходе из строя одного или нескольких компонентов его работоспособность в целом не будет нарушена.
Большую роль в этой схеме играет балансировщик — система, которая занимается распределением запросов/трафика. На этапе ее проектирования важно предусмотреть следующие ключевые требования:
Фактически, это описание кластера, узлами которого являются серверы-балансеры.
В этой статье мы хотим поделиться рецептом подобного кластера, простого и неприхотливого к ресурсам, концепцию которого успешно применяем в собственной инфраструктуре для балансировки запросов к серверам нашей панели управления, внутреннему DNS серверу, кластеру Galera и разнообразными микросервисам.
Договоримся о терминах:
— Серверы, входящие в состав кластера, будем называть узлами или балансерами.
— Конечными серверами будем называть хосты, на которые проксируется трафик через кластер.
— Виртуальным IP будем называть адрес, “плавающий” между всеми узлами, и на который должны указывать имена сервисов в DNS.
Что потребуется:
— Для настройки кластера потребуется как минимум два сервера (или вирт.машины) с двумя сетевыми интерфейсами на каждом.
— Первый интерфейс будет использоваться для связи с внешним миром. Здесь будут настроены реальный и виртуальный IP адреса.
— Второй интерфейс будет использоваться под служебный трафик, для общения узлов друг с другом. Здесь будет настроен адрес из приватной (“серой”) сети 172.16.0.0/24.
Вторые интерфейсы каждого из узлов должны находиться в одном сегменте сети.
Используемые технологии:
VRRP, Virtual Router Redundancy Protocol — в контексте этой статьи, реализация «плавающего» между узлами кластера виртуального IP адреса. В один момент времени такой адрес может быть поднят на каком-то одном узле, именуемом MASTER. Второй узел называется BACKUP. Оба узла постоянно обмениваются специальными heartbeat сообщениями. Получение или неполучение таких сообщений в рамках заданных промежутков дает основания для переназначения виртуального IP на “живой” сервер. Более подробно о протоколе можно прочитать здесь.
LVS, Linux Virtual Server — механизм балансировки на транспортном/сеансовом уровне, встроенный в ядро Linux в виде модуля IPVS. Хорошее описание возможностей LVS можно найти здесь и здесь.
Суть работы сводится к указанию того, что есть определенная пара “IP + порт” и она является виртуальным сервером. Для этой пары назначаются адреса реальных серверов, ответственных за обработку запросов, задается алгоритм балансировки, а также режим перенаправления запросов.
В нашей системе мы будем использовать Nginx как промежуточное звено между LVS и конечными серверами, на которые нужно проксировать трафик. Nginx будет присутствовать на каждом узле.
Для настроек VRRP и взаимодействия с IPVS будем использовать демон Keepalived, написанный в рамках проекта Linux Virtual Server.
КОНЦЕПЦИЯ
Система будет представлять собой связку из двух независимых друг от друга равнозначных узлов-балансеров, объединенных в кластер средствами технологии LVS и протокола VRRP.
Точкой входа для трафика будет являться виртуальный IP адрес, поднятый либо на одном, либо на втором узле.
Поступающие запросы LVS перенаправляет к одному из запущенных экземпляров Nginx — локальному или на соседнем узле. Такой подход позволяет равномерно размазывать запросы между всеми узлами кластера, т.е. более оптимально использовать ресурсы каждого балансера.
Работа Nginx заключается в проксировании запросов на конечные сервера. Начиная с версии 1.9.13 доступны функции проксирования на уровне транспортных протоколов tcp и udp.
Каждый vhost/stream будет настроен принимать запросы как через служебный интерфейс с соседнего балансера так и поступающие на виртуальный IP. Причем даже в том случае, если виртуальный IP адрес физически не поднят на данном балансере (Keepalived назначил серверу роль BACKUP).
Таким образом, схема хождения трафика в зависимости от состояния балансера (MASTER или BACKUP) выглядит так:
РЕАЛИЗАЦИЯ:
В качестве операционной системы будем использовать Debian Jessie с подключенными backports репозиториями.
Установим на каждый узел-балансер пакеты с необходимым для работы кластера ПО и сделаем несколько общесистемных настроек:
На интерфейсе eth1 настроим адреса из серой сети 172.16.0.0/24 :
Виртуальный IP адрес прописывать на интерфейсе eth0 не нужно. Это сделает Keepalived.
В файл /etc/sysctl.d/local.conf добавим следующие директивы:
Первая включает возможность слушать IP, которые не подняты локально (это нужно для работы Nginx). Вторая включает автоматическую защиту от DDoS на уровне балансировщика IPVS (при нехватке памяти под таблицу сессий начнётся автоматическое вычищение некоторых записей). Третья увеличивает размер conntrack таблицы.
В /etc/modules включаем загрузку модуля IPVS при старте системы:
Параметр conn_tab_bits определяет размер таблицы с соединениями. Его значение является степенью двойки. Максимально допустимое значение — 20.
Кстати, если модуль не будет загружен до старта Keepalived, последний начинает сегфолтиться.
Теперь перезагрузим оба узла-балансера. Так мы убедимся, что при старте вся конфигурация корректно поднимется.
Общие настройки выполнены. Дальнейшие действия будем выполнять в контексте двух задач:
Вводные данные:
Начнем с конфигурации Nginx.
Добавим описание секции stream в /etc/nginx/nginx.conf :
И создадим соответствующий каталог:
Настройки для веб-серверов добавим в файл /etc/nginx/sites-enabled/web_servers.conf
Настройки для DNS-серверов добавим в файл /etc/nginx/stream-enabled/dns_servers.conf
Далее остается сконфигурировать Keepalived (VRRP + LVS). Это немного сложнее, поскольку нам потребуется написать специальный скрипт, который будет запускаться при переходе узла-балансера между состояниями MASTER/BACKUP.
При переходе в состояние MASTER, скрипт удаляет это правило.
Настройки LVS для группы веб-серверов:
Настройки LVS для группы DNS-серверов:
В завершении перезагрузим конфигурацию Nginx и Keepalived:
ТЕСТИРОВАНИЕ:
Посмотрим как балансировщик распределяет запросы к конечным серверам. Для этого на каждом из веб-серверов создадим index.php с каким-нибудь простым содержимым:
И сделаем несколько запросов по http к виртуальному IP 192.168.0.100 :
Если в процессе выполнения этого цикла посмотреть на статистику работы LVS (на MASTER узле), то мы можем увидеть следующую картину:
Здесь видно как происходит распределение запросов между узлами кластера: есть два активных соединения, которые обрабатываются в данный момент и 6 уже обработанных соединений.
Статистику по все соединениям, проходящим через LVS, можно посмотреть так:
Здесь, соответственно, видим то же самое: 2 активных и 6 неактивный соединений.
ПОСЛЕСЛОВИЕ:
Предложенная нами конфигурация может послужить отправным пунктом для проектирования частного решения под конкретный проект со своими требованиями и особенностями.
Если у вас возникли вопросы по статье или что-то показалось спорным — пожалуйста, оставляйте свои комментарии, будем рады обсудить.
Отказоустойчивая кластеризация Windows Server с SQL Server
Отказоустойчивый кластер Windows Server (WSFC) представляет собой группу независимых серверов, совместная работа которых позволяет повысить доступность приложений и служб. SQL Server поддержка экземпляров отказоустойчивого кластера Группы доступности AlwaysOn и SQL Server осуществляется с использованием служб и возможностей WSFC.
Термины и определения
Отказоустойчивый кластер Windows Server (WSFC) — это группа независимых серверов, совместная работа которых позволяет повысить доступность приложений и служб.
Узел
Сервер, который является членом WSFC.
Ресурс кластера
Физическая или логическая сущность, которая может принадлежать узлу, которую можно переводить в режимы «в сети» и «вне сети», перемещать между узлами и которой можно управлять как объектом кластера. Ресурс кластера может принадлежать одновременно только одному узлу.
Роль
Коллекция ресурсов кластера, управляемая как единый объект кластера и предоставляющая определенные функциональные возможности. Для SQL Server ролью будет группа доступности AlwaysOn или экземпляр отказоустойчивого кластера AlwaysOn. Роль содержит все ресурсы кластера, необходимые для роли группы доступности или экземпляра отказоустойчивого кластера. Отработка отказа и восстановление размещения всегда выполняются в контексте ролей. Роль экземпляра отказоустойчивого кластера содержит ресурс IP-адреса, ресурс сетевого имени и ресурсы SQL Server. Роль группы доступности содержит ресурс группы доступности, а также, если настроен прослушиватель, ресурсы сетевого имени и IP-адреса.
Ресурс сетевого имени
Имя логического сервера, которое управляется как ресурс кластера. Ресурс сетевого имени должен использоваться с ресурсом IP-адреса. Для этих элементов могут требоваться объекты в доменных службах Active Directory или в службе доменных имен (DNS).
Зависимость ресурсов
Ресурс, от которого зависит другой ресурс. Если ресурс А зависит от ресурса Б, то Б является зависимостью А. Ресурс A невозможно будет запустить, если отсутствует ресурс Б.
Предпочитаемый владелец
Предпочтительный узел для запуска группы ресурсов. Каждая группа ресурсов связана со списком предпочитаемых владельцев, отсортированных в порядке предпочтения. Во время автоматического перехода на другой ресурс группа ресурсов перемещается на следующий предпочтительный узел в списке.
Возможный владелец
Дополнительный узел, на котором может запускаться ресурс. Каждая группа ресурсов связана со списком возможных владельцев. Отработка отказа ролей может выполняться только на узлы из списка возможных владельцев.
Режим кворума
Конфигурация кворума в отказоустойчивом кластере, определяющая количество сбоев узлов, которое может выдержать кластер.
Обязательный кворум
Процесс запуска кластера несмотря на то, что на связи недостаточное количество элементов для кворума.
Обзор отказоустойчивого кластера Windows Server
Отказоустойчивая кластеризация Windows Server предусматривает инфраструктурные компоненты, поддерживающие сценарии высокого уровня доступности и аварийного восстановления для таких размещенных серверных приложений, как Microsoft SQL Server и Microsoft Exchange. При отказе узла кластера или службы все службы, которые размещались на этом узле, могут автоматически или вручную переноситься на другой доступный узел в рамках процесса под названием отработка отказа.
Узлы в кластере WSFC за счет совместной работы обеспечивают следующие типы возможностей:
Распределенные метаданные и уведомления. Метаданные служб и размещенных приложений WSFC хранятся на каждом узле кластера. Среди этих метаданных не только параметры размещенных приложений, но также конфигурация и состояние WSFC. Изменения в метаданных или состоянии узла автоматически распространяются на другие узлы кластера WSFC.
Управление ресурсами. Отдельные узлы в кластере WSFC могут предоставлять физические ресурсы, например подключаемое напрямую хранилище, сетевые интерфейсы и доступ к общему дисковому хранилищу. Размещенные приложения регистрируют себя как ресурсы кластера и могут настраивать запуск и зависимости от исправности других ресурсов.
Мониторинг работоспособности. Определение исправности основного узла и исправности между узлами осуществляется за счет сочетания сетевых соединений по типу тактовых импульсов и мониторинга ресурсов. Общее состояние работоспособности кластера WSFC определяется голосами кворума узлов в кластере.
Координация отработки отказа. Каждый ресурс настроен для размещения на основном узле, и каждый можно автоматически или вручную переносить на один или несколько второстепенных узлов. Политика отработки отказа в зависимости от исправности управляет автоматическим переносом владения ресурсами между узлами. Узлы и размещенные приложения получают уведомления об отработке отказа, что позволяет им выполнить соответствующие действия.
Дополнительные сведения см. в статье Failover Clustering Overview — Windows Server(Обзор отказоустойчивой кластеризации — Windows Server).
Технологии SQL Server AlwaysOn и WSFC
SQL Server AlwaysOn — это решение высокого уровня доступности и аварийного восстановления с использованием WSFC. Компоненты AlwaysOn представляют собой интегрированные, гибкие решения, повышающие доступность приложений, окупаемость вложений в оборудование и упрощающее развертывание систем высокого уровня доступности и управление ими.
Экземпляры Группы доступности AlwaysOn и экземпляры отказоустойчивого кластера AlwaysOn используют технологию платформы WSFC и регистрируют компоненты в качестве ресурсов кластера WSFC. Связанные ресурсы объединяются в роль, которую можно сделать зависимой от других ресурсов кластера WSFC. Затем кластер WSFC сможет выявлять необходимость в перезапуске экземпляра SQL Server (и сигнализировать об этой необходимости), а также автоматически выполнять отработку отказа с переходом на другой серверный узел в кластере WSFC.
ВАЖНО! Чтобы воспользоваться всеми возможностями технологий SQL Server AlwaysOn, вам следует выполнить несколько связанных с WSFC предварительных требований.
Высокий уровень доступности на уровне экземпляра с помощью экземпляров отказоустойчивого кластера AlwaysOn
Экземпляр отказоустойчивого кластера AlwaysOn представляет собой экземпляр SQL Server, установленный на нескольких узлах в кластере WSFC. Этот тип экземпляра зависит от ресурсов для хранения и имени виртуальной сети. Хранилище может использовать общее дисковое пространство на базе Fibre Channel, iSCSI, FCoE или SAS либо локально подключенное хранилище на основе локальных дисковых пространств (S2D). Ресурс имени виртуальной сети зависит от одного или нескольких виртуальных IP-адресов, которые расположены в разных подсетях. Служба SQL Server и служба агента SQL Server также являются ресурсами, и обе они зависят от ресурсов хранилища и имени виртуальной сети.
В случае отработки отказа служба WSFC переносит владение ресурсов экземпляра на указанный узел отработки отказа. Затем экземпляр SQL Server перезапускается на узле отработки отказа и выполняется обычное восстановление баз данных. В любой момент времени FCI и базовые ресурсы могут размещаться только на одном узле в кластере.
ПРИМЕЧАНИЕ. Экземпляру отказоустойчивого кластера AlwaysOn требуется симметричное общее дисковое хранилище, например сеть хранения данных (SAN) или общая папка SMB. Тома общего дискового хранилища должны быть доступны всем потенциальным узлам отработки отказа в кластере WSFC.
Высокий уровень доступности на уровне баз данных с Группы доступности AlwaysOn
Группа доступности AlwaysOn — это одна или несколько пользовательских баз данных, для которых отработка отказа выполняется одновременно. Группа доступности состоит из первичной реплики доступности и от одной до четырех вторичных реплик, которые поддерживаются за счет перемещения данных на основании журнала SQL Server для обеспечения защиты данных, не требующей общего хранилища. Каждая реплика размещается в экземпляре SQL Server в отдельном узле кластера WSFC. Группа доступности и соответствующее имя виртуальной сети регистрируются как ресурсы в кластере WSFC.
При отработке отказа вместо переноса владения общих физических ресурсов на другой узел WSFC используется для перенастройки вторичной реплики на другом экземпляре SQL Server в первичную реплику группы доступности. Затем ресурс виртуального сетевого имени группы доступности переводится на этот экземпляр.
ПРИМЕЧАНИЕ. Группы доступности AlwaysOn не требует развертывать экземпляр отказоустойчивого кластера или использовать симметричное общее хранилище (SAN или SMB).
Экземпляр отказоустойчивого кластера (FCI) может использоваться совместно с группой доступности для повышения доступности реплики доступности. Однако во избежание соперничества в кластере WSFC автоматический переход на другой ресурс группы доступности не поддерживается для реплики доступности, размещенной в FCI.
Мониторинг исправности WSFC и отработка отказа
Высокий уровень доступности для решения AlwaysOn достигается за счет упреждающего мониторинга работоспособности физических и логических ресурсов кластера WSFC, а также за счет автоматического перехода на другой ресурс с переходом на дублирующее оборудование и его перенастройкой. Системный администратор также может запустить переход на другой ресурс вручную для группы доступности или экземпляра SQL Server для перехода с одного узла на другой.
Политики отработки отказа для узлов, экземпляров отказоустойчивого кластера и групп доступности
Политика отработки отказа настраивается на уровне узла кластера WSFC, экземпляра отказоустойчивого кластера SQL Server и группы доступности. Эта политика на основе серьезности, продолжительности и частоты неисправного состояния ресурса кластера и времени отклика узла может включать перезапуск службы или автоматический переход на другой ресурс с переходом с одного узла на другой либо включать перевод первичной реплики группы доступности с одного экземпляра SQL Server на другой.
Определение исправности ресурсов WSFC
Все ресурсы в кластере WSFC могут сообщать о своем состоянии и работоспособности периодически или по запросу. Об отказе ресурса могут говорить различные обстоятельства, например неисправность электропитания, ошибки дисков или памяти, ошибки в сети, неотвечающие службы.
Ресурсы кластера WSFC, например сети, хранилища и службы, можно делать зависимыми друг от друга. Совокупная исправность ресурса определяется путем последовательного суммирования его работоспособности с исправностью каждого из зависимых ресурсов.
Определение исправности между узлами WSFC и определение голосов в кворуме
Все узлы в кластере WSFC участвуют в периодической передаче пульса, сообщающего состояние работоспособности узла другим узлам. Неотвечающие узлы считаются неисправными.
Кворум — это механизм, позволяющий обеспечивать работоспособность кластера WSFC путем проверки наличия достаточного количества ресурсов в нем. Если кластер WSFC имеет достаточно голосов, он работоспособен и может обеспечивать отказоустойчивость на уровне узлов.
Режим кворума настраивается в кластере WSFC, который определяет методику голосования кворума, а также момент выполнения автоматического перехода на другой ресурс или перевода кластера в режим «вне сети».
СОВЕТ. Рекомендуется, чтобы число голосов кворума в кластере WSFC всегда было нечетным. По соображениям голосования кворума нет необходимости устанавливать SQL Server на всех узлах в кластере. Дополнительный сервер может выступать в качестве члена кворума, либо модель кворума WSFC можно настроить для использования удаленной общей папки в качестве решающего голоса.
Аварийное восстановление через принудительный кворум
В зависимости от принятых методов работы и конфигурации кластера WSFC можно использовать как автоматический, так и ручной переход на другой ресурс. При этом решение SQL Server AlwaysOn остается всегда надежным и отказоустойчивым. Однако если кворуму узлов с правом голоса в кластере WSFC не удается связаться друг с другом либо если кластеру WSFC по другим причинам не удается проверить работоспособность, то кластер WSFC может перейти в автономный режим.
При переходе кластера WSFC в автономный режим из-за неожиданной аварии или по причине постоянно возникающего сбоя в работе оборудования или ошибки связи требуется вмешательство администратора для принудительного создания кворума и переключения работоспособных кластеров обратно в режим «в сети» в неотказоустойчивой конфигурации.
После этого будет необходимо также предпринять ряд действий по перенастройке кластера WSFC, восстановлению затронутых реплик баз данных и повторному созданию кворума.
Связь компонентов SQL Server AlwaysOn с WSFC
Между функциями и компонентами SQL Server AlwaysOn и WSFC существуют связи нескольких уровней.
Узлы являются членами кластера WSFC.
Метаданные и состояние конфигурации WSFC для всех узлов сохраняются на каждом узле. Каждый сервер может предоставлять тома асимметричного хранения или общего хранения (SAN) для пользовательских и системных баз данных. Каждый сервер имеет по крайней мере один физический сетевой интерфейс в одной или нескольких IP-подсетях.
Кластер WSFC контролирует работоспособность группы серверов и управляет их конфигурацией.
Механизмы WSFC распространяют изменения в метаданных и состоянии конфигурации WSFC во всех узлах кластера WSFC. Если используется диск-свидетель, метаданные также хранятся на нем. По умолчанию каждый узел кластера WSFC имеет голос в кворуме, а ресурс-свидетель используется, если он необходим и настроен.
Группы доступности AlwaysOn — это подразделы кластера WSFC.
При удалении и повторном создании кластера WSFC необходимо отключить и повторно включить функцию Группы доступности AlwaysOn на каждом экземпляре сервера, на котором была включена функция Группы доступности AlwaysOn в исходном кластере WSFC. Дополнительные сведения см. в разделе Включение и отключение групп доступности AlwaysOn (SQL Server).