Mindenkinek helló! Már ma elindul a kurzus , ezért megvalósítottunk egy megfelelő tematikus webináriumot, amely az ELB áttekintésére összpontosított. Megvizsgáltuk a terheléselosztó típusokat, és létrehoztunk néhány EC2 példányt a terheléselosztóval. Továbbá más felhasználási példákat is tanulmányoztunk.
, Ön képes lesz:
- megérteni, mi az az AWS Load Balancing;
- ismerni az Elastic Load Balancer típusait és összetevőit;
- az AWS ELB-t alkalmazni a gyakorlatában.
Miért fontos ezt tudni:
- hasznos, ha AWS tanúsító vizsgákat kíván tenni;
- egyszerű módja a terhelés elosztásának a szerverek között;
- egyszerű módja a Lambda hozzáadásának a szolgáltatásához (ALB).
A nyílt órát vezette , rendszermérnök egy weboldalakat fejlesztő és karbantartó marketingcégnél.
Bevezetés
Az Elastic Load Balancer definícióját alább látható diagramon tekintheti meg, amely bemutatja a legegyszerűbb példát:
A Load Balancer fogadja a kéréseket és elosztja azokat a példányok között. Van egy külön példányunk, Lambda funkcióink és egy Auto Scaling csoportunk (szerverek csoportja).
AWS ELB típusok
1. Tekintsük át az alapvető típusokat:
Classic Load Balancer. Az AWS első terheléselosztója, működik a 4. és 7. OSI rétegen, támogatja a HTTP, HTTPS, TCP és SSL protokollokat. Alapvető terheléselosztást biztosít több Amazon EC2 példány között, és működik a kérés és a kapcsolat szintjén is. Nyissuk meg (szürkével kiemelve):
Ez a terheléselosztó elavultnak számít, ezért csak különleges esetekben ajánlott használni. Például olyan alkalmazásokhoz, amelyek az EC2‑Classic hálózatra épültek. Egyébként senki sem akadályoz meg minket abban, hogy létrehozzuk:
2. Network Load Balancer. Nagy terheléshez ideális, a 4. OSI rétegen működik (használható EKS és ECS esetén), támogatja a TCP, UDP és TLS protokollokat.
A Network Load Balancer a forgalmat a célobjektumokhoz irányítja az Amazon VPC-n belül, és képes kezelni millió kérést másodpercenként, rendkívül alacsony késleltetéssel. Emellett optimalizálva van a hirtelen és változó terhelésű forgalmi modellek kezelésére.
3. Application Load Balancer. A 7. szinten működik, támogatja a Lambda-t, szabályokat alkalmaz a fejléceken és útvonalakon, és támogatja a HTTP és HTTPS protokollokat.
Alkalmazás-alapú architektúrákra, beleértve a mikroszolgáltatásokat és konténereket alapozva, a kérésirányítás kiterjesztett megoldásait biztosítja. A forgalmat a célobjektumokra irányítja az Amazon VPC-n innen, a kérés tartalma alapján.
Sok felhasználó számára az Application Load Balancer elsőként helyettesíti a Classic Load Balancert, mivel a TCP nem olyan elterjedt, mint a HTTP.
Készítsünk egyet, így már két terheléselosztónk lesz:
Terheléselosztó komponensei
A terheléselosztó közös komponensei (minden terheléselosztóra jellemző):
- Hozzáférési naplózási irányelv
— az ELB hozzáférési naplóid. A beállítások elvégzéséhez lépjen a Leírásra, és válassza az „Attribútumok szerkesztése” gombot:
Ezután adja meg az S3Bucket-et — az Amazon objektumtárolót:
- Sémák
— belső vagy külső terheléselosztó. Az a lényeg, hogy a LoadBalancernek kell-e külső címeket kapnia ahhoz, hogy elérhető legyen kívülről, vagy lehet ez a belső terheléselosztó;
- Biztonsági csoportok
— hozzáférés-vezérlés a terheléselosztóhoz. Lényegében ez egy magas szintű tűzfal.
- Alhálózatok
— alhálózatok az Ön VPC-jén belül (ezek szerint az elérhetőségi zónák). Az alhálózatokat a létrehozáskor adják meg. Ha a VPC régióra van korlátozva, az alhálózatok az elérhetőségi zónákra korlátozódnak. Amikor terheléselosztót hoz létre, érdemes azt legalább két alhálózatban létrehozni (ez segít, ha az egyik elérhetőségi zónával problémák merülnének fel);
- Hallgatók
— a terheléselosztó protokolljai. Mint már említettük, a Classic Load Balancer esetében ez lehet HTTP, HTTPS, TCP és SSL, a Network Load Balancer esetén — TCP, UDP és TLS, az Application Load Balancer esetében pedig HTTP és HTTPS.
Példa a Classic Load Balancer-re:
Viszont az Application Load Balancer esetében egy kicsit más felületet látunk, és összességében más logikát:
Terheléselosztó komponensek v2 (ALB és NLB)
Most részletesebben megvizsgáljuk a 2. verziós Application Load Balancer és Network Load Balancer terheléselosztókat. Ezek a terheléselosztók saját komponens sajátosságokkal rendelkeznek. Például megjelent egy olyan fogalom, mint a Célcsoportok — példányok (és funkciók). Ennek a komponensnek köszönhetően lehetőségünk nyílt megadni, hogy mely Célcsoportokra szeretnénk irányítani a forgalmat.
Egyszerű szavakkal, a Célcsoportokban azokat a példányokat határozzuk meg, ahova a forgalom érkezik. Ha a Classic Load Balancer esetén egyszerűen csatlakoztatja a példányokat a terheléselosztóhoz, akkor az Application Load Balancer esetén először:
- létrehozza a terheléselosztót;
- létrehozza a célcsoportot;
- a szükséges portok vagy Load Balancer szabályok alapján a megfelelő Target Group-ok felé irányítod;
- a Target Group-okban példányokat rendelsz hozzá.
Ez a működési logika bonyolultabbnak tűnhet, de valójában kényelmesebb.
A következő összetevő — Listener szabályok (routing szabályok). Ez már csak az Application Load Balancer-re vonatkozik. Ha a Network Load Balancer esetében egyszerűen létrehozol egy Listener-t, és az konkrét Target Group-ra irányítja a forgalmat, akkor az Application Load Balancer esetében minden .
Most beszéljünk egy kicsit a következő összetevőről — Elastic IP (statikus címek az NLB számára). Ha a Listener szabályok a routing-ra vonatkoztak az Application Load Balancer esetében, akkor az Elastic IP csak a Network Load Balancer-re vonatkozik.
Hozzuk létre a Network Load Balancer-t:
Éppen a létrehozás folyamatában látni fogjuk, hogy lehetőség van Elastic IP választására:
Az Elastic IP egyetlen IP-címet biztosít, amelyet különböző EC2 példányokhoz lehet kapcsolni az idő múlásával. Ha egy EC2 példány rendelkezik Elastic IP-címmel, és ez a példány leállt vagy le lett állítva, akkor az Elastic IP-hez egy új EC2 példány azonnal csatlakoztatható. Így a jelenlegi alkalmazásod nem áll le, mivel az alkalmazások ugyanazt az IP-címet látják, még ha a konkrét EC2 meg is változott.
Íme azért, hogy mire jó az Elastic IP. Nézd, három IP-címet látunk, de ezek nem maradnak itt örökre:
Az Amazon idővel változtatja őket, ezt akár 60 másodpercenként megteheti (de a gyakorlatban természetesen ritkábban). Ezért az IP-címek megváltozhatnak. A Network Load Balancer esetében éppen azt teheti, hogy az IP-t hozzárendelheti, és megadhatja a szabályaiban, politikáiban stb.
Levonjuk a következtetéseket
Az ELB automatikus forgalomelosztást biztosít a bejövő forgalom számára több célobjektum között (konténerek, Amazon EC2 példányok, IP-címek és Lambda funkciók). Az ELB képes forgalmat elosztani változó teher mellett, akár egy elérhetőségi zónán belül, akár több elérhetőségi zóna között. A felhasználó három különböző típusú balancer közül választhat, amelyek biztosítják a magas rendelkezésre állást, az automatikus skálázást és a megfelelő védelmet. Mindez fontos az alkalmazásaid megbízhatóságának biztosításához.
Fő előnyök:
- magas rendelkezésre állás. A szolgáltatási megállapodásban 99,99%-os rendelkezésre állás van a terheléselosztó számára. Például több elérhetőségi zóna biztosítja, hogy a forgalmat csak a hibátlan objektumok kezeljék. Valójában terhelést lehet elosztani az egész régióban, irányítva a forgalmat a hibátlan célobjektumok felé a különböző elérhetőségi zónákban;
- biztonság. Az ELB az Amazon VPC-vel működik, különböző biztonsági lehetőségeket biztosítva — beleértve az integrált tanúsítványkezelést, a felhasználói hitelesítést és az SSL/TLS titkosítást. Mindez központosított és rugalmas TLS-beállítások kezelését teszi lehetővé;
- rugalmasság. Az ELB képes kezelni a hirtelen változásokat a hálózati forgalomban. A mély integráció az Auto Scaling-gel elegendő erőforrást biztosít az alkalmazás számára, ha a terhelés változik, így manuális beavatkozásra nincs szükség;
- flexibilitás. IP-címeket lehet alkalmazni a kérések célobjektumokhoz való irányítására. Ez garantálja a rugalmasságot a célalkalmazások virtualizálása során, lehetővé téve ezzel több alkalmazás egyidejű futtatását egy példányon. Mivel az alkalmazások egy hálózati portot használhatnak, és külön biztonsági csoportokkal rendelkeznek, egyszerűbbé válik az alkalmazások közötti interakció, például ha mikroszolgáltatások alapú architektúráról van szó;
- monitorozás és auditálás. Az alkalmazások valós idejű monitorozása lehetséges az Amazon CloudWatch funkcióinak használatával. Ezek metrikákat, naplókat és a kérések nyomon követését jelentik. Egyszerű kifejezésekkel élve, képes lesz problémákat azonosítani és meglehetősen pontosan megállapítani a teljesítmény szűk keresztmetszeteit;
- hibrid terheléselosztás. A terheléselosztás lehetősége a helyi erőforrások és az AWS között, ugyanazzal a terheléselosztóval megkönnyíti a helyi alkalmazások migrációját vagy felhőbe történő bővítését. Egyszerűbbé válik a hibakezelés a felhő használatával is.
Ha további részletekre kíváncsi, íme még pár hasznos hivatkozás az Amazon hivatalos oldaláról:
- .
Forrás: habr.com
