Grunderna i Azure DNS och Load Balancer

DNS (Domain Name System) översätter människoläsbara domännamn (som api.mycompany.com) till IP-adresser som datorer använder för att kommunicera. Azure tillhandahåller två DNS-tjänster: Azure DNS för att vara värd för offentliga DNS-zoner (internetanslutna domäner) och Azure Private DNS för intern namnmatchning inom VNets. Utan korrekt DNS-konfiguration måste Azure-resurser refereras till med sina IP-adresser, vilket gör arkitekturer sköra – varje IP-ändring bryter alla beroende konfigurationer. Azure DNS är en mycket tillgänglig, globalt distribuerad tjänst som stöds av Microsofts anycast-nätverk.

Offentliga Azure DNS-zoner innehåller DNS-poster för domäner som är åtkomliga från internet. Domänen delegeras till Azure DNS genom att domänens NS-poster uppdateras så att de pekar på Azures namnservrar. Domänen kan vara registrerad hos en registrar som GoDaddy. När delegeringen är klar hanteras alla DNS-poster (A, CNAME, MX, TXT med flera) från Azure-portalen eller CLI i stället för hos en separat DNS-leverantör. Offentliga Azure DNS-zoner erbjuder 100 % SLA-tillgänglighet, global spridning på under en sekund och åtkomst som styrs med RBAC, så att endast behöriga teammedlemmar kan ändra DNS-poster.

Privata Azure DNS-zoner tillhandahåller namnmatchning för resurser i VNets utan att DNS-poster exponeras offentligt. Det går till exempel att skapa en privat zon myapp.internal och registrera virtuella datorer så att de kan slås upp med namn (db.myapp.internal) i stället för IP-adress. Privata DNS-zoner länkas till VNets – endast resurser i länkade VNets kan slå upp de privata posterna. Det går även att aktivera automatisk registrering, som automatiskt skapar DNS-poster för virtuella datorer när de ansluter till VNet-nätverket och håller DNS uppdaterat utan manuell hantering.

Private Endpoints (för tjänster som Azure SQL, Blob Storage och Key Vault) kräver att DNS översätter tjänstens offentliga värdnamn till den privata IP-adressen i stället för den offentliga IP-adressen. Azure tillhandahåller privata DNS-zoner för varje tjänst (t.ex. privatelink.blob.core.windows.net för Blob Storage). När en Private Endpoint skapas skapar Azure en DNS A-post i den privata zonen som pekar på den privata IP-adressen. Länka zonen till VNet-nätverket, så översätts alla DNS-uppslagningar för storage accountets URL automatiskt till den privata IP-adressen – trafiken dirigeras via det privata stamnätet utan ändringar i programkoden.

Azure Load Balancer distribuerar inkommande nätverkstrafik mellan flera backend-resurser (virtuella datorer eller instanser i en skalningsuppsättning) för att säkerställa att ingen enskild resurs överbelastas. Den verkar på lager 4 (transportlagret) i OSI-modellen – TCP- och UDP-paket dirigeras utifrån källans och målets IP-adress samt port, utan att HTTP-innehållet inspekteras. Azure Load Balancer är en mycket tillgänglig, zonredundant tjänst med ett 99,99-procentigt SLA (Standard SKU) och stöder både inkommande lastbalansering (från internet eller ett VNet) och utgående SNAT för virtuella datorers internettrafik.

Azure Load Balancer har fyra huvudkomponenter: Frontend IP configuration – den offentliga eller privata IP-adress som klienterna ansluter till. Backend pool – uppsättningen virtuella datorer eller instanser i en skalningsuppsättning som tar emot trafik. Load balancing rules – kopplar en frontend-IP-adress och port till en backend-port och anger algoritmen för trafikfördelning (5-tuple-hash som standard). Health probes – testar regelbundet varje backend-instans; instanser som misslyckas med hälsokontroller slutar ta emot nya anslutningar tills de återhämtar sig. Tillsammans definierar dessa komponenter hur trafiken tas emot, kontrolleras och distribueras.

