Развертывание кластера больших данных SQL Server в режиме Active Directory

Статья
03/18/2023

В этой статье описывается развертывание кластера больших данных SQL Server в режиме Active Directory. Для выполнения действий, описанных в этой статье, требуется доступ к домену Active Directory. Прежде чем продолжить, выполните требования, описанные в разделе Развертывание кластера больших данных SQL Server в режиме Active Directory.

Внимание

Поддержка надстройки "Кластеры больших данных" Microsoft SQL Server 2019 будет прекращена. Мы прекратим поддержку Кластеров больших данных SQL Server 2019 28 февраля 2025 г. Все существующие пользователи SQL Server 2019 с Software Assurance будут полностью поддерживаться на платформе, и программное обеспечение будет продолжать поддерживаться с помощью накопительных обновлений SQL Server до этого времени. Дополнительные сведения см. в записи блога объявлений и в статье о параметрах больших данных на платформе Microsoft SQL Server.

Подготовка развертывания

Чтобы развернуть кластер больших данных с интеграцией AD, необходимо предоставить дополнительные сведения для создания в AD объектов, связанных с кластером больших данных.

Используя профиль kubeadm-prod (или openshift-prod, начиная с выхода накопительного пакета обновления 5 — CU5), вы автоматически получите заполнители для сведений о безопасности и конечных точках, которые требуются для интеграции с AD.

Кроме того, необходимо предоставить учетные данные, которые Кластеры больших данных будут использовать для создания необходимых объектов в AD. Эти учетные данные предоставляются в качестве переменных среды

Трафик и порты

Убедитесь, что все брандмауэры и сторонние приложения разрешают порты, требуемые для обмена данными с Active Directory.

Схема трафика между кластером больших данных и Active Directory. Контроллер, служба поддержки безопасности и другие службы кластеров говорят через LDAP или Kerberos к контроллерам домена. Служба прокси-сервера DNS Кластеры больших данных выступает через DNS-серверы.

Запросы выполняются с использованием этих протоколов между службами кластеров Kubernetes и доменом Active Directory, поэтому должны быть разрешены входящие и исходящие подключения в любом брандмауэре или стороннем приложении, прослушивающем требуемые порты для TCP и UDP. Стандартные номера портов, которые Active Directory использует:

Service	Порт
DNS	53
LDAP LDAPS	389 636
Kerberos	88
Протокол изменения пароля Kerberos/AD	464
Порт глобального каталога через LDAP через LDAPS	3268 3269

Задание переменных среды безопасности

Следующие переменные среды предоставляют учетные данные для учетной записи доменной службы Кластеров больших данных, которая будет использоваться для настройки интеграции с AD. Эта учетная запись также используется Кластерами больших данных для обслуживания связанных объектов AD в дальнейшем.

export DOMAIN_SERVICE_ACCOUNT_USERNAME=<AD principal account name>
export DOMAIN_SERVICE_ACCOUNT_PASSWORD=<AD principal password>

Предоставление параметров безопасности и конечных точек

В дополнение к переменным среды для учетных данных вам также потребуется предоставить сведения о безопасности и конечных точках, чтобы интеграция с AD функционировала. Необходимые параметры автоматически предоставляются в составе профиля развертывания kubeadm-prod/openshift-prod.

Для интеграции с AD требуются следующие параметры. Добавьте эти параметры в файлы control.json и bdc.json с помощью команд config replace, показанных ниже в этой статье. Во всех примерах ниже используется пример домена contoso.local.

security.activeDirectory.ouDistinguishedName: различающееся имя подразделения (OU), в которое будут добавлены все учетные записи AD, созданные при развертывании кластера. Если домен называется contoso.local, различающееся имя подразделения имеет вид: OU=BDC,DC=contoso,DC=local.
security.activeDirectory.dnsIpAddresses: содержит список IP-адресов DNS-серверов домена.
security.activeDirectory.domainControllerFullyQualifiedDns: список полного доменного имени контроллера домена. Полное доменное имя содержит название компьютера/узла контроллера домена. Если у вас несколько контроллеров доменов, список можно указать здесь. Пример: HOSTNAME.CONTOSO.LOCAL.

Внимание

Если несколько контроллеров домена обслуживают домен, используйте основной контроллер домена (PDC) в качестве первой записи в списке в domainControllerFullyQualifiedDns конфигурации безопасности. Чтобы получить имя PDC, введите netdom query fsmoв командной строке и нажмите клавишу ВВОД.
security.activeDirectory.realmНеобязательный параметр: в большинстве случаев область равна доменному имени. В случаях, когда они не совпадают, используйте этот параметр для определения имени области (например, CONTOSO.LOCAL). Значение, указанное для этого параметра, должно быть полным.
security.activeDirectory.netbiosDomainName Необязательный параметр. NetBIOS-имя домена Active Directory. В большинстве случаев это будет первая метка доменного имени AD. В иных случаях используйте этот параметр, чтобы задать NetBIOS-имя домена. Значение не должно содержать точек. Обычно это имя используется для уточнения имен учетных записей пользователей в домене. Например, CONTOSO\user, где CONTOSO — это доменное имя в формате NetBIOS.

