Sådan fungerer Azure Load Balancer

Fuldført

Azure Load Balancer arbejder på transportlaget i OSI-modellen. Denne Layer 4-funktionalitet gør det muligt at administrere trafik baseret på bestemte egenskaber for trafikken. Egenskaber, herunder kilde- og destinationsadresse, TCP- eller UDP-protokoltype og portnummer.

Load Balancer har flere elementer, der arbejder sammen for at sikre et programs høje tilgængelighed og ydeevne:

  • Front-end IP
  • Regler for justering af belastning
  • Back end-pulje
  • Sundhedsmæssige sonder
  • Indgående NAT-regler
  • Porte med høj tilgængelighed
  • Udgående regler

Front-end IP

Frontend-IP-adressen er den adresse, klienter bruger til at oprette forbindelse til webprogrammet. En frontend-IP-adresse kan enten være en offentlig eller en privat IP-adresse. Azure-belastningsjusteringer kan have flere frontend-IP'er. Valget af en offentlig eller en privat IP-adresse bestemmer, hvilken type belastningsjustering der skal oprettes:

  • Offentlig IP-adresse: En offentlig belastningsjustering: En offentlig belastningsjustering knytter den offentlige IP og porten for indgående trafik til den private IP og porten for den virtuelle maskine. Du kan distribuere bestemte trafiktyper på tværs af flere VM'er eller tjenester ved at anvende regler for justering af belastning. Du kan f.eks. sprede belastningen af webanmodningstrafik på tværs af flere webservere. Belastningsjusteringen knytter svartrafikken fra den private IP og porten for den virtuelle maskine til den offentlige IP og porten for belastningsjusteringen. Derefter sender den svaret tilbage til den anmodende klient.

  • Privat IP-adresse: En intern belastningsjustering: En intern belastningsjustering distribuerer trafik til ressourcer, der er i et virtuelt netværk. Azure begrænser adgangen til frontend-IP-adresserne for et virtuelt netværk, der er belastningsbalanceret. Frontend-IP-adresser og virtuelle netværk udsættes aldrig direkte for et internetslutpunkt. Interne line of business-programmer kører i Azure og tilgås fra Azure eller fra ressourcer i det lokale miljø via en VPN- eller ExpressRoute-forbindelse.

    diagram, der viser, hvordan offentlige og interne belastningsjusteringer fungerer i Azure Load Balancer.

Regler for justering af belastning

En regel for belastningsjustering definerer, hvordan trafik distribueres til back end-gruppen. Reglen knytter en given frontend-IP- og portkombination til et sæt back end IP-adresser og portkombination.

diagram, der viser, hvordan regler for justering af belastning fungerer i Azure Load Balancer.

Trafik administreres ved hjælp af en femtuppelhash, der er lavet af følgende elementer:

  • Kilde-IP-: IP-adressen på den klient, der anmoder om det.
  • Kildeport: Porten for den klient, der anmoder om det.
  • DESTINATIONS-IP-: Destinationens IP-adresse for anmodningen.
  • destinationsport: Destinationsporten for anmodningen.
  • protokoltype: Den angivne protokoltype, TCP eller UDP.
  • sessionens tilhørsforhold: Sikrer, at den samme puljenode altid håndterer trafik for en klient.

Med Load Balancer kan du udføre belastningsjusteringstjenester på flere porte, flere IP-adresser eller begge dele. Du kan konfigurere forskellige regler for justering af belastning for hver frontend-IP. Flere frontendkonfigurationer understøttes kun med IaaS VM'er.

Load Balancer kan ikke anvende forskellige regler, der er baseret på internt trafikindhold, fordi det kører på Lag 4 (transportlag) i OSI-modellen. Hvis du har brug for at administrere trafik baseret på egenskaberne for Layer 7 (programlag), skal du installere en løsning som Azure Application Gateway.

Back end-pulje

Back end-gruppen er en gruppe VM'er eller forekomster i et virtual machine scale-sæt, der svarer på den indgående anmodning. Hvis du vil skalere omkostningseffektivt for at imødekomme store mængder indgående trafik, anbefaler retningslinjer for databehandling generelt, at der føjes flere forekomster til back end-puljen.

Load Balancer implementerer automatisk omkonfiguration for at videredistribuere belastningen på tværs af det ændrede antal forekomster, når du skalerer forekomster op eller ned. Hvis du f.eks. har føjet yderligere to VM'er til back end-gruppen, omkonfigurerer Load Balancer sig selv for at begynde at afbalancere trafikken til disse forekomster baseret på de allerede konfigurerede regler for justering af belastning.

Sundhedsmæssige sonder

En tilstandssonde bruges til at bestemme tilstandsstatussen for forekomsterne i back end-gruppen. Denne tilstandssonde bestemmer, om en forekomst er sund og kan modtage trafik. Du kan definere den usunde grænse for dine tilstandssonder. Når en sonde ikke reagerer, stopper belastningsjusteringen med at sende nye forbindelser til de usunde forekomster. En sondefejl påvirker ikke eksisterende forbindelser. Forbindelsen fortsætter indtil:

  • Programmet afslutter flowet.
  • Timeout for inaktivitet opstår.
  • Vm'en lukkes ned.

Med Load Balancer kan du konfigurere forskellige tilstandssondetyper for slutpunkter: TCP, HTTP og HTTPS.

  • brugerdefineret TCP-sonde: Denne sonde er afhængig af, at der oprettes en vellykket TCP-session til en defineret sondeport. Hvis den angivne lyttefunktion på den virtuelle maskine findes, lykkes sonden. Hvis forbindelsen afvises, mislykkes sonden. Du kan angive grænsen Port, Interval og Usund.
  • brugerdefineret HTTP- eller HTTPS-sonde: Belastningsjusteringen sonderer jævnligt dit slutpunkt (hvert 15. sekund som standard). Forekomsten er i orden, hvis den svarer med en HTTP 200 inden for timeoutperioden (standard på 31 sekunder). En anden status end HTTP 200 medfører, at sonden mislykkes. Du kan angive porten (port), URI'en for anmodning om tilstandsstatus fra back end (URI), hvor lang tid der skal gå mellem sondeforsøg (Interval) og antallet af fejl, der skal opstå, for at forekomsten kan anses for at være usund (Usund grænse).

Sessionens persistens

Load Balancer distribuerer som standard netværkstrafik ligeligt mellem flere VM-forekomster. Det giver kun stickiness i en transportsession. Sessionens persistens angiver, hvordan trafik fra en klient skal håndteres. Standardfunktionsmåden (Ingen) er, at en hvilken som helst maskine, der fungerer korrekt, kan håndtere efterfølgende anmodninger fra en klient.

Sessionens persistens kaldes også sessionens tilhørsforhold, kildens IP-tilhørsforhold eller klientens IP-tilhørsforhold. Denne distributionstilstand bruger en totuppel (kilde-IP og destinations-IP) eller tretuppel (kilde-IP, destinations-IP og protokoltype) hash til at dirigere til back end-forekomster. Når du bruger sessionens persistens, går forbindelser fra den samme klient til den samme back end-forekomst i back end-gruppen. Du kan konfigurere en af følgende indstillinger for sessionens persistens:

  • Ingen (standard): Angiver, at en hvilken som helst vm, der fungerer korrekt, kan håndtere anmodningen.
  • klient-IP(2-tuple): Angiver, at den samme back end-forekomst kan håndtere efterfølgende anmodninger fra den samme klient-IP-adresse.
  • klient-IP og protokol (3-tuple): Angiver, at den samme back end-forekomst kan håndtere efterfølgende anmodninger fra den samme klient-IP-adresse og protokolkombination.

Du kan ændre denne funktionsmåde ved at konfigurere en af de indstillinger, der er beskrevet i følgende afsnit.

Porte med høj tilgængelighed

En belastningsjusteringsregel, der er konfigureret med protocol - all and port - 0, kaldes en portregel med høj tilgængelighed. Denne regel gør det muligt for en enkelt regel at justere belastningsjusteringen af alle TCP- og UDP-flow, der modtages på alle porte i en intern standardbelastningsjustering.

Beslutningen om justering af belastning foretages pr. flow. Denne handling er baseret på følgende fem-tupelforbindelse:

  • Kilde-IP-adresse
  • Kildeport
  • Destinations-IP-adresse
  • Destinationsport
  • Protokol

Regler for belastningsjustering af HA-porte hjælper dig med kritiske scenarier, f.eks. høj tilgængelighed og skalering for virtuelle netværksapparater (NVA'er) i virtuelle netværk. Funktionen kan hjælpe, når et stort antal porte skal være belastningsafbalanceret.

diagram, der viser, hvordan porte med høj tilgængelighed fungerer i Azure Load Balancer.

Indgående NAT-regler

Du kan bruge regler for justering af belastning sammen med NAT-regler (Network Address Translation). Du kan f.eks. bruge NAT fra belastningsjusteringens offentlige adresse til TCP 3389 på en bestemt VM. Denne regelkombination giver fjernskrivebordsadgang uden for Azure.

diagram, der viser, hvordan indgående NAT-regler fungerer i Azure Load Balancer.

Udgående regler

En udgående regel konfigurerer SNAT (Source Network Address Translation) for alle VM'er eller forekomster, der er identificeret af back end-gruppen. Denne regel gør det muligt for forekomster i back end at kommunikere (udgående) til internettet eller andre offentlige slutpunkter.

diagram, der viser, hvordan udgående regler fungerer i Azure Load Balancer.