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

  • Статья

В этой статье описывается развертывание кластера больших данных 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 к DNS-серверам.

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

Служба Порт
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 в конфигурации безопасности. Чтобы получить имя основного контроллера домена, введите 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, областью действия которых является универсальная или глобальная группа. Они не могут быть локальными доменными группами.

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

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

Совет

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

Важно!

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

Важно!

Если пользователи домена имеют большое количество членств в группах, следует настроить значения параметров шлюза httpserver.requestHeaderBuffer (значение по умолчанию — 8192) и HDFS hadoop.security.group.mapping.ldap.search.group.hierarchy.levels (значение по умолчанию — 10) с помощью пользовательского файла конфигурации развертывания 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, необходимо выполнить следующие действия:

  1. Выполните команду azdata bdc rotate -n <your-cluster-name>, которая сменит keytab в кластере, чтобы обеспечить правильность записей AES в keytab. Дополнительные сведения см. в описании команды azdata bdc. Кроме того, azdata bdc rotate сменит пароли объектов AD, созданных автоматически во время первоначального развертывания в указанном подразделении.
  2. Для каждого автоматически созданного объекта 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: необязательный параметр. Этот параметр появился в накопительном пакете обновления 5 (CU5) для SQL Server 2019 для поддержки развертывания нескольких кластеров больших данных в одном домене. С помощью этого параметра можно указать разные 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: необязательный параметр. Этот параметр появился в накопительном пакете обновления 5 (CU5) для SQL Server 2019 для поддержки развертывания нескольких кластеров больших данных в одном домене. Этот параметр гарантирует уникальность имен учетных записей для различных служб кластеров больших данных, которые должны различаться между двумя кластерами. Настройка имени префикса учетной записи является необязательной; по умолчанию в качестве префикса учетной записи используется имя поддомена. Если имя поддомена длиннее 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 в дереве JSON в разделе security в файле 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