Taakverdeling voor meerdere regio's met Traffic Manager en Application Gateway

Application Gateway
Bastion
Load Balancer
Traffic Manager

Deze referentiearchitectuur fungeert voor webworkloads met robuuste toepassingen met meerdere onderdelen en wordt geïmplementeerd in meerdere Azure-regio's voor hoge beschikbaarheid en robuust herstel na noodherstel.

Microsoft Azure Traffic Manager het verkeer tussen regio's en er is een regionale load balancer op basis van Azure Application Gateway. Deze combinatie biedt u de voordelen van Traffic Manager flexibele routering en Application Gateway mogelijkheden van de Application Gateway, waaronder:

  • Web Application Firewall (WAF).
  • Transport Layer Security (TLS) beëindigen.
  • Padgebaseerde routering.
  • Sessieaffiniteit op basis van cookies.

In dit scenario bestaat de toepassing uit drie lagen:

  • Weblaag: dit is de bovenste laag en heeft de gebruikersinterface. Het parseert gebruikersinteracties en geeft de acties door aan de bedrijfslaag voor verwerking.
  • Bedrijfslaag: verwerkt de interacties van de gebruiker en bepaalt de volgende stappen. Het verbindt de web- en gegevenslagen.
  • Gegevenslaag: slaat de toepassingsgegevens op, meestal in een database, objectopslag of bestanden.

Taakverdeling voor meerdere regio's met Application Gateway en Traffic Manager.

Notitie

Azure biedt een reeks volledig beheerde oplossingen voor taakverdeling. Als u op zoek bent naar beëindiging van het Transport Layer Security-protocol (TLS) ('SSL-offload') of per HTTP/HTTPS-aanvraag, verwerking op toepassingslaag, bekijkt u Wat is Azure Application Gateway?. Als u op zoek bent naar regionale taakverdeling, bekijkt u Azure Load Balancer. Uw end-to-end scenario 's kunnen eventueel profiteren van een combinatie van deze oplossingen.

Zie Overzicht van opties voor taakverdeling in Azure voor een vergelijking van azure-opties voor taakverdeling.

Architectuur

Traffic Manager werkt op de DNS-laag om toepassingsverkeer te sturen volgens de routeringsmethode van uw keuze. U kunt er bijvoorbeeld voor zorgen dat aanvragen worden verzonden naar de dichtstbijzijnde eindpunten om de reactiesnelheid te verbeteren. Application Gateway load balancer http(s) en WebSocket-aanvragen wanneer deze worden gerouteerd naar back-ende-poolservers. De back-end kan openbare of privé-eindpunten, virtuele machines, Azure Virtual Machine Scale Sets, app-services of AKS-clusters zijn. U kunt verkeer door sturen op basis van kenmerken van een HTTP-aanvraag, zoals hostnaam en URI-pad.

Onderdelen

  • Azure Virtual Machines VM's zijn schaalbare rekenresources op aanvraag die u de flexibiliteit van virtualisatie bieden, maar de onderhoudseisen van fysieke hardware elimineren. De besturingssysteemkeuzes zijn onder Windows en Linux. De VM's zijn een on-demand en schaalbare resource.
  • Azure Virtual Machine Scale Sets is geautomatiseerde VM-schaalbaarheid met load-balanced die het beheer van uw toepassingen vereenvoudigt en de beschikbaarheid verhoogt.
  • Traffic Manager is een verkeers-load balancer op basis van DNS die het verkeer optimaal distribueert naar services in wereldwijde Azure-regio's en tegelijkertijd een hoge beschikbaarheid en reactiesnelheid biedt. Zie de sectie Configuratie van Traffic Manager voor meer informatie.
  • 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 zoneoverschrijdende redundantie. Met één Application Gateway kunnen meerdere exemplaren van de gateway worden uitgevoerd.
  • Azure Load Balancer is een load balancer voor laag 4. Er zijn twee SKU's: Standard en Basic. In deze architectuur stuurt een zone-redundante Standard Load Balancer netwerkverkeer van de weblaag naar de bedrijfslaag. 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.
  • Azure DDoS Protection heeft verbeterde functies ter bescherming tegen DDoS-aanvallen (Distributed Denial of Service), functies die verder gaan dan de basisbeveiliging die Azure biedt.
  • Azure DNS is een hostingservice voor DNS-domeinen. Het biedt naamresolutie met behulp Microsoft Azure infrastructuur. Door uw domeinen in Azure te hosten, kunt u uw DNS-records met dezelfde referenties, API's, hulpprogramma's en facturering beheren als voor uw andere Azure-services. Azure DNS ondersteunt ook privé-DNS-zones. Azure DNS Private Zones naamresolutie in een virtueel netwerk, evenals tussen virtuele netwerken. De records in een privé-DNS-zone kunnen niet worden opgelost via internet. DNS-resolutie voor een privé-DNS-zone werkt alleen vanuit virtuele netwerken die er aan zijn gekoppeld.
  • Azure Virtual Network is een beveiligd particulier netwerk in de cloud. Het verbindt VM's met elkaar, met internet en met on-premises netwerken.
  • 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.

