Basisprincipes van Azure DNS en Load Balancer

DNS (Domain Name System) vertaalt voor mensen leesbare domeinnamen (zoals api.mycompany.com) naar IP-adressen die computers gebruiken om te communiceren. Azure biedt twee DNS-services: Azure DNS voor het hosten van openbare DNS-zones (domeinen die via internet toegankelijk zijn) en Azure Private DNS voor interne naamomzetting binnen VNets. Zonder de juiste DNS-configuratie moeten naar Azure-resources worden verwezen met hun IP-adressen, waardoor architecturen kwetsbaar worden — elke IP-wijziging verbreekt alle afhankelijke configuraties. Azure DNS is een zeer beschikbare, wereldwijd gedistribueerde service die wordt ondersteund door het anycast-netwerk van Microsoft.

Openbare zones in Azure DNS hosten DNS-records voor domeinen die via internet toegankelijk zijn. Je delegeert je domein (geregistreerd bij een registrar zoals GoDaddy) aan Azure DNS door de NS-records van het domein bij te werken zodat ze naar de naamservers van Azure verwijzen. Na de delegatie beheer je alle DNS-records (A, CNAME, MX, TXT enzovoort) vanuit de Azure-portal of CLI in plaats van via een afzonderlijke DNS-provider. Openbare zones in Azure DNS bieden een SLA-beschikbaarheid van 100%, wereldwijde propagatie binnen minder dan een seconde en via RBAC beheerde toegang, zodat alleen geautoriseerde teamleden DNS-records kunnen wijzigen.

Privézones in Azure DNS bieden naamomzetting voor resources binnen VNets zonder DNS-records openbaar te maken. Je kunt bijvoorbeeld de privézone myapp.internal maken en je VM's registreren, zodat ze op naam (db.myapp.internal) in plaats van op IP-adres worden gevonden. Privézones in Azure DNS zijn gekoppeld aan VNets — alleen resources in gekoppelde VNets kunnen de privérecords omzetten. Je kunt ook automatische registratie inschakelen. Hierdoor worden automatisch DNS-records voor VM's gemaakt wanneer ze deelnemen aan het VNet, zodat DNS zonder handmatig beheer gesynchroniseerd blijft.

Private eindpunten (voor services zoals Azure SQL, Blob Storage en Key Vault) vereisen DNS om de openbare hostnaam van de service naar het privé-IP-adres in plaats van naar het openbare IP-adres om te zetten. Azure biedt privé-DNS-zones voor elke service (bijvoorbeeld privatelink.blob.core.windows.net voor Blob Storage). Wanneer je een privé-eindpunt maakt, maakt Azure in deze privézone een DNS A-record dat naar het privé-IP-adres verwijst. Koppel deze zone aan je VNet, waarna alle DNS-lookups voor de URL van het opslagaccount automatisch naar het privé-IP-adres worden omgezet — het verkeer wordt via de privébackbone gerouteerd zonder wijzigingen in de toepassingscode.

