Omfattningen av Amazon Web Services-nätverket är 69 zoner runt om i världen i 22 regioner: USA, Europa, Asien, Afrika och Australien. Varje zon innehåller upp till 8 datacenter – Data Processing Centers. Varje datacenter har tusentals eller hundratusentals servrar. Nätverket är utformat på ett sådant sätt att alla osannolika avbrottsscenarier beaktas. Till exempel är alla regioner isolerade från varandra, och tillgänglighetszoner är åtskilda över avstånd på flera kilometer. Även om du klipper av kabeln kommer systemet att byta till backup-kanaler, och förlusten av information kommer att uppgå till några datapaket. Vasily Pantyukhin kommer att prata om vilka andra principer nätverket bygger på och hur det är uppbyggt.
Vasily Pantyukhin började som Unix-administratör i .ru-företag, arbetade med stor Sun Microsystem-hårdvara i 6 år, predikade en datacentrerad värld på EMC i 11 år. Det utvecklades naturligt till privata moln och flyttade sedan till offentliga. Nu, som Amazon Web Services-arkitekt, ger han teknisk rådgivning för att hjälpa till att leva och utvecklas i AWS-molnet.
I den tidigare delen av AWS-trilogin grävde Vasily in i designen av fysiska servrar och databasskalning. Nitrokort, anpassad KVM-baserad hypervisor, Amazon Aurora-databas - om allt detta i materialet "" Läs för sammanhang eller titta tal.
Denna del kommer att fokusera på nätverksskalning, ett av de mest komplexa systemen i AWS. Utvecklingen från ett platt nätverk till ett virtuellt privat moln och dess design, interna tjänster från Blackfoot och HyperPlane, problemet med en bullrig granne, och i slutet - skalan på nätverket, stamnätet och fysiska kablar. Om allt detta under skärningen.
Friskrivningsklausul: allt nedan är Vasilys personliga åsikt och kanske inte sammanfaller med Amazon Web Services position.
Nätverksskalning
AWS-molnet lanserades 2006. Hans nätverk var ganska primitivt – med en platt struktur. Utbudet av privata adresser var gemensamt för alla molnhyresgäster. När du startar en ny virtuell maskin fick du av misstag en tillgänglig IP-adress från detta intervall.
Detta tillvägagångssätt var lätt att implementera, men begränsade i grunden användningen av molnet. I synnerhet var det ganska svårt att utveckla hybridlösningar som kombinerade privata nätverk på marken och i AWS. Det vanligaste problemet var överlappande IP-adressintervall.
Virtuellt privat moln
Molnet visade sig vara efterfrågat. Det är dags att tänka på skalbarhet och möjligheten att använda den av tiotals miljoner hyresgäster. Det platta nätet har blivit ett stort hinder. Därför funderade vi på hur vi skulle isolera användare från varandra på nätverksnivå så att de självständigt kunde välja IP-intervall.
Vad är det första du tänker på när du tänker på nätverksisolering? Säkert VLAN и VRF - Virtuell routing och vidarebefordran.
Tyvärr fungerade det inte. VLAN ID är bara 12 bitar, vilket ger oss endast 4096 isolerade segment. Även de största switcharna kan använda maximalt 1-2 tusen VRF:er. Att använda VRF och VLAN tillsammans ger oss bara några miljoner subnät. Detta är definitivt inte tillräckligt för tiotals miljoner hyresgäster, som var och en måste kunna använda flera subnät.
Vi har helt enkelt inte råd att köpa det antal stora lådor som krävs, till exempel från Cisco eller Juniper. Det finns två anledningar: det är galet dyrt, och vi vill inte vara utlämnade till deras utvecklings- och lappningspolitik.
Det finns bara en slutsats - gör din egen lösning.
2009 meddelade vi VPC - Virtuellt privat moln. Namnet fastnade och nu använder många molnleverantörer det också.
VPC är ett virtuellt nätverk SDN (Programvarudefinierat nätverk). Vi bestämde oss för att inte uppfinna speciella protokoll på L2- och L3-nivåerna. Nätverket körs på standard Ethernet och IP. För överföring över nätverket är virtuell maskintrafik inkapslad i vårt eget protokollomslag. Den anger det ID som tillhör hyresgästens VPC.
Låter enkelt. Det finns dock flera allvarliga tekniska utmaningar som måste övervinnas. Till exempel var och hur man lagrar data om kartläggning av virtuella MAC/IP-adresser, VPC-ID och motsvarande fysiska MAC/IP. I AWS-skala är detta en enorm tabell som borde fungera med minimala åtkomstfördröjningar. Ansvarig för detta karttjänst, som sprids i ett tunt lager i hela nätverket.
I nya generationens maskiner utförs inkapsling av Nitro-kort på hårdvarunivå. I äldre fall är inkapsling och dekapsling mjukvarubaserad.
Låt oss ta reda på hur det fungerar i allmänna termer. Låt oss börja med L2-nivån. Låt oss anta att vi har en virtuell maskin med IP 10.0.0.2 på en fysisk server 192.168.0.3. Den skickar data till virtuell maskin 10.0.0.3, som lever på 192.168.1.4. En ARP-förfrågan genereras och skickas till nätverkets Nitro-kort. För enkelhetens skull antar vi att båda virtuella maskinerna lever i samma "blå" VPC.
Kartan ersätter källadressen med sin egen och vidarebefordrar ARP-ramen till karttjänsten.
Karttjänsten returnerar information som är nödvändig för överföring över det fysiska L2-nätverket.
Nitrokortet i ARP-svaret ersätter MAC på det fysiska nätverket med en adress i VPC.
Vid överföring av data lindar vi logisk MAC och IP i ett VPC-omslag. Vi överför allt detta över det fysiska nätverket med hjälp av lämpliga käll- och destinations-IP Nitro-kort.
Den fysiska maskin som paketet är avsett till utför kontrollen. Detta är nödvändigt för att förhindra möjligheten till adresspoofing. Maskinen skickar en särskild förfrågan till karttjänsten och frågar: ”Från fysisk maskin 192.168.0.3 fick jag ett paket som är avsett för 10.0.0.3 i den blå VPC:n. Är han legitim?
Karttjänsten kontrollerar sin resursallokeringstabell och tillåter eller nekar paketet att passera. I alla nya fall är ytterligare validering inbäddad i Nitro-kort. Det är omöjligt att kringgå det ens teoretiskt. Därför kommer spoofing till resurser i en annan VPC inte att fungera.
Därefter skickas data till den virtuella maskin som den är avsedd för.
Karttjänsten fungerar även som en logisk router för överföring av data mellan virtuella maskiner i olika subnät. Allt är konceptuellt enkelt, jag kommer inte att gå in på detaljer.
Det visar sig att vid överföring av varje paket vänder sig servrarna till karttjänsten. Hur hanterar man oundvikliga förseningar? Cachning, självklart.
Det fina är att du inte behöver cacha hela det enorma bordet. En fysisk server är värd för virtuella maskiner från ett relativt litet antal VPC:er. Du behöver bara cacha information om dessa VPC:er. Att överföra data till andra VPC:er i "standard"-konfigurationen är fortfarande inte legitimt. Om funktionalitet som VPC-peering används, så laddas dessutom information om motsvarande VPC in i cachen.
Vi ordnade överföringen av data till VPC.
Blackfoot
Vad ska man göra i de fall trafik behöver överföras utanför, till exempel till Internet eller via VPN till marken? Hjälper oss här Blackfoot - intern AWS-tjänst. Den är utvecklad av vårt sydafrikanska team. Det är därför tjänsten är uppkallad efter en pingvin som bor i Sydafrika.
Blackfoot dekapslar trafik och gör vad som behövs med den. Data skickas till Internet som de är.
Data dekapseras och omlindas i IPsec när du använder ett VPN.
När du använder Direct Connect taggas trafik och skickas till lämpligt VLAN.
HyperPlane
Detta är en intern flödeskontrolltjänst. Många nätverkstjänster kräver övervakning dataflödestillstånd. Till exempel när NAT används måste flödeskontroll säkerställa att varje IP:destinationsportpar har en unik utgående port. När det gäller en balanserare NLB - Network Load Balancer, bör dataflödet alltid riktas till samma virtuella målmaskin. Security Groups är en stateful brandvägg. Den övervakar inkommande trafik och öppnar implicit portar för utgående paketflöde.
I AWS-molnet är kraven på överföringslatens extremt höga. Det är därför HyperPlane avgörande för hela nätverkets prestanda.
Hyperplane är byggt på virtuella EC2-maskiner. Det finns ingen magi här, bara list. Tricket är att det här är virtuella maskiner med stort RAM-minne. Operationer är transaktionella och utförs uteslutande i minnet. Detta gör att du kan uppnå förseningar på endast tiotals mikrosekunder. Att arbeta med disken skulle döda all produktivitet.
Hyperplane är ett distribuerat system av ett stort antal sådana EC2-maskiner. Varje virtuell maskin har en bandbredd på 5 GB/s. Över hela det regionala nätverket ger detta otroliga terabitar av bandbredd och tillåter bearbetning miljontals anslutningar per sekund.
HyperPlane fungerar bara med strömmar. VPC-paketinkapsling är helt transparent för det. En potentiell sårbarhet i denna interna tjänst skulle fortfarande förhindra att VPC-isoleringen bryts. Nivåerna nedan ansvarar för säkerheten.
Bullrig granne
Det finns fortfarande ett problem bullrig granne - bullrig granne. Låt oss anta att vi har 8 noder. Dessa noder bearbetar alla molnanvändares flöden. Allt verkar vara bra och belastningen bör vara jämnt fördelad över alla noder. Noder är mycket kraftfulla och det är svårt att överbelasta dem.
Men vi bygger vår arkitektur utifrån även osannolika scenarier.
Låg sannolikhet betyder inte omöjligt.
Vi kan föreställa oss en situation där en eller flera användare skulle generera för mycket belastning. Alla HyperPlane-noder är involverade i att bearbeta denna belastning och andra användare kan potentiellt uppleva någon form av prestandaträff. Detta bryter mot konceptet med molnet, där hyresgäster inte har någon möjlighet att påverka varandra.
Hur löser man problemet med en bullrig granne? Det första som kommer att tänka på är skärning. Våra 8 noder är logiskt uppdelade i 4 skärvor med 2 noder vardera. Nu kommer en bullrig granne bara att störa en fjärdedel av alla användare, men det kommer att störa dem mycket.
Låt oss göra saker annorlunda. Vi kommer att tilldela endast 3 noder till varje användare.
Tricket är att slumpmässigt tilldela noder till olika användare. På bilden nedan skär den blå användaren noder med en av de andra två användarna - grön och orange.
Med 8 noder och 3 användare är sannolikheten för att en bullrig granne korsar en av användarna 54 %. Det är med denna sannolikhet som en blå användare kommer att påverka andra hyresgäster. Samtidigt, bara en del av sin last. I vårt exempel kommer denna påverkan åtminstone på något sätt inte att vara märkbar för alla, utan för endast en tredjedel av alla användare. Detta är redan ett bra resultat.
Antal användare som kommer att korsa varandra
Sannolikhet i procent
0
18%
1
54%
2
26%
3
2%
Låt oss föra situationen närmare verkligheten - låt oss ta 100 noder och 5 användare på 5 noder. I det här fallet kommer ingen av noderna att skära varandra med en sannolikhet på 77%.
Antal användare som kommer att korsa varandra
Sannolikhet i procent
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
I en verklig situation, med ett stort antal HyperPlane-noder och användare, är den potentiella påverkan av en bullrig granne på andra användare minimal. Denna metod kallas blandning av skärning - blanda skärvning. Det minimerar den negativa effekten av nodfel.
Många tjänster är byggda på basis av HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Nätverksskala
Låt oss nu prata om omfattningen av själva nätverket. För oktober 2019 erbjuder AWS sina tjänster i 22 regioner, och 9 till är planerade.
- Varje region innehåller flera tillgänglighetszoner. Det finns 69 av dem runt om i världen.
- Varje A-Ö består av databehandlingscenter. Det finns inte fler än 8 av dem totalt.
- Datacentret rymmer ett stort antal servrar, några med upp till 300 000.
Låt oss nu ta ett genomsnitt av allt detta, multiplicera och få en imponerande siffra som återspeglar Amazon molnskala.
Det finns många optiska länkar mellan Availability Zones och datacentret. I en av våra största regioner har 388 kanaler lagts bara för AZ-kommunikation mellan varandra och kommunikationscentra med andra regioner (Transit Centers). Totalt ger detta galet 5000 Tbit.
Backbone AWS är byggd specifikt för och optimerad för molnet. Vi bygger det på kanalerna 100 GB/s. Vi kontrollerar dem helt, med undantag för regioner i Kina. Trafiken delas inte med andra företags laster.
Naturligtvis är vi inte den enda molnleverantören med ett privat stamnät. Fler och fler stora företag går denna väg. Detta bekräftas av oberoende forskare, till exempel från .
Grafen visar att andelen innehållsleverantörer och molnleverantörer växer. På grund av detta minskar andelen internettrafik från stamnätsleverantörer ständigt.
Jag ska förklara varför detta händer. Tidigare var de flesta webbtjänster tillgängliga och konsumerade direkt från Internet. Numera finns fler och fler servrar i molnet och är tillgängliga via CDN - Innehållsfördelningsnätverk. För att komma åt en resurs går användaren via Internet endast till närmaste CDN PoP - Punkt av närvaro. Oftast är det någonstans i närheten. Sedan lämnar den det offentliga Internet och flyger genom en privat ryggrad över till exempel Atlanten och kommer direkt till resursen.
Jag undrar hur internet kommer att förändras om 10 år om denna trend fortsätter?
Fysiska kanaler
Forskare har ännu inte räknat ut hur man kan öka ljusets hastighet i universum, men de har gjort stora framsteg i metoder för att överföra det genom optisk fiber. Vi använder för närvarande 6912 fiberkablar. Detta hjälper till att avsevärt optimera kostnaden för deras installation.
I vissa regioner måste vi använda speciella kablar. Till exempel i Sydney-regionen använder vi kablar med en speciell beläggning mot termiter.
Ingen är immun från problem och ibland skadas våra kanaler. Bilden till höger visar optiska kablar i en av de amerikanska regionerna som slets av byggnadsarbetare. Till följd av olyckan gick endast 13 datapaket förlorade, vilket är förvånande. Än en gång - bara 13! Systemet bytte bokstavligen omedelbart till reservkanaler - vågen fungerar.
Vi galopperade genom några av Amazons molntjänster och teknologier. Jag hoppas att du åtminstone har en uppfattning om omfattningen av de uppgifter som våra ingenjörer måste lösa. Personligen tycker jag att detta är väldigt spännande.
Detta är den sista delen av trilogin från Vasily Pantyukhin om AWS-enheten. I delar beskriver serveroptimering och databasskalning, och i — Serverlösa funktioner och Firecracker.
På i november kommer Vasily Pantyukhin att dela med sig av nya detaljer om Amazon-enheten. han om orsakerna till fel och designen av distribuerade system hos Amazon. 24 oktober är fortfarande möjligt biljett till ett bra pris och betala senare. Vi väntar på dig på HighLoad++, kom och låt oss chatta!
Källa: will.com