Предварительные требования, ограничения и рекомендации для групп доступности AlwaysOn

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

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

Исправления .NET, поддерживающие группы доступности

В зависимости от компонентов и компонентов SQL Server, которые будут использоваться с группами доступности AlwaysOn, может потребоваться установить дополнительные исправления .NET, определенные в следующей таблице. Исправления можно устанавливать в любом порядке.

Контрольный список: требования (система Windows)

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

Рекомендации для компьютеров, на которых размещаются реплики доступности (система Windows)

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

• Выделенные сетевые адаптеры: Для оптимальной производительности следует использовать выделенный сетевой адаптер для групп доступности Always On (сетевую карту).

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

• Идентичный макет диска. Каждый компьютер, на котором размещена реплика доступности, должен иметь идентичный макет диска (с точными буквами дисков и размерами), чтобы обеспечить зеркальное отображение путей к файлам базы данных (mdf, ldf), предотвращая осложнения во время заполнения и синхронизации. Просмотрите ограничения (базы данных доступности) для разных макетов дисков.

Разрешения (система Windows)

Для администрирования кластера WSFC пользователь должен быть системным администратором на каждом узле кластера.

Дополнительные сведения об учетной записи для администрирования кластера см. в Приложении A. Требования к отказоустойчивому кластеру.

Связанные задачи (система Windows)

Изменение узлаRecordTTL (с помощью PowerShell)

1. Откройте окно Powershell с помощью варианта Запуск от имени администратора.

2. Импортируйте модуль FailoverClusters.

3. С помощью командлета Get-ClusterResource найдите ресурс сетевого имени, а затем с помощью командлета Set-ClusterParameter задайте значение HostRecordTTL следующим образом:

   Get-ClusterResource "<NetworkResourceName>" | Set-ClusterParameter HostRecordTTL <TimeInSeconds>

   В следующем примере для PowerShell задается значение HostRecordTTL в 300 секунд для сетевого ресурса сетевого имени SQL Network Name (SQL35).

   Import-Module FailoverClusters
   
   $nameResource = "SQL Network Name (SQL35)"
   Get-ClusterResource $nameResource | Set-ClusterParameter HostRecordTTL 300
   

   Совет

   Каждый раз при открытии нового окна PowerShell потребуется импортировать модуль FailoverClusters .

Связанное содержимое (PowerShell)

• Кластеризация и высокая доступность (блог группы отказоустойчивой кластеризации и балансировки сетевой нагрузки)

• Приступая к работе с Windows PowerShell в отказоустойчивом кластере

• Команды ресурса кластера и соответствующие командлеты Windows PowerShell

Связанное содержимое (система Windows)

• Настройка параметров DNS для многосайтового отказоустойчивого кластера

• Регистрация DNS в ресурсе сетевого имени

Предварительные требования и ограничения экземпляра SQL Server

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

В этом разделе:

• Контрольный список: предварительные требования
• Использование потоков по группам доступности
• Разрешения
• Связанные задачи
• См. также

Контрольный список: предварительные требования (экземпляр сервера)

Список функций, поддерживаемых выпусками SQL Server в Windows, см. в следующих статье:

• Выпуски и поддерживаемые функции SQL Server 2022
• Выпуски и поддерживаемые функции SQL Server 2019
• Выпуски SQL Server 2017 и поддерживаемые функции
• Выпуски и поддерживаемые функции SQL Server 2016

Использование потоков группами доступности

Группы доступности AlwaysOn имеют следующие требования для рабочих потоков:

• В неактивном экземпляре SQL Server группы доступности AlwaysOn используют 0 потоков.

• Максимальное число потоков, используемых для групп доступности, — это заданный настройками параметр максимального числа потоков сервера ("max worker threads") минус 40.