Azure Load Balancer verdeelt inkomend netwerkverkeer over meerdere back-endresources (VM's of instanties in een schaalset), zodat geen enkele resource wordt overbelast. De service werkt op laag 4 (transportlaag) van het OSI-model — TCP- en UDP-pakketten worden gerouteerd op basis van bron- en doel-IP-adres en poort, zonder de HTTP-inhoud te inspecteren. Azure Load Balancer is een zeer beschikbare, zoneredundante service met een SLA van 99,99% (Standard-SKU) en ondersteunt zowel inkomende taakverdeling (vanaf internet of een VNet) als uitgaande SNAT voor internetverkeer van VM's.

Azure Load Balancer heeft vier hoofdonderdelen: Frontend-IP-configuratie — het openbare of privé-IP-adres waarmee clients verbinding maken. Back-endpool — de verzameling VM's of instanties van een schaalset die verkeer ontvangen. Regels voor taakverdeling — koppelen een frontend-IP-adres en -poort aan een back-endpoort en geven het algoritme voor de verkeersverdeling op (standaard een hash op basis van een 5-tuple). Gezondheidscontroles — testen elke back-endinstantie periodiek; instanties die de gezondheidscontroles niet doorstaan, ontvangen geen nieuwe verbindingen totdat ze zijn hersteld. Samen bepalen deze onderdelen hoe verkeer wordt ontvangen, gecontroleerd en verdeeld.

Gezondheidscontroles zijn periodieke controles die de taakverdeler naar elke back-endinstantie stuurt om te bepalen of deze gezond is en verkeer moet ontvangen. Je configureert het protocol van de controle (HTTP, HTTPS of TCP), de poort en het interval. Voor HTTP-/HTTPS-controles stuurt de taakverdeler een GET-aanvraag naar een opgegeven URL-pad — de instantie is gezond als deze HTTP 200 retourneert. Voor TCP-controles betekent een geslaagde TCP-verbinding dat de instantie gezond is. Als een back-end een configureerbaar aantal opeenvolgende controles niet doorstaat, stopt de taakverdeler met het sturen van nieuwe verbindingen totdat de instantie de controles weer doorstaat. Dit biedt automatische fouttolerantie zonder handmatige tussenkomst.

Azure Load Balancer is beschikbaar in twee SKU's: Basic — gratis, ondersteunt maximaal 300 back-endinstanties, geen SLA, geen ondersteuning voor beschikbaarheidszones en geen verplichte NSG-configuratie volgens het principe secure-by-default. Standard — betaald (ongeveer $20 per maand als basistarief), ondersteunt maximaal 1.000 back-endinstanties, een SLA van 99,99%, een zoneredundante frontend, standaard beveiligd (expliciete NSG-regels zijn vereist om verkeer toe te staan) en meerdere frontend-IP-adressen. Voor elke productiewerklast wordt de Standard-SKU sterk aanbevolen. Microsoft trekt de Basic-SKU buiten gebruik — nieuwe implementaties moeten altijd Standard gebruiken.

Azure Load Balancer kan in twee configuraties worden geïmplementeerd: openbare (externe) Load Balancer — heeft een openbaar IP-adres op de frontend en verdeelt internetverkeer over back-end-VM's. Deze wordt gebruikt voor toepassingen die via internet toegankelijk zijn, zoals webservers en API-gateways. interne (privé) Load Balancer — heeft een privé-IP-adres op de frontend binnen een VNet en verdeelt verkeer binnen het VNet. Deze wordt gebruikt voor toepassingen met meerdere lagen waarbij de taakverdeler van de toepassingslaag niet vanaf internet toegankelijk mag zijn — alleen vanuit de weblaag in hetzelfde VNet. Je kunt beide tegelijk implementeren: een openbare LB voor de weblaag en een interne LB voor de toepassingslaag.

Azure biedt twee primaire services voor taakverdeling voor verschillende scenario's: Azure Load Balancer — laag 4, TCP/UDP, extreem lage latentie en geschikt voor miljoenen verbindingen per seconde. Dit is het meest geschikt voor niet-HTTP-workloads of wanneer maximale doorvoer en minimale latentie prioriteit hebben. Azure Application Gateway — laag 7, HTTP/HTTPS, begrijpt URL-paden en headers en bevat een Web Application Firewall (WAF), SSL-beëindiging, sessie-affiniteit op basis van cookies en routering op basis van URL's. Dit is het meest geschikt voor webapplicaties die taakverdeling nodig hebben die rekening houdt met de inhoud, TLS-offloading en WAF-bescherming. Gebruik Load Balancer voor eenvoudige TCP-taakverdeling. Voor webapplicaties biedt Application Gateway aanzienlijke extra waarde.

DNS en Load Balancer werken samen om veerkrachtige, gebruiksvriendelijke eindpunten te creëren. Een veelgebruikt patroon: 1) Maak een Azure Load Balancer met een openbaar IP-adres van de Standard-laag en een backendpool met VM's van webservers. 2) Maak in Azure DNS een DNS CNAME-record dat www.mycompany.com laat verwijzen naar het openbare IP-adres (of de DNS-naam) van de Load Balancer. 3) Wanneer gebruikers www.mycompany.com bezoeken, verwijst DNS naar het IP-adres van de Load Balancer en verdeelt de Load Balancer de aanvragen over gezonde VM-instanties. Dit biedt zowel een gebruiksvriendelijke URL als automatische verkeersverdeling met fouttolerantie.

In deze les heb je geleerd dat Azure DNS openbare en privé-DNS-zones host met bijna 100% beschikbaarheid, zodat Azure-resources namen krijgen die voor mensen leesbaar zijn, dat privé-DNS-zones met automatische registratie de DNS-records van een VNet actueel houden zonder handmatig beheer, en dat Azure Load Balancer TCP/UDP-verkeer van laag 4 verdeelt over gezonde backend-VM-instanties en daarbij statuscontroles gebruikt om defecte instanties automatisch te detecteren en over te slaan. Hierna gaan we verder met de cursus Azure-databases, te beginnen met Azure SQL Database.