Pacemaker для групп доступности и экземпляров отказоустойчивого кластера в Linux

Применимо к:SQL Server в Linux

Начиная с SQL Server 2017 (14.x), SQL Server поддерживается как в Linux, так и в Windows. Как и развертывания SQL Server на базе Windows, базы данных и экземпляры SQL Server должны быть высокодоступными в Linux. В этой статье рассматриваются основные сведения о Pacemaker с использованием Corosync, а также о том, как спланировать и развернуть его для конфигурации SQL Server.

Основы HA расширения/надстройки

Все поддерживаемые в настоящее время дистрибутивы содержат надстройку или расширение для обеспечения высокого уровня доступности, основанные на стеке кластеризации Pacemaker. Этот стек включает два ключевых компонента: Pacemaker и Corosync. Все компоненты, входящие в стек:

• Кардиостимулятор. Основной компонент кластеризации, который координирует вещи между кластеризованными компьютерами.
• Corosync. Платформа и набор API, предоставляющий такие вещи, как кворум, возможность перезапуска неудачных процессов и т. д.
• libQB. Предоставляет такие возможности, как ведение журнала.
• Агент ресурсов. Определенные функциональные возможности, предоставляемые для интеграции приложения с Pacemaker.
• Агент ограждения. Скрипты и функции, которые помогают изолировать узлы и справиться с ними, если у них возникли проблемы.

Это решение по-разному похоже на развертывание кластеризованных конфигураций с помощью Windows. В Windows форма доступности, называемая кластер отказоустойчивости Windows Server (WSFC), встроена в операционную систему, при этом функция, позволяющая создавать WSFC, отказоустойчивое кластерирование, по умолчанию отключена. В Windows группы доступности и функции управления доступом создаются на основе WSFC и совместно используют тесную интеграцию из-за конкретной библиотеки ресурсов, предоставляемой SQL Server. Это решение с плотной интеграцией по большому счету возможно, потому что оно полностью от одного поставщика.

Хотя Pacemaker доступен во всех поддерживаемых дистрибутивах Linux, каждое из них может настраиваться и иметь незначительно отличающиеся реализации и версии. Некоторые отличия будут показаны в инструкциях, приведенных в этой статье. Слой кластеризации с открытым исходным кодом, поэтому, несмотря на его наличие в дистрибутивах, он не интегрирован так тесно, как WSFC в Windows. Поэтому Microsoft предоставляет mssql-server-ha, чтобы SQL Server и стек Pacemaker могли обеспечить схожий, но не идентичный уровень функциональности для AG и FCI, как это реализовано в Windows.

Полную документацию по Pacemaker, включая более подробные и полные справочные сведения по RHEL и SLES, см. на следующих ресурсах:

• RHEL
• SLES
• Ubuntu

Дополнительные сведения обо всем стеке см. на официальной странице документации Pacemaker на сайте ClusterLabs.

Основные понятия и терминология Pacemaker

В этом разделе описываются общие понятия и терминология для реализации Pacemaker.

Узел

Узел — это сервер, входящий в кластер. Кластер Pacemaker изначально поддерживает до 16 узлов. Это число может быть превышено, если Corosync не работает на дополнительных узлах, но Для SQL Server требуется Corosync. Таким образом, максимальное количество узлов кластера может иметь для любой конфигурации на основе SQL Server значение 16; это ограничение Pacemaker и не имеет ничего общего с максимальными ограничениями для групп управления доступом или ЦС, введенных SQL Server.

Ресурс

Кластеры WSFC и Pacemaker имеют понятие ресурса. Ресурс — это специальная функциональная возможность, выполняемая в контексте кластера, например диск или IP-адрес. Например, под управлением Pacemaker могут быть созданы как ресурсы FCI, так и ресурсы AG. Это похоже на то, что выполняется в WSFC, где вы видите ресурс SQL Server для FCI или группы доступности при настройке группы доступности, но не идентично из-за основополагающих различий в интеграции SQL Server с Pacemaker.

Pacemaker имеет стандартные и клонированные ресурсы. Ресурсы-клоны — это объекты, которые запускаются одновременно на всех узлах. Примером может быть IP-адрес, доступный на нескольких узлах в целях балансировки нагрузки. Любой ресурс, создаваемый для экземпляра FCI, использует стандартный ресурс, так как в определенный момент времени экземпляр FCI может размещаться только на одном узле.

