Поделиться через


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

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

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

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

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

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

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

Шаги по созданию AG (группы доступности) на серверах Linux для обеспечения высокой доступности отличаются от шагов на отказоустойчивом кластере Windows Server. Ниже описываются основные этапы.

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

    Внимание

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

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

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

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

    Внимание

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

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

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

  4. Добавьте AG в качестве ресурса в кластер.

    Способ добавления AG в качестве ресурса в кластере зависит от дистрибутива 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/hosts на node1 с добавлениями для 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 см. в разделе "Настройка расширенных событий" для групп доступности.

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

Служба 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>'
);

В предыдущем примере замените <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 (14.x) используется CERTIFICATEединственный метод проверки подлинности, поддерживаемый для конечной точки зеркального отображения базы данных. Параметр WINDOWS недоступен.

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

Создать AG

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

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

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

Примечание.

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

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

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

    Указывает, что сущность внешнего кластера управляет AG. Примером сущности внешнего кластера является 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 вашего экземпляра SQL Server. Например, если имя узла — 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;

Внимание

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

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

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

Внимание

Эта архитектура позволяет размещать третью реплику в любом выпуске SQL Server. Например, третью реплику можно разместить в версии SQL Server Express Edition. В выпуске 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;

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

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

Используйте две реплики с синхронным режимом доступности. Например, следующий сценарий создает группу доступности (AG) 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;

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

Присоединение вторичных реплик к группе доступности AG (Availability Group)

Пользователю Pacemaker требуются ALTER, CONTROL, и 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, чтобы присоединить группу доступности (AG).

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

ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE;

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

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

CREATE DATABASE [db1];
GO

ALTER DATABASE [db1]
    SET RECOVERY FULL;
GO

BACKUP DATABASE [db1]
    TO DISK = N'/var/opt/mssql/data/db1.bak';

На первичной реплике SQL Server выполните следующий скрипт T-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;
GO

Внимание

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

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

Замечания

Внимание

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

Внимание

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