在 Active Directory 模式下部署 SQL Server 大数据群集
本文介绍如何在 Active Directory 模式下部署 SQL Server 大数据群集。 本文中的步骤要求访问 Active Directory 域。 在继续操作之前，需要完成在 Active Directory 模式下部署 SQL Server 大数据群集中所说明的要求。
重要
Microsoft SQL Server 2019 大数据群集附加产品将停用。 对 SQL Server 2019 大数据群集的支持将于 2025 年 2 月 28 日结束。 具有软件保障的 SQL Server 2019 的所有现有用户都将在平台上获得完全支持，在此之前，该软件将继续通过 SQL Server 累积更新进行维护。 有关详细信息，请参阅公告博客文章和 Microsoft SQL Server 平台上的大数据选项。
准备部署
要部署具有 AD 集成的大数据群集，需要提供一些附加信息，在 AD 中创建与大数据群集相关的对象。
通过使用 kubeadm-prod 配置文件或 openshift-prod（从 CU5 版本开始），你将自动获得 AD 集成所需的安全相关信息和终结点相关信息的占位符。
此外，还需要提供大数据群集将用于在 AD 中创建必要对象的凭据。 这些凭据作为环境变量提供。
流量和端口
验证是否有任何防火墙或第三方应用程序允许 Active Directory 通信所需的端口。
通过这些协议向 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 集成需要以下参数。 使用本文后面显示的 config replace 命令将这些参数添加到 control.json 和 bdc.json 文件中。 以下所有示例都使用示例域 contoso.local。
security.activeDirectory.ouDistinguishedName：组织单位 (OU) 的可分辨名称，其中将添加群集部署创建的所有 AD 帐户。 如果域名为contoso.local，则 OU 可分辨名称为：OU=BDC,DC=contoso,DC=local。security.activeDirectory.dnsIpAddresses：包含域的 DNS 服务器 IP 地址的列表。security.activeDirectory.domainControllerFullyQualifiedDns：域控制器的 FQDN 列表。 FQDN 包含域控制器的计算机/主机名。 如果有多个域控制器，可以在此处提供列表。 示例：HOSTNAME.CONTOSO.LOCAL。重要
当多个域控制器为域提供服务时，使用主域控制器 (PDC) 作为安全配置中
domainControllerFullyQualifiedDns列表的第一个条目。若要获取 PDC 名称，在命令提示符处键入netdom query fsmo，然后按 Enter。security.activeDirectory.realm可选参数：大多数情况下，领域等同于域名。 对于领域不同于域名的情况，请使用此参数定义领域名称（例如CONTOSO.LOCAL）。 为此参数提供的值应为完全限定的值。security.activeDirectory.netbiosDomainName可选参数：这是 AD 域的 NETBIOS 名称。 在大多数情况下，这将是 AD 域名的第一个标签。 对于不同的情况，请使用此参数来定义 NETBIOS 域名。 此值不应包含任何点。 通常，此名称用于限定域中的用户帐户。 例如 CONTOSO\user，其中 CONTOSO 是 NETBIOS 域名。注意
对配置（其中，Active Directory 域名不同于使用 security.activeDirectory.netbiosDomainName 的 Active Directory 域名的 NETBIOS 名称）的支持从 SQL Server 2019 CU9 开始启用。
security.activeDirectory.domainDnsName：将用于群集的 DNS 域的名称（例如contoso.local）。security.activeDirectory.clusterAdmins：此参数采用一个 AD 组。 AD 组范围必须为通用或全局。 此组的成员将具有bdcAdmin群集角色，该角色将在群集中为他们授予管理员权限。 这意味着他们在 SQL Server 中具有sysadmin权限、在 HDFS 中具有superuser权限、连接到控制器时具有管理员权限。重要
部署开始之前，在 AD 中创建此组。 如果此 AD 组的范围为本地域，则部署失败。
security.activeDirectory.clusterUsers：大数据群集中常规用户（无管理员权限）的 AD 组列表。 此列表可以包括范围设置为通用组或全局组的 AD 组。 它们不能是本地域组。
此列表中的 AD 组映射到 bdcUser 大数据群集角色，需要对其授予对 SQL Server 的访问权限（请参阅 SQL Server 权限）或者对 HDFS 的访问权限（请参阅 HDFS 权限指南）。 当连接到控制器终结点时，这些用户只能使用 azdata bdc endpoint list 命令列出群集中的可用终结点。
有关如何更新 AD 组的这些设置的详细信息，请参阅管理 Active Directory 模式下的大数据群集访问。
提示
若要在 Azure Data Studio 中连接到 SQL Server 主机时启用 HDFS 浏览体验，必须向具有 bdcUser 角色的用户授予 VIEW SERVER STATE 权限，因为 Azure Data Studio 使用 sys.dm_cluster_endpoints DMV 将所需的 Knox 网关终结点连接到 HDFS。
重要
部署开始之前，请在 AD 中创建这些组。 如果这些 AD 组中的任何一个范围为本地域，则部署失败。
重要
如果你的域用户具有大量组成员身份，则应使用自定义 bdc.json 部署配置文件，以调整网关设置 httpserver.requestHeaderBuffer 的值（默认值为 8192）和 HDFS 设置 hadoop.security.group.mapping.ldap.search.group.hierarchy.levels 的值（默认值为 10）。 这是一种最佳做法，可以避免网关和/或 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可选参数：布尔值，指示是否应在自动生成的 AD 帐户上启用 AES 128 和 AES 256。 默认值为false。 当此参数设置为true时，在大数据群集部署期间，将在自动生成的 AD 对象上检查以下标志：“此帐户支持 Kerberos AES 128 位加密”和“此帐户支持 Kerberos AES 256 位加密”。
注意
参数 security.activeDirectory.enableAES 从 SQL Server 大数据群集 CU13 开始提供。 如果大数据群集的版本低于 CU13，需要执行以下步骤：
- 运行
azdata bdc rotate -n <your-cluster-name>命令。此命令将轮换群集中的密钥表，只有这样，才能确保密钥表中的 AES 条目正确。 有关详细信息，请参阅 azdata bdc。 此外，在指定的 OU 中进行初始部署期间，azdata bdc rotate将轮换自动生成的 AD 对象的密码。 - 在初始大数据群集部署期间提供的 OU 中每个自动生成的 AD 对象上设置以下标志：“此帐户支持 Kerberos AES 128 位加密”和“此帐户支持 Kerberos AES 256 位加密”。 在域控制器上执行 PowerShell 脚本
Get-ADUser -Filter * -SearchBase '<OU Path>' | Set-ADUser -replace @{ 'msDS-SupportedEncryptionTypes' = '24' }即可实现此目的，该脚本将在<OU Path>参数指定的 OU 中的每个帐户上设置 AES 字段。
重要
在部署开始之前，在 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 名称。 如果未在control.json文件的 active directory 部分指定此参数的值，默认情况下，将使用大数据群集名称（与 Kubernetes 命名空间名称相同）来计算子域设置的值。注意
通过子域设置传递的值不是新的 AD 域，而只是大数据群集内部使用的 DNS 域。
重要
从 SQL Server 2019 CU5 版本开始，需要安装或升级最新版本的 Azure Data CLI (
azdata) 才能利用这些新功能，并在同一域中部署多个大数据群集。请参阅概念：在 Active Directory 模式下部署 SQL Server 大数据群集，了解有关在同一 Active Directory 域中部署多个大数据群集的详细信息。
security.activeDirectory.accountPrefix：可选参数 此参数在 SQL Server 2019 CU5 版本中引入，以支持针对同一个域部署多个大数据群集。 此设置保证各种大数据群集服务的帐户名称的唯一性，这些名称必须在任意两个群集之间有所不同。 默认情况下，可以选择对帐户前缀名称进行自定义，子域名称用作帐户前缀。 如果子域名称长度超过 12 个字符，则将子域名的前 12 个字符用作帐户前缀。注意
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 版本中，部署配置文件中的安全配置部分的结构发生了明显的变化，并且所有 Active Directory 相关设置位于 control.json 文件的 security 下 json 树的新 activeDirectory 中。
注意
除了为此部分所述的子域提供不同的值，在同一 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\"]
可以根据需要替代 subdomain 和 accountPrefix 设置的默认值（仅从 SQL Server 2019 CU5 版本开始）。
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 条目。 在连接到不同群集终结点时，将使用这些名称。 例如，如果 SQL 主实例的 DNS 名称是 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"
可以在此处找到示例脚本，用于在具有 AD 集成的单节点 Kubernetes 群集 (kubeadm) 上部署 SQL Server 大数据群集。
注意
在某些情况下，无法适应新引入的 subdomain 参数。 例如，必须部署低于 CU5 的版本，并且已升级 Azure Data CLI (azdata)。 这不太可能发生，但如果需要还原到 CU5 之前的行为，可以在 control.json 的 active directory 部分中将 useSubdomain 参数设置为 false。 命令如下：
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.useSubdomain=false"
现在，你应该已经设置了所有必需的参数来部署具有 Active Directory 集成的大数据群集。
现在，你可使用 Azure Data CLI (azdata) 命令和 kubeadm-prod 部署配置文件部署与 Active Directory 集成的大数据群集。 有关如何部署大数据群集的完整文档，请参阅如何在 Kubernetes 上部署 SQL Server 大数据群集。
验证域控制器的反向 DNS 条目
请确保在 DNS 服务器中注册了域控制器本身的反向 DNS 条目（PTR 记录）。 可以通过对域控制器的 IP 地址运行 nslookup 来验证这一点，以查看是否可以将其解析为域控制器 FQDN。
已知问题和限制
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 大数据群集配置的同一域。 不支持启用来自其他受信任域的登录。
后续步骤
连接 SQL Server 大数据群集：Active Directory 模式
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