Partilhar via

Posicionamento adequado de controladores de domínio e considerações de site

A definição adequada do local é fundamental para o desempenho. Os clientes que perdem acesso ao site podem experienciar um desempenho insatisfatório para autenticações e consultas. Além disso, com a introdução do IPv6 nos clientes, a solicitação pode vir do endereço IPv4 ou IPv6 e o Ative Directory precisa ter sites devidamente definidos para IPv6. O sistema operacional prefere IPv6 a IPv4 quando ambos estão configurados.

A partir do Windows Server 2008, o controlador de domínio tenta usar a resolução de nomes para fazer uma pesquisa inversa para determinar o site em que o cliente deve estar. Isso pode causar o esgotamento do pool de threads ATQ e fazer com que o controlador de domínio pare de responder. A resolução apropriada para isso é definir corretamente a topologia de site para IPv6. Como solução alternativa, pode-se otimizar a infraestrutura de resolução de nomes para responder rapidamente às solicitações do controlador de domínio. Para saber mais, veja Resposta atrasada do Controlador de Domínio do Windows Server 2008 ou Windows Server 2008 R2 a solicitações LDAP ou Kerberos.

Uma área adicional de consideração é localizar DCs de leitura/gravação para cenários em que os RODCs estão em uso. Certas operações requerem acesso a um Controlador de Domínio gravável ou visam um Controlador de Domínio gravável quando um Controlador de Domínio Read-Only é suficiente. A otimização desses cenários tomaria dois caminhos:

  • Contactar Controladores de Domínio modificáveis quando um Controlador de Domínio Read-Only for suficiente. Isso requer uma alteração no código do aplicativo.
  • Onde pode ser necessário um Controlador de Domínio com capacidade de gravação. Coloque controladores de domínio de leitura-gravação em locais centrais para minimizar a latência.

Para mais informações, consultar:

Otimizar para referências

As referências são como as consultas LDAP são redirecionadas quando o controlador de domínio não hospeda uma cópia da partição consultada. Quando uma referência é retornada, ela contém o nome distinto da partição, um nome DNS e um número de porta. O cliente usa essas informações para continuar a consulta em um servidor que hospeda a partição. Este é um cenário DCLocator onde todas as definições de sites de recomendações e o posicionamento dos controladores de domínio são mantidos, mas os aplicativos que dependem de redirecionamentos são frequentemente negligenciados. É recomendável garantir que a Topologia do AD, incluindo definições de site e posicionamento do controlador de domínio, reflita adequadamente as necessidades do cliente. Além disso, isso pode incluir ter controladores de domínio de vários domínios em um único site, ajustar as configurações de DNS ou realocar o site de um aplicativo.

Considerações de otimização para relações de confiança

Em um cenário intraflorestal, as relações de confiança são processadas de acordo com a seguinte hierarquia de domínio: Grand-Child Domínio -> Domínio Filho -> Domínio Raiz da Floresta -> Domínio Filho -> Domínio Grand-Child. Isso significa que canais seguros na raiz da floresta e em cada nível superior podem ficar sobrecarregados devido à agregação de solicitações de autenticação que transitam pelos controladores de domínio na hierarquia de confiança. Isso também pode sofrer atrasos em Diretórios Ativos de grande dispersão geográfica, quando a autenticação também precisa transitar ligações com alta latência, impactando o fluxo mencionado. Sobrecargas podem ocorrer em cenários de confiança entre florestas e em níveis hierárquicos inferiores. As seguintes recomendações aplicam-se a todos os cenários:

  • Ajuste corretamente a API MaxConcurrentpara suportar a carga através do canal seguro. Para obter mais informações, consulte Como fazer o ajuste de desempenho para autenticação NTLM usando a configuração MaxConcurrentApi.

  • Crie atalhos de confiança conforme apropriado com base no volume de trabalho.

  • Certifique-se de que cada controlador de domínio no domínio é capaz de executar a resolução de nomes e se comunicar com os controladores de domínio no domínio confiável.

  • Certifique-se de que as considerações de localidade sejam levadas em conta para relações de confiança.

  • Ative o Kerberos onde for possível e reduza o uso do canal seguro para minimizar o risco de enfrentar limitações nas APIs MaxConcurrent.

