Fundamentos do Azure DNS e do Balanceador de Carga

O DNS (Sistema de Nomes de Domínio) traduz nomes de domínio legíveis por pessoas, como api.mycompany.com, em endereços IP usados pelos computadores para se comunicar. O Azure oferece dois serviços DNS: o Azure DNS, para hospedar zonas DNS públicas (domínios voltados para a internet), e o Azure Private DNS, para a resolução de nomes interna nas VNets. Sem uma configuração DNS adequada, os recursos do Azure precisam ser referenciados por seus endereços IP, tornando as arquiteturas frágeis — qualquer alteração de IP interrompe todas as configurações dependentes. O Azure DNS é um serviço altamente disponível e distribuído globalmente, sustentado pela rede anycast da Microsoft.

As zonas públicas do Azure DNS hospedam registros DNS para domínios acessíveis pela internet. Você delega seu domínio, registrado com um registrador como GoDaddy, ao Azure DNS atualizando os registros NS do domínio para apontarem para os servidores de nomes do Azure. Depois da delegação, você gerencia todos os registros DNS (A, CNAME, MX, TXT etc.) pelo portal do Azure ou pela CLI, em vez de usar um provedor DNS separado. As zonas públicas do Azure DNS oferecem disponibilidade com SLA de 100%, propagação global em menos de um segundo e acesso controlado por RBAC, para que somente membros autorizados da equipe possam modificar os registros DNS.

As zonas privadas do Azure DNS fornecem resolução de nomes para recursos dentro das VNets sem expor os registros DNS publicamente. Por exemplo, você pode criar uma zona privada myapp.internal e registrar suas VMs para que sejam resolvidas por nome (db.myapp.internal), em vez de por IP. As zonas privadas do DNS são vinculadas a VNets — somente os recursos nas VNets vinculadas podem resolver os registros privados. Você também pode habilitar o registro automático, que cria automaticamente registros DNS para as VMs quando elas ingressam na VNet, mantendo o DNS sincronizado sem gerenciamento manual.

Os Private Endpoints — para serviços como Azure SQL, Blob Storage e Key Vault — exigem que o DNS resolva o nome de host público do serviço para o IP privado, em vez do IP público. O Azure oferece zonas privadas do DNS para cada serviço, por exemplo, privatelink.blob.core.windows.net para Blob Storage. Quando você cria um Private Endpoint, o Azure cria um registro DNS A nessa zona privada apontando para o IP privado. Vincule essa zona à sua VNet, e todas as consultas DNS para a URL da conta de armazenamento serão resolvidas automaticamente para o IP privado — roteando o tráfego pela rede de backbone privada sem alterações no código do aplicativo.

O Azure Load Balancer distribui o tráfego de rede de entrada entre vários recursos de backend — VMs ou instâncias em um conjunto de dimensionamento — para garantir que nenhum recurso fique sobrecarregado. Ele opera na Camada 4 (Camada de Transporte) do modelo OSI: roteia pacotes TCP e UDP com base no IP e na porta de origem e destino, sem inspecionar o conteúdo HTTP. O Azure Load Balancer é um serviço altamente disponível, com redundância de zona e SLA de 99,99% (SKU Standard), e oferece balanceamento de carga de entrada, da internet ou da VNet, e SNAT de saída para o acesso das VMs à internet.

O Azure Load Balancer tem quatro componentes principais: configuração de IP de frontend — o IP público ou privado ao qual os clientes se conectam. pool de backend — o conjunto de VMs ou instâncias de um conjunto de dimensionamento que recebe o tráfego. regras de balanceamento de carga — mapeiam um IP:porta de frontend para uma porta de backend e especificam o algoritmo de distribuição de carga (hash de 5 tuplas, por padrão). sondas de integridade — verificam periodicamente cada instância de backend; as instâncias que falham nas verificações deixam de receber novas conexões até se recuperarem. Juntos, esses componentes definem como o tráfego é recebido, verificado e distribuído.

