Wanneer u uw vRealize Automation-cloudsjablonen maakt of bewerkt, gebruikt u de meest geschikte load balancer-resources voor uw doelstellingen.
U kunt NSX- en cloudonafhankelijke load balancer-resources in een cloudsjabloon gebruiken om load balancing in een implementatie te beheren.
De cloudonafhankelijke load balancer kan in meerdere clouds worden geïmplementeerd. Een cloudspecifieke load balancer kan geavanceerde instellingen en functies opgeven die alleen beschikbaar zijn voor een specifieke cloud/topologie. Cloudspecifieke eigenschappen zijn beschikbaar in het resourcetype NSX load balancer (Cloud.NSX.LoadBalancer). Als u deze eigenschappen toevoegt op een cloudonafhankelijke load balancer (Cloud.LoadBalancer) worden deze genegeerd als bijvoorbeeld een load balancer van Amazon Web Services of Microsoft Azure is ingericht, maar worden deze gerespecteerd als een load balancer van NSX-V of NSX-T is ingericht. Kies een van de beschikbare resourcetypen voor load balancers op basis van voorwaarden in uw vRealize Automation-cloudsjabloon.
U kunt een load-balancerresource niet rechtstreeks verbinden met een beveiligingsgroepresource in het ontwerpcanvas.
Cloudonafhankelijke load-balancerresource
Gebruik een cloudonafhankelijke load balancer wanneer u netwerkeigenschappen wilt opgeven voor elk type doelmachine.
Cloud.LoadBalancer
-resourcetype. De standaardresource wordt weergegeven als:
Cloud_LoadBalancer_1:
type: Cloud.LoadBalancer
properties:
routes: []
network: ''
instances: []
internetFacing: false
NSX-load-balancerresource
Gebruik een load balancer van NSX wanneer de cloudsjabloon kenmerken bevat die specifiek zijn voor NSX-V of NSX-T (Beleids-API- of Manager-API-methoden). U kunt een of meer load balancers koppelen aan een NSX-V- of NSX-T-netwerk of aan machines die zijn gekoppeld aan een NSX-V- of NSX-T-netwerk.
Cloud.NSX.LoadBalancer
-resourcetype. De standaardresource wordt weergegeven als:
Cloud_NSX_LoadBalancer_1:
type: Cloud.NSX.LoadBalancer
properties:
routes: []
network: ''
instances: []
Opties voor load balancer in cloudsjablooncode
Door een of meer load balancer-resources toe te voegen aan uw cloudsjabloon kunt u de volgende instellingen opgeven. Er zijn enkele voorbeelden beschikbaar op Netwerken, beveiligingsgroepen en load balancers in vRealize Automation.
Het HTTP-protocol wordt ondersteund voor alle load balancers op aanvraag.
Het HTTPS-protocol wordt alleen ondersteund voor load balancers op aanvraag die zijn gekoppeld aan een NSX-T-cloudaccount waarvan de NSX-modus is ingesteld op Beleid. NSX-T-cloudaccounts waarvan de NSX-modus is ingesteld op Manager kan het HTTPS-protocol niet gebruiken.
- Machinespecificatie
U kunt benoemde machineresources opgeven om deel te nemen aan een load balancing-pool. U kunt ook opgeven dat een specifieke machine-NIC deel uitmaakt van de load-balancerpool.
Deze optie is alleen beschikbaar voor de NSX load balancer-resource (
Cloud.NSX.LoadBalancer
).- resource.Cloud_Machine_1.id
Hiermee geeft u op dat de load balancer de machine bevat die in de cloudsjablooncode is geïdentificeerd als Cloud_Machine_1.
- resource.Cloud_Machine_2.networks[2].id
Hiermee geeft u op dat de load balancer alleen de machine bevat die in de cloudsjablooncode is gedefinieerd als Cloud_Machine_2 wanneer deze wordt geïmplementeerd op machine-NIC Cloud_Machine_2.networks[2].
- resource.Cloud_Machine_1.id
- Logboekregistratieniveau
De waarde van het registratieniveau bepaalt een ernstniveau voor het foutenlogboek. De opties zijn NONE, EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, INFO, DEBUG en NOTICE. De waarde van het logboekregistratieniveau is van toepassing op alle load balancers in de cloudsjabloon. Deze optie is specifiek voor NSX. Voor load balancers die een bovenliggende load balancer hebben, overschrijft de instelling van het bovenliggende logboekregistratieniveau alle instellingen voor logboekregistratieniveau in de onderliggende load balancers.
Raadpleeg onderwerpen zoals Load balancers toevoegen in de productdocumentatie voor NSX voor gerelateerde informatie.
- Type
Gebruik een load balancer-type om een schaalgrootte op te geven. De standaardwaarde is klein. Deze optie is specifiek voor NSX. Voor load balancers die een bovenliggende load balancer hebben, overschrijft de instelling van het bovenliggende type elke instelling voor type in de onderliggende load balancers.
- Klein
Komt overeen met compact in NSX-V en klein in NSX-T.
- Normaal
Komt overeen met groot in NSX-V en normaal in NSX-T.
- Groot
Komt overeen met quad-groot in NSX-V en groot in NSX-T.
- Extra groot
Komt overeen met extra groot in NSX-V en groot in NSX-T.
Raadpleeg voor gerelateerde informatie onderwerpen zoals Resources voor het schalen van load balancers in de productdocumentatie voor NSX.
Deze optie is alleen beschikbaar voor de NSX-load-balancerresource (
Cloud.NSX.LoadBalancer
). - Klein
- Algoritme (serverpool)
Gebruik een algoritmische methode voor de verdeling om te bepalen hoe binnenkomende verbindingen worden verdeeld over de leden van de serverpool. Het algoritme kan worden gebruikt op een serverpool of rechtstreeks op een server. Alle load balancing-algoritmen slaan servers over die aan een van de volgende voorwaarden voldoen:
- De status Beheerder is ingesteld op UITGESCHAKELD.
- De status Beheerder is ingesteld op GRACEFUL_DISABLED en er is geen overeenkomende persistentie-invoer.
- De status actieve of passieve gezondheidscontrole is INACTIEF.
- De verbindingslimiet voor het maximum aantal gelijktijdige verbindingen van de serverpool is bereikt.
Deze optie is specifiek voor NSX.
- IP_HASH
Selecteert een server op basis van een hash van het oorspronkelijke IP-adres en het totale gewicht van alle actieve servers.
Komt overeen met IP-HASH in NSX-V en NSX-T.
- LEAST_CONNECTION
Hiermee worden clientaanvragen naar meerdere servers gedistribueerd op basis van het aantal bestaande verbindingen op de server. Nieuwe verbindingen worden verzonden naar de server met het minste aantal verbindingen. De gewichtswaarden van de serverpoolonderdelen worden genegeerd, ook als ze zijn geconfigureerd.
Komt overeen met LEASTCONN in NSX-V en LEAST_CONNECTION in NSX-T.
- ROUND_ROBIN
Binnenkomende clientaanvragen doorlopen een lijst met beschikbare servers die de aanvraag kunnen afhandelen. Negeert het gewicht van serverpoolleden, zelfs als dit geconfigureerd is. Standaard.
Komt overeen met ROUND_ROBIN in NSX-V en NSX-T.
- WEIGHTED_LEAST_CONNECTION
Aan elke server wordt een gewichtswaarde toegewezen die aangeeft hoe die server presteert ten opzichte van andere servers in de pool. De waarde bepaalt hoeveel clientaanvragen naar een server worden verzonden in vergelijking met andere servers in de pool. Dit algoritme voor load balancing focust op het gebruik van de gewichtswaarde voor een gelijke verdeling van de taken tussen de beschikbare serverresources. De gewichtswaarde is standaard 1 als de waarde niet is geconfigureerd en langzame start is ingeschakeld.
Komt overeen met WEIGHTED_LEAST_CONNECTION in NSX-T. Er is geen correlatie in NSX-V.
- WEIGHTED_ROUND_ROBIN
Aan elke server wordt een gewichtswaarde toegewezen die aangeeft hoe die server presteert ten opzichte van andere servers in de pool. De waarde bepaalt hoeveel clientaanvragen naar een server worden verzonden in vergelijking met andere servers in de pool. Dit algoritme voor load balancing focust op de gelijke verdeling van de werklast tussen de beschikbare serverresources.
Komt overeen met WEIGHTED_ROUND_ROBIN in NSX-T. Er is geen correlatie in NSX-V.
- URI
Het linkergedeelte van de URI wordt gehasht en gedeeld door het totale gewicht van de actieve servers. Het resultaat bepaalt welke server de aanvraag ontvangt. Dit zorgt ervoor dat een URI altijd wordt doorverwezen naar dezelfde server zolang er geen servers actief of inactief worden. De URI-algoritmeparameter heeft twee opties:
uriLength=<len>
enuriDepth=<dep>
. Het lengteparameterbereik moet1<=len<256
zijn. Het diepteparameterbereik moet1<=dep<10
zijn. Lengte- en diepteparameters worden gevolgd door een positief geheel getal. Deze opties kunnen taken alleen over servers verdelen op basis van het begin van de URI. De lengteparameter geeft aan dat het algoritme alleen rekening moet houden met de gedefinieerde tekens aan het begin van de URI om de hash te berekenen. De diepteparameter geeft de maximumdirectorydiepte aan die moet worden gebruikt om de hash te berekenen. Voor elke slash in de aanvraag wordt één niveau geteld. Als beide parameters zijn opgegeven, stopt de evaluatie wanneer een van de parameters is bereikt.Komt overeen met URI in NSX-V. Er is geen correlatie in NSX-T.
- HTTPHEADER
De naam van de HTTP-koptekst wordt opgezocht in elke HTTP-aanvraag. De naam van de koptekst tussen haakjes is niet hoofdlettergevoelig. Als de koptekst afwezig is of geen waarde bevat, wordt het round-robin-algoritme toegepast. De algoritmeparameter HTTPHEADER heeft één optie:
headerName=<name>
.Komt overeen met HTTPHEADER in NSX-V. Er is geen correlatie in NSX-T.
- URL
De URL-parameter die is opgegeven in het argument, wordt opgezocht in de querytekenreeks van elke HTTP GET-aanvraag. Als de parameter wordt gevolgd door een gelijkteken = en een waarde, wordt de waarde gehasht en gedeeld door het totale gewicht van de actieve servers. Het resultaat bepaalt welke server de aanvraag ontvangt. Dit proces wordt gebruikt om gebruikers-id's in aanvragen te volgen en om ervoor te zorgen dat eenzelfde gebruikers-id altijd naar dezelfde server wordt verzonden zolang er geen servers actief of inactief worden. Als geen waarde of parameter wordt gevonden, wordt het round-robin-algoritme toegepast. De URL-algoritmeparameter heeft één optie:
urlParam=<url>
.Komt overeen met URL in NSX-V. Er is geen correlatie in NSX-T.
Raadpleeg onderwerpen zoals Een serverpool toevoegen voor load balancing in de NSX-productdocumentatie voor gerelateerde informatie.
- Statusmonitor
Gebruik de opties van de statusmonitor om te testen of een server beschikbaar is. Actieve statusmonitor voor HTTP-, ICMP-, TCP- en UDP-protocollen wordt ondersteund. Passieve statusmonitor is alleen beschikbaar voor NSX-T.
Deze optie is specifiek voor NSX.
- httpMethod
HTTP-methode die wordt gebruikt om de serverstatus voor de gezondheidscontroleaanvraag te detecteren. Methoden zijn GET, HOST, OPTIONS, HEAD of PUT.
- requestBody
Gezondheidscontrole van de inhoud van de aanvraagtekst. Gebruikt, en vereist, door HTTP-, TCP- en UDP-protocollen.
- responseBody
Gezondheidscontrole van de inhoud van de verwachte reactietekst. Als de ontvangen tekenreeks overeenkomt met deze reactietekst, wordt de server als gezond beschouwd. Gebruikt, en vereist, door HTTP-, TCP- en UDP-protocollen.
Opmerking: Als u het UDP-monitorprotocol gebruikt, zijn de parametersUDP Data Sent
enUDP Data Expected
vereist. De eigenschappenrequestBody
enresponseBody
worden aan deze parameters toegewezen.Deze optie is beschikbaar voor de NSX-load-balancerresource (
Cloud.NSX.LoadBalancer
).Raadpleeg onderwerpen zoals Een actieve statusmonitor configureren in de productdocumentatie voor NSX voor gerelateerde informatie.
- httpMethod
- Gezondheidscontrole
Gebruik de opties van de gezondheidscontrole om op te geven hoe de load balancer de gezondheidscontroles uitvoert.
Deze optie is alleen beschikbaar voor de NSX-load-balancerresource (
Cloud.NSX.LoadBalancer
).Zie Netwerken, beveiligingsgroepen en load balancers in vRealize Automation voor een voorbeeld van de beschikbare gezondheidscontrole-instellingen.
NSX-V- en NSX-T-netwerktypen en load-balanceropties
De opties voor load balancers zijn afhankelijk van het netwerk waaraan de load balancer-resource in de cloudsjabloon is gekoppeld. U kunt een load balancer configureren ten opzichte van het netwerktype en netwerkomstandigheden.
- Netwerk op aanvraag
Als de load-balancerberekeningen aan een netwerk op aanvraag zijn gekoppeld, wordt een nieuwe laag-1-router gemaakt en gekoppeld aan de laag-0-router die in het netwerkprofiel is opgegeven. De load balancer wordt vervolgens aan de laag-1-router gekoppeld. De VIP-advertentie voor de laag-1-router wordt ingeschakeld als het VIP zich in een bestaand netwerk bevindt. Als een netwerk is geconfigureerd voor DHCP, delen het netwerk op aanvraag en de load balancer de laag-1-router.
- Bestaand netwerk
Als de load balancer aan een bestaand netwerk is gekoppeld, wordt de load balancer gemaakt met de laag-1-router van het bestaande netwerk. Er wordt een nieuwe load balancer gemaakt als er geen load balancer aan de laag-1-router is gekoppeld. Als de load balancer al bestaat, worden er nieuwe virtuele servers aan gekoppeld. Als het bestaande netwerk niet aan een laag-1-router is gekoppeld, wordt een nieuwe laag-1-router gemaakt en gekoppeld aan een laag-0-router die in het netwerkprofiel is gedefinieerd. De VIP-advertentie voor de laag-1-router is niet ingeschakeld.
vRealize Automation biedt geen ondersteuning voor NSX-T twee-armige load balancer (inline load balancer) op twee verschillende bestaande netwerken. Houd er rekening mee dat de VIP-uplink zich in een scenario met een twee-armige load balancer op een bestaand netwerk bevindt terwijl de machines die lid zijn van de pool, verbonden zijn met een netwerk op aanvraag. Als u load balancing wilt opgeven wanneer u een bestaand netwerk gebruikt, moet u een éénarmige load balancer configureren waarin hetzelfde bestaande netwerk wordt gebruikt voor de load-balancer-VIP en de machines die lid zijn van de pool. Als u echter een load balancer gebruikt die u in het netwerkprofiel heeft geselecteerd, kunt u vanaf vRealize Automation 8.4.2 de load balancer tussen machines op twee verschillende bestaande netwerken instellen als er verbinding tussen de twee bestaande netwerken is.
- Netwerkisolatie gedefinieerd in het netwerkprofiel
Voor netwerktypen van
outbound
ofprivate
kunt u netwerkisolatie-instellingen opgeven in een netwerkprofiel om een nieuwe beveiligingsgroep te emuleren. Omdat machines aan een bestaand netwerk worden gekoppeld en isolatie-instellingen in het profiel worden gedefinieerd, is deze optie vergelijkbaar met een load balancer die is gemaakt in een bestaand netwerk. Het verschil is dat het IP-adres van de laag-1-uplinkpoort aan de beveiligingsgroep van de isolatie wordt toegevoegd, om het gegevenspad in te schakelen.
U kunt instellingen voor load balancers opgeven voor NSX-gerelateerde netwerken door gebruik te maken van een NSX-load balancer-resource in het cloudsjabloonontwerp.
Zie het VMware-blogbericht vRA Cloud Assembly Load Balancer with NSX-T Deep Dive voor meer informatie.
Persistentie van load-balancerprofiel van NSX-T
Instellingen voor logboekregistratieniveau of -type opnieuw configureren wanneer meerdere load balancers een NSX-T Laag 1 of NSX-V Edge delen
Wanneer u een cloudsjabloon gebruikt die meerdere load balancers bevat die een laag-1-router delen in het NSX-T-eindpunt of een Edge-router in het NSX-V-eindpunt, worden de instellingen voor de andere load balancers niet bijgewerkt door het opnieuw configureren van de instellingen voor het logboekregistratieniveau of -type. Onjuiste instellingen leiden tot inconsistenties in NSX. Om inconsistenties te voorkomen bij het opnieuw configureren van deze instellingen voor logboekregistratieniveau en/of -type, gebruikt u dezelfde herconfiguratiewaarden voor alle load-balancerresources in de cloudsjabloon die een laag 1 of Edge in het gekoppelde NSX-eindpunt delen.
Beschikbare bewerkingen voor dag 2
Wanneer u een implementatie met een load balancer in- of uitschaalt, wordt de load balancer geconfigureerd om de recent toegevoegde machines op te nemen of om de machines voor taakverdeling te stoppen die in aanmerking komen voor ontkoppeling.
Zie Welke acties kan ik op Cloud Assembly-implementaties uitvoeren voor een lijst met veelgebruikte bewerkingen voor dag 2 die beschikbaar zijn voor cloudsjablonen en implementaties.
Meer informatie
Zie Meer informatie over netwerkprofielen in vRealize Automation voor informatie over het definiëren van load-balancerinstellingen in een netwerkprofiel.
Zie Netwerken, beveiligingsgroepen en load balancers in vRealize Automation voor voorbeelden van cloudsjabloonontwerpen die load balancers bevatten.