{"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\/ro\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Extinderea re\u021belei Amazon Web Services const\u0103 \u00een 69 de zone din \u00eentreaga lume, \u00een 22 de regiuni: SUA, Europa, Asia, Africa \u0219i Australia. \u00cen fiecare zon\u0103 se afl\u0103 p\u00e2n\u0103 la 8 centre de date (CDP). \u00cen fiecare CDP sunt mii sau sute de mii de servere. Re\u021beaua este construit\u0103 astfel \u00eenc\u00e2t toate scenariile improbabile de \u00eentrerupere s\u0103 fie luate \u00een considerare. De exemplu, toate regiunile sunt izolate una de cealalt\u0103, iar zonele de disponibilitate sunt dispuse la distan\u021be de c\u00e2\u021biva kilometri. Chiar dac\u0103 un cablu este rupt, sistemul va comuta pe canale de rezerv\u0103, iar pierderile de informa\u021bii vor fi de c\u00e2teva pachete de date. Despre ce alte principii fundamenteaz\u0103 re\u021beaua \u0219i cum este aceasta organizat\u0103, va povesti Vasili Pantyuhin.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/4cc9672442cd7bf744ffced6471be040.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Vasili Pantyuhin<\/b> a \u00eenceput ca administrator Unix \u00een companii .ru, a lucrat timp de 6 ani cu echipamente mari de la Sun Microsystem, iar timp de 11 ani a promovat centralizarea datelor \u00een EMC. A evoluat natural c\u0103tre solu\u021bii de cloud privat, apoi a trecut la cele publice. Acum, \u00een calitate de arhitect pentru Amazon Web Services, ofer\u0103 sfaturi tehnice pentru a tr\u0103i \u0219i a se dezvolta \u00een cloud-ul AWS.<\/p>\n<p>\u00cen partea anterioar\u0103 a trilogiei despre structura AWS, Vasili a aprofundat tema serverelor fizice \u0219i scalarea bazelor de date. Cardurile Nitro, hipervizorul personalizat bazat pe KVM, baza de date Amazon Aurora \u2014 toate acestea sunt discutate \u00een materialul \u201e<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/471686\/\">Cum \u201eg\u0103te\u0219te\u201d AWS serviciile sale elastice. Scalarea serverelor \u0219i bazelor de date<\/a><\/noindex>\u201d. Citi\u021bi pentru a v\u0103 familiariza cu contextul sau viziona\u021bi <noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/S3f6nWJxBvk\">\u00eenregistrarea video<\/a><\/noindex> a prezent\u0103rii.<\/p>\n<p>\u00cen aceast\u0103 parte se va vorbi despre scalarea re\u021belei \u2014 unul dintre cele mai complexe sisteme din AWS. Evolu\u021bia de la o re\u021bea plat\u0103 la Virtual Private Cloud \u0219i structura acesteia, serviciile interne Blackfoot \u0219i HyperPlane, problema vecinului zgomotos, iar la final \u2014 amploarea re\u021belei, backbone-ul \u0219i cablurile fizice. Toate acestea sunt discutate mai jos.<\/p>\n<p><i>Declinarea responsabilit\u0103\u021bii: tot ceea ce urmeaz\u0103 este o opinie personal\u0103 a lui Vasili \u0219i poate s\u0103 nu coincid\u0103 cu pozi\u021bia Amazon Web Services.<\/i><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Scalarea re\u021belei<\/h2>\n<p>\nCloud-ul AWS a fost lansat \u00een 2006. Re\u021beaua sa era destul de primitiv\u0103 \u2014 cu o structur\u0103 plat\u0103. Domeniul adreselor private era comun pentru to\u021bi chiria\u0219ii cloud-ului. La lansarea unei noi ma\u0219ini virtuale, primeai accidental o adres\u0103 IP disponibil\u0103 din acest domeniu.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/dde10b64891861582bc56510adb0fb56.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAceast\u0103 abordare era simpl\u0103 \u00een implementare, dar limita fundamental utilizarea cloud-ului. \u00cen special, era destul de dificil s\u0103 dezvol\u021bi solu\u021bii hibride care combinau re\u021bele private de la sol cu cele din AWS. Cea mai frecvent\u0103 problem\u0103 era intersectarea domeniilor de adrese IP.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/8e95325862ae0438d3b1edef45c692b0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cloud Privat Virtual<\/h3>\n<p>\nCloud-ul a devenit foarte cerut. A sosit momentul s\u0103 ne g\u00e2ndim la scalabilitate \u0219i la posibilitatea utiliz\u0103rii acestuia de c\u0103tre zeci de milioane de chiria\u0219i. Re\u021beaua plat\u0103 a devenit principalul obstacol. De aceea, ne-am g\u00e2ndit cum s\u0103 izol\u0103m utilizatorii unii de al\u021bii la nivel de re\u021bea, astfel \u00eenc\u00e2t ei s\u0103 poat\u0103 alege singuri intervalele IP.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/e082da6a68a889e3091c75dd3aa912ec.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCe v\u0103 vine primul \u00een minte c\u00e2nd v\u0103 g\u00e2ndi\u021bi la izolarea re\u021belei? Desigur <b>VLAN<\/b> \u0219i <b>VRF \u2014 Rutare Virtual\u0103 \u0219i \u00cenaintare<\/b>.<\/p>\n<p>Din p\u0103cate, acest lucru nu a func\u021bionat. VLAN ID este de doar 12 bi\u021bi, ceea ce ne ofer\u0103 doar 4096 de segmente izolate. Chiar \u0219i \u00een cele mai mari switch-uri pot fi utilizate maximum 1-2 mii VRF. Utilizarea comun\u0103 a VRF \u0219i VLAN ne ofer\u0103 doar c\u00e2teva milioane de subre\u021bele. Acest lucru este cu siguran\u021b\u0103 insuficient pentru zeci de milioane de chiria\u0219i, fiecare dintre ei av\u00e2nd nevoie s\u0103 utilizeze mai multe subre\u021bele.<\/p>\n<p>De asemenea, pur \u0219i simplu nu ne putem permite s\u0103 cump\u0103r\u0103m cantitatea necesar\u0103 de echipamente mari, de exemplu, de la Cisco sau Juniper. Exist\u0103 dou\u0103 motive: este extrem de scump \u0219i nu dorim s\u0103 depindem de politica lor de dezvoltare \u0219i patching.<\/p>\n<blockquote><p>Concluzia este una \u2013 s\u0103 ne cre\u0103m propria solu\u021bie.<\/p><\/blockquote>\n<p>\n\u00cen 2009 am anun\u021bat <b>VPC<\/b> \u2014 <b>Cloud Privat Virtual<\/b>. Numele a prins \u0219i acum mul\u021bi furnizori de cloud \u00eel folosesc.<\/p>\n<p>VPC este o re\u021bea virtual\u0103 <b>SDN<\/b> (Re\u021bea Definita prin Software). Am decis s\u0103 nu invent\u0103m protocoale speciale la nivelurile L2 \u0219i L3. Re\u021beaua func\u021bioneaz\u0103 pe Ethernet standard \u0219i IP. Pentru a transmite date prin re\u021bea, traficul ma\u0219inilor virtuale este \u00eencapsulat \u00eentr-un wrapper al propriului nostru protocol. \u00cen acesta se specific\u0103 ID-ul care apar\u021bine chiria\u0219ului VPC.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/63c6226b5dcecbf4376547c3c1605fef.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPare simplu. Cu toate acestea, trebuie s\u0103 rezolv\u0103m c\u00e2teva probleme tehnice serioase. De exemplu, unde \u0219i cum s\u0103 stoc\u0103m datele despre asocierea adreselor MAC\/IP virtuale, VPC ID \u0219i MAC\/IP fizice corespunz\u0103toare. La scal\u0103 AWS, aceasta este o tabel\u0103 enorm\u0103, care trebuie s\u0103 func\u021bioneze cu \u00eent\u00e2rzieri minime la accesare. Pentru aceasta r\u0103spunde <b>serviciul de mapare<\/b>, care este r\u0103sp\u00e2ndit sub\u021bire pe \u00eentreaga re\u021bea.<\/p>\n<p>\u00cen ma\u0219inile de nou\u0103 genera\u021bie, \u00eencapsularea se realizeaz\u0103 prin pl\u0103cile Nitro la nivel hardware. \u00cen instan\u021bele mai vechi, \u00eencapsularea \u0219i decapsularea sunt realizate software.\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/d17738749f273d94e943723f7b2a6b5a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nS\u0103 \u00een\u021belegem cum func\u021bioneaz\u0103 acest lucru \u00een linii mari. S\u0103 \u00eencepem cu nivelul L2. S\u0103 presupunem c\u0103 avem o ma\u0219in\u0103 virtual\u0103 cu IP 10.0.0.2 pe un server fizic 192.168.0.3. Aceasta trimite date unei ma\u0219ini virtuale 10.0.0.3, care se afl\u0103 pe 192.168.1.4. Se formeaz\u0103 o solicitare ARP, care ajunge pe placa de re\u021bea Nitro. Pentru simplitate, s\u0103 consider\u0103m c\u0103 ambele ma\u0219ini virtuale se afl\u0103 \u00een acela\u0219i VPC \"albastru\".<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/d260113b0502cecc328919dd5c3b69ac.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPlaca \u00eenlocuie\u0219te adresa surs\u0103 cu a sa \u0219i retransmite cadrul ARP c\u0103tre serviciul de mapare.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/812d7693bc54afc24f6e763fdb91180e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nServiciul de mapare returneaz\u0103 informa\u021biile necesare pentru transmiterea prin re\u021beaua fizic\u0103 L2.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/b21fd6edb95ef2e990db813074c7907c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPlaca Nitro \u00een r\u0103spunsul ARP \u00eenlocuie\u0219te MAC-ul din re\u021beaua fizic\u0103 cu adresa din VPC.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/6e6931c7fe92d5cf2584c5bf9b2b3fdb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAtunci c\u00e2nd transmitem date, \u00eempachet\u0103m MAC-urile \u0219i IP-urile logice \u00een un ambalaj VPC. Toate acestea sunt transmise prin re\u021beaua fizic\u0103 folosind IP-urile corespunz\u0103toare ale pl\u0103cilor Nitro de surs\u0103 \u0219i destina\u021bie.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/e786d7f88e1fea1557590f2b2bd6e88f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMa\u0219ina fizic\u0103 care prime\u0219te pachetul efectueaz\u0103 o verificare. Aceasta este necesar\u0103 pentru a preveni posibilitatea falsific\u0103rii adreselor. Ma\u0219ina trimite o solicitare special\u0103 c\u0103tre serviciul de mapare \u0219i \u00eentreab\u0103: \"De pe ma\u0219ina fizic\u0103 192.168.0.3 am primit un pachet destinat lui 10.0.0.3 \u00een VPC-ul \"albastru\". Este acesta legitim?\"\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/cedf4d7e77936e4cc8f873defefbe37f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nServiciul de mapare verific\u0103 \u00een tabela sa de alocare a resurselor \u0219i permite sau interzice trecerea pachetului. \u00cen toate noile instan\u021be, o validare suplimentar\u0103 este integrat\u0103 \u00een pl\u0103cile Nitro. Aceasta nu poate fi ocolit\u0103 nici m\u0103car teoretic. De aceea, falsificarea pe resurse din alt VPC nu va func\u021biona.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/3e6bc5a80a7d36785299f6a3fbb19d92.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nApoi, datele sunt trimise ma\u0219inii virtuale pentru care sunt destinate.\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/19884070ad3b2b7b2835e2c3c182949a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nServiciul de mapare func\u021bioneaz\u0103 \u0219i ca un router logic pentru transmiterea datelor \u00eentre ma\u0219inile virtuale din subre\u021bele diferite. Din punct de vedere conceptual, totul este simplu, nu voi analiza detaliat.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/9d592d738d02bbcf6bfcbda2812f8f0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nRezult\u0103 c\u0103, la transmiterea fiec\u0103rui pachet, serverele fac apel la serviciul de mapare. Cum putem combate \u00eent\u00e2rzierile inevitabile? <b>Prin cache.<\/b>, desigur.<\/p>\n<p>Toat\u0103 frumuse\u021bea const\u0103 \u00een faptul c\u0103 nu este nevoie s\u0103 se cacheze toat\u0103 imensa tabel\u0103. Pe serverul fizic tr\u0103iesc ma\u0219ini virtuale dintr-un num\u0103r relativ mic de VPC-uri. Informa\u021bia trebuie s\u0103 fie cache-uit\u0103 doar despre aceste VPC-uri. Transmiterea datelor \u00een alte VPC-uri, \u00een configura\u021bia \"implicit\u0103\", nu este niciodat\u0103 legitim\u0103. Dac\u0103 se folose\u0219te o func\u021bionalitate precum VPC-peering, atunci \u00een cache se \u00eencarc\u0103 suplimentar informa\u021biile despre VPC-urile corespunz\u0103toare.\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/5ac44d8854bff3c7738724ee9dda0c57.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAm \u00een\u021beles cum func\u021bioneaz\u0103 transmiterea datelor \u00een VPC.<\/p>\n<h3>Blackfoot<\/h3>\n<p>\nCe s\u0103 facem \u00een cazul \u00een care traficul trebuie transmis \u00een exterior, de exemplu \u00een Internet sau prin VPN pe p\u0103m\u00e2nt? Aici ne ajut\u0103 <b>Blackfoot<\/b> \u2014 un serviciu intern AWS. A fost dezvoltat de echipa noastr\u0103 din Africa de Sud. De aceea serviciul este numit dup\u0103 un pinguin care tr\u0103ie\u0219te \u00een Africa de Sud.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/dc6f233224d130df42adf522602167c6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBlackfoot decapsuleaz\u0103 traficul \u0219i face cu el ce trebuie. Datele sunt trimise \u00een Internet a\u0219a cum sunt.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/b6a51230202355b27de9730fbc18bd7f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDatele sunt decapsulate \u0219i din nou \u00eenvelite \u00eentr-un ambalaj IPsec atunci c\u00e2nd se folose\u0219te VPN.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/ef76780a9be99d72c5763a41274f4224.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nC\u00e2nd se utilizeaz\u0103 Direct Connect, traficul este etichetat \u0219i trimis \u00een VLAN-ul corespunz\u0103tor.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/89adc2616e0bf97355a2c638720fd791.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>HyperPlane<\/h3>\n<p>\nAcesta este un serviciu intern de control al fluxului. Multe servicii de re\u021bea necesit\u0103 controlul <b>st\u0103rii fluxului de date<\/b>. De exemplu, atunci c\u00e2nd se utilizeaz\u0103 NAT, controlul fluxului trebuie s\u0103 garanteze c\u0103 fiec\u0103rei perechi \u201eIP: port de destina\u021bie\u201d \u00eei corespunde un port de ie\u0219ire unic. \u00cen cazul unui echilibrator de \u00eenc\u0103rcare <b>NLB<\/b> \u2014 <b>Network Load Balancer<\/b>, fluxul de date trebuie s\u0103 fie \u00eentotdeauna direc\u021bionat c\u0103tre aceea\u0219i ma\u0219in\u0103 virtual\u0103 \u021bint\u0103. Security Groups sunt un firewall cu p\u0103strarea st\u0103rii. Acesta monitorizeaz\u0103 traficul de intrare \u0219i deschide implicit porturile pentru fluxul de ie\u0219ire al pachetelor.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/da1ad8e7179ebffbe786348db25f0a95.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen cloud-ul AWS, cerin\u021bele pentru \u00eent\u00e2rzierile de transfer sunt extrem de mari. De aceea <b>HyperPlane<\/b> este critic pentru func\u021bionarea \u00eentregii re\u021bele.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/eb73570e579c6e0b05727029345e559a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHyperplane este construit pe ma\u0219ini virtuale EC2. Aici nu exist\u0103 magie, doar trucuri. Trucul este acela c\u0103 aceste ma\u0219ini virtuale au mult RAM. Opera\u021biile sunt tranzac\u021bionale \u0219i se efectueaz\u0103 exclusiv \u00een memorie. Aceasta permite ob\u021binerea \u00eent\u00e2rzierilor de doar c\u00e2teva microsecunde. Lucrul cu discul ar distruge \u00eentreaga performan\u021b\u0103.\u00a0<\/p>\n<p>Hyperplane este un sistem distribuit format dintr-un num\u0103r enorm de astfel de ma\u0219ini EC2. Fiecare ma\u0219in\u0103 virtual\u0103 are o l\u0103\u021bime de band\u0103 de 5 GB\/s. La nivelul \u00eentregii re\u021bele regionale, acest lucru ofer\u0103 o capacitate nebuneasc\u0103 de terabi\u021bi \u0219i permite preluarea <b>milionelor de conexiuni pe secund\u0103<\/b>.<\/p>\n<p>HyperPlane func\u021bioneaz\u0103 doar cu fluxuri. Incapsularea pachetelor VPC este complet transparent\u0103 pentru el. O vulnerabilitate poten\u021bial\u0103 \u00een acest serviciu intern nu va permite totu\u0219i s\u0103 fie spart\u0103 izolarea VPC. Securitatea este responsabilitatea nivelurilor inferioare.<\/p>\n<h3>vecin zgomotos<\/h3>\n<p>\nExist\u0103 \u0219i o alt\u0103 problem\u0103 <b>a vecinului zgomotos<\/b> \u2014 <b>vecin zgomotos<\/b>. S\u0103 presupunem c\u0103 avem 8 noduri. Aceste noduri gestioneaz\u0103 fluxurile tuturor utilizatorilor din cloud. Totul pare bine, iar sarcina ar trebui s\u0103 fie distribuit\u0103 uniform \u00eentre toate nodurile. Nodurile sunt foarte puternice \u0219i este greu s\u0103 le supra\u00eenc\u0103rc\u0103m.<\/p>\n<p>Dar noi ne construim arhitectura av\u00e2nd \u00een vedere chiar \u0219i scenariile pu\u021bin probabile.\u00a0<\/p>\n<blockquote><p>O probabilitate sc\u0103zut\u0103 nu \u00eenseamn\u0103 imposibilitate.<\/p><\/blockquote>\n<p>\nNe putem imagina o situa\u021bie \u00een care unul sau mai mul\u021bi utilizatori genereaz\u0103 o \u00eenc\u0103rc\u0103tur\u0103 prea mare. Toate nodurile HyperPlane sunt implicate \u00een gestionarea acestei \u00eenc\u0103rc\u0103turi, iar ceilal\u021bi utilizatori ar putea sim\u021bi o oarecare sc\u0103dere a performan\u021bei. Aceasta distruge conceptul de cloud, \u00een care chiria\u0219ii nu au posibilitatea de a influen\u021ba unul pe altul.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/8508878637dc3d4c0b0b565e08d73e52.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCum rezolv\u0103m problema \u201evecinului zgomotos\u201d? Primul lucru care \u00eemi vine \u00een minte este shardingul. Cele 8 noduri sunt \u00eemp\u0103r\u021bite logic \u00een 4 sharduri, c\u00e2te 2 noduri \u00een fiecare. Acum vecinul zgomotos va deranja doar un sfert dintre to\u021bi utilizatorii, dar impactul s\u0103u va fi semnificativ.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/33e10c10b246ee8ddeb171ac44372c56.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHai s\u0103 facem altfel. Fiecare utilizator va fi alocat c\u00e2te 3 noduri.\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/1afa7337b8418740b9ef5860be9d3a82.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTrucul const\u0103 \u00een a atribui nodurile utilizatorilor diferit, aleatoriu. \u00cen imaginea de mai jos, utilizatorul albastru se intersecteaz\u0103 cu nodurile unuia dintre ceilal\u021bi doi utilizatori \u2014 verde \u0219i portocaliu.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/e0fd896db825b390bd66d2055707464d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCu 8 noduri \u0219i 3 utilizatori, probabilitatea ca vecinul zgomotos s\u0103 se intersecteze cu unul dintre utilizatori este de 54%. Aceasta este probabilitatea cu care utilizatorul albastru va influen\u021ba ceilal\u021bi chiria\u0219i. \u00cen acela\u0219i timp, aceasta se va \u00eent\u00e2mpla doar cu o parte a sarcinii sale. \u00cen exemplul nostru, acest impact va fi vizibil nu tuturor, ci doar unei treimi dintre utilizatori. Acesta este un rezultat bun.<\/p>\n<p>Num\u0103rul de utilizatori care se vor intersecta<\/p>\n<p>Probabilitatea \u00een procente<\/p>\n<p>0<\/p>\n<p>18%<\/p>\n<p>1<\/p>\n<p>54%<\/p>\n<p>2<\/p>\n<p>26%<\/p>\n<p>3<\/p>\n<p>2%<\/p>\n<p>S\u0103 aproximez situa\u021bia la una real\u0103 \u2014 s\u0103 lu\u0103m 100 de noduri \u0219i 5 utilizatori pe 5 noduri. \u00cen acest caz, niciunul dintre noduri nu se va intersecta cu o probabilitate de 77%.\u00a0<\/p>\n<p>Num\u0103rul de utilizatori care se vor intersecta<\/p>\n<p>Probabilitatea \u00een procente<\/p>\n<p>0<\/p>\n<p>77%<\/p>\n<p>1<\/p>\n<p>21%<\/p>\n<p>2<\/p>\n<p>1,8%<\/p>\n<p>3<\/p>\n<p>0,06%<\/p>\n<p>4<\/p>\n<p>0,0006%<\/p>\n<p>5<\/p>\n<p>0,00000013%<\/p>\n<p>\u00centr-o situa\u021bie real\u0103, av\u00e2nd o cantitate enorm\u0103 de noduri \u0219i utilizatori HyperPlane, influen\u021ba poten\u021bial\u0103 a vecinului zgomotos asupra altor utilizatori este minim\u0103. Acest metod se nume\u0219te <b>sharding de amestecare<\/b> \u2014 <b>shuffle sharding<\/b>. El minimizeaz\u0103 efectul negativ al defec\u021biunilor nodurilor.<\/p>\n<p>Pe baza HyperPlane sunt construite numeroase servicii: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n<h3>Magnitudinea re\u021belei<\/h3>\n<p>\nAcum s\u0103 vorbim despre amploarea re\u021belei. \u00cen octombrie 2019, AWS \u00ee\u0219i ofer\u0103 serviciile \u00een <b>22 regiuni<\/b>, iar alte 9 sunt planificate.<\/p>\n<ul>\n<li>Fiecare regiune con\u021bine mai multe zone de disponibilitate - Availability Zone. \u00cen total, exist\u0103 69 \u00een \u00eentreaga lume.\n<\/li>\n<li>Fiecare AZ este format\u0103 din Centre de Date. Num\u0103rul acestora nu dep\u0103\u0219e\u0219te 8.\n<\/li>\n<li>\u00cen Centrele de Date se afl\u0103 un num\u0103r uria\u0219 de servere, iar \u00een unele p\u00e2n\u0103 la 300.000.\n<\/li>\n<\/ul>\n<p>\nAcum s\u0103 calcul\u0103m media, s\u0103 \u00eenmul\u021bim \u0219i s\u0103 ob\u021binem o cifr\u0103 impresionant\u0103 care ilustreaz\u0103 <b>amploarea cloudului Amazon<\/b>.<\/p>\n<p>\u00centre zonele de disponibilitate \u0219i Centrele de Date exist\u0103 multe conexiuni optice. \u00centr-o dintre cele mai mari regiuni ale noastre, doar pentru a conecta AZ \u00eentre ele \u0219i centrele de comunicare cu alte regiuni (Transit Centers) sunt instalate 388 de canale. \u00cen total, aceasta ofer\u0103 un uria\u0219 <b>5000 Tbps<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/2d9faa9275665bc1d3c6fbb49235fac4.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBackbone-ul AWS este construit special pentru cloud \u0219i optimizat pentru a lucra cu acesta. \u00cel construim pe canale de <b>100 Gbps<\/b>. Le control\u0103m complet, cu excep\u021bia regiunilor din China. Traficul nu este \u00eemp\u0103r\u021bit cu \u00eenc\u0103rc\u0103rile altor companii.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/3359c6ade7215527f40ee3b54a0b700e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDesigur, nu suntem singurul furnizor de cloud cu o re\u021bea backbone privat\u0103. Tot mai multe companii mari urmeaz\u0103 aceast\u0103 cale. Acest lucru este sus\u021binut de cercet\u0103tori independen\u021bi, de exemplu, de la <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.telegeography.com\/telegeographys-content-providers-submarine-cable-holdings-list\">Telegeography<\/a><\/noindex>.<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/b7aa723241783d131881caf5db73f7e6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00cen grafic se poate observa c\u0103 cota furnizorilor de con\u021binut \u0219i a furnizorilor de cloud cre\u0219te. Din cauza aceasta, cota de trafic Internet a furnizorilor backbone scade constant.<\/p>\n<p>Voi explica de ce se \u00eent\u00e2mpl\u0103 acest lucru. \u00cen trecut, majoritatea serviciilor web erau accesibile \u0219i consumate direct din Internet. Acum, tot mai multe servere sunt situate \u00een cloud \u0219i sunt accesibile prin <b>CDN<\/b> \u2014 <b>Content Distribution Network<\/b>. Pentru a accesa resursa, utilizatorul trece prin Internet doar p\u00e2n\u0103 la cel mai apropiat PoP CDN - <b>Point of Presence<\/b>. Cel mai adesea, acesta se afl\u0103 \u00een apropiere. Apoi, p\u0103r\u0103se\u0219te Internetul public \u0219i, printr-o backbone privat\u0103, c\u0103l\u0103tore\u0219te, de exemplu, peste Atlantic, ajung\u00e2nd direct la resurs\u0103.<\/p>\n<p>Este interesant cum se va schimba Internetul \u00een 10 ani dac\u0103 aceast\u0103 tendin\u021b\u0103 va continua?<\/p>\n<h3>Canale fizice<\/h3>\n<p>\nDeocamdat\u0103, oamenii de \u0219tiin\u021b\u0103 nu au g\u0103sit o modalitate de a cre\u0219te viteza luminii \u00een Univers, dar au progresat semnificativ \u00een metodele de transfer al acesteia prin fibr\u0103 optic\u0103. Acum folosim cabluri cu 6912 fibre. Acest lucru ajut\u0103 la optimizarea semnificativ\u0103 a costurilor de instalare.<\/p>\n<p>\u00cen unele regiuni, suntem nevoi\u021bi s\u0103 folosim cabluri speciale. De exemplu, \u00een regiunea Sydney, folosim cabluri cu un strat special \u00eempotriva termitelor.\u00a0<\/p>\n<p><img decoding=\"async\" alt=\"Cum AWS \u201eg\u0103te\u0219te\u201d serviciile sale elastice. Scalarea re\u021belei\" src=\"\/wp-content\/uploads\/2019\/10\/738bec49680ba7a31237862f0834942a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNimeni nu este protejat de nepl\u0103ceri, iar uneori canalele noastre sufer\u0103 daune. \u00cen fotografia de mai sus, cablurile de fibr\u0103 optic\u0103 din una dintre regiunile americane au fost rupte de muncitori. Ca urmare a accidentului, au fost pierdute doar 13 pachete de date, ceea ce este uimitor. \u00cenc\u0103 o dat\u0103 \u2013 doar 13! Sistemul s-a comutat practic instantaneu pe canalele de rezerv\u0103 \u2014 scala func\u021bioneaz\u0103.<\/p>\n<p>Am trecut rapid prin c\u00e2teva servicii \u0219i tehnologii ale cloud-ului Amazon. Sper c\u0103 acum ave\u021bi o idee despre amploarea problemelor cu care se confrunt\u0103 inginerii no\u0219tri. Personal, m\u0103 entuziasmeaz\u0103 foarte mult acest domeniu.\u00a0<\/p>\n<blockquote><p>Aceasta este partea final\u0103 a trilogiei lui Vasily Pantyukhin despre arhitectura AWS. \u00cen <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/471686\/\">prima<\/a><\/noindex> parte sunt descrise optimizarea serverelor \u0219i scalarea bazei de date, iar \u00een <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/464305\/\">al doilea<\/a><\/noindex> cea de-a doua \u2014 func\u021biile serverless \u0219i Firecracker.<\/p>\n<p>Pe <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++<\/a><\/noindex> \u00cen noiembrie, Vasily Pantyukhin va \u00eemp\u0103rt\u0103\u0219i noi detalii despre arhitectura Amazon. El <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\/5977\">va vorbi<\/a><\/noindex> despre cauzele defec\u021biunilor \u0219i proiectarea sistemelor distribuite \u00een Amazon. Pe 24 octombrie, mai pute\u021bi <noindex><a rel=\"nofollow\" href=\"https:\/\/conf.ontico.ru\/conference\/join\/hl2019.html\">rezerva<\/a><\/noindex> un bilet la un pre\u021b bun, iar plata poate fi efectuat\u0103 mai t\u00e2rziu. V\u0103 a\u0219tept\u0103m la HighLoad++, veni\u021bi \u2014 s\u0103 discut\u0103m!<\/p><\/blockquote>\n<p>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/471688\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0441\u0435\u0442\u0438 Amazon Web Services \u2014\u00a0\u044d\u0442\u043e 69 \u0437\u043e\u043d \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443 \u0432 22 \u0440\u0435\u0433\u0438\u043e\u043d\u0430\u0445: \u0421\u0428\u0410, \u0415\u0432\u0440\u043e\u043f\u0430, \u0410\u0437\u0438\u044f, \u0410\u0444\u0440\u0438\u043a\u0430 \u0438 \u0410\u0432\u0441\u0442\u0440\u0430\u043b\u0438\u044f. \u0412 \u043a\u0430\u0436\u0434\u043e\u0439 \u0437\u043e\u043d\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0434\u043e 8 \u0426\u041e\u0414 \u2014 \u0426\u0435\u043d\u0442\u0440\u043e\u0432 \u041e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0414\u0430\u043d\u043d\u044b\u0445. \u0412 \u043a\u0430\u0436\u0434\u043e\u043c \u0426\u041e\u0414 \u0442\u044b\u0441\u044f\u0447\u0438 \u0438\u043b\u0438 \u0441\u043e\u0442\u043d\u0438 \u0442\u044b\u0441\u044f\u0447 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432. \u0421\u0435\u0442\u044c \u043f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0430 \u0442\u0430\u043a, \u0447\u0442\u043e \u0432\u0441\u0435 \u043c\u0430\u043b\u043e\u0432\u0435\u0440\u043e\u044f\u0442\u043d\u044b\u0435 \u0441\u0446\u0435\u043d\u0430\u0440\u0438\u0438 \u043f\u0435\u0440\u0435\u0431\u043e\u0435\u0432 \u0432 \u0440\u0430\u0431\u043e\u0442\u0435 \u043f\u0440\u0438\u043d\u0438\u043c\u0430\u044e\u0442\u0441\u044f \u0432 \u0440\u0430\u0441\u0447\u0435\u0442. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0432\u0441\u0435 \u0440\u0435\u0433\u0438\u043e\u043d\u044b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":39305,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39304","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0441\u0435\u0442\u0438 Amazon Web Services \u2014 \u044d\u0442\u043e 69 \u0437\u043e\u043d \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443 \u0432 22 \u0440\u0435\u0433\u0438\u043e\u043d\u0430\u0445: \u0421\u0428\u0410, \u0415\u0432\u0440\u043e\u043f\u0430, \u0410\u0437\u0438\u044f, \u0410\u0444\u0440\u0438\u043a\u0430 \u0438 \u0410\u0432\u0441\u0442\u0440\u0430\u043b\u0438\u044f. \u0412 \u043a\u0430\u0436\u0434\u043e\u0439 \u0437\u043e\u043d\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0434\u043e 8 \u0426\u041e\u0414 \u2014 \u0426\u0435\u043d\u0442\u0440\u043e\u0432 \u041e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0414\u0430\u043d\u043d\u044b\u0445.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a AWS \u00ab\u0432\u0430\u0440\u0438\u0442\u00bb \u0441\u0432\u043e\u0438 \u044d\u043b\u0430\u0441\u0442\u0438\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b. \u041c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0441\u0435\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0441\u0435\u0442\u0438 Amazon Web Services \u2014 \u044d\u0442\u043e 69 \u0437\u043e\u043d \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443 \u0432 22 \u0440\u0435\u0433\u0438\u043e\u043d\u0430\u0445: \u0421\u0428\u0410, \u0415\u0432\u0440\u043e\u043f\u0430, \u0410\u0437\u0438\u044f, \u0410\u0444\u0440\u0438\u043a\u0430 \u0438 \u0410\u0432\u0441\u0442\u0440\u0430\u043b\u0438\u044f. \u0412 \u043a\u0430\u0436\u0434\u043e\u0439 \u0437\u043e\u043d\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0434\u043e 8 \u0426\u041e\u0414 \u2014 \u0426\u0435\u043d\u0442\u0440\u043e\u0432 \u041e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0414\u0430\u043d\u043d\u044b\u0445.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:29:40+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:29:40+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Cum AWS \u00ee\u0219i \"g\u0103te\u0219te\" serviciile elastice. Scalarea re\u021belei | ProHoster","description":"Scala re\u021belei Amazon Web Services este de 69 de zone \u00een \u00eentreaga lume, \u00een 22 de regiuni: SUA, Europa, Asia, Africa \u0219i Australia. Fiecare zon\u0103 are p\u00e2n\u0103 la 8 DC-uri \u2014 Centre de Date.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a AWS \u00ab\u0432\u0430\u0440\u0438\u0442\u00bb \u0441\u0432\u043e\u0438 \u044d\u043b\u0430\u0441\u0442\u0438\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b. \u041c\u0430\u0441\u0448\u0442\u0430\u0431\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0441\u0435\u0442\u0438 | ProHoster","og:description":"\u041c\u0430\u0441\u0448\u0442\u0430\u0431 \u0441\u0435\u0442\u0438 Amazon Web Services \u2014 \u044d\u0442\u043e 69 \u0437\u043e\u043d \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443 \u0432 22 \u0440\u0435\u0433\u0438\u043e\u043d\u0430\u0445: \u0421\u0428\u0410, \u0415\u0432\u0440\u043e\u043f\u0430, \u0410\u0437\u0438\u044f, \u0410\u0444\u0440\u0438\u043a\u0430 \u0438 \u0410\u0432\u0441\u0442\u0440\u0430\u043b\u0438\u044f. \u0412 \u043a\u0430\u0436\u0434\u043e\u0439 \u0437\u043e\u043d\u0435 \u043d\u0430\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0434\u043e 8 \u0426\u041e\u0414 \u2014 \u0426\u0435\u043d\u0442\u0440\u043e\u0432 \u041e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0414\u0430\u043d\u043d\u044b\u0445.","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:29:40+00:00","article:modified_time":"2019-10-31T19:29:40+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39304","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:37:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:52:26","updated":"2026-01-24 01:37:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/39304","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=39304"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/39304\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/39305"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=39304"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=39304"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=39304"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}