Hi almal! Die kursus begin vandag , in verband waarmee ons 'n ooreenstemmende tematiese webinar gehou het gewy aan die ELB-oorsig. Ons het na die tipes balanseerders gekyk en verskeie EC2-instansies met 'n balanseerder geskep. Ons het ook ander voorbeelde van gebruik bestudeer.
, Jy sal:
- verstaan wat AWS Load Balancing is;
- die tipes Elastiese Load Balancer en sy komponente ken;
- gebruik AWS ELB in jou praktyk.
Hoekom moet jy dit enigsins weet?
- nuttig as jy van plan is om AWS-sertifiseringseksamens af te lê;
- dit is 'n eenvoudige manier om die las tussen bedieners te versprei;
- Dit is 'n eenvoudige manier om Lambda by jou diens (ALB) te voeg.
Het 'n oop les gehou , stelselingenieur by 'n bemarkingsmaatskappy vir webwerf-ontwikkeling en -ondersteuning.
Inleiding
Wat 'n elastiese lasbalanseerder is, kan in die diagram hieronder gesien word, wat 'n eenvoudige voorbeeld toon:
Load Balancer aanvaar versoeke en versprei dit oor gevalle. Ons het een aparte geval, daar is Lambda-funksies en daar is 'n AutoScaling-groep ('n groep bedieners).
AWS ELB Tipes
1. Kom ons kyk na die hooftipes:
Klassieke Load Balancer. Die heel eerste lasbalanseerder van AWS werk op beide OSI Layer 4 en Layer 7, wat HTTP, HTTPS, TCP en SSL ondersteun. Dit bied basiese lasbalansering oor verskeie Amazon EC2-gevalle en werk op beide die versoek- en verbindingsvlakke. Kom ons maak dit oop (in grys uitgelig):
Hierdie balanseerder word as verouderd beskou, daarom word dit slegs in sekere gevalle aanbeveel vir gebruik. Byvoorbeeld, vir toepassings wat op die EC2-Classic-netwerk gebou is. In beginsel keer niemand ons om dit te skep nie:
2. Netwerk Load Balancer. Geskik vir swaar werkladings, werk op OSI Layer 4 (kan in EKS en ECS gebruik word), TCP, UDP en TLS word ondersteun.
Network Load Balancer lei verkeer na teikens in 'n Amazon VPC en is in staat om miljoene versoeke per sekonde te verwerk met ultra-lae latency. Boonop is dit geoptimaliseer om verkeerspatrone met skielike en veranderende vragte te hanteer.
3. Toepassing Load Balancer. Werk by laag 7, het Lambda-ondersteuning, ondersteun kop- en padvlakreëls, ondersteun HTTP en HTTPS.
Verskaf gevorderde versoekroetering gefokus op die lewering van toepassings wat gebou is op moderne argitekture, insluitend mikrodienste en houers. Lei verkeer na teikens in Amazon VPC gebaseer op die inhoud van die versoek.
Vir baie gebruikers was Application Load Balancer die eerste keuse om Classic Load Balancer te vervang, want TCP is nie so algemeen soos HTTP nie.
Kom ons skep dit ook, as gevolg hiervan sal ons reeds twee lasbalanseerders hê:
Laaibalanskomponente
Algemene lasbalanskomponente (algemeen vir alle balanseerders):
- Toegang logboekbeleid
- jou ELB toegang logs. Om instellings te maak, kan jy na Beskrywing gaan en die "Redigeer eienskappe"-knoppie kies:
Dan spesifiseer ons S3Bucket - Amazon objekberging:
- skema
— interne of eksterne balanseerder. Die punt is of jou LoadBalancer eksterne adresse moet ontvang om van buite toeganklik te wees, of kan dit jou interne load balancer wees;
- Veiligheidsgroepe
— toegangsbeheer tot die balanseerder. In wese is dit 'n hoëvlak firewall.
- subnets
- subnette binne jou VPC (en, dienooreenkomstig, beskikbaarheidsone). Subnette word tydens skepping gespesifiseer. As VPC's beperk word deur streek, dan word subnetwerke beperk deur beskikbaarheidsones. Wanneer 'n Load Balancer geskep word, is dit beter om dit in ten minste twee subnette te skep (help as probleme opduik met een Beskikbaarheidsone);
- luisteraars
- jou balanseerder protokolle. Soos vroeër genoem, kan dit vir Classic Load Balancer HTTP, HTTPS, TCP en SSL wees, vir Network Load Balancer - TCP, UDP en TLS, vir Application Load Balancer - HTTP en HTTPS.
Voorbeeld vir Classic Load Balancer:
Maar in die Application Load Balancer sien ons 'n effens ander koppelvlak en oor die algemeen verskillende logika:
Load Balancer v2-komponente (ALB en NLB)
Kom ons kyk nou van naderby na weergawe 2-balanseerders Application Load Balancer en Network Load Balancer. Hierdie balanseerders het hul eie komponentkenmerke. So 'n konsep soos Teikengroepe het byvoorbeeld verskyn - gevalle (en funksies). Danksy hierdie komponent het ons die geleentheid om te spesifiseer na watter van die teikengroepe ons verkeer wil rig.
In eenvoudige terme, in Teikengroepe spesifiseer ons die gevalle waar die verkeer sal kom. As jy in dieselfde Classic Load Balancer eenvoudig dadelik die intensiteit aan die balancer koppel, dan moet jy eers in die Application Load Balancer:
- skep 'n Load Balancer;
- skep 'n teikengroep;
- rig via die vereiste poorte of Load Balancer-reëls na die vereiste Teikengroepe;
- in Teikengroepe ken jy gevalle toe.
Hierdie bedryfslogika lyk dalk meer ingewikkeld, maar in werklikheid is dit geriefliker.
Die volgende komponent is Luisterreëls (reëls vir roetering). Dit is slegs van toepassing op Application Load Balancer. As jy in Network Load Balancer eenvoudig 'n Luisteraar skep, en dit stuur verkeer na 'n spesifieke teikengroep, dan is alles in Application Load Balancer .
Kom ons sê nou 'n paar woorde oor die volgende komponent - Elastiese IP (statiese adresse vir NLB). As die Luisteraarreëls-roeteringreëls slegs die Toepassingslasbalanseerder beïnvloed het, het Elastic IP slegs die Netwerklasbalanseerder beïnvloed.
Kom ons skep 'n Network Load Balancer:
En net tydens die skeppingsproses sal ons sien dat ons die geleentheid kry om Elastic IP te kies:
Elastiese IP verskaf 'n enkele IP-adres wat met verloop van tyd met verskillende EC2-gevalle geassosieer kan word. As 'n EC2-instansie 'n Elastic IP-adres het en daardie instansie word beëindig of gestop, kan jy onmiddellik 'n nuwe EC2-instansie met 'n Elastic IP-adres assosieer. Jou huidige toepassing sal egter nie ophou werk nie, aangesien toepassings steeds dieselfde IP-adres sien, selfs al het die regte EC2 verander.
Hier oor die onderwerp waarom Elastic IP nodig is. Kyk, ons sien 3 IP-adresse, maar hulle sal nie vir ewig hier bly nie:
Amazon verander hulle met verloop van tyd, miskien elke 60 sekondes (maar in die praktyk, natuurlik, minder gereeld). Dit beteken dat IP-adresse kan verander. En in die geval van Network Load Balancer, kan jy net 'n IP-adres bind en dit in jou reëls, beleide, ens.
Maak gevolgtrekkings
ELB verskaf outomatiese verspreiding van inkomende verkeer oor verskeie teikens (houers, Amazon EC2-gevalle, IP-adresse en Lambda-funksies). ELB is in staat om verkeer met verskillende vragte te versprei binne 'n enkele beskikbaarheidsone en oor verskeie beskikbaarheidsones. Die gebruiker kan kies uit drie soorte balanseerders wat hoë beskikbaarheid, outoskaling en goeie beskerming bied. Dit alles is belangrik om die fouttoleransie van u toepassings te verseker.
Die belangrikste voordele:
- hoë beskikbaarheid. Die diensooreenkoms veronderstel 99,99% beskikbaarheid vir die lasbalanseerder. Byvoorbeeld, verskeie beskikbaarheidsones verseker dat verkeer slegs deur gesonde voorwerpe verwerk word. Trouens, jy kan die las oor die hele streek balanseer, deur verkeer na gesonde teikens in verskillende beskikbaarheidsones te herlei;
- veiligheid. ELB werk saam met Amazon VPC, wat verskeie sekuriteitsvermoëns bied - geïntegreerde sertifikaatbestuur, gebruikersverifikasie en SSL/TLS-dekripsie. Almal bied gesentraliseerde en buigsame bestuur van TLS-instellings;
- elastisiteit. Die ELB kan skielike veranderinge in netwerkverkeer hanteer. En diep integrasie met Auto Scaling gee die toepassing genoeg hulpbronne as die vrag verander, sonder dat handmatige ingryping nodig is;
- buigsaamheid. Jy kan IP-adresse gebruik om versoeke na die teikens van jou toepassings te stuur. Dit bied buigsaamheid wanneer teikentoepassings gevirtualiseer word, en gee dus die vermoë om verskeie toepassings op 'n enkele instansie te huisves. Aangesien toepassings 'n enkele netwerkpoort kan gebruik en afsonderlike sekuriteitsgroepe kan hê, word kommunikasie tussen toepassings vereenvoudig wanneer ons byvoorbeeld 'n mikrodiens-gebaseerde argitektuur het;
- monitering en oudit. U kan toepassings intyds monitor deur Amazon CloudWatch-kenmerke te gebruik. Ons praat oor statistieke, logs, versoekopsporing. In eenvoudige terme sal jy in staat wees om probleme te identifiseer en prestasie-knelpunte redelik akkuraat te identifiseer;
- hibriede vragbalansering. Die vermoë om balans te laai tussen hulpbronne op die perseel en AWS deur dieselfde lasbalanseerder te gebruik, maak dit maklik om toepassings op die perseel na die wolk te migreer of uit te brei. Fouthantering word ook vereenvoudig deur die wolk te gebruik.
As jy belangstel in besonderhede, hier is nog 'n paar nuttige skakels vanaf die amptelike Amazon-webwerf:
- .
Bron: will.com