Bewerken

Delen via

Webtoepassing met meerdere lagen, ontworpen voor HA/DR

Azure
Azure Arc
SQL Server
Windows

Dit voorbeeldscenario is van toepassing op elke branche die flexibele toepassingen met meerdere lagen moet implementeren die zijn gebouwd voor hoge beschikbaarheid en herstel na noodgevallen. In dit scenario bestaat de toepassing uit drie lagen.

  • Weblaag: de bovenste laag, inclusief de gebruikersinterface. Deze laag parseert gebruikersinteracties en geeft de acties door aan de volgende laag voor verwerking.
  • Bedrijfslaag: verwerkt de interacties van de gebruiker en neemt logische beslissingen over de volgende stappen. Deze laag verbindt de weblaag en de gegevenslaag.
  • Gegevenslaag: slaat de toepassingsgegevens op. Een database, objectopslag of bestandsopslag wordt doorgaans gebruikt.

Veelvoorkomende toepassingsscenario's zijn bedrijfskritieke toepassingen die worden uitgevoerd in Windows of Linux. Dit kan een off-the-shelf-toepassing zijn, zoals SAP en SharePoint of een aangepaste Line-Of-Business-toepassing.

Potentiële gebruikscases

Andere relevante use cases zijn:

  • Zeer tolerante toepassingen implementeren, zoals SAP en SharePoint
  • Een plan voor bedrijfscontinuïteit en herstel na noodgevallen ontwerpen voor Line-Of-Business-toepassingen
  • Herstel na noodgevallen configureren en gerelateerde drills uitvoeren voor nalevingsdoeleinden

Architectuur

Diagram showing the architecture overview of a highly resilient multitier web application.

Een Visio-bestand van deze architectuur downloaden.

Werkstroom

  • Distribueer de VM's in elke laag over twee beschikbaarheidszones in regio's die zones ondersteunen. In andere regio's implementeert u de VM's in elke laag binnen één beschikbaarheidsset.
  • De databaselaag kan worden geconfigureerd voor het gebruik van AlwaysOn-beschikbaarheidsgroepen. Met deze SQL Server-configuratie wordt één primaire lees-/schrijfreplica binnen een beschikbaarheidsgroep geconfigureerd met maximaal acht secundaire alleen-lezen replica's. Als er een probleem optreedt met de primaire replica, voert de beschikbaarheidsgroep een failover uit van de primaire lees-/schrijfactiviteit naar een van de secundaire replica's, zodat de toepassing beschikbaar blijft. Zie Overzicht van AlwaysOn-beschikbaarheidsgroepen voor SQL Server voor meer informatie.
  • Voor scenario's voor herstel na noodgevallen kunt u asynchrone systeemeigen SQL AlwaysOn-replicatie configureren naar de doelregio die wordt gebruikt voor herstel na noodgevallen. U kunt ook Azure Site Recovery-replicatie naar de doelregio configureren als de snelheid van gegevenswijziging binnen de ondersteunde limieten van Azure Site Recovery valt.
  • Gebruikers hebben toegang tot de front-end-ASP.NET-weblaag via het Traffic Manager-eindpunt.
  • Traffic Manager leidt verkeer om naar het primaire openbare IP-eindpunt in de primaire bronregio.
  • Met het openbare IP-adres wordt de aanroep omgeleid naar een van de VM-exemplaren van de weblaag via een openbare load balancer. Alle VM-exemplaren van de weblaag bevinden zich in één subnet.
  • Vanaf de weblaag-VM wordt elke aanroep gerouteerd naar een van de VM-exemplaren in de bedrijfslaag via een interne load balancer voor verwerking. Alle VM's in de bedrijfslaag bevinden zich in een afzonderlijk subnet.
  • De bewerking wordt verwerkt in de bedrijfslaag en de ASP.NET toepassing maakt verbinding met het Microsoft SQL Server-cluster in een back-endlaag via een interne Load Balancer van Azure. Deze back-end SQL Server-exemplaren bevinden zich in een afzonderlijk subnet.
  • Het secundaire eindpunt van Traffic Manager is geconfigureerd als het openbare IP-adres in de doelregio die wordt gebruikt voor herstel na noodgevallen.
  • In het geval van een onderbreking van de primaire regio roept u Azure Site Recovery-failover aan en wordt de toepassing actief in de doelregio.
  • Het Traffic Manager-eindpunt leidt het clientverkeer automatisch om naar het openbare IP-adres in de doelregio.