При создании группы доступности (AG) необходима специализированная форма клонированного ресурса, называемого ресурсом с несколькими состояниями. Хотя группа доступности имеет только одну первичную реплику, сама группа доступности работает на всех узлах, с которыми она настроена для работы, и может потенциально разрешить такие вещи, как доступ только для чтения. Так как это "активное" использование узла, ресурсы имеют концепцию двух состояний: Повышенный (ранее Главный) и Не повышенный (ранее Подчиненный). Дополнительные сведения см. в разделе "Ресурсы с несколькими состояниями: Ресурсы, имеющие несколько режимов".

Группы и наборы ресурсов

Подобно ролям в WSFC, кластер Pacemaker использует концепцию группы ресурсов. Группа ресурсов (называемая набором в SLES) представляет собой коллекцию ресурсов, которые работают вместе и могут переключаться с одного узла на другой как единый блок. Группы ресурсов не могут содержать ресурсы, настроенные как "Продвигаемые" или "Не продвигаемые", поэтому они не могут использоваться для групп доступности. Хотя группу ресурсов можно использовать для ФКК, обычно это не рекомендуется.

Ограничения

WSFC имеют различные параметры для ресурсов и такие понятия, как зависимости, которые указывают WSFC на отношения родитель/ребенок между двумя разными ресурсами. Зависимость — это просто правило, указывающее WSFC, какой ресурс должен быть переведен в сетевой режим первым.

Кластер Pacemaker не имеет понятия зависимостей, но есть ограничения. Существует три типа ограничений: совместное размещение, расположение и упорядочение.

• Ограничение на совместное размещение определяет, могут ли два ресурса выполняться на одном узле.
• Ограничение расположения сообщает кластеру Pacemaker, где ресурс может (или не может) работать.
• Ограничение упорядочения указывает кластеру Pacemaker, в каком порядке должны запускаться ресурсы.

Кворум, агенты ограждения и STONITH

Кворум в Pacemaker подобен WSFC по концепции. Цель механизма кворума кластера заключается в том, чтобы обеспечить работоспособность кластера. Как надстройки WSFC, так и надстройки высокого уровня доступности для дистрибутивов Linux имеют концепцию голосования, где каждый узел подсчитывается к кворуму. Вам нужно добиться большинства голосов, иначе в худшем случае кластер будет отключен.

В отличие от WSFC, нет следящего ресурса для работы с кворумом. Как и в WSFC, цель состоит в том, чтобы сохранить нечетное число голосов. Для групп доступности и экземпляров FCI используются разные конфигурации кворума.

WSFC мониторит состояние узлов и управляет ими при возникновении проблемы. Более поздние версии WSFCs предлагают такие функции, как помещение в карантин узла, который неправильно работает или недоступен (узел не включен, сбой сетевого обмена данными и т. д.). На стороне Linux этот тип функции предоставляется агентом ограждения. Иногда эта концепция называется ограждением. Однако эти агенты ограждения (fence agents) ориентированы на развертывание и часто предоставляются поставщиками оборудования и некоторыми поставщиками программного обеспечения, например, предоставляющими гипервизоры. Например, VMware предоставляет агент ограждения, который можно использовать для виртуальных машин Linux, виртуализованных с помощью vSphere.

Кворум и ограждение связаны с другим понятием — STONITH (Shoot the Other Node in the Head). STONITH должен иметь поддерживаемый кластер Pacemaker во всех дистрибутивах Linux. Дополнительные сведения см. в статье об ограждении в кластере высокой доступности Red Hat (RHEL).

corosync.conf

Файл corosync.conf содержит конфигурацию кластера. Он расположен в /etc/corosync. В ходе обычных повседневных операций этот файл должен всегда оставаться без изменений, если кластер настроен правильно.

Расположение журнала кластера

Расположения журналов кластеров Pacemaker зависят от дистрибутива.

• RHEL и SLES: /var/log/cluster/corosync.log
• Ubuntu: /var/log/corosync/corosync.log

Чтобы изменить расположение журнала по умолчанию, измените corosync.conf.

Планирование кластеров Pacemaker для SQL Server

В этом разделе рассматриваются важные вопросы планирования для кластера Pacemaker.

Виртуализация кластеров Pacemaker на основе Linux для SQL Server

Использование виртуальных машин для развертывания развертываний SQL Server на основе Linux для групп управления доступом и ЦС охватывается теми же правилами, что и для их Windows-коллег. Существует базовый набор правил для поддержки виртуализированных развертываний SQL Server, предоставляемых Microsoft в политике Support Microsoft SQL Server для продуктов, работающих в среде виртуализации оборудования. Различные гипервизоры, такие как Hyper-V Microsoft и ESXi VMware, могут иметь разные дисперсии поверх этого из-за различий в самих платформах.

