Настройка группы доступности Always On SQL Server для обеспечения высокой доступности в Linux

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

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

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

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

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

Дорожная карта

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

  1. Руководство по установке SQL Server на Linux.

    Важно!

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

  2. Создайте группу доступности. Этот шаг рассматривается в этой статье.

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

    Способ настройки диспетчера ресурсов кластера зависит от конкретного дистрибутива Linux. Инструкции по работе с дистрибутивами см. по следующим ссылкам:

    Важно!

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

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

    Сведения о SLES см. в статье о расширении для обеспечения высокой доступности SUSE Linux Enterprise.

  4. Добавьте группу доступности в качестве ресурса в кластер.

    Способ добавления группы доступности в качестве ресурса в кластере зависит от дистрибутива Linux. Инструкции по работе с дистрибутивами см. по следующим ссылкам:

Рекомендации по нескольким сетевым интерфейсам (сетевым адаптерам)

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

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

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

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

Примечание.

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

  1. Обновление имени компьютера для каждого узла.

    Каждое имя SQL Server должно отвечать следующим требованиям:

    • 15 символов или меньше;
    • уникальность в пределах сети.

    Чтобы указать имя компьютера, измените файл /etc/hostname. Следующий скрипт позволяет изменить /etc/hostname с помощью vi:

    sudo vi /etc/hostname
    
  2. Настройка файла hosts.

    Примечание.

    Если имена узлов зарегистрированы с их IP-адресами на DNS-сервере, указанные ниже действия выполнять не нужно. Убедитесь, что все узлы, которые требуется включить в конфигурацию группы доступности, могут взаимодействовать друг с другом. (Команда проверки связи с узлом должна возвращать ответ с соответствующим IP-адресом.) Кроме того, проверьте, не содержит ли файл /etc/hosts запись, которая сопоставляет IP-адрес localhost 127.0.0.1 с именем узла.

    Файл hosts на каждом сервере содержит IP-адреса и имена всех серверов, которые будут участвовать в группе доступности.

    Следующая команда возвращает IP-адрес текущего сервера:

    sudo ip addr show
    

    Обновите /etc/hosts. Следующий скрипт позволяет изменить /etc/hosts с помощью vi:

    sudo vi /etc/hosts
    

    В следующем примере показано /etc/hostsnode1 добавление для node1, node2а также node3. В этом примере node1 ссылается на сервер, на котором размещена первичная реплика, а node2 и node3 ссылаются на серверы, на которых размещены вторичные реплики.

    127.0.0.1    localhost localhost4 localhost4.localdomain4
    ::1          localhost localhost6 localhost6.localdomain6
    10.128.18.12 node1
    10.128.16.77 node2
    10.128.15.33 node3
    

Установка SQL Server

Установите SQL Server. Инструкции по установке SQL Server для различных сред см. по указанным ниже ссылкам:

Включение групп доступности Always On

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

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

Включение сеанса событий AlwaysOn_health

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

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

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

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

Служба SQL Server на Linux использует сертификаты для проверки подлинности при обмене данными между конечными точками с зеркальным отображением.

Следующий сценарий 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/

На каждом целевом сервере предоставьте пользователю 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>**'
        );

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

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

Следующий запрос Transact-SQL создает конечную точку прослушивания с именем Hadr_endpoint для группы доступности. Он запускает конечную точку и предоставляет созданному вами сертификату разрешение на подключение. Перед выполнением данного сценария замените значения между **< ... >**. При необходимости можно включить IP-адрес LISTENER_IP = (0.0.0.0). IP-адрес прослушивателя должен быть IPv4-адресом. Также можно использовать 0.0.0.0.

Обновите следующий сценарий Transact-SQL для среды на всех экземплярах SQL Server:

CREATE ENDPOINT [Hadr_endpoint]
    AS TCP (LISTENER_PORT = **<5022>**)
    FOR DATABASE_MIRRORING (
        ROLE = ALL,
        AUTHENTICATION = CERTIFICATE dbm_certificate,
        ENCRYPTION = REQUIRED ALGORITHM AES
        );

ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;

Примечание.

Если вы используете выпуск SQL Server Express на одном узле для размещения реплики, поддерживающей только конфигурацию, единственным допустимым значением для ROLE является WITNESS. Выполните следующий скрипт в выпуске SQL Server Express:

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;

TCP-порт в брандмауэре должен быть открыт для порта прослушивателя.

Важно!

Для выпуска SQL Server 2017 единственный поддерживаемый способ проверки подлинности для конечной точки с зеркальным отображением базы данных — CERTIFICATE. Параметр WINDOWS будет включен в будущем выпуске.

Дополнительные сведения см. в статье Конечная точка зеркального отображения базы данных (SQL Server).

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

В примерах этого раздела объясняется, как создать группу доступности с помощью Transact-SQL. Можно также использовать мастер создания групп доступности в SQL Server Management Studio. При создании группы доступности с помощью мастера она возвращает ошибку при присоединении реплика к группе доступности. Чтобы устранить эту проблему, предоставьте Pacemaker разрешения ALTER, CONTROL и VIEW DEFINITIONS в группе доступности на всех репликах. После предоставления разрешений на первичной реплике присоедините узлы к группе доступности с помощью мастера, но для правильного функционирования высокой доступности предоставьте разрешение на всех репликах.

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

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

