De skaal fan it Amazon Web Services-netwurk is 69 sônes om 'e wrâld yn 22 regio's: FS, Jeropa, Aazje, Afrika en Austraalje. Elke sône befettet maksimaal 8 datasintra - Data Processing Centers. Elk datasintrum hat tûzenen of hûnderttûzenen servers. It netwurk is op sa'n manier ûntwurpen dat alle ûnwierskynlike ûnderbrekkingssenario's yn rekken brocht wurde. Bygelyks, alle regio's binne isolearre fan elkoar, en berikberens sônes wurde skieden oer ôfstannen fan ferskate kilometers. Sels as jo de kabel snije, sil it systeem oerskeakelje nei reservekopykanalen, en it ferlies fan ynformaasje sil in pear gegevenspakketten bedrage. Vasily Pantyukhin sil prate oer hokker oare prinsipes it netwurk is boud op en hoe't it is strukturearre.
Vasily Pantyukhin begûn as Unix-behearder yn .ru-bedriuwen, wurke oan grutte Sun Microsystem-hardware foar 6 jier, en preke in data-sintraal wrâld foar 11 jier by EMC. It evoluearre natuerlik yn privee wolken, en ferhuze doe nei iepenbiere wolken. No, as Amazon Web Services-arsjitekt, leveret hy technysk advys om te helpen te libjen en te ûntwikkeljen yn 'e AWS-wolk.
Yn it foarige diel fan 'e AWS-trilogy dûke Vasily yn it ûntwerp fan fysike servers en skaalfergrutting fan databases. Nitro-kaarten, oanpaste KVM-basearre hypervisor, Amazon Aurora-database - oer dit alles yn it materiaal "" Lês foar kontekst of sjoch taspraken.
Dit diel sil rjochtsje op skaalfergrutting fan netwurken, ien fan 'e meast komplekse systemen yn AWS. De evolúsje fan in plat netwurk nei in Virtual Private Cloud en syn ûntwerp, ynterne tsjinsten fan Blackfoot en HyperPlane, it probleem fan in lawaaierige buorman, en oan 'e ein - de skaal fan it netwurk, rêchbonke en fysike kabels. Oer dit alles ûnder de besuniging.
Disclaimer: alles hjirûnder is de persoanlike miening fan Vasily en kin net oerienkomme mei de posysje fan Amazon Web Services.
Netwurk skaalfergrutting
De AWS-wolk waard lansearre yn 2006. Syn netwurk wie frij primityf - mei in platte struktuer. It berik fan privee adressen wie mienskiplik foar alle wolk hierders. By it starten fan in nije firtuele masine krigen jo by ûngelok in beskikber IP-adres út dit berik.
Dizze oanpak wie maklik te ymplementearjen, mar beheine it gebrûk fan 'e wolk grûnslach. Benammen wie it frij lestich om hybride oplossingen te ûntwikkeljen dy't privee netwurken op 'e grûn en yn AWS kombineare. It meast foarkommende probleem wie oerlappende IP-adresberiken.
Firtuele privee wolk
De wolk die bliken yn fraach te wêzen. De tiid is kommen om nei te tinken oer skaalberens en de mooglikheid fan gebrûk troch tsientallen miljoenen hierders. It platte netwurk is in grut obstakel wurden. Dêrom hawwe wy tochten oer hoe't jo brûkers fan elkoar kinne isolearje op netwurknivo, sadat se selsstannich IP-beriken kinne kieze.
Wat is it earste dat yn 't sin komt as jo tinke oan netwurkisolaasje? Wis VLANs и VRF - Firtuele Routing en trochstjoere.
Spitigernôch slagge it net. VLAN ID is mar 12 bits, dat jout ús allinne 4096 isolearre segminten. Sels de grutste skeakels kinne maksimaal 1-2 tûzen VRF's brûke. It brûken fan VRF en VLAN tegearre jout ús mar in pear miljoen subnets. Dit is perfoarst net genôch foar tsientallen miljoenen hierders, dy't elk meardere subnetten brûke moatte.
Wy kinne ek gewoan net betelje om it fereaske oantal grutte doazen te keapjen, bygelyks fan Cisco of Juniper. D'r binne twa redenen: it is dwylsinnich djoer, en wy wolle net oerlevere wurde fan har ûntwikkeling en it patchjen fan belied.
D'r is mar ien konklúzje - meitsje jo eigen oplossing.
Yn 2009 hawwe wy bekend makke VPC - Firtuele privee wolk. De namme bleau fêst en no brûke in protte wolkproviders it ek.
VPC is in firtuele netwurk SDN (Software Defined Network). Wy besletten gjin spesjale protokollen út te finen op 'e L2- en L3-nivo's. It netwurk rint op standert Ethernet en IP. Foar oerdracht oer it netwurk wurdt firtuele masineferkear ynkapsele yn ús eigen protokol-wrapper. It jout de ID oan dy't heart by de VPC fan 'e hierder.
Klinkt ienfâldich. D'r binne lykwols ferskate serieuze technyske útdagings dy't moatte wurde oerwûn. Bygelyks, wêr en hoe te bewarjen gegevens op mapping firtuele MAC / IP adressen, VPC ID en oerienkommende fysike MAC / IP. Op AWS-skaal is dit in enoarme tabel dy't moat wurkje mei minimale tagongsfertragingen. Ferantwurdlik foar dit mapping tsjinst, dat is ferspraat yn in tinne laach troch it netwurk.
Yn masines fan nije generaasje wurdt ynkapseling útfierd troch Nitro-kaarten op hardwarenivo. Yn âldere gefallen binne ynkapseling en dekapsulaasje software-basearre.
Litte wy útfine hoe't it yn algemiene termen wurket. Litte wy begjinne mei it L2-nivo. Lit ús oannimme dat wy hawwe in firtuele masine mei IP 10.0.0.2 op in fysike tsjinner 192.168.0.3. It stjoert gegevens nei firtuele masine 10.0.0.3, dy't libbet op 192.168.1.4. In ARP-fersyk wurdt oanmakke en stjoerd nei it netwurk Nitro-kaart. Foar ienfâld, wy oannimme dat beide firtuele masines libje yn deselde "blauwe" VPC.
De kaart ferfangt it boarneadres mei har eigen en stjoert it ARP-frame troch nei de mappingtsjinst.
De kaarttsjinst jout ynformaasje werom dy't nedich is foar oerdracht oer it fysike netwurk L2.
De Nitro-kaart yn 'e ARP-antwurd ferfangt de MAC op it fysike netwurk mei in adres yn' e VPC.
By it oerdragen fan gegevens ferpakke wy logyske MAC en IP yn in VPC-wrapper. Wy stjoere dit alles oer it fysike netwurk mei de passende boarne en bestimming IP Nitro-kaarten.
De fysike masine wêrop it pakket is ornearre fiert de kontrôle út. Dit is nedich om de mooglikheid fan adres spoofing foar te kommen. De masine stjoert in spesjaal fersyk nei de kaarttsjinst en freget: "Fan fysike masine 192.168.0.3 krige ik in pakket dat bedoeld is foar 10.0.0.3 yn 'e blauwe VPC. Is hy legitime?
De mapping tsjinst kontrolearret syn boarne tawizing tabel en lit of wegeret it pakket trochjaan. Yn alle nije gefallen is ekstra falidaasje ynbêde yn Nitro-kaarten. It is ûnmooglik om te omgean it sels teoretysk. Dêrom sil spoofing nei boarnen yn in oare VPC net wurkje.
Dêrnei wurde de gegevens stjoerd nei de firtuele masine wêrfoar it bedoeld is.
De mapping tsjinst wurket ek as in logyske router foar it oerdragen fan gegevens tusken firtuele masines yn ferskate subnets. Alles is konseptueel ienfâldich, ik sil net yn detail gean.
It docht bliken dat by it ferstjoeren fan elk pakket de tsjinners nei de mappingtsjinst draaie. Hoe om te gean mei ûnûntkombere fertragingen? Caching, fansels.
It skientme is dat jo de heule enoarme tafel net hoege te cache. In fysike tsjinner host firtuele masines fan in relatyf lyts oantal VPC's. Jo hoege allinich ynformaasje oer dizze VPC's te cache. It oerdragen fan gegevens nei oare VPC's yn 'e "standert" konfiguraasje is noch altyd net legitimearre. As funksjonaliteit lykas VPC-peering brûkt wurdt, dan wurdt ek ynformaasje oer de oerienkommende VPC's yn 'e cache laden.
Wy sorteare de oerdracht fan gegevens nei de VPC.
Blackfoot
Wat te dwaan yn gefallen dêr't ferkear nei bûten ferstjoerd wurde moat, bygelyks nei it ynternet of fia VPN nei de grûn? Helpt ús hjir Blackfoot - AWS ynterne tsjinst. It is ûntwikkele troch ús Súd-Afrikaanske team. Dêrom is de tsjinst neamd nei in pinguïn dy't yn Súd-Afrika libbet.
Blackfoot decapsules ferkear en docht wat nedich is mei it. Gegevens wurde stjoerd nei it ynternet lykas is.
De gegevens wurde dekapsulearre en opnij ferpakt yn IPsec by it brûken fan in VPN.
By it brûken fan Direct Connect, wurdt ferkear markearre en stjoerd nei it passende VLAN.
HyperPlane
Dit is in tsjinst foar ynterne streamkontrôle. In protte netwurktsjinsten fereaskje tafersjoch data flow steaten. Bygelyks, by it brûken fan NAT, moat streamkontrôle derfoar soargje dat elk IP: bestimmingsportpaar in unike útgeande haven hat. Yn it gefal fan in balancer NLB - Netwurk Load Balancer, de gegevensstream moat altyd wurde rjochte op deselde doelfirtuele masine. Feiligensgroepen is in steatlike firewall. It kontrolearret ynkommende ferkear en iepenet ymplisyt havens foar útgeande pakketstream.
Yn 'e AWS-wolk binne easken foar oerdrachtlatinsje ekstreem heech. Dêrom HyperPlane kritysk foar de prestaasjes fan it hiele netwurk.
Hyperplane is boud op EC2 firtuele masines. D'r is hjir gjin magy, allinich slûchslimme. De trúk is dat dit firtuele masines binne mei grutte RAM. Operaasjes binne transaksje en útfierd allinnich yn it ûnthâld. Hjirmei kinne jo fertragingen fan mar tsientallen mikrosekonden berikke. Wurkje mei de skiif soe deadzje alle produktiviteit.
Hyperplane is in ferspraat systeem fan in grut oantal sokke EC2 masines. Elke firtuele masine hat in bânbreedte fan 5 GB / s. Oer it heule regionale netwurk leveret dit ongelooflijke terabits fan bânbreedte en makket ferwurking mooglik miljoenen ferbiningen per sekonde.
HyperPlane wurket allinich mei streamen. VPC pakket ynkapseling is folslein transparant foar it. In potinsjele kwetsberens yn dizze ynterne tsjinst soe noch foarkomme dat de VPC-isolaasje brutsen wurdt. De nivo's hjirûnder binne ferantwurdlik foar feiligens.
Noisy buorman
Der is noch in probleem lawaaierige buorman - lawaaierige buorman. Litte wy oannimme dat wy 8 knopen hawwe. Dizze knooppunten ferwurkje de streamen fan alle wolk brûkers. Alles liket goed te wêzen en de lading moat lykwichtich ferdield wurde oer alle knopen. Knooppunten binne heul krêftich en it is lestich om se te oerladen.
Mar wy bouwe ús arsjitektuer basearre op sels ûnwierskynlike senario's.
Lege kâns betsjut net ûnmooglik.
Wy kinne ús in situaasje yntinke wêryn ien of mear brûkers tefolle lading generearje. Alle HyperPlane-knooppunten binne belutsen by it ferwurkjen fan dizze lading en oare brûkers kinne mooglik in soarte fan prestaasje-hit ûnderfine. Dit brekt it konsept fan 'e wolk, wêryn hierders gjin mooglikheid hawwe om inoar te beynfloedzjen.
Hoe kinne jo it probleem fan in lawaaiige buorman oplosse? It earste ding dat yn 't sin komt is sharding. Us 8 knopen binne logysk ferdield yn 4 shards fan elk 2 knopen. No sil in lawaaiige buorman mar in kwart fan alle brûkers steure, mar it sil har bot steure.
Litte wy dingen oars dwaan. Wy sille allinich 3 knopen tawize oan elke brûker.
De trúk is om willekeurige knooppunten oan ferskate brûkers te jaan. Op de foto hjirûnder snijt de blauwe brûker knopen mei ien fan 'e oare twa brûkers - grien en oranje.
Mei 8 knopen en 3 brûkers is de kâns dat in lawaaierige buorman krúst mei ien fan de brûkers 54%. It is mei dizze kâns dat in blauwe brûker oare hierders beynfloedet. Tagelyk, mar in part fan syn lading. Yn ús foarbyld sil dizze ynfloed op syn minst ien of oare manier merkber wêze foar net elkenien, mar foar mar in tredde fan alle brûkers. Dit is al in goed resultaat.
Oantal brûkers dy't kruse sille
Kâns yn prosint
0
18%
1
54%
2
26%
3
2%
Litte wy de situaasje tichter by de realiteit bringe - litte wy 100 knopen nimme en 5 brûkers op 5 knopen. Yn dit gefal sil gjin fan 'e knopen krúsje mei in kâns fan 77%.
Oantal brûkers dy't kruse sille
Kâns yn prosint
0
77%
1
21%
2
1,8%
3
0,06%
4
0,0006%
5
0,00000013%
Yn in echte situaasje, mei in grut oantal HyperPlane-knooppunten en brûkers, is de potensjele ynfloed fan in lawaaierige buorman op oare brûkers minimaal. Dizze metoade wurdt neamd mingen sharding - shuffle sharding. It minimalisearret it negative effekt fan knooppuntfalen.
In protte tsjinsten binne boud op basis fan HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.
Netwurk skaal
No litte wy prate oer de skaal fan it netwurk sels. Foar oktober 2019 biedt AWS har tsjinsten yn 22 regio, en 9 mear binne pland.
- Elke regio befettet ferskate beskikberenssônes. D'r binne 69 fan har om 'e wrâld.
- Elke AZ bestiet út gegevensferwurkingssintra. Der binne net mear as 8 fan harren yn totaal.
- It datasintrum hat in enoarm oantal servers, guon mei maksimaal 300.
No litte wy dit alles gemiddelde, fermannichfâldigje en krije in yndrukwekkend figuer dat reflektearret Amazon wolk skaal.
D'r binne in protte optyske keppelings tusken Availability Zones en it datasintrum. Yn ien fan ús grutste regio's binne 388 kanalen oanlein krekt foar AZ-kommunikaasje tusken inoar en kommunikaasjesintra mei oare regio's (Transit Centers). Yn totaal jout dit gek 5000 Tbit.
Backbone AWS is spesifyk boud foar en optimalisearre foar de wolk. Wy bouwe it op 'e kanalen 100 GB / s. Wy kontrolearje se folslein, mei útsûndering fan regio's yn Sina. Ferkear wurdt net dield mei de loads fan oare bedriuwen.
Fansels binne wy net de ienige wolkprovider mei in privee eftergrûnnetwurk. Hieltyd mear grutte bedriuwen folgje dit paad. Dat wurdt befêstige troch ûnôfhinklike ûndersikers, bygelyks fan .
De grafyk lit sjen dat it oandiel fan ynhâldproviders en wolkproviders groeit. Hjirtroch nimt it oandiel ynternetferkear fan backbone-oanbieders konstant ôf.
Ik sil útlizze wêrom dit bart. Eartiids wiene de measte webtsjinsten tagonklik en direkt fan it ynternet konsumearre. Tsjintwurdich lizze mear en mear servers yn 'e wolk en binne tagonklik fia CDN - Ynhâld Distribution Network. Om tagong te krijen ta in boarne giet de brûker allinich fia it ynternet nei de tichtstbye CDN PoP - Point of Presence. Meast faak is it earne tichtby. Dan ferlit it it iepenbiere ynternet en fljocht troch in privee rêchbonke oer de Atlantyske, bygelyks, en komt direkt nei de boarne.
Ik freegje my ôf hoe't it ynternet yn 10 jier sil feroarje as dizze trend trochgiet?
Fysike kanalen
Wittenskippers hawwe noch net útfûn hoe't te fergrutsjen de snelheid fan ljocht yn it hielal, mar se hawwe makke grutte foarútgong yn metoaden fan transmitting it fia glêstried. Wy brûke op it stuit 6912 glêstriedkabels. Dit helpt om de kosten fan har ynstallaasje signifikant te optimalisearjen.
Yn guon regio's moatte wy spesjale kabels brûke. Bygelyks, yn 'e Sydney-regio brûke wy kabels mei in spesjale coating tsjin termiten.
Nimmen is ymmún foar problemen en soms wurde ús kanalen skansearre. De foto rjochts lit optyske kabels sjen yn ien fan 'e Amerikaanske regio's dy't troch bouwurkers ferskuord waarden. As gefolch fan it ûngelok binne mar 13 gegevenspakketten ferlern gien, wat ferrassend is. Noch ien kear - mar 13! It systeem skeakele letterlik direkt oer op reservekopykanalen - de skaal wurket.
Wy galoppearren troch guon fan Amazon's wolktsjinsten en technologyen. Ik hoopje dat jo op syn minst wat idee hawwe fan 'e skaal fan' e taken dy't ús yngenieurs moatte oplosse. Persoanlik fyn ik dit tige spannend.
Dit is it lêste diel fan 'e trilogy fan Vasily Pantyukhin oer it AWS-apparaat. YN dielen beskriuwe tsjinner optimalisaasje en databank skaalfergrutting, en yn - serverless funksjes en Firecracker.
op yn novimber sil Vasily Pantyukhin nije details fan it Amazon-apparaat diele. Hy oer de oarsaken fan mislearrings en it ûntwerp fan ferspraat systemen by Amazon. 24 oktober is noch mooglik ticket op in goede priis, en betelje letter. Wy wachtsje op jo by HighLoad++, kom en lit ús petearje!
Boarne: www.habr.com