Salut tuturor! Cursul începe astăzi , motiv pentru care am organizat un webinar tematic dedicat prezentării ELB. Am discutat despre tipurile de echilibrarea încărcării și am creat câteva instanțe EC2 cu un echilibror. De asemenea, am studiat și alte exemple de utilizare.
, veți putea:
- să înțelegeți ce este AWS Load Balancing;
- să cunoașteți tipurile de Elastic Load Balancer și componentele sale;
- să folosiți AWS ELB în practica dumneavoastră.
De ce este important să stăpâniți aceste cunoștințe:
- este util dacă plănuiți să susțineți examenele de certificare AWS;
- este un mod simplu de a distribui încărcătura între servere;
- este un mod simplu de a adăuga Lambda în serviciul dumneavoastră (ALB).
Lecția deschisă a fost susținută de , inginer de sistem într-o companie de marketing specializată în dezvoltarea și întreținerea site-urilor.
Introducere
Ce este Elastic Load Balancer poate fi văzut în diagrama de mai jos, unde este prezentat un exemplu simplu:
Load Balancer primește cererile și le distribuie între instanțe. Avem o instanță separată, funcții Lambda și un grup AutoScaling (un grup de servere).
Tipurile AWS ELB
1. Să analizăm principalele tipuri:
Classic Load Balancer. Primul echilibror de la AWS, funcționează atât la nivelul 4, cât și la nivelul 7 al modelului OSI, suportă HTTP, HTTPS, TCP și SSL. Oferă o balansare de bază a încărcăturii între mai multe instanțe Amazon EC2 și funcționează atât la nivel de cereri, cât și la nivel de conexiune. Să-l deschidem (evidențiat în gri):
Acest echilibror este considerat învechit, prin urmare este recomandat să fie utilizat doar în anumite cazuri. De exemplu, pentru aplicațiile construite în rețeaua EC2‑Classic. Totuși, nimeni nu ne împiedică să-l creăm:
2. Network Load Balancer. Potrivit pentru sarcini mari, funcționează la nivelul 4 al modelului OSI (poate fi folosit în EKS și ECS), suportă TCP, UDP și TLS.
Network Load Balancer direcționează traficul către obiectele țintă din Amazon VPC și poate gestiona milioane de cereri pe secundă cu întârzieri extrem de reduse. De asemenea, este optimizat pentru a gestiona modele de trafic cu încărcături subite și variabile.
3. Application Load Balancer. Funcționează la nivelul 7, are suport pentru Lambda, suportă reguli la nivel de antete și căi, suportă HTTP și HTTPS.
Oferă rutare extinsă a cererilor, orientată spre livrarea aplicațiilor construite pe arhitecturi moderne, inclusiv microservicii și containere. Direcționează traficul către resursele țintă din Amazon VPC, bazându-se pe conținutul cererii.
Pentru mulți utilizatori, Application Load Balancer a înlocuit în primul rând Classic Load Balancer, deoarece TCP nu este atât de frecvent folosit în comparație cu HTTP.
Să-l creăm și pe acesta, ceea ce ne va lăsa cu două balanțatoare de încărcare:
Componentele Load Balance
Componente comune ale Load Balance (caracteristice tuturor balanțatoarelor):
- Politica de jurnalizare a accesului
— jurnalele dvs. de acces la ELB. Pentru a efectua setările, puteți merge la Description și selectați butonul „Edit attributes”:
Apoi specificăm S3Bucket — serviciul de stocare de obiecte Amazon:
- Schema
— balanțator intern sau extern. Ideea este dacă LoadBalancer-ul dvs. ar trebui să primească adrese externe pentru a fi accesibil din exterior sau dacă poate fi un balanțator intern;
- Grupuri de securitate
— controlul accesului la balanțator. În esență, este un firewall la un nivel înalt.
- Subrețele
— subrețele în interiorul VPC-ului dvs. (respectiv și zone de disponibilitate). Subrețelele sunt specificate la crearea lor. Dacă VPC-ul este restricționat la o zonă, atunci subrețelele sunt restricționate la zonele de disponibilitate. Atunci când creați Load Balancer, este mai bine să-l creați în cel puțin două subrețele (ajută în cazul în care apar probleme cu o zonă de disponibilitate);
- Listeners
— protocoalele balanțatorului dvs. Așa cum s-a menționat anterior, pentru Classic Load Balancer acestea pot fi HTTP, HTTPS, TCP și SSL, pentru Network Load Balancer — TCP, UDP și TLS, iar pentru Application Load Balancer — HTTP și HTTPS.
Exemplu pentru Classic Load Balancer:
Dar în Application Load Balancer vedem o interfață puțin diferită și în general o logică diferită:
Componentele Load Balancer v2 (ALB și NLB)
Acum vom analiza mai în detaliu balanțatoarele de a doua versiune, Application Load Balancer și Network Load Balancer. Aceste balanțatoare au propriile caracteristici componente. De exemplu, a apărut noțiunea de Grupuri Țintă — instanțe (și funcții). Datorită acestui component, avem posibilitatea de a specifica la care dintre Grupurile Țintă dorim să direcționăm traficul.
Spunând pe înțelesul tuturor, în Grupurile Țintă specificăm instanțele către care va veni traficul. Dacă în Classic Load Balancer conectați pur și simplu instanțele la balanțator, în Application Load Balancer mai întâi:
- creați Load Balancer;
- creați un grup țintă;
- dirijați către porturile sau regulile Load Balancer necesare pentru grupurile țintă corespunzătoare;
- în grupurile țintă, alocați instanțele.
Această logică de lucru poate părea mai complicată, dar în realitate este mai convenabilă.
Componentele următoare — Reguli de Listener (reguli de rutare). Aceasta se referă doar la Application Load Balancer. Dacă în Network Load Balancer pur și simplu creați un Listener care trimite traficul către un anumit grup țintă, în Application Load Balancer totul .
Acum să spunem câteva cuvinte despre următoarea componentă — Elastic IP (adrese statice pentru NLB). Dacă regulile de rutare ale regulilor Listener se refereau doar la Application Load Balancer, Elastic IP se referă doar la Network Load Balancer.
Să creăm un Network Load Balancer:
Și chiar în procesul de creare vom vedea că ni se oferă posibilitatea de a alege Elastic IP:
Elastic IP oferă o adresă IP unică care poate fi asociată cu diferite instanțe EC2 în timp. Dacă o instanță EC2 are o adresă Elastic IP și această instanță este oprită sau închisă, puteți asocia imediat o nouă instanță EC2 cu adresa Elastic IP. În acest fel, aplicația dumneavoastră actuală nu va fi oprită, deoarece aplicațiile văd aceeași adresă IP, chiar dacă EC2-ul real s-a schimbat.
Iată despre motivul pentru care este necesar Elastic IP. Uitați, vedem 3 adrese IP, dar acestea nu vor rămâne aici pentru totdeauna:
Amazon le schimbă în timp, poate să o facă la fiecare 60 de secunde (dar în practică, desigur, mai rar). Asta înseamnă că adresele IP se pot schimba. Iar în cazul Network Load Balancer, puteți chiar lega adresa IP și a o menționa în regulile, politicile etc.
Să tragem concluzii
ELB asigură distribuirea automată a traficului de intrare între mai multe obiecte țintă (containere, instanțe Amazon EC2, adrese IP și funcții Lambda). ELB poate distribui traficul cu o sarcină variabilă atât într-o zonă de disponibilitate, cât și între mai multe zone de disponibilitate. Utilizatorul poate alege dintre cele trei tipuri de balansatoare care asigură atât disponibilitate ridicată, cât și scalare automată, precum și o protecție decentă. Toate acestea sunt importante pentru a asigura reziliența aplicațiilor dumneavoastră.
Principalele avantaje:
- disponibilitate ridicată. Acordul de servicii prevede o disponibilitate de 99,99% pentru balansorul de sarcină. De exemplu, mai multe zone de disponibilitate garantează că traficul va fi procesat doar de obiecte funcționale. Practic, este posibil să se balanseze sarcina pe întreaga regiune, direcționând traficul către obiectele țintă funcționale din diferite zone de disponibilitate;
- securitate. ELB funcționează cu Amazon VPC, oferind diverse opțiuni pentru asigurarea securității — inclusiv gestionarea certificatelor integrate, autentificarea utilizatorilor și decriptarea SSL/TLS. Toate acestea asigură o gestionare centralizată și flexibilă a setărilor TLS;
- elasticitate. ELB poate gestiona schimbările bruște ale traficului de rețea. Integrarea profundă cu Auto Scaling asigură aplicației suficiente resurse în mod automat, fără a necesita intervenție manuală;
- flexibilitate. Se pot utiliza adrese IP pentru direcționarea cererilor către obiectele țintă ale aplicațiilor dumneavoastră. Acest lucru asigură flexibilitate în virtualizarea aplicațiilor țintă, permițând astfel găzduirea mai multor aplicații pe aceeași instanță. Deoarece aplicațiile pot folosi un singur port de rețea și au grupuri de securitate separate, interacțiunea între aplicații este simplificată, mai ales în cazul unei arhitecturi bazate pe microservicii;
- monitorizare și audit. Poți monitoriza aplicațiile în timp real, folosind funcționalitățile Amazon CloudWatch. Acest lucru se referă la metrice, jurnale, monitorizarea cererilor. Pe scurt, vei putea identifica probleme și determina cu precizie punctele slabe de performanță;
- balansare hibridă a sarcinii. Capacitatea de a balansa sarcina între resursele locale și AWS folosind același balansor simplifică migrarea sau extinderea aplicațiilor locale în cloud. De asemenea, se simplifică gestionarea erorilor utilizând cloud-ul.
Dacă ești interesat de detalii, iată câteva linkuri utile de pe site-ul oficial Amazon:
- .
Sursa: habr.com
