Conceber uma solução híbrida de Sistema de Nomes de Domínio com o Azure

Esta arquitetura de referência ilustra como projetar uma solução híbrida de DNS (Sistema de Nomes de Domínio) para resolver nomes para cargas de trabalho hospedadas no local e no Microsoft Azure. Essa arquitetura funciona para usuários e outros sistemas que estão se conectando a partir do local e da Internet pública.

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de Trabalho

A arquitetura é composta pelos seguintes componentes:

• Rede no local. A rede local representa um único datacenter conectado ao Azure por meio de uma conexão de Rota Expressa do Azure ou VPN (rede virtual privada). Nesse cenário, os seguintes componentes compõem a rede local:
  • Servidores DNS . Esses servidores representam dois servidores com serviço DNS instalado que estão agindo como resolvedor/encaminhador. Esses servidores DNS são usados para todos os computadores na rede local como servidores DNS. Os registros devem ser criados nesses servidores para todos os pontos de extremidade no Azure e no local.
  • Gateway. O gateway representa um dispositivo VPN ou uma conexão de Rota Expressa usada para se conectar ao Azure.
• Subscrição do Hub. A assinatura de hub representa uma assinatura do Azure usada para hospedar recursos de conectividade, gerenciamento e rede compartilhados em várias cargas de trabalho hospedadas no Azure. Esses recursos podem ser divididos em várias assinaturas, conforme descrito na arquitetura de escala empresarial.

  Nota

  A rede virtual do hub pode ser substituída por um hub de rede virtual de longa distância (WAN), caso em que os servidores DNS teriam que ser hospedados em uma rede virtual (VNet) do Azure diferente. Na arquitetura de escala empresarial, essa VNet é mantida em sua própria assinatura intitulada assinatura Identity.

  • Sub-rede do Azure Bastion. O serviço Azure Bastion na rede virtual do hub é usado para comunicação remota para máquinas virtuais (VMs) no hub e VNets spoke da Internet pública para fins de manutenção.
  • Sub-rede privada do ponto final. A sub-rede de ponto de extremidade privada hospeda pontos de extremidade privados para cargas de trabalho hospedadas no Azure em redes virtuais que não são emparelhadas ao hub. Com esse tipo de VNet desconectada, seus endereços IP podem entrar em conflito com outros endereços IP usados no Azure e no local.
  • Sub-rede do gateway. A sub-rede do gateway hospeda o gateway da VPN do Azure, ou Rota Expressa, que é usado para fornecer conectividade de volta ao datacenter local.
  • Sub-rede de serviços partilhados. A sub-rede de serviços compartilhados hospeda serviços que são compartilhados entre várias cargas de trabalho do Azure. Nesse cenário, essa sub-rede hospeda máquinas virtuais que executam Windows ou Linux que também são usadas como servidores DNS. Esses servidores DNS hospedam as mesmas zonas DNS que os servidores locais.
• Subscrição ligada. A assinatura conectada representa uma coleção de cargas de trabalho que exigem uma rede virtual e conectividade de volta à rede local.
  • VNet peering. Este componente é uma conexão de emparelhamento de volta à VNet do hub. Essa conexão permite a conectividade da rede local com o spoke e back através da VNet do hub.
  • Sub-rede padrão. A sub-rede padrão contém uma carga de trabalho de exemplo.
    • web-vmss. Este conjunto de escala de máquina virtual de exemplo hospeda uma carga de trabalho no Azure que pode ser acessada localmente, no Azure e na Internet pública.
    • Balanceador de carga. O balanceador de carga fornece acesso a uma carga de trabalho que uma série de VMs hospeda. O endereço IP desse balanceador de carga na sub-rede padrão deve ser usado para acessar a carga de trabalho do Azure e do datacenter local.
  • Sub-rede AppGateway. Essa sub-rede é a sub-rede necessária para o serviço Gateway de Aplicativo do Azure.
    • AppGateway. O Application Gateway fornece acesso à carga de trabalho de exemplo na sub-rede padrão para usuários da Internet pública.
    • WKLD1-PIP. Esse endereço é o endereço IP público usado para acessar a carga de trabalho de exemplo da Internet pública.
• Assinatura desconectada. A assinatura desconectada representa uma coleção de cargas de trabalho que não exigem conectividade de volta ao datacenter local e que usam o serviço de link privado.
  • PLSSubnet. A sub-rede de serviço de link privado (PLSSubnet) contém um ou mais recursos de serviço de link privado que fornecem conectividade a cargas de trabalho hospedadas na assinatura Conectada.
  • Sub-rede padrão. A sub-rede padrão contém uma carga de trabalho de exemplo.
    • web-vmss. Este conjunto de escala de máquina virtual de exemplo hospeda uma carga de trabalho no Azure que pode ser acessada localmente, no Azure e na Internet pública.
    • Balanceador de carga. O balanceador de carga fornece acesso a uma carga de trabalho que uma série de VMs hospeda. Esse balanceador de carga está conectado ao serviço de link privado para fornecer acesso aos usuários que vêm do Azure e do datacenter local.
  • Sub-rede AppGateway. Essa sub-rede é a sub-rede necessária para o serviço Application Gateway.
    • AppGateway. O Application Gateway fornece acesso à carga de trabalho de exemplo na sub-rede padrão para usuários da Internet pública.
    • WKLD2-PIP. Esse endereço é o endereço IP público usado para acessar a carga de trabalho de exemplo da Internet pública.
  • Sub-rede do Azure Bastion. O serviço Azure Bastion na rede virtual desconectada é usado para comunicação remota para VMs no hub e VNets spoke da Internet pública para fins de manutenção.