Примечание.

Поддержка конфигурации, в которой доменное имя Active Directory отличается от NetBIOS-имени домена Active Directory, посредством security.activeDirectory.netbiosDomainName появилась начиная с SQL Server 2019 с накопительным пакетом обновления 9.
contoso.local: имя домена DNS, которое будет использоваться для кластера (например, security.activeDirectory.domainDnsName).
security.activeDirectory.clusterAdmins: этот параметр принимает одну группу AD. Область действия группы AD должна быть универсальной или глобальной. Члены этой группы будут иметь bdcAdmin роль кластера, которая предоставит им разрешения администратора в кластере. Это означает, что у них есть разрешения sysadmin в SQL Server, разрешения superuser в HDFS и разрешения администратора при подключении к конечной точке контроллера.

Внимание

Создайте эту группу в AD перед началом развертывания. Если область для этой группы AD является локальной доменной, развертывание завершается сбоем.
security.activeDirectory.clusterUsers: список групп AD, которые являются обычными пользователями (без разрешений администратора) в кластере больших данных. Список может включать группы AD, областью действия которых является универсальная или глобальная группа. Они не могут быть локальными доменными группами.

Группы AD в этом списке сопоставляются с bdcUser ролью кластера больших данных, и им необходимо предоставить доступ к SQL Server (см. разрешения SQL Server) или HDFS (см . руководство по разрешениям HDFS). При подключении к конечной точке контроллера эти пользователи могут перечислять только конечные точки, доступные в кластере с помощью azdata bdc endpoint list команды.

Дополнительные сведения об обновлении групп AD для этих параметров см. в разделе Управление доступом к кластеру больших данных в режиме AD.

Совет

Чтобы включить просмотр HDFS при подключении к главному серверу SQL Server в Azure Data Studio, пользователю с ролью bdcUser необходимо предоставить разрешения VIEW SERVER STATE, так как Azure Data Studio использует sys.dm_cluster_endpoints dmV, чтобы получить необходимую конечную точку шлюза Knox для подключения к HDFS.

Внимание

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

Внимание

Если у пользователей домена имеется большое количество членства в группах, следует настроить значения параметра httpserver.requestHeaderBuffer шлюза (значение по умолчанию) и параметр hadoop.security.group.mapping.ldap.search.group.hierarchy.levels HDFS (значение 108192по умолчанию) с помощью пользовательского файла конфигурации развертывания bdc.json. Это позволяет избежать истечения времени ожидания подключения к шлюзу и/или получения HTTP-ответов с кодом состояния 431 (Слишком большие поля заголовка запроса). Ниже приведен раздел файла конфигурации, в котором показано, как определить значения этих параметров и каковы рекомендуемые значения для большего числа членств в группах:

{
    ...
    "spec": {
        "resources": {
            ...
            "gateway": {
                "spec": {
                    "replicas": 1,
                    "endpoints": [{...}],
                    "settings": {
                        "gateway-site.gateway.httpserver.requestHeaderBuffer": "65536"
                    }
                }
            },
            ...
        },
        "services": {
            ...
            "hdfs": {
                "resources": [...],
                "settings": {
                  "core-site.hadoop.security.group.mapping.ldap.search.group.hierarchy.levels": "4"
                }
            },
            ...
        }
    }
}

security.activeDirectory.enableAES Optional parameter Необязательный параметр. Это логическое значение указывает, следует ли включить AES 128 и AES 256 для автоматически создаваемых учетных записей AD. Значение по умолчанию: false. Если этот параметр имеет значение true, то для автоматически создаваемых объектов AD при развертывании кластера больших данных будут установлены флаги "Данная учетная запись поддерживает 128-разрядное шифрование Kerberos AES" и "Данная учетная запись поддерживает 256-разрядное шифрование Kerberos AES".

Примечание.

Параметр security.activeDirectory.enableAES доступен для Кластеров больших данных начиная с версии SQL Server с накопительным пакетом обновлений 13 (CU13). Если кластер больших данных имеет версию ниже CU13, необходимо выполнить следующие действия:

