Настройка кластера Ubuntu для ресурса группы доступности

Этот документ описывает, как создать кластер с тремя узлами в Ubuntu 20.04 и добавить в него ранее созданную группу доступности в качестве ресурса. Для обеспечения высокого уровня доступности группе доступности в Linux требуется три узла — см. статью Высокий уровень доступности и защита данных для конфигураций групп доступности.

На этом этапе интеграция SQL Server с Pacemaker в Linux реализована не на таком уровне, как с WSFC в Windows. Внутри SQL сведения о наличии кластера отсутствуют, вся оркестрация осуществляется снаружи, а сама служба управляется Pacemaker как автономный экземпляр. Кроме того, имя виртуальной сети относится только к WSFC. В Pacemaker его эквивалент отсутствует. Динамические административные представления Always On, запрашивающие сведения о кластере, возвращают пустые строки. Вы по-прежнему можете создать прослушиватель, чтобы использовать его для прозрачного переподключения после отработки отказа, но требуется вручную зарегистрировать имя прослушивателя на DNS-сервере с IP, использованным для создания ресурса виртуального IP-адреса (как описано в следующих разделах).

В следующих разделах описаны действия по настройке решения отказоустойчивого кластера.

Схема действий

Действия по созданию группы доступности на серверах Linux для обеспечения высокой доступности отличаются от действий, выполняемых в отказоустойчивом кластере Windows Server. Ниже описывается общий порядок действий.

Настройте диспетчер ресурсов кластера, например Pacemaker. Эти инструкции приведены в этом документе.

Способ настройки диспетчера ресурсов кластера зависит от конкретного дистрибутива Linux.

Для обеспечения высокого уровня доступности в рабочих средах требуется агент ограждения, например STONITH. В примерах в этой документации агенты ограждения не используются. Примеры приводятся только для тестирования и проверки.

Кластер Linux использует ограждение для возврата кластера в известное состояние. Способ настройки ограждения зависит от дистрибутива и среды. В настоящее время ограждение недоступно в некоторых облачных средах. Дополнительные сведения см. в статье о политиках поддержки для кластеров RHEL с высоким уровнем доступности на платформах виртуализации.

Ограждение обычно реализуется в операционной системе и зависит от среды. Инструкции по установке ограждений см. в документации распространителя операционной системы.

Установка и настройка Pacemaker в каждом узле кластера

Откройте порты брандмауэра на всех узлах. Откройте порт для службы высокой доступности Pacemaker, экземпляра SQL Server и конечной точки группы доступности. TCP-порт по умолчанию для сервера, где выполняется SQL Server, имеет значение 1433.

Кроме того, можно просто отключить брандмауэр.

Установите пакеты Pacemaker. Выполните следующие команды на всех узлах.

Задайте пароль для пользователя по умолчанию, который создается при установке пакетов Pacemaker и Corosync. Используйте на всех узлах один и тот же пароль.

Включение и запуск службы pcsd и Pacemaker

Следующая команда включает и запускает службу pcsd и Pacemaker. Выполните ее на всех узлах. Это позволяет узлам повторно подключаться к кластеру после перезагрузки.

Команда включения Pacemaker может завершиться с ошибкой "pacemaker Default-Start contains no runlevels, aborting" (pacemaker Default-Start не содержит уровни выполнения, прерывание). Она безвредна и позволяет продолжить настройку кластера.

Создание кластера

Удалите любые существующие конфигурации кластера со всех узлов.

Команда sudo apt-get install pcs одновременно устанавливает pacemaker, corosync и pcs и запускает все 3 эти службы. При запуске corosync создается файл шаблона /etc/cluster/corosync.conf. Для успешного выполнения дальнейших действий этот файл должен отсутствовать, поэтому можно остановить выполнение pacemaker/corosync и удалить /etc/cluster/corosync.conf, тогда дальнейшие действия пройдут успешно. Команда pcs cluster destroy делает то же самое, и вы можете использовать ее в качестве средства однократной начальной настройки кластера.

Следующая команда удаляет все существующие файлы конфигурации кластера и останавливает все службы кластера. Это приводит к окончательному уничтожению кластера. Запустите ее в качестве первого шага в подготовительной среде. Обратите внимание, что команда pcs cluster destroy отключает службу pacemaker, которую требуется снова включить. Выполните на всех узлах следующую команду.

Команда уничтожает все существующие ресурсы кластера.

Из-за известной проблемы, изучением которой уже занимается поставщик услуг кластеризации, при запуске кластера (pcs cluster start) возникает указанная ниже ошибка. Это связано с тем, что файл журнала, который настроен в /etc/corosync/corosync.conf и создается при выполнении команды установки кластера, является неверным. Чтобы обойти эту ошибку, измените файл журнала на /var/log/corosync/corosync.log. Кроме того, можно создать файл /var/log/cluster/corosync.log.

