Бөлісу құралы:


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

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

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

Общие сведения о кластерах HPE Serviceguard см. в разделе "Кластеры 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 2025 (17.x), 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 при создании виртуальной машины.

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

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

Схема, на которой показана синхронизация данных пользователей и данных конфигурации первичной реплики с вторичной репликой. Только реплика конфигурации синхронизирует только данные конфигурации.

  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>'
);

В предыдущем примере замените <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 — этот стандартный порт, используемый для конечной точки зеркального отображения базы данных, но его можно изменить на любой доступный порт.

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

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, которую вы добавите в группу доступности.

    CREATE DATABASE [db1];
    GO
    
  2. Переключение базы данных на модель полного восстановления. Для всех баз данных в группе доступности требуется полная модель восстановления.

    ALTER DATABASE [db1]
    SET RECOVERY FULL;
    
  3. Создайте резервную копию базы данных. Перед добавлением в группу доступности базе данных требуется хотя бы одна полная резервная копия.

    BACKUP DATABASE [db1]
    TO DISK = N'/var/opt/mssql/data/db1.bak';
    
  4. Задайте для базы данных полную модель восстановления.

    ALTER DATABASE [db1]
    SET RECOVERY FULL;
    
  5. Резервное копирование базы данных на диск.

    BACKUP DATABASE [db1]
    TO DISK = N'/var/opt/mssql/data/db1.bak';
    
  6. Добавьте базу данных db1 в группу доступности.

    ALTER AVAILABILITY GROUP [ag1]
    ADD DATABASE [db1];
    

После выполнения предыдущих шагов вы увидите группу доступности 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.
    Тип Внутренняя
    Артикул «Базовый» или «Стандартный»
    Виртуальная сеть Виртуальная сеть, используемая для реплик виртуальной машины
    Подсеть Подсеть, в которой размещаются экземпляры 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, который вам понадобится для развертывания AG в кластере Serviceguard.

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

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

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

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

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

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