Componentes

• Rede Virtual. A Rede Virtual do Azure (VNet) é o bloco de construção fundamental para a sua rede privada no Azure. A VNet permite que muitos tipos de recursos do Azure, como as Máquinas Virtuais (VM) do Azure, se comuniquem com segurança entre si, com a Internet e com redes locais.

• Azure Bastion. O Azure Bastion é um serviço totalmente gerido que fornece um acesso RDP (Remote Desktop Protocol) e SSH (Secure Shell Protocol) mais seguro e uniforme a máquinas virtuais (VMs) sem qualquer exposição através de endereços IP públicos.

• Gateway de VPN. O Gateway VPN envia tráfego criptografado entre uma rede virtual do Azure e um local local pela Internet pública. Também pode utilizar o Gateway VPN para enviar tráfego encriptado entre redes virtuais do Azure através da rede Microsoft. Um gateway VPN é um tipo específico de gateway de rede virtual.

• Private Link. O Azure Private Link proporciona conectividade privada de uma rede virtual para serviços de plataforma como serviço (PaaS) do Azure, serviços do cliente ou para serviços de parceiros da Microsoft. Simplifica a arquitetura da rede e protege a ligação entre os pontos finais no Azure ao eliminar a exposição dos dados à Internet pública.

• Gateway de Aplicação. O Gateway de Aplicação do Azure é um balanceador de carga do tráfego da Web que lhe permite gerir o tráfego para as suas aplicações Web. Os balanceadores de carga tradicionais funcionam na camada de transporte (camada OSI 4 - TCP e UDP) e encaminham o tráfego com base no endereço IP de origem e porta, para uma porta e um endereço IP de destino.

Recomendações

As recomendações seguintes aplicam-se à maioria dos cenários. Siga-as, a não ser que tenha requisitos específicos que as anulem.

Estender o AD DS para o Azure (opcional)

Use zonas DNS integradas no AD DS para hospedar registros DNS para seu datacenter local e o Azure. Nesse cenário, há dois conjuntos de servidores DNS do AD DS: um local e outro na VNet de hub.

Recomendamos estender seu domínio do AD DS para o Azure. Também recomendamos configurar as VNets hub e spoke para usar os servidores AD DS DNS na VNet do hub para todas as VMs no Azure.

Configurar DNS split-brain

Certifique-se de que o DNS split-brain está em vigor para permitir que os sistemas do Azure, os utilizadores no local e os utilizadores da Internet acedam a cargas de trabalho com base no local a partir do qual estão a ligar-se.

Para cargas de trabalho conectadas e desconectadas, recomendamos os seguintes componentes para resolução de DNS:

• Zonas DNS do Azure para utilizadores da Internet.
• Servidores DNS para utilizadores locais e sistemas Azure.
• Zonas DNS privadas do Azure para resolução entre VNets do Azure.

Para entender melhor essa recomendação de cérebro dividido, considere a Carga de Trabalho 1, para a qual usaremos o wkld1.contoso.com FQDN (nome de domínio totalmente qualificado).

Nesse cenário, os usuários da Internet devem resolver esse nome para o endereço IP público que o Application Gateway expõe por meio de Wkld1-pip. Essa resolução é feita criando um registro de endereço (registro A) no DNS do Azure para a assinatura conectada.

Os usuários locais devem resolver o mesmo nome para o endereço IP interno do balanceador de carga na assinatura conectada. Essa resolução é feita criando um registro A nos servidores DNS na assinatura do hub.

Os sistemas do Azure podem resolver o mesmo nome para um endereço IP interno para o balanceador de carga na assinatura conectada criando um registro A no servidor DNS na assinatura do hub ou usando zonas DNS privadas. Quando estiver a utilizar zonas DNS privadas, crie manualmente um registo A na zona DNS privada ou ative o registo automático.

Usar zonas DNS privadas para um link privado

Em nosso cenário, a Carga de Trabalho 2 é hospedada em uma assinatura desconectada e o acesso a essa carga de trabalho para usuários locais e sistemas do Azure conectados é possível por meio de um ponto de extremidade privado na VNet do hub. No entanto, há uma terceira possibilidade de conexão para essa carga de trabalho: sistemas do Azure na mesma VNet que a Workload 2.

Para entender melhor as recomendações de DNS para a Carga de Trabalho 2, usaremos o wkld2.contoso.com FQDN e discutiremos as recomendações individuais.

