Группы доступности для SQL Server on Linux

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

В этой статье описываются характеристики групп доступности (AG) в SQL Server установках под управлением Linux. Он также охватывает различия между отказоустойчивыми кластерами AG на основе Linux и Windows Server (WSFC). Ознакомьтесь с разделом Что такое группа доступности Always On? для изучения основ групп доступности, так как они работают одинаково в Windows и Linux, за исключением кластера отказоустойчивости Windows Server (WSFC).

С точки зрения высокого уровня группы доступности в SQL Server on Linux совпадают с реализацией на основе WSFC. Это означает, что все ограничения и функции одинаковы, за некоторыми исключениями. Ниже приведены основные отличия.

• Microsoft Distributed Transaction Coordinator (DTC) поддерживается в Linux, начиная с SQL Server 2017 CU 16. Однако DTC пока не поддерживается в группах доступности в Linux. Если приложения требуют использования распределенных транзакций и требуют группы доступности, разверните SQL Server на Windows.
• В развертываниях на основе Linux, которым требуется высокий уровень доступности, для кластеризации вместо WSFC используется Pacemaker.
• В отличие от большинства конфигураций для доступных групп в Windows, Pacemaker никогда не требует Active Directory Domain Services (AD DS), за исключением сценария кластера рабочей группы.
• Сбой группы доступности от одного узла к другому отличается от Linux и Windows.
• Некоторые параметры, такие как required_synchronized_secondaries_to_commit, можно изменить только через Pacemaker в Linux, в то время как установка на основе WSFC использует Transact-SQL.

Число реплик и узлов кластера

Группа доступности в выпуске SQL Server Standard может иметь две общие реплики: одну первичную и одну вторичную, которая может использоваться только для целей доступности. Его нельзя использовать для чего-либо другого, например, для читаемых запросов. Группа доступности в версии SQL Server Enterprise может иметь до девяти реплик в общей сложности: одна основная и до восьми вторичных реплик, из которых до трех (включая основную) могут быть синхронными. При использовании базового кластера общее количество узлов может быть не более 16, если используется Corosync. Группа доступности может охватывать не более девяти из 16 узлов в редакции SQL Server Enterprise и двух узлов в редакции SQL Server Standard.

Конфигурация с двумя репликами, для которой требуется возможность автоматического перехода на другую реплику, требует использования реплики, предназначенной только для конфигурации, как описано в разделе Реплика и кворум только для конфигурации. Реплики, доступные только для конфигурации, появились в SQL Server 2017 (14.x) накопительного обновления 1 (CU 1), чтобы она была минимальной версией, развернутой для этой конфигурации.

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

Доступные для чтения вторичные реплики поддерживаются только в выпуске SQL Server Enterprise.

Тип кластера и режим аварийного переключения

Новые возможности SQL Server 2017 (14.x) — это введение типа кластера для групп доступности. Для Linux существует два допустимых значения: External и None. Тип кластера External означает, что Pacemaker используется в составе группы доступности. Для использования типа кластера "External" требуется, чтобы режим отработки отказа также был установлен как "External" (это нововведение появилось в SQL Server 2017 (14.x)). Автоматическое переключение при отказе поддерживается, но, в отличие от WSFC, при использовании Pacemaker режим переключения при отказе устанавливается как Внешний, а не автоматический. В отличие от WSFC, часть группы доступности в Pacemaker создается после настройки группы доступности.

Тип кластера «None» означает, что не требуется ни использовать Pacemaker, ни применять его в группе доступности. Даже на серверах с настроенным Pacemaker, если группа доступности настроена с типом кластера 'None', Pacemaker не видит и не управляет этой группой доступности. Тип кластера «None» поддерживает только ручное переключение с первичной на вторичную реплику. Группа доступности, созданная с помощью "None", в основном предназначена для обновлений и горизонтального масштабирования чтения. Хотя она может работать в таких сценариях, как аварийное восстановление или локальная доступность, когда автоматическое переключение при отказе не требуется, это не рекомендуется. Настройка прослушивателя также будет более сложной без Pacemaker.

Тип кластера хранится в динамическом представлении управления SQL Server (DMV) sys.availability_groups в столбцах cluster_type и cluster_type_desc.

требуемые_синхронизированные_вторичные_для_подтверждения

