{"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\/et\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Kuidas AWS oma elastseid teenuseid \u201ekeedab\u201d. V\u00f5rgustiku skaleerimine","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Amazon Web Services'i v\u00f5rgustiku ulatus on 69 tsooni 22 piirkonnas \u00fcle kogu maailma: Ameerikas, Euroopas, Aasias, Aafrikas ja Austraalias. Igas tsoonis asub kuni 8 andmekeskust. Igas andmekeskuses on tuhandeid v\u00f5i k\u00fcmneid tuhandeid servereid. V\u00f5rk on \u00fcles ehitatud nii, et k\u00f5ik ebat\u00f5en\u00e4olised katkestused on ette n\u00e4htud. N\u00e4iteks on k\u00f5ik piirkonnad \u00fcksteisest isoleeritud ning ligip\u00e4\u00e4sus tsoonid on paigutatud kilomeetrite kaugusele. Ieven kui kaabel katkeb, l\u00e4heb s\u00fcsteem varukanalitele ning info kaotus on vaid m\u00f5ne andmepaketi jagu. Lisainfot sellest, millistel p\u00f5him\u00f5tetel v\u00f5rk p\u00f5hineb ja kuidas see on \u00fcles ehitatud, r\u00e4\u00e4gib Vasili Pantjuhin.<\/p>\n

\"Kuidas
\n
\nVasili Pantjuhin<\/b> algas Unix-administraatorina .ru ettev\u00f5tetes, 6 aastat t\u00f6\u00f6tas suurte rauatootjate Sun Microsystems juures, 11 aastat levitas andmekeskuse keskset m\u00f5tteviisi EMC-s. Loomulikult on ta evolutsioneerunud privaatsetesse pilvedesse ja seej\u00e4rel suundunud avalikesse. T\u00e4na, olles Amazon Web Services'i arhitekt, aitab ta tehniliste n\u00f5uannetega ellu j\u00e4\u00e4da ja areneda AWS pilves.<\/p>\n

Triloogia e AWS, Vasilii s\u00fcvenes f\u00fc\u00fcsiliste serverite ja andmebaasi skaleerimise toimimisse. Nitro-kaardid, KVM-p\u00f5hine kohandatud h\u00fcperviisor, Amazon Aurora andmebaas \u2014 k\u00f5igest sellest artiklis \"Kuidas AWS oma elastseid teenuseid \"keedab\". Serverite ja andmebaaside skaleerimine<\/a><\/noindex>\". Loe, et konteksti s\u00fcveneda, v\u00f5i vaata videoklipp<\/a><\/noindex> ettekandeid.<\/p>\n

Selles osas r\u00e4\u00e4gitakse v\u00f5rgu skaleerimisest \u2014 \u00fchest k\u00f5ige keerulisemast s\u00fcsteemist AWS-is. Areng lapikust v\u00f5rgust Virtuaalsesse Erakliendiv\u00f5rku, selle struktuur, siseteenused Blackfoot ja HyperPlane, m\u00fcra probleemi, ning l\u00f5puks \u2014 v\u00f5rgu ulatus, selgroog ja f\u00fc\u00fcsilised kaablid. K\u00f5igest sellest allpool.<\/p>\n

Distsipliin: k\u00f5ik, mis allpool on \u2014 Vasilii isiklik arvamus ja see ei pruugi kajastada Amazon Web Services'i seisukohti.<\/i>
\n<\/a><\/noindex><\/p>\n

V\u00f5rgu skaleerimine<\/h2>\n

\nAWS pilv k\u00e4ivitati 2006. aastal. Selle v\u00f5rk oli piisavalt primitiivne \u2014 lapiku struktuuriga. Privaatsete aadresside vahemik oli k\u00f5igi pilve\u00fc\u00fcrnike jaoks \u00fchine. Uue virtuaalse masina k\u00e4ivitamisel said sa juhuslikult saadaval oleva IP-aadressi sellest vahemikust.<\/p>\n

\"Kuidas
\n
\nSee l\u00e4henemine oli lihtne teostada, kuid p\u00f5him\u00f5tteliselt piiras pilve kasutamist. Eelk\u00f5ige oli \u00e4\u00e4rmiselt keeruline arendada h\u00fcbriidlahendusi, kus liideti maapealsed ja AWS-i erav\u00f5rgud. Levinum probleem oli IP-aadresside vahemike kattumine.<\/p>\n

\"Kuidas
\n<\/p>\n

Virtuaalne Privaatsusv\u00e4li<\/h3>\n

\nPilv osutus n\u00f5utud. On aeg m\u00f5elda skaleeritavusele ja v\u00f5imalusele seda kasutada k\u00fcmnete miljonite \u00fc\u00fcrnike poolt. Lame v\u00f5rk oli peamine takistus. Seet\u00f5ttu m\u00f5tlesime, kuidas isoleerida kasutajaid \u00fcksteisest v\u00f5rgu tasandil, et nad saaksid iseseisvalt valida IP-vahemikke.<\/p>\n

\"Kuidas
\n
\nMis esimene m\u00f5te tuleb p\u00e4he, kui m\u00f5tlete v\u00f5rgu isoleerimisele? Loomulikult VLAN<\/b> ja VRF \u2014 Virtuaalne Suunamine ja Edastamine<\/b>.<\/p>\n

Kahjuks see ei \u00f5nnestunud. VLAN ID on vaid 12 bittine, mis annab meile ainult 4096 isoleeritud segmenti. Isegi suurimates l\u00fclitites saab kasutada maksimaalselt 1-2 tuhat VRF-i. VRF-i ja VLAN-i jagamine annab meile vaid m\u00f5ned miljonid alamv\u00f5rgud. Seda on kindlasti liiga v\u00e4he k\u00fcmnete miljonite tenantide jaoks, kellel k\u00f5igil peab olema v\u00f5imalus kasutada mitmeid alamv\u00f5rke.<\/p>\n

Me ei saa endale lubada osta vajaliku arvu suuri seadmeid, n\u00e4iteks Cisco v\u00f5i Juniperilt. Sellel on kaks p\u00f5hjust: see on \u00fclimalt kallis ja me ei taha sattuda s\u00f5ltuvusse nende arendus- ja patchimisprotsessidest.<\/p>\n

Kokkuv\u00f5te on \u2013 k\u00fcpsetada omaenda lahendus.<\/p><\/blockquote>\n

\n2009. aastal kuulutasime v\u00e4lja VPC.<\/b> \u2014 Virtuaalne Privaatsusv\u00e4li<\/b>. Nimi on juurdunud ja n\u00fc\u00fcd kasutavad seda ka paljud pilveteenuse pakkujad.<\/p>\n

VPC \u2013 see on virtuaalne v\u00f5rk SDN<\/b> (Software Defined Network). Otsustasime, et ei hakka leiutama spetsiaalseid protokolle L2 ja L3 tasanditel. V\u00f5rk t\u00f6\u00f6tab standardse Etherneti ja IP p\u00f5hjal. Andmete edastamiseks virtuaalmasinate vahel kapseldatakse liiklus meie enda protokolli m\u00e4hisesse. Selles m\u00e4\u00e4ratakse ID, mis kuulub VPC tenantile.<\/p>\n

\"Kuidas
\n
\nTundub lihtne. Siiski tuleb lahendada mitmeid t\u00f5siseid tehnilisi \u00fclesandeid. N\u00e4iteks, kus ja kuidas salvestada andmed virtuaalsete MAC\/IP-aadresse, VPC ID-d ja vastavaid f\u00fc\u00fcsilisi MAC\/IP. AWS-i mastaabis on see hiiglaslik tabel, mis peab t\u00f6\u00f6tama minimaalse viivitusega p\u00e4ringute korral. Selle eest vastutab mappimise teenus<\/b>, mis on laiali hajutatud \u00fcle kogu v\u00f5rgu.<\/p>\n

Uute p\u00f5lvkondade masinates toimub kapseldamine Nitro kaartide kaudu riistvaratasemel. Vanemates instantsides on kapseldamine ja de-kapseldamine tarkvaraline.\u00a0<\/p>\n

\"Kuidas
\n
\nVaatame \u00fcldiselt, kuidas see t\u00f6\u00f6tab. Alustame L2 tasemelt. Oletame, et meil on virtuaalmasin IP-iga 10.0.0.2 f\u00fc\u00fcsilisel serveril 192.168.0.3. See saadab andmeid virtuaalmasinale 10.0.0.3, mis asub aadressil 192.168.1.4. Koostatakse ARP-p\u00e4ring, mis j\u00f5uab v\u00f5rgu Nitro kaardini. Lihtsuse huvides eeldame, et m\u00f5lemad virtuaalmasinad elavad samas \"sinises\" VPC-s.<\/p>\n

\"Kuidas
\n
\nKaart asendab l\u00e4hteaadressi oma enda aadressiga ja edastab ARP-raami mappimise teenusele.<\/p>\n

\"Kuidas
\n
\nMappimise teenus tagastab teabe, mis on vajalik f\u00fc\u00fcsilises L2-v\u00f5rgus edastamiseks.<\/p>\n

\"Kuidas
\n
\nNitro-kaart ARP-vastuses asendab f\u00fc\u00fcsilises v\u00f5rgus MAC-aadressi VPC-aadressiga.<\/p>\n

\"Kuidas
\n
\nAndmete edastamisel pakime loogilised MAC ja IP VPC-kattes. K\u00f5ik see edastatakse f\u00fc\u00fcsilises v\u00f5rgus vastava IP Nitro-kaardi abil, kus allikas ja sihtkoht.<\/p>\n

\"Kuidas
\n
\nF\u00fc\u00fcsiline masin, kellele pakett on m\u00f5eldud, teeb kontrolli. See on vajalik, et v\u00e4ltida aadresside vale esitamist. Masin saadab spetsiaalse p\u00e4ringu kaardistamisteenusele ja k\u00fcsib: \"F\u00fc\u00fcsiliselt masinalt 192.168.0.3 sain paketi, mis on m\u00f5eldud 10.0.0.3 'sinisesse' VPC-sse. Kas see on legaalne?\"\u00a0<\/p>\n

\"Kuidas
\n
\nKaardistamisteenus kontrollib oma ressursipaigutuse tabelit ja lubab v\u00f5i keelab paketi edastamise. K\u00f5ikides uutest instantsidest on t\u00e4iendav valideerimine Nitro-kaartidesse sisse ehitatud. Seda ei ole isegi teoreetiliselt v\u00f5imalik m\u00f6\u00f6da hiilida. Seet\u00f5ttu ei toimi teiste VPC-de ressursside vale esitamine.<\/p>\n

\"Kuidas
\n
\nSeej\u00e4rel saadetakse andmed virtuaalsesse masinasse, kellele need on m\u00f5eldud.\u00a0<\/p>\n

\"Kuidas
\n
\nKaardistamisteenus toimib ka loogilise ruuterina andmete edastamiseks erinevates alamisv\u00f5rkudes asuvate virtuaalmasinate vahel. Seal on k\u00f5ik kontseptuaalselt lihtne, ei hakka seda \u00fcksikasjalikult selgitama.<\/p>\n

\"Kuidas
\n
\nSeega, iga paketi edastamisel p\u00f6\u00f6rduvad serverid kaardistamisteenuse poole. Kuidas leevendada v\u00e4ltimatuid viivitusi? K\u00fcsimusele aitab vastata vahem\u00e4llu salvestamine<\/b>, loomulikult.<\/p>\n

Kogu ilu seisneb selles, et ei ole vaja salvestada kogu tohutut tabelit. F\u00fc\u00fcsilisel serveril elavad virtuaalsed masinad suhteliselt v\u00e4ikse arvu VPC-de seest. Vahem\u00e4llu tuleb salvestada vaid nende VPC-de info. Andmete edastamine teistesse VPC-desse \u201evaikimisi\u201d konfiguratsioonis ei ole siiski legit. Kui kasutada sellist funktsionaalsust nagu VPC-peering, lisatakse vahem\u00e4llu lisainfos vastavad VPC-d.\u00a0<\/p>\n

\"Kuidas
\n
\nAndmete edastamisega VPC-sse saime hakkama.<\/p>\n

Blackfoot<\/h3>\n

\nKuidas olla olukordades, kus tuleb edastada liiklust v\u00e4ljaspoole, n\u00e4iteks Internetti v\u00f5i VPN-i kaudu allapoole? Siin p\u00e4\u00e4stab meid Blackfoot<\/b> \u2014 sisemine AWS-teenus. See on loodud meie L\u00f5una-Aafrika meeskonna poolt. Seet\u00f5ttu on teenuse nimi p\u00fchendatud pingviinile, kes elab L\u00f5una-Aafrikas.<\/p>\n

\"Kuidas
\n
\nBlackfoot dekapsuleerib liiklust ja teeb sellega, mis on vajalik. Andmed saadetakse Internetti sellisena nagu nad on.<\/p>\n

\"Kuidas
\n
\nAndmed dekapsuleeritakse ja keeratakse taas IPsec-i \u00fcmbrisesse, kui kasutatakse VPN-i.<\/p>\n

\"Kuidas
\n
\nDirect Connecti kasutamisel m\u00e4rgistatakse ja edastatakse liiklus vastavasse VLAN-i.<\/p>\n

\"Kuidas
\n<\/p>\n

HyperPlane<\/h3>\n

\nSee on sisevoogude j\u00e4lgimise teenus. Paljud v\u00f5rguteenused n\u00f5uavad voogude kontrollimist andmete voogude olek<\/b>. N\u00e4iteks NAT-i kasutamisel peab voogude juhtimine tagama, et igale \"IP: sihtport\" paarile vastab ainulaadne v\u00e4ljuv port. Koos tasakaalustajaga NLB<\/b> \u2014 V\u00f5rgutasakaalu tasandaja<\/b>, peab andmevoog alati suunama samasse sihtvirtuaalmasinasse. Turvagrupp on olekus\u00e4ilitav tulem\u00fc\u00fcr. See j\u00e4lgib sissetulevat liiklust ja avab vaikimisi sadamad v\u00e4ljuvatele pakettidele.<\/p>\n

\"Kuidas
\n
\nAWS-s on edastusviivituse n\u00f5udmised \u00e4\u00e4rmiselt k\u00f5rged. Seet\u00f5ttu HyperPlane<\/b> on see kogu v\u00f5rgu toimimise jaoks kriitiline.<\/p>\n

\"Kuidas
\n
\nHyperplane on \u00fcles ehitatud EC2 virtuaalmasinatele. Siin pole mingit imet, vaid vaid petmine. Petmine seisneb selles, et need on virtuaalmasinad suure m\u00e4lu mahuga. Tehingud viiakse l\u00e4bi eranditult m\u00e4lus. See v\u00f5imaldab saavutada viivitusi vaid k\u00fcmnete mikrosekunditega. T\u00f6\u00f6 ketas oleks tapnud kogu j\u00f5udluse.\u00a0<\/p>\n

Hyperplane on hajutatud s\u00fcsteem, mis koosneb suurest hulgast EC2-masinatest. Igal virtuaalmasinal on l\u00e4bilaskev\u00f5ime 5 GB\/s. Kogu piirkondliku v\u00f5rgu ulatuses annab see metsiku terabittide l\u00e4bilaskev\u00f5ime ja v\u00f5imaldab t\u00f6\u00f6tleda miljoneid \u00fchendusi sekundis<\/b>.<\/p>\n

HyperPlane t\u00f6\u00f6tab ainult voogude p\u00f5hjal. VPC pakettide inkapsuleerimine on selle jaoks t\u00e4iesti l\u00e4bipaistev. Potentsiaalne haavatavus selles siseteenuses ei v\u00f5imalda ikkagi VPC isolatsiooni murda. Turvalisuse tagavad madalamad tasemed.<\/p>\n

Noisy neighbor<\/h3>\n

\nOn veel \u00fcks probleem m\u00fcrarikka naabri<\/b> \u2014 noisy neighbor<\/b>. \u00dctleme, et meil on 8 s\u00f5lme. Need s\u00f5lmed t\u00f6\u00f6tlevad k\u00f5igi pilv kasutajate vooge. Tundub, et k\u00f5ik on korras ja koormus peaks olema \u00fchtlaselt jaotatud k\u00f5ikidele s\u00f5lmedele. S\u00f5lmed on v\u00e4ga v\u00f5imsad ja neid on keeruline \u00fcle koormata.<\/p>\n

Aga me ehitame oma arhitektuuri isegi v\u00e4hem t\u00f5en\u00e4oliste stsenaariumide p\u00f5hjal.\u00a0<\/p>\n

Madala t\u00f5en\u00e4osuse ei t\u00e4henda, et see oleks v\u00f5imatu.<\/p><\/blockquote>\n

\nMe v\u00f5ime ette kujutada olukorda, kus \u00fcks v\u00f5i mitu kasutajat genereerivad liiga suurt koormust. Selle koormuse t\u00f6\u00f6tlemises on kaasatud k\u00f5ik HyperPlane'i s\u00f5lmed ja teised kasutajad v\u00f5ivad potentsiaalselt tunda mingit j\u00f5udluse langust. See rikub pilve kontseptsiooni, kus tenantidel ei ole v\u00f5imalik \u00fcksteisele m\u00f5ju avaldada.<\/p>\n

\"Kuidas
\n
\nKuidas lahendada m\u00fcra tegeva naabri probleem? Esimene asi, mis p\u00e4he tuleb \u2013 shardimine. Meie 8 s\u00f5lme jagunevad loogiliselt 4 shardiks, igas 2 s\u00f5lmega. N\u00fc\u00fcd h\u00e4irib m\u00fcra tegeva naabri tegevus vaid neljandikku k\u00f5igist kasutajatest, kuid siiski oluliselt.<\/p>\n

\"Kuidas
\n
\nTeeme teisiti. Iga\u00fchele jagame vaid 3 s\u00f5lme.\u00a0<\/p>\n

\"Kuidas
\n
\nNipp on m\u00e4\u00e4rata erinevate kasutajate s\u00f5lmed juhuslikult. Alloleval pildil ristuvad sinise kasutaja s\u00f5lmed \u00fche kahel teisel kasutajal \u2013 rohelisel ja oran\u017eil.<\/p>\n

\"Kuidas
\n
\n8 s\u00f5lme ja 3 kasutajaga on m\u00fcrarikka naaberi sissetungi t\u00f5en\u00e4osus \u00fche kasutaja osas 54%. Just sellise t\u00f5en\u00e4osusega avaldab sinine kasutaja m\u00f5ju teistele \u00fc\u00fcrnikele. Samas on see m\u00f5ju m\u00e4rgatav vaid kolmandikule k\u00f5ikidest kasutajatest. See on juba korralik tulemus.<\/p>\n

Kasutajate arv, kes ristuvad<\/p>\n

T\u00f5en\u00e4osus protsentides<\/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\u00e4hendame olukorda reaalsusele \u2014 v\u00f5tame 100 s\u00f5lme ja 5 kasutajat 5 s\u00f5lmes. Sellisel juhul ei ristu \u00fckski s\u00f5lm t\u00f5en\u00e4osusega 77%.\u00a0<\/p>\n

Kasutajate arv, kes ristuvad<\/p>\n

T\u00f5en\u00e4osus protsentides<\/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

Reaalses olukorras, kui HyperPlane s\u00f5lmi ja kasutajaid on suur hulk, on m\u00fcrarikka naabri m\u00f5ju teistele kasutajatele minimaalne. Seda meetodit nimetatakse segavaks shardinguks<\/b> \u2014 shuffle sharding<\/b>. See minimeerib s\u00f5lmede rikke negatiivset m\u00f5ju.<\/p>\n

HyperPlane'i p\u00f5hjal on loodud palju teenuseid: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

V\u00f5rgu ulatused<\/h3>\n

\nN\u00fc\u00fcd r\u00e4\u00e4gime v\u00f5rgu ulatusest. Oktoobris 2019 pakub AWS oma teenuseid 22 piirkonnas<\/b>, lisaks on plaanis veel 9.<\/p>\n