Sziasztok! A tanfolyam ma kezdődik , amelyhez kapcsolódóan az ELB felülvizsgálatának szentelt tematikus webináriumot tartottuk. Megnéztük a kiegyensúlyozó típusokat, és több EC2 példányt készítettünk kiegyenlítővel. Tanulmányoztunk más felhasználási példákat is.
, Fogsz:
- megérteni, mi az AWS terheléselosztás;
- ismeri a rugalmas terheléselosztó típusait és alkatrészeit;
- használja az AWS ELB-t a gyakorlatában.
Miért kell ezt egyáltalán tudni?
- hasznos, ha AWS minősítő vizsgát tervez;
- ez egy egyszerű módja a terhelés elosztásának a szerverek között;
- Ez egy egyszerű módja annak, hogy Lambdát adjon a szolgáltatáshoz (ALB).
Nyílt leckét tartott , rendszermérnök egy marketingcégnél webhelyfejlesztéssel és támogatással.
Bevezetés
Az alábbi diagramon látható, hogy mi az elasztikus terheléselosztó, amely egy egyszerű példát mutat:
A Load Balancer elfogadja a kéréseket, és szétosztja azokat a példányok között. Egy külön példányunk van, vannak Lambda függvények és van egy AutoScaling csoport (szerverek csoportja).
AWS ELB típusok
1. Nézzük a főbb típusokat:
Klasszikus terheléselosztó. Az AWS legelső kiegyensúlyozója, mind a 4-es, mind a 7-es OSI-rétegen működik, a HTTP, HTTPS, TCP és SSL támogatja. Alapvető terheléselosztást biztosít több Amazon EC2 példányon keresztül, és mind a kérés, mind a kapcsolat szintjén működik. Nyissuk ki (szürkével kiemelve):
Ez a kiegyenlítő elavultnak tekinthető, ezért használata csak bizonyos esetekben javasolt. Például az EC2-Classic hálózatra épített alkalmazásokhoz. Elvileg senki sem akadályoz meg bennünket abban, hogy elkészítsük:
2. Hálózati terheléselosztó. Alkalmas nagy terhelésekhez, OSI Layer 4-en működik (EKS-ben és ECS-ben használható), TCP, UDP és TLS támogatott.
A Network Load Balancer a forgalmat a célpontokhoz irányítja egy Amazon VPC-ben, és másodpercenként kérések millióit képes feldolgozni rendkívül alacsony késleltetéssel. Ezenkívül a forgalmi minták kezelésére optimalizálták a hirtelen és változó terhelésekkel.
3. Alkalmazási terheléselosztó. A 7-es rétegben működik, Lambda-támogatással rendelkezik, támogatja a fejléc- és elérési út szintű szabályokat, támogatja a HTTP-t és a HTTPS-t.
Speciális kérés-útválasztást biztosít a modern architektúrákra épülő alkalmazások szállítására összpontosítva, beleértve a mikroszolgáltatásokat és a konténereket. A kérés tartalma alapján a forgalmat az Amazon VPC célpontjaihoz irányítja.
Sok felhasználó számára az Application Load Balancer volt az első választás a Classic Load Balancer helyett, mivel a TCP nem olyan gyakori, mint a HTTP.
Készítsük el mi is, aminek eredményeként már két terheléselosztónk lesz:
Terhelési egyensúly összetevői
Közös terhelési egyensúly-komponensek (minden egyensúlyozónál közös):
- Hozzáférés naplózási szabályzata
— az ELB hozzáférési naplói. A beállítások elvégzéséhez lépjen a Leírásba, és válassza az „Attribútumok szerkesztése” gombot:
Ezután megadjuk az S3Bucket - Amazon objektumtárolót:
- Rendszer
— belső vagy külső kiegyensúlyozó. A lényeg az, hogy a LoadBalancernek külső címeket kell-e kapnia ahhoz, hogy kívülről elérhető legyen, vagy ez lehet a belső terheléselosztója;
- Biztonsági csoportok
— hozzáférés szabályozása a kiegyenlítőhöz. Lényegében ez egy magas szintű tűzfal.
- Alhálózatok
— a VPC-n belüli alhálózatok (és ennek megfelelően a rendelkezésre állási zóna). Az alhálózatok a létrehozás során kerülnek megadásra. Ha a VPC-ket régiók korlátozzák, akkor az alhálózatokat a rendelkezésre állási zónák korlátozzák. A Load Balancer létrehozásakor jobb, ha legalább két alhálózatban hozza létre (segít, ha problémák merülnek fel egy elérhetőségi zónával);
- hallgatók
— a kiegyensúlyozó protokolljait. Mint korábban említettük, a Classic Load Balancer esetében ez lehet HTTP, HTTPS, TCP és SSL, a Network Load Balancer esetében - TCP, UDP és TLS, az Application Load Balancer esetében - HTTP és HTTPS.
Példa a klasszikus terheléselosztóra:
De az Application Load Balancerben egy kicsit más felületet és általában eltérő logikát látunk:
Load Balancer v2 összetevők (ALB és NLB)
Most nézzük meg közelebbről a 2-es verziójú kiegyenlítőket: Application Load Balancer és Network Load Balancer. Ezeknek a kiegyenlítőknek megvannak a saját alkatrészei. Például megjelent egy olyan fogalom, mint a célcsoportok - példányok (és függvények). Ennek a komponensnek köszönhetően lehetőségünk van megadni, hogy a Célcsoportok közül melyikbe szeretnénk forgalmat irányítani.
Egyszerűen fogalmazva, a Célcsoportokban megadjuk azokat az eseteket, ahová a forgalom érkezik. Ha ugyanabban a Classic Load Balancerben egyszerűen azonnal csatlakoztatja az intenzitást a kiegyenlítőhöz, akkor az Application Load Balancerben először:
- hozzon létre egy terheléselosztót;
- hozzon létre egy célcsoportot;
- közvetlenül a szükséges portokon vagy Load Balancer szabályokon keresztül a kívánt célcsoportokhoz;
- a célcsoportokban példányokat rendel hozzá.
Ez a működési logika bonyolultabbnak tűnhet, de valójában kényelmesebb.
A következő összetevő az Hallgató szabályok (útválasztási szabályok). Ez csak az Application Load Balancerre vonatkozik. Ha a Network Load Balancerben egyszerűen létrehoz egy figyelőt, és az egy adott célcsoporthoz küldi a forgalmat, akkor az Application Load Balancerben mindent .
Most pedig ejtsünk néhány szót a következő komponensről - Rugalmas IP (statikus címek az NLB számára). Ha az útválasztási szabályok figyelőszabályai csak az Application Load Balancerre voltak hatással, akkor az Elastic IP csak a hálózati terheléselosztóra.
Hozzon létre egy hálózati terheléselosztót:
És csak a létrehozási folyamat során látni fogjuk, hogy lehetőséget kapunk az Elastic IP kiválasztására:
Az Elastic IP egyetlen IP-címet biztosít, amely idővel különböző EC2-példányokhoz társítható. Ha egy EC2-példány rugalmas IP-címmel rendelkezik, és az adott példányt leállítják vagy leállítják, azonnal társíthat egy új EC2-példányt egy rugalmas IP-címhez. A jelenlegi alkalmazás azonban nem fog leállni, mivel az alkalmazások továbbra is ugyanazt az IP-címet látják, még akkor is, ha a valódi EC2 megváltozott.
Itt arról a témáról, hogy miért van szükség az Elastic IP-re. Nézze, 3 IP-címet látunk, de ezek nem maradnak itt örökre:
Az Amazon idővel megváltoztatja őket, talán 60 másodpercenként (de a gyakorlatban persze ritkábban). Ez azt jelenti, hogy az IP-címek változhatnak. A Network Load Balancer esetében pedig csak köthet egy IP-címet, és feltüntetheti a szabályokban, szabályzatokban stb.
Végezzen következtetéseket
Az ELB biztosítja a bejövő forgalom automatikus elosztását több célpont között (tárolók, Amazon EC2 példányok, IP-címek és Lambda-funkciók). Az ELB képes elosztani a forgalmat változó terhelés mellett egyetlen rendelkezésre állási zónán belül és több rendelkezésre állási zóna között is. A felhasználó háromféle egyensúlyozó közül választhat, amelyek magas rendelkezésre állást, automatikus skálázást és jó védelmet biztosítanak. Mindez azért fontos, hogy biztosítsa alkalmazásai hibatűrését.
Főbb előnyei:
- magas rendelkezésre állás. A szolgáltatási szerződés 99,99%-os rendelkezésre állást feltételez a terheléselosztó számára. Például a több rendelkezésre állási zóna biztosítja, hogy a forgalmat csak egészséges objektumok dolgozzák fel. Valójában kiegyenlítheti a terhelést az egész régióban, átirányítva a forgalmat a különböző elérhetőségi zónákban lévő egészséges célokra;
- biztonság. Az ELB együttműködik az Amazon VPC-vel, különféle biztonsági lehetőségeket kínálva – integrált tanúsítványkezelést, felhasználói hitelesítést és SSL/TLS visszafejtést. Mindez együtt biztosítja a TLS-beállítások központi és rugalmas kezelését;
- rugalmasság. Az ELB képes kezelni a hálózati forgalom hirtelen változásait. Az automatikus méretezéssel való mély integráció pedig elegendő erőforrást biztosít az alkalmazásnak, ha a terhelés megváltozik, anélkül, hogy kézi beavatkozásra lenne szükség;
- rugalmasság. Az IP-címek segítségével a kéréseket az alkalmazások célpontjaihoz irányíthatja. Ez rugalmasságot biztosít a célalkalmazások virtualizálása során, így lehetővé válik több alkalmazás egyetlen példányon történő üzemeltetése. Mivel az alkalmazások egyetlen hálózati portot használhatnak, és külön biztonsági csoportokkal rendelkeznek, az alkalmazások közötti kommunikáció leegyszerűsödik, ha mondjuk mikroszolgáltatásokon alapuló architektúrával rendelkezünk;
- monitoring és audit. Az Amazon CloudWatch funkcióival valós időben figyelheti az alkalmazásokat. Metrikákról, naplókról, kéréskövetésről beszélünk. Egyszerűen fogalmazva, képes lesz pontosan azonosítani a problémákat és a teljesítmény szűk keresztmetszeteit;
- hibrid terheléselosztás. A helyszíni erőforrások és az AWS közötti terheléselosztás lehetősége ugyanazon terheléselosztó használatával megkönnyíti a helyszíni alkalmazások felhőbe való migrálását vagy bővítését. A felhő használatával a hibakezelés is leegyszerűsödik.
Ha érdekelnek a részletek, itt van még néhány hasznos link az Amazon hivatalos webhelyéről:
- .
Forrás: will.com