Выполните команду azdata bdc rotate -n <your-cluster-name>, которая сменит keytab в кластере, чтобы обеспечить правильность записей AES в keytab. Дополнительные сведения см. в описании команды azdata bdc. Кроме того, azdata bdc rotate сменит пароли объектов AD, созданных автоматически во время первоначального развертывания в указанном подразделении.
Для каждого автоматически созданного объекта AD в том подразделении, которое вы указали во время исходного развертывания кластера больших данных, установите следующие флаги: "Эта учетная запись поддерживает 128-битовое шифрование Kerberos AES" и "Эта учетная запись поддерживает 256-битовое шифрование Kerberos AES". Для этого можно выполнить на контроллере домена следующий скрипт PowerShell Get-ADUser -Filter * -SearchBase '<OU Path>' | Set-ADUser -replace @{ 'msDS-SupportedEncryptionTypes' = '24' }, который задает поля AES для каждой учетной записи в подразделении, как указано в параметре <OU Path>.

Внимание

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

security.activeDirectory.appOwnersНеобязательный параметр: список групп AD, имеющих разрешения на создание, удаление и запуск любого приложения. Список может включать группы AD, областью действия которых является универсальная или глобальная группа. Они не могут быть локальными доменными группами.
security.activeDirectory.appReadersНеобязательный параметр: список групп AD, имеющих разрешения на запуск любого приложения. Список может включать группы AD, областью действия которых является универсальная или глобальная группа. Они не могут быть локальными доменными группами.

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

Авторизованные роли	Команда Azure Data CLI (`azdata`)
appOwner	azdata app create
appOwner	azdata app update
appOwner, appReader	azdata app list
appOwner, appReader	azdata app describe
appOwner	azdata app delete
appOwner, appReader	azdata app run

security.activeDirectory.subdomain: необязательный параметр Этот параметр представлен в выпуске SQL Server 2019 CU5 для поддержки развертывания нескольких кластеров больших данных в одном домене. С помощью этого параметра можно указать разные DNS-имена для каждого развернутого кластера больших данных. Если значение этого параметра не указано в разделе Active Directory файла control.json, по умолчанию для расчета значения параметра поддомена будет использоваться имя кластера больших данных (то же, что и имя пространства имен Kubernetes).

Примечание.

Значение, передаваемое через параметр поддомена, является не новым доменом AD, а лишь DNS-доменом, который используется кластером больших данных для внутренних целей.

Внимание

Чтобы использовать эти новые возможности и развернуть несколько кластеров больших данных в одном домене, необходимо установить последнюю версию или обновить Azure Data CLI (azdata), чтобы она соответствовала накопительному пакету обновления 5 (CU5) для SQL Server 2019.

Дополнительные сведения о развертывании нескольких кластеров больших данных в одном домене Active Directory см. в разделе Концепция: развертывание Кластеров больших данных SQL Server в режиме Active Directory.
security.activeDirectory.accountPrefix: необязательный параметр Этот параметр представлен в выпуске SQL Server 2019 CU5 для поддержки развертывания нескольких кластеров больших данных в одном домене. Этот параметр гарантирует уникальность имен учетных записей для различных служб кластеров больших данных, которые должны различаться между двумя кластерами. Настройка имени префикса учетной записи является необязательной; по умолчанию в качестве префикса учетной записи используется имя поддомена. Если имя поддомена длиннее 12 символов, в качестве префикса учетной записи используются первые 12 символов имени поддомена.

Примечание.

Длина имени учетной записи Active Directory должна составлять не более 20 символов. Кластеру больших данных необходимо использовать 8 символов для различения объектов pod и наборов с отслеживанием состояния. В итоге остается 12 символов для префикса учетной записи.

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

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

azdata bdc config init --source kubeadm-prod  --target custom-prod-kubeadm

Чтобы задать указанные выше параметры в файле control.json, используйте следующие команды Azure Data CLI (azdata). Эти команды заменяют конфигурацию и предоставляют ваши значения до развертывания.

Внимание

В выпуске SQL Server 2019 CU2 структура раздела конфигурации безопасности в профиле развертывания изменилась визуально, и все связанные параметры Active Directory находятся в новом activeDirectory дереве security JSON в control.json файле.

Примечание.

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

Приведенный ниже пример основан на использовании SQL Server 2019 CU2. В нем показано, как заменить значения параметров, связанных с AD, в конфигурации развертывания. Ниже приведены примеры значений домена.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