Указанная ниже команда создает кластер с тремя узлами. Перед выполнением данного сценария замените значения между < . > . Выполните следующую команду на первичном узле.

В текущей реализации агента ресурсов SQL Server имя узла должно соответствовать свойству ServerName экземпляра. Например, если имя узла — node1, убедитесь, что SERVERPROPERTY ("ServerName") возвращает node1 в экземпляре SQL Server. В случае несоответствия реплики переходят в состояние разрешения после создания ресурса Pacemaker.

Сценарий, в котором это правило важно, заключается в использовании полных доменных имен. Например, если вы используете node1.yourdomain.com в качестве имени узла во время установки кластера, убедитесь, что SERVERPROPERTY ("ServerName") возвращает node1.yourdomain.com, а не только node1. Возможные обходные пути для решения этой проблемы:

• Переименуйте имя узла в FQDN и используйте хранимые процедуры sp_dropserver и sp_addserver , чтобы убедиться, что метаданные в SQL Server соответствуют изменениям.
• Используйте параметр addr в команде pcs cluster auth , чтобы сопоставить имя узла со значением SERVERPROPERTY ("ServerName") и использовать статический IP-адрес в качестве адреса узла.

Если кластер был настроен ранее на тех же узлах, используйте параметр --force при выполнении команды pcs cluster setup. Обратите внимание, что это эквивалентно команде pcs cluster destroy. Службу Pacemaker необходимо включить повторно с помощью команды sudo systemctl enable pacemaker.

Настройка ограждения (STONITH)

Поставщики кластера Pacemaker требуют, чтобы STONITH был включен, а устройство ограждения настроено для поддерживаемой установки кластера. Если диспетчер ресурсов кластера не может определить состояние узла или ресурса в нем, для перевода кластера в известное состояние используется ограждение. Ограждение на уровне ресурсов гарантирует отсутствие повреждений данных в случае сбоя за счет настройки ресурса. Вы можете использовать ограждение на уровне ресурсов, например с распределенным реплицируемым блочным устройством (DRBD), чтобы пометить диск в узле как устаревший при отключении канала связи. Ограждение на уровне узлов гарантирует, что в узле не выполняются никакие ресурсы. Это осуществляется путем сброса узла, а соответствующая реализация для Pacemaker называется STONITH (что дословно расшифровывается как "застрелить другой узел"). Pacemaker поддерживает множество разных устройств ограждения, например источник бесперебойного питания или карты интерфейса управления для серверов. Дополнительные сведения см. в статьях Кластеры Pacemaker с нуля и Ограждение и Stonith

Так как конфигурация ограждения на уровне узлов сильно зависит от вашей среды, мы отключим ее для этого руководства (ее можно настроить позже). Запустите следующий скрипт на первичном узле.

Отключение STONITH выполняется только в целях тестирования. Если вы планируете использовать Pacemaker в рабочей среде, следует спланировать реализацию STONITH с учетом особенностей среды и поддерживать ее в рабочем состоянии. Обратитесь к поставщику операционной системы за информацией об агентах ограждения для любого конкретного распределения.

Задание свойства кластера cluster-recheck-interval

cluster-recheck-interval указывает интервал опроса, с которым кластер проверяет наличие изменений в параметрах ресурсов, ограничениях или других параметрах кластера. Если реплика выходит из строя, кластер пытается перезапустить ее с интервалом, который связан со значениями failure-timeout и cluster-recheck-interval . Например, если для failure-timeout установлено значение 60 с, а для cluster-recheck-interval — 120 с, то повторная попытка перезапуска предпринимается с интервалом, который больше 60 с, но меньше 120 с. Мы рекомендуем установить для failure-timeout значение, равное 60 с, а для cluster-recheck-interval значение больше 60 с. Задавать для cluster-recheck-interval небольшое значение не рекомендуется.

Чтобы изменить значение свойства на 2 minutes , выполните следующую команду:

Если у вас уже есть ресурс группы доступности, управляемый кластером Pacemaker, обратите внимание, что все дистрибутивы, использующие последний доступный пакет Pacemaker 1.1.18-11.el7, вносят изменение в поведение для параметра start-failure-is-fatal cluster, когда его значение равно false. Это изменение влияет на рабочий процесс отработки отказа. В случае сбоя первичной реплики ожидается, что будет выполнена отработка отказа кластера на одну из доступных вторичных реплик. Вместо этого пользователи увидят, что кластер продолжает попытки запустить первичную реплику с ошибкой. Если первичная реплика не включается (из-за постоянного сбоя), кластер не выполняет отработку отказа на другую доступную вторичную реплику. Из-за этого изменения рекомендуемая ранее конфигурация для установки параметра start-failure-is-fatal больше не действительна, и для этого параметра нужно вернуть значение по умолчанию true . Кроме того, нужно обновить ресурс группы доступности для включения свойства failover-timeout .

Чтобы изменить значение свойства на true , выполните следующую команду:

Измените существующее свойство failure-timeout ресурса группы доступности на выполнение 60s (замените ag1 именем ресурса группы доступности).

Установка агента ресурсов SQL Server для интеграции с Pacemaker

Выполните следующие команды на всех узлах.

Создание учетных данных SQL Server для Pacemaker

На всех серверах SQL Server создайте имя для входа на сервер с помощью Pacemaker. Следующий запрос Transact-SQL создает имя для входа:

При создании группы доступности пользователю Pacemaker потребуются разрешения на изменение, управление и просмотр определения для группы доступности после ее создания, но до того, как в нее будут добавлены узлы.

На всех серверах SQL Server сохраните учетные данные для входа SQL Server.

Создание ресурса группы доступности

Чтобы создать ресурс группы доступности, используйте команду pcs resource create и задайте свойства ресурса. Приведенная ниже команда ocf:mssql:ag создает ресурс типа «основной/подчиненный» для группы доступности ag1 .

При создании ресурса и периодически после этого агент ресурсов Pacemaker автоматически задает в группе доступности значение REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT на основе ее конфигурации. Например, если группа доступности содержит три синхронные реплики, агент задаст для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT значение 1 . Дополнительную информацию и параметры конфигурации см. в разделе High Availability and Data Protection for Availability Group Configurations (Высокий уровень доступности и защита данных для конфигураций групп доступности).

Создание ресурса виртуального IP-адреса

Чтобы создать ресурс виртуального IP-адреса, выполните указанную ниже команду на одном узле. Используйте доступный статический IP-адрес из сети. Перед выполнением этого скрипта замените значения между < . > на допустимый IP-адрес.

В Pacemaker эквивалент имени виртуального сервера отсутствует. Чтобы использовать строку подключения, указывающую на строковое имя сервера, а не IP-адрес, зарегистрируйте IP-адрес ресурса и требуемое имя виртуального сервера в DNS. Для конфигураций аварийного восстановления зарегистрируйте имя и IP-адрес нужного виртуального сервера на DNS-серверах на основном сайте и сайте аварийного восстановления.

Добавление ограничения совместного размещения

Почти каждое решение в кластере Pacemaker, например выбор места запуска ресурса, принимается путем сравнения оценок. Оценки вычисляются для каждого ресурса, а диспетчер ресурсов кластера выбирает узел с наивысшей оценкой для конкретного ресурса. (Если узел имеет отрицательную оценку для ресурса, последний не может выполняться в этом узле.) Используйте ограничения для настройки решений в кластере. Ограничения имеют оценку. Если ограничение имеет оценку меньше бесконечности (INFINITY), то это только рекомендация. Оценка, равная INFINITY, указывает на обязательный характер. Чтобы убедиться, что первичная реплика и ресурс виртуального IP-адреса находятся на одном узле, определите ограничение совместного размещения с оценкой INFINITY. Чтобы добавить ограничение совместного размещения, выполните приведенную ниже команду на одном узле.

Добавление ограничения упорядочения

Ограничение совместного размещения имеет неявное ограничение упорядочения. Оно перемещает ресурс виртуального IP-адреса перед перемещением ресурса группы доступности. Последовательность событий по умолчанию:

Пользователь выполняет команду pcs resource move с узла node1 на узел node2 для первичной реплики группы доступности.

Ресурс виртуального IP-адреса останавливается на node1.

Ресурс виртуального IP-адреса запускается на node2.

На этом этапе IP-адрес временно указывает на node2, пока node2 все еще является вторичной репликой перед отработкой отказа.

Первичная реплика группы доступности на node1 понижается до вторичной.

Вторичная реплика группы доступности на node2 повышается до первичной.

Чтобы предотвратить ситуацию, когда IP-адрес временно указывает на узел с вторичной репликой перед отработкой отказа, добавьте ограничение упорядочения.

Чтобы добавить ограничение упорядочения, выполните приведенную ниже команду в одном узле.

После настройки кластера и добавления группы доступности в качестве ресурса кластера вы не можете использовать Transact-SQL для отработки отказа ресурсов группы доступности. Ресурсы кластера SQL Server в Linux не так сильно зависят от операционной системы, как если бы они находились в отказоустойчивом кластере Windows Server (WSFC). Служба SQL Server не имеет сведений о наличии кластера. Вся оркестрация осуществляется с помощью средств управления кластерами. В RHEL или Ubuntu используйте pcs .