{"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 \u201ekeedab\u201d oma elastseid teenuseid. V\u00f5rgu skaleerimine","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Amazon Web Servicesi v\u00f5rgu ulatus ulatub 69 tsooni kogu maailmas 22 regioonis: Ameerika \u00dchendriigid, Euroopa, Aasia, Aafrika ja Austraalia. Igas tsoonis asub kuni 8 andmekeskust. Igas andmekeskuses on tuhandeid v\u00f5i sadu tuhandeid servereid. S\u00fcsteem on \u00fcles ehitatud nii, et arvesse on v\u00f5etud k\u00f5ik ebat\u00f5en\u00e4olised katkestamise stsenaariumid. N\u00e4iteks on k\u00f5ik regioonid teineteisest isoleeritud ning k\u00e4ttesaadavuse tsoonid paiknevad mitme kilomeetri kaugusel \u00fcksteisest. Isegi kui kaabel katkeb, suundub s\u00fcsteem varu\u00fchendustele ning andmete kadu on minimaalne. Millistel muudel p\u00f5him\u00f5tetel v\u00f5rku on ehitatud ja kuidas see toimib, r\u00e4\u00e4gib Vasili Pantjuhin.<\/p>\n

\"Kuidas
\n
\nVassili Pantiuhin<\/b> hakkas Unix-administraatorina t\u00f6\u00f6tama .ru ettev\u00f5tetes, tegeles 6 aastat suurte Sun Microsystem masinatega, 11 aastat propageeris ta andmekeskuste keskset rolli EMC-s. Loomulikult arenes ta v\u00e4lja erasektorisse, seej\u00e4rel liikus avalikku. Praegu, Amazon Web Servicesi arhitektilt, annab ta tehnilisi n\u00f5uandeid, kuidas AWS-is elada ja areneda.<\/p>\n

Triloogia eelmisel osal r\u00e4\u00e4kis Vasili f\u00fc\u00fcsiliste serverite \u00fclesehitusest ja andmebaasi skaleerimisest. Nitro-kaardid, kohandatud KVM-p\u00f5hine h\u00fcperviisor, Amazon Aurora andmebaas \u2014 k\u00f5igest sellest loe artiklis \"Kuidas AWS \u00abkeedab\u00bb oma elastseid teenuseid. Serverite ja andmebaaside skaleerimine<\/a><\/noindex>\". Lugege, et s\u00fcveneda konteksti, v\u00f5i vaata videomaterjal<\/a><\/noindex> esitlusi.<\/p>\n

Selles osas r\u00e4\u00e4gitakse v\u00f5rgu skaleerimisest \u2014 \u00fchest k\u00f5ige keerulisemast s\u00fcsteemist AWS-is. Evolutsioon tasapinnalisest v\u00f5rgust Virtual Private Cloud'i ning selle \u00fclesehitus, siseteenused Blackfoot ja HyperPlane, m\u00fcrarikka naabri probleem ning l\u00f5pus \u2014 v\u00f5rgu ulatused, backbone ja f\u00fc\u00fcsilised kaablid. K\u00f5igest sellest alapealkirja all.<\/p>\n

Eemaldatud: k\u00f5ik, mis allpool, on Vasili isiklik arvamus ja see ei pruugi kattuda Amazon Web Services'i seisukohaga.<\/i>
\n<\/a><\/noindex><\/p>\n

V\u00f5rgu skaleerimine<\/h2>\n

\nAWS-i pilv k\u00e4ivitati 2006. aastal. Selle v\u00f5rk oli suhteliselt primitiivne \u2014 tasapinnaline struktuur. Erakliendi aadresside ulatus oli k\u00f5igi pilve \u00fc\u00fcrnike jaoks \u00fchine. Uue virtuaalse masina k\u00e4ivitamisel said te juhuslikult \u00fche selle ulatuse IP-aadressi.<\/p>\n

\"Kuidas
\n
\nSelline l\u00e4henemine oli lihtne teostada, kuid piiras oluliselt pilve kasutamist. Eriti oli keeruline arendada h\u00fcbriidlahendusi, kus \u00fchendatakse maapealsed ja AWS-i erav\u00f5rgud. Levinud probleem oli IP-aadressi ulatuste kattumine.<\/p>\n

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

Virtual Private Cloud<\/h3>\n

\nPilv on osutunud n\u00f5udlikuks. On aeg m\u00f5elda skaleeritavusele ja v\u00f5imalusele kasutada seda k\u00fcmneid miljoneid \u00fc\u00fcrnikke. Lame v\u00f5rk on saanud peamiseks takistuseks. Seet\u00f5ttu m\u00f5tleme, kuidas saaksime kasutajaid \u00fcksteisest v\u00f5rgu tasandil isoleerida, et nad saaksid iseseisvalt valida IP-aadresse.<\/p>\n

\"Kuidas
\n
\nMis tuleb esimesena meelde, kui m\u00f5tlete v\u00f5rgu isoleerimisele? Loomulikult VLAN<\/b> ja VRF \u2014 virtuaalne marsruutimine ja edastamine<\/b>.<\/p>\n

Kahjuks see ei t\u00f6\u00f6tanud. VLAN ID on vaid 12 bitti, mis annab meile k\u00f5igest 4096 isoleeritud segmenti. Isegi suurimatel l\u00fclititel 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 \u00fc\u00fcrnike jaoks, kellel k\u00f5igil peab olema v\u00f5imalus kasutada mitmeid alamv\u00f5rke.<\/p>\n

Lisaks ei saa me endale lubada osta vajalike suurte kastide hulka, n\u00e4iteks Cisco v\u00f5i Juniperi juures. Sellel on kaks p\u00f5hjust: see on uskumatult kallis ja me ei soovi saada s\u00f5ltuvaks nende arendus- ja v\u00e4rskenduspoliitikast.<\/p>\n

Kokkuv\u00f5tteks \u2013 tuleb keeta oma lahendus.<\/p><\/blockquote>\n

\nAastal 2009 kuulutasime me v\u00e4lja VPC<\/b> \u2014 Virtual Private Cloud<\/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> (Tarkvara m\u00e4\u00e4ratud v\u00f5rk). Otsustasime mitte v\u00e4lja m\u00f5elda spetsiaalseid protokolle L2 ja L3 tasanditel. V\u00f5rk t\u00f6\u00f6tab standardse Etherneti ja IP-ga. Masinate liiklus pakitakse meie patenteeritud protokolli \u00fcmbrikku. Sellega m\u00e4\u00e4ratakse ID, mis kuulub VPC \u00fc\u00fcrnikule.<\/p>\n

\"Kuidas
\n
\nSee k\u00f5lab lihtsalt. Kuid probleemide lahendamiseks tuleb lahendada mitmeid t\u00f5siseid tehnilisi v\u00e4ljakutseid. N\u00e4iteks, kus ja kuidas hoida andmeid virtuaalsete MAC\/IP-aadresse, VPC ID ja vastavaid f\u00fc\u00fcsilisi MAC\/IP. AWS ulatuses on see tohutu tabel, mis peab t\u00f6\u00f6tama minimaalsete viivitustega p\u00e4ringute korral. Selle eest vastutab mappauditeenuseid<\/b>, mis on laiali jaotatud \u00f5hukese kihina kogu v\u00f5rgus.<\/p>\n

Uue p\u00f5lvkonna masinates toimub pakettimine Nitro kaartide kaudu riistvaral tasandil. Vanemates instantsides toimub pakettimine ja dekapituleerimine tarkvaraliselt.\u00a0<\/p>\n

\"Kuidas
\n
\nVaatame, kuidas see t\u00f6\u00f6tab \u00fcldiselt. Alustame L2 tasemelt. Oletame, et meil on virtuaalmasin, mille IP on 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-kaardile. Lihtsuse huvides oletame, et m\u00f5lemad virtuaalmasinad asuvad samas \"sinises\" VPCs.<\/p>\n

\"Kuidas
\n
\nKaart asendab allika aadressi oma enda omaga ja edastab ARP-raami maapealse teenuse mapeerimisele.<\/p>\n

\"Kuidas
\n
\nMapeerimisteenus tagastab teabe, mida vajatakse f\u00fc\u00fcsilisel L2 v\u00f5rgul andmete edastamiseks.<\/p>\n

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

\"Kuidas
\n
\nAndmete edastamisel pakime loogilised MAC ja IP VPC-katetesse. Edastame selle k\u00f5ik f\u00fc\u00fcsilisel v\u00f5rgul vastava IP Nitro-kaardi allika ja sihtkoha kaudu.<\/p>\n

\"Kuidas
\n
\nF\u00fc\u00fcsiline masin, kellele paket on m\u00f5eldud, teostab kontrolli. See on vajalik aadresside valeleidmise v\u00e4listamiseks. Masin saadab spetsiaalse p\u00e4ringu mapeerimisteenusele ja k\u00fcsib: \"F\u00fc\u00fcsiliselt masinast 192.168.0.3 sain paketi, mis on m\u00f5eldud 10.0.0.3 sinises VPCs. Kas see on legitiimne?\"\u00a0<\/p>\n

\"Kuidas
\n
\nMapeerimisteenus kontrollib oma ressursside asukoha tabelit ja kas lubab v\u00f5i keelab paketi edasiviimise. K\u00f5ikides uutes instantsides on Nitro-kaartidesse sisse ehitatud t\u00e4iendav valideerimine. Selle t\u00f5kestamine ei ole isegi teoreetiliselt v\u00f5imalik. Seega spoofing teistesse VPC-desse ei toimi.<\/p>\n

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

\"Kuidas
\n
\nMapeerimisteenus t\u00f6\u00f6tab ka loogilise marsruuterina andmete edastamiseks erinevates alv\u00f5rkudes paiknevate virtuaalmasinate vahel. Seal on kontseptsiooniliselt k\u00f5ik lihtne, ma ei hakka seda detailselt k\u00e4sitlema.<\/p>\n

\"Kuidas
\n
\nTuleb v\u00e4lja, et igal paketi edastamisel p\u00f6\u00f6rdub server maapeerse teenuse mapeerimise poole. Kuidas tulla toime v\u00e4ltimatute viivitustega? Vahem\u00e4lu loomisega<\/b>, loomulikult.<\/p>\n

K\u00f5ige parem on see, et ei ole vaja vahem\u00e4llu salvestada tervet tohutut tabelit. F\u00fc\u00fcsilisel serveril asuvad virtuaalmasinad suhteliselt v\u00e4heste VPC-de seas. Vahem\u00e4llu tuleb salvestada teave ainult nende VPC-de kohta. Andmete edastamine teistesse VPC-desse \"vaikimisi\" konfiguratsioonis ei ole ikkagi legitiimne. Kui kasutatakse sellist funktsionaalsust nagu VPC-leading, siis laaditakse vahem\u00e4llu t\u00e4iendavalt vastava VPC teave.\u00a0<\/p>\n

\"Kuidas
\n
\nAndmete edastamises VPC-s saime selgeks.<\/p>\n

Blackfoot<\/h3>\n

\nKuidas toimida olukordades, kui liiklust tuleb edastada v\u00e4ljapoole, n\u00e4iteks Internetti v\u00f5i VPN kaudu maapinnale? Siin aitab meid Blackfoot<\/b> \u2014 sisemine AWS teenus. See on v\u00e4lja t\u00f6\u00f6tatud meie L\u00f5una-Aafrika meeskonna poolt. Seet\u00f5ttu on teenus nimetatud L\u00f5una-Aafrikas elava pingviini j\u00e4rgi.<\/p>\n

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

\"Kuidas
\n
\nAndmed dekapsuleeritakse ja pakendatakse uuesti IPsec-katte alla, kui kasutatakse VPN-i.<\/p>\n

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

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

HyperPlane<\/h3>\n

\nSee on sisemine voo juhendamise teenus. Paljud v\u00f5rguteenused n\u00f5uavad voo juhtimist andmevoo seisundi<\/b>. N\u00e4iteks NAT-i kasutamisel peab voo juhtimine tagama, et iga \u00abIP: sihtport\u00bb paar vastab unikaalsele v\u00e4ljaminevale pordile. Koormuse tasakaalu puhul NLB<\/b> \u2014 V\u00f5rgu Koormuse Tasakaalustaja<\/b>, peab andmevoog alati olema suunatud \u00fchte ja samasse sihtvirtualmasinasse. Turvar\u00fchmad on olekuga tulem\u00fc\u00fcr. See j\u00e4lgib sissetulevat liiklust ja avab automaatselt pordid v\u00e4ljamineva andmevoo jaoks.<\/p>\n

\"Kuidas
\n
\nAWS pilves on edastuslatentsusohtlikud n\u00f5uded \u00e4\u00e4rmiselt k\u00f5rged. Seet\u00f5ttu HyperPlane<\/b> on kriitiline kogu v\u00f5rgu t\u00f6\u00f6kindluse jaoks.<\/p>\n

\"Kuidas
\n
\nHyperplane on \u00fcles ehitatud EC2 virtuaalmasinatele. Siin pole mingit maagiat, vaid ainult trikk. Trikk seisneb selles, et need on virtuaalmasinad suure RAM-i mahuga. Tehingud on ja need toimuvad eranditult m\u00e4lus. See v\u00f5imaldab saavutada viivitusi vaid k\u00fcmnendik mikrosekundeid. T\u00f6\u00f6 kettaga h\u00e4vitaks kogu j\u00f5udluse.\u00a0<\/p>\n

Hyperplane on jagatud s\u00fcsteem, mis koosneb tohutust arvust sellistest EC2 masinatest. Igal virtuaalmasinal on l\u00e4bilaskev\u00f5ime 5 GB\/s. Terve piirkonna v\u00f5rgu perspektiivis annab see massiivse terabitti l\u00e4bilaskev\u00f5ime ja v\u00f5imaldab t\u00f6\u00f6delda miljoneid \u00fchendusi sekundis<\/b>.<\/p>\n

HyperPlane t\u00f6\u00f6tab ainult andmevoogudega. VPC pakettide kapseldamine on selle jaoks t\u00e4iesti l\u00e4bipaistev. Selle sisemise teenuse potentsiaalne haavatavus ei v\u00f5imalda siiski VPC-isolatsiooni l\u00e4bida. Turvalisuse eest vastutavad madalamad tasemed.<\/p>\n

H\u00e4iritud naaber<\/h3>\n

\nOn veel probleem h\u00e4iriva naabri<\/b> \u2014 h\u00e4iriv naaber<\/b>. Oletame, et meil on 8 nodi. Need noded t\u00f6\u00f6tlevad k\u00f5ikide pilvekasutajate vooge. Tundub, et k\u00f5ik on h\u00e4sti ja koormus peaks olema \u00fchtlaselt jaotatud k\u00f5igi nodide vahel. Nodid on v\u00e4ga v\u00f5imsad ja neid on raske \u00fclet\u00e4ita.<\/p>\n

Kuid me ehitame oma arhidektuuri isegi v\u00e4het\u00f5en\u00e4olistest stsenaariumidest l\u00e4htuvalt.\u00a0<\/p>\n

Madala t\u00f5en\u00e4osus ei t\u00e4henda v\u00f5imatust.<\/p><\/blockquote>\n

\nSaame ette kujutada olukorda, kus \u00fcks v\u00f5i mitu kasutajat genereerivad liiga suurt koormust. K\u00f5ik HyperPlane nodid on seotud selle koormuse t\u00f6\u00f6tlemisse ja teised kasutajad v\u00f5ivad kogeda mingisugust j\u00f5udluse langust. See rikub pilve kontseptsiooni, kus \u00fc\u00fcrnikud ei saa teineteisele m\u00f5ju avaldada.<\/p>\n

\"Kuidas
\n
\nKuidas lahendada l\u00e4rmakate naabrite probleem? Esimene asi, mis p\u00e4he tuleb - shardimine. Meie 8 nodi jagunevad loogiliselt 4 shardiks, igas 2 nodi. N\u00fc\u00fcd segab l\u00e4rmakas naaber vaid neljandikku k\u00f5ikidest kasutajatest, kuid selle m\u00f5ju on siiski tugev.<\/p>\n

\"Kuidas
\n
\nTeeme teistmoodi. Iga\u00fchele kasutajale eraldame vaid 3 nodi.\u00a0<\/p>\n

\"Kuidas
\n
\nNipin on m\u00e4\u00e4rata nodid erinevatele kasutajatele juhuslikult. Alloleval pildil on sinine kasutaja \u00fchenduses \u00fche teise kasutajaga - rohelise ja oran\u017eiga.<\/p>\n

\"Kuidas
\n
\n8 nodi ja 3 kasutaja korral on l\u00e4rmakate naabrite t\u00f5en\u00e4osus teiste kasutajatega seonduda 54%. Just selle t\u00f5en\u00e4osusega m\u00f5jutab sinine kasutaja teisi \u00fc\u00fcrnikke. Samuti ainult osa oma koormusest. Meie n\u00e4ites on see m\u00f5ju m\u00e4rgatav vaid kolmandikule k\u00f5ikidest kasutajatest. See on juba hea 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\u00e4heneme olukorrale reaalsetele tingimustele - v\u00f5tame 100 nodi ja 5 kasutajat 5 nodit. Sellisel juhul ei \u00fchildu \u00fckski nod 77% t\u00f5en\u00e4osusega.\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, kus on tohutult palju HyperPlane nodi ja kasutajaid, on l\u00e4rmakate naabrite potentsiaalne m\u00f5ju teistele kasutajatele minimaalne. Seda meetodit nimetatakse shuffle sharding<\/b> \u2014 . See minimeerib negatiivseid m\u00f5jusid nodide rikete korral.<\/b>HyperPlane'i baasil on ehitatud palju teenuseid: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

V\u00f5rgumahud<\/p>\n

V\u00f5rgu ulatus<\/h3>\n

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