Os cenários de confiança entre domínios são uma área que tem sido consistentemente um ponto problemático para muitos clientes. Problemas de resolução de nomes e conectividade, geralmente devido a firewalls, causam esgotamento de recursos no controlador de domínio confiável e afetam todos os clientes. Além disso, um cenário muitas vezes negligenciado é otimizar o acesso a controladores de domínio confiáveis. As áreas-chave para garantir que isso funcione corretamente são as seguintes:

  • Verifique se a resolução de nomes DNS e WINS que os controladores de domínio confiáveis estão usando pode resolver uma lista precisa de controladores de domínio para o domínio confiável.

    • Os registros adicionados estaticamente tendem a se tornar obsoletos e reintroduzir problemas de conectividade ao longo do tempo. Os encaminhamentos DNS, o DNS dinâmico e a fusão de infraestruturas WINS/DNS são mais sustentáveis a longo termo.

    • Garanta a configuração adequada de encaminhadores, encaminhamentos condicionais e cópias secundárias para zonas de pesquisa direta e inversa para cada recurso no ambiente que um cliente possa precisar acessar. Mais uma vez, isto requer manutenção manual e tende a tornar-se obsoleto. A consolidação das infraestruturas é ideal.

  • Os controladores de domínio no domínio confiável tentarão localizar primeiro os controladores de domínio no domínio confiável que estão no mesmo site e, em seguida, fazer failback para os localizadores genéricos.

    • Para saber mais sobre como o DCLocator funciona, veja Localizando um controlador de domínio no site mais próximo.

    • Convirja nomes de site entre os domínios confiáveis e confiáveis para refletir o controlador de domínio no mesmo local. Verifique se os mapeamentos de sub-rede e endereço IP estão vinculados corretamente a sites em ambas as florestas. Para obter mais informações, consulte Localizador de Domínio numa Confiança de Floresta.

    • Verifique se as portas estão abertas, de acordo com as necessidades do DCLocator, para o local do controlador de domínio. Se existirem firewalls entre os domínios, certifique-se de que os firewalls estão configurados corretamente para TODAS as relações de confiança. Se os firewalls não estiverem abertos, o controlador de domínio confiável ainda tentará acessar o domínio confiável. Se a comunicação falhar por qualquer motivo, o controlador de domínio de confiança eventualmente expirará a solicitação para o controlador de domínio confiável. No entanto, esses tempos limite podem levar vários segundos por solicitação e podem esgotar as portas de rede no controlador de domínio confiável se o volume de solicitações de entrada for alto. O cliente pode experimentar as esperas para o tempo limite no controlador de domínio como threads suspensos, que podem se traduzir em aplicativos suspensos (se o aplicativo executar a solicitação no thread em primeiro plano). Para obter mais informações, consulte Como configurar um firewall para domínios e relações de confiança.

    • Use DnsAvoidRegisterRecords para eliminar controladores de domínio de baixo desempenho ou alta latência, como aqueles em sites satélite, da publicidade para os localizadores genéricos. Para obter mais informações, consulte Como otimizar o local de um controlador de domínio ou catálogo global que reside fora do site de um cliente.

      Note

      Há um limite prático de cerca de 50 para o número de controladores de domínio que o cliente pode consumir. Estes devem ser os controladores de domínio com maior capacidade e mais otimizados para o site.

    • Considere colocar controladores de domínio de domínios fidedignos e de confiança na mesma localização física.

Para todos os cenários de confiança, as credenciais são roteadas de acordo com o domínio especificado nas solicitações de autenticação. Isso também é verdade para consultas às APIs LookupAccountName e LsaLookupNames (bem como outras, essas são apenas as mais comumente usadas). Quando os parâmetros de domínio para essas APIs recebem um valor NULL, o controlador de domínio tentará localizar o nome da conta especificado em cada domínio confiável disponível.

Referências Adicionais

  • Last updated on