• Реплики доступности, размещенные на данном экземпляре сервера, совместно используют один пул потоков в SQL Server 2019 (15.x) и предыдущих версиях.

  Потоки совместно используются по требованию следующим образом.

  • Обычно имеется 3–10 общих потоков, но это число может возрасти в зависимости от рабочей нагрузки первичной реплики.

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

  • Экземпляр SQL Server использует до 100 потоков параллельного повтора для вторичных реплик. Каждая база данных использует до половины от общего числа ядер ЦП, но не более 16 потоков на базу данных. Если общее число требуемых потоков для одного экземпляра превышает 100, SQL Server использует один поток повтора для каждой из оставшихся баз данных. Потоки последовательного повтора выпускаются примерно через 15 секунд бездействия.

• Кроме того, группы доступности используют неразделенные потоки следующим образом.

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

  • Резервное копирование на вторичной реплике удерживает поток на первичной реплике на время операции резервного копирования.

• SQL Server 2022 (16.x) представил параллельный пул потоков повтора, который является пулом потоков уровня экземпляра, общим для всех баз данных с работой повторного выполнения. С помощью этого пула один и тот же набор потоков может обрабатывать записи журнала для разных баз данных одновременно (параллельно). В SQL Server 2019 (15.x) и предыдущих версиях количество доступных потоков для повтора ограничено 100.

• SQL Server 2019 (15.x) представил параллельный повтор для баз данных группы доступности, оптимизированных для памяти. В SQL Server 2016 (13.x) и SQL Server 2017 (14.x) таблицы на основе дисков не используют параллельный повтор, если база данных в группе доступности также оптимизирована для памяти.

Дополнительные сведения см. в разделе AlwaysOn — серия обучения HADRON: использование рабочего пула для баз данных с поддержкой HADRON (блог инженеров SQL Server CSS).

Разрешения (экземпляр сервера)

Связанные задачи (экземпляр сервера)

Связанное содержимое (экземпляр сервера)

• Обучающая серия AlwaysOn — HADRON: использование рабочего пула для баз данных с поддержкой HADRON

Рекомендации по подключению к сети

Настоятельно рекомендуется использовать одни и те же сетевые соединения для обмена данными между узлами WSFC и репликами доступности. Использование отдельных сетевых соединений может привести к непредвиденному поведению в случае отказа даже некоторых из них.

Например, чтобы группа доступности поддерживала автоматический переход на другой ресурс, вторичная реплика, которая является участником обработки отказа, должна находиться в состоянии SYNCHRONIZED. Если сетевая ссылка на эту вторичную реплику завершается ошибкой (даже периодически), реплика входит в состояние UNSYNCHRONIZED и не может начать повторно выполнять повторную синхронизацию, пока не будет восстановлена ссылка. Если WSFC запрашивает автоматическую отработку отказа во время несинхронизации вторичной реплики, автоматическое отработка отказа не происходит.

Поддержка возможности подключения клиента

Сведения о поддержке групп доступности AlwaysOn для подключения клиентов см. в статье "Поддержка подключения драйверов и клиентов" для групп доступности.

Предварительные требования и ограничения для использования экземпляра отказоустойчивого кластера SQL Server (FCI) для размещения реплики доступности

В этом разделе:

• Ограничения
• Контрольный список: предварительные требования
• Связанные задачи
• См. также

Ограничения (экземпляры отказоустойчивого кластера)

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

  Кроме того, каждая другая реплика должна размещаться экземпляром SQL Server, который находится на другом узле кластера в том же отказоустойчивом кластере Windows Server. Единственное исключение состоит в том, что при переносе в другой кластер группа доступности может временно находиться в двух кластерах.

  Предупреждение

  Использование диспетчера отказоустойчивости кластеров для перемещения FCI, в котором размещена группа доступности, на узел, на котором уже размещена реплика той же группы доступности, может привести к потере реплики группы доступности, предотвращая его перенос в сети на целевом узле. Один узел отказоустойчивого кластера не может размещать несколько реплик для одной группы доступности. Дополнительные сведения о том, как это происходит, и способы восстановления см. в записи блога Проблема: Неожиданное удаление реплики в группе доступности.

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

