Hej alla! Kursen startar idag , i samband med vilket vi höll ett motsvarande tematiskt webbseminarium tillägnat ELB-granskningen. Vi tittade på typerna av balanserare och skapade flera EC2-instanser med en balanserare. Vi studerade även andra exempel på användning.
, Du kommer:
- förstå vad AWS Load Balancing är;
- känna till typerna av Elastic Load Balancer och dess komponenter;
- använd AWS ELB i din praktik.
Varför behöver du veta detta överhuvudtaget?
- användbart om du planerar att ta AWS-certifieringsprov;
- detta är ett enkelt sätt att fördela belastningen mellan servrar;
- Detta är ett enkelt sätt att lägga till Lambda till din tjänst (ALB).
Genomförde en öppen lektion , systemingenjör på ett marknadsföringsföretag för webbutveckling och support.
Inledning
Vad en Elastic Load Balancer är kan ses i diagrammet nedan, som visar ett enkelt exempel:
Load Balancer accepterar förfrågningar och distribuerar dem över instanser. Vi har en separat instans, det finns Lambda-funktioner och det finns en AutoScaling-grupp (en grupp servrar).
AWS ELB-typer
1. Låt oss titta på huvudtyperna:
Klassisk lastbalanserare. Den allra första lastbalanseraren från AWS, fungerar på både OSI Layer 4 och Layer 7, och stöder HTTP, HTTPS, TCP och SSL. Det ger grundläggande belastningsbalansering över flera Amazon EC2-instanser och fungerar på både begäran och anslutningsnivåer. Låt oss öppna den (markerad i grått):
Denna balanserare anses vara föråldrad, så den rekommenderas endast för användning i vissa fall. Till exempel för applikationer som byggdes på nätverket EC2-Classic. I princip är det ingen som hindrar oss från att skapa det:
2. Network Load Balancer. Lämplig för tunga arbetsbelastningar, fungerar på OSI Layer 4 (kan användas i EKS och ECS), TCP, UDP och TLS stöds.
Network Load Balancer dirigerar trafik till mål i en Amazon VPC och kan behandla miljontals förfrågningar per sekund med ultralåg latens. Dessutom är den optimerad för att hantera trafikmönster med plötsliga och växlande belastningar.
3. Application Load Balancer. Fungerar på lager 7, har Lambda-stöd, stöder rubrik- och sökvägsnivåregler, stöder HTTP och HTTPS.
Ger avancerad förfrågningsdirigering fokuserad på att leverera applikationer byggda på moderna arkitekturer, inklusive mikrotjänster och behållare. Dirigerar trafik till mål i Amazon VPC baserat på innehållet i begäran.
För många användare var Application Load Balancer det första valet att ersätta Classic Load Balancer, eftersom TCP inte är lika vanligt som HTTP.
Låt oss skapa det också, som ett resultat av vilket vi redan kommer att ha två lastbalanserare:
Lastbalanskomponenter
Vanliga lastbalanskomponenter (gemensamt för alla balansörer):
- Åtkomst till loggningspolicy
— dina ELB-åtkomstloggar. För att göra inställningar kan du gå till Beskrivning och välja knappen "Redigera attribut":
Sedan anger vi S3Bucket - Amazon-objektlagring:
- Schema
— intern eller extern balanserare. Poängen är om din LoadBalancer måste ta emot externa adresser för att vara åtkomlig utifrån, eller kan det vara din interna lastbalanserare;
- Säkerhetsgrupper
— åtkomstkontroll till balanseraren. Detta är i huvudsak en brandvägg på hög nivå.
- Undernät
— undernät i din VPC (och, följaktligen, tillgänglighetszon). Undernät specificeras under skapandet. Om VPC:er är begränsade av region, är subnät begränsade av tillgänglighetszoner. När du skapar en lastbalanserare är det bättre att skapa den i minst två undernät (hjälper om problem uppstår med en tillgänglighetszon);
- lyssnare
— dina balanseringsprotokoll. Som tidigare nämnts, för Classic Load Balancer kan det vara HTTP, HTTPS, TCP och SSL, för Network Load Balancer - TCP, UDP och TLS, för Application Load Balancer - HTTP och HTTPS.
Exempel på klassisk lastbalanserare:
Men i Application Load Balancer ser vi ett lite annorlunda gränssnitt och generellt annorlunda logik:
Load Balancer v2-komponenter (ALB och NLB)
Låt oss nu titta närmare på version 2-balanserare Application Load Balancer och Network Load Balancer. Dessa balanserare har sina egna komponentegenskaper. Till exempel dök ett sådant koncept som Målgrupper upp - instanser (och funktioner). Tack vare denna komponent har vi möjlighet att specificera vilken av Målgrupperna vi vill dirigera trafik till.
Enkelt uttryckt, i Målgrupper anger vi de fall där trafiken kommer att komma. Om du i samma Classic Load Balancer helt enkelt omedelbart kopplar intensiteten till balancern, då i Application Load Balancer:
- skapa en lastbalanserare;
- skapa en målgrupp;
- direkt via de nödvändiga portarna eller Load Balancer-reglerna till de erforderliga målgrupperna;
- i Målgrupper tilldelar du instanser.
Denna driftlogik kan tyckas mer komplicerad, men i själva verket är den bekvämare.
Nästa komponent är Lyssnaren regler (regler för routing). Detta gäller endast Application Load Balancer. Om du i Network Load Balancer helt enkelt skapar en Listener, och den skickar trafik till en specifik målgrupp, då i Application Load Balancer .
Låt oss nu säga några ord om nästa komponent - Elastisk IP (statiska adresser för NLB). Om routingreglerna för Listener-reglerna endast påverkade Application Load Balancer, så påverkade Elastic IP endast Network Load Balancer.
Låt oss skapa en Network Load Balancer:
Och just under skapelseprocessen kommer vi att se att vi ges möjlighet att välja Elastic IP:
Elastic IP tillhandahåller en enda IP-adress som kan associeras med olika EC2-instanser över tid. Om en EC2-instans har en Elastic IP-adress och den instansen avslutas eller stoppas, kan du omedelbart associera en ny EC2-instans med en Elastic IP-adress. Din nuvarande applikation kommer dock inte att sluta fungera, eftersom applikationer fortfarande ser samma IP-adress, även om den verkliga EC2 har ändrats.
Här på ämnet varför Elastic IP behövs. Titta, vi ser tre IP-adresser, men de kommer inte att stanna här för alltid:
Amazon ändrar dem med tiden, kanske var 60:e sekund (men i praktiken, naturligtvis, mer sällan). Detta innebär att IP-adresser kan ändras. Och i fallet med Network Load Balancer kan du bara binda en IP-adress och ange den i dina regler, policyer etc.
Rita slutsatser
ELB tillhandahåller automatisk distribution av inkommande trafik över flera mål (containrar, Amazon EC2-instanser, IP-adresser och Lambda-funktioner). ELB kan distribuera trafik med varierande belastning både inom en enskild tillgänglighetszon och över flera tillgänglighetszoner. Användaren kan välja mellan tre typer av balanserare som ger hög tillgänglighet, autoskalning och bra skydd. Allt detta är viktigt för att säkerställa feltoleransen för dina applikationer.
De viktigaste fördelarna:
- hög tillgänglighet. Serviceavtalet förutsätter 99,99 % tillgänglighet för lastbalanseraren. Till exempel säkerställer flera tillgänglighetszoner att trafik endast bearbetas av friska objekt. Faktum är att du kan balansera belastningen över hela regionen och omdirigera trafik till sunda mål i olika tillgänglighetszoner;
- säkerhet. ELB arbetar med Amazon VPC och tillhandahåller olika säkerhetsfunktioner - integrerad certifikathantering, användarautentisering och SSL/TLS-dekryptering. Allt tillsammans ger centraliserad och flexibel hantering av TLS-inställningar;
- elasticitet. ELB kan hantera plötsliga förändringar i nätverkstrafiken. Och djup integration med Auto Scaling ger applikationen tillräckligt med resurser om belastningen ändras, utan att kräva manuellt ingripande;
- flexibilitet. Du kan använda IP-adresser för att dirigera förfrågningar till målen för dina applikationer. Detta ger flexibilitet vid virtualisering av målapplikationer, vilket ger möjligheten att vara värd för flera applikationer på en enda instans. Eftersom applikationer kan använda en enda nätverksport och har separata säkerhetsgrupper, förenklas kommunikationen mellan applikationer när vi har, säg, en mikrotjänstbaserad arkitektur;
- övervakning och revision. Du kan övervaka applikationer i realtid med Amazon CloudWatch-funktioner. Vi pratar om mätvärden, loggar, spårning av förfrågningar. Enkelt uttryckt kommer du att kunna identifiera problem och lokalisera prestandaflaskhalsar ganska exakt;
- hybrid lastbalansering. Möjligheten att lastbalans mellan lokala resurser och AWS med samma lastbalanserare gör det enkelt att migrera eller expandera lokala applikationer till molnet. Även felhanteringen förenklas med hjälp av molnet.
Om du är intresserad av detaljer, här är ytterligare ett par användbara länkar från den officiella Amazon-webbplatsen:
- .
Källa: will.com