{"id":39304,"date":"2019-10-31T22:29:40","date_gmt":"2019-10-31T19:29:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Hur AWS \"kokar\" sina elastiska tj\u00e4nster. N\u00e4tverksskalning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

N\u00e4tverkskapaciteten hos Amazon Web Services best\u00e5r av 69 zoner runt om i v\u00e4rlden i 22 regioner: USA, Europa, Asien, Afrika och Australien. Varje zon rymmer upp till 8 datacenter \u2014 databehandlingscenter. I varje datacenter finns tusentals eller hundratusentals servrar. N\u00e4tverket \u00e4r utformat s\u00e5 att alla osannolika driftst\u00f6rningar beaktas. Till exempel \u00e4r alla regioner isolerade fr\u00e5n varandra, och tillg\u00e4nglighetszonerna ligger p\u00e5 flera kilometers avst\u00e5nd fr\u00e5n varandra. \u00c4ven om en kabel klipps kommer systemet att anv\u00e4nda reservkanaler, och informationsf\u00f6rlusten kommer att vara n\u00e5gra datapaket. Mer om de principer som n\u00e4tverket \u00e4r byggt p\u00e5 och hur det fungerar ber\u00e4ttar Vasily Pantyukhin.<\/p>\n

\"Hur
\n
\nVasilij Pantu Chin<\/b> b\u00f6rjade som Unix-administrat\u00f6r p\u00e5 .ru-f\u00f6retag, arbetade i 6 \u00e5r med stora maskiner fr\u00e5n Sun Microsystems, och predikade i 11 \u00e5r datacenterfokus i EMC. Som en naturlig utveckling \u00f6vergick jag till privata moln och sedan till offentliga. Nu, som arkitekt p\u00e5 Amazon Web Services, ger jag tekniska r\u00e5d f\u00f6r att hj\u00e4lpa f\u00f6retag att v\u00e4xa och leva i AWS-molnet.<\/p>\n

I den f\u00f6reg\u00e5ende delen av trilogin om AWS uppbyggnad f\u00f6rdjupade Vasily sig i uppbyggnaden av fysiska servrar och skalning av databaser. Nitro-kort, anpassad hypervisor baserad p\u00e5 KVM, databasen Amazon Aurora \u2014 allt detta finns i materialet \"Hur AWS \"kokar\" sina elastiska tj\u00e4nster. Skalning av servrar och databaser<\/a><\/noindex>\". L\u00e4s f\u00f6r att f\u00e5 en djupare f\u00f6rst\u00e5else av kontexten eller se videoinspelning<\/a><\/noindex> presentationerna.<\/p>\n

I den h\u00e4r delen handlar det om n\u00e4tverkets skalning \u2014 en av de mest komplexa systemen inom AWS. Utvecklingen fr\u00e5n ett platt n\u00e4tverk till Virtual Private Cloud och dess uppbyggnad, interna tj\u00e4nster som Blackfoot och HyperPlane, problemet med bullriga grannar, och slutligen \u2014 n\u00e4tverksstorlekar, backbone och fysiska kablar. Allt detta finner du under l\u00e4s mer.<\/p>\n

Ansvarsfriskrivning: allt nedan \u00e4r Vasily's personliga \u00e5sikt, och den kan skilja sig fr\u00e5n Amazon Web Services st\u00e5ndpunkter.<\/i>
\n<\/a><\/noindex><\/p>\n

N\u00e4tverksskalning<\/h2>\n

\nAWS-molnet lanserades \u00e5r 2006. Dess n\u00e4tverk var ganska primitivt \u2014 med en platt struktur. Adressintervallet f\u00f6r privata adresser var gemensamt f\u00f6r alla hyresg\u00e4ster i molnet. N\u00e4r en ny virtuell maskin startade fick du av en slump en tillg\u00e4nglig IP-adress fr\u00e5n detta intervall.<\/p>\n

\"Hur
\n
\nDetta tillv\u00e4gag\u00e5ngss\u00e4tt var enkelt att genomf\u00f6ra, men det begr\u00e4nsade grundl\u00e4ggande anv\u00e4ndningen av molnet. Speciellt var det ganska sv\u00e5rt att utveckla hybridl\u00f6sningar som kombinerade privata n\u00e4tverk p\u00e5 marken och i AWS. Det vanligaste problemet l\u00e5g i \u00f6verlappningen av IP-adressintervall.<\/p>\n

\"Hur
\n<\/p>\n

Virtual Private Cloud<\/h3>\n

\nMolnet har blivit efterfr\u00e5gat. Det \u00e4r dags att t\u00e4nka p\u00e5 skalbarheten och m\u00f6jligheten att anv\u00e4nda det av tiotals miljoner hyresg\u00e4ster. Det platta n\u00e4tverket har blivit det st\u00f6rsta hindret. D\u00e4rf\u00f6r b\u00f6rjade vi t\u00e4nka p\u00e5 hur vi kan isolera anv\u00e4ndare fr\u00e5n varandra p\u00e5 n\u00e4tverksniv\u00e5 s\u00e5 att de sj\u00e4lva kan v\u00e4lja IP-omr\u00e5den.<\/p>\n

\"Hur
\n
\nVad kommer f\u00f6rst i tankarna n\u00e4r du t\u00e4nker p\u00e5 n\u00e4tverksisolering? Sj\u00e4lvklart VLAN<\/b> och VRF - Virtual Routing and Forwarding<\/b>.<\/p>\n

Tyv\u00e4rr har det inte fungerat. VLAN-ID \u00e4r endast 12 bitar, vilket ger oss bara 4096 isolerade segment. \u00c4ven i de st\u00f6rsta switcharna kan h\u00f6gst 1-2 tusen VRF anv\u00e4ndas. Kombinationen av VRF och VLAN ger oss bara n\u00e5gra miljoner deln\u00e4t. Det \u00e4r definitivt inte tillr\u00e4ckligt f\u00f6r tiotals miljoner hyresg\u00e4ster, d\u00e4r varje hyresg\u00e4st m\u00e5ste ha m\u00f6jlighet att anv\u00e4nda flera deln\u00e4t.<\/p>\n

Dessutom kan vi helt enkelt inte ha r\u00e5d att k\u00f6pa det antal stora enheter som kr\u00e4vs, till exempel fr\u00e5n Cisco eller Juniper. Det finns tv\u00e5 sk\u00e4l: det \u00e4r fruktansv\u00e4rt dyrt, och vi vill inte bli beroende av deras utvecklings- och patchpolitik.<\/p>\n

Slutsatsen \u00e4r klar - vi m\u00e5ste koka ihop v\u00e5r egen l\u00f6sning.<\/p><\/blockquote>\n

\n\u00c5r 2009 tillk\u00e4nnagav vi VPC<\/b> \u2014 Virtual Private Cloud<\/b>. Namnet har slagit igenom och nu anv\u00e4nder m\u00e5nga molnleverant\u00f6rer det ocks\u00e5.<\/p>\n

VPC \u00e4r ett virtuellt n\u00e4tverk SDN<\/b> (Software Defined Network). Vi beslutade oss f\u00f6r att inte uppfinna egna protokoll p\u00e5 L2- och L3-niv\u00e5er. N\u00e4tverket fungerar p\u00e5 standard Ethernet och IP. F\u00f6r att \u00f6verf\u00f6ra trafik fr\u00e5n virtuella maskiner kapslas den in i omslaget av v\u00e5rt eget protokoll. I det anges ID:t som tillh\u00f6r VPC-hyresg\u00e4sten.<\/p>\n

\"Hur
\n
\nDet l\u00e5ter enkelt. Men det finns flera allvarliga tekniska utmaningar att l\u00f6sa. Till exempel, var och hur ska vi lagra data om mappningen av virtuella MAC\/IP-adresser, VPC-ID och motsvarande fysiska MAC\/IP? I skalan av AWS \u00e4r detta en enorm tabell som m\u00e5ste fungera med minimala f\u00f6rdr\u00f6jningar vid \u00e5tkomst. Det ansvarar f\u00f6r mappningstj\u00e4nsten<\/b>, som \u00e4r utspridd i ett tunt lager \u00f6ver hela n\u00e4tverket.<\/p>\n

I n\u00e4sta generations maskiner utf\u00f6rs inkapslingen av Nitro-kort p\u00e5 h\u00e5rdvaruniv\u00e5. I \u00e4ldre instanser \u00e4r inkapsling och dekapsling programvarubaserade.\u00a0<\/p>\n

\"Hur
\n
\nL\u00e5t oss f\u00f6rst\u00e5 hur detta fungerar i stora drag. Vi b\u00f6rjar med niv\u00e5 L2. Anta att vi har en virtuell maskin med IP 10.0.0.2 p\u00e5 en fysisk server 192.168.0.3. Den skickar data till den virtuella maskinen 10.0.0.3, som ligger p\u00e5 192.168.1.4. En ARP-f\u00f6rfr\u00e5gan bildas och hamnar p\u00e5 det n\u00e4tverkskort som heter Nitro. F\u00f6r enkelhetens skull antar vi att b\u00e5da virtuella maskinerna finns i samma \"bl\u00e5\" VPC.<\/p>\n

\"Hur
\n
\nKortet ers\u00e4tter k\u00e4lladressen med sin egen och vidarebefordrar ARP-ramen till mappningstj\u00e4nsten.<\/p>\n

\"Hur
\n
\nMappningstj\u00e4nsten returnerar information som beh\u00f6vs f\u00f6r att skicka \u00f6ver det fysiska L2-n\u00e4tverket.<\/p>\n

\"Hur
\n
\nNitro-kortet ers\u00e4tter MAC-adressen i det fysiska n\u00e4tverket med adressen i VPC i ARP-svaret.<\/p>\n

\"Hur
\n
\nVid datatransfer kapslar vi de logiska MAC- och IP-adresserna i en VPC-f\u00f6rpackning. Allt detta skickas \u00f6ver det fysiska n\u00e4tverket med hj\u00e4lp av motsvarande IP Nitro-kort i avs\u00e4ndning och mottagning.<\/p>\n

\"Hur
\n
\nDen fysiska maskinen som paketet \u00e4r avsett f\u00f6r utf\u00f6r en kontroll. Detta g\u00f6rs f\u00f6r att f\u00f6rhindra adressf\u00f6rfalskning. Maskinen skickar en speciell f\u00f6rfr\u00e5gan till mappningstj\u00e4nsten och fr\u00e5gar: \"Fr\u00e5n den fysiska maskinen 192.168.0.3 har jag mottagit ett paket som \u00e4r avsett f\u00f6r 10.0.0.3 i \"bl\u00e5\" VPC. \u00c4r det legitimt?\"\u00a0<\/p>\n

\"Hur
\n
\nMappningstj\u00e4nsten kontrollerar sin resursallokeringstabell och till\u00e5ter eller f\u00f6rbjuder paketets passage. I alla nya instanser \u00e4r det ytterligare validering inbyggd i Nitro-korten. Den kan inte omg\u00e5s ens teoretiskt. D\u00e4rf\u00f6r fungerar spoofing p\u00e5 resurser i en annan VPC inte.<\/p>\n

\"Hur
\n
\nD\u00e4refter skickas data till den virtuella maskinen de \u00e4r avsedda f\u00f6r.\u00a0<\/p>\n

\"Hur
\n
\nMappningstj\u00e4nsten fungerar ocks\u00e5 som en logisk router f\u00f6r data\u00f6verf\u00f6ring mellan virtuella maskiner i olika deln\u00e4t. Konceptuellt \u00e4r det ganska enkelt, jag kommer inte att g\u00e5 in p\u00e5 detaljer.<\/p>\n

\"Hur
\n
\nDet visar sig att vid \u00f6verf\u00f6ring av varje paket v\u00e4nder sig servrarna till mappningstj\u00e4nsten. Hur ska vi hantera de oundvikliga f\u00f6rdr\u00f6jningarna? Genom caching<\/b>, sj\u00e4lvklart.<\/p>\n

Det fina \u00e4r att vi inte beh\u00f6ver cacha hela den enorma tabellen. P\u00e5 den fysiska servern finns virtuella maskiner fr\u00e5n ett relativt litet antal VPC:er. Informationen som beh\u00f6ver cachas g\u00e4ller endast dessa VPC:er. \u00d6verf\u00f6ring av data till andra VPC:er i \"standardkonfigurationen\" \u00e4r \u00e4nd\u00e5 inte legitim. Om s\u00e5dana funktioner som VPC-peering anv\u00e4nds, l\u00e4ggs ytterligare information om de motsvarande VPC:erna till i cachen.\u00a0<\/p>\n

\"Hur
\n
\nVi har nu f\u00f6rst\u00e5tt hur data\u00f6verf\u00f6ring i VPC fungerar.<\/p>\n

Blackfoot<\/h3>\n

\nHur hanterar man situationer d\u00e4r trafiken m\u00e5ste skickas ut\u00e5t, till exempel till Internet eller via VPN till landet? H\u00e4r \u00e4r vi r\u00e4ddade av Blackfoot<\/b> \u2014 den interna tj\u00e4nsten AWS. Den har utvecklats av v\u00e5rt sydafrikanska team. D\u00e4rf\u00f6r kallas tj\u00e4nsten efter pingvinen som lever i Sydafrika.<\/p>\n

\"Hur
\n
\nBlackfoot dekapslar trafiken och g\u00f6r med den vad som beh\u00f6vs. Data skickas till Internet som det \u00e4r.<\/p>\n

\"Hur
\n
\nData dekapslas och kapslas in i en IPsec-wrap vid anv\u00e4ndning av VPN.<\/p>\n

\"Hur
\n
\nVid anv\u00e4ndning av Direct Connect taggas trafiken och \u00f6verf\u00f6rs till motsvarande VLAN.<\/p>\n

\"Hur
\n<\/p>\n

HyperPlane<\/h3>\n

\nDetta \u00e4r en intern fl\u00f6deskontrolltj\u00e4nst. M\u00e5nga n\u00e4tverkstj\u00e4nster kr\u00e4ver kontroll av statusen f\u00f6r datatrafiken<\/b>. Till exempel, vid anv\u00e4ndning av NAT m\u00e5ste fl\u00f6deskontrollen s\u00e4kerst\u00e4lla att varje par \"IP: destinationport\" motsvarar en unik utg\u00e5ende port. Vid en balansl\u00f6sare NLB<\/b> \u2014 N\u00e4tverksbelastningsbalanserare<\/b>, m\u00e5ste datatrafiken alltid styras till samma m\u00e5l virtuella maskin. Security Groups \u00e4r en brandv\u00e4gg med statusbevarande. Den \u00f6vervakar inkommande trafik och \u00f6ppnar obem\u00e4rkt portar f\u00f6r utg\u00e5ende datapaket.<\/p>\n

\"Hur
\n
\nI AWS-molnet \u00e4r kraven p\u00e5 \u00f6verf\u00f6ringsf\u00f6rdr\u00f6jningar extremt h\u00f6ga. D\u00e4rf\u00f6r HyperPlane<\/b> \u00e4r kritiska f\u00f6r hela n\u00e4tverks funktionalitet.<\/p>\n

\"Hur
\n
\nHyperplane \u00e4r byggd p\u00e5 EC2-maskiner. H\u00e4r finns ingen magi, bara knep. Knepet \u00e4r att det \u00e4r virtuella maskiner med stor RAM. Transaktionerna \u00e4r endast genomf\u00f6rda i minnet. Detta m\u00f6jligg\u00f6r f\u00f6rdr\u00f6jningar p\u00e5 bara n\u00e5gra tiotal mikrosekunder. Arbete med disk skulle krossa all prestanda.\u00a0<\/p>\n

Hyperplane \u00e4r ett distribuerat system av enorma m\u00e4ngder s\u00e5dana EC2-maskiner. Varje virtuell maskin har en bandbredd p\u00e5 5 GB\/s. P\u00e5 regional n\u00e4tverksniv\u00e5 ger detta galna terabitar av bandbredd och m\u00f6jligg\u00f6r hantering av miljoner anslutningar per sekund<\/b>.<\/p>\n

HyperPlane fungerar endast med str\u00f6mmar. VPC-kapslar paket \u00e4r helt transparenta f\u00f6r den. Potentiell s\u00e5rbarhet i denna interna tj\u00e4nst skulle \u00e4nd\u00e5 inte till\u00e5ta att bryta isoleringen av VPC. S\u00e4kerheten ansvarar f\u00f6r lagren nedanf\u00f6r.<\/p>\n

Noisy neighbor<\/h3>\n

\nDet finns ocks\u00e5 ett problem med den bullriga grannen<\/b> \u2014 noisy neighbor<\/b>. Anta att vi har 8 noder. Dessa noder hanterar str\u00f6mmar fr\u00e5n alla anv\u00e4ndare i molnet. Allt verkar bra och belastningen borde spridas j\u00e4mnt \u00f6ver alla noder. Noderna \u00e4r mycket kraftfulla och det \u00e4r sv\u00e5rt att \u00f6verbelasta dem.<\/p>\n

Men vi bygger v\u00e5r arkitektur med tanke p\u00e5 \u00e4ven de osannolika scenarierna.\u00a0<\/p>\n

En l\u00e5g sannolikhet betyder inte om\u00f6jlighet.<\/p><\/blockquote>\n

\nVi kan f\u00f6rest\u00e4lla oss en situation d\u00e4r en eller flera anv\u00e4ndare genererar en f\u00f6r stor belastning. Denna belastning involverar alla HyperPlane-noder, och andra anv\u00e4ndare kan potentiellt m\u00e4rka en viss minskning i prestanda. Detta bryter mot konceptet av molnet, d\u00e4r hyresg\u00e4sterna inte har m\u00f6jlighet att p\u00e5verka varandra.<\/p>\n

\"Hur
\n
\nHur l\u00f6ser vi problemet med den bullriga grannen? Det f\u00f6rsta som kommer att t\u00e4nka p\u00e5 \u00e4r sharding. V\u00e5ra 8 noder delas logiskt upp i 4 shards med 2 noder i varje. Nu st\u00f6r den bullriga grannen bara en fj\u00e4rdedel av alla anv\u00e4ndare, men det st\u00f6r kraftigt.<\/p>\n

\"Hur
\n
\nL\u00e5t oss g\u00f6ra p\u00e5 ett annat s\u00e4tt. Vi ger varje anv\u00e4ndare bara 3 noder.\u00a0<\/p>\n

\"Hur
\n
\nTricket \u00e4r att tilldela noder till olika anv\u00e4ndare slumpm\u00e4ssigt. I bilden nedan korsar den bl\u00e5 anv\u00e4ndaren noder med en av de tv\u00e5 andra anv\u00e4ndarna \u2014 den gr\u00f6na och den orangea.<\/p>\n

\"Hur
\n
\nMed 8 noder och 3 anv\u00e4ndare \u00e4r sannolikheten f\u00f6r att den bullriga grannen korsar en av anv\u00e4ndarna 54 %. Med en s\u00e5dan sannolikhet kommer den bl\u00e5 anv\u00e4ndaren att p\u00e5verka andra hyresg\u00e4ster. Och detta endast med en del av sin belastning. I v\u00e5rt exempel kommer denna p\u00e5verkan att endast vara m\u00e4rkbar f\u00f6r en tredjedel av alla anv\u00e4ndare. Det \u00e4r redan ett bra resultat.<\/p>\n

Antal anv\u00e4ndare som korsar<\/p>\n

Sannolikhet i procent<\/p>\n

0<\/p>\n

18%<\/p>\n

1<\/p>\n

54%<\/p>\n

2<\/p>\n

26%<\/p>\n

3<\/p>\n

2%<\/p>\n

L\u00e5t oss n\u00e4rma oss situationen mer verklighetstroget - vi tar 100 noder och 5 anv\u00e4ndare p\u00e5 5 noder. I detta fall korsar ingen av noderna varandra med en sannolikhet p\u00e5 77 %.\u00a0<\/p>\n

Antal anv\u00e4ndare som korsar<\/p>\n

Sannolikhet i procent<\/p>\n

0<\/p>\n

77%<\/p>\n

1<\/p>\n

21%<\/p>\n

2<\/p>\n

1,8%<\/p>\n

3<\/p>\n

0,06%<\/p>\n

4<\/p>\n

0,0006%<\/p>\n

5<\/p>\n

0,00000013%<\/p>\n

I en verklig situation, med ett stort antal HyperPlane-noder och anv\u00e4ndare, \u00e4r den potentiella p\u00e5verkan fr\u00e5n den bullriga grannen p\u00e5 andra anv\u00e4ndare minimal. Denna metod kallas shuffle sharding<\/b> \u2014 . Den minimerar den negativa effekten av att noder g\u00e5r ner.<\/b>M\u00e5nga tj\u00e4nster \u00e4r byggda p\u00e5 HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

N\u00e4tverksstorlekar<\/p>\n

n\u00e4tverksstorlek<\/h3>\n

\nL\u00e5t oss nu prata om storleken p\u00e5 n\u00e4tverket. I oktober 2019 erbjuder AWS sina tj\u00e4nster i 22 regioner<\/b>, och ytterligare 9 \u00e4r planerade.<\/p>\n