Tere kõigile! Kursus algab täna
- mõista, mis on AWS-i koormuse tasakaalustamine;
- teadma elastse koormuse tasakaalustaja tüüpe ja selle komponente;
- kasutage oma praktikas AWS ELB-d.
Miks sa seda üldse teadma pead?
- kasulik, kui plaanite sooritada AWS-i sertifitseerimiseksameid;
- see on lihtne viis koormuse jaotamiseks serverite vahel;
- See on lihtne viis Lambda lisamiseks oma teenusesse (ALB).
Viidi läbi avatud õppetund
Sissejuhatus
Mis on elastne koormuse tasakaalustaja, on näha alloleval diagrammil, mis näitab lihtsat näidet:
Load Balancer aktsepteerib taotlusi ja jaotab need eksemplaride vahel. Meil on üks eraldiseisev eksemplar, seal on Lambda funktsioonid ja AutoScaling rühm (serverite rühm).
AWS ELB tüübid
1. Vaatame põhitüüpe:
Klassikaline koormuse tasakaalustaja. Kõige esimene AWS-i koormuse tasakaalustaja töötab nii OSI 4. kui ka 7. kihil, toetades HTTP, HTTPS, TCP ja SSL-i. See pakub põhilist koormuse tasakaalustamist mitme Amazon EC2 eksemplari vahel ja töötab nii taotluse kui ka ühenduse tasemel. Avame selle (halliga esile tõstetud):
Seda tasakaalustajat peetakse aegunuks, seega on soovitatav seda kasutada ainult teatud juhtudel. Näiteks rakenduste jaoks, mis on ehitatud EC2-Classic võrgule. Põhimõtteliselt ei takista keegi meid seda loomast:
2. Võrgu koormuse tasakaalustaja. Sobib suure töökoormuse jaoks, töötab OSI Layer 4-s (saab kasutada EKS-is ja ECS-is), toetatud on TCP, UDP ja TLS.
Network Load Balancer suunab liikluse Amazon VPC-s sihtmärkideni ja on võimeline töötlema miljoneid taotlusi sekundis ülimadala latentsusega. Lisaks on see optimeeritud liiklusmustrite käsitlemiseks äkiliste ja muutuvate koormustega.
3. Rakenduse koormuse tasakaalustaja. Töötab 7. kihil, omab Lambda tuge, toetab päise ja tee taseme reegleid, toetab HTTP ja HTTPS.
Pakub täiustatud päringu marsruutimist, mis keskendub kaasaegsetele arhitektuuridele, sealhulgas mikroteenustele ja konteineritele, üles ehitatud rakenduste pakkumisele. Suunab liikluse Amazon VPC sihtmärkidele päringu sisu põhjal.
Paljude kasutajate jaoks oli Application Load Balancer esimene valik klassikalise koormuse tasakaalustaja asendamiseks, kuna TCP pole nii levinud kui HTTP.
Loome ka selle, mille tulemusena on meil juba kaks koormuse tasakaalustajat:
Koormuse tasakaalu komponendid
Üldised koormustasakaalu komponendid (ühine kõigile tasakaalustajatele):
- Juurdepääsu logimispoliitika
— teie ELB juurdepääsulogid. Seadete tegemiseks võite minna jaotisse Kirjeldus ja valida nupp „Muuda atribuute”.
Seejärel määrame S3Bucket - Amazoni objektide salvestusruumi:
- Skeem
— sisemine või välimine tasakaalustaja. Asi on selles, kas teie LoadBalancer peab saama väliseid aadresse, et see oleks väljastpoolt juurdepääsetav, või võib see olla teie sisemine koormuse tasakaalustaja;
- Turvarühmad
— juurdepääsu kontroll tasakaalustusseadmele. Põhimõtteliselt on see kõrgetasemeline tulemüür.
- Alamvõrgud
— alamvõrgud teie VPC-s (ja vastavalt saadavuse tsoonis). Alamvõrgud määratakse loomise ajal. Kui VPC-d on piiratud piirkonnaga, siis alamvõrke piiravad saadavuse tsoonid. Load Balanceri loomisel on parem see luua vähemalt kahes alamvõrgus (aitab, kui probleemid tekivad ühe Kättesaadavustsooniga);
- Kuulajad
- teie tasakaalustaja protokollid. Nagu varem mainitud, võib klassikalise koormuse tasakaalustaja jaoks olla HTTP, HTTPS, TCP ja SSL, võrgu koormuse tasakaalustaja jaoks - TCP, UDP ja TLS, rakenduste koormuse tasakaalustaja jaoks - HTTP ja HTTPS.
Klassikalise koormuse tasakaalustaja näide:
Kuid rakenduses Application Load Balancer näeme veidi erinevat liidest ja üldiselt erinevat loogikat:
Load Balancer v2 komponendid (ALB ja NLB)
Nüüd vaatame lähemalt versiooni 2 tasakaalustajaid Application Load Balancer ja Network Load Balancer. Nendel tasakaalustajatel on oma komponentide omadused. Näiteks ilmus selline mõiste nagu sihtrühmad - eksemplarid (ja funktsioonid). Tänu sellele komponendile on meil võimalus täpsustada, millisesse Sihtgruppi me liiklust suuname.
Lihtsamalt öeldes määratleme sihtrühmades juhtumid, kuhu liiklus tuleb. Kui samas Classic Load Balanceris ühendate intensiivsuse lihtsalt kohe tasakaalustajaga, siis Application Load Balanceris kõigepealt:
- loo Load Balancer;
- luua sihtrühm;
- suunata vajalike portide või Load Balanceri reeglite kaudu vajalikesse sihtrühmadesse;
- jaotises Sihtrühmad määrate eksemplare.
See tööloogika võib tunduda keerulisem, kuid tegelikult on see mugavam.
Järgmine komponent on Kuulaja reeglid (marsruutimise reeglid). See kehtib ainult Application Load Balanceri kohta. Kui Network Load Balanceris loote lihtsalt kuulaja ja see saadab liikluse kindlale sihtrühmale, siis rakenduses Application Load Balancer kõik
Nüüd ütleme paar sõna järgmise komponendi kohta - Elastne IP (NLB staatilised aadressid). Kui kuulaja reeglite marsruutimisreeglid mõjutasid ainult rakenduse koormuse tasakaalustajat, siis elastne IP mõjutas ainult võrgu koormuse tasakaalustajat.
Loome võrgu koormuse tasakaalustaja:
Ja just loomisprotsessi ajal näeme, et meile antakse võimalus valida elastne IP:
Elastne IP pakub ühte IP-aadressi, mida saab aja jooksul seostada erinevate EC2 eksemplaridega. Kui EC2 eksemplaril on elastne IP-aadress ja see eksemplar lõpetatakse või peatatakse, saate kohe siduda uue EC2 eksemplari elastse IP-aadressiga. Kuid teie praegune rakendus ei lakka töötamast, kuna rakendused näevad endiselt sama IP-aadressi, isegi kui tegelik EC2 on muutunud.
siin on
Amazon muudab neid aja jooksul, võib-olla iga 60 sekundi järel (aga praktikas muidugi harvem). See tähendab, et IP-aadressid võivad muutuda. Ja Network Load Balanceri puhul saate lihtsalt siduda IP-aadressi ja märkida selle oma reeglites, poliitikates jne.
Järeldusi teha
ELB pakub sissetuleva liikluse automaatset jaotamist mitme sihtmärgi vahel (konteinerid, Amazon EC2 eksemplarid, IP-aadressid ja Lambda funktsioonid). ELB on võimeline jaotama erineva koormusega liiklust nii ühes saadavuse tsoonis kui ka mitmes saadavustsoonis. Kasutaja saab valida kolme tüüpi tasakaalustajate vahel, mis pakuvad kõrget kättesaadavust, automaatset skaleerimist ja head kaitset. Kõik see on oluline, et tagada teie rakenduste veataluvus.
Peamised plussid:
- kõrge kättesaadavus. Teenusleping eeldab koormuse tasakaalustaja 99,99% saadavust. Näiteks mitu saadavuse tsooni tagab, et liiklust töötlevad ainult terved objektid. Tegelikult saate kogu piirkonna koormust tasakaalustada, suunates liikluse ümber tervislikele sihtmärkidele erinevates saadavustsoonides;
- turvalisus. ELB töötab Amazon VPC-ga, pakkudes erinevaid turbevõimalusi – integreeritud sertifikaatide haldust, kasutaja autentimist ja SSL/TLS dekrüpteerimist. Kõik koos tagab TLS-i sätete tsentraliseeritud ja paindliku haldamise;
- elastsus. ELB saab hakkama äkiliste muutustega võrguliikluses. Ja sügav integratsioon automaatse skaleerimisega annab rakendusele koormuse muutumisel piisavalt ressursse, ilma et oleks vaja käsitsi sekkuda;
- paindlikkus. IP-aadresse saate kasutada päringute suunamiseks oma rakenduste sihtmärkideni. See pakub sihtrakenduste virtualiseerimisel paindlikkust, andes seega võimaluse majutada mitut rakendust ühel eksemplaril. Kuna rakendused saavad kasutada ühte võrguporti ja neil on eraldi turvarühmad, on rakendustevaheline suhtlus lihtsustatud, kui meil on näiteks mikroteenustel põhinev arhitektuur;
- järelevalve ja audit. Amazon CloudWatchi funktsioonide abil saate rakendusi reaalajas jälgida. Me räägime mõõdikutest, logidest, taotluste jälgimisest. Lihtsamalt öeldes suudate probleeme tuvastada ja jõudluse kitsaskohti üsna täpselt kindlaks teha;
- hübriidkoormuse tasakaalustamine. Kohalike ressursside ja AWS-i vahelise koormuse tasakaal sama koormuse tasakaalustaja abil muudab kohapealsete rakenduste pilve migreerimise või laiendamise lihtsaks. Samuti on pilve abil rikete käsitlemine lihtsustatud.
Kui olete üksikasjadest huvitatud, on siin veel paar kasulikku linki Amazoni ametlikult veebisaidilt:
Allikas: www.habr.com