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

Область применения: SQL Server — Linux

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

Общие сведения о кластерах HPE 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)

• Установка SQL Server на Red Hat
• Сервис

SUSE Linux Enterprise Server (SLES)

• Установка SQL Server в SLES
• Сервис

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

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

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

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

• Установите Serviceguard для Linux на двух узлах. См. раздел Install_serviceguard_using_cminstaller.
• Установите сервер кворума Serviceguard на третьем узле. См. раздел Install_QS_from_the_ISO.

После завершения установки кластера 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.

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

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

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;

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

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

• Группы доступности в Linux