• Изменение имени сети FCI. Если необходимо изменить сетевое имя FCI, на котором размещена реплика доступности, необходимо удалить реплику из своей группы доступности, а затем добавить реплику обратно в группу доступности. Вы не можете удалить первичную реплику, поэтому при переименовании FCI, на котором размещена первичная реплика, необходимо выполнить отработку отказа на вторичную реплику, а затем удалить предыдущую первичную реплику и добавить ее обратно. Переименование FCI может изменить URL-адрес конечной точки зеркального отображения базы данных. При добавлении реплики убедитесь, что указываете URL-адрес текущей конечной точки.

Контрольный список: предварительные требования FCI)

Связанные задачи (ФК)

Связанное содержимое (FCIs)

• Отказоустойчивая кластеризация и группы доступности Always On (SQL Server)

• Руководство по архитектуре AlwaysOn. Создание решения высокого уровня доступности и аварийного восстановления с помощью экземпляров отказоустойчивого кластера и групп доступности

Предварительные требования и ограничения группы доступности

В этом разделе:

• Ограничения
• Требования
• Безопасность
• Связанные задачи

Ограничения (группы доступности)

• Реплики доступности должны размещаться на разных узлах одного кластера WSFC: Для данной группы доступности реплики доступности должны размещаться на разных экземплярах сервера, работающих на разных узлах одного и того же кластера WSFC. Единственное исключение состоит в том, что при переносе в другой кластер группа доступности может временно находиться в двух кластерах.

  Примечание.

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

• Уникальное имя группы доступности: Имя каждой группы доступности должно быть уникальным в пределах кластера WSFC. Максимальная длина имени группы доступности составляет 128 символов.

• Реплики доступности: Каждая группа доступности поддерживает одну первичную реплику и до восьми вторичных реплик. Все реплики могут выполняться в режиме асинхронной фиксации или до пяти из них могут работать в режиме синхронной фиксации (одна первичная реплика с двумя синхронными вторичными репликами). Каждая реплика должна иметь уникальное имя сервера в Windows и SQL Server. Имена серверов в Windows и SQL Server должны совпадать.

• Максимальное количество групп доступности и баз данных доступности на компьютер: фактическое количество баз данных и групп доступности, которые можно поместить на компьютер (виртуальную машину или физический), зависит от оборудования и рабочей нагрузки, но не существует принудительного ограничения. Корпорация Майкрософт тестировала до 10 групп доступности и 100 DBS на физический компьютер, однако это не ограничение привязки. В зависимости от характеристик оборудования на сервере и рабочей нагрузки можно поместить больше баз данных и групп доступности в экземпляр SQL Server. Признаки перегруженных систем могут включать в себя, но не ограничены, исчерпанием рабочих потоков, медленным временем отклика для системных представлений группы доступности и динамических административных представлений и /или приостановленных дампов системы диспетчера. Обязательно проведите тщательное тестирование среды с рабочей нагрузкой, чтобы убедиться, что система в состоянии обрабатывать пиковую нагрузку в рамках соглашений об уровне обслуживания приложений. При рассмотрении соглашений об уровне обслуживания обязательно проверяйте нагрузку в условиях сбоя, а также ожидаемое время ответа.

• Не используйте диспетчер отказоустойчивости кластеров для управления группами доступности. Состояние FCI SQL Server совместно используется между SQL Server и отказоустойчивой кластером Windows Server (WSFC) с SQL Server, сохраняя более подробные сведения о состоянии экземпляров, чем о кластере. Модель управления заключается в том, что SQL Server необходимо инициировать транзакции и отвечать за поддержание представления кластера о состоянии в синхронизации с представлением состояния SQL Server. Если состояние кластера изменяется за пределами SQL Server, состояние может выйти из синхронизации между WSFC и SQL Server, что может привести к непредсказуемому поведению.

  Например:

  • Не изменяйте свойства группы доступности, например возможных владельцев.

  • Не используйте диспетчер отказоустойчивости кластеров для отработки отказа групп доступности. Необходимо использовать Transact-SQL или SQL Server Management Studio.

