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

Группы доступности Always On, решение для обеспечения высокой доступности и аварийного восстановления, представленное в SQL Server 2014, требует кластеризации отказоустойчивости Windows Server (WSFC). Кроме того, хотя группы доступности AlwaysOn не зависят от отказоустойчивой кластеризации SQL Server, можно использовать экземпляр отказоустойчивой кластеризации (FCI) для размещения реплики доступности для группы доступности. Важно знать роль каждой технологии кластеризации и знать, какие рекомендации необходимы при разработке среды групп доступности AlwaysOn.

Замечание

Сведения о концепциях групп доступности AlwaysOn см. в обзоре групп доступности AlwaysOn (SQL Server).

Кластер WSFC и группы доступности

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

Группы доступности 'Always On' используют кластер отказоустойчивой кластеризации Windows (WSFC) для мониторинга и управления текущими ролями реплик доступности, которые принадлежат определенной группе доступности, а также для определения того, как событие отказа влияет на эти реплики доступности. Группа ресурсов WSFC создается для каждой создаваемой группы доступности. Кластер WSFC отслеживает эту группу ресурсов для оценки работоспособности основной реплики.

Кворум для групп доступности AlwaysOn основан на всех узлах кластера WSFC независимо от того, размещает ли данный узел кластера любые реплики доступности. В отличие от зеркального отображения базы данных, в группах доступности Always On нет роли свидетеля.

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

Это важно

Разделы реестра групп доступности AlwaysOn — это подразделы кластера WSFC. При удалении и повторном создании кластера WSFC необходимо отключить и повторно включить функцию групп доступности AlwaysOn в каждом экземпляре SQL Server, где размещена реплика доступности в исходном кластере WSFC.

Сведения о запуске SQL Server на узлах отказоустойчивой кластеризации Windows Server (WSFC) и о кворуме WSFC см. в разделе " Отказоустойчивая кластеризация Windows Server" (WSFC) с SQL Server.

Миграция между кластерами групп доступности AlwaysOn для обновления ОС

Начиная с SQL Server 2012 с пакетом обновления 1 (SP1), группы доступности Always On поддерживают миграцию групп доступности между кластерами для развертываний в новый кластер отказоустойчивой кластеризации Windows Server (WSFC). Миграция между кластерами перемещает одну группу доступности или пакет групп доступности в новый целевой кластер WSFC с минимальным временем простоя. Процесс миграции между кластерами позволяет поддерживать соглашения об уровне обслуживания при обновлении до кластера Windows Server 2012. SQL Server 2012 с пакетом обновления 1 (SP1) или более поздней версии необходимо установить и включить для AlwaysOn в кластере WSFC назначения. Успешное выполнение миграции между кластерами зависит от тщательного планирования и подготовки целевого кластера WSFC.

Дополнительные сведения см. в разделе "Миграция между кластерами групп доступности AlwaysOn" для обновления ОС.

Экземпляры отказоустойчивого кластера SQL Server (FCIs) и группы доступности

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

Группы доступности AlwaysOn не зависят от любой формы общего хранилища. Однако при использовании экземпляра отказоустойчивого кластера SQL Server (FCI) для размещения одной или нескольких реплик доступности каждому из этих ПАРАМЕТРОВ потребуется общее хранилище в зависимости от стандартной установки экземпляра отказоустойчивого кластера SQL Server.

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

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

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

	Узлы в FCI	Реплики в группе доступности
Использует кластер WSFC	Да	Да
Уровень защиты	Пример	База данных
Тип хранилища	Общее	Не общее Обратите внимание, что хотя реплики в группе доступности не используют совместные хранилища, реплика, размещенная в FCI, использует общую систему хранения, как требуется для этого FCI. Решение хранения данных совместно используется только узлами в FCI, но не между репликами группы доступности.
Решения хранения данных	Прямое подключение, SAN, точки подключения, SMB	Зависит от типа узла
Доступные для чтения вторичные	Нет*	Да
Применимые параметры политики отработки отказа	Кворум WSFC Связанный с FCI Параметры группы доступности**	Кворум WSFC Параметры группы доступности
Ресурсы для перехода в случае сбоя	Сервер, экземпляр и база данных	Только база данных

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

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

Замечание

Дополнительные сведения о количестве узлов в отказоустойчивой кластеризации и группах доступности AlwaysOn для различных выпусков SQL Server см. в статьях "Функции, поддерживаемые выпусками SQL Server 2012 ( (https://go.microsoft.com/fwlink/?linkid=232473).

Рекомендации для размещения реплики доступности на FCI

Это важно

Если вы планируете разместить реплику доступности в экземпляре отказоустойчивого кластера SQL Server (FCI), убедитесь, что узлы узла Windows Server 2008 соответствуют предварительным требованиям AlwaysOn и ограничениям для экземпляров отказоустойчивого кластера (FCIs). Дополнительные сведения см. в разделе "Предварительные требования", "Ограничения" и "Рекомендации" для групп доступности AlwaysOn (SQL Server).

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

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

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

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

Marcel настраивает два кластера WSFC с двумя узлами NODE01 и NODE02. Он устанавливает экземпляр отказоустойчивого кластера SQL Server, fciInstance1, на обоих NODE01 и NODE02, где NODE01 является текущим владельцем fciInstance1.
В NODE02, Marcel устанавливает другой экземпляр SQL Server, Instance3который является автономным экземпляром.
В NODE01, Marcel включает fciInstance1 для Always On Availability Groups. На NODE02 он включает Instance3 для групп доступности Always On. Затем он настраивает группу доступности, для которой fciInstance1 размещается первичная реплика, и Instance3 размещает вторичную реплику.
В какой-то момент fciInstance1 становится недоступным на NODE01, и кластер WSFC вызывает переключение fciInstance1 на NODE02. После отработки отказа экземпляр fciInstance1, поддерживающий группы доступности Always On, работает в основной роли на NODE02. Однако экземпляр Instance3 теперь находится на том же узле кластера WSFC, что и fciInstance1. Это нарушает ограничение групп доступности AlwaysOn.
Чтобы устранить проблему, представленную этим сценарием, автономный экземпляр, Instance3должен находиться на другом узле в том же кластере WSFC, что NODE01 и NODE02.

Дополнительные сведения о отказоустойчивой кластеризации SQL Server см. в разделе "Экземпляры отказоустойчивого кластера AlwaysOn" (SQL Server).

Ограничения на использование диспетчера отказоустойчивости кластеров WSFC с группами доступности

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

Нельзя добавлять или удалять ресурсы в службе, поддерживающей работу в кластере (группе ресурсов) для группы доступности.
Не изменяйте свойства групп доступности, такие как возможные владельцы и предпочтительные владельцы. Эти свойства устанавливаются автоматически группой доступности.
Не используйте диспетчер отказоустойчивого кластеров для перемещения групп доступности на другие узлы или резервные группы доступности. Диспетчер отказоустойчивого кластера не имеет сведений о состоянии синхронизации реплик доступности, и это может привести к длительному простою. Необходимо использовать Transact-SQL или SQL Server Management Studio.

Связанные материалы

См. также

Обзор групп доступности AlwaysOn (SQL Server)Включение и отключение групп доступности AlwaysOn (SQL Server)Мониторинг групп доступности (Transact-SQL)
Отказоустойчивые кластерные экземпляры AlwaysOn (SQL Server)

Last updated on 2017-06-13