Новое для SQL Server 2017 (14.x) — это параметр, используемый AGS с именем required_synchronized_secondaries_to_commit. Он указывает группе доступности количество вторичных реплик, которые должны быть синхронизированы с основной репликой. Это включает возможности, такие как автоматическое переключение на резерв (только при интеграции с Pacemaker с кластером типа External), и управляет поведением таких элементов, как доступность первичной системы, если нужное количество вторичных реплик находится в режиме онлайн или офлайн. Подробные сведения см. в разделе Высокий уровень доступности и защита данных для конфигураций группы доступности. Значение required_synchronized_secondaries_to_commit устанавливается по умолчанию и поддерживается Pacemaker/SQL Server. Это значение можно переопределить вручную.

Сочетание required_synchronized_secondaries_to_commit и нового порядкового номера (который хранится в sys.availability_groups) сообщает Pacemaker и SQL Server, что, например, может произойти автоматическое переключение на резерв. В этом случае вторичная реплика будет иметь тот же номер последовательности, что и основная, то есть она будет на уровне со всеми последними данными о конфигурации.

Для required_synchronized_secondaries_to_commit можно задать три значения: 0, 1 или 2. Они управляют поведением в случае, когда реплика становится недоступной. Числа соответствуют количеству вторичных реплик, которые должны быть синхронизированы с базой данных-источником. В Linux это поведение выглядит следующим образом:

required_synchronized_secondaries_to_commit управляет не только поведением отработки отказа при использовании синхронных реплик, но и потерей данных. При значении 1 или 2 вторичная реплика всегда должна быть синхронизирована, чтобы обеспечить избыточность данных. Это означает отсутствие потери данных.

Чтобы изменить значение required_synchronized_secondaries_to_commit, используйте следующий синтаксис:

Red Hat Enterprise Linux (RHEL) и Ubuntu

sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<value>

SUSE Linux Enterprise Server (SLES)

sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>

В этом примере <AGResourceName> — это имя ресурса, настроенного для AG, а <value> равно 0, 1 или 2. Чтобы восстановить ситуацию по умолчанию, когда Pacemaker управляет этим параметром, выполните ту же инструкцию без значения.

Автоматическая отработка отказа группы доступности возможна, если выполняются следующие условия.

• Для первичной и вторичной реплики задано синхронное перемещение данных.
• Вторичный сервер синхронизирован (не находится в процессе синхронизации), что означает, что обе системы находятся на одной и той же точке данных.
• Тип кластера установлен как External. Автоматическая отработка отказа невозможна с типом кластера None.
• В той вторичной реплике, которая станет первичной, sequence_number имеет наибольший порядковый номер — иными словами, ее sequence_number соответствует значению у исходной первичной реплики.

Если эти условия выполнены, и сервер, на котором размещена первичная реплика, выходит из строя, управление группой доступности передается синхронной реплике. Поведение синхронных реплик (которых может быть всего три: одна первичная и две вторичные реплики) может далее контролироваться с помощью required_synchronized_secondaries_to_commit. Это работает с AG как в Windows, так и в Linux, но настроено по-разному. В Linux значение автоматически настраивается кластером в самом ресурсе группы доступности (AG).

Реплика, предназначенная только для конфигурации, и кворум

Конфигурационная реплика была введена для решения ограничений в обработке кворума с помощью Pacemaker, особенно при изолировании сбойного узла. Конфигурация только из двух узлов недостаточна для группы доступности. Для FCI механизмы кворума, предоставляемые Pacemaker, могут быть подходящими, поскольку весь арбитраж отказоустойчивости FCI происходит на уровне кластера. Для группы доступности арбитраж в среде Linux выполняется в SQL Server, где хранятся все метаданные. Именно здесь в действие вступает реплика, предназначенная только для конфигурации.

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

Чтобы группа доступности поддерживала кворум и допускала автоматический переход на другой ресурс с типом кластера External, она должна:

• Имейте три синхронные реплики (только для SQL Server редакции Enterprise);
• Предусмотрены две реплики (одна первичная и одна вторичная) и одна реплика только для конфигурации.

Отказоустойчивость вручную может происходить как при использовании типа кластера External, так и None для конфигураций группы доступности. Хотя реплика, предназначенная только для конфигурации, может быть настроена с помощью группы доступности (AG), которая имеет тип кластера None, чтобы избежать усложнения развертывания, этого не рекомендуется делать. Для этих конфигураций вручную измените required_synchronized_secondaries_to_commit значение не менее 1, чтобы иметь по крайней мере одну синхронизированную реплику.

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

Если используется реплика только для конфигурации, она реализует следующее поведение.

• По умолчанию параметр required_synchronized_secondaries_to_commit имеет значение 0. При необходимости это значение можно изменить вручную на 1.