Health probes är återkommande kontroller som lastbalanseraren skickar till varje backend-instans för att avgöra om den är frisk och bör ta emot trafik. Protokollet för kontrollen (HTTP, HTTPS eller TCP), porten och intervallet konfigureras. För HTTP/HTTPS-kontroller skickar lastbalanseraren en GET-begäran till en angiven URL-sökväg – instansen anses vara frisk om den returnerar HTTP 200. För TCP-kontroller innebär en lyckad TCP-anslutning att instansen är frisk. Om en backend misslyckas med ett konfigurerbart antal kontroller i rad slutar lastbalanseraren att skicka nya anslutningar till den tills den åter klarar kontrollerna. Detta ger automatisk feltålighet utan manuella åtgärder.

Azure Load Balancer finns i två SKU:er: Basic – kostnadsfri, stöder upp till 300 backend-instanser, inget SLA, inget stöd för tillgänglighetszoner och inget krav på NSG enligt principen säker som standard. Standard – avgiftsbelagd (cirka 20 USD/månad i grundavgift), stöder upp till 1 000 backend-instanser, 99,99-procentigt SLA, zonredundant frontend, säker som standard (explicit konfigurerade NSG-regler krävs för att tillåta trafik) och stöd för flera frontend-IP-adresser. För produktionsarbetsbelastningar rekommenderas Standard SKU starkt. Microsoft avvecklar Basic SKU – nya distributioner bör alltid använda Standard.

Azure Load Balancer kan distribueras i två konfigurationer: Public (External) Load Balancer – har en offentlig IP-adress på frontend och distribuerar internettrafik mellan backend-virtuella datorer. Den används för internetanslutna program som webbservrar och API-gateways. Internal (Private) Load Balancer – har en privat IP-adress på frontend inom ett VNet och distribuerar trafik inom VNet-nätverket. Den används för flerskiktsprogram där lastbalanseraren för programskiktet inte ska vara åtkomlig från internet – endast från webbskiktet i samma VNet. Båda kan distribueras samtidigt: en offentlig LB för webbskiktet och en intern LB för programskiktet.

Azure erbjuder två primära lastbalanseringstjänster för olika scenarier: Azure Load Balancer — lager 4, TCP/UDP, extremt låg latens och hanterar miljontals anslutningar per sekund. Bäst för arbetsbelastningar som inte använder HTTP eller när maximal genomströmning och minimal latens är prioriterade. Azure Application Gateway — lager 7, HTTP/HTTPS, förstår URL-sökvägar och huvuden och inkluderar Web Application Firewall (WAF), SSL-terminering, cookiebaserad sessionsaffinitet och URL-baserad routning. Bäst för webbapplikationer som behöver innehållsmedveten lastbalansering, TLS-avlastning och WAF-skydd. För enkel TCP-lastbalansering använder ni Load Balancer. För webbapplikationer tillför Application Gateway betydande mervärde.

DNS och Load Balancer samarbetar för att skapa motståndskraftiga och användarvänliga slutpunkter. Ett vanligt mönster är: 1) Skapa en Azure Load Balancer med en offentlig Standard-IP-adress och en backend-pool med virtuella webbserverdatorer. 2) Skapa en DNS CNAME-post i Azure DNS som pekar www.mycompany.com mot Load Balancers offentliga IP-adress (eller DNS-namn). 3) När användare besöker www.mycompany.com slår DNS upp Load Balancers IP-adress, och Load Balancer distribuerar förfrågningarna över felfria VM-instanser. Detta ger både en användarvänlig URL och automatisk trafikfördelning med feltolerans.

I den här lektionen har ni lärt er att: Azure DNS hanterar offentliga och privata DNS-zoner med nästan 100 % tillgänglighet, vilket möjliggör läsbara namn för Azure-resurser, privata DNS-zoner med automatisk registrering håller VNet:s DNS-poster aktuella utan manuell hantering och Azure Load Balancer distribuerar TCP/UDP-trafik på lager 4 över felfria backend-VM-instanser med hjälp av hälsoavläsningar för att automatiskt upptäcka och kringgå instanser som har slutat fungera. Härnäst går vi vidare till kursen om Azure-databaser, med start i Azure SQL Database.