De omvang van het Amazon Web Services-netwerk bedraagt 69 zones over de hele wereld in 22 regio's: de VS, Europa, Azië, Afrika en Australië. Elke zone bevat maximaal 8 datacenters - Data Processing Centers. Elk datacenter beschikt over duizenden of honderdduizenden servers. Het netwerk is zo ingericht dat er rekening gehouden wordt met alle onwaarschijnlijke uitvalscenario’s. Zo zijn alle regio’s van elkaar geïsoleerd en zijn bereikbaarheidszones over afstanden van meerdere kilometers gescheiden. Zelfs als u de kabel doorknipt, schakelt het systeem over naar back-upkanalen en zal het verlies aan informatie slechts enkele datapakketten bedragen. Vasily Pantyukhin zal vertellen op welke andere principes het netwerk is gebouwd en hoe het is gestructureerd.
Vasili Pantjoechin begon als Unix-beheerder bij .ru-bedrijven, werkte zes jaar aan grote Sun Microsystem-hardware en predikte elf jaar lang een datacentrische wereld bij EMC. Het evolueerde op natuurlijke wijze naar private clouds en verhuisde vervolgens naar publieke clouds. Nu geeft hij als Amazon Web Services-architect technisch advies om te helpen leven en ontwikkelen in de AWS-cloud.
In het vorige deel van de AWS-trilogie verdiepte Vasily zich in het ontwerp van fysieke servers en het schalen van databases. Nitro-kaarten, aangepaste KVM-gebaseerde hypervisor, Amazon Aurora-database - hierover alles in het materiaal "" Lees voor context of kijk toespraken.
Dit deel zal zich richten op netwerkschaling, een van de meest complexe systemen in AWS. De evolutie van een plat netwerk naar een Virtual Private Cloud en het ontwerp ervan, de interne diensten van Blackfoot en HyperPlane, het probleem van een luidruchtige buurman, en uiteindelijk de schaal van het netwerk, de backbone en fysieke kabels. Over dit alles onder de snit.
Disclaimer: alles hieronder is de persoonlijke mening van Vasily en valt mogelijk niet samen met het standpunt van Amazon Web Services.
Netwerkschaling
De AWS-cloud werd in 2006 gelanceerd. Zijn netwerk was vrij primitief – met een platte structuur. Het bereik aan privéadressen was gemeenschappelijk voor alle cloudtenants. Bij het starten van een nieuwe virtuele machine heeft u per ongeluk een beschikbaar IP-adres uit dit bereik ontvangen.
Deze aanpak was eenvoudig te implementeren, maar beperkte het gebruik van de cloud fundamenteel. Het was met name vrij moeilijk om hybride oplossingen te ontwikkelen die particuliere netwerken op de grond en in AWS combineerden. Het meest voorkomende probleem was overlappende IP-adresbereiken.
Virtuele privécloud
Er bleek veel vraag naar de cloud. Het is tijd om na te denken over schaalbaarheid en de mogelijkheid van gebruik ervan door tientallen miljoenen huurders. Het platte netwerk is een groot obstakel geworden. Daarom hebben we erover nagedacht hoe we gebruikers op netwerkniveau van elkaar kunnen isoleren, zodat ze onafhankelijk IP-bereiken kunnen kiezen.
Wat is het eerste dat in je opkomt als je denkt aan netwerkisolatie? Zeker VLAN и VRF - Virtuele routering en doorsturen.
Helaas werkte het niet. VLAN ID is slechts 12 bits, wat ons slechts 4096 geïsoleerde segmenten oplevert. Zelfs de grootste switches kunnen maximaal 1-2 VRF's gebruiken. Door VRF en VLAN samen te gebruiken, hebben we slechts een paar miljoen subnetten. Dit is zeker niet genoeg voor tientallen miljoenen tenants, die elk meerdere subnetten moeten kunnen gebruiken.
We kunnen het ons ook eenvoudigweg niet veroorloven om het benodigde aantal grote dozen te kopen, bijvoorbeeld bij Cisco of Juniper. Er zijn twee redenen: het is waanzinnig duur en we willen niet overgeleverd zijn aan hun ontwikkelings- en patchingbeleid.
Er is maar één conclusie: maak je eigen oplossing.
In 2009 hebben wij dit aangekondigd VPC - Virtuele privécloud. De naam bleef hangen en inmiddels gebruiken ook veel cloudproviders hem.
VPC is een virtueel netwerk SDN (Softwaregedefinieerd netwerk). We hebben besloten geen speciale protocollen uit te vinden op L2- en L3-niveau. Het netwerk draait op standaard Ethernet en IP. Voor transmissie via het netwerk wordt het verkeer van virtuele machines ingekapseld in onze eigen protocolwrapper. Het geeft de ID aan die bij de VPC van de huurder hoort.
Klinkt eenvoudig. Er zijn echter verschillende ernstige technische uitdagingen die moeten worden overwonnen. Bijvoorbeeld waar en hoe gegevens moeten worden opgeslagen over het in kaart brengen van virtuele MAC/IP-adressen, VPC-ID en bijbehorende fysieke MAC/IP. Op AWS-schaal is dit een enorme tafel die zou moeten werken met minimale toegangsvertragingen. Verantwoordelijk hiervoor kaartdienst, dat in een dunne laag door het netwerk wordt verspreid.
In machines van de nieuwe generatie wordt de inkapseling uitgevoerd door Nitro-kaarten op hardwareniveau. In oudere gevallen zijn inkapseling en decapsulatie softwaregebaseerd.
Laten we eens kijken hoe het in algemene termen werkt. Laten we beginnen met het L2-niveau. Laten we aannemen dat we een virtuele machine met IP 10.0.0.2 hebben op een fysieke server 192.168.0.3. Het verzendt gegevens naar virtuele machine 10.0.0.3, die zich op 192.168.1.4 bevindt. Er wordt een ARP-verzoek gegenereerd en naar de Nitro-netwerkkaart verzonden. Voor de eenvoud gaan we ervan uit dat beide virtuele machines in dezelfde “blauwe” VPC leven.
De kaart vervangt het bronadres door zijn eigen adres en stuurt het ARP-frame door naar de kaartservice.
De mappingservice retourneert informatie die nodig is voor verzending via het fysieke L2-netwerk.
De Nitro-kaart in het ARP-antwoord vervangt de MAC op het fysieke netwerk door een adres in de VPC.
Bij de gegevensoverdracht verpakken we logische MAC en IP in een VPC-wrapper. We verzenden dit allemaal via het fysieke netwerk met behulp van de juiste bron- en bestemmings-IP Nitro-kaarten.
De fysieke machine waarvoor het pakket bestemd is, voert de controle uit. Dit is nodig om de mogelijkheid van adresspoofing te voorkomen. De machine stuurt een speciaal verzoek naar de mappingservice en vraagt: “Van fysieke machine 192.168.0.3 heb ik een pakket ontvangen dat bedoeld is voor 10.0.0.3 in de blauwe VPC. Is hij legitiem?
De mappingservice controleert de resourcetoewijzingstabel en staat toe of weigert het pakket door te laten. In alle nieuwe gevallen is extra validatie ingebed in Nitro-kaarten. Het is onmogelijk om het zelfs theoretisch te omzeilen. Daarom zal spoofing naar bronnen in een andere VPC niet werken.
Vervolgens worden de gegevens verzonden naar de virtuele machine waarvoor ze bedoeld zijn.
De mappingservice werkt ook als een logische router voor het overbrengen van gegevens tussen virtuele machines in verschillende subnetten. Alles is conceptueel eenvoudig, ik zal niet in detail treden.
Het blijkt dat de servers bij het verzenden van elk pakket zich tot de mappingservice wenden. Hoe om te gaan met onvermijdelijke vertragingen? Caching, natuurlijk.
Het mooie is dat je niet de hele grote tafel hoeft te cachen. Een fysieke server host virtuele machines van een relatief klein aantal VPC's. U hoeft alleen informatie over deze VPC's in de cache op te slaan. Het overbrengen van gegevens naar andere VPC's in de “standaard” configuratie is nog steeds niet legitiem. Als functionaliteit zoals VPC-peering wordt gebruikt, wordt informatie over de bijbehorende VPC's bovendien in de cache geladen.
We hebben de overdracht van gegevens naar de VPC geregeld.
Blackfoot
Wat te doen als verkeer naar buiten moet worden verzonden, bijvoorbeeld naar internet of via VPN naar de grond? Helpt ons hier Blackfoot — Interne AWS-dienst. Het is ontwikkeld door ons Zuid-Afrikaanse team. Daarom is het servies vernoemd naar een pinguïn die in Zuid-Afrika leeft.
Blackfoot kapselt het verkeer af en doet ermee wat nodig is. Gegevens worden ongewijzigd naar internet verzonden.
Bij gebruik van een VPN worden de gegevens ontkapseld en opnieuw verpakt in IPsec.
Bij gebruik van Direct Connect wordt het verkeer getagd en naar het juiste VLAN gestuurd.
HyperVlak
Dit is een interne stroomcontroledienst. Veel netwerkdiensten vereisen monitoring gegevensstroomstatussen. Wanneer u bijvoorbeeld NAT gebruikt, moet de stroomcontrole ervoor zorgen dat elk IP:bestemming-poortpaar een unieke uitgaande poort heeft. In het geval van een balancer NLB - Netwerk Load Balancer, moet de gegevensstroom altijd naar dezelfde virtuele doelmachine worden geleid. Beveiligingsgroepen is een stateful firewall. Het controleert inkomend verkeer en opent impliciet poorten voor uitgaande pakketstromen.
In de AWS-cloud zijn de vereisten voor transmissielatentie extreem hoog. Daarom HyperVlak cruciaal voor de prestaties van het gehele netwerk.
Hyperplane is gebouwd op virtuele EC2-machines. Er is hier geen magie, alleen sluwheid. De truc is dat dit virtuele machines zijn met een groot RAM-geheugen. Bewerkingen zijn transactioneel en worden uitsluitend in het geheugen uitgevoerd. Hiermee kunt u vertragingen van slechts tientallen microseconden bereiken. Werken met de schijf zou alle productiviteit tenietdoen.
Hyperplane is een gedistribueerd systeem van een groot aantal van dergelijke EC2-machines. Elke virtuele machine heeft een bandbreedte van 5 GB/s. Dit levert voor het gehele regionale netwerk ongelooflijke terabits aan bandbreedte op en maakt verwerking mogelijk miljoenen verbindingen per seconde.
HyperPlane werkt alleen met streams. VPC-pakketinkapseling is daarvoor volledig transparant. Een potentiële kwetsbaarheid in deze interne dienst zou nog steeds voorkomen dat de VPC-isolatie wordt verbroken. De onderstaande niveaus zijn verantwoordelijk voor de beveiliging.
Lawaaierige buurman
Er is nog steeds een probleem luidruchtige buurman - luidruchtige buurman. Laten we aannemen dat we 8 knooppunten hebben. Deze knooppunten verwerken de stromen van alle cloudgebruikers. Alles lijkt in orde te zijn en de belasting moet gelijkmatig over alle knooppunten worden verdeeld. Knooppunten zijn erg krachtig en het is moeilijk om ze te overbelasten.
Maar we bouwen onze architectuur op basis van zelfs onwaarschijnlijke scenario's.
Een lage waarschijnlijkheid betekent niet onmogelijk.
We kunnen ons een situatie voorstellen waarin een of meerdere gebruikers teveel belasting zouden genereren. Alle HyperPlane-knooppunten zijn betrokken bij het verwerken van deze belasting en andere gebruikers kunnen mogelijk een prestatieverlies ondervinden. Dit doorbreekt het concept van de cloud, waarbij huurders geen mogelijkheid hebben om elkaar te beïnvloeden.
Hoe het probleem van een luidruchtige buurman oplossen? Het eerste dat in je opkomt is scherven. Onze 8 knooppunten zijn logisch verdeeld in 4 scherven van elk 2 knooppunten. Nu zal een luidruchtige buurman slechts een kwart van alle gebruikers storen, maar hij zal hen enorm storen.
Laten we de dingen anders doen. We wijzen slechts 3 knooppunten toe aan elke gebruiker.
De truc is om knooppunten willekeurig aan verschillende gebruikers toe te wijzen. In de onderstaande afbeelding kruist de blauwe gebruiker knooppunten met een van de andere twee gebruikers: groen en oranje.
Met 8 knooppunten en 3 gebruikers is de kans dat een luidruchtige buur een van de gebruikers kruist 54%. Het is met deze waarschijnlijkheid dat een blauwe gebruiker andere huurders zal beïnvloeden. Tegelijkertijd slechts een deel van de lading. In ons voorbeeld zal deze invloed op de een of andere manier niet voor iedereen merkbaar zijn, maar voor slechts een derde van alle gebruikers. Dit is al een goed resultaat.
Aantal gebruikers dat elkaar zal kruisen
Waarschijnlijkheid in procent
0
18%
1
54%
2
26%
3
2%
Laten we de situatie dichter bij de realiteit brengen: laten we 100 knooppunten en 5 gebruikers op 5 knooppunten nemen. In dit geval zal geen van de knooppunten elkaar kruisen met een waarschijnlijkheid van 77%.
Aantal gebruikers dat elkaar zal kruisen
Waarschijnlijkheid in procent
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
In een echte situatie, met een groot aantal HyperPlane-nodes en gebruikers, is de potentiële impact van een luidruchtige buurman op andere gebruikers minimaal. Deze methode heet scherven mengen - shuffle scherven. Het minimaliseert het negatieve effect van knooppuntstoringen.
Veel diensten zijn gebouwd op basis van HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Netwerkschaal
Laten we het nu hebben over de schaal van het netwerk zelf. Voor oktober 2019 biedt AWS zijn diensten aan in 22 regio's, en er staan er nog 9 gepland.
- Elke regio bevat verschillende Beschikbaarheidszones. Er zijn er 69 over de hele wereld.
- Elke AZ bestaat uit Dataverwerkingscentra. In totaal zijn het er niet meer dan 8.
- Het datacenter herbergt een groot aantal servers, sommige met wel 300.
Laten we dit nu allemaal middelen, vermenigvuldigen en een indrukwekkend cijfer krijgen dat weerspiegelt Amazon-cloudschaal.
Er zijn veel optische verbindingen tussen Availability Zones en het datacenter. In een van onze grootste regio's zijn 388 kanalen aangelegd speciaal voor AZ-communicatie tussen elkaar en communicatiecentra met andere regio's (Transit Centers). In totaal geeft dit gek 5000 Tbit.
Backbone AWS is specifiek gebouwd voor en geoptimaliseerd voor de cloud. Wij bouwen het op de kanalen 100 GB/s. Wij controleren ze volledig, met uitzondering van regio's in China. Het verkeer wordt niet gedeeld met de lading van andere bedrijven.
Uiteraard zijn wij niet de enige cloudprovider met een eigen backbone-netwerk. Steeds meer grote bedrijven volgen dit pad. Dit wordt bevestigd door onafhankelijke onderzoekers van bijvoorbeeld .
Uit de grafiek blijkt dat het aandeel contentaanbieders en cloudaanbieders groeit. Hierdoor neemt het aandeel van het internetverkeer van backbone-providers voortdurend af.
Ik zal uitleggen waarom dit gebeurt. Voorheen waren de meeste webservices rechtstreeks vanaf internet toegankelijk en te gebruiken. Tegenwoordig staan steeds meer servers in de cloud en zijn ze via internet bereikbaar CDN - Inhoudsdistributienetwerk. Om toegang te krijgen tot een bron gaat de gebruiker via internet alleen naar de dichtstbijzijnde CDN PoP - Aanwezigheidspunt. Meestal is het ergens in de buurt. Vervolgens verlaat het het openbare internet en vliegt via een particuliere backbone bijvoorbeeld de Atlantische Oceaan over en komt rechtstreeks bij de bron terecht.
Ik vraag me af hoe het internet over tien jaar zal veranderen als deze trend zich voortzet?
Fysieke kanalen
Wetenschappers zijn er nog niet achter hoe ze de snelheid van het licht in het heelal kunnen verhogen, maar ze hebben grote vooruitgang geboekt in de methoden om het licht via optische vezels te verzenden. Momenteel gebruiken we 6912 glasvezelkabels. Dit helpt om de kosten van hun installatie aanzienlijk te optimaliseren.
In sommige regio's moeten we speciale kabels gebruiken. In de regio Sydney gebruiken we bijvoorbeeld kabels met een speciale coating tegen termieten.
Niemand is immuun voor problemen en soms raken onze kanalen beschadigd. Op de foto rechts zijn optische kabels te zien in een van de Amerikaanse regio's die door bouwvakkers zijn gescheurd. Als gevolg van het ongeval gingen slechts 13 datapakketten verloren, wat verrassend is. Nogmaals - slechts 13! Het systeem schakelde letterlijk onmiddellijk over op back-upkanalen - de weegschaal werkt.
We galoppeerden door enkele clouddiensten en -technologieën van Amazon. Ik hoop dat je op zijn minst enig idee hebt van de omvang van de taken die onze ingenieurs moeten oplossen. Persoonlijk vind ik dit heel spannend.
Dit is het laatste deel van de trilogie van Vasily Pantyukhin over het AWS-apparaat. IN delen beschrijven serveroptimalisatie en databaseschaling, en in — serverloze functies en Firecracker.
Op in november zal Vasily Pantyukhin nieuwe details van het Amazon-apparaat delen. Hij over de oorzaken van storingen en het ontwerp van gedistribueerde systemen bij Amazon. 24 oktober is nog mogelijk ticket voor een goede prijs, en betaal later. We wachten op je bij HighLoad++, kom en laten we praten!
Bron: www.habr.com