Onderdelen

  • Beschikbaarheidssets zorgen ervoor dat de VM's die u in Azure implementeert over meerdere geïsoleerde hardwareknooppunten in een cluster worden verdeeld. Als er een hardware- of softwarefout optreedt in Azure, wordt alleen een subset van uw VM's beïnvloed en blijft uw hele oplossing beschikbaar en operationeel.
  • Beschikbaarheidszones beschermen uw toepassingen en gegevens tegen datacenterfouten. Beschikbaarheidszones zijn afzonderlijke fysieke locaties binnen een Azure-regio. Elke zone bestaat uit een of meer datacenters die zijn uitgerust met onafhankelijke voeding, koeling en netwerken.
  • Met Azure Site Recovery kunt u VM's repliceren naar een andere Azure-regio voor bedrijfscontinuïteit en noodherstel. U kunt periodieke noodherstelanalyses uitvoeren om ervoor te zorgen dat u voldoet aan de nalevingsbehoeften. De VM wordt met de opgegeven instellingen gerepliceerd in de geselecteerde regio, zodat u uw toepassingen kunt herstellen in het geval van uitval in de bronregio.
  • Azure Traffic Manager is een load balancer op basis van DNS die verkeer optimaal distribueert naar services in wereldwijde Azure-regio's en tegelijkertijd hoge beschikbaarheid en reactiesnelheid biedt.
  • Azure Load Balancer distribueert inkomend verkeer volgens gedefinieerde regels en statustests. Een load balancer biedt lage latentie en hoge doorvoer, omhoog schalen naar miljoenen stromen voor alle TCP- en UDP-toepassingen. In dit scenario wordt een openbare load balancer gebruikt om binnenkomend clientverkeer naar de weblaag te distribueren. In dit scenario wordt een interne load balancer gebruikt om verkeer van de bedrijfslaag naar het back-end-SQL Server-cluster te distribueren.

Alternatieven

  • Windows kan worden vervangen door andere besturingssystemen omdat niets in de infrastructuur afhankelijk is van het besturingssysteem.
  • SQL Server voor Linux kan het back-endgegevensarchief vervangen.
  • De database kan worden vervangen door elke standaarddatabasetoepassing die beschikbaar is.

Scenariodetails

In dit scenario ziet u een toepassing met meerdere lagen die gebruikmaakt van ASP.NET en Microsoft SQL Server. In Azure-regio's die beschikbaarheidszones ondersteunen, kunt u uw virtuele machines (VM's) implementeren in een bronregio in verschillende beschikbaarheidszones en de VM's repliceren naar de doelregio die wordt gebruikt voor herstel na noodgevallen. In Azure-regio's die geen ondersteuning bieden voor beschikbaarheidszones, kunt u uw VM's implementeren binnen een beschikbaarheidsset en de VM's repliceren naar de doelregio.

Als u verkeer tussen regio's wilt routeren, hebt u een globale load balancer nodig. Er zijn twee belangrijke Azure-aanbiedingen:

  • Azure Front Door
  • Azure Traffic Manager

Houd bij het kiezen van een load balancer rekening met uw vereisten en de functieset van de twee aanbiedingen. Hoe snel wilt u een failover uitvoeren? Kunt u de overhead van TLS-beheer overnemen? Zijn er beperkingen voor de kosten van de organisatie?

Front Door heeft laag 7-mogelijkheden: SSL-offload, padgebaseerde routering, snelle failover, caching en andere om de prestaties en hoge beschikbaarheid van uw toepassingen te verbeteren. U kunt sneller pakketreistijden ervaren omdat de infrastructuur eerder in het Azure-netwerk wordt uitgevoerd.

Omdat Front Door een nieuwe hop toevoegt, zijn er beveiligingsbewerkingen toegevoegd. Als de architectuur voldoet aan wettelijke vereisten, zijn er mogelijk beperkingen voor het aanvullende TLS-beëindigingspunt voor verkeer. De TLS-coderingssuites die door Front Door zijn geselecteerd, moeten voldoen aan de beveiligingsbalk van uw organisatie. Front Door verwacht ook dat de back-endservices gebruikmaken van certificaten die door Microsoft worden gebruikt.

Een andere overweging is kosten. De architectuur moet profiteren van de uitgebreide functieset (niet alleen failover) om de extra kosten te rechtvaardigen.

Traffic Manager is een op DNS gebaseerde taakverdelingsservice. Het balancer en voert alleen een failover uit op DNS-niveau. Daarom kan er geen failover worden uitgevoerd zo snel als Front Door, vanwege veelvoorkomende problemen met DNS-caching en systemen die DNS-TTLs niet respecteren.

U kunt beide load balancers combineren, indien nodig. U wilt bijvoorbeeld de failover op basis van DNS, maar u wilt een POP-ervaring toevoegen vóór die door verkeer beheerde infrastructuur.

Deze architectuur maakt gebruik van Traffic Manager omdat deze lichtgewicht is. De timing van de failover is voldoende voor illustratieve doeleinden.

Overwegingen

Schaalbaarheid

U kunt VM's in elke laag toevoegen of verwijderen op basis van uw schaalvereisten. Omdat in dit scenario load balancers worden gebruikt, kunt u meer VM's toevoegen aan een laag zonder dat dit van invloed is op de uptime van toepassingen.

Zie de controlelijst voor prestatie-efficiëntie in het Azure Architecture Center voor andere onderwerpen over schaalbaarheid.

Beveiliging

Al het verkeer van het virtuele netwerk naar de front-endtoepassingslaag wordt beveiligd door netwerkbeveiligingsgroepen. Regels beperken de verkeersstroom, zodat alleen de VM-exemplaren van de front-endtoepassingslaag toegang hebben tot de back-enddatabaselaag. Uitgaand internetverkeer is niet toegestaan vanuit de bedrijfslaag of databaselaag. Om de footprint van aanvallen te verminderen, zijn er geen directe poorten voor extern beheer geopend. Zie Azure-netwerkbeveiligingsgroepen voor meer informatie.

Zie de Documentatie voor Azure-beveiliging voor algemene richtlijnen voor het ontwerpen van veilige scenario's.

Prijzen

Voor het configureren van herstel na noodgevallen voor Azure-VM's met behulp van Azure Site Recovery worden doorlopend de volgende kosten in rekening gebracht.

  • Azure Site Recovery-licentiekosten per VM.
  • Kosten voor uitgaand netwerk voor het repliceren van gegevenswijzigingen van de bron-VM-schijven naar een andere Azure-regio. Azure Site Recovery maakt gebruik van ingebouwde compressie om de vereisten voor gegevensoverdracht met ongeveer 50% te verminderen.
  • Opslagkosten op de herstelsite. Dit is doorgaans hetzelfde als de bronregioopslag plus eventuele extra opslagruimte die nodig is om de herstelpunten te onderhouden als momentopnamen voor herstel.

We hebben een voorbeeldkostencalculator geleverd voor het configureren van herstel na noodgevallen voor een toepassing met drie lagen met behulp van zes virtuele machines. Alle services zijn vooraf geconfigureerd in de kostencalculator. Als u wilt zien hoe de prijzen voor uw specifieke use case veranderen, wijzigt u de juiste variabelen om de kosten te schatten.

Bijdragers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

Volgende stappen

Zie voor aanvullende referentiearchitecturen voor hoge beschikbaarheid en herstel na noodgevallen: