Microsoft Azure Beschikbaarheidszones zijn afzonderlijke fysieke locaties binnen een Azure-regio, elk met een of meer datacenters met onafhankelijke voeding, koeling en netwerken. De fysieke scheiding van beschikbaarheidszones binnen een regio beperkt het effect van zonefouten op toepassingen en gegevens. De referentiearchitectuur die in dit artikel wordt gepresenteerd, toont best practices voor een zonale implementatie: een implementatie die gebruikmaakt van Beschikbaarheidszones beschikbaarheid van toepassingen te vergroten. Een zonale implementatie is geschikt voor veel soorten toepassingen. Het specifieke voorbeeld dat hier wordt weergegeven, is denale implementatie van een webtoepassing die wordt uitgevoerd op virtuele machines (VM's) en die gebruikmaakt van Microsoft SQL Server database.
Deze aanpak wordt gebruikt in scenario's met hoge beschikbaarheid waarbij tolerantie erg belangrijk is. Met ha-architectuur is er een balans tussen hoge tolerantie, lage latentie en kosten. Deze architectuur maakt gebruik van redundante resources verspreid over zones om een hoge tolerantie te bieden. Verkeer kan worden gerouteerd tussen zones om de impact van een zonefout te minimaliseren. Als een zone mislukt, nemen resources in andere zones het verkeer over totdat de mislukte zone wordt hersteld. Dit biedt een hoog tolerantieniveau.
Deze architectuur biedt een efficiënt gebruik van resources, omdat de meeste resources actief worden gebruikt. Alle resources, met andere dan de passieve SQL Server, worden gebruikt bij het verwerken van aanvragen. De passieve SQL Server alleen actief als de actieve SQL Server mislukt.
De zone-redundante Azure Application Gateway zone-redundante load balancer het verkeer naar de beschikbare resources te distribueren.
Een Visio-bestand van deze architectuur downloaden.
Architectuur
De architectuur maakt gebruik van resources die zijn verdeeld over meerdere zones om een IaaS-webtoepassing (Infrastructure as a Service) hoge beschikbaarheid te bieden die gebruikmaakt van SQL Server database. Een zone-redundante Application Gateway verkeer naar VM's binnen de weblaag. Een zone-redundante load balancer routeert verkeer van de VM's in de weblaag naar de actieve SQL Server. In het geval van een zonefout routet Application Gateway naar VM's in andere beschikbare zones. Routering tussen zones heeft een hogere latentie dan routering binnen de zone.
Als de actieve SQL Server niet beschikbaar is vanwege een zonefout of lokale fout, wordt een passieve SQL Server de actieve SQL Server. De zone-redundante load balancer de failover naar de nieuw actieve SQL Server en routeer verkeer naar de failover.
Hieronder ziet u een fout in Zone 1.
Een Visio-bestand van deze architectuur downloaden.
De Application Gateway is zone-redundant. Dit wordt niet beïnvloed door het mislukken van Zone 1 en maakt gebruik van statustests om de beschikbare VM's te bepalen. Als Zone 1 niet beschikbaar is, wordt verkeer alleen naar de resterende twee zones gerouted. De zone-redundante load balancer wordt ook niet beïnvloed door het mislukken van Zone 1 en maakt gebruik van statustests om de locatie van de actieve SQL Server. In dit voorbeeld detecteert load balancer dat de actieve SQL Server zich in de Zone 3 verkeer naar de Zone 3 routeert.
Het spreiden van resources Beschikbaarheidszones beschermt een toepassing ook tegen gepland onderhoud. Wanneer VM's worden gedistribueerd over Beschikbaarheidszones zijn ze in feite verdeeld over drie updatedomeinen. Het Azure-platform herkent deze distributie over updatedomeinen om ervoor te zorgen dat VM's in verschillende zones niet tegelijkertijd worden bijgewerkt.
Door VM's te repliceren Beschikbaarheidszones, kunt u uw toepassingen en gegevens beschermen tegen zonestoringen. Dit is hoe Azure voldoet aan de beste service level agreement (SLA) voor VM's met een uptime van 99,99%. Zie Oplossingen bouwen voor hoge beschikbaarheid met behulp van Beschikbaarheidszones.
De architectuur heeft de volgende onderdelen:
Algemeen
Resourcegroepen. Resourcegroepen worden gebruikt om Azure-resources te groepen, zodat ze kunnen worden beheerd op basis van levensduur, eigenaar of andere criteria.
Azure-beschikbaarheidszones. Beschikbaarheidszones zijn afzonderlijke fysieke locaties binnen een Azure-regio, elk met een of meer datacenters met onafhankelijke voeding, koeling en netwerken. Door VM's in meerdere zones te plaatsen, wordt de toepassing bestand tegen fouten binnen een zone.
Netwerken en taakverdeling
- Virtueel netwerk en subnetten. Elke azure-VM wordt geïmplementeerd in een virtueel netwerk dat kan worden gesegmenteerd in subnetten, één subnet voor elke laag.
- Application Gateway. Azure Application Gateway is een laag 7 load balancer. In deze architectuur routeert een zone-redundante Application Gateway HTTP-aanvragen naar de webfront-end. Application Gateway biedt ook een Web Application Firewall (WAF) die de toepassing beschermt tegen veelvoorkomende aanvallen en beveiligingsproblemen. De v2-SKU van Application Gateway ondersteuning voor zone-overschrijdende redundantie. Met één Application Gateway kunnen meerdere gateway-exemplaren worden uitgevoerd. Voor productieworkloads moet u ten minste twee workloads uitvoeren. Zie Autoscaling and Zone-redundant Application Gateway v2 (Automatisch schalen en zone-redundante Application Gateway v2) en How does Application Gateway support high availability and scalability? (Hoe Application Gateway hoge beschikbaarheid en schaalbaarheid ondersteunen? voor meer informatie.
- Azure Load Balancer. Azure Load Balancer is een load balancer voor laag 4. In deze architectuur stuurt een zone-redundante Azure-Standard Load Balancer netwerkverkeer van de weblaag naar SQL Server. Omdat een zone-redundante load balancer niet is vastgemaakt aan een specifieke zone, blijft de toepassing het netwerkverkeer distribueren in het geval van een zonefout. Een zone-redundante load balancer wordt gebruikt om beschikbaarheid te bieden in het geval de actieve SQL Server niet beschikbaar is. De Standard-SKU van Azure Load Balancer ondersteuning voor zone-overschrijdende redundantie. Zie voor meer informatie Standard Load Balancer en Beschikbaarheidszones.
- Netwerkbeveiligingsgroepen (NSG's). Een netwerkbeveiligingsgroep wordt gebruikt om netwerkverkeer binnen het virtuele netwerk te beperken. In deze architectuur accepteert de weblaag alleen verkeer van het openbare IP-eindpunt. Bovendien accepteert de databaselaag geen verkeer van een ander subnet dan het subnet van de weblaag.
- DDoS-beveiliging. Het Azure-platform biedt bescherming tegen DDoS-aanvallen (Distributed Denial of Service). Voor extra beveiliging raden we u aan om Azure DDoS Protection Standardte gebruiken, die verbeterde DDoS-beperkingsfuncties heeft. Zie Beveiligingsoverwegingen.
- Azure Bastion. Azure Bastion biedt veilige en naadloze Remote Desktop Protocol (RDP) en SSH-toegang (Secure Shell) tot de virtuele machines in het virtuele netwerk. Dit biedt toegang terwijl de openbare IP-adressen van de virtuele machines in het virtuele netwerk worden beperkt. Azure Bastion biedt een rendabel alternatief voor een inrichtende VM om toegang te bieden tot alle VM's binnen hetzelfde virtuele netwerk.
Microsoft SQL Server
SQL Server Always On-beschikbaarheidsgroepen. Een SQL Server Always On-beschikbaarheidsgroep biedt hoge beschikbaarheid in de gegevenslaag door replicatie en failover in te stellen. Er wordt Windows WSFC-technologie (Server Failover Cluster) gebruikt voor failover.
Cloud witness. Voor een failovercluster moet meer dan de helft van de knooppunten worden uitgevoerd, een voorwaarde die quorum heeft. Als het cluster slechts twee knooppunten heeft, kan een netwerkpartitie ertoe leiden dat elk knooppunt denkt dat het het primaire knooppunt is. In dat geval hebt u een witness nodig om de bindingen te verbreken en quorum tot stand te laten komen. Een witness is een resource zoals een gedeelde schijf die kan fungeren als een tie-breaker om een quorum tot stand te laten komen. Cloud witness is een type witness dat gebruikmaakt van Azure Blob Storage. De Azure Blob Storage moet zone-redundante Storage (ZRS) gebruiken om niet te worden beïnvloed door een zonefout.
Zie Understanding cluster and pool quorum (Cluster- en poolquorum begrijpen) voor meer informatie over het concept quorum. Zie Deploy a Cloud Witness for a Failover Cluster (Een cloud-witness implementeren voor een failovercluster) voor meer informatie over Cloud Witness.
Aanbevelingen
Uw vereisten kunnen afwijken van de architectuur die hier wordt beschreven. Gebruik deze aanbevelingen als uitgangspunt.
Zie Run a Windows VM on Azure (Een virtuele Windows uitvoeren in Azure) voor aanbevelingen voor het configureren van de VM's.
Zie Azure Virtual Networks plannen en ontwerpen voor meer informatie over het ontwerpen van virtuele netwerken en subnetten.
Netwerkbeveiligingsgroepen
Gebruik NSG-regels om het verkeer tussen lagen te beperken. In deze architectuur kan alleen de weblaag rechtstreeks communiceren met de databaselaag. Als u deze regel wilt afdwingen, moet de databaselaag al het binnenkomende verkeer blokkeren, met uitzondering van het subnet van de weblaag.
- Al het inkomende verkeer van het virtuele netwerk weigeren. (Gebruik de VIRTUELE _ Network-tag in de regel.)
- Sta het inkomende verkeer van het subnet van de weblaag toe.
- Sta het inkomende verkeer van het subnet van de databaselaag zelf toe. Deze regel staat communicatie toe tussen de database-VM's, die nodig zijn voor databasereplicatie en failover.
Maak regels 2 – 3 met een hogere prioriteit dan de eerste regel, zodat ze deze overschrijven.
SQL Server AlwaysOn-beschikbaarheidsgroepen
We raden Always On-beschikbaarheidsgroepen aan voor Microsoft SQL Server hoge beschikbaarheid. Andere lagen maken verbinding met de database via een listener voor de beschikbaarheidsgroep. De listener maakt het mogelijk dat een SQL-client verbinding maakt zonder de naam van het fysieke exemplaar van SQL Server te kennen. Virtuele machines die toegang hebben tot de database, moeten worden toegevoegd aan het domein. De client (in dit geval een andere laag) gebruikt DNS om de naam van het virtuele netwerk van de listener om te zetten in IP-adressen.
Configureer SQL Server Always On-beschikbaarheidsgroep als volgt:
- Maak een Windows WSFC-cluster (Server Failover Clustering), een SQL Server Always On-beschikbaarheidsgroep en een primaire replica. Zie Voor meer informatie Aan de slag met Always On-beschikbaarheidsgroepen.
- Maak een interne load balancer met een statisch privé-IP-adres.
- Maak een beschikbaarheidsgroeplistener en wijs de DNS-naam van de listener toe aan het IP-adres van een interne load balancer.
- Maak een load balancer-regel voor de SQL Server-controlepoort (standaard TCP-poort 1433). De load balancer-regel moet zwevende IP-adressen, ook wel Direct Server Return, inschakelen. Dit zorgt ervoor dat de VM rechtstreeks antwoordt naar de client, waardoor een directe verbinding met de primaire replica mogelijk is.
Notitie
Als zwevende IP-adressen zijn ingeschakeld, moet het front-end poortnummer hetzelfde zijn als het back-end poortnummer in de load balancer-regel.
Wanneer een SQL-client verbinding probeert te maken, stuurt de load balancer de verbindingsaanvraag door naar de primaire replica. Als er een failover naar een andere replica is, load balancer nieuwe aanvragen automatisch door naar een nieuwe primaire replica. Zie Configure a load balancer for an availability group on Azure SQL Server VMs (Een beschikbaarheidsgroep configureren op Azure SQL Server VM's) voor meer informatie.
Met een failover worden bestaande clientverbindingen gesloten. Nadat de failover is voltooid, worden nieuwe verbindingen gerouteerd naar de nieuwe primaire replica.
Als uw toepassing aanzienlijk meer leest dan schrijft, stuurt u enkele van de alleen-lezen query's om naar een secundaire replica. Zie Verbinding maken naar een alleen-lezen replica.
Test uw implementatie door een handmatige failover van de beschikbaarheidsgroep te forceren.
Beschikbaarheidsoverwegingen
Beschikbaarheidszones bieden een hoge tolerantie binnen één regio. Als u nog hogere beschikbaarheid nodig hebt, kunt u overwegen om de toepassing te repliceren tussen twee regio's, met behulp Azure Traffic Manager failover. Zie Een toepassing met meerdere lagen uitvoeren in meerdere Azure-regio'svoor hoge beschikbaarheid voor meer informatie.
Niet alle regio's ondersteunen Beschikbaarheidszones en niet alle VM-grootten worden ondersteund in alle zones. Voer de volgende Azure CLI-opdracht uit om de ondersteunde zones voor elke VM-grootte binnen een regio te vinden:
az vm list-skus --resource-type virtualMachines --zone false --location eastus -o table
Virtual Machine Scale Sets automatisch plaatsingsgroepen gebruiken, die fungeren als een impliciete beschikbaarheidsset. Zie voor meer informatie over de plaatsing van groepen Werken met grote schaalsets voor virtuele machines.
Statuscontroles
Application Gateway en Azure Load Balancer beide statustests gebruiken om de beschikbaarheid van VM-exemplaren te bewaken.
- Application Gateway maakt altijd gebruik van een HTTP-test.
- Load Balancer kunt een test maken met HTTP of TCP. Over het algemeen, als op een VM een HTTP-server wordt uitgevoerd, gebruikt u een HTTP-test. Gebruik anders TCP.
Als een test een exemplaar niet binnen een time-outperiode kan bereiken, stopt de gateway of load balancer het verzenden van verkeer naar die VM. De test blijft het controleren en retourneert de VM naar de back-endpool wanneer de VM weer beschikbaar is.
HTTP-tests verzenden een HTTP GET-aanvraag naar een opgegeven pad en luisteren naar een HTTP 200-antwoord. Dit pad kan het hoofdpad ('/') zijn, of een eindpunt voor statuscontrole dat aangepaste logica implementeert om de status van de toepassing te controleren. Voor het eindpunt moeten anonieme HTTP-aanvragen worden toegestaan.
Zie voor meer informatie over statustests:
Zie Health Endpoint Monitoring pattern (Patroon Status van eindpuntbewaking) voor overwegingen over het ontwerpen van een eindpunt voor een statustest.
Kostenoverwegingen
Gebruik de Azure-prijscalculator om de kosten te schatten. Hier zijn enkele andere overwegingen.
Virtuele-machineschaalsets
Virtual Machine Scale Sets zijn beschikbaar op alle Windows VM-grootten. Er worden alleen kosten in rekening gebracht voor de Azure-VM's die u implementeert en voor eventuele extra onderliggende infrastructuurbronnen die worden verbruikt, zoals opslag en netwerken. Er worden geen incrementele kosten voor de Virtual Machine Scale Sets service.
Zie Prijzen voor virtuele Windows voor prijzen voor enkele VM's.
SQL Server
Als u Azure SQL DBaaS kiest, kunt u de kosten verlagen omdat u geen Always On-beschikbaarheidsgroep en domeincontrollermachines hoeft te configureren. Er zijn verschillende implementatieopties, van individuele databases tot beheerde exemplaren of elastische pools. Zie Prijzen voor Azure SQL voor meer informatie.
Zie SQL prijzen voor VM's voor SQL server.
Azure Load Balancer
Er worden alleen kosten in rekening gebracht voor het aantal geconfigureerde taakverdelings- en uitgaande regels. Inkomende NAT-regels zijn gratis. Er worden geen kosten per uur in rekening Standard Load Balancer wanneer er geen regels zijn geconfigureerd.
Raadpleeg de kostensectie in Azure Architecture Framework voor meer informatie.
Application Gateway
De Application Gateway moet worden ingericht met de v2-SKU en kan meerdere Beschikbaarheidszones. Met de v2-SKU wordt het prijsmodel gebaseerd op het verbruik en bestaat het uit twee onderdelen: een vaste prijs per uur en kosten op basis van verbruik.
Zie de sectie met prijzen in Automatisch schalen en Zone-redundante Application Gateway v2 voor meer informatie.
Beveiligingsoverwegingen
Virtuele netwerken zijn een verkeersisolatiegrens in Azure. Standaard kunnen VM's in één virtueel netwerk niet rechtstreeks communiceren met VM's in een ander virtueel netwerk. U kunt virtuele netwerken echter expliciet verbinden met behulp van peering voor virtuele netwerken.
Verkeersbeperking
Gebruik netwerkbeveiligingsgroepen (NSG's) om verkeer van en naar internet te beperken. Zie voor meer informatie Microsoft-cloudservices en -netwerkbeveiliging.
DMZ
U kunt een virtueel netwerkapparaat (NVA) toevoegen om een DMZ te maken tussen internet en het virtuele Azure-netwerk. NVA is een algemene term voor een virtueel apparaat dat netwerkgerelateerde taken kan uitvoeren, zoals een firewall, pakketinspectie, controle en aangepaste routering. Zie Netwerk-DMZ tussen Azure en een on-premises datacenter voor meer informatie.
Versleuteling
Versleutel gevoelige data-at-rest en gebruik Azure Key Vault om de versleutelingssleutels voor de database te beheren. Key Vault kan versleutelingssleutels opslaan in hardwarebeveiligingsmodules (HSM's). Zie voor meer informatie Integratie van Azure Sleutelkluis configureren voor SQL Server op Azure-VM's. Het is ook raadzaam om toepassingsgeheimen, zoals databaseverbindingsreeksen, op te slaan in Key Vault.
DDoS-bescherming
Het Azure-platform biedt standaard DDoS-basisbeveiliging. Deze basisbeveiliging is gericht op het beveiligen van de Azure-infrastructuur. Hoewel DDoS-basisbeveiliging automatisch wordt ingeschakeld, raden we u aan om Azure DDoS Protection Standard. Standaardbeveiliging maakt gebruik van adaptieve afstemming, op basis van de netwerkverkeerspatronen van uw toepassing, om bedreigingen te detecteren. Hierdoor kunnen oplossingen worden toegepast tegen DDoS-aanvallen die mogelijk niet worden opgemerkt door het DDoS-beleid voor de hele infrastructuur. Standaardbeveiliging biedt ook waarschuwingen, telemetrie en analyses via Azure Monitor. Zie voor meer informatie Azure DDoS Protection: Best practices en referentiearchitecten.