Создание группы доступности, независимой от домена

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

Для групп доступности AlwaysOn (AGs) требуется базовый отказоустойчивый кластер Windows Server (WSFC). Развертывание WSFC через Windows Server 2012 R2 требует, чтобы серверы, участвующие в WSFC, также известные как узлы, были присоединены к одному домену. Дополнительные сведения о доменных службах Active Directory (AD DS) см. здесь.

Зависимость от AD DS и WSFC является более сложной, чем ранее развернутая с конфигурацией базы данных зеркало ing (DBM), так как DBM может быть развернута в нескольких центрах обработки данных с помощью сертификатов без каких-либо таких зависимостей. Для традиционной группы доступности, охватывающей несколько центров обработки данных, требуется, чтобы все серверы были присоединены к одному домену Active Directory. Разные домены, даже доверенные домены, не работают. Все серверы должны быть узлами одного и того же кластера WSFC. Данная конфигурация показана на следующем рисунке. В SQL Server 2016 (13.x) и более поздних версиях также распределены группы доступности, которые достигают этой цели по-другому.

Windows Server 2012 R2 представила отсоединяемый от Active Directory кластер, специализированную форму отказоустойчивого кластера Windows Server, который можно использовать с группами доступности. Этот тип WSFC также требует, чтобы узлы, которые должны присоединяться к домену, были присоединены к одному и тому же домену Active Directory, однако в данном случае WSFC использует DNS, но не использует домен. Так как домен по-прежнему участвует, отсоединяемый от Active Directory кластер по-прежнему не предоставляет возможности, свободные от домена.

Windows Server 2016 представила новый тип отказоустойчивого кластера Windows Server на основе основы отсоединяемого кластера Active Directory: кластера рабочей группы. Кластер рабочей группы позволяет SQL Server развертывать группу доступности на вершине WSFC, которая не требует AD DS. SQL Server требует использования сертификатов для защиты конечных точек точно так же, как сценарии зеркального отражения базы данных. Этот тип группы доступности называется независимой от домена группой доступности. Развертывание группы доступности с базовым кластером рабочей группы поддерживает следующие сочетания узлов, составляющих WSFC:

• Ни один из узлов не присоединен к домену.
• Все узлы присоединены к разным доменам.
• Смешанные узлы — одни из них подключены к домену, другие нет.

На следующем рисунке показан пример независимой группы доступности домена, в которой узлы в Центре обработки данных 1 присоединены к домену, но те, которые в Центре обработки данных 2 используют DNS. В этом случае задайте DNS-суффикс на всех серверах, которые будут служить узлами WSFC. Каждое приложение и сервер, которые обращаются к группе доступности, должны получать одни и те же данные DNS.

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

При развертывании независимой группы доступности домена есть некоторые известные предостережения:

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

• Базовый вариант кластера рабочей группы WSFC можно создать только с помощью PowerShell, но затем его можно администрировать с помощью диспетчера отказоустойчивости кластеров.

• Если требуется Kerberos, необходимо развернуть стандартный WSFC, подключенный к домену Active Directory, и независимая группа доступности домена, вероятно, не является вариантом.

• Несмотря на то, что прослушиватель доступен для настройки, его можно будет использовать только после регистрации в DNS. Как отмечалось ранее, поддержка Kerberos для прослушивателя отсутствует.

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

• Сертификаты используются в конфигурации группы доступности.

Задание и проверка DNS-суффикса на всех серверах-репликах

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

1. С помощью сочетания клавиш Windows + X выберите "Система".
2. Если имя компьютера и полное имя компьютера совпадают, dns-суффикс не задан. Например, если имя компьютера имеет значение SERVER1, значение для полного имени компьютера не должно быть просто SERVER1. Результат должен выглядеть приблизительно так: SERVER1.CONTOSO.LAB. CONTOSO.LAB — суффикс DNS. Значение рабочей группы должно быть указано WORKGROUP. Если вам нужно задать DNS-суффикс, выберите "Изменить Параметры".
3. В диалоговом окне "Свойства системы" выберите "Изменить " на вкладке "Имя компьютера".
4. В диалоговом окне "Изменения имени компьютера" или "Домен" нажмите кнопку "Дополнительно".
5. В диалоговом окне dns-суффикса и имени компьютера NetBIOS введите общий DNS-суффикс в качестве основного DNS-суффикса .
6. Нажмите кнопку "ОК ", чтобы закрыть диалоговое окно "Dns Суффикс" и "Имя компьютера NetBIOS".
7. Нажмите кнопку "ОК", чтобы закрыть диалоговое окно "Изменения имени компьютера" или "Домен".
8. Вам будет предложено перезапустить сервер, чтобы изменения вступили в силу. Нажмите кнопку "ОК", чтобы закрыть диалоговое окно "Изменения имени компьютера" или "Домен".
9. Нажмите кнопку "Закрыть", чтобы закрыть диалоговое окно "Свойства системы".
10. Вам будет предложено перезапустить. Если вы не хотите немедленно перезапустить, нажмите кнопку "Перезапустить позже", в противном случае нажмите кнопку "Перезапустить".
11. После перезапуска сервера убедитесь, что общий DNS-суффикс настроен снова, просмотрев систему.