Кроме того (только после выхода накопительного пакета обновления 5 (CU5) для SQL Server 2019), вы можете переопределить значения по умолчанию для параметров subdomain и accountPrefix.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.subdomain=[\"bdctest\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.accountPrefix=[\"bdctest\"]"

Аналогичным образом, в выпусках, предшествующих SQL Server 2019 CU2, можно запустить:

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

Помимо указанных выше сведений необходимо также указать DNS-имена для разных конечных точек кластера. Записи DNS, использующие указанные DNS-имена, будут автоматически созданы на DNS-сервере при развертывании. Эти имена будут использоваться при подключении к разным конечным точкам кластера. Например, если DNS-имя для главного экземпляра SQL имеет значение mastersql, а поддомен будет использовать значение по умолчанию имени кластера в control.json, вы будете использовать mastersql.contoso.local,31433 или mastersql.mssql-cluster.contoso.local,31433 (в зависимости от значений, указанных в файлах конфигурации развертывания для DNS-имен конечных точек) для подключения к главному экземпляру из этих средств.

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[1].dnsName=<monitoring services DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[0].dnsName=<SQL Master Primary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[1].dnsName=<SQL Master Secondary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.gateway.spec.endpoints[0].dnsName=<Gateway (Knox) DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.appproxy.spec.endpoints[0].dnsName=<app proxy DNS name>.<Domain name. e.g. contoso.local>"

Внимание

Можно использовать собственные DNS-имена конечных точек, если они полностью определены и не конфликтуют между любыми двумя кластерами больших данных, развернутыми в одном домене. При необходимости можно использовать значение параметра subdomain, чтобы гарантировать, что DNS-имена различаются в разных кластерах. Например:

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.<subdomain e.g. mssql-cluster>.contoso.local"

Здесь вы найдете пример скрипта для развертывания кластера больших данных SQL Server в кластере Kubernetes с одним узлом (kubeadm) и интеграцией с AD.

Примечание.

В некоторых ситуациях вы не можете использовать новый параметр subdomain. Например, необходимо развернуть выпуск до пакета обновлений CU5, и вы уже обновили Azure Data CLI (azdata). Это маловероятно, но, если необходимо вернуться к поведению до выхода накопительного пакета обновления 5 (CU5), можно задать для параметра useSubdomain значение false в разделе control.json Active Directory. Ниже приведена соответствующая команда.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.useSubdomain=false"

На данный момент у вас должны быть заданы все необходимые параметры для развертывания Кластеров больших данных с интеграцией с Active Directory.

Теперь можно развернуть кластер больших данных, интегрированный с Active Directory, с помощью команды Azure Data CLI (azdata) и профиля развертывания kubeadm-prod. Полную документацию по развертыванию кластеров больших данных см. в статье Развертывание кластеров больших данных SQL Server в Kubernetes.

Проверка обратной DNS-записи для контроллера домена

Убедитесь в наличии обратной DNS-записи (записи PTR) для самого доменного контроллера, зарегистрированного на сервере DNS. Это можно проверить, выполнив команду nslookup для IP-адреса контроллера домена и убедившись, что адрес разрешается в полное доменное имя контроллера.

Известные проблемы и ограничения

Ограничения, которые следует учитывать в накопительном пакете обновления 5 (CU5) для SQL Server 2019

В настоящее время информационная панель поиска журналов и информационная панель метрик не поддерживают проверку подлинности AD. Для проверки подлинности на этих информационных панелях можно использовать базовые имя пользователя и пароль, заданные при развертывании. Все остальные конечные точки кластера поддерживают проверку подлинности AD.
Сейчас безопасный режим AD будет работать только в средах развертывания kubeadm и openshift, но не в AKS или ARO. Профили развертывания kubeadm-prod и openshift-prod по умолчанию включают разделы, посвященные безопасности.
До выпуска накопительного пакета обновления 5 (CU5) для SQL Server 2019 разрешен всего один кластер больших данных на домен (Active Directory). Поддержка нескольких кластеров больших данных на домен доступна начиная с выпуска накопительного пакета обновления 5 (CU5).
Ни одна из групп AD, указанных в конфигурациях безопасности, не может быть в области DomainLocal. Вы можете проверить область группы AD, выполнив эти инструкции.
Учетные записи AD, которые могут использоваться для входа в кластер больших данных, разрешены из того же домена, который был настроен для Кластеров больших данных SQL Server. Поддержка входов из другого доверенного домена не планируется.

Следующие шаги

Подключение sql Server Кластеры больших данных: режим Active Directory

Устранение неполадок при интеграции кластера больших данных SQL Server с Active Directory

Концепция: развертывание SQL Server Кластеры больших данных в режиме Active Directory

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

Развертывание кластера больших данных SQL Server в режиме Active Directory

Подготовка развертывания

Трафик и порты

Задание переменных среды безопасности

Предоставление параметров безопасности и конечных точек

Проверка обратной DNS-записи для контроллера домена

Известные проблемы и ограничения

Следующие шаги

Обратная связь

Дополнительные ресурсы