As sondas de integridade são verificações periódicas enviadas pelo Load Balancer a cada instância de backend para determinar se ela está saudável e deve receber tráfego. Você configura o protocolo da sonda (HTTP, HTTPS ou TCP), a porta e o intervalo. Para sondas HTTP/HTTPS, o Load Balancer envia uma solicitação GET para um caminho de URL especificado — a instância é considerada saudável se retornar HTTP 200. Para sondas TCP, uma conexão TCP bem-sucedida indica que a instância está saudável. Se um backend falhar em um número configurável de sondas consecutivas, o Load Balancer deixará de enviar novas conexões para ele até que volte a ser aprovado nas sondas. Isso proporciona tolerância automática a falhas sem intervenção manual.

O Azure Load Balancer está disponível em dois SKUs: Basic — gratuito, compatível com até 300 instâncias de backend, sem SLA, sem suporte a zonas de disponibilidade e sem requisito de NSG seguro por padrão. Standard — pago (aproximadamente US$ 20 por mês de custo base), compatível com até 1.000 instâncias de backend, SLA de 99,99%, frontend com redundância de zona, seguro por padrão (exige regras NSG explícitas para permitir o tráfego) e compatibilidade com vários IPs de frontend. Para qualquer carga de trabalho de produção, o SKU Standard é altamente recomendado. A Microsoft está descontinuando o SKU Basic — novas implantações devem sempre usar o Standard.

O Azure Load Balancer pode ser implantado em duas configurações: Load Balancer público (externo) — tem um IP público no frontend e distribui o tráfego da internet entre as VMs de backend. É usado para aplicativos voltados para a internet, como servidores Web e gateways de API. Load Balancer interno (privado) — tem um IP privado no frontend, dentro de uma VNet, e distribui o tráfego entre recursos da VNet. É usado em aplicativos multicamadas nos quais o Load Balancer da camada de aplicativo não deve ser acessível pela internet — somente pela camada Web na mesma VNet. Você pode implantar ambos simultaneamente: um LB público para a camada Web e um LB interno para a camada de aplicativo.

O Azure oferece dois serviços principais de balanceamento de carga para diferentes cenários: Balanceador de Carga do Azure — Camada 4, TCP/UDP, latência ultrabaixa e capacidade de lidar com milhões de conexões por segundo. É ideal para cargas de trabalho que não usam HTTP ou quando a prioridade é obter o máximo de taxa de transferência e a menor latência possível. Gateway de Aplicativos do Azure — Camada 7, HTTP/HTTPS, entende caminhos de URL e cabeçalhos, e inclui Firewall de Aplicativos Web (WAF), terminação SSL, afinidade de sessão baseada em cookies e roteamento baseado em URL. É ideal para aplicações Web que precisam de balanceamento de carga com reconhecimento de conteúdo, descarregamento de TLS e proteção WAF. Para balanceamento de carga TCP simples, use o Balanceador de Carga. Para aplicações Web, o Gateway de Aplicativos agrega um valor significativo.

O DNS e o Balanceador de Carga trabalham juntos para criar pontos de extremidade resilientes e fáceis de usar. Um padrão comum: 1) crie um Balanceador de Carga do Azure com um IP público Standard e um pool de back-end de VMs de servidores Web. 2) crie um registro DNS CNAME no Azure DNS apontando www.mycompany.com para o IP público (ou nome DNS) do Balanceador de Carga. 3) quando os usuários acessarem www.mycompany.com, o DNS resolverá o endereço para o IP do Balanceador de Carga, que distribuirá as solicitações entre as instâncias de VM íntegras. Isso fornece uma URL fácil de usar e distribuição automática de tráfego com tolerância a falhas.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) apresentados nesta lição.

Nesta lição, você aprendeu que: o Azure DNS hospeda zonas DNS públicas e privadas com disponibilidade próxima de 100%, permitindo usar nomes legíveis para recursos do Azure; as zonas DNS privadas com registro automático mantêm os registros DNS da VNet atualizados sem gerenciamento manual; e o Balanceador de Carga do Azure distribui o tráfego TCP/UDP da Camada 4 entre instâncias de VM íntegras do back-end, usando sondas de integridade para detectar e ignorar automaticamente instâncias com falha. Em seguida, iniciaremos o curso Bancos de Dados do Azure, começando pelo Banco de Dados SQL do Azure.