Saluton al ĉiuj! La kurso komenciĝas hodiaŭ , lige kun kiu ni okazigis respondan teman retseminarion dediĉitan al la ELB-recenzo. Ni rigardis la specojn de balanciloj kaj kreis plurajn EC2-instancojn per balancilo. Ni ankaŭ studis aliajn ekzemplojn de uzo.
, Vi faros:
- kompreni kio estas AWS Load Balancing;
- koni la tipojn de Elastic Load Balancer kaj ĝiaj komponantoj;
- uzu AWS ELB en via praktiko.
Kial vi entute bezonas scii ĉi tion?
- utila se vi planas fari ekzamenojn pri atestado de AWS;
- ĉi tio estas simpla maniero distribui la ŝarĝon inter serviloj;
- Ĉi tio estas simpla maniero aldoni Lambda al via servo (ALB).
Faris malferman lecionon , Sisteminĝeniero ĉe merkatika firmao por reteja disvolviĝo kaj subteno.
Enkonduko
Kio estas Elasta Ŝarĝbalancilo, videblas en la suba diagramo, kiu montras simplan ekzemplon:
Load Balancer akceptas petojn kaj distribuas ilin tra okazoj. Ni havas unu apartan ekzemplon, ekzistas Lambda-funkcioj kaj ekzistas AutoScaling-grupo (grupo de serviloj).
AWS ELB-Tipoj
1. Ni rigardu la ĉefajn tipojn:
Klasika Ŝarĝbalancilo. La unua ekvilibristo de AWS, funkcias sur ambaŭ OSI-tavoloj 4 kaj 7, HTTP, HTTPS, TCP kaj SSL estas subtenataj. Ĝi provizas bazan ŝarĝan ekvilibron tra pluraj Amazon EC2-instancoj kaj funkcias ambaŭ ĉe la peto kaj konektniveloj. Ni malfermu ĝin (markita en griza):
Ĉi tiu balancilo estas konsiderata malmoderna, do ĝi rekomendas uzi nur en iuj kazoj. Ekzemple, por aplikoj kiuj estis konstruitaj sur la EC2-Classic-reto. Principe neniu malhelpas nin krei ĝin:
2. Network Load Balancer. Taŭga por pezaj laborŝarĝoj, funkcias ĉe OSI-Tavolo 4 (povas esti uzata en EKS kaj ECS), TCP, UDP kaj TLS estas subtenataj.
Network Load Balancer direktas trafikon al celoj en Amazon VPC kaj kapablas prilabori milionojn da petoj sekundo kun tre malalta latenco. Aldone, ĝi estas optimumigita por trakti trafikajn ŝablonojn kun subitaj kaj ŝanĝiĝantaj ŝarĝoj.
3. Apliko Load Balancer. Funkcias ĉe tavolo 7, havas Lambda-subtenon, subtenas titolajn kaj padnivelajn regulojn, subtenas HTTP kaj HTTPS.
Provizas altnivelan peton-vojigo koncentrita al liverado de aplikaĵoj konstruitaj sur modernaj arkitekturoj, inkluzive de mikroservoj kaj ujoj. Direktas trafikon al celoj en Amazon VPC surbaze de la enhavo de la peto.
Por multaj uzantoj, Application Load Balancer estis la unua elekto por anstataŭigi Classic Load Balancer, ĉar TCP ne estas tiel ofta kiel HTTP.
Ni kreu ĝin ankaŭ, rezulte de kio ni jam havos du ŝarĝbalancilojn:
Ŝarĝbalancaj Komponentoj
Komunaj Ŝarĝbalancaj Komponentoj (komuna al ĉiuj ekvilibristoj):
- Politiko pri Ensaluta Aliro
— viaj ELB-aliraj protokoloj. Por fari agordojn, vi povas iri al Priskribo kaj elekti la butonon "Redakti atributojn":
Tiam ni specifas S3Bucket - Amazon-objektan stokadon:
- Skemo
— interna aŭ ekstera ekvilibro. La punkto estas ĉu via LoadBalancer devas ricevi eksterajn adresojn por esti alirebla de ekstere, aŭ ĉu ĝi povas esti via interna ŝarĝbalancilo;
- Sekurecaj Grupoj
- alirkontrolo al la ekvilibristo. Esence ĉi tio estas altnivela fajroŝirmilo.
- Subretoj
— subretoj ene de via VPC (kaj, sekve, havebleca zono). Subretoj estas specifitaj dum kreado. Se VPC-oj estas limigitaj de regiono, tiam Subretoj estas limigitaj de haveblecaj zonoj. Kreante Ŝarĝbalancilon, estas pli bone krei ĝin en almenaŭ du subretoj (helpas se aperas problemoj kun unu Disponebla Zono);
- Aŭskultantoj
— viaj ekvilibraj protokoloj. Kiel menciite antaŭe, por Classic Load Balancer ĝi povas esti HTTP, HTTPS, TCP kaj SSL, por Network Load Balancer - TCP, UDP kaj TLS, por Application Load Balancer - HTTP kaj HTTPS.
Ekzemplo por Klasika Ŝarĝbalancilo:
Sed en la Aplika Ŝarĝbalancilo ni vidas iomete malsaman interfacon kaj ĝenerale malsaman logikon:
Load Balancer v2-komponentoj (ALB kaj NLB)
Nun ni rigardu pli detale al la versio 2-balanciloj de Apliko-Ŝargilo kaj Reto-Ŝargilo. Ĉi tiuj balanciloj havas siajn proprajn komponentajn trajtojn. Ekzemple aperis tia koncepto kiel Celgrupoj - okazoj (kaj funkcioj). Danke al ĉi tiu komponanto, ni havas la ŝancon specifi al kiu el la Celgrupoj ni volas direkti trafikon.
En simplaj terminoj, en Celgrupoj ni specifas la okazojn, kie venos la trafiko. Se en la sama Klasika Ŝarĝbalancilo vi simple tuj konektas la intensecon al la balancilo, tiam en la Aplika Ŝarĝbalancilo vi unue:
- krei Ŝarĝbalancilon;
- krei Celgrupon;
- direkti per la postulataj havenoj aŭ Load Balancer reguloj al la postulataj Celgrupoj;
- en Celgrupoj vi atribuas okazojn.
Tiu ĉi operacia logiko povas ŝajni pli komplika, sed fakte ĝi estas pli oportuna.
La sekva komponanto estas Aŭskultanto reguloj (reguloj por vojigo). Ĉi tio nur validas por Aplikaĵo-Ŝarĝbalancilo. Se en Network Load Balancer vi simple kreas Aŭskultanton, kaj ĝi sendas trafikon al specifa Celgrupo, tiam en Application Load Balancer ĉio .
Nun ni diru kelkajn vortojn pri la sekva ero - Elasta IP (senmovaj adresoj por NLB). Se la reguloj de vojigo, Aŭskultanto-reguloj influis nur la Aplikaĵan Ŝarĝbalancilon, tiam Elasta IP influis nur la Retan Ŝarĝbalancilon.
Ni kreu Retan Ŝarĝbalancilon:
Kaj ĝuste dum la krea procezo ni vidos, ke ni ricevas la ŝancon elekti Elastikan IP:
Elasta IP provizas ununuran IP-adreson kiu povas esti asociita kun malsamaj EC2-instancoj laŭlonge de la tempo. Se EC2-instanco havas elastan IP-adreson kaj tiu kazo estas ĉesigita aŭ ĉesigita, vi povas tuj asocii novan EC2-instancon kun elasta IP-adreso. Tamen via nuna aplikaĵo ne ĉesos funkcii, ĉar aplikaĵoj ankoraŭ vidas la saman IP-adreson, eĉ se la vera EC2 ŝanĝiĝis.
tie pri la temo kial Elastika IP estas necesa. Rigardu, ni vidas 3 IP-adresojn, sed ili ne restos ĉi tie por ĉiam:
Amazon ŝanĝas ilin laŭlonge de la tempo, eble ĉiujn 60 sekundojn (sed en la praktiko, kompreneble, malpli ofte). Ĉi tio signifas, ke IP-adresoj povas ŝanĝiĝi. Kaj en la kazo de Network Load Balancer, vi povas simple ligi IP-adreson kaj indiki ĝin en viaj reguloj, politikoj ktp.
Eltiri konkludojn
ELB disponigas aŭtomatan distribuadon de envenanta trafiko tra pluraj celoj (ujoj, Amazon EC2-instancoj, IP-adresoj kaj Lambda funkcioj). ELB kapablas distribui trafikon kun diversaj ŝarĝoj kaj ene de ununura Disponebleco-Zono kaj tra pluraj Disponeblaj Zonoj. La uzanto povas elekti el tri specoj de balanciloj, kiuj disponigas altan haveblecon, aŭtoskalon kaj bonan protekton. Ĉio ĉi estas grava por certigi la misfunkciadon de viaj aplikoj.
Ĉefaj avantaĝoj:
- alta havebleco. La serva interkonsento supozas 99,99% haveblecon por la ŝarĝbalancilo. Ekzemple, pluraj Disponeblaj Zonoj certigas, ke trafiko estas prilaborita nur de sanaj objektoj. Fakte, vi povas ekvilibrigi la ŝarĝon tra la tuta regiono, redirektante trafikon al sanaj celoj en malsamaj haveblecaj zonoj;
- sekureco. ELB funkcias kun Amazon VPC, provizante diversajn sekureckapablojn - integran atestiladministradon, uzantan aŭtentigon kaj SSL/TLS-malĉifradon. Ĉio kune provizas centralizitan kaj flekseblan administradon de TLS-agordoj;
- elasteco. La ELB povas trakti subitajn ŝanĝojn en rettrafiko. Kaj profunda integriĝo kun Aŭtomata Skalado donas al la aplikaĵo sufiĉe da rimedoj se la ŝarĝo ŝanĝiĝas, sen postuli manan intervenon;
- fleksebleco. Vi povas uzi IP-adresojn por direkti petojn al la celoj de viaj aplikoj. Ĉi tio disponigas flekseblecon dum virtualigado de celaj aplikoj, tiel donante la kapablon gastigi plurajn aplikojn sur ununura kazo. Ĉar aplikoj povas uzi ununuran retan havenon kaj havi apartajn sekurecajn grupojn, komunikado inter aplikoj estas simpligita kiam ni havas, ekzemple, mikroserv-bazitan arkitekturon;
- monitorado kaj revizio. Vi povas monitori aplikojn en reala tempo uzante funkciojn de Amazon CloudWatch. Ni parolas pri metrikoj, protokoloj, peto-spurado. En simplaj terminoj, vi povos identigi problemojn kaj precize precizigi rendimentajn proplempunktojn;
- hibrida ŝarĝbalancado. La kapablo ŝarĝi ekvilibron inter surlokaj rimedoj kaj AWS uzante la saman ŝarĝbalancilon faciligas migri aŭ vastigi surlokajn aplikojn al la nubo. Fiaskotraktado ankaŭ estas simpligita uzante la nubon.
Se vi interesiĝas pri detaloj, jen kelkaj pliaj utilaj ligiloj de la oficiala Amazon-retejo:
- .
fonto: www.habr.com