Примечание.

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

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

Создание независимой группы доступности домена в настоящее время невозможно полностью использовать SQL Server Management Studio. Хотя создание независимой группы доступности домена в основном совпадает с созданием обычной группы доступности, некоторые аспекты (например, создание сертификатов) возможны только с Помощью Transact-SQL. В следующем примере предполагается конфигурация группы доступности с двумя реплика: одна первичная и одна вторичная.

1. Используя инструкции из рабочих групп и кластеров с несколькими доменами в Windows Server 2016, разверните кластер рабочей группы, состоящий из всех серверов, которые будут участвовать в группе доступности. Перед настройкой кластера рабочей группы убедитесь, что общий DNS-суффикс уже настроен.

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

3. Для каждого экземпляра, на котором размещен первичный реплика, требуется главный ключ базы данных (DMK). Если dmK еще не существует, выполните следующую команду:

   CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Strong Password';
   GO
   

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

   CREATE CERTIFICATE InstanceA_Cert
   WITH SUBJECT = 'InstanceA Certificate';
   GO
   

5. Создайте резервную копию сертификата. При желании защиту можно укрепить с помощью закрытого ключа. В этом примере не используется закрытый ключ.

   BACKUP CERTIFICATE InstanceA_Cert
   TO FILE = 'Backup_path\InstanceA_Cert.cer';
   GO
   

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

7. В первичной реплике необходимо создать имя входа для каждой вторичной реплики группы доступности. Это имя входа предоставляет разрешения для подключения к конечной точке, используемой независимой группой доступности домена. Например, для реплика с именем InstanceB:

   CREATE LOGIN InstanceB_Login WITH PASSWORD = 'Strong Password';
   GO
   

8. В каждой вторичной реплике создайте имя входа для первичной реплики. Это имя для входа предоставляется разрешение на подключение к конечной точке. Например, на реплика с именем InstanceB:

   CREATE LOGIN InstanceA_Login WITH PASSWORD = 'Strong Password';
   GO
   

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

   CREATE USER InstanceA_User FOR LOGIN InstanceA_Login;
   GO
   

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

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

    CREATE CERTIFICATE [InstanceB_Cert]
    AUTHORIZATION InstanceB_User
    FROM FILE = 'Restore_path\InstanceB_Cert.cer';
    

12. Создайте конечную точку, которая будет использоваться группой доступности в каждом экземпляре, выступающем в качестве реплики. Для групп доступности конечная точка должна иметь тип DATABASE_MIRRORING. Конечная точка использует для проверки подлинности сертификат, созданный для этого экземпляра при выполнении шага 4. Синтаксис показан в следующем примере для создания конечной точки с помощью сертификата. Выберите соответствующий метод шифрования и другие параметры, относящиеся к вашей среде. Дополнительные сведения о доступных параметрах см. в статье CREATE ENDPOINT.

    CREATE ENDPOINT DIAG_EP STATE = STARTED AS TCP (
        LISTENER_PORT = 5022,
        LISTENER_IP = ALL
    )
    FOR DATABASE_MIRRORING (
        AUTHENTICATION = CERTIFICATE InstanceX_Cert, ROLE = ALL
    );
    

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

    GRANT CONNECT ON ENDPOINT::DIAG_EP TO [InstanceX_Login];
    GO
    

14. После настройки базовых сертификатов и защиты конечной точки создайте группу доступности любым удобным способом. Необходимо вручную создать резервную копию, скопировать и восстановить резервную копию, используемую для инициализации вторичной или использовать автоматическое заполнение. Использование мастера для инициализации вторичных реплика включает использование файлов блока сообщений сервера (S МБ), которые могут не работать при использовании кластера рабочей группы, не присоединенного к домену.

15. При создании прослушивателя убедитесь, что его имя и IP-адрес зарегистрированы в DNS.

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

• Использование мастера добавления базы данных в группу доступности (среда SQL Server Management Studio)
• Использование диалогового окна "Создание группы доступности" (SQL Server Management Studio)
• Создание группы доступности AlwaysOn с помощью Transact-SQL (T-SQL)