Руководство. Настройка группы доступности AlwaysOn с помощью HPE Serviceguard для Linux

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

В этом руководстве объясняется, как настроить группы доступности SQL Server с ПОМОЩЬЮ HPE Serviceguard для Linux, работающих на локальных виртуальных машинах или в Виртуальные машины на основе Azure.

Общие сведения о кластерах HPE Serviceguard см. здесь.

Примечание.

Корпорация Майкрософт поддерживает перемещение данных, группы доступности и компоненты SQL Server. Для получения поддержки, относящейся к документации по управлению кластером HPE Serviceguard и кворумом, обратитесь в HPE.

В этом руководстве рассматриваются следующие задачи:

  • Установка SQL Server на всех трех виртуальных машинах, которые будут входить в группу доступности.
  • Установка HPE Serviceguard на виртуальных машинах.
  • Создание кластера HPE Serviceguard.
  • Создание балансировщика нагрузки на портале Azure
  • Создание группы доступности и добавление в нее образца базы данных.
  • Развертывание рабочей нагрузки SQL Server в группе доступности с помощью диспетчера кластеров Serviceguard.
  • Выполнение автоматической отработки отказа и присоединение узла обратно к кластеру.

Необходимые компоненты

  • В Azure создайте три виртуальных машины на основе Linux. Чтобы создать виртуальные машины на основе Linux в Azure, следуйте указаниям, приведенным в статье Краткое руководство. Создание виртуальной машины Linux на портале Azure. При развертывании виртуальных машин обязательно используйте дистрибутивы Linux, поддерживаемые HPE Serviceguard. Вы также можете развернуть виртуальные машины локально в локальной среде.

    Пример поддерживаемого дистрибутива см. на странице HPE Serviceguard для Linux. Обратитесь в HPE для получения сведений о поддержке общедоступных облачных сред.

    Инструкции в этом руководстве проверены для использования с HPE Serviceguard для Linux. Пробную версию можно скачать с сайта HPE.

  • Файлы базы данных SQL Server в подключении логического тома (LVM) для всех трех виртуальных машин. См. краткое руководство по началу работы с Serviceguard Linux (HPE).

  • Убедитесь, что на виртуальных машинах установлена среда выполнения Java OpenJDK. Пакет SDK для IBM Java не поддерживается.

Установка SQL Server

На всех трех виртуальных машинах выполните одно из приведенных ниже действий в зависимости от дистрибутива Linux, выбранного для этого руководства, чтобы установить SQL Server и инструменты.

Red Hat Enterprise Linux (RHEL)

SUSE Linux Enterprise Server (SLES)

После выполнения этого шага на всех трех виртуальных машинах, которые будут использоваться в группе доступности, должна быть установлена служба SQL Server и инструменты.

Установка HPE Serviceguard на виртуальных машинах.

На этом шаге выполняется установка HPE Serviceguard для Linux на всех трех виртуальных машинах. В следующей таблице описывается роль каждого сервера в кластере.

Количество виртуальных машин Роль HPE Serviceguard Роль реплики группы доступности Microsoft SQL Server
1 Узлы кластера HPE Serviceguard Первичная реплика
1 или более Узел кластера HPE Serviceguard Вторичная реплика
1 Сервер кворума HPE Serviceguard Реплика, поддерживающая только конфигурацию

Примечание.

Ознакомьтесь с этим видео из HPE, в котором описывается установка и настройка кластера HPE Serviceguard с помощью пользовательского интерфейса.

Для установки Serviceguard воспользуйтесь методом cminstaller. Конкретные инструкции доступны по следующим ссылкам:

После завершения установки кластера HPE Serviceguard можно включить портал управления кластерами через TCP-порт 5522 на узле первичной реплики. Следующие шаги добавляют правило в брандмауэр, чтобы разрешить 5522. Следующая команда используется для Red Hat Enterprise Linux (RHEL). Для других дистрибутивов необходимо выполнить аналогичные команды:

sudo firewall-cmd --zone=public --add-port=5522/tcp --permanent
sudo firewall-cmd --reload

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

Следуйте инструкциям по настройке и созданию кластера HPE Serviceguard. На этом шаге вы также настроите сервер кворума.

  1. Настройте сервер кворума Serviceguard на третьем узле. См. раздел Configure_QS.
  2. Создайте и настройте кластер Serviceguard на двух других узлах. См. раздел Configure_and_create_Cluster.