• Не добавляйте ресурсы или не изменяйте зависимости, связанные с ролью группы доступности. Мы не рекомендуем размещать дополнительные ресурсы (включая пользователя или стороннего) в роль группы доступности или изменять зависимости ролей, так как эти изменения могут негативно повлиять на производительность отработки отказа.

Предварительные требования (группы доступности)

При создании или повторной настройке конфигурации групп доступности обязательно следуйте описанным ниже требованиям.

Безопасность (группы доступности)

• Параметры безопасности наследуются от WSFC. Отказоустойчивая кластеризация Windows Server обеспечивает два уровня безопасности пользователей на уровне всего кластера.

  • Доступ только для чтения

  • Полный контроль

    Для групп доступности AlwaysOn требуется полный контроль и включение групп доступности AlwaysOn в экземпляре SQL Server обеспечивает полный контроль над кластером (с помощью идентификатора безопасности службы).

    Невозможно напрямую добавить или удалить безопасность для экземпляра сервера в Диспетчере кластеров. Для управления сеансами безопасности кластера используйте диспетчер конфигурации SQL Server или эквивалент WMI из SQL Server.

• Каждый экземпляр SQL Server должен иметь разрешения на доступ к реестру, кластеру и т. д.

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

Разрешения (группы доступности)

Связанные задачи (группы доступности)

Предварительные требования и ограничения базы данных доступности

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

В этом разделе:

• Требования
• Ограничения
• Рекомендации для компьютеров, на которых размещаются реплики доступности (система Windows)
• Разрешения
• Связанные задачи

Контрольный список: требования (базы данных доступности)

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

Ограничения (базы данных доступности)

• Если путь к файлу (в том числе буква диска) базы данных-получателя отличается от пути в соответствующей базе данных-источнике, применимы следующие ограничения.

  • Мастер создания группы доступности и мастер добавления базы данных в группу доступности. Полный параметр не поддерживается (на странице выбора начальной Синхронизация данных хронизации (мастера группы доступности AlwaysOn) )

  • RESTORE WITH MOVE: Для создания баз данных-получателей файлы базы данных должны иметь атрибут RESTORED WITH MOVE в каждом экземпляре SQL Server, в котором размещена вторичная реплика.

  • Воздействие на операции добавления файлов: Операция добавления файлов, выполняемая позднее в основной реплике, может завершиться со сбоем в базах данных-получателях. Эта ошибка может вызвать приостановку работы баз данных-получателей. Это, в свою очередь, вызовет переход дополнительных реплик в состояние NOT SYNCHRONIZING.

    Примечание.

    Дополнительные сведения о реакции на операции добавления файла, завершившиеся сбоем, см. в разделе Устранение неполадок с операциями добавления файла, завершившимися сбоем (группы доступности Always On).

• Вы не можете удалить базу данных, которая в настоящее время принадлежит группе доступности.

Дальнейшие действия для защищенных баз данных TDE

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

Разрешения (базы данных доступности)

Необходимо разрешение ALTER в базе данных.

Связанные задачи (базы данных доступности)

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

• Руководство по решениям режима AlwaysOn в Microsoft SQL Server для обеспечения высокой доступности и аварийного восстановления
• Блоги команды разработчиков SQL Server AlwaysOn: официальный блог по SQL Server AlwaysOn
• Обучающая серия AlwaysOn — HADRON: использование рабочего пула для баз данных с поддержкой HADRON
• Что такое группа доступности AlwaysOn?
• Отказоустойчивая кластеризация и группы доступности Always On (SQL Server)
• Поддержка подключения драйверов и клиентов для групп доступности