Lezen in het Engels

Delen via

Hoge beschikbaarheid en taakverdeling van uw privénetwerkconnectors en -toepassingen

  • Artikel

In dit artikel wordt uitgelegd hoe verkeerdistributie werkt met de implementatie van uw toepassingsproxy. Meer informatie over hoe verkeer wordt verdeeld over gebruikers en connectors, samen met tips voor het optimaliseren van de prestaties van connectors. Meer informatie over hoe verkeer stroomt tussen connectors en back-end-app-servers, met aanbevelingen voor taakverdeling tussen meerdere back-endservers.

Distributie van verkeer over connectors

Connectors brengen hun verbindingen tot stand op basis van principes voor hoge beschikbaarheid. Er is geen garantie dat verkeer gelijkmatig wordt verdeeld over connectors en dat er geen sessieaffiniteit is. Het gebruik varieert echter en aanvragen worden willekeurig verzonden naar exemplaren van de toepassingsproxyservice. Als gevolg hiervan wordt verkeer doorgaans bijna gelijkmatig verdeeld over de connectors. Het diagram en de stappen laten zien hoe verbindingen tot stand worden gebracht tussen gebruikers en connectors.

Diagram met verbindingen tussen gebruikers en connectors

  1. Een gebruiker op een clientapparaat probeert toegang te krijgen tot een on-premises toepassing die is gepubliceerd via de toepassingsproxy.
  2. De aanvraag gaat via een Azure Load Balancer om te bepalen welk exemplaar van de toepassingsproxyservice de aanvraag moet nemen. Er zijn tientallen exemplaren beschikbaar om de aanvragen voor al het verkeer in de regio te accepteren. Met deze methode kunt u het verkeer gelijkmatig verdelen over de exemplaren van de service.
  3. De aanvraag wordt verzonden naar Service Bus.
  4. Service Bus-signalen naar een beschikbare connector. De connector haalt vervolgens de aanvraag van Service Bus op.
    • In stap 2 gaan aanvragen naar verschillende exemplaren van de toepassingsproxyservice, zodat verbindingen waarschijnlijker worden gemaakt met verschillende connectors. Als gevolg hiervan worden connectors bijna gelijkmatig binnen de groep gebruikt.
  5. De connector geeft de aanvraag door aan de back-endserver van de toepassing. Vervolgens stuurt de toepassing het antwoord terug naar de connector.
  6. De connector voltooit het antwoord door een uitgaande verbinding te openen met het exemplaar van de service van waaruit de aanvraag is ontvangen. Vervolgens wordt deze verbinding onmiddellijk gesloten. Elke connector is standaard beperkt tot 200 gelijktijdige uitgaande verbindingen.
  7. Het antwoord wordt vervolgens vanuit het exemplaar van de service teruggegeven aan de client.
  8. Volgende aanvragen van dezelfde verbinding herhalen de stappen.

Een toepassing heeft vaak veel resources en opent meerdere verbindingen wanneer deze worden geladen. Elke verbinding doorloopt de stappen die moeten worden toegewezen aan een service-exemplaar. Als de verbinding niet is gekoppeld aan een connector, selecteert u een nieuwe beschikbare connector.

Aanbevolen procedures voor hoge beschikbaarheid van connectors

  • Vanwege de manier waarop verkeer wordt verdeeld over connectors voor hoge beschikbaarheid, is het essentieel om altijd tenminste twee connectors in een connectorgroep te hebben. Drie connectors hebben de voorkeur om extra buffer te bieden tussen connectors. Volg de documentatie voor capaciteitsplanning om het juiste aantal connectors te bepalen dat u nodig hebt.

  • Plaats connectors op verschillende uitgaande verbindingen om één storingspunt te voorkomen. Als connectors dezelfde uitgaande verbinding gebruiken, heeft een netwerkprobleem met de verbinding invloed op alle connectors die deze gebruiken.

  • Vermijd het afdwingen dat connectors opnieuw worden opgestart wanneer deze zijn verbonden met productietoepassingen. Dit kan een negatieve invloed hebben op de distributie van verkeer tussen connectors. Het opnieuw opstarten van connectors zorgt ervoor dat meer connectors niet beschikbaar zijn en dwingt verbindingen met de resterende beschikbare connector af. Het resultaat is in eerste instantie een ongelijk gebruik van de connectors.

  • Vermijd alle vormen van inline-inspectie op uitgaande TLS-communicatie (Transport Layer Security) tussen connectors en Azure. Dit type inline inspectie veroorzaakt een verslechtering van de communicatiestroom.

  • Zorg dat automatische updates worden uitgevoerd voor uw connectors. Als de Updater-service voor de privénetwerkconnector wordt uitgevoerd, worden uw connectors automatisch bijgewerkt en ontvangen ze de meest recente upgrade. Als u de Connector Updater-service niet ziet op uw server, moet u de connector opnieuw installeren om updates op te halen.

