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

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

DNS por zona

Os nomes de DNS por zona 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 importante:

  • Disponibilidade aprimorada: se uma zona sofrer uma interrupção, isso não afetará a resolução de DNS em outras zonas, resultando em 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 de 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 suas instâncias, independentemente da zona em que elas estão localizadas. 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 qualquer região que esteja com falhas no plano de controle.
    • Interrupções de serviço: serviços essenciais do Compute Engine, como escalonamento automático ou recuperação automática para grupos gerenciados de instâncias (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 os 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 da migração para o DNS zonal.

Orientação sobre compatibilidade de projetos

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

1. Domínios de pesquisa 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 é necessário verificar nada:

    • Windows
    • Container-Optimized OS
    • Debian 10 ou posterior
    • Fedora CoreOS 27 ou mais recente
    • RHEL 8 ou mais recente
    • Ubuntu 18.04 ou posterior
    • Imagens personalizadas que usam a versão 2.26 ou mais recente 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 usando a versão 2.25 ou anterior do glibc, execute o seguinte comando para ver os domínios de pesquisa atuais:

    cat /etc/resolv.conf

    A linha search na saída mostra os domínios de pesquisa atuais. Você não pode 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, resolva a limitação usando uma das seguintes abordagens:

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

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

O DNS zonal acrescenta um qualificador zonal ao nome de domínio totalmente qualificado (FQDN) interno, o que aumenta o tamanho do nome geral.

  • Quando verificar:sistemas legados, como o Windows Server 2003 ou anterior, têm um limite de 15 caracteres para o nome devido a convenções mais antigas do NetBIOS.
  • O que fazer:se você usa esses sistemas legados, verifique se os nomes de 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 o nome de uma instância em um SO legado exceder 15 caracteres após anexar o qualificador zonal, resolva 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.
  • Faça upgrade do sistema operacional: atualize o SO convidado da instância de computação para uma imagem moderna do sistema operacional Windows em que as restrições de nomenclatura do NetBIOS não se aplicam mais.

3. Redes VPC compartilhadas

Se a infraestrutura usa projetos de serviço conectados por uma VPC compartilhada, a resolução de nomes se comporta de maneira um pouco diferente depois que você passa a usar o DNS zonal.

  • O que fazer:para garantir uma comunicação perfeita na sua 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