Примечание.

Группы доступности могут содержать вторичные синхронные или асинхронные реплики.

Создайте группу доступности для обеспечения высокой доступности в Linux. Используйте инструкцию CREATE AVAILABILITY GROUP с CLUSTER_TYPE = EXTERNAL.

  • Группа доступности: CLUSTER_TYPE = EXTERNAL.

    Указывает, что сущность внешнего кластера управляет группой доступности. Примером сущности внешнего кластера является Pacemaker. Если тип кластера группы доступности является внешним,

  • Задайте первичные и вторичные реплика: FAILOVER_MODE = EXTERNAL

    Указывает, что реплика взаимодействует с диспетчером внешнего кластера, например Pacemaker.

Следующие сценарии Transact-SQL используются для создания группы доступности ag1 для обеспечения высокой доступности. Сценарий настраивает реплики группы доступности с параметром SEEDING_MODE = AUTOMATIC. Если этот параметр задан, SQL Server будет автоматически создавать базы данных на каждом сервере-получателе. Обновите следующий сценарий для своей среды. Замените значения <node1>, <node2> и <node3> на имена экземпляров SQL Server, где размещаются реплики. Замените значение <5022> на порт, заданный для конечной точки зеркального отображения данных. Чтобы создать группу доступности, выполните на экземпляре SQL Server, где размещена первичная реплика, следующий сценарий Transact-SQL:

Важно!

В текущей реализации агента ресурсов 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-адрес в качестве адреса узла.

Выполните только один из приведенных ниже сценариев.

Создание группы доступности с тремя синхронными реплика

Создайте группу доступности с тремя синхронными реплика:

CREATE AVAILABILITY GROUP [ag1]
      WITH (DB_FAILOVER = ON, 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 = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = EXTERNAL,
            SEEDING_MODE = AUTOMATIC
            );

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Важно!

После запуска предыдущего скрипта для создания группы доступности с тремя синхронными реплика не выполните следующий сценарий:

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

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

Важно!

Эта архитектура позволяет размещать третью реплику в любом выпуске SQL Server. Например, третью реплику можно разместить в выпуске SQL Server Express. В выпуске Express единственным допустимым типом конечной точки является WITNESS.

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. Группы доступности node1 и node2 поддерживают размещение реплик в синхронном режиме с автоматическим заполнением и автоматическим переходом на другой ресурс.

Важно!

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

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

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

Кроме того, группу доступности с CLUSTER_TYPE=EXTERNAL можно настроить с помощью SQL Server Management Studio или PowerShell.

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

Пользователю Pacemaker требуются ALTERCONTROLразрешения и VIEW DEFINITION разрешения на группу доступности для всех реплика. Чтобы предоставить разрешения, выполните следующий сценарий Transact-SQL после создания группы доступности на первичной реплике и каждой вторичной реплики сразу после их добавления в группу доступности. Перед запуском скрипта замените <pacemakerLogin> именем учетной записи пользователя Pacemaker. Если у вас нет имени входа в Pacemaker, создайте имя входа sql server для Pacemaker.

GRANT ALTER, CONTROL, VIEW DEFINITION ON AVAILABILITY GROUP::ag1 TO <pacemakerLogin>
GRANT VIEW SERVER STATE TO <pacemakerLogin>

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

ALTER AVAILABILITY GROUP [ag1] JOIN WITH (CLUSTER_TYPE = EXTERNAL);

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

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

Убедитесь, что база данных, добавленная в группу доступности, находится в полной модели восстановления и имеет действительную резервную копию журнала. Если база данных тестовая или только что создана, сделайте ее резервную копию. На первичной реплике SQL Server выполните следующий сценарий Transact-SQL, чтобы создать базу данных с именем db1 и ее резервную копию.

CREATE DATABASE [db1];
ALTER DATABASE [db1] SET RECOVERY FULL;
BACKUP DATABASE [db1]
   TO DISK = N'/var/opt/mssql/data/db1.bak';

На первичной реплике SQL Server выполните следующий сценарий Transact-SQL, чтобы добавить базу данных с именем db1 в группу доступности с именем ag1.

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

Убедитесь, что база данных создана на вторичных серверах.

На каждой вторичной реплике SQL Server выполните следующий запрос, чтобы убедиться, что база данных db1 создана и синхронизирована.

SELECT * FROM sys.databases WHERE name = 'db1';
GO
SELECT DB_NAME(database_id) AS 'database', synchronization_state_desc FROM sys.dm_hadr_database_replica_states;

Важно!

После создания группы доступности необходимо настроить интеграцию с кластерной технологией, такой как Pacemaker, для обеспечения высокой доступности. Для конфигурации масштабирования чтения с помощью групп доступности, начиная с SQL Server 2017 (14.x), настройка кластера не требуется.

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

Замечания

Важно!

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

Важно!

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