• Если происходит сбой первичного и если required_synchronized_secondaries_to_commit равен 0, вторичная реплика становится новой первичной и становится доступной как для чтения, так и для записи. Если значение равно 1, происходит автоматический отказоустойчивый переход, но он не принимает новые транзакции, пока другая реплика не будет подключена.

• Если вторичная реплика завершается ошибкой и required_synchronized_secondaries_to_commit имеет значение 0, первичная реплика по-прежнему принимает транзакции, но если в этот момент происходит сбой первичной реплики, защита данных и отработка отказа невозможна (вручную или автоматически), так как вторичная реплика недоступна.

• Если реплика только для конфигурации завершается сбоем, группа доступности функционирует нормально, но автоматическое переключение невозможно.

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

Множественные группы доступности

Для каждого кластера или набора серверов Pacemaker можно создать несколько групп доступности. Единственное ограничение — системные ресурсы. Владение группами доступности (AG) отображается основным пользователем. Разные группы доступности могут принадлежать различным узлам; они не обязаны все работать на одном узле.

Расположение диска и папки для баз данных

Как и в группах доступности (AG) на базе Windows, структура дисков и папок пользовательских баз данных, участвующих в группе доступности, должна быть идентична. Например, если пользовательские базы данных находятся в /var/opt/mssql/userdata на сервере A, эта же папка должна существовать на сервере B. Единственным исключением из этого является раздел Interoperability с группами доступности и репликами на основе Windows.

Прослушиватель для Linux

Функциональность слушателя является необязательной для AG. Он предоставляет единую точку входа для всех подключений (чтение и/или запись в основную реплику и/или только чтение для вторичных реплик), так что приложениям и конечным пользователям не приходится знать, какой сервер размещает данные. В WSFC это сочетание ресурса сетевого имени и IP-ресурса, который затем регистрируется в AD DS (при необходимости) и DNS. В сочетании с самим ресурсом AG оно и предоставляет эту абстракцию. Дополнительные сведения о прослушивателе см. в разделе «Подключение к прослушивателю группы доступности Always On».

Прослушиватель в Linux настраивается иначе, но его функциональные возможности аналогичны. В Pacemaker нет концепции ресурса имени сети, а также не создается объект в AD DS; существует только ресурс IP-адреса, созданный в Pacemaker, который может выполняться на любом из узлов. Для слушателя в DNS необходимо создать запись с понятным именем, ассоциированную с IP-ресурсом. IP-ресурс прослушивателя активен только на сервере, на котором размещена первичная реплика для этой группы доступности.

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

Однако сочетания DNS-имени и IP-адреса по-прежнему недостаточно для обеспечения всех функций, которые предоставляет прослушиватель в WSFC, таких как маршрутизация только для чтения для вторичных реплик. При настройке группы доступности прослушиватель по-прежнему должен быть настроен в SQL Server. Это можно увидеть в мастере настройки и синтаксисе Transact-SQL. Это можно настроить двумя способами, чтобы функционировать так же, как в Windows.

• Для группы доступности с типом "Внешний", IP-адрес прослушивателя, созданного в SQL Server, должен совпадать с IP-адресом ресурса, созданного в Pacemaker.
• Для группы доступности, созданной с типом кластера None, используйте IP-адрес, связанный с первичной репликой.

Экземпляр, связанный с предоставленным IP-адресом, становится координатором для таких задач, как запросы маршрутизации только для чтения из приложений.

Взаимодействие с группами доступности и репликами на основе Windows

Группа доступности с типом кластера "External" или "WSFC" не может иметь свои реплики между платформами. Это справедливо как для версии SQL Server Standard, так и для версии SQL Server Enterprise. Это означает, что в традиционной конфигурации группы доступности с базовым кластером одна реплика не может находиться в WSFC, а другая — в Linux с Pacemaker.

Группа доступности (AG) с типом кластера NONE может иметь свои реплики, работающие на разных операционных системах, поэтому в одной группе доступности могут быть как реплики на базе Linux, так и на базе Windows. Пример показан здесь, где основная реплика основана на Windows, а вторичная — на одном из дистрибутивов Linux.

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

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

• Настройка группы доступности SQL Server для обеспечения высокой доступности в Linux
• Настройка группы доступности SQL Server для масштабирования в Linux
• Настройка кластера Pacemaker для групп доступности SQL Server
• Настройка группы доступности SQL Server Always On на Windows и Linux (кроссплатформенно)