Visão geral do uso do DNS zonal

Este documento descreve os benefícios e a abordagem recomendada para migrar suas cargas de trabalho e organização do DNS global para o DNS zonal.

O DNS zonal reduz o risco de interrupções entre regiões e melhora a confiabilidade geral dos projetos no Compute Engine.

Benefícios de usar nomes DNS zonais

Google Cloud oferece dois tipos de nomes DNS internos: zonal e global.

DNS por zona

Os nomes DNS zonais incluem o nome da instância do Compute Engine, a zona em que ela está localizada e o projeto que a contém. Esses nomes são resolvidos em uma zona específica. Como resultado, my-vm.zone1.google.com é exclusivo de zone1 e representa uma instância diferente de my-vm.zone2.google.com. Esse isolamento oferece um benefício fundamental:

  • Maior disponibilidade: se uma zona sofrer uma interrupção, isso não afetará a resolução de DNS em outras zonas, o que levará a uma maior disponibilidade para seus aplicativos.

O DNS zonal é o método de resolução de DNS interno padrão para organizações criadas após 6 de setembro de 2018.

DNS global

Os nomes DNS globais não incluem a zona em que a instância está localizada. Isso significa que cada instância precisa ter um nome DNS exclusivo em todas as zonas do projeto. Essa abordagem tem uma desvantagem significativa:

  • Ponto único de falha: se o serviço de DNS global tiver problemas, isso poderá afetar todas as instâncias, independentemente da zona em que estão localizadas em. Isso pode causar os seguintes problemas:
    • Não é possível criar novas instâncias: talvez não seja possível criar novas instâncias em nenhuma região que esteja com falhas no plano de controle.
    • Interrupções de serviço: serviços críticos do Compute Engine, como escalonamento automático ou recuperação automática para grupos de instâncias gerenciadas (MIGs), podem não funcionar corretamente.

Abordagem recomendada para migrar do DNS global para o DNS zonal

Em geral, o processo de migração do DNS global para o DNS zonal tem duas etapas:

  1. Configure novos projetos para usar o DNS zonal por padrão.
  2. Migre projetos atuais do DNS global para o DNS zonal mudando a configuração de metadados do DNS interno.

Alguns projetos podem não ser compatíveis com o DNS zonal. Esses projetos exigem análise e solução de problemas antes de serem migrados para o DNS zonal.

Orientações de compatibilidade do projeto

O Compute Engine verifica os 30 dias anteriores do histórico de DNS interno para determinar se é possível migrar para o DNS zonal sem fazer mudanças no código. Mesmo que o projeto seja recomendado para migração, o Google recomenda que você verifique se a configuração específica da carga de trabalho está pronta para a mudança para o DNS zonal. Para garantir que tudo funcione sem problemas após a migração, revise os seguintes fatores ambientais:

1. Domínios de pesquisa de DNS (somente Linux ou Unix)

Ao mudar para o DNS zonal, o Compute Engine adiciona um novo domínio ao caminho de pesquisa da instância.

  • Quando verificar:se você executar distribuições mais antigas do Linux ou Unix que usam a versão 2.25 ou anterior do glibc, o sistema terá um limite máximo de seis domínios de pesquisa.

  • Quando pular:se a instância executar um dos seguintes sistemas operacionais, não será necessário verificar nada:

    • Windows
    • Container-Optimized OS
    • Debian 10 ou posterior
    • Fedora CoreOS 27 ou posterior
    • RHEL 8 ou posterior
    • Ubuntu 18.04 ou posterior
    • Imagens personalizadas que usam a versão 2.26 ou posterior do glibc

Como verificar seu ambiente:

  1. Conecte-se à instância do Linux e verifique a versão do glibc executando o seguinte comando:

    ldd --version

  2. Se você estiver na versão 2.25 ou anterior do glibc, consulte seus domínios de pesquisa atuais executando o seguinte comando:

    cat /etc/resolv.conf

    A linha search na saída mostra os domínios de pesquisa atuais. Não é possível ter mais de cinco domínios para adicionar um novo domínio de pesquisa com segurança e evitar exceder o limite de seis do SO.

Como mitigar:

Se a instância exceder o limite de domínio de pesquisa em uma versão afetada do SO, você poderá resolver a limitação usando uma das seguintes abordagens:

  • Criar uma nova instância: crie uma instância de substituição usando uma imagem de SO compatível (como Debian 10 ou posterior ou RHEL 8 ou posterior).
  • Atualizar a instância atual: atualize o SO convidado na instância de computação para que ela execute um sistema operacional compatível.

2. Comprimento do nome da instância (sistemas operacionais legados)

O DNS zonal anexa um qualificador zonal ao nome de domínio totalmente qualificado (FQDN, na sigla em inglês) interno, tornando o nome geral mais longo.

  • Quando verificar:sistemas legados, como o Windows Server 2003 ou versões anteriores, têm um limite de 15 caracteres devido a convenções NetBIOS mais antigas.
  • O que fazer:se você usar esses sistemas legados, verifique se os nomes DNS zonais mais longos não excedem esse limite de caracteres.

As imagens modernas do SO Windows não são afetadas.

Como mitigar:

Se um nome de instância em um SO legado exceder 15 caracteres após anexar o qualificador zonal, você poderá resolver o problema usando um dos seguintes métodos:

  • Renomear a instância: interrompa a instância e renomeie-a para que o FQDN combinado permaneça dentro do limite de 15 caracteres do NetBIOS.
  • Fazer upgrade do sistema operacional: atualize o SO convidado da instância de computação para uma imagem moderna do sistema operacional Windows para a qual as restrições de nomenclatura do NetBIOS não se aplicam mais.

3. Redes VPC compartilhadas

Se a infraestrutura usar projetos de serviço conectados usando uma VPC compartilhada, a resolução de nomes se comportará de maneira um pouco diferente depois que você mudar para o DNS zonal.

  • O que fazer:para garantir uma comunicação perfeita na VPC compartilhada, verifique se os aplicativos resolvem nomes de instâncias nesses projetos de serviço usando o FQDN zonal. O FQDN zonal inclui o nome da zona específica.

A seguir