Aanbevelingen

De volgende aanbevelingen gelden voor de meeste scenario's. Volg deze aanbevelingen tenzij er een specifieke vereiste is die iets anders voorschrijft.

  • Gebruik ten minste twee Azure-regio's voor hogere beschikbaarheid. U kunt uw toepassing implementeren in meerdere Azure-regio's in actieve/passieve of actief/actieve configuraties. Zie Meerdere regio's voor meer informatie.
  • Voor productieworkloads moet u ten minste twee gateway-exemplaren uitvoeren. Houd er rekening mee dat in deze architectuur de openbare eindpunten van de toepassingsgateways worden geconfigureerd als de Traffic Manager back-end.
  • Gebruik regels voor netwerkbeveiligingsgroepen (NSG's) om verkeer tussen lagen te beperken. Zie Netwerkbeveiligingsgroepen voor meer informatie.

Beschikbaarheidsoverwegingen

Azure-beschikbaarheidszones

Azure-beschikbaarheidszones bieden hoge beschikbaarheid binnen een regio. Een regionaal netwerk verbindt ten minste drie fysiek afzonderlijke strategisch geplaatste datacenters in elke regio.

Meerdere regio's

Implementatie in meerdere regio's kan een hogere beschikbaarheid bieden dan implementeren in één regio. Als een regionale storing van invloed is op de primaire regio, kunt u met Traffic Manager een Failover-schakeling naar de secundaire regio uitvoeren. Meerdere regio's kunnen ook helpen als een afzonderlijk subsysteem van de toepassing uitvalt.

Houd er rekening mee dat deze architectuur van toepassing is op actief/passief en voor actief/actief-configuraties in Azure-regio's.

Zie Regio's en Beschikbaarheidszones in Azure voor technische informatie.

Gekoppelde regio's

Elke Azure-regio is gekoppeld aan een andere regio in dezelfde geografie (bijvoorbeeld de Verenigde Staten, Europa of Azië). Met deze benadering kunt u resources, zoals VM-opslag, repliceren tussen regio's. Het idee is om één regio beschikbaar te houden, zelfs als de andere regio niet meer beschikbaar is vanwege een natuurramp, ramp, stroomuitval, netwerkuitval, en meer.

Er zijn andere voordelen van regionale koppeling, waaronder:

  • In het geval van een bredere Azure-storing krijgt van elk paar één regio prioriteit, om te zorgen dat toepassingen zo snel mogelijk weer beschikbaar zijn.
  • Geplande Azure-updates worden voor gepaarde regio’s één voor één geïmplementeerd, om downtime en het risico op niet-beschikbare toepassingen te beperken.
  • Gegevens blijven voor juridische en belastingdoeleinden voor ieder paar binnen hetzelfde geografische gebied (met uitzondering van Brazilië - zuid).

Zorg ervoor dat beide regio's alle Azure-services ondersteunen die uw toepassing nodig heeft (zie Services per regio). Raadpleeg voor meer informatie over regioparen Bedrijfscontinuïteit en herstel na noodgevallen (BCDR): gekoppelde Azure-regio's voor meer informatie.

Configuratie van Traffic Manager

Traffic Manager biedt hoge beschikbaarheid voor uw kritieke toepassingen door eindpunten te bewaken en automatische failover te bieden wanneer een eindpunt uitvallen.

Houd rekening met de volgende punten bij het configureren van Traffic Manager:

  • Routering: Traffic Manager ondersteunt zes verkeersrouteringsmethoden om te bepalen hoe verkeer naar de verschillende service-eindpunten moet worden geroutering. In deze architectuur gebruiken we prestatieroutering, die verkeer doorstuurt naar het eindpunt met de laagste latentie voor de gebruiker. Traffic Manager wordt automatisch aangepast wanneer de latentie van eindpunten verandert. Als u meer gedetailleerde controle nodig hebt, bijvoorbeeld om een voorkeurs-failover binnen een regio te kiezen, kunt u Traffic Manager gebruiken in een geneste configuratie.

    Zie Configure the performance traffic routing method (De routeringsmethode voor prestatieverkeer configureren) voor configuratie-informatie.

    Zie routeringsmethoden voor meer informatie Traffic Manager routeringsmethoden.

  • Statustest: Traffic Manager maakt gebruik van een HTTP-test (of HTTPS)-test om de beschikbaarheid van elke regio te bewaken. Met de test wordt gecontroleerd op een HTTP 200-respons van een opgegeven URL-pad. Maak, als een best practice, een eindpunt waarmee de algemene status van de toepassing wordt gerapporteerd en gebruik dit eindpunt voor de statustest. Anders kan de test een goed eindpunt rapporteren wanneer kritieke onderdelen van de toepassing mislukken. Zie Health Endpoint Monitoring pattern (Patroon Status van eindpuntbewaking) voor meer informatie.

    Tijdens het uitvoeren van deze Failover-overschakeling door Traffic Manager is de toepassing tijdelijk niet bereikbaar voor clients. Hoe lang dit duurt, is afhankelijk van de volgende factoren:

    • Met de statustest moet worden gedetecteerd dat de primaire regio onbereikbaar is geworden.
    • DNS-servers moeten de DNS-records voor het IP-adres in de cache bijwerken. Hoe lang dit duurt, is afhankelijk van de DNS TTL (Time To Live). Standaard is de TTL-waarde 300 seconden (5 minuten), maar u kunt deze waarde configureren wanneer u het Traffic Manager-profiel maakt.

    Zie About Traffic Manager Monitoring (Over Traffic Manager bewaking) voor meer informatie.

  • Verkeersweergave: schakel Verkeersweergave om te begrijpen welke regio's een grote hoeveelheid verkeer hebben, maar last hebben van hogere latentie. Vervolgens gebruikt u deze informatie om uw footprint-uitbreiding naar nieuwe Azure-regio's te plannen. Op die manier hebben uw gebruikers een lagere latentie. Zie Traffic Manager Verkeersweergave voor meer informatie.

Application Gateway

  • Application Gateway v1 SKU ondersteunt scenario's met hoge beschikbaarheid wanneer u twee of meer exemplaren hebt geïmplementeerd. Azure distribueert deze exemplaren over update- en foutdomeinen om ervoor te zorgen dat exemplaren niet allemaal tegelijk mislukken. De v1-SKU ondersteunt schaalbaarheid door meerdere exemplaren van dezelfde gateway toe te voegen om de belasting te delen.
  • Application Gateway v2 SKU zorgt er automatisch voor dat nieuwe exemplaren worden verdeeld over foutdomeinen en updatedomeinen. Als u zone-redundantie kiest, worden de nieuwste exemplaren ook verdeeld over beschikbaarheidszones om zonefout resiliency te bieden.

Statuscontroles

Application Gateway en 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 HTTP of TCP testen. 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 Application Gateway of Load Balancer verzenden van verkeer naar die VM. De test blijft controleren en retournt de VM naar de back-endpool als de VM weer beschikbaar wordt. 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.

Beheerbaarheidsoverwegingen

  • Resourcegroepen: gebruik Resourcegroepen om Azure-resources te beheren op levensduur, eigenaar en andere kenmerken.
  • Peering voor virtuele netwerken: gebruik peering voor virtuele netwerken om naadloos twee of meer virtuele netwerken in Azure te verbinden. De virtuele netwerken worden voor connectiviteitsdoeleinden als één netwerk weergegeven. Het verkeer tussen virtuele machines in virtuele peernetwerken maakt gebruik van de Microsoft-backbone-infrastructuur. Zorg ervoor dat de adresruimte van de virtuele netwerken niet overlapt. In dit scenario worden de virtuele netwerken via wereldwijde peering van virtuele netwerken via peering aan elkaar verbonden om gegevensreplicatie van de primaire regio naar de secundaire regio toe te staan.
  • Virtueel netwerk en subnetten: azure-VM's en specifieke Azure-resources (zoals Application Gateway en Load Balancer) worden geïmplementeerd in een virtueel netwerk dat kan worden gesegmenteerd in subnetten. Maak een apart subnet voor elke laag.

Beveiligingsoverwegingen

  • Gebruik DDoS Protection Standard voor meer DDoS-beveiliging dan de basisbeveiliging die Azure biedt. Zie Beveiligingsoverwegingen voor meer informatie.
  • Gebruik netwerkbeveiligingsgroepen (NSG's) om netwerkverkeer binnen het virtuele netwerk te beperken. In de architectuur met drie lagen die hier wordt weergegeven, accepteert de databaselaag bijvoorbeeld alleen verkeer van de bedrijfslaag en het Bastion-subnet, niet van de webfront-end.

Netwerkbeveiligingsgroepen

Alleen de bedrijfslaag kan rechtstreeks communiceren met de databaselaag. Als u deze regel wilt afdwingen, moet de databaselaag al het binnenkomende verkeer blokkeren, met uitzondering van het subnet bedrijfslaag.

  1. Al het binnenkomende verkeer van het virtuele netwerk weigeren. (Gebruik de VIRTUAL_NETWORK in de regel.)
  2. Toestaan van inkomende verkeer van de bedrijfslaag subnet.
  3. 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.

U kunt servicetags gebruiken voor het definiëren van besturingselementen voor netwerktoegang in netwerkbeveiligingsgroepen of Azure Firewall. Zie Application Gateway infrastructuurconfiguratie voor meer informatie over Application Gateway NSG-vereisten.

Prijzen

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 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 één VM Windows Virtual Machines prijzen.

Standard Load Balancer

De prijzen van Standard Load Balancer worden elk uur gebaseerd op het aantal geconfigureerde regels voor uitgaande taakverdeling. Inkomende NAT-regels zijn gratis. Er worden geen kosten per uur in rekening brengen voor de Standard-SKU Load Balancer wanneer er geen regels zijn geconfigureerd. Er worden ook kosten in rekening brengen voor de hoeveelheid gegevens die door de Load Balancer verwerkt.

Zie Load Balancing pricing (Prijzen van taakverdeling) voor meer informatie.

Application Gateway v2 SKU

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 prijzen voor Application Gateway meer informatie.

Traffic Manager

Traffic Manager facturering is gebaseerd op het aantal ONTVANGEN DNS-query's, met korting voor services die meer dan 1 miljard maandelijkse query's ontvangen. Er worden ook kosten in rekening gebracht voor elk bewaakt eindpunt. Zie prijzen voor Traffic Manager prijsinformatie.

Peering op virtueel netwerk

Een implementatie met hoge beschikbaarheid die gebruik maakt van meerdere Azure-regio's maakt gebruik van peering voor virtuele netwerken. De kosten voor peering van virtuele netwerken binnen dezelfde regio zijn niet hetzelfde als de kosten voor wereldwijde peering voor virtuele netwerken.

Zie Prijzen voor Virtual Network voor meer informatie.

Volgende stappen

Zie voor aanvullende referentiearchitectarchitecten die gebruikmaken van dezelfde technologieën: