Implantar vários Clusters de Big Data do SQL Server dentro do mesmo domínio do Active Directory

  • Artigo

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.

  • Um conflito de nomenclatura para nomes da entidade de serviço e domínio DNS
  • Nome da entidade de segurança da conta do domínio

O que são colisões de nome de objeto?

Conflito de SPN (nomes da entidade de serviço) e de nomenclatura de domínio DNS

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.

Nome da entidade de segurança da conta do domínio

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.

Como resolver colisões de nome

Etapas para resolver problemas de domínio SPN e DNS – SQL Server CU5 2019

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.

Como garantir a exclusividade do nome da conta

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.

Semântica

Veja a seguir os parâmetros adicionados no SQL Server 2019 CU5 para configurar vários clusters em um domínio:

subdomain

  • Campo opcional
  • Tipo de dados: cadeia de caracteres
  • Definição: um subdomínio DNS exclusivo a ser usado para este Cluster de Big Data. Esse valor deve ser diferente para cada cluster implantado no domínio do Active Directory.
  • Valor padrão: Quando não for fornecido, o nome do cluster será usado como o valor padrão
  • Comprimento máximo: 63 caracteres por rótulo (o rótulo sendo cada cadeia de caracteres separada por um ponto).
  • Comentários: Os nomes DNS do ponto de extremidade devem usar o subdomínio em seu FQDN.

accountPrefix

  • Campo opcional
  • Tipo de dados: cadeia de caracteres
  • Definição: um prefixo exclusivo para contas do AD que o Cluster de Big Data gerará. Esse valor deve ser diferente para cada cluster implantado no domínio do Active Directory.
  • Valor padrão: Quando não for fornecido, o nome do subdomínio será usado como o valor padrão. Quando o subdomínio não for fornecido, o nome do cluster será usado como o nome do subdomínio e, portanto, o nome do cluster também será herdado como accountPrefix. Se o subdomínio for fornecido e for um nome com várias partes (que contém um ou mais pontos), o usuário deverá fornecer um accountPrefix.
  • Comprimento máximo: 12 caracteres

Ajustes no domínio do AD e no servidor DNS

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.

Alterações no arquivo de configuração de implantação

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.

Alguns exemplos de configuração de segurança do Active Directory

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" 
            } 
        ]

Perguntas

Você precisa criar unidades organizacionais separadas para clusters diferentes?

Isso não é obrigatório, mas é recomendado. Fornecer UOs separadas para clusters separados ajuda você a gerenciar as contas de usuário geradas.

Como posso reverter para o comportamento de antes da versão SQL Server 2019 CU5?

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"

Próximas etapas

Solucionar problemas de integração do Active Directory ao cluster de Big Data do SQL Server