Nesse cenário, os usuários da Internet devem resolver esse nome para o endereço IP público que o Application Gateway expõe por meio de Wkld2-pip. Essa resolução é feita criando um registro A no DNS do Azure para a assinatura conectada.

Os usuários locais e os sistemas do Azure conectados à VNet do hub e às VNets spoke devem resolver o mesmo nome para o endereço IP interno do ponto de extremidade privado na VNet do Hub. Essa resolução é feita criando um registro A nos servidores DNS na assinatura do hub.

Os sistemas do Azure na mesma VNet que a Workload 2 devem resolver o nome para o endereço IP do balanceador de carga na assinatura desconectada. Essa resolução é feita usando uma zona DNS privada no DNS do Azure nessa assinatura.

Os sistemas do Azure em VNets diferentes ainda podem resolver o endereço IP da Carga de Trabalho 2 se você vincular essas VNets à zona DNS privada que está hospedando o registro A para a Carga de Trabalho 2.

Ativar o registo automático

Ao configurar um link de rede virtual com uma zona DNS privada, você pode, opcionalmente, configurar o registro automático para todas as máquinas virtuais.

Se você estiver usando o servidor DNS do AD DS, configure as VMs do Windows para usar atualizações dinâmicas para computadores Windows para manter seus próprios registros DNS atualizados nos servidores DNS do AD DS. Recomendamos habilitar atualizações dinâmicas e configurar os servidores DNS para permitir apenas atualizações seguras.

As VMs Linux não suportam atualizações dinâmicas seguras. Para computadores Linux locais, use o protocolo DHCP (Dynamic Host Configuration Protocol) para registrar registros DNS nos servidores DNS do AD DS.

Para VMs Linux no Azure, use um processo automatizado.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Escalabilidade

• Por região do Azure ou datacenters locais, considere usar pelo menos dois servidores DNS cada.
• Observe como isso é feito no cenário anterior, com servidores DNS locais e na rede virtual do hub.

Disponibilidade

• Considere a colocação de servidores DNS. Conforme descrito na seção de considerações de escalabilidade, os servidores DNS devem ser colocados perto dos usuários e sistemas que precisam acessar a eles.
  • Por região do Azure. Cada região do Azure tem seu próprio hub VNet ou hub vWAN. É aqui que os servidores DNS devem ser implantados.
  • Por datacenter local. Você também deve ter um par de servidores DNS por datacenter local para usuários e sistemas nesses locais.
  • Para cargas de trabalho isoladas (desconectadas), hospede uma zona DNS privada e uma zona DNS pública para cada assinatura para gerenciar registros DNS split-brain.

Capacidade de gestão

• Considere a necessidade de registros DNS para serviços de plataforma como serviço (PaaS).
• Você também deve considerar a resolução de DNS para serviços PaaS que usam um ponto de extremidade privado. Use uma zona DNS privada para isso e use seu pipeline de DevOps para criar registros nos servidores DNS.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

• Se você precisar do uso do DNSSEC, considere que o DNS do Azure atualmente não oferece suporte a ele.
• Para validação DNSSEC, implante um servidor DNS personalizado e habilite a validação DNSEC.
• A Proteção contra DDoS do Azure, combinada com as práticas recomendadas de design de aplicativos, fornece recursos aprimorados de mitigação de DDoS para fornecer mais defesa contra ataques DDoS. Você deve habilitar a Proteção DDOS do Azure em qualquer rede virtual de perímetro.

DevOps

• Automatize a configuração dessa arquitetura combinando modelos do Azure Resource Manager para a configuração de todos os recursos. As zonas DNS públicas e privadas oferecem suporte ao gerenciamento completo da CLI do Azure, PowerShell, .NET e API REST.
• Se você estiver usando um pipeline de integração contínua e desenvolvimento contínuo (CI/CD) para implantar e manter cargas de trabalho no Azure e no local, também poderá configurar o registro automático de registros DNS.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

• Os custos da zona DNS do Azure baseiam-se no número de zonas DNS alojadas no Azure e no número de consultas DNS recebidas.
• Utilize a calculadora de preços do Azure para prever os custos. Os modelos de preços para o DNS do Azure são explicados aqui.
• O modelo de cobrança do Azure ExpressRoute é baseado em dados limitados, que cobram por gigabyte pela transferência de dados de saída, ou dados ilimitados, que cobram uma taxa mensal, incluindo toda a transferência de dados.
• Se você estiver usando VPN, em vez da Rota Expressa, o custo depende da SKU do gateway de rede virtual e é cobrado por hora.

Próximos passos

Saiba mais sobre as tecnologias de componentes:

• O que é o DNS do Azure?
• O que é a Rede Virtual do Azure?
• O que é o Azure ExpressRoute?
• O que é o Azure Bastion?

Recursos relacionados

Explore arquiteturas relacionadas:

• Compartilhamento de arquivos na nuvem corporativa do Azure
• Aplicação de N camadas com Apache Cassandra
• SaaS multilocatário no Azure
• Estenda uma rede local usando a Rota Expressa