{"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\/cs\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Jak AWS \"va\u0159\u00ed\" sv\u00e9 elastick\u00e9 slu\u017eby. \u0160k\u00e1lov\u00e1n\u00ed s\u00edt\u011b","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u0160k\u00e1lov\u00e1n\u00ed Amazon Web Services zahrnuje 69 z\u00f3n po cel\u00e9m sv\u011bt\u011b ve 22 regionech: USA, Evropa, Asie, Afrika a Austr\u00e1lie. V ka\u017ed\u00e9 z\u00f3n\u011b se nach\u00e1z\u00ed a\u017e 8 datov\u00fdch center. V ka\u017ed\u00e9m datov\u00e9m centru jsou tis\u00edce nebo statis\u00edce server\u016f. S\u00ed\u0165 je navr\u017eena tak, aby brala v \u00favahu v\u0161echny m\u00e1lo pravd\u011bpodobn\u00e9 sc\u00e9n\u00e1\u0159e v\u00fdpadk\u016f. Nap\u0159\u00edklad v\u0161echny regiony jsou izolov\u00e1ny od sebe a z\u00f3ny dostupnosti jsou vzd\u00e1leny n\u011bkolik kilometr\u016f. I kdy\u017e dojde k p\u0159eru\u0161en\u00edm kabelu, syst\u00e9m p\u0159ejde na z\u00e1lo\u017en\u00ed kan\u00e1ly a ztr\u00e1ty informac\u00ed budou minim\u00e1ln\u00ed. O dal\u0161\u00edch principech fungov\u00e1n\u00ed s\u00edt\u011b a jej\u00ed struktu\u0159e bude hovo\u0159it Vasily Pantyuchin.<\/p>\n

\"Jak
\n
\nVasily Pantyuchin<\/b> za\u010d\u00ednal jako Unix administr\u00e1tor v .ru spole\u010dnostech, 6 let pracoval s velk\u00fdmi za\u0159\u00edzen\u00edmi Sun Microsystem, 11 let propagoval datacentricitu sv\u011bta v EMC. P\u0159irozen\u011b p\u0159e\u0161el k priv\u00e1tn\u00edm cloud\u016fm, pak se p\u0159esunul do ve\u0159ejn\u00fdch. Nyn\u00ed, jako architekt Amazon Web Services, poskytuje technick\u00e9 rady pro \u017eivot a rozvoj v cloudu AWS.<\/p>\n

V p\u0159edchoz\u00ed \u010d\u00e1sti trilogie o fungov\u00e1n\u00ed AWS se Vasily hloub\u011bji zab\u00fdval strukturou fyzick\u00fdch server\u016f a \u0161k\u00e1lov\u00e1n\u00edm datab\u00e1z\u00ed. Nitro karty, vlastn\u00ed hypervizor na b\u00e1zi KVM, datab\u00e1ze Amazon Aurora \u2014 o tom v\u0161em v materi\u00e1lu \"Jak AWS \"va\u0159\u00ed\" sv\u00e9 elastick\u00e9 slu\u017eby. \u0160k\u00e1lov\u00e1n\u00ed server\u016f a datab\u00e1z\u00ed<\/a><\/noindex>\". P\u0159e\u010dt\u011bte si, abyste se pono\u0159ili do kontextu, nebo se pod\u00edvejte na videoz\u00e1znam<\/a><\/noindex> prezentace.<\/p>\n

V t\u00e9to \u010d\u00e1sti se budeme zab\u00fdvat \u0161k\u00e1lov\u00e1n\u00edm s\u00edt\u011b \u2014 jedn\u00edm z nejkomplexn\u011bj\u0161\u00edch syst\u00e9m\u016f v AWS. Evoluce od ploch\u00e9 s\u00edt\u011b k Virtual Private Cloud a jej\u00ed struktura, intern\u00ed slu\u017eby Blackfoot a HyperPlane, probl\u00e9m hlu\u010dn\u00e9ho souseda, a nakonec \u2014 rozsahy s\u00edt\u011b, backbone a fyzick\u00e9 kabely. O tom v\u0161em se dozv\u00edte n\u00ed\u017ee.<\/p>\n

Disklaimer: v\u0161e, co je n\u00ed\u017ee, je osobn\u00ed n\u00e1zor Vasilyho a nemus\u00ed se shodovat s postojem Amazon Web Services.<\/i>
\n<\/a><\/noindex><\/p>\n

\u0160k\u00e1lov\u00e1n\u00ed s\u00edt\u011b<\/h2>\n

\nCloud AWS byl spu\u0161t\u011bn v roce 2006. Jeho s\u00ed\u0165 byla dost primitivn\u00ed \u2014 s plochou strukturou. Rozsah priv\u00e1tn\u00edch adres byl spole\u010dn\u00fd pro v\u0161echny n\u00e1jemce cloudu. P\u0159i spu\u0161t\u011bn\u00ed nov\u00e9 virtu\u00e1ln\u00ed stanice jste n\u00e1hodn\u011b z\u00edskali dostupnou IP adresu z tohoto rozsahu.<\/p>\n

\"Jak
\n
\nTento p\u0159\u00edstup byl snadn\u00fd na implementaci, ale z\u00e1sadn\u011b omezoval pou\u017e\u00edv\u00e1n\u00ed cloudu. Zejm\u00e9na bylo obt\u00ed\u017en\u00e9 vyv\u00edjet hybridn\u00ed \u0159e\u0161en\u00ed, kter\u00e1 kombinuj\u00ed soukrom\u00e9 s\u00edt\u011b na m\u00edst\u011b a v AWS. Nej\u010dast\u011bj\u0161\u00edm probl\u00e9mem byla p\u0159ekr\u00fdv\u00e1n\u00ed rozsah\u016f IP adres.<\/p>\n

\"Jak
\n<\/p>\n

Virtu\u00e1ln\u00ed priv\u00e1tn\u00ed cloud<\/h3>\n

\nCloud se uk\u00e1zal jako \u017e\u00e1dan\u00fd. P\u0159i\u0161el \u010das p\u0159em\u00fd\u0161let o \u0161k\u00e1lovatelnosti a mo\u017enosti jeho vyu\u017eit\u00ed des\u00edtkami milion\u016f tenant\u016f. Pl\u00e1novan\u00e1 s\u00ed\u0165 se stala hlavn\u00ed p\u0159ek\u00e1\u017ekou. Proto jsme za\u010dali p\u0159em\u00fd\u0161let, jak izolovat u\u017eivatele od sebe na \u00farovni s\u00edt\u011b tak, aby si mohli nez\u00e1visle vyb\u00edrat rozsahy IP.<\/p>\n

\"Jak
\n
\nCo v\u00e1s napadne jako prvn\u00ed, kdy\u017e p\u0159em\u00fd\u0161l\u00edte o s\u00ed\u0165ov\u00e9 izolaci? Samoz\u0159ejm\u011b VLAN<\/b> a VRF \u2014 Virtu\u00e1ln\u00ed sm\u011brov\u00e1n\u00ed a p\u0159epos\u00edl\u00e1n\u00ed<\/b>.<\/p>\n

Bohu\u017eel to nefungovalo. VLAN ID m\u00e1 pouze 12 bit\u016f, co\u017e n\u00e1m d\u00e1v\u00e1 pouze 4096 izolovan\u00fdch segment\u016f. I v nejv\u011bt\u0161\u00edch p\u0159ep\u00edna\u010d\u00edch lze pou\u017e\u00edt maxim\u00e1ln\u011b 1-2 tis\u00edce VRF. Sd\u00edlen\u00ed VRF a VLAN n\u00e1m d\u00e1v\u00e1 jen n\u011bkolik milion\u016f pods\u00edt\u00ed. To rozhodn\u011b nesta\u010d\u00ed pro des\u00edtky milion\u016f tenant\u016f, z nich\u017e ka\u017ed\u00fd mus\u00ed m\u00edt mo\u017enost vyu\u017e\u00edvat n\u011bkolik pods\u00edt\u00ed.<\/p>\n

Tak\u00e9 si jednodu\u0161e nem\u016f\u017eeme dovolit koupit po\u017eadovan\u00e9 mno\u017estv\u00ed velk\u00fdch box\u016f, nap\u0159\u00edklad od Cisco nebo Juniper. D\u016fvody jsou dva: je to \u0161\u00edlen\u011b drah\u00e9 a nechceme se dostat do z\u00e1vislosti na jejich politice v\u00fdvoje a patchov\u00e1n\u00ed.<\/p>\n

Jedno je jasn\u00e9 \u2013 mus\u00edme si uva\u0159it vlastn\u00ed \u0159e\u0161en\u00ed.<\/p><\/blockquote>\n

\nV roce 2009 jsme ozn\u00e1mili VPC<\/b> \u2014 Virtu\u00e1ln\u00ed priv\u00e1tn\u00ed cloud<\/b>. N\u00e1zev se ujal a nyn\u00ed ho pou\u017e\u00edv\u00e1 mnoho dal\u0161\u00edch poskytovatel\u016f cloudu.<\/p>\n

VPC je virtu\u00e1ln\u00ed s\u00ed\u0165 SDN<\/b> (Software Defined Network). Rozhodli jsme se nevym\u00fd\u0161let speci\u00e1ln\u00ed protokoly na \u00farovn\u00edch L2 a L3. S\u00ed\u0165 funguje na standardn\u00edm Ethernetu a IP. Pro p\u0159enos po s\u00edti se provoz virtu\u00e1ln\u00edch stroj\u016f encapsulov\u00e1 do obalu na\u0161eho vlastn\u00edho protokolu. V n\u011bm je uvedeno ID, kter\u00e9 pat\u0159\u00ed tenantovi VPC.<\/p>\n

\"Jak
\n
\nZn\u00ed to jednodu\u0161e. Nicm\u00e9n\u011b je t\u0159eba vy\u0159e\u0161it n\u011bkolik z\u00e1va\u017en\u00fdch technick\u00fdch \u00faloh. Nap\u0159\u00edklad kde a jak uchov\u00e1vat data o mapov\u00e1n\u00ed virtu\u00e1ln\u00edch MAC\/IP adres, VPC ID a odpov\u00eddaj\u00edc\u00edch fyzick\u00fdch MAC\/IP. V r\u00e1mci AWS to je obrovsk\u00e1 tabulka, kter\u00e1 mus\u00ed fungovat s minim\u00e1ln\u00edmi zpo\u017ed\u011bn\u00edmi p\u0159i p\u0159\u00edstupu. O to se star\u00e1 mapovac\u00ed slu\u017eba<\/b>, kter\u00e1 je rozprost\u0159ena tenkou vrstvou po cel\u00e9 s\u00edti.<\/p>\n

V nov\u00fdch generac\u00edch stroj\u016f je enkapsulace prov\u00e1d\u011bna kartami Nitro na hardwarov\u00e9 \u00farovni. Ve star\u0161\u00edch instanc\u00edch se enkapsulace a dekapsulace prov\u00e1d\u011bj\u00ed softwarem.\u00a0<\/p>\n

\"Jak
\n
\nPoj\u010fme se pod\u00edvat, jak to funguje v obecn\u00fdch rysech. Za\u010dneme na \u00farovni L2. P\u0159edpokl\u00e1dejme, \u017ee m\u00e1me virtu\u00e1ln\u00ed stroj s IP 10.0.0.2 na fyzick\u00e9m serveru 192.168.0.3. Ten pos\u00edl\u00e1 data virtu\u00e1ln\u00edmu stroji 10.0.0.3, kter\u00fd se nach\u00e1z\u00ed na 192.168.1.4. Vytv\u00e1\u0159\u00ed se ARP dotaz, kter\u00fd dopadne na s\u00ed\u0165ovou Nitro kartu. Pro zjednodu\u0161en\u00ed p\u0159edpokl\u00e1dejme, \u017ee ob\u011b virtu\u00e1ln\u00ed stroje jsou v jedn\u00e9 \u201emodr\u00e9\u201c VPC.<\/p>\n

\"Jak
\n
\nKarta nahrad\u00ed adresu zdroje svou vlastn\u00ed a p\u0159epo\u0161le ARP r\u00e1mec mapovac\u00ed slu\u017eb\u011b.<\/p>\n

\"Jak
\n
\nMapovac\u00ed slu\u017eba vr\u00e1t\u00ed informace, kter\u00e9 jsou pot\u0159ebn\u00e9 pro p\u0159enos po fyzick\u00e9 s\u00edti L2.<\/p>\n

\"Jak
\n
\nNitro karta v ARP odpov\u011bdi nahrad\u00ed MAC v fyzick\u00e9 s\u00edti adresou v VPC.<\/p>\n

\"Jak
\n
\nP\u0159i p\u0159enosu dat zabal\u00edme logick\u00e9 MAC a IP do VPC ob\u00e1lky. V\u0161echno to pos\u00edl\u00e1me po fyzick\u00e9 s\u00edti s pomoc\u00ed odpov\u00eddaj\u00edc\u00edch IP Nitro karet zdroje a c\u00edle.<\/p>\n

\"Jak
\n
\nFyzick\u00fd stroj, kter\u00e9mu je paket ur\u010den, provede kontrolu. To je d\u016fle\u017eit\u00e9, aby se p\u0159ede\u0161lo mo\u017enosti podvr\u017een\u00ed adres. Stroj pos\u00edl\u00e1 speci\u00e1ln\u00ed dotaz mapovac\u00ed slu\u017eb\u011b a pt\u00e1 se: \"Z fyzick\u00e9ho stroje 192.168.0.3 jsem obdr\u017eela paket, kter\u00fd je ur\u010den pro 10.0.0.3 v 'modr\u00e9' VPC. Je leg\u00e1ln\u00ed?\"\u00a0<\/p>\n

\"Jak
\n
\nMapovac\u00ed slu\u017eba porovn\u00e1 se svou tabulkou um\u00edst\u011bn\u00ed zdroj\u016f a bu\u010f povol\u00ed, nebo zak\u00e1\u017ee pr\u016fchod paketu. Ve v\u0161ech nov\u00fdch instanc\u00edch je dodate\u010dn\u00e1 validace zapracov\u00e1na do Nitro karet. Je nemo\u017en\u00e9 ji obelst\u00edt, ani teoreticky. Proto spoofing na zdroje v jin\u00e9 VPC nefunguje.<\/p>\n

\"Jak
\n
\nD\u00e1le jsou data odesl\u00e1na virtu\u00e1ln\u00edmu stroji, pro kter\u00fd jsou ur\u010dena.\u00a0<\/p>\n

\"Jak
\n
\nMapovac\u00ed slu\u017eba tak\u00e9 funguje jako logick\u00fd sm\u011brova\u010d pro p\u0159enos dat mezi virtu\u00e1ln\u00edmi stroji v r\u016fzn\u00fdch pods\u00edt\u00edch. Tam je konceptu\u00e1ln\u011b v\u0161e jednoduch\u00e9, nebudu to detailn\u011b rozeb\u00edrat.<\/p>\n

\"Jak
\n
\nZ toho vypl\u00fdv\u00e1, \u017ee p\u0159i p\u0159enosu ka\u017ed\u00e9ho paketu se servery obracej\u00ed na mapovac\u00ed slu\u017ebu. Jak se vyrovnat s nevyhnuteln\u00fdmi zpo\u017ed\u011bn\u00edmi? Mezipam\u011b\u0165ov\u00e1n\u00edm<\/b>, samoz\u0159ejm\u011b.<\/p>\n

Cel\u00e1 kr\u00e1sa spo\u010d\u00edv\u00e1 v tom, \u017ee nen\u00ed nutn\u00e9 cachovat celou obrovskou tabulku. Na fyzick\u00e9m serveru \u017eij\u00ed virtu\u00e1ln\u00ed instance ze relativn\u011b mal\u00e9ho po\u010dtu VPC. Informace je t\u0159eba cachovat pouze o t\u011bchto VPC. P\u0159enos dat do jin\u00fdch VPC v 'v\u00fdchoz\u00ed' konfiguraci p\u0159esto nen\u00ed leg\u00e1ln\u00ed. Pokud se pou\u017e\u00edv\u00e1 takov\u00e1 funkcionalita jako VPC-peering, pak se do cache dodate\u010dn\u011b na\u010d\u00edtaj\u00ed informace o odpov\u00eddaj\u00edc\u00edch VPC.\u00a0<\/p>\n

\"Jak
\n
\nS p\u0159enosem dat do VPC jsme si poradili.<\/p>\n

Blackfoot<\/h3>\n

\nCo d\u011blat v p\u0159\u00edpadech, kdy je t\u0159eba p\u0159en\u00e9st provoz ven, nap\u0159\u00edklad na Internet nebo p\u0159es VPN na zem? Zde n\u00e1m pom\u00e1h\u00e1 Blackfoot<\/b> \u2014 intern\u00ed slu\u017eba AWS. Byla vyvinuta na\u0161\u00edm jihoafrick\u00fdm t\u00fdmem. Proto se slu\u017eba jmenuje po tu\u010d\u0148\u00e1kovi, kter\u00fd \u017eije v Ji\u017en\u00ed Africe.<\/p>\n

\"Jak
\n
\nBlackfoot dekapsuluje provoz a d\u011bl\u00e1 s n\u00edm to, co je t\u0159eba. data do Internetu se odes\u00edlaj\u00ed tak, jak jsou.<\/p>\n

\"Jak
\n
\nData se dekapsuluj\u00ed a znovu obaluj\u00ed do IPsec p\u0159i pou\u017eit\u00ed VPN.<\/p>\n

\"Jak
\n
\nP\u0159i pou\u017eit\u00ed Direct Connect se provoz ozna\u010duje a p\u0159en\u00e1\u0161\u00ed do odpov\u00eddaj\u00edc\u00edho VLAN.<\/p>\n

\"Jak
\n<\/p>\n

HyperPlane<\/h3>\n

\nJe to intern\u00ed slu\u017eba pro kontrolu toku. Mnoho s\u00ed\u0165ov\u00fdch slu\u017eeb vy\u017eaduje kontrolu stavu datov\u00e9ho toku<\/b>. Nap\u0159\u00edklad p\u0159i pou\u017eit\u00ed NAT mus\u00ed kontrola toku garantovat, \u017ee ka\u017ed\u00e9mu p\u00e1ru 'IP: c\u00edlov\u00fd port' odpov\u00edd\u00e1 unik\u00e1tn\u00ed v\u00fdchoz\u00ed port. V p\u0159\u00edpad\u011b vyrovn\u00e1va\u010de zat\u00ed\u017een\u00ed NLB<\/b> \u2014 Network Load Balancer<\/b>, datov\u00fd tok mus\u00ed b\u00fdt v\u017edy nasm\u011brov\u00e1n na stejnou c\u00edlovou virtu\u00e1ln\u00ed instanci. Security Groups jsou firewall s uchov\u00e1n\u00edm stavu. Sleduj\u00ed p\u0159\u00edchoz\u00ed provoz a implicitn\u011b otev\u00edraj\u00ed porty pro odchoz\u00ed tok paket\u016f.<\/p>\n

\"Jak
\n
\nV cloudu AWS jsou po\u017eadavky na latence p\u0159enosu velmi vysok\u00e9. Proto HyperPlane<\/b> to je kritick\u00e9 pro funk\u010dnost cel\u00e9 s\u00edt\u011b.<\/p>\n

\"Jak
\n
\nHyperplane je postaven na virtu\u00e1ln\u00edch stroj\u00edch EC2. Nen\u00ed zde \u017e\u00e1dn\u00e1 magie, pouze finta. Finta spo\u010d\u00edv\u00e1 v tom, \u017ee to jsou virtu\u00e1ln\u00ed stroje s velk\u00fdm RAM. Transak\u010dn\u00ed operace prob\u00edhaj\u00ed v\u00fdhradn\u011b v pam\u011bti. To umo\u017e\u0148uje dos\u00e1hnout latenc\u00ed v r\u00e1mci des\u00edtek mikrosekund. Pr\u00e1ce s diskem by zabila ve\u0161ker\u00fd v\u00fdkon.\u00a0<\/p>\n

Hyperplane je distribuovan\u00fd syst\u00e9m z obrovsk\u00e9ho mno\u017estv\u00ed takov\u00fdch EC2 stroj\u016f. Ka\u017ed\u00e1 virtu\u00e1ln\u00ed instance m\u00e1 propustnost 5 GB\/s. V r\u00e1mci cel\u00e9 region\u00e1ln\u00ed s\u00edt\u011b to poskytuje \u0161\u00edlen\u00e9 terabity propustnosti a umo\u017e\u0148uje zpracovat miliony spojen\u00ed za sekundu.<\/b>.<\/p>\n

HyperPlane funguje pouze s toky. VPC enkapsulace paket\u016f je pro n\u011bj zcela pr\u016fhledn\u00e1. Potenci\u00e1ln\u00ed zranitelnost v t\u00e9to intern\u00ed slu\u017eb\u011b p\u0159esto neumo\u017en\u00ed prolomit izolaci VPC. Za bezpe\u010dnost odpov\u00eddaj\u00ed ni\u017e\u0161\u00ed \u00farovn\u011b.<\/p>\n

hlukov\u00fd soused<\/h3>\n

\nExistuje je\u0161t\u011b jeden probl\u00e9m hlukov\u00e9ho souseda<\/b> \u2014 hlukov\u00fd soused<\/b>. P\u0159edpokl\u00e1dejme, \u017ee m\u00e1me 8 uzl\u016f. Tyto uzly zpracov\u00e1vaj\u00ed toky v\u0161ech u\u017eivatel\u016f cloudu. Vypad\u00e1 to dob\u0159e a z\u00e1t\u011b\u017e by m\u011bla b\u00fdt rovnom\u011brn\u011b rozlo\u017eena mezi v\u0161echny uzly. Uzly jsou velmi v\u00fdkonn\u00e9 a je obt\u00ed\u017en\u00e9 je p\u0159et\u00ed\u017eit.<\/p>\n

Ale budujeme svou architekturu i na z\u00e1klad\u011b i nepravd\u011bpodobn\u00fdch sc\u00e9n\u00e1\u0159\u016f.\u00a0<\/p>\n

N\u00edzk\u00e1 pravd\u011bpodobnost neznamen\u00e1 nemo\u017enost.<\/p><\/blockquote>\n

\nM\u016f\u017eeme si p\u0159edstavit situaci, kdy jeden nebo n\u011bkolik u\u017eivatel\u016f generuj\u00ed p\u0159\u00edli\u0161 vysokou z\u00e1t\u011b\u017e. Do zpracov\u00e1n\u00ed t\u00e9to z\u00e1t\u011b\u017ee jsou zapojeny v\u0161echny uzly HyperPlane a ostatn\u00ed u\u017eivatel\u00e9 mohou potenci\u00e1ln\u011b poc\u00edtit ur\u010dit\u00e9 sn\u00ed\u017een\u00ed v\u00fdkonu. To naru\u0161uje koncept cloudu, ve kter\u00e9m nemaj\u00ed n\u00e1jemci mo\u017enost ovliv\u0148ovat jeden druh\u00e9ho.<\/p>\n

\"Jak
\n
\nJak vy\u0159e\u0161it probl\u00e9m hlu\u010dn\u00e9ho souseda? Prvn\u00ed, co m\u011b napadne, je shardov\u00e1n\u00ed. Na\u0161ich 8 uzl\u016f se logicky d\u011bl\u00ed na 4 shardy, p\u0159i\u010dem\u017e ka\u017ed\u00fd m\u00e1 2 uzly. Nyn\u00ed hlu\u010dn\u00fd soused ovlivn\u00ed pouze \u010dtvrtinu v\u0161ech u\u017eivatel\u016f, ale v\u00fdznamn\u011b.<\/p>\n

\"Jak
\n
\nUd\u011bl\u00e1me to jinak. Ka\u017ed\u00e9mu u\u017eivateli p\u0159id\u011bl\u00edme jen 3 uzly.\u00a0<\/p>\n

\"Jak
\n
\nFinta spo\u010d\u00edv\u00e1 v tom, \u017ee p\u0159i\u0159azujeme uzly r\u016fzn\u00fdm u\u017eivatel\u016fm n\u00e1hodn\u011b. Na obr\u00e1zku n\u00ed\u017ee se modr\u00fd u\u017eivatel p\u0159ekr\u00fdv\u00e1 s uzly jednoho ze dvou dal\u0161\u00edch u\u017eivatel\u016f \u2014 zelen\u00fdm a oran\u017eov\u00fdm.<\/p>\n

\"Jak
\n
\nP\u0159i 8 uzlech a 3 u\u017eivatel\u00edch je pravd\u011bpodobnost, \u017ee se hlu\u010dn\u00fd soused p\u0159ekryje s jedn\u00edm z u\u017eivatel\u016f, 54 %. S takovou pravd\u011bpodobnost\u00ed ovlivn\u00ed modr\u00fd u\u017eivatel ostatn\u00ed n\u00e1jemce. a to pouze \u010d\u00e1st\u00ed sv\u00e9 z\u00e1t\u011b\u017ee. V na\u0161em p\u0159\u00edkladu bude toto vliv viditeln\u00fd pouze pro t\u0159etinu v\u0161ech u\u017eivatel\u016f. To u\u017e je slu\u0161n\u00fd v\u00fdsledek.<\/p>\n

\u010c\u00edslo u\u017eivatel\u016f, kte\u0159\u00ed se p\u0159ekr\u00fdvaj\u00ed<\/p>\n

Pravd\u011bpodobnost v procentech<\/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

P\u0159ibl\u00ed\u017e\u00edme situaci k re\u00e1ln\u00e9 \u2014 vezmeme 100 uzl\u016f a 5 u\u017eivatel\u016f na 5 uzlech. V tomto p\u0159\u00edpad\u011b se \u017e\u00e1dn\u00fd z uzl\u016f s pravd\u011bpodobnost\u00ed 77 % nep\u0159ekr\u00fdv\u00e1.\u00a0<\/p>\n

\u010c\u00edslo u\u017eivatel\u016f, kte\u0159\u00ed se p\u0159ekr\u00fdvaj\u00ed<\/p>\n

Pravd\u011bpodobnost v procentech<\/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

Ve skute\u010dn\u00e9 situaci, p\u0159i velk\u00e9m po\u010dtu uzl\u016f HyperPlane a u\u017eivatel\u016f, je potenci\u00e1ln\u00ed vliv hlu\u010dn\u00e9ho souseda na ostatn\u00ed u\u017eivatele minim\u00e1ln\u00ed. Tato metoda se naz\u00fdv\u00e1 m\u00edch\u00e1n\u00ed shard\u016f<\/b> \u2014 shuffle sharding<\/b>. Minimalizuje negativn\u00ed dopad na selh\u00e1n\u00ed uzl\u016f.<\/p>\n

Na HyperPlane je postaveno mnoho slu\u017eeb: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

M\u011b\u0159\u00edtko s\u00edt\u011b<\/h3>\n

\nNyn\u00ed se pod\u00edvejme na m\u011b\u0159\u00edtko samotn\u00e9 s\u00edt\u011b. K \u0159\u00edjnu 2019 AWS nab\u00edz\u00ed sv\u00e9 slu\u017eby ve 22 regionech<\/b>, p\u0159i\u010dem\u017e dal\u0161\u00edch 9 je v pl\u00e1nu.<\/p>\n