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

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

Prepare deployment

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

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

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

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

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

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

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

Следующие переменные среды предоставляют учетные данные для учетной записи службы доменных кластеров больших данных, которая будет использоваться для настройки интеграции 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: различающееся имя подразделения (подразделения), где будут добавлены все учетные записи AD, созданные при развертывании кластера. Если домен называется contoso.local, то отличительное имя подразделения: OU=BDC,DC=contoso,DC=local.

• security.activeDirectory.dnsIpAddresses: содержит список IP-адресов DNS-серверов домена.

• security.activeDirectory.domainControllerFullyQualifiedDns: список полного доменного имени контроллера домена. Полное доменное имя содержит имя компьютера или узла контроллера домена. Если у вас несколько контроллеров домена, вы можете указать список здесь. Пример: HOSTNAME.CONTOSO.LOCAL.

  Important

  Если несколько контроллеров домена обслуживают домен, используйте основной контроллер домена (PDC) в качестве первой записи в списке в domainControllerFullyQualifiedDns конфигурации безопасности. Чтобы получить имя PDC, введите netdom query fsmoв командной строке и нажмите клавишу ВВОД.

• security.activeDirectory.realm Необязательный параметр: в большинстве случаев область равна доменному имени. В случаях, когда они не совпадают, используйте этот параметр для определения имени области (например, CONTOSO.LOCAL). Значение, предоставленное для этого параметра, должно быть полностью квалифицированным.

• security.activeDirectory.netbiosDomainName Необязательный параметр: это имя NETBIOS домена AD. В большинстве случаев это будет первая метка доменного имени AD. В случаях, когда он отличается, используйте этот параметр для определения доменного имени NETBIOS. Это значение не должно содержать точек. Обычно это имя используется для определения учетных записей пользователей в домене. Например, CONTOSO\user, где contoso — это доменное имя NETBIOS.

  Note

  Поддержка конфигурации, в которой доменное имя Active Directory отличается от имени NETBIOS домена Active Directory, используя имя security.activeDirectory.netbiosDomainName , начиная с SQL Server 2019 CU9.

• security.activeDirectory.domainDnsName: имя домена DNS, который будет использоваться для кластера (например, contoso.local).

• security.activeDirectory.clusterAdmins: этот параметр принимает одну группу AD. Область группы AD должна быть универсальной или глобальной. Члены этой группы будут иметь bdcAdmin роль кластера, которая предоставит им права администратора в кластере. Это означает, что у них есть sysadmin разрешения в SQL Server, superuser разрешения в HDFS и разрешения администратора при подключении к конечной точке контроллера.

  Important

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

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

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

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

{
    ...
    "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значение , следующие флаги "Эта учетная запись поддерживает шифрование Kerberos AES 128 бит" и "Эта учетная запись поддерживает шифрование Kerberos AES 256 бит" будет проверяться на автоматически созданных объектах AD во время развертывания кластера больших данных.

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

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

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

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

  Note

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

  Important

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

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

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

  Note

  Active Directory требует, чтобы имена учетных записей были ограничены 20 символами. Кластер больших данных должен использовать 8 символов для различения модулей pod и StatefulSet. Это оставляет нас 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. В нем показано, как заменить значения параметров, связанных с 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\"]

При необходимости, начиная с выпуска SQL Server 2019 CU5, можно переопределить значения по умолчанию для настроек 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 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.

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-адрес контроллера домена, чтобы убедиться, что его можно разрешить в полное доменное имя контроллера домена.

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

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

• В настоящее время панель мониторинга поиска по журналам и панель мониторинга метрик не поддерживают проверку подлинности AD. Базовый набор имени пользователя и пароля при развертывании можно использовать для проверки подлинности на этих панелях мониторинга. Все остальные конечные точки кластера поддерживают проверку подлинности AD.

• Безопасный режим AD будет работать только в средах развертывания kubeadm и openshift, но пока не поддерживается в AKS или ARO. Профили развертывания kubeadm-prod и openshift-prod включают разделы безопасности по умолчанию.

• До выпуска SQL Server 2019 CU5 разрешено только один кластер больших данных на домен (Active Directory). Включение нескольких кластеров больших данных для каждого домена доступно начиная с выпуска CU5.

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

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

Next steps

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

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

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