Hej alle! Kurset starter i dag , i forbindelse med hvilket vi afholdt et tilsvarende tematisk webinar dedikeret til ELB-gennemgangen. Vi så på typerne af balancerer og oprettede flere EC2-instanser med en balancer. Vi undersøgte også andre eksempler på brug.
, Du vil:
- forstå, hvad AWS Load Balancing er;
- kender typerne af Elastic Load Balancer og dens komponenter;
- bruge AWS ELB i din praksis.
Hvorfor skal du overhovedet vide dette?
- nyttigt, hvis du planlægger at tage AWS-certificeringseksamener;
- dette er en enkel måde at fordele belastningen mellem servere;
- Dette er en enkel måde at tilføje Lambda til din tjeneste (ALB).
Afholdt en åben lektion , systemingeniør hos et marketingfirma til udvikling og support af websteder.
Indledning
Hvad en Elastic Load Balancer er, kan ses i diagrammet nedenfor, som viser et simpelt eksempel:
Load Balancer accepterer anmodninger og distribuerer dem på tværs af instanser. Vi har en separat instans, der er Lambda-funktioner, og der er en AutoScaling-gruppe (en gruppe af servere).
AWS ELB typer
1. Lad os se på hovedtyperne:
Klassisk Load Balancer. Den allerførste load balancer fra AWS fungerer på både OSI Layer 4 og Layer 7 og understøtter HTTP, HTTPS, TCP og SSL. Det giver grundlæggende belastningsbalancering på tværs af flere Amazon EC2-instanser og fungerer på både anmodnings- og forbindelsesniveauet. Lad os åbne det (fremhævet med gråt):
Denne balancer anses for at være forældet, så den anbefales kun til brug i visse tilfælde. For eksempel til applikationer, der er bygget på EC2-Classic-netværket. I princippet er der ingen, der forhindrer os i at skabe det:
2. Network Load Balancer. Velegnet til tunge arbejdsbelastninger, fungerer på OSI Layer 4 (kan bruges i EKS og ECS), TCP, UDP og TLS understøttes.
Network Load Balancer dirigerer trafik til mål i en Amazon VPC og er i stand til at behandle millioner af anmodninger i sekundet med ultralav latenstid. Derudover er den optimeret til at håndtere trafikmønstre med pludselige og skiftende belastninger.
3. Application Load Balancer. Fungerer på lag 7, har Lambda-understøttelse, understøtter header- og stiniveauregler, understøtter HTTP og HTTPS.
Giver avanceret anmodningsrouting med fokus på at levere applikationer bygget på moderne arkitekturer, herunder mikrotjenester og containere. Leder trafik til mål i Amazon VPC baseret på indholdet af anmodningen.
For mange brugere var Application Load Balancer det første valg til at erstatte Classic Load Balancer, fordi TCP ikke er så almindeligt som HTTP.
Lad os også skabe det, som et resultat af hvilket vi allerede vil have to belastningsbalancere:
Belastningsbalancekomponenter
Fælles belastningsbalancekomponenter (fælles for alle balancere):
- Adgang til logningspolitik
— dine ELB-adgangslogfiler. For at foretage indstillinger kan du gå til Beskrivelse og vælge knappen "Rediger attributter":
Så specificerer vi S3Bucket - Amazon-objektlagring:
- Scheme
— intern eller ekstern balancer. Pointen er, om din LoadBalancer skal modtage eksterne adresser for at være tilgængelig udefra, eller kan det være din interne load balancer;
- Sikkerhedsgrupper
— adgangskontrol til balanceren. Grundlæggende er dette en firewall på højt niveau.
- Undernet
— undernet i din VPC (og følgelig tilgængelighedszone). Undernet er angivet under oprettelsen. Hvis VPC'er er begrænset af region, så er undernet begrænset af tilgængelighedszoner. Når du opretter en Load Balancer, er det bedre at oprette den i mindst to undernet (hjælper, hvis der opstår problemer med en tilgængelighedszone);
- lyttere
- dine balancer-protokoller. Som tidligere nævnt kan det for Classic Load Balancer være HTTP, HTTPS, TCP og SSL, for Network Load Balancer - TCP, UDP og TLS, for Application Load Balancer - HTTP og HTTPS.
Eksempel på Classic Load Balancer:
Men i Application Load Balancer ser vi en lidt anden grænseflade og generelt en anden logik:
Load Balancer v2 komponenter (ALB og NLB)
Lad os nu se nærmere på version 2 balancere Application Load Balancer og Network Load Balancer. Disse balancere har deres egne komponentfunktioner. For eksempel dukkede et sådant koncept som Målgrupper op - instanser (og funktioner). Takket være denne komponent har vi mulighed for at specificere, hvilken af Målgrupperne vi ønsker at dirigere trafik til.
Enkelt sagt angiver vi i Target Groups de tilfælde, hvor trafikken kommer. Hvis du i den samme Classic Load Balancer simpelthen straks forbinder intensiteten til balanceren, så i Application Load Balancer skal du først:
- oprette en Load Balancer;
- oprette en Målgruppe;
- direkte via de påkrævede porte eller Load Balancer-regler til de påkrævede målgrupper;
- i Målgrupper tildeler du forekomster.
Denne driftslogik kan virke mere kompliceret, men faktisk er den mere praktisk.
Den næste komponent er Lytterregler (regler for ruteføring). Dette gælder kun for Application Load Balancer. Hvis du i Network Load Balancer blot opretter en Listener, og den sender trafik til en bestemt målgruppe, så er alt i Application Load Balancer .
Lad os nu sige et par ord om den næste komponent - Elastisk IP (statiske adresser for NLB). Hvis routingreglerne Listener-reglerne kun påvirkede Application Load Balancer, så vedrørte Elastic IP kun Network Load Balancer.
Lad os oprette en Network Load Balancer:
Og lige under oprettelsesprocessen vil vi se, at vi får mulighed for at vælge Elastic IP:
Elastic IP giver en enkelt IP-adresse, der kan associeres med forskellige EC2-instanser over tid. Hvis en EC2-instans har en Elastic IP-adresse, og den instans er afsluttet eller stoppet, kan du straks knytte en ny EC2-instans til en Elastic IP-adresse. Din nuværende applikation vil dog ikke holde op med at fungere, da applikationer stadig ser den samme IP-adresse, selvom den rigtige EC2 er ændret.
her om emnet, hvorfor Elastic IP er nødvendig. Se, vi ser 3 IP-adresser, men de vil ikke blive her for evigt:
Amazon ændrer dem over tid, måske hvert 60. sekund (men i praksis selvfølgelig sjældnere). Det betyder, at IP-adresser kan ændre sig. Og i tilfælde af Network Load Balancer kan du bare binde en IP-adresse og angive den i dine regler, politikker osv.
Drage konklusioner
ELB giver automatisk distribution af indgående trafik på tværs af flere mål (containere, Amazon EC2-instanser, IP-adresser og Lambda-funktioner). ELB er i stand til at distribuere trafik med varierende belastning både inden for en enkelt tilgængelighedszone og på tværs af flere tilgængelighedszoner. Brugeren kan vælge mellem tre typer balancere, der giver høj tilgængelighed, autoskalering og god beskyttelse. Alt dette er vigtigt for at sikre fejltolerancen for dine applikationer.
De vigtigste fordele:
- høj tilgængelighed. Serviceaftalen forudsætter 99,99 % tilgængelighed for load balanceren. For eksempel sikrer flere tilgængelighedszoner, at trafik kun behandles af sunde objekter. Faktisk kan du afbalancere belastningen på tværs af hele regionen og omdirigere trafikken til sunde mål i forskellige tilgængelighedszoner;
- sikkerhed. ELB arbejder sammen med Amazon VPC og leverer forskellige sikkerhedsfunktioner - integreret certifikatstyring, brugergodkendelse og SSL/TLS-dekryptering. Alt sammen giver centraliseret og fleksibel styring af TLS-indstillinger;
- elasticitet. ELB kan håndtere pludselige ændringer i netværkstrafikken. Og dyb integration med automatisk skalering giver applikationen nok ressourcer, hvis belastningen ændres, uden at det kræver manuel indgriben;
- fleksibilitet. Du kan bruge IP-adresser til at dirigere anmodninger til målene for dine applikationer. Dette giver fleksibilitet ved virtualisering af målapplikationer, hvilket giver mulighed for at være vært for flere applikationer på en enkelt instans. Da applikationer kan bruge en enkelt netværksport og har separate sikkerhedsgrupper, forenkles kommunikationen mellem applikationer, når vi f.eks. har en mikroservice-baseret arkitektur;
- overvågning og revision. Du kan overvåge applikationer i realtid ved hjælp af Amazon CloudWatch-funktioner. Vi taler om metrics, logs, anmodningssporing. Enkelt sagt vil du være i stand til at identificere problemer og lokalisere ydeevneflaskehalse ret præcist;
- hybrid belastningsbalancering. Evnen til at load balance mellem lokale ressourcer og AWS ved hjælp af den samme load balancer gør det nemt at migrere eller udvide lokale applikationer til skyen. Fejlhåndtering er også forenklet ved hjælp af skyen.
Hvis du er interesseret i detaljer, her er et par flere nyttige links fra det officielle Amazon-websted:
- .
Kilde: www.habr.com