Hola a tots! El curs comença avui , en relació amb el qual vam realitzar un webinar temàtic corresponent dedicat a la revisió ELB. Hem analitzat els tipus d'equilibradors i hem creat diverses instàncies EC2 amb un equilibrador. També hem estudiat altres exemples d'ús.
, faràs:
- entendre què és AWS Load Balancing;
- conèixer els tipus d'Elastic Load Balancer i els seus components;
- utilitzeu AWS ELB a la vostra pràctica.
Per què necessites saber això?
- útil si teniu previst fer exàmens de certificació AWS;
- aquesta és una manera senzilla de distribuir la càrrega entre servidors;
- Aquesta és una manera senzilla d'afegir Lambda al vostre servei (ALB).
Va fer una lliçó oberta , enginyer de sistemes en una empresa de màrqueting per al desenvolupament i suport de llocs web.
Introducció
El que és un Elastic Load Balancer es pot veure al diagrama següent, que mostra un exemple senzill:
Load Balancer accepta sol·licituds i les distribueix entre instàncies. Tenim una instància separada, hi ha funcions Lambda i hi ha un grup AutoScaling (un grup de servidors).
Tipus AWS ELB
1. Vegem els principals tipus:
Equilibrador de càrrega clàssic. El primer equilibrador d'AWS, funciona a les dues capes OSI 4 i 7, s'admeten HTTP, HTTPS, TCP i SSL. Proporciona un equilibri de càrrega bàsic en diverses instàncies d'Amazon EC2 i funciona tant a nivell de sol·licitud com de connexió. Obrim-lo (ressaltat en gris):
Aquest equilibrador es considera obsolet, per la qual cosa es recomana utilitzar-lo només en determinats casos. Per exemple, per a aplicacions que es van crear a la xarxa EC2-Classic. En principi, ningú ens impedeix crear-lo:
2. Equilibrador de càrrega de xarxa. Apte per a càrregues de treball pesades, funciona a OSI Layer 4 (es pot utilitzar en EKS i ECS), s'admeten TCP, UDP i TLS.
Network Load Balancer encamina el trànsit als objectius en un Amazon VPC i és capaç de processar milions de sol·licituds per segon amb una latència molt baixa. A més, està optimitzat per gestionar els patrons de trànsit amb càrregues sobtades i canviants.
3. Equilibrador de càrrega de l'aplicació. Funciona a la capa 7, té suport Lambda, admet regles de nivell de capçalera i camí, admet HTTP i HTTPS.
Proporciona un encaminament de sol·licituds avançat centrat en el lliurament d'aplicacions basades en arquitectures modernes, inclosos microserveis i contenidors. Dirigeix el trànsit als objectius a Amazon VPC en funció del contingut de la sol·licitud.
Per a molts usuaris, Application Load Balancer va ser la primera opció per substituir Classic Load Balancer, perquè TCP no és tan comú com HTTP.
Creem-lo també, com a resultat de la qual cosa ja tindrem dos equilibradors de càrrega:
Components d'equilibri de càrrega
Components comuns d'equilibri de càrrega (comú a tots els equilibradors):
- Política de registre d'accés
— els vostres registres d'accés ELB. Per fer la configuració, podeu anar a Descripció i seleccionar el botó "Edita els atributs":
A continuació, especifiquem S3Bucket - Emmagatzematge d'objectes Amazon:
- Esquema
— equilibrador intern o extern. La qüestió és si el vostre LoadBalancer ha de rebre adreces externes per poder ser accessible des de l'exterior, o pot ser el vostre equilibrador de càrrega intern;
- Grups de seguretat
— control d'accés a l'equilibrador. Essencialment, es tracta d'un tallafoc d'alt nivell.
- Subxarxes
— subxarxes dins del vostre VPC (i, en conseqüència, zona de disponibilitat). Les subxarxes s'especifiquen durant la creació. Si les VPC estan limitades per regió, les subxarxes estan limitades per zones de disponibilitat. Quan es crea un equilibrador de càrrega, és millor crear-lo en almenys dues subxarxes (ajuda si sorgeixen problemes amb una zona de disponibilitat);
- Oients
- els vostres protocols d'equilibri. Com s'ha esmentat anteriorment, per a Classic Load Balancer pot ser HTTP, HTTPS, TCP i SSL, per a Network Load Balancer - TCP, UDP i TLS, per a Application Load Balancer - HTTP i HTTPS.
Exemple de Classic Load Balancer:
Però a l'Application Load Balancer veiem una interfície lleugerament diferent i una lògica generalment diferent:
Components de Load Balancer v2 (ALB i NLB)
Ara fem una ullada més de prop als equilibradors de la versió 2 Application Load Balancer i Network Load Balancer. Aquests equilibradors tenen les seves pròpies característiques de components. Per exemple, va aparèixer un concepte com Target Groups: instàncies (i funcions). Gràcies a aquest component, tenim l'oportunitat d'especificar a quins dels grups objectiu volem dirigir el trànsit.
En termes senzills, a Grups objectiu especifiquem els casos on arribarà el trànsit. Si al mateix Classic Load Balancer simplement connecteu immediatament la intensitat a l'equilibrador, llavors primer a l'Application Load Balancer:
- crear un equilibrador de càrrega;
- crear un grup objectiu;
- directe mitjançant els ports requerits o les regles de Load Balancer als grups objectiu requerits;
- a Grups objectiu assigneu instàncies.
Aquesta lògica de funcionament pot semblar més complicada, però de fet és més convenient.
El següent component és Normes de l'oient (normes d'encaminament). Això només s'aplica a Application Load Balancer. Si a Network Load Balancer només creeu un listener i envia trànsit a un grup objectiu específic, a l'Application Load Balancer tot .
Ara diguem algunes paraules sobre el següent component: IP elàstica (adreces estàtiques per a NLB). Si les regles d'enrutament de les regles d'escolta només afectaven l'equilibrador de càrrega de l'aplicació, aleshores l'IP elàstica només afectava l'equilibrador de càrrega de xarxa.
Creem un equilibrador de càrrega de xarxa:
I just durant el procés de creació veurem que se'ns dóna l'oportunitat de seleccionar IP elàstica:
Elastic IP proporciona una única adreça IP que es pot associar amb diferents instàncies EC2 al llarg del temps. Si una instància EC2 té una adreça IP elàstica i aquesta instància s'acaba o s'atura, podeu associar immediatament una instància EC2 nova amb una adreça IP elàstica. Tanmateix, la vostra aplicació actual no deixarà de funcionar, ja que les aplicacions encara veuen la mateixa adreça IP, encara que l'EC2 real hagi canviat.
aquí està sobre el tema de per què es necessita Elastic IP. Mira, veiem 3 adreces IP, però no es quedaran aquí per sempre:
Amazon els canvia amb el temps, potser cada 60 segons (però a la pràctica, és clar, amb menys freqüència). Això vol dir que les adreces IP poden canviar. I en el cas de Network Load Balancer, només podeu vincular una adreça IP i indicar-la a les vostres regles, polítiques, etc.
Treure conclusions
ELB proporciona una distribució automàtica del trànsit entrant entre diversos objectius (contenidors, instàncies Amazon EC2, adreces IP i funcions Lambda). ELB és capaç de distribuir trànsit amb diferents càrregues tant dins d'una única zona de disponibilitat com entre diverses zones de disponibilitat. L'usuari pot triar entre tres tipus d'equilibradors que proporcionen alta disponibilitat, autoescala i una bona protecció. Tot això és important per garantir la tolerància a errors de les vostres aplicacions.
Principals avantatges:
- alta disponibilitat. L'acord de servei suposa una disponibilitat del 99,99% per a l'equilibrador de càrrega. Per exemple, diverses zones de disponibilitat garanteixen que el trànsit només sigui processat per objectes en bon estat. De fet, podeu equilibrar la càrrega a tota la regió, redirigint el trànsit a objectius saludables en diferents zones de disponibilitat;
- seguretat. ELB treballa amb Amazon VPC, proporcionant diverses capacitats de seguretat: gestió integrada de certificats, autenticació d'usuaris i desxifrat SSL/TLS. Tot plegat ofereix una gestió centralitzada i flexible de la configuració de TLS;
- elasticitat. L'ELB pot gestionar canvis sobtats en el trànsit de la xarxa. I la integració profunda amb Auto Scaling proporciona a l'aplicació recursos suficients si la càrrega canvia, sense necessitat d'intervenció manual;
- flexibilitat. Podeu utilitzar adreces IP per encaminar les sol·licituds als objectius de les vostres aplicacions. Això proporciona flexibilitat a l'hora de virtualitzar aplicacions de destinació, donant així la possibilitat d'allotjar diverses aplicacions en una sola instància. Com que les aplicacions poden utilitzar un únic port de xarxa i tenir grups de seguretat separats, la comunicació entre aplicacions es simplifica quan tenim, per exemple, una arquitectura basada en microserveis;
- seguiment i auditoria. Podeu supervisar les aplicacions en temps real mitjançant les funcions d'Amazon CloudWatch. Estem parlant de mètriques, registres, seguiment de sol·licituds. En termes senzills, podreu identificar problemes i identificar els colls d'ampolla de rendiment amb força precisió;
- equilibri de càrrega híbrid. La capacitat d'equilibrar la càrrega entre els recursos locals i AWS mitjançant el mateix equilibrador de càrrega facilita la migració o l'expansió d'aplicacions locals al núvol. La gestió de fallades també es simplifica mitjançant el núvol.
Si esteu interessats en els detalls, aquí teniu un parell d'enllaços útils més del lloc web oficial d'Amazon:
- .
Font: www.habr.com