Eventos
Obtenha a certificação no Microsoft Fabric gratuitamente!
19 de nov., 23 - 10 de dez., 23
Por tempo limitado, a equipe da Comunidade do Microsoft Fabric está oferecendo vouchers de exame DP-600 gratuitos.
Prepare-se agoraNão há mais suporte para esse navegador.
Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.
Aplica-se a: SQL Server 2019 (15.x)
Este artigo explica as atualizações da CU5 (Atualização Cumulativa 5) do SQL Server 2019, que permite a configuração de vários clusters de Big Data do SQL Server 2019. Vários Clusters de Big Data agora podem ser implantados e integrados ao mesmo Domínio do Active Directory.
Importante
O complemento Clusters de Big Data do Microsoft SQL Server 2019 será desativado. O suporte para Clusters de Big Data do SQL Server 2019 será encerrado em 28 de fevereiro de 2025. Todos os usuários existentes do SQL Server 2019 com Software Assurance terão suporte total na plataforma e o software continuará a ser mantido por meio de atualizações cumulativas do SQL Server até esse momento. Para obter mais informações, confira a postagem no blog de anúncio e as opções de Big Data na plataforma do Microsoft SQL Server.
Antes do SQL Server 2019 CU5, dois problemas impediam a implantação de vários Clusters de Big Data em domínios do AD.
O nome de domínio fornecido na implantação é usado como domínio DNS do seu AD (Active Directory). Isso significa que os pods podem se conectar entre si dentro da rede interna usando esse domínio DNS. Os usuários também se conectam aos pontos de extremidade do cluster de Big Data usando esse domínio DNS. Como resultado, qualquer SPN (Nome da Entidade de Serviço) criado para um serviço no cluster de Big Data tem o nome do pod, do serviço ou do ponto de extremidade do Kubernetes qualificado com esse domínio DNS do AD. Se um usuário implanta um segundo cluster no domínio, os SPNs gerados têm o mesmo FQDN, pois os nomes de pod e o nome de domínio DNS não são diferentes entre os clusters. Considere um caso em que o domínio DNS do AD é contoso.local
. Um dos SPNs gerados para o SQL Server do pool mestre no pod master-0
é MSSQLSvc/master-0.contoso.local:1433
. No segundo cluster que o usuário tenta implantar, o nome do pod para master-0
é o mesmo. O usuário fornece o mesmo domínio DNS do AD (contoso.local
) resultando na mesma cadeia de caracteres SPN. O Active Directory proíbe a criação de um SPN conflitante ocasionando uma falha de implantação para o segundo cluster.
Durante uma implantação do cluster de Big Data com um domínio do Active Directory, várias entidades de segurança de conta são geradas para serviços em execução dentro do Cluster de Big Data. Essas entidades são basicamente contas de usuário do AD. Antes do SQL Server 2019 CU5, os nomes dessas contas não eram exclusivos entre clusters. Isso se manifesta na tentativa de criar o mesmo nome de conta de usuário para um serviço específico no Cluster de Big Data em dois clusters diferentes. O segundo cluster que está sendo implantado enfrenta um conflito no AD e a conta não pode ser criada.
Os SPNs devem ser exclusivos em clusters. O nome de domínio DNS passado em tempo de implantação também precisa ser diferente. Você pode especificar nomes DNS diferentes com uma configuração introduzida recentemente no arquivo de configuração de implantação: subdomain
. Se o subdomínio diferir entre dois clusters e a comunicação interna puder ocorrer nesse subdomínio, os SPNs incluirão o subdomínio, alcançando a exclusividade necessária.
Observação
O valor passado pela configuração do subdomínio não é um novo domínio do AD, mas um domínio DNS que é usado internamente.
Vamos retornar ao caso da SPN do SQL Server do pool mestre. Se o subdomínio é bdc
, a SPN discutida é alterada para MSSQLSvc/master-0.bdc.contoso.local:1433
.
O nome do Cluster de Big Data ou o nome do namespace é usado para calcular o valor das configurações do subdomínio. Opcionalmente, você pode personalizar o valor do parâmetro de subdomínio recém-introduzido na especificação de configuração do Active Directory. Quando os usuários desejam substituir o nome do subdomínio, eles podem fazer isso usando o novo parâmetro de subdomínio na especificação de configuração do Active Directory.
Para atualizar nomes de conta e garantir a exclusividade, use prefixos de conta. O prefixo de conta é um segmento do nome da conta que é exclusiva entre dois clusters. O segmento restante do nome da conta pode ser constante. O novo formato de nome da conta se parece com o seguinte: <prefix>-<name>-<podId>
.
Observação
O Active Directory exige que os nomes das contas sejam limitados a 20 caracteres. O cluster de Big Data precisa usar oito dos caracteres para distinguir pods e StatefulSets. Isso deixa 12 caracteres para o prefixo da conta.
Você tem a opção de personalizar o nome da conta. Use o parâmetro accountPrefix
na especificação de configuração do Active Directory. O SQL Server 2019 CU5 introduz o accountPrefix
na especificação de configuração. Por padrão, o nome do subdomínio é usado como o prefixo da conta. Se o nome do subdomínio tiver mais de 12 caracteres, a substring inicial de 12 caracteres do nome do subdomínio será usada como prefixo da conta.
O subdomínio só se aplica ao DNS. Portanto, o novo nome de conta de usuário do LDAP é bdc-ldap@contoso.local
. O nome da conta não é bdc-ldap@bdc.contoso.local
.
Veja a seguir os parâmetros adicionados no SQL Server 2019 CU5 para configurar vários clusters em um domínio:
Não há nenhuma alteração necessária no domínio do AD ou no controlador de domínio para acomodar a implantação de vários clusters de Big Data no mesmo domínio do Active Directory. O subdomínio DNS será criado automaticamente no servidor DNS ao registrar nomes DNS de pontos de extremidade externos.
A seção activeDirectory na configuração do painel de controle control.json tem dois novos parâmetros opcionais: subdomain
e accountPrefix
. O nome do cluster é usado para cada um desses parâmetros. Forneça novos valores para essas configurações se você desejar substituir o comportamento padrão. O nome do cluster é o mesmo que o nome do namespace.
Você tem a opção de usar qualquer nome DNS de ponto de extremidade, desde que ele seja totalmente qualificado. Ele também não pode entrar em conflito com nenhum outro cluster de Big Data implantado no mesmo domínio. Você pode usar o valor de parâmetro do subdomínio para garantir que os nomes DNS sejam diferentes entre clusters. Considere o ponto de extremidade do gateway. Você pode usar o nome gateway
do ponto de extremidade e registrá-lo no servidor DNS automaticamente. Para fazer isso como parte da implantação do cluster de Big Data, use gateway.bdc1.contoso.local
como o nome DNS. Se bdc1
for o subdomínio e contoso.local
for o nome de domínio DNS do AD. Outros valores aceitáveis são: gateway-bdc1.contoso.local
ou simplesmente gateway.contoso.local
.
Veja a seguir um exemplo de configuração de segurança do Active Directory, caso você queira substituir subdomínio e accountPrefix.
"security": {
"activeDirectory": {
"ouDistinguishedName":"OU=contosoou,DC=contoso,DC=local",
"dnsIpAddresses": [ "10.10.10.10" ],
"domainControllerFullyQualifiedDns": [ "contoso-win2016-dc.contoso.local" ],
"domainDnsName":"contoso.local",
"subdomain": "bdc",
"accountPrefix": "myprefix",
"clusterAdmins": [ "contosoadmins" ],
"clusterUsers": [ "contosousers1", "contosousers2" ]
}
}
Veja abaixo um exemplo de especificação de ponto de extremidade para pontos de extremidades de painel de controle. Use qualquer valor para nomes DNS, contanto que eles sejam exclusivos e totalmente qualificados:
"endpoints": [
{
"serviceType": "NodePort",
"port": 30080,
"name": "Controller",
"dnsName": "control-bdc1.contoso.local"
},
{
"serviceType": "NodePort",
"port": 30777,
"name": "ServiceProxy",
"dnsName": "monitor-bdc1.contoso.local"
}
]
Isso não é obrigatório, mas é recomendado. Fornecer UOs separadas para clusters separados ajuda você a gerenciar as contas de usuário geradas.
Pode haver cenários em que você não poderá acomodar o parâmetro subdomain
recém-introduzido. Por exemplo, você precisa implantar uma versão anterior à CU5 e já atualizou a CLI de Dados do Azure (azdata
). Isso é muito improvável, mas se você precisar reverter para o comportamento de antes da versão CU5, defina o parâmetro useSubdomain
como false
na seção do Active Directory do control.json
.
O exemplo a seguir define useSubdomain
como false
para esse cenário.
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.useSubdomain=false"
Solucionar problemas de integração do Active Directory ao cluster de Big Data do SQL Server
Eventos
Obtenha a certificação no Microsoft Fabric gratuitamente!
19 de nov., 23 - 10 de dez., 23
Por tempo limitado, a equipe da Comunidade do Microsoft Fabric está oferecendo vouchers de exame DP-600 gratuitos.
Prepare-se agora