{"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\/sl\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Kako AWS 'kuha' svoje elasti\u010dne storitve. Raz\u0161iritev omre\u017eja","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mre\u017ea Amazon Web Services obuhva\u0107a 69 zona \u0161irom sveta u 22 regiona: Sjedinjene Ameri\u010dke Dr\u017eave, Evropa, Azija, Afrika i Australija. U svakoj zoni se nalazi do 8 data centara. U svakom data centru su hiljade ili stotine hiljada servera. Mre\u017ea je izgra\u0111ena tako da uzima u obzir sve malo verovatne scenarije prekida rada. Na primer, svi regioni su me\u0111usobno izolovani, a dostupne zone su raspore\u0111ene na udaljenostima od nekoliko kilometara. \u010cak i ako se kabl prese\u010de, sistem \u0107e pre\u0107i na rezervne kanale, a gubici informacija bi\u0107e minimalni. O principima na kojima se mre\u017ea zasniva i njenoj strukturi govori\u0107e Vasiliy Pantiukhin.<\/p>\n

\"Kako
\n
\nVasilij Pantjuhin<\/b> zapo\u010deo kao Unix administrator u .ru kompanijama, 6 godina se bavio velikim hardverom Sun Microsystem, 11 godina evangelizovao je datacentri\u010dnu prirodu sveta u EMC-u. Prirodno je evoluirao ka privatnim cloud re\u0161enjima, a zatim pre\u0161ao na javne. Sada, kao arhitekta Amazon Web Services, pru\u017ea tehni\u010dke savete kako da \u017eive i razvijaju se u AWS cloudu.<\/p>\n

U prethodnom delu trilogije o strukturi AWS-a, Vasiliy se dublje upustio u strukturu fizi\u010dkih servera i skaliranja baze podataka. Nitro kartice, prilago\u0111eni hipervizor zasnovan na KVM-u, baza podataka Amazon Aurora \u2014 o svemu ovome pi\u0161e u materijalu \u201eKako AWS 'kuha' svoje elasti\u010dne storitve. Raz\u0161iritev stre\u017enikov in baz podatkov<\/a><\/noindex>\u201c. Pro\u010ditajte da se uronite u kontekst ili pogledajte video posnetek<\/a><\/noindex> izlaganja.<\/p>\n

U ovom delu \u0107e se govoriti o skaliranju mre\u017ee \u2014 jednom od najslo\u017eenijih sistema u AWS-u. Evolucija od ravne mre\u017ee do Virtual Private Cloud-a i njena struktura, unutra\u0161nje usluge Blackfoot i HyperPlane, problem bu\u010dnog kom\u0161ije, a na kraju \u2014 razmere mre\u017ee, backbone i fizi\u010dki kablovi. O svemu ovome ispod.<\/p>\n

Disklejmer: sve \u0161to sledi su li\u010dna mi\u0161ljenja Vasiliyja i ona se mo\u017eda ne\u0107e poklapati sa stavovima Amazon Web Services.<\/i>
\n<\/a><\/noindex><\/p>\n

Skaliranje omre\u017eja<\/h2>\n

\nAWS cloud je lansiran 2006. godine. Njegova mre\u017ea je bila dovoljno primitivna \u2014 sa ravnom strukturom. Opseg privatnih adresa bio je zajedni\u010dki za sve zakupce clouda. Kada biste pokrenuli novu virtuelnu ma\u0161inu, slu\u010dajno ste dobijali dostupnu IP adresu iz ovog opsega.<\/p>\n

\"Kako
\n
\nOvakav pristup je bio jednostavan za implementaciju, ali je su\u0161tinski ograni\u010davao kori\u0161\u0107enje clouda. Konkretno, bilo je posebno te\u0161ko razvijati hibridna re\u0161enja koja su kombinovala privatne mre\u017ee na zemlji i u AWS-u. Naj\u010de\u0161\u0107i problem bio je u preklapanju opsega IP adresa.<\/p>\n

\"Kako
\n<\/p>\n

Virtual Private Cloud<\/h3>\n

\nOblak se je izkazal za potreben. Pri\u0161el je \u010das, da razmislimo o raz\u0161irljivosti in mo\u017enostih njegove uporabe za desetine milijonov najemnikov. Ravna omre\u017eja so postala glavna ovira. Zato smo razmi\u0161ljali, kako izolirati uporabnike drug od drugega na omre\u017eni ravni tako, da bi lahko sami izbirali obsege IP.<\/p>\n

\"Kako
\n
\nKaj vam najprej pride na misel, ko razmi\u0161ljate o omre\u017eni izolaciji? Seveda VLAN<\/b> in VRF \u2013 Virtual Routing and Forwarding<\/b>.<\/p>\n

Na \u017ealost to ni delovalo. VLAN ID je zgolj 12 bitov, kar nam daje le 4096 izoliranih segmentov. Tudi v najve\u010djih stikalu lahko uporabimo najve\u010d 1-2 tiso\u010d VRF. Souporaba VRF in VLAN nam omogo\u010da le nekaj milijonov podomre\u017eij. To je zagotovo premalo za desetine milijonov najemnikov, od katerih mora imeti vsak mo\u017enost uporabe ve\u010d podomre\u017eij.<\/p>\n

Poleg tega si preprosto ne moremo privo\u0161\u010diti nakupa potrebnega \u0161tevila velikih naprav, na primer od Cisco ali Juniper. Dva razloga: to je noro drago in no\u010demo postati odvisni od njihove razvojne in popravne politike.<\/p>\n

Eden zaklju\u010dek je \u2013 skuhati svoje lastne re\u0161itve.<\/p><\/blockquote>\n

\nLeta 2009 smo napovedali VPC<\/b> \u2014 Virtual Private Cloud<\/b>. Ime se je prijelo in zdaj ga uporabljajo tudi mnogi ponudniki oblakov.<\/p>\n

VPC je virtualno omre\u017eje SDN<\/b> (Software Defined Network). Odlo\u010dili smo se, da ne bomo izumljali posebnih protokolov na ravneh L2 in L3. Omre\u017eje deluje na standardnem Ethernetu in IP. Za prenos prometa virtualnih naprav je promet enkapsuliran v ovoj na\u0161ega lastnega protokola. V njem je naveden ID, ki pripada VPC najemnika.<\/p>\n

\"Kako
\n
\nZveni preprosto. Vendar je treba re\u0161iti nekaj resnih tehni\u010dnih izzivov. Na primer, kje in kako shraniti podatke o preslikavi virtualnih MAC\/IP naslovov, VPC ID in ustreznih fizi\u010dnih MAC\/IP. Na ravni AWS to predstavlja ogromno tabelo, ki mora delovati z minimalnimi zakasnitvami pri dostopu. Za to skrbi storitev preslikave<\/b>, ki je razpr\u0161ena po celotnem omre\u017eju.<\/p>\n

V napravah nove generacije se enkapsulacija izvaja z Nitro karticami na strojni ravni. V starej\u0161en instancah so enkapsulacija in deenkapsulacija programski.\u00a0<\/p>\n

\"Kako
\n
\nPoglejmo, kako to deluje v splo\u0161nem. Za\u010dnimo na ravni L2. Predpostavimo, da imamo virtualni stroj z IP 10.0.0.2 na fizi\u010dnem stre\u017eniku 192.168.0.3. Ta po\u0161ilja podatke virtualnemu stroju 10.0.0.3, ki deluje na 192.168.1.4. Oblikuje se ARP-poizvedba, ki pride na omre\u017eno Nitro-karto. Za poenostavitev predpostavimo, da oba virtualna stroja obstajata v istem 'modrem' VPC.<\/p>\n

\"Kako
\n
\nKarta zamenja naslov po\u0161iljatelja s svojim lastnim in posreduje ARP-okvir storitvi za preslikavanje.<\/p>\n

\"Kako
\n
\nStoritev za preslikavanje vrne informacije, ki so potrebne za prenos po fizi\u010dnem omre\u017eju L2.<\/p>\n

\"Kako
\n
\nNitro-karta v ARP-odgovoru zamenja MAC v fizi\u010dnem omre\u017eju z naslovom v VPC.<\/p>\n

\"Kako
\n
\nPri prenosu podatkov ovijemo logi\u010dne MAC in IP v VPC-ovitek. Vse to prenesemo po fizi\u010dnem omre\u017eju s pomo\u010djo ustreznih IP Nitro-kart po\u0161iljatelja in prejemnika.<\/p>\n

\"Kako
\n
\nFizi\u010dni stroj, za katerega je paket namenjen, izvede preverjanje. To je potrebno, da se prepre\u010di mo\u017enost zamenjave naslovov. Stroj po\u0161lje poseben poizvedbni na storitev za preslikavanje in vpra\u0161a: 'Iz fizi\u010dnega stroja 192.168.0.3 sem prejela paket, ki je namenjen 10.0.0.3 v 'modrem' VPC. Je legitimen?'\u00a0<\/p>\n

\"Kako
\n
\nStoritev za preslikavanje preveri svojo tabelo dodeljevanja virov in omogo\u010di ali zavrne prehod paketa. V vseh novih instancah je dodatna validacija vklju\u010dena v Nitro-kartah. Te je teoreti\u010dno nemogo\u010de obiti. Zato spoofing na vire v drugem VPC ne deluje.<\/p>\n

\"Kako
\n
\nNato se podatki po\u0161ljejo virtualnemu stroju, za katerega so namenjeni.\u00a0<\/p>\n

\"Kako
\n
\nStoritev za preslikavanje deluje tudi kot logi\u010dni usmerjevalnik za prenos podatkov med virtualnimi stroji v razli\u010dnih podmre\u017eah. Tam je konceptualno vse preprosto, ne bom podrobno razlagal.<\/p>\n

\"Kako
\n
\nIzkazalo se je, da se ob prenosu vsakega paketa stre\u017eniki obra\u010dajo na storitev za preslikavanje. Kako se boriti proti neizbe\u017enim zamudam? Z predpomnjenjem<\/b>, seveda.<\/p>\n

Celo lepota je v tem, da ni potrebno predpomniti cele ogromne tabele. Na fizi\u010dnem stre\u017eniku \u017eivijo virtualni stroji iz razmeroma majhnega \u0161tevila VPC. Predpomniti je potrebno informacije le o teh VPC. Prenos podatkov v druge VPC v 'privzeti' konfiguraciji kljub temu ni legitimen. \u010ce se uporablja taka funkcionalnost, kot je VPC-peering, se v predpomnilnik dodatno nalo\u017eijo informacije o ustreznih VPC.\u00a0<\/p>\n

\"Kako
\n
\nS prenosom podatkov v VPC smo se \u017ee ukvarjali.<\/p>\n

Blackfoot<\/h3>\n

\nKako postupiti u slu\u010dajevima kada je potrebno prenijeti promet van, na primjer na Internet ili putem VPN-a? Tu nam poma\u017ee Blackfoot<\/b> \u2014 interna usluga AWS-a. Razvila ju je na\u0161a ju\u017enoafri\u010dka ekipa. Stoga se usluga zove po pingvinu koji \u017eivi u Ju\u017enoj Africi.<\/p>\n

\"Kako
\n
\nBlackfoot dekapsulira promet i \u010dini s njim ono \u0161to treba. Podaci se \u0161alju na Internet onakvi kakvi jesu.<\/p>\n

\"Kako
\n
\nPodaci se dekapsuliraju i ponovno omotavaju u IPsec omotnicu prilikom kori\u0161tenja VPN-a.<\/p>\n

\"Kako
\n
\nPri kori\u0161tenju Direct Connect prometa se ozna\u010dava i proslije\u0111uje u odgovaraju\u0107i VLAN.<\/p>\n

\"Kako
\n<\/p>\n

HyperPlane<\/h3>\n

\nOvo je interna usluga za kontrolu prometa. Mnoge mre\u017ene usluge zahtijevaju kontrolu stanja protoka podataka<\/b>. Na primjer, prilikom kori\u0161tenja NAT-a, kontrola protoka mora jam\u010diti da svakom paru \"IP: odredi\u0161ni port\" odgovara jedinstveni izlazni port. U slu\u010daju balansiranja optere\u0107enja NLB<\/b> \u2014 Network Load Balancer<\/b>, protok podataka uvijek mora biti usmjeren na istu ciljanju virtualnu ma\u0161inu. Security Groups su vatrozid s odr\u017eavanjem stanja. Prati dolazni promet i neizravno otvara portove za izlazni protok paketa.<\/p>\n

\"Kako
\n
\nU AWS oblaku, zahtjevi za ka\u0161njenjem prijenosa su izuzetno visoki. Zato HyperPlane<\/b> je kriti\u010dno za funkcionalnost cijele mre\u017ee.<\/p>\n

\"Kako
\n
\nHyperplane je izgra\u0111en na EC2 virtualnim ma\u0161inama. Ovdje nema nikakve magije, samo trik. Trik je u tome \u0161to su to virtualke s velikim RAM-om. Operacije su transakcijske i obavljaju se isklju\u010divo u memoriji. To omogu\u0107ava ka\u0161njenja od samo nekoliko mikrosekundi. Rad s diskom bi ubio cijelu u\u010dinkovitost.\u00a0<\/p>\n

Hyperplane je distribuirani sustav iz ogromnog broja takvih EC2 ma\u0161ina. Svaka virtualka ima propusnost od 5 GB\/s. Na razini cijele regionalne mre\u017ee to omogu\u0107ava nevjerojatne terabite propusnosti i omogu\u0107ava obradu milijuna veza u sekundi.<\/b>.<\/p>\n

HyperPlane radi samo s tokovima. VPC inkapsulacija paketa za njega je potpuno prozirna. Potencijalna ranjivost u ovoj internoj usluzi i dalje ne bi dozvolila probijanje VPC izolacije. Sigurnost pokrivaju ni\u017ei slojevi.<\/p>\n

Noisy neighbor<\/h3>\n

\nPostoji jo\u0161 jedan problem \u0161umnog susjeda<\/b> \u2014 noisy neighbor<\/b>. Predpostavimo da imamo 8 nodov. Ti nodi obdelujejo tokove vseh uporabnikov v oblak. Zdi se, da je vse v redu in obremenitev bi se morala enakomerno razporediti med vse nodi. Nodi so zelo zmogljivi in jih je te\u017eko preobremeniti.<\/p>\n

Toda mi gradimo svojo arhitekturo, upo\u0161tevajo\u010d celo nepri\u010dakovane scenarije.\u00a0<\/p>\n

Nizka verjetnost ne pomeni nemogo\u010de.<\/p><\/blockquote>\n

\nLahko si predstavljamo situacijo, v kateri bo en ali ve\u010d uporabnikov generiralo preveliko obremenitev. V obdelavo te obremenitve so vklju\u010deni vsi nodi HyperPlane in drugi uporabniki lahko potencialno ob\u010dutijo dolo\u010deno zni\u017eanje zmogljivosti. To ru\u0161i koncept oblaka, v katerem nimajo najemniki mo\u017enosti, da vplivajo drug na drugega.<\/p>\n

\"Kako
\n
\nKako re\u0161iti problem hrupnega soseda? Prvo, kar pride na pamet \u2013 sharding. Na\u0161ih 8 nod je logi\u010dno razdeljenih na 4 sharde po 2 nodi v vsakem. Zdaj bo hrupni sosed motil le \u010detrtino vseh uporabnikov, toda mo\u010dno.<\/p>\n

\"Kako
\n
\nPoglejmo druga\u010de. Vsakemu uporabniku bomo namenili po 3 nodi.\u00a0<\/p>\n

\"Kako
\n
\nTrik je v tem, da dodelimo nodi razli\u010dnim uporabnikom naklju\u010dno. Na sliki spodaj se modri uporabnik prekriva z eno od dveh drugih uporabnikov \u2013 zelenim in oran\u017enim.<\/p>\n

\"Kako
\n
\nPri 8 nodah in 3 uporabnikih je verjetnost prekrivanja hrupnega soseda z enim od uporabnikov 54%. Prav s to verjetnostjo bo modri uporabnik vplival na druge najemnike. Pri tem samo z delom svoje obremenitve. V na\u0161em primeru bo ta vpliv opazen le delno, in sicer le pri tretjini vseh uporabnikov. To je \u017ee precej\u0161en rezultat.<\/p>\n

\u0160tevilo uporabnikov, ki se bodo prekrili<\/p>\n

Verjetnost v odstotkih<\/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

Pribli\u017eajmo situacijo realnosti \u2013 vzemimo 100 nod in 5 uporabnikov na 5 nodah. V tem primeru se nobena izmed nod ne bo prekrila z verjetnostjo 77%.\u00a0<\/p>\n

\u0160tevilo uporabnikov, ki se bodo prekrili<\/p>\n

Verjetnost v odstotkih<\/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

V realni situaciji, pri ogromnem \u0161tevilu HyperPlane nod in uporabnikov, je potencialni vpliv hrupnega soseda na druge uporabnike minimalen. Ta metoda se imenuje me\u0161ano sharding<\/b> \u2014 shuffle sharding<\/b>. Minimalizira negativni u\u010dinek izpada nod.<\/p>\n

Na podlagi HyperPlane je zgrajenih mnogo storitev: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

Obsegi omre\u017eja<\/h3>\n

\nSedaj se bomo pogovorili o razse\u017enostih same mre\u017ee. Do oktobra 2019 AWS ponuja svoje storitve v 22 regijah<\/b>, devet pa jih je \u0161e na\u010drtovanih.<\/p>\n