Verkeersstroom tussen connectors en toepassingsservers voor de back-end

Een ander belangrijk gebied waarbij hoge beschikbaarheid een factor is, is de verbinding tussen connectors en de back-endservers. Wanneer een toepassing wordt gepubliceerd via de Microsoft Entra-toepassingsproxy, stroomt verkeer van de gebruikers naar de toepassingen via drie hops:

  1. De gebruiker maakt verbinding met het openbare eindpunt van de Microsoft Entra-toepassingsproxyservice in Azure. De verbinding wordt tot stand gebracht tussen het ip-adres van de oorspronkelijke client (openbaar) van de client en het IP-adres van het eindpunt van de toepassingsproxy.
  2. De privénetwerkconnector haalt de HTTP-aanvraag van de client op uit de toepassingsproxyservice.
  3. De privénetwerkconnector maakt verbinding met de doeltoepassing. De connector gebruikt een eigen IP-adres om de verbinding tot stand te brengen.

Diagram van de gebruiker die verbinding maakt met een toepassing via een toepassingsproxy

Overwegingen voor het veld X-Doorgestuurd-Voor koptekst

In sommige situaties (zoals controle, taakverdeling, enzovoort), is het delen van het oorspronkelijke IP-adres van de externe client met de on-premises omgeving een vereiste. Om aan de vereiste te voldoen, voegt microsoft Entra private network connector het veld X-Forwarded-For header toe met het ip-adres van de oorspronkelijke client (openbaar) aan de HTTP-aanvraag. Het juiste netwerkapparaat (load balancer, firewall) of de webserver of back-endtoepassing kan de informatie vervolgens lezen en gebruiken.

Aanbevolen procedures voor taakverdeling tussen meerdere toepassingsservers

Taakverdeling is belangrijk wanneer de connectorgroep die is toegewezen aan de toepassingsproxy twee of meer connectors heeft. Taakverdeling is ook belangrijk wanneer u de back-endwebtoepassing uitvoert op meerdere servers.

Scenario 1: Back-endtoepassing vereist geen sessiepersistentie

Het eenvoudigste scenario is waarbij de webtoepassing aan de back-end geen session stickiness (sessiepersistentie) vereist. Een exemplaar van een back-endtoepassing verwerkt gebruikersaanvragen in de serverfarm. U kunt een load balancer van laag 4 gebruiken en zonder affiniteit configureren. Enkele opties zijn onder andere Microsoft Network Load Balancing en Azure Load Balancer of een load balancer van een andere leverancier. U kunt ook een round robin Domain Name System-strategie (DNS) configureren.

Scenario 2: back-endtoepassing vereist geen sessiepersistentie

In dit scenario vereist de webtoepassing aan de back-end sessie stickiness (sessiepersistentie) tijdens de geverifieerde sessie. Het exemplaar van de back-endtoepassing verwerkt gebruikersaanvragen. De aanvragen worden uitgevoerd op dezelfde server in de serverfarm. Dit scenario kan ingewikkelder zijn omdat de client meestal meerdere verbindingen tot stand brengt met de toepassingsproxyservice. Aanvragen via verschillende verbindingen kunnen verschillende connectors en servers in de farm bereiken. Omdat elke connector voor deze communicatie een eigen IP-adres gebruikt, kan de load balancer niet zorgen voor sessie stickiness op basis van het IP-adres van de connectors. Affiniteit van het bron-IP-adres kan ook niet worden gebruikt. Hier volgen enkele opties voor scenario 2:

  • Optie 1: de sessiepersistentie baseren op een sessiecookie die is ingesteld door de load balancer. Deze optie wordt aanbevolen omdat de belasting gelijkmatiger kan worden verdeeld over de back-endservers. Hiervoor is een load balancer van laag 7 vereist met deze mogelijkheid en die het HTTP-verkeer kan verwerken en de TLS-verbinding kan beëindigen. U kunt Azure Application Gateway (sessieaffiniteit) of een load balancer van een andere leverancier gebruiken.

  • Optie 2: de sessiepersistentie baseren op het veld X-Forwarded-For. Voor deze optie is een load balancer van laag 7 met deze mogelijkheid vereist die het HTTP-verkeer kan verwerken en de TLS-verbinding kan beëindigen.

  • Optie 3: configureer de back-endtoepassing om sessiepersistentie niet te vereisen.

Raadpleeg de documentatie van uw softwareleverancier om inzicht te hebben in de taakverdelingsvereisten van de back-endtoepassing.

Volgende stappen