Hei kaikki! Kurssi alkaa tänään , jonka yhteydessä järjestimme vastaavan ELB-katsaukselle omistetun temaattisen webinaarin. Tarkastelimme tasapainottimien tyyppejä ja loimme useita EC2-esineitä tasapainottimella. Tutkimme myös muita käyttöesimerkkejä.
, Tulet:
- ymmärtää, mitä AWS Load Balancing on;
- tuntea elastisen kuormituksen tasauslaitteen ja sen komponenttien tyypit;
- käytä AWS ELB:tä harjoituksissasi.
Miksi tämä ylipäätään tarvitsee tietää?
- hyödyllinen, jos aiot suorittaa AWS-sertifiointikokeita;
- tämä on yksinkertainen tapa jakaa kuorma palvelimien välillä;
- Tämä on yksinkertainen tapa lisätä Lambda palveluun (ALB).
Piti avoin oppitunti , järjestelmäinsinööri markkinointiyrityksessä verkkosivustojen kehittämiseen ja tukeen.
Esittely
Mikä elastinen kuormituksen tasauslaite on, voidaan nähdä alla olevasta kaaviosta, jossa on yksinkertainen esimerkki:
Load Balancer hyväksyy pyynnöt ja jakaa ne esiintymien kesken. Meillä on yksi erillinen esiintymä, on Lambda-funktioita ja on AutoScaling-ryhmä (palvelinryhmä).
AWS ELB-tyypit
1. Tarkastellaan päätyyppejä:
Klassinen Load Balancer. Ensimmäinen AWS:n kuormantasaaja toimii sekä OSI Layer 4:ssä että Layer 7:ssä ja tukee HTTP:tä, HTTPS:ää, TCP:tä ja SSL:ää. Se tarjoaa peruskuormituksen tasauksen useille Amazon EC2 -esiintymille ja toimii sekä pyyntö- että yhteystasoilla. Avataan se (korostettu harmaalla):
Tämä tasapainotin katsotaan vanhentuneeksi, joten sitä suositellaan käytettäväksi vain tietyissä tapauksissa. Esimerkiksi sovelluksille, jotka on rakennettu EC2-Classic-verkkoon. Periaatteessa kukaan ei estä meitä luomasta sitä:
2. Network Load Balancer. Soveltuu raskaaseen työmäärään, toimii OSI Layer 4:ssä (voidaan käyttää EKS:ssä ja ECS:ssä), TCP, UDP ja TLS ovat tuettuja.
Network Load Balancer reitittää liikenteen Amazon VPC:n kohteisiin ja pystyy käsittelemään miljoonia pyyntöjä sekunnissa erittäin alhaisella viiveellä. Lisäksi se on optimoitu käsittelemään äkillisiä ja vaihtuvia kuormituksia aiheuttavia liikennemalleja.
3. Sovelluksen kuormituksen tasapainotin. Toimii kerroksessa 7, siinä on Lambda-tuki, tukee otsikko- ja polkutason sääntöjä, tukee HTTP:tä ja HTTPS:ää.
Tarjoaa edistyneen pyyntöreitityksen, joka keskittyy moderneille arkkitehtuureille rakennettujen sovellusten toimittamiseen, mukaan lukien mikropalvelut ja säiliöt. Ohjaa liikenteen Amazon VPC:n kohteisiin pyynnön sisällön perusteella.
Monille käyttäjille Application Load Balancer oli ensimmäinen vaihtoehto korvata Classic Load Balancer, koska TCP ei ole yhtä yleinen kuin HTTP.
Luodaan sekin, minkä seurauksena meillä on jo kaksi kuormitustasainta:
Kuormituksen tasapainon osat
Yleiset kuormituksen tasapainon osat (yhteinen kaikille tasapainottajille):
- Access Logging Policy
- ELB-käyttölokit. Voit tehdä asetuksia siirtymällä kohtaan Kuvaus ja valitsemalla "Muokkaa määritteitä" -painikkeen:
Sitten määritämme S3Bucket - Amazon-objektien tallennustila:
- ohjelma
— sisäinen tai ulkoinen tasapainotin. Kysymys on siitä, onko LoadBalancerin saatava ulkoisia osoitteita, jotta se on käytettävissä ulkopuolelta, vai voiko se olla sisäinen kuormantasaajasi;
- Turvaryhmiä
— Tasapainottimen kulunvalvonta. Pohjimmiltaan tämä on korkean tason palomuuri.
- Aliverkot
— VPC:n sisällä olevat aliverkot (ja vastaavasti saatavuusvyöhyke). Aliverkot määritetään luonnin aikana. Jos VPC:t ovat aluekohtaisia, aliverkkoja rajoittavat käytettävyysalueet. Kun luot Load Balanceria, on parempi luoda se vähintään kahteen aliverkkoon (auttaa, jos yhden Saatavuusvyöhykkeen kanssa ilmenee ongelmia);
- kuuntelijoita
- tasapainotusprotokollasi. Kuten aiemmin mainittiin, Classic Load Balancerille se voi olla HTTP, HTTPS, TCP ja SSL, Network Load Balancerille - TCP, UDP ja TLS, Application Load Balancerille - HTTP ja HTTPS.
Esimerkki klassisesta Load Balancerista:
Mutta Application Load Balancerissa näemme hieman erilaisen käyttöliittymän ja yleensä erilaisen logiikan:
Load Balancer v2 -komponentit (ALB ja NLB)
Katsotaanpa nyt tarkemmin version 2 tasapainottimia Application Load Balancer ja Network Load Balancer. Näillä tasapainottimilla on omat komponenttiominaisuudet. Esimerkiksi sellainen käsite kuin kohderyhmät ilmestyi - esiintymät (ja toiminnot). Tämän komponentin ansiosta meillä on mahdollisuus määrittää, mihin kohderyhmiin haluamme ohjata liikennettä.
Yksinkertaisesti sanottuna kohderyhmissä määritämme tapaukset, joihin liikenne tulee. Jos samassa Classic Load Balancerissa kytket intensiteetin yksinkertaisesti välittömästi tasapainottimeen, niin Application Load Balancerissa ensin:
- luo Load Balancer;
- luo kohderyhmä;
- suoraan vaadittujen porttien tai Load Balancer -sääntöjen kautta vaadituille kohderyhmille;
- Kohderyhmissä määrität esiintymiä.
Tämä toimintalogiikka voi tuntua monimutkaisemmalta, mutta itse asiassa se on kätevämpi.
Seuraava komponentti on Kuuntelijan säännöt (reitityksen säännöt). Tämä koskee vain Application Load Balanceria. Jos Network Load Balancerissa luot vain kuuntelijan ja se lähettää liikennettä tiettyyn kohderyhmään, niin Application Load Balancerissa kaikki .
Sanotaan nyt muutama sana seuraavasta komponentista - Elastinen IP (staattiset osoitteet NLB:lle). Jos Listener-sääntöjen reitityssäännöt vaikuttivat vain Application Load Balanceriin, elastinen IP vaikutti vain Network Load Balanceriin.
Luodaan Network Load Balancer:
Ja juuri luomisprosessin aikana näemme, että meille annetaan mahdollisuus valita Elastic IP:
Elastinen IP tarjoaa yhden IP-osoitteen, joka voidaan liittää eri EC2-esiintymiin ajan myötä. Jos EC2-ilmentymällä on elastinen IP-osoite ja kyseinen ilmentymä lopetetaan tai pysäytetään, voit välittömästi liittää uuden EC2-ilmentymän elastiseen IP-osoitteeseen. Nykyinen sovelluksesi ei kuitenkaan lakkaa toimimasta, koska sovellukset näkevät edelleen saman IP-osoitteen, vaikka todellinen EC2 olisi muuttunut.
Täällä aiheeseen, miksi elastista IP:tä tarvitaan. Katsos, näemme 3 IP-osoitetta, mutta ne eivät pysy täällä ikuisesti:
Amazon muuttaa niitä ajan myötä, ehkä 60 sekunnin välein (mutta käytännössä tietysti harvemmin). Tämä tarkoittaa, että IP-osoitteet voivat muuttua. Ja Network Load Balancerin tapauksessa voit vain sitoa IP-osoitteen ja ilmoittaa sen säännöissäsi, käytännöissäsi jne.
Johtopäätöksiä
ELB tarjoaa saapuvan liikenteen automaattisen jakelun useiden kohteiden kesken (säilöt, Amazon EC2 -esiintymät, IP-osoitteet ja Lambda-toiminnot). ELB pystyy jakamaan liikennettä vaihtelevalla kuormituksella sekä yhden saatavuusvyöhykkeen sisällä että useiden saatavuusvyöhykkeiden kesken. Käyttäjä voi valita kolmesta tasapainotustyypistä, jotka tarjoavat korkean käytettävyyden, automaattisen skaalauksen ja hyvän suojan. Kaikki tämä on tärkeää sovelluksiesi vikasietoisuuden varmistamiseksi.
Tärkeimmät edut:
- korkea saatavuus. Palvelusopimuksessa oletetaan kuormituksen tasaajan 99,99 %:n käytettävyyttä. Esimerkiksi useat saatavuusvyöhykkeet varmistavat, että liikennettä käsittelevät vain terveet kohteet. Itse asiassa voit tasapainottaa kuormitusta koko alueella ja ohjata liikennettä terveisiin kohteisiin eri käytettävyysalueilla;
- turvallisuus. ELB toimii Amazon VPC:n kanssa tarjoten erilaisia suojausominaisuuksia - integroidun sertifikaattien hallinnan, käyttäjän todennuksen ja SSL/TLS-salauksen purkamisen. Kaikki yhdessä tarjoaa keskitetyn ja joustavan TLS-asetusten hallinnan;
- joustavuus. ELB pystyy käsittelemään äkillisiä muutoksia verkkoliikenteessä. Ja syvä integraatio Auto Scalingin kanssa antaa sovellukselle riittävästi resursseja kuormituksen muuttuessa ilman manuaalista toimenpiteitä;
- joustavuus. Voit käyttää IP-osoitteita pyyntöjen reitittämiseen sovelluksiesi kohteisiin. Tämä tarjoaa joustavuutta kohdesovellusten virtualisoinnissa, mikä antaa mahdollisuuden isännöidä useita sovelluksia yhdessä esiintymässä. Koska sovellukset voivat käyttää yhtä verkkoporttia ja niillä on erilliset suojausryhmät, sovellusten välinen kommunikaatio yksinkertaistuu, kun meillä on esimerkiksi mikropalvelupohjainen arkkitehtuuri;
- seuranta ja auditointi. Voit seurata sovelluksia reaaliajassa Amazon CloudWatch -ominaisuuksien avulla. Puhumme mittareista, lokeista, pyyntöjen seurannasta. Yksinkertaisesti sanottuna pystyt tunnistamaan ongelmat ja paikantamaan suorituskyvyn pullonkaulat melko tarkasti;
- hybridi kuormituksen tasapainotus. Mahdollisuus kuormituksen tasapainottamiseen paikallisten resurssien ja AWS:n välillä käyttämällä samaa kuormitustasaajaa helpottaa paikallisten sovellusten siirtämistä tai laajentamista pilveen. Myös vikojen käsittely yksinkertaistuu pilven avulla.
Jos olet kiinnostunut yksityiskohdista, tässä on pari muuta hyödyllistä linkkiä Amazonin viralliselta verkkosivustolta:
- .
Lähde: will.com