При виртуализации групп доступности и экземпляров кластера с отказоустойчивостью (FCI) необходимо убедиться, что для узлов заданного кластера Pacemaker установлена анти-аффинность. При настройке высокой доступности в рамках конфигурации группы доступности или FCI виртуальные машины, на которых размещен SQL Server, никогда не должны работать на одном узле гипервизора. Например, если развернут двухузловой FCI, потребуется по крайней мере три гипервизорных хоста, чтобы один из VM, размещающий узел, мог переместиться в случае сбоя узла или хоста, особенно при использовании таких функций, как Live Migration или vMotion.

См. документацию по Hyper-V в разделе Использование гостевых кластеров для обеспечения высокой доступности

Сеть

В отличие от WSFC, Pacemaker не требует выделенного имени или хотя бы одного выделенного IP-адреса для самого кластера Pacemaker. Для AG и FCI требуются IP-адреса (см. документацию для каждого из них для получения дополнительных сведений), но не имена, так как ресурса сетевого имени нет. SLES разрешает настройку IP-адреса в целях администрирования, но не требуется, как показано в разделе "Создание кластера Pacemaker".

Как и для WSFC, для Pacemaker будет предпочтительной избыточная сеть, в которой отдельные сетевые карты (NIC или pNIC) имеют свои собственные IP-адреса. С точки зрения конфигурации кластера у каждого IP-адреса будет так называемый собственный круг. Тем не менее, как и в WSFCs сегодня, многие реализации виртуализированы или в общедоступном облаке, где существует только один виртуализированный сетевой адаптер (vNIC), представленный серверу. Если все pNICs и vNICs подключены к одному физическому или виртуальному коммутатору, на уровне сети не обеспечивается истинная избыточность, поэтому настройка нескольких сетевых адаптеров является скорее иллюзорной для виртуальной машины. Как правило, избыточность сети является неотъемлемой частью гипервизора для виртуализованных развертываний и, конечно же, общедоступного облака.

Одно из различий между несколькими сетевыми адаптерами с Pacemaker и WSFC заключается в том, что Pacemaker позволяет использовать несколько IP-адресов в одной подсети, тогда как WSFC этого не позволяет. Дополнительные сведения о нескольких подсетях и кластерах Linux см. в статье "Настройка групп доступности с несколькими подсетями Always On и экземпляров отказоустойчивого кластера".

Кворум и STONITH

Конфигурация кворума и требования связаны с развертываниями SQL Server, специфичными для группы доступности (AG) или FCI.

STONITH требуется для поддерживаемого кластера Pacemaker. Сведения о настройке STONITH см. в документации по дистрибутиву. Пример для SLES см. в статье об ограждении на основе хранилища. Существует также агент STONITH для VMware vCenter для решений на основе ESXI. Дополнительные сведения см. в статье Stonith Plugin Agent for VMware VM VCenter SOAP Fencing (Неофициальный).

Совместимость

В этом разделе содержатся сведения о взаимодействии кластера на основе Linux с WSFC или другими дистрибутивами Linux.

WSFC

В настоящее время нет прямого способа для совместной работы между WSFC и кластером Pacemaker. Это означает, что нет способа создать группу доступности (AG) или отказоустойчивый кластер (FCI), который работает между WSFC и Pacemaker. Однако существуют два решения для взаимодействия, оба из которых предназначены для AG. Единственный способ, как FCI может участвовать в кроссплатформенной конфигурации, это если он участвует в качестве экземпляра в одном из этих двух сценариев:

• Группа доступности с типом кластера None. Дополнительные сведения см. в документации по группам доступности Windows .
• Распределенная ГД, которая представляет собой особый тип группы доступности, позволяющий настраивать две разные ГД, каждая в качестве своей собственной группы доступности. Дополнительные сведения о распределенных группах доступности см. в документации Распределенные группы доступности.

Другие дистрибутивы Linux

В Linux все узлы кластера Pacemaker должны находиться в одном дистрибутиве. Например, это означает, что узел RHEL не может быть частью кластера Pacemaker с узлом SLES. Основная причина этого была ранее указана: дистрибутивы могут иметь разные версии и функциональные возможности, поэтому вещи не могли работать должным образом. Смешивание дистрибутивов, как и смешивание WSFC и Linux, предполагает использование None или распределенных групп доступности.

Связанный контент

• Разверните кластер Pacemaker для SQL Server на Linux
• Настройка кластера Pacemaker для групп доступности SQL Server