Virtuele netwerkapparaten met hoge beschikbaarheid implementeren op Azure Stack Hub

In dit artikel wordt beschreven hoe u een set virtuele netwerkapparaten (NVA's) implementeert voor hoge beschikbaarheid in Azure Stack Hub. Een NVA wordt meestal gebruikt om de stroom netwerkverkeer van een perimeternetwerk (ook wel een DMZ genoemd) naar andere netwerken of subnetten te regelen. Dit artikel bevat een voorbeeldarchitecturen voor alleen inkomend verkeer, alleen uitgaand verkeer en zowel inkomend als uitgaand verkeer.

Er zijn NVA's van verschillende leveranciers beschikbaar op Azure Stack Hub Marketplace. Gebruik er een voor optimale prestaties.

De architectuur heeft de volgende onderdelen:

Netwerken en taakverdeling

• Virtueel netwerk en subnetten. Elke Virtuele Azure-machine wordt geïmplementeerd in een virtueel netwerk dat kan worden gesegmenteerd in subnetten. Maak een apart subnet voor elke laag.

• Laag 7 Load Balancer. Omdat Application Gateway nog niet beschikbaar is in Azure Stack Hub, zijn er alternatieven beschikbaar op Azure Stack Hub Marketplace, zoals KEMP LoadMaster Load Balancer ADC Content Switch/ f5 Big-IP Virtual Edition of A10 vThunder ADC

• Load balancers. Gebruik Azure Load Balancer om netwerkverkeer te distribueren van de weblaag naar de bedrijfslaag en van de bedrijfslaag naar SQL Server.

• Netwerkbeveiligingsgroepen (NSG's). Gebruik NSG's om netwerkverkeer binnen het virtuele netwerk te beperken. In de architectuur met drie lagen die hier wordt weergegeven, accepteert de databaselaag bijvoorbeeld geen verkeer van de webfront-end, alleen van de bedrijfslaag en het beheersubnet.

• UDR's. Gebruik door de gebruiker gedefinieerde routes (UDR's) om verkeer naar de specifieke load balancer te routeren.

In dit artikel wordt ervan uitgegaan dat u basiskennis hebt van Azure Stack Hub-netwerken.

Architectuurdiagrammen

Een NVA kan in veel verschillende architecturen worden geïmplementeerd in een perimeternetwerk. De volgende afbeelding illustreert bijvoorbeeld het gebruik van één NVA voor inkomend verkeer.

In deze architectuur biedt de NVA een beveiligde netwerkgrens door al het inkomende en uitgaande netwerkverkeer te controleren en alleen het verkeer door te laten dat voldoet aan netwerkbeveiligingsregels. Het feit dat al het netwerkverkeer via de NVA moet worden doorgegeven, betekent dat de NVA een Single Point of Failure in het netwerk is. Als de NVA uitvalt, is er geen ander pad voor het netwerkverkeer en zijn alle back-end-subnetten niet beschikbaar.

Als u wilt zorgen dat een NVA maximaal beschikbaar is, dient u meer dan één NVA te implementeren in een beschikbaarheidsset.

De volgende architecturen beschrijven de resources en configuratie die nodig zijn voor NVA's met een hoge beschikbaarheid:

Oplossing	Voordelen	Overwegingen
Inkomend verkeer met NVA's in laag 7	Alle NVA-knooppunten zijn actief.	Vereist een NVA die verbindingen kan beëindigen en SNAT kan gebruiken. Vereist een afzonderlijke set NVA's voor verkeer dat afkomstig is van het bedrijfsnetwerk/internet en van Azure Stack Hub. Kan alleen worden gebruikt voor verkeer dat afkomstig is van buiten Azure Stack Hub.
Uitgaand verkeer met NVA's in laag 7	Alle NVA-knooppunten zijn actief.	Vereist een NVA die verbindingen kan beëindigen en SNAT (Source Network Address Translation) implementeert.
Inkomend/uitgaand verkeer met NVA's in laag 7	Alle knooppunten zijn actief. Kan verkeer verwerken dat afkomstig is van Azure Stack Hub.	Vereist een NVA die verbindingen kan beëindigen en SNAT kan gebruiken. Vereist een afzonderlijke set NVA's voor verkeer dat afkomstig is van het bedrijfsnetwerk/internet en van Azure Stack Hub.

Inkomend verkeer met NVA's in laag 7

In de volgende afbeelding ziet u een architectuur voor hoge beschikbaarheid die een perimeternetwerk voor inkomend verkeer implementeert achter een internetgerichte load balancer. Deze architectuur is ontworpen om connectiviteit te bieden met Azure Stack Hub-workloads voor verkeer op laag 7, zoals HTTP of HTTPS:

Het voordeel van deze architectuur is dat alle NVA's actief zijn. Als er één NVA uitvalt, stuurt de load balancer netwerkverkeer naar de andere NVA. Beide NVA's routeren verkeer naar de interne load balancer, dus het verkeer blijft stromen zolang er één NVA actief is. De NVA's moeten SSL-verkeer dat is bedoeld voor de VM's in de weblaag kunnen beëindigen. Deze NVA's kunnen niet worden uitgebreid voor het verwerken van Enterprise Network-verkeer, omdat voor enterprisenetwerkverkeer een andere toegewezen set NVA's met eigen netwerkroutes is vereist.

Uitgaand verkeer met NVA's in laag 7

De architectuur inkomend verkeer met laag 7 NVA's kan worden uitgebreid om een uitgaand perimeternetwerk te bieden voor aanvragen die afkomstig zijn uit de Azure Stack Hub-workload. De volgende architectuur is ontworpen om hoge beschikbaarheid van de NVA's in het perimeternetwerk te bieden voor verkeer op laag 7, zoals HTTP of HTTPS:

In deze architectuur wordt al het verkeer dat afkomstig is van Azure Stack Hub doorgestuurd naar een interne load balancer. De load balancer verdeelt uitgaande aanvragen tussen een set NVA's. Deze NVA's leiden verkeer naar internet met hun afzonderlijke openbare IP-adressen.

Inkomend/uitgaand verkeer met NVA's in laag 7

In de twee architecturen voor inkomend en uitgaand verkeer was er een afzonderlijk perimeternetwerk voor inkomend en uitgaand verkeer. De volgende architectuur laat zien hoe u een perimeternetwerk maakt dat kan worden gebruikt voor zowel inkomend als uitgaand verkeer van laag 7, zoals HTTP of HTTPS:

In de architectuur Van inkomend uitgaand verkeer met laag 7 NVA's verwerken de NVA's binnenkomende aanvragen van een laag 7-Load Balancer. De NVA's verwerken ook uitgaande aanvragen van de workload-VM's in de back-end-pool van de load balancer. Omdat binnenkomend verkeer wordt gerouteerd met een load balancer op laag 7 en uitgaand verkeer wordt gerouteerd met een SLB (Azure Stack Hub Basic Load Balancer), zijn de NVA's verantwoordelijk voor het onderhouden van sessieaffiniteit. Dat wil dat de load balancer van laag 7 een toewijzing bijhoudt van binnenkomende en uitgaande aanvragen, zodat het juiste antwoord kan worden doorgestuurd naar de oorspronkelijke aanvrager. De interne load balancer heeft echter geen toegang tot de laag 7 load balancer-toewijzingen en gebruikt zijn eigen logica om antwoorden naar de NVA's te verzenden. Het is mogelijk dat de load balancer een antwoord kan verzenden naar een NVA die de aanvraag in eerste instantie niet heeft ontvangen van de load balancer van laag 7. In dit geval moeten de NVA's het antwoord onderling communiceren en overdragen, zodat de juiste NVA het antwoord kan doorsturen naar de load balancer van laag 7.

Notitie

U kunt het probleem van asymmetrische routering ook oplossen door ervoor te zorgen dat de NVA's SNAT (adresomzetting voor het inkomende bronnetwerk) uitvoeren. Hierbij zou het oorspronkelijke bron-IP-adres van de aanvrager worden vervangen door een van de IP-adressen van de NVA die is gebruikt voor de inkomende stroom. Dit zorgt ervoor dat u meerdere NVA's tegelijk kunt gebruiken terwijl de routesymmetrie behouden blijft.

Volgende stappen

• Zie Azure Stack Hub VM-functies voor meer informatie over Azure Stack Hub-VM's.
• Zie Cloudontwerppatronen voor meer informatie over Azure-cloudpatronen.