Примечание.

Вы можете обойти ручную установку кластера HPE Serviceguard и кворума, добавив расширение HPE Serviceguard для Linux (SGLX) из Azure VM Marketplace при создании виртуальной машины.

Создание группы доступности и добавление образца базы данных

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

Screenshot showing how the primary replica synchronizes user data and configuration data with the secondary replica. The primary replica only synchronizes configuration data with the configuration only replica. The configuration only replica doesn't have user data replicas.

  1. Синхронная репликация пользовательских данных на вторичную реплику. Она также включает метаданные конфигурации группы доступности.

  2. Синхронная репликация метаданных конфигурации группы доступности. Он не содержит пользовательские данные.

Дополнительные сведения см. в разделе "Две синхронные реплика" и только реплика конфигурации.

Чтобы создать группу доступности, выполните следующие шаги.

  1. Включите группы доступности и перезапустите mssql-server на всех виртуальных машинах, включая только реплика конфигурации.
  2. Включение сеанса AlwaysOn_health событий (необязательно)
  3. Создание сертификата на основной виртуальной машине.
  4. Создание сертификата на дополнительных серверах
  5. Создание конечных точек зеркального отображения базы данных на репликах.
  6. Создание группы доступности.
  7. Присоединение вторичных реплик.
  8. Добавление базы данных в группу доступности

Включение групп доступности и перезапуск mssql-server

Включите группы доступности на всех узлах, на которых размещен экземпляр SQL Server. Затем перезапустите mssql-server. На всех трех узлах выполните следующий скрипт:

sudo /opt/mssql/bin/mssql-conf
set hadr.hadrenabled 1 sudo systemctl restart mssql-server

Включение сеанса AlwaysOn_health событий (необязательно)

При желании вы также можете включить расширенные события групп доступности Always On, что помогает выявлять корневые причины при устранении неполадок групп доступности. На каждом экземпляре SQL Server выполните следующую команду:

ALTER EVENT SESSION AlwaysOn_health ON SERVER WITH (STARTUP_STATE=ON);
GO

Создание сертификата на основной виртуальной машине.

Следующий сценарий Transact-SQL создает главный ключ и сертификат. Затем он создает резервную копию сертификата и защищает файл закрытым ключом. Обновите сценарий, задав надежные пароли. Подключитесь к основному экземпляру SQL Server и запустите следующий скрипт Transact-SQL:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<Master_Key_Password>';

CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';

BACKUP CERTIFICATE dbm_certificate TO FILE = '/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY
    ( FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
      ENCRYPTION BY PASSWORD = '<Private_Key_Password>' );

На этом этапе первичная реплика SQL Server имеет сертификат в файле /var/opt/mssql/data/dbm_certificate.cer и закрытый ключ в файле var/opt/mssql/data/dbm_certificate.pvk. Скопируйте эти файлы в одно и то же место на всех серверах, где будут размещаться реплики доступности. mssql Используйте пользователя или предоставьте пользователю разрешение mssql на доступ к этим файлам.

Например, на исходном сервере указанная ниже команда копирует файлы на целевой компьютер. Замените значения node2 именем узла, на котором работает вторичный экземпляр сервера SQL Server. Скопируйте сертификат на реплике, поддерживающей только конфигурацию, и выполните на этом узле приведенные ниже команды.

cd /var/opt/mssql/data
scp dbm_certificate.* root@<node2>:/var/opt/mssql/data/

Теперь на вторичных виртуальных машинах под управлением вторичного экземпляра и конфигурации только реплика SQL Server выполните следующие команды, чтобы mssql пользователь смог владеть скопированным сертификатом:

cd /var/opt/mssql/data
chown mssql:mssql dbm_certificate.*

Создание сертификата на серверах-получателях

Следующий сценарий Transact-SQL создает главный ключ и сертификат из резервной копии, созданной в первичной реплике SQL Server. Обновите сценарий, задав надежные пароли. Для расшифровки используется тот же пароль, что и при создании PVK-файла в предыдущем шаге. Чтобы создать сертификат, выполните следующий скрипт на всех серверах-получателях, кроме реплики, поддерживающей только конфигурацию:

CREATE MASTER KEY ENCRYPTION BY PASSWORD =
'<Master_Key_Password>';

CREATE CERTIFICATE dbm_certificate FROM FILE =
'/var/opt/mssql/data/dbm_certificate.cer'
WITH PRIVATE KEY ( FILE = '/var/opt/mssql/data/dbm_certificate.pvk',
DECRYPTION BY PASSWORD = '<Private_Key_Password>' );

Создание конечных точек зеркального отображения базы данных на репликах.

На первичных и вторичных реплика выполните следующие команды, чтобы создать конечные точки зеркало базы данных:

CREATE ENDPOINT [hadr_endpoint] AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING
        (
        ROLE = WITNESS,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );

ALTER ENDPOINT [hadr_endpoint] STATE = STARTED;

Примечание.

5022 — этот стандартный порт, используемый для конечной точки зеркального отображения базы данных, но его можно изменить на любой доступный порт.

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

CREATE ENDPOINT [hadr_endpoint] AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (
        ROLE = WITNESS,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );

ALTER ENDPOINT [hadr_endpoint] STATE = STARTED;

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

В основном реплика экземпляре выполните следующие команды. Эти команды создают группу доступности с именем ag1EXTERNAL cluster_type и предоставляют разрешение на создание базы данных группе доступности.

Перед выполнением следующих скриптов замените заполнители <node1>, <node2> и <node3> (для реплики, поддерживающей только конфигурацию) именами виртуальных машин, созданных на предыдущих шагах.

CREATE AVAILABILITY GROUP [ag1]
    WITH (CLUSTER_TYPE = EXTERNAL)
    FOR REPLICA ON
    N'<node1>' WITH (
        ENDPOINT_URL = N'tcp://<node1>:<5022>',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC
        ),

    N'<node2>' WITH (
        ENDPOINT_URL = N'tcp://<node2>:\<5022>',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = EXTERNAL,
        SEEDING_MODE = AUTOMATIC
        ),
    
    N'<node3>' WITH (
        ENDPOINT_URL = N'tcp://<node3>:<5022>',
        AVAILABILITY_MODE = CONFIGURATION_ONLY
        );
          
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Присоединение вторичных реплик

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

ALTER AVAILABILITY GROUP [ag1]
JOIN WITH (CLUSTER_TYPE = EXTERNAL);
GO
ALTER AVAILABILITY GROUP [ag1]
GRANT CREATE ANY DATABASE;
GO

Добавление базы данных в группу доступности

Подключение в основной реплика и выполните следующие команды T-SQL:

  1. Создайте образец базы данных с именем db1, которая будет добавлена в группу доступности.
  2. Переключение базы данных на модель полного восстановления. Все базы данных в группе доступности должны использовать модель полного восстановления.
  3. Создайте резервную копию базы данных. Перед добавлением в группу доступности базе данных требуется хотя бы одна полная резервная копия.
-- creates a database named db1
CREATE DATABASE [db1];
GO

-- set the database in full recovery model
ALTER DATABASE [db1] SET RECOVERY FULL; 
GO

-- backs up the database to disk
BACKUP DATABASE [db1]
TO DISK = N'/var/opt/mssql/data/db1.bak';
GO

-- adds the database db1 to the AG
ALTER AVAILABILITY GROUP [ag1] ADD DATABASE [db1];
GO

После успешного выполнения предыдущих шагов вы увидите созданную ag1 группу доступности, а три виртуальные машины добавляются как реплика с одним основным реплика, одним дополнительным реплика и одним реплика только для конфигурации. ag1 содержит одну базу данных.

Развертывание рабочей нагрузки группы доступности SQL Server (диспетчер кластеров HPE)

В HPE Serviceguard разверните рабочую нагрузку SQL Server в группе доступности с помощью пользовательского интерфейса диспетчера кластеров Serviceguard.

Разверните рабочую нагрузку группы доступности и активируйте высокий уровень доступности (HA), аварийное восстановление (DR) через кластер Serviceguard, используя графический пользовательский интерфейс диспетчера Serviceguard. См. раздел "Защита Microsoft SQL Server на Linux для групп доступности AlwaysOn".

Создание балансировщика нагрузки на портале Azure

Для развертываний в облаке Azure HPE Serviceguard для Linux требуется подсистема балансировки нагрузки для включения клиентских подключений с основными реплика для замены традиционных IP-адресов.

  1. В портал Azure откройте группу ресурсов, содержащую узлы кластера Serviceguard или виртуальные машины.

  2. В группе ресурсов щелкните Добавить.

  3. Найдите "подсистема балансировки нагрузки", а затем в результатах поиска выберите load Balancer , опубликованный корпорацией Майкрософт.

  4. На панели Load Balancer нажмите кнопку "Создать".

  5. Настройте подсистему балансировки нагрузки следующим образом:

    Параметр Значение
    Имя Имя подсистемы балансировки нагрузки. Например, SQLAvailabilityGroupLB.
    Тип Внутренняя
    SKU «Базовый» или «Стандартный»
    Виртуальная сеть Виртуальная сеть, используемая для реплика виртуальных машин
    Подсеть Подсеть, в которой размещаются экземпляры SQL Server
    Назначение IP-адресов Статические
    Частный IP-адрес Создание частного IP-адреса в подсети
    Подписка Выберите соответствующую подписку
    Группа ресурсов Выберите соответствующую группу ресурсов
    Местонахождение Выберите то же расположение, что и узлы SQL

Настройка серверного пула

Серверный пул — это адреса двух экземпляров, на которых настроен кластер Serviceguard.

  1. В группе ресурсов щелкните созданную подсистему балансировки нагрузки.
  2. Перейдите к Параметры > серверным пулам и нажмите кнопку "Добавить", чтобы создать внутренний пул адресов.
  3. В поле "Добавление внутреннего пула" в разделе "Имя" введите имя внутреннего пула.
  4. В разделе Сопоставлено с выберите Виртуальная машина.
  5. Выберите виртуальную машину в среде и свяжите соответствующий IP-адрес с каждым выбором.
  6. Выберите Добавить.

Создание пробы

Проба определяет, как Azure проверяет, какой узел кластера Serviceguard является основным реплика. Azure проверяет службу по IP-адресу и порту, которые вы указываете при создании пробы.

  1. На панели параметров подсистемы балансировки нагрузки выберите пробы работоспособности.

  2. На панели проб работоспособности нажмите кнопку "Добавить".

  3. Для настройки пробы используйте следующие значения:

    Параметр Значение
    Имя Имя, представляющее пробу. Например, SQLAGPrimaryReplicaProbe.
    Протокол TCP
    порт. Вы можете использовать любой доступный порт. Например, 59999.
    Интервал 5
    Пороговое значение сбоя 2
  4. Нажмите ОК.

  5. Войдите на все виртуальные машины и откройте порт пробы с помощью следующих команд:

    sudo firewall-cmd --zone=public --add-port=59999/tcp --permanent
    sudo firewall-cmd --reload
    

Azure создает пробу, а затем использует ее для тестирования узла Serviceguard, на котором выполняется основной реплика экземпляр группы доступности. Помните, что порт настроен (59999), который требуется для развертывания группы доступности в кластере Serviceguard.

Настройка правил балансировки нагрузки

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

  1. На панели параметров подсистемы балансировки нагрузки выберите правила балансировки нагрузки.

  2. На панели правил балансировки нагрузки нажмите кнопку "Добавить".

  3. Настройте правило балансировки нагрузки с помощью следующих параметров:

    Параметр Значение
    Имя Имя, представляющее правила балансировки нагрузки. Например, SQLAGPrimaryReplicaListener.
    Протокол TCP
    порт. 1433
    Внутренний порт 1433. Это значение игнорируется, так как это правило использует плавающий IP-адрес.
    Проба Используйте имя пробы, созданной для этого балансировщика нагрузки.
    Сохранение сеанса нет
    Время ожидания простоя (в минутах) 4
    Плавающий IP-адрес Включен
  4. Нажмите ОК.

  5. Azure настроит правило балансировки нагрузки. Теперь подсистема балансировки нагрузки настроена для маршрутизации трафика на узел Serviceguard, который является основным экземпляром реплика в кластере.

Запишите внешний IP-адрес подсистемы балансировки нагрузки "LbReadWriteIP", который требуется для развертывания группы доступности в кластере Serviceguard.

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

Выполнение автоматической отработки отказа и присоединение узла обратно к кластеру

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

  1. Диспетчер кластеров повышает уровень одной из вторичных реплик в группе доступности до первичной.
  2. Нерабочая первичная реплика автоматически присоединяет кластер после резервного копирования. Диспетчер кластеров повышает ее уровень до вторичной реплики.

Сведения о HPE Serviceguard см. в разделе Тестирования настройки для обеспечения готовности к отработке отказа