Hei alle sammen! Kurset starter i dag , i forbindelse med dette holdt vi et tilsvarende tematisk webinar dedikert til ELB-gjennomgangen. Vi så på typene balansere og opprettet flere EC2-instanser med en balanserer. Vi har også studert andre eksempler på bruk.
, Du vil:
- forstå hva AWS Load Balancing er;
- kjenne til typene Elastic Load Balancer og dens komponenter;
- bruk AWS ELB i praksisen din.
Hvorfor trenger du å vite dette i det hele tatt?
- nyttig hvis du planlegger å ta AWS-sertifiseringseksamener;
- dette er en enkel måte å fordele belastningen mellom servere på;
- Dette er en enkel måte å legge til Lambda i tjenesten din (ALB).
Gjennomførte en åpen leksjon , systemingeniør i et markedsføringsselskap for nettstedutvikling og support.
Innledning
Hva en Elastic Load Balancer er kan sees i diagrammet nedenfor, som viser et enkelt eksempel:
Load Balancer godtar forespørsler og distribuerer dem på tvers av instanser. Vi har en separat forekomst, det er Lambda-funksjoner og det er en AutoScaling-gruppe (en gruppe servere).
AWS ELB-typer
1. La oss se på hovedtypene:
Klassisk Load Balancer. Den aller første lastbalanseren fra AWS, fungerer på både OSI Layer 4 og Layer 7, og støtter HTTP, HTTPS, TCP og SSL. Den gir grunnleggende lastbalansering på tvers av flere Amazon EC2-forekomster og fungerer både på forespørsels- og tilkoblingsnivå. La oss åpne den (uthevet i grått):
Denne balansereren anses som utdatert, så den anbefales kun å brukes i visse tilfeller. For eksempel for applikasjoner som ble bygget på EC2-Classic-nettverket. I prinsippet er det ingen som hindrer oss i å lage det:
2. Nettverksbelastningsbalanser. Egnet for store arbeidsbelastninger, opererer på OSI Layer 4 (kan brukes i EKS og ECS), TCP, UDP og TLS støttes.
Network Load Balancer ruter trafikk til mål i en Amazon VPC og er i stand til å behandle millioner av forespørsler per sekund med ultralav ventetid. I tillegg er den optimalisert for å håndtere trafikkmønstre med plutselige og skiftende belastninger.
3. Application Load Balancer. Fungerer på lag 7, har Lambda-støtte, støtter header- og stinivåregler, støtter HTTP og HTTPS.
Gir avansert forespørselsruting fokusert på å levere applikasjoner bygget på moderne arkitekturer, inkludert mikrotjenester og containere. Leder trafikk til mål i Amazon VPC basert på innholdet i forespørselen.
For mange brukere var Application Load Balancer førstevalget for å erstatte Classic Load Balancer, fordi TCP ikke er like vanlig som HTTP.
La oss lage det også, som et resultat av at vi allerede vil ha to lastbalansere:
Lastbalansekomponenter
Vanlige lastbalansekomponenter (felles for alle balansere):
- Tilgang loggingspolicy
— dine ELB-tilgangslogger. For å gjøre innstillinger, kan du gå til Beskrivelse og velge "Rediger attributter"-knappen:
Deretter spesifiserer vi S3Bucket - Amazon-objektlagring:
- Scheme
— intern eller ekstern balanserer. Poenget er om din LoadBalancer må motta eksterne adresser for å være tilgjengelig fra utsiden, eller kan det være din interne load balancer;
- Sikkerhetsgrupper
— tilgangskontroll til balanseren. I hovedsak er dette en brannmur på høyt nivå.
- subnett
— undernett i VPC-en din (og følgelig tilgjengelighetssonen). Undernett spesifiseres under opprettelsen. Hvis VPC-er er begrenset av region, er undernett begrenset av tilgjengelighetssoner. Når du oppretter en Load Balancer, er det bedre å lage den i minst to subnett (hjelper hvis det oppstår problemer med en tilgjengelighetssone);
- lyttere
- balanseringsprotokollene dine. Som nevnt tidligere, for Classic Load Balancer kan det være HTTP, HTTPS, TCP og SSL, for Network Load Balancer - TCP, UDP og TLS, for Application Load Balancer - HTTP og HTTPS.
Eksempel for klassisk belastningsbalanser:
Men i Application Load Balancer ser vi et litt annet grensesnitt og generelt en annen logikk:
Load Balancer v2-komponenter (ALB og NLB)
La oss nå se nærmere på versjon 2-balansere Application Load Balancer og Network Load Balancer. Disse balansere har sine egne komponentfunksjoner. For eksempel dukket et slikt konsept som Målgrupper opp - forekomster (og funksjoner). Takket være denne komponenten har vi mulighet til å spesifisere hvilke av Målgruppene vi ønsker å dirigere trafikk til.
Enkelt sagt, i Target Groups spesifiserer vi forekomstene hvor trafikken vil komme. Hvis du i den samme Classic Load Balancer ganske enkelt umiddelbart kobler intensiteten til balanseren, så i Application Load Balancer:
- lage en belastningsbalanser;
- opprette en målgruppe;
- direkte via de nødvendige portene eller Load Balancer-reglene til de nødvendige målgruppene;
- i Målgrupper tildeler du forekomster.
Denne driftslogikken kan virke mer komplisert, men faktisk er den mer praktisk.
Den neste komponenten er Lytterregler (regler for ruting). Dette gjelder kun for Application Load Balancer. Hvis du i Network Load Balancer ganske enkelt oppretter en lytter, og den sender trafikk til en spesifikk målgruppe, så i Application Load Balancer .
La oss nå si noen ord om den neste komponenten - Elastisk IP (statiske adresser for NLB). Hvis rutereglene for lytterregler bare påvirket applikasjonsbelastningsbalanseren, så påvirket Elastic IP bare nettverksbelastningsbalanseren.
La oss lage en nettverksbelastningsbalanser:
Og bare under opprettelsesprosessen vil vi se at vi får muligheten til å velge Elastic IP:
Elastic IP gir én enkelt IP-adresse som kan assosieres med forskjellige EC2-forekomster over tid. Hvis en EC2-forekomst har en Elastic IP-adresse og den forekomsten avsluttes eller stoppes, kan du umiddelbart knytte en ny EC2-forekomst til en Elastic IP-adresse. Din nåværende applikasjon vil imidlertid ikke slutte å fungere, siden applikasjoner fortsatt ser den samme IP-adressen, selv om den virkelige EC2 har endret seg.
Her om temaet hvorfor Elastic IP er nødvendig. Se, vi ser 3 IP-adresser, men de vil ikke bli her for alltid:
Amazon endrer dem over tid, kanskje hvert 60. sekund (men i praksis, selvfølgelig, sjeldnere). Dette betyr at IP-adresser kan endres. Og når det gjelder Network Load Balancer, kan du bare binde en IP-adresse og angi den i regler, retningslinjer osv.
Trekke konklusjoner
ELB gir automatisk distribusjon av innkommende trafikk på tvers av flere mål (containere, Amazon EC2-forekomster, IP-adresser og Lambda-funksjoner). ELB er i stand til å distribuere trafikk med varierende belastning både innenfor en enkelt tilgjengelighetssone og på tvers av flere tilgjengelighetssoner. Brukeren kan velge mellom tre typer balansere som gir høy tilgjengelighet, autoskalering og god beskyttelse. Alt dette er viktig for å sikre feiltoleransen til applikasjonene dine.
De viktigste fordelene:
- høy tilgjengelighet. Serviceavtalen forutsetter 99,99 % tilgjengelighet for lastbalanseren. For eksempel sikrer flere tilgjengelighetssoner at trafikk kun behandles av friske objekter. Faktisk kan du balansere belastningen over hele regionen, og omdirigere trafikk til sunne mål i forskjellige tilgjengelighetssoner;
- sikkerhet. ELB jobber med Amazon VPC, og tilbyr ulike sikkerhetsfunksjoner - integrert sertifikatadministrasjon, brukerautentisering og SSL/TLS-dekryptering. Alt sammen gir sentralisert og fleksibel administrasjon av TLS-innstillinger;
- elastisitet. ELB kan håndtere plutselige endringer i nettverkstrafikken. Og dyp integrasjon med Auto Scaling gir applikasjonen nok ressurser hvis belastningen endres, uten å kreve manuell intervensjon;
- fleksibilitet. Du kan bruke IP-adresser til å rute forespørsler til målene for applikasjonene dine. Dette gir fleksibilitet ved virtualisering av målapplikasjoner, og gir dermed muligheten til å være vert for flere applikasjoner på en enkelt forekomst. Siden applikasjoner kan bruke en enkelt nettverksport og har separate sikkerhetsgrupper, blir kommunikasjonen mellom applikasjoner forenklet når vi for eksempel har en mikrotjenester-basert arkitektur;
- overvåking og revisjon. Du kan overvåke applikasjoner i sanntid ved å bruke Amazon CloudWatch-funksjoner. Vi snakker om beregninger, logger, forespørselssporing. Enkelt sagt vil du være i stand til å identifisere problemer og finne ytelsesflaskehalser ganske nøyaktig;
- hybrid lastbalansering. Muligheten til å lastebalanse mellom lokale ressurser og AWS ved å bruke samme lastbalanser gjør det enkelt å migrere eller utvide lokale applikasjoner til skyen. Feilhåndtering er også forenklet ved bruk av skyen.
Hvis du er interessert i detaljer, her er et par nyttige lenker til fra det offisielle Amazon-nettstedet:
- .
Kilde: www.habr.com