Webtoepassing met meerdere lagen, ontworpen voor HA/DR

Azure
Arc
SQL Server
Windows

Dit voorbeeldscenario is van toepassing op elke branche die robuuste toepassingen met meerdere onderdelen moet implementeren die zijn gebouwd voor hoge beschikbaarheid en herstel na noodherstel. 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. Meestal wordt een database, objectopslag of bestandsopslag gebruikt.

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

Relevante gebruiksgevallen

Andere relevante gebruiksgevallen zijn:

  • Zeer robuuste toepassingen zoals SAP en SharePoint
  • Een plan voor bedrijfscontinuïteit en herstel na noodherstel ontwerpen voor Line-Of-Business-toepassingen
  • Herstel na noodherstel configureren en gerelateerde oefeningen uitvoeren voor nalevingsdoeleinden

Architectuur

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

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

  • Azure Front Door
  • Azure Traffic Manager

Houd bij het load balancer rekening met uw vereisten en de functieset van de twee aanbiedingen. Hoe snel wilt u een failover? Kunt u de overhead van TLS-beheer aan? Zijn er organisatiekostenbeperkingen?

Front Door biedt laag 7-mogelijkheden: SSL-offload, padgebaseerde routering, snelle failover, caching en andere om de prestaties en hoge beschikbaarheid van uw toepassingen te verbeteren. Mogelijk ervaart u snellere pakkettijden omdat de infrastructuur sneller wordt onboarding uitgevoerd in het Azure-netwerk.

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

Een andere overweging is de 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. Er wordt alleen op DNS-niveau een balans gevonden en er wordt een over-over-ing-over Daarom kan er niet zo snel een fail over worden overgenomen als Front Door, vanwege veelvoorkomende problemen met DNS-caching en systemen die geen DNS-TTL's respecteren.

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

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

Architectuuroverzicht van een zeer flexibele webtoepassing met meerderelaags

  • Distribueren van de VM's in elke laag over twee beschikbaarheidszones in regio's die zones ondersteunen. Implementeer in andere regio's de VM's in elke laag binnen één beschikbaarheidsset.
  • De databaselaag kan worden geconfigureerd voor het gebruik van Always On-beschikbaarheidsgroepen. Met deze SQL Server configuratie wordt één primaire database binnen een cluster geconfigureerd met maximaal acht secundaire databases. Als er een probleem optreedt met de primaire database, wordt er een overgeslagen naar een van de secundaire databases, zodat de toepassing beschikbaar blijft. Zie Overview of Always On availability groups for SQL Server (Overzicht van Always On-beschikbaarheidsgroepen voor SQL Server.
  • Voor noodherstelscenario's kunt u een SQL asynchrone systeemeigen replicatie van AlwaysOn configureren naar de doelregio die wordt gebruikt voor herstel na noodherstel. U kunt ook Azure Site Recovery replicatie naar de doelregio configureren als de snelheid voor gegevenswijziging binnen de ondersteunde limieten van Azure Site Recovery.
  • 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.
  • Het openbare IP-adres leidt de aanroep om naar een van de VM-exemplaren van de weblaag via een openbare load balancer. Alle VM-exemplaren van de weblaag staan in één subnet.
  • Vanaf de weblaag-VM wordt elke aanroep doorgeleid naar een van de VM-exemplaren in de bedrijfslaag via een interne load balancer voor verwerking. Alle zakelijke VM's staan in een afzonderlijk subnet.
  • De bewerking wordt verwerkt in de bedrijfslaag en de ASP.NET-toepassing maakt via een interne Azure-load balancer verbinding met het Microsoft SQL Server-cluster in een back-endlaag. Deze back-end SQL Server exemplaren zich in een afzonderlijk subnet.
  • Het secundaire eindpunt van Traffic Manager wordt geconfigureerd als het openbare IP-adres in de doelregio die wordt gebruikt voor herstel na noodherstel.
  • In het geval van een primaire regioonderbreking roept u een Azure Site Recovery 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 slechts een subset van uw VM's beïnvloed en blijft uw hele oplossing beschikbaar en operationeel.
  • Beschikbaarheidszones beschermen uw toepassingen en gegevens tegen storingen in datacenters. 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.
  • Azure Site Recovery kunt u VM's repliceren naar een andere Azure-regio voor bedrijfscontinuïteit en herstel na noodherstel. U kunt periodieke noodhersteloefeningen 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 op DNS gebaseerde verkeers-load balancer die verkeer optimaal distribueert naar services in wereldwijde Azure-regio's en tegelijkertijd een hoge beschikbaarheid en reactiesnelheid biedt.
  • Azure Load Balancer verdeelt het inkomende verkeer volgens gedefinieerde regels en statustests. Een load balancer biedt lage latentie en hoge doorvoer, omhoog schalen tot miljoenen stromen voor alle TCP- en UDP-toepassingen. Een openbare load balancer wordt in dit scenario gebruikt om binnenkomend clientverkeer naar de weblaag te distribueren. In dit load balancer wordt een interne SQL Server gebruikt om verkeer van de bedrijfslaag naar het back-endcluster SQL Server distribueren.

Alternatieven

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

Andere 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 de toepassing.

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

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. Er is geen uitgaand internetverkeer 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 Azure-beveiligingsdocumentatie voor algemene richtlijnen voor het ontwerpen van veilige scenario's.

Prijzen

Voor het configureren van herstel na noodherstel voor Virtuele Azure-Azure Site Recovery worden de volgende kosten doorlopend in rekening gebracht.

  • Azure Site Recovery licentiekosten per VM.
  • Netwerkkosten 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.
  • Storage op de herstelsite. Dit is doorgaans hetzelfde als de opslag in de bronregio plus eventuele extra opslag die nodig is om de herstelpunten te onderhouden als momentopnamen voor herstel.

We hebben een voorbeeld van een kostencalculator opgegeven voor het configureren van herstel na noodherstel 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.