Dag Allemaal! De cursus begint vandaag , in verband waarmee we een overeenkomstig thematisch webinar hielden gewijd aan de ELB-review. We hebben gekeken naar de soorten balancers en hebben verschillende EC2-instances gemaakt met een balancer. We hebben ook andere gebruiksvoorbeelden bestudeerd.
, Je zal:
- begrijpen wat AWS Load Balancing is;
- ken de soorten Elastic Load Balancer en zijn componenten;
- gebruik AWS ELB in uw praktijk.
Waarom moet je dit überhaupt weten?
- handig als u van plan bent AWS-certificeringsexamens af te leggen;
- dit is een eenvoudige manier om de belasting tussen servers te verdelen;
- Dit is een eenvoudige manier om Lambda aan uw service (ALB) toe te voegen.
Een open les gegeven , systeemingenieur bij een marketingbedrijf voor websiteontwikkeling en -ondersteuning.
Introductie
Wat een Elastic Load Balancer is, kun je zien in onderstaand schema, waarin een eenvoudig voorbeeld te zien is:
Load Balancer accepteert verzoeken en distribueert deze over instanties. We hebben één aparte instance, er zijn Lambda-functies en er is een AutoScaling-groep (een groep servers).
AWS ELB-typen
1. Laten we eens kijken naar de belangrijkste typen:
Klassieke load-balancer. De allereerste load balancer van AWS werkt op zowel OSI Layer 4 als Layer 7 en ondersteunt HTTP, HTTPS, TCP en SSL. Het biedt basisbelastingverdeling over meerdere Amazon EC2-instanties en werkt op zowel verzoek- als verbindingsniveau. Laten we het openen (grijs gemarkeerd):
Deze balancer wordt als verouderd beschouwd en wordt daarom alleen in bepaalde gevallen aanbevolen. Bijvoorbeeld voor applicaties die op het EC2‑Classic netwerk zijn gebouwd. In principe houdt niemand ons tegen om het te creëren:
2. Netwerkloadbalancer. Geschikt voor zware werklasten, werkt op OSI Layer 4 (kan worden gebruikt in EKS en ECS), TCP, UDP en TLS worden ondersteund.
Network Load Balancer routeert verkeer naar doelen in een Amazon VPC en kan miljoenen verzoeken per seconde verwerken met ultralage latentie. Bovendien is het geoptimaliseerd voor verkeerspatronen met plotselinge en wisselende belastingen.
3. Applicatieloadbalancer. Werkt op laag 7, heeft Lambda-ondersteuning, ondersteunt regels op header- en padniveau, ondersteunt HTTP en HTTPS.
Biedt geavanceerde verzoekroutering gericht op het leveren van applicaties die zijn gebouwd op moderne architecturen, inclusief microservices en containers. Leidt verkeer naar doelen in Amazon VPC op basis van de inhoud van het verzoek.
Voor veel gebruikers was Application Load Balancer de eerste keuze om de klassieke Load Balancer te vervangen, omdat TCP niet zo gebruikelijk is als HTTP.
Laten we het ook maken, waardoor we al twee load balancers hebben:
Componenten voor belastingsbalans
Gemeenschappelijke Load Balance-componenten (gemeenschappelijk voor alle balancers):
- Toegang tot logboekbeleid
— uw ELB-toegangslogboeken. Om instellingen te maken, kunt u naar Beschrijving gaan en de knop “Attributen bewerken” selecteren:
Vervolgens specificeren we S3Bucket - Amazon-objectopslag:
- schema
— interne of externe balancer. Het punt is of uw LoadBalancer externe adressen moet ontvangen om van buitenaf toegankelijk te zijn, of dat het uw interne load balancer kan zijn;
- Beveiligingsgroepen
— toegangscontrole tot de balancer. In wezen is dit een firewall op hoog niveau.
- subnetten
— subnetten binnen uw VPC (en dienovereenkomstig de beschikbaarheidszone). Subnetten worden opgegeven tijdens het maken. Als VPC's beperkt zijn per regio, worden subnetten beperkt door beschikbaarheidszones. Bij het maken van een Load Balancer is het beter om deze in ten minste twee subnetten te maken (helpt als er problemen optreden met één Beschikbaarheidszone);
- luisteraars
— uw balancerprotocollen. Zoals eerder vermeld, kan dit voor Classic Load Balancer HTTP, HTTPS, TCP en SSL zijn, voor Network Load Balancer - TCP, UDP en TLS, voor Application Load Balancer - HTTP en HTTPS.
Voorbeeld voor klassieke Load Balancer:
Maar in de Application Load Balancer zien we een iets andere interface en over het algemeen andere logica:
Load Balancer v2-componenten (ALB en NLB)
Laten we nu versie 2-balancers Application Load Balancer en Network Load Balancer eens nader bekijken. Deze balancers hebben hun eigen componentkenmerken. Er verscheen bijvoorbeeld een concept als Doelgroepen - instanties (en functies). Dankzij dit onderdeel hebben we de mogelijkheid om te specificeren naar welke doelgroep we verkeer willen sturen.
Simpel gezegd specificeren we in Doelgroepen de gevallen waar verkeer zal komen. Als je in dezelfde Classic Load Balancer simpelweg direct de intensiteit aan de balancer koppelt, dan doe je in de Application Load Balancer eerst:
- maak een Load Balancer;
- maak een doelgroep aan;
- direct via de benodigde poorten of Load Balancer-regels naar de gewenste Doelgroepen;
- in Doelgroepen wijst u instanties toe.
Deze bedieningslogica lijkt misschien ingewikkelder, maar is in feite handiger.
Het volgende onderdeel is Luisteraar regels (regels voor routering). Dit geldt alleen voor Application Load Balancer. Als u in Network Load Balancer eenvoudigweg een Listener maakt en deze verkeer naar een specifieke doelgroep stuurt, dan is in Application Load Balancer alles .
Laten we nu een paar woorden zeggen over het volgende onderdeel: Elastisch IP (statische adressen voor NLB). Als de routeringsregels van de Listener-regels alleen van invloed waren op de Application Load Balancer, had Elastic IP alleen invloed op de Network Load Balancer.
Laten we een Network Load Balancer maken:
En net tijdens het creatieproces zullen we zien dat we de mogelijkheid krijgen om Elastic IP te selecteren:
Elastic IP biedt één IP-adres dat in de loop van de tijd aan verschillende EC2-instanties kan worden gekoppeld. Als een EC2-exemplaar een elastisch IP-adres heeft en dat exemplaar wordt beëindigd of gestopt, kunt u onmiddellijk een nieuw EC2-exemplaar aan een elastisch IP-adres koppelen. Uw huidige applicatie stopt echter niet met werken, aangezien applicaties nog steeds hetzelfde IP-adres zien, zelfs als de echte EC2 is gewijzigd.
Hier over het onderwerp waarom Elastic IP nodig is. Kijk, we zien 3 IP-adressen, maar ze zullen niet voor altijd hier blijven:
Amazon verandert ze in de loop van de tijd, misschien elke 60 seconden (maar in de praktijk natuurlijk minder vaak). Dit betekent dat IP-adressen kunnen veranderen. En in het geval van Network Load Balancer kunt u gewoon een IP-adres binden en dit aangeven in uw regels, beleid, enz.
Trek conclusies
ELB biedt automatische distributie van inkomend verkeer over meerdere doelen (containers, Amazon EC2-instanties, IP-adressen en Lambda-functies). ELB is in staat verkeer met variërende belastingen te distribueren, zowel binnen een enkele Beschikbaarheidszone als over meerdere Beschikbaarheidszones. De gebruiker kan kiezen uit drie soorten balancers die hoge beschikbaarheid, autoscaling en goede bescherming bieden. Dit alles is belangrijk om de fouttolerantie van uw applicaties te garanderen.
De belangrijkste voordelen:
- hoge beschikbaarheid. De serviceovereenkomst gaat uit van een beschikbaarheid van 99,99% voor de load balancer. Meerdere Beschikbaarheidszones zorgen er bijvoorbeeld voor dat verkeer alleen door gezonde objecten wordt verwerkt. In feite kunt u de belasting over de hele regio verdelen, waardoor verkeer wordt omgeleid naar gezonde doelen in verschillende beschikbaarheidszones;
- veiligheid. ELB werkt met Amazon VPC en biedt verschillende beveiligingsmogelijkheden: geïntegreerd certificaatbeheer, gebruikersauthenticatie en SSL/TLS-decodering. Alles bij elkaar zorgt dit voor gecentraliseerd en flexibel beheer van TLS-instellingen;
- elasticiteit. De ELB kan plotselinge veranderingen in het netwerkverkeer opvangen. En de diepgaande integratie met Auto Scaling geeft de applicatie voldoende middelen als de belasting verandert, zonder dat handmatige tussenkomst nodig is;
- flexibiliteit. U kunt IP-adressen gebruiken om verzoeken naar de doelen van uw toepassingen te routeren. Dit biedt flexibiliteit bij het virtualiseren van doelapplicaties, waardoor de mogelijkheid wordt geboden om meerdere applicaties op één exemplaar te hosten. Omdat applicaties één enkele netwerkpoort kunnen gebruiken en aparte beveiligingsgroepen hebben, wordt de communicatie tussen applicaties vereenvoudigd als we bijvoorbeeld een op microservices gebaseerde architectuur hebben;
- monitoring en audit. U kunt applicaties in realtime volgen met behulp van Amazon CloudWatch-functies. We hebben het over statistieken, logs en het volgen van verzoeken. In eenvoudige bewoordingen kunt u problemen en knelpunten in de prestaties vrij nauwkeurig identificeren;
- hybride loadbalancing. De mogelijkheid om de belasting tussen on-premises bronnen en AWS te verdelen met behulp van dezelfde load balancer, maakt het eenvoudig om on-premises applicaties naar de cloud te migreren of uit te breiden. Ook de afhandeling van storingen wordt vereenvoudigd dankzij de cloud.
Als je geïnteresseerd bent in details, zijn hier nog een paar nuttige links van de officiële Amazon-website:
- .
Bron: www.habr.com