Dela via

Hög tillgänglighet och belastningsutjämning för dina privata nätverksanslutningar och program

  • Artikel

Den här artikeln beskriver hur trafikdistribution fungerar med distributionen av programproxyn. Lär dig hur trafik distribueras mellan användare och anslutningsappar, tillsammans med tips för att optimera anslutningsprestanda. Lär dig hur trafik flödar mellan anslutningsappar och serverdelsappservrar, med rekommendationer för belastningsutjämning mellan flera serverdelsservrar.

Trafikdistribution mellan anslutningsappar

Anslut orer upprättar sina anslutningar baserat på principer för hög tillgänglighet. Det finns ingen garanti för att trafiken är jämnt fördelad över anslutningsappar och att det inte finns någon sessionstillhörighet. Användningen varierar dock och begäranden skickas slumpmässigt till programproxytjänstinstanser. Därför distribueras trafiken vanligtvis nästan jämnt över anslutningsapparna. Diagrammet och stegen visar hur anslutningar upprättas mellan användare och anslutningsappar.

Diagram som visar anslutningar mellan användare och anslutningsappar

  1. En användare på en klientenhet försöker komma åt ett lokalt program som publicerats via programproxy.
  2. Begäran går via en Azure Load Balancer för att avgöra vilken programproxytjänstinstans som ska ta begäran. Det finns tiotals instanser tillgängliga för att acceptera begäranden för all trafik i regionen. Den här metoden hjälper till att fördela trafiken jämnt mellan tjänstinstanserna.
  3. Begäran skickas till Service Bus.
  4. Service Bus-signaler till en tillgänglig anslutningsapp. Anslutningsappen hämtar sedan begäran från Service Bus.
    • I steg 2 går begäranden till olika programproxytjänstinstanser, så anslutningar är mer benägna att göras med olika anslutningsappar. Därför används anslutningsappar nästan jämnt i gruppen.
  5. Anslutningsappen skickar begäran till programmets serverdelsserver. Sedan skickar programmet tillbaka svaret till anslutningsappen.
  6. Anslutningsappen slutför svaret genom att öppna en utgående anslutning till tjänstinstansen varifrån begäran kom. Sedan stängs anslutningen omedelbart. Som standard är varje anslutningsapp begränsad till 200 samtidiga utgående anslutningar.
  7. Svaret skickas sedan tillbaka till klienten från tjänstinstansen.
  8. Efterföljande begäranden från samma anslutning upprepar stegen.

Ett program har ofta många resurser och öppnar flera anslutningar under belastning. Varje anslutning går igenom stegen för att allokeras till en tjänstinstans. Om anslutningen inte är kopplad till en anslutningsapp väljer du en ny tillgänglig anslutningsapp.

Metodtips för hög tillgänglighet för anslutningsappar

  • På grund av hur trafik distribueras mellan anslutningsappar för hög tillgänglighet är det viktigt att alltid ha minst två anslutningsappar i en anslutningsgrupp. Tre anslutningsappar är att föredra för att tillhandahålla extra buffert mellan anslutningsappar. Följ dokumentationen om kapacitetsplanering för att fastställa rätt antal anslutningsappar som du behövde.

  • Placera anslutningsappar på olika utgående anslutningar för att undvika en felpunkt. Om anslutningsappar använder samma utgående anslutning påverkar ett nätverksproblem med anslutningen alla anslutningsappar som använder den.

  • Undvik att tvinga anslutningsappar att starta om när de är anslutna till produktionsprogram. Detta kan påverka fördelningen av trafik mellan anslutningsappar negativt. Omstart av anslutningsappar gör att fler anslutningsappar inte är tillgängliga och tvingar anslutningar till den återstående tillgängliga anslutningsappen. Resultatet är en ojämn användning av anslutningsapparna från början.

  • Undvik alla former av infogad inspektion av utgående TLS-kommunikation (Transport Layer Security) mellan anslutningsappar och Azure. Den här typen av infogad inspektion orsakar försämring av kommunikationsflödet.

  • Se till att hålla automatiska uppdateringar igång för dina anslutningsappar. Om uppdateringstjänsten för privata nätverksanslutningar körs uppdateras anslutningsapparna automatiskt och får den senaste uppgraderade. Om du inte ser tjänsten Anslut eller Updater på servern måste du installera om anslutningsappen för att få uppdateringar.

Trafikflöde mellan anslutningsappar och serverdelsprogramservrar

Ett annat viktigt område där hög tillgänglighet är en faktor är anslutningen mellan anslutningsappar och serverdelsservrarna. När ett program publiceras via Microsoft Entra-programproxy flödar trafik från användarna till programmen via tre hopp:

  1. Användaren ansluter till den offentliga slutpunkten för Microsoft Entra-programproxytjänsten i Azure. Anslutningen upprättas mellan klientens ursprungliga IP-adress (offentlig) för klienten och IP-adressen för programproxyslutpunkten.
  2. Den privata nätverksanslutningen hämtar HTTP-begäran från klienten från programproxytjänsten.
  3. Den privata nätverksanslutningen ansluter till målprogrammet. Anslutningsappen använder sin egen IP-adress för att upprätta anslutningen.

Diagram över användare som ansluter till ett program via programproxy

Överväganden för sidhuvudfält i X-Forwarded-For

I vissa situationer (till exempel granskning, belastningsutjämning och så vidare) är det ett krav att dela den externa klientens ursprungliga IP-adress med den lokala miljön. För att uppfylla kravet lägger Microsoft Entras privata nätverksanslutning till fältet X-Forwarded-For med den ursprungliga klientens IP-adress (offentlig) i HTTP-begäran. Lämplig nätverksenhet (lastbalanserare, brandvägg) eller webbservern eller serverdelsprogrammet kan sedan läsa och använda informationen.

Metodtips för belastningsutjämning mellan flera programservrar

Belastningsutjämning är viktigt när anslutningsgruppen som tilldelats programproxyprogrammet har två eller flera anslutningsappar. Belastningsutjämning är också viktigt när du kör serverdelswebbprogrammet på flera servrar.

Scenario 1: Serverdelsprogrammet kräver inte sessionspersistens

Det enklaste scenariot är att serverdelswebbprogrammet inte kräver sessionsstinne (sessionspersistens). En serverdelsprograminstans hanterar användarbegäranden i servergruppen. Du kan använda en layer 4-lastbalanserare och konfigurera den utan tillhörighet. Några alternativ är Microsoft Network Load Balancing och Azure Load Balancer eller en lastbalanserare från en annan leverantör. Du kan också konfigurera en DNS-strategi (Round-Robin Domain Name System).

Scenario 2: Serverdelsprogrammet kräver sessionspersistens

I det här scenariot kräver serverdelswebbprogrammet sessionshållning (sessionspersistens) under den autentiserade sessionen. Serverdelsprograminstansen hanterar användarbegäranden. Begäranden körs på samma server i servergruppen. Det här scenariot kan vara mer komplicerat eftersom klienten vanligtvis upprättar flera anslutningar till programproxytjänsten. Begäranden om olika anslutningar kan komma till olika anslutningsappar och servrar i servergruppen. Eftersom varje anslutningsapp använder sin egen IP-adress för den här kommunikationen kan lastbalanseraren inte säkerställa sessionsstinne baserat på IP-adressen för anslutningsapparna. Käll-IP-tillhörighet kan inte heller användas. Här följer några alternativ för scenario 2:

  • Alternativ 1: Basera sessionspersistenceen på en sessionscookie som angetts av lastbalanseraren. Det här alternativet rekommenderas eftersom det gör att belastningen kan spridas jämnare mellan serverdelsservrarna. Det kräver en layer 7-lastbalanserare med den här funktionen och som kan hantera HTTP-trafiken och avsluta TLS-anslutningen. Du kan använda Azure Application Gateway (sessionstillhörighet) eller en lastbalanserare från en annan leverantör.

  • Alternativ 2: Basera sessionspersistensen på fältet X-Forwarded-For header. Det här alternativet kräver en layer 7-lastbalanserare med den här funktionen och som kan hantera HTTP-trafiken och avsluta TLS-anslutningen.

  • Alternativ 3: Konfigurera serverdelsprogrammet så att det inte kräver sessionspersistens.

Information om belastningsutjämningskraven för serverdelsprogrammet finns i dokumentationen till programvaruleverantören.

Nästa steg