{"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\/sq\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-seti","title":{"rendered":"Si i \u201cgatuan\u201d AWS sh\u00ebrbimet e veta elastike. Shkall\u00ebzimi i rrjetit","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Skala e rrjetit Amazon Web Services p\u00ebrb\u00ebhet nga 69 zona n\u00eb mbar\u00eb bot\u00ebn n\u00eb 22 rajone: SHBA, Evrop\u00eb, Azi, Afrik\u00eb dhe Australi. N\u00eb \u00e7do zon\u00eb ndodhen deri n\u00eb 8 Qendra t\u00eb t\u00eb Dh\u00ebnave (QTT). N\u00eb \u00e7do QTT ka mij\u00ebra ose qindra mij\u00ebra servera. Rrjeti \u00ebsht\u00eb nd\u00ebrtuar n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb gjitha skenar\u00ebt e pak\u00ebt t\u00eb nd\u00ebrprerjeve t\u00eb sh\u00ebrbimit t\u00eb merren parasysh. P\u00ebr shembull, t\u00eb gjitha rajonet jan\u00eb t\u00eb izoluar nga nj\u00ebra-tjetra, dhe zonat e disponueshm\u00ebris\u00eb jan\u00eb t\u00eb shp\u00ebrndara n\u00eb distanca disa kilometra. Edhe n\u00ebse pritet kabulli, sistemi do t\u00eb kaloj\u00eb n\u00eb kanale rezerv\u00eb, dhe humbja e informacionit do t\u00eb p\u00ebrb\u00ebhet nga nj\u00ebsi paketash t\u00eb dh\u00ebnash. N\u00eb lidhje me principet e tjera mbi t\u00eb cilat \u00ebsht\u00eb nd\u00ebrtuar rrjeti dhe si \u00ebsht\u00eb organizuar, do t\u00eb tregoj\u00eb Vasiliy Pantyukhin.<\/p>\n

\"Si
\n
\nVasiliy Pantyukhin<\/b> ka filluar si administrator Unix n\u00eb kompanit\u00eb .ru, ka kaluar 6 vjet me pajisje t\u00eb m\u00ebdha nga Sun Microsystems, dhe 11 vjet ka predikuar qendrim t\u00eb orientuar nga t\u00eb dh\u00ebnat n\u00eb EMC. N\u00eb m\u00ebnyr\u00eb natyrale, ka evoluar n\u00eb cloud privat, m\u00eb pas u bashkua me at\u00eb publik. Tani, si arkitekt i Amazon Web Services, ndihmon me k\u00ebshillat teknike q\u00eb t\u00eb jetojn\u00eb dhe zhvillohen n\u00eb cloud AWS.<\/p>\n

N\u00eb pjes\u00ebn e m\u00ebparshme t\u00eb trilogjis\u00eb p\u00ebr struktur\u00ebn e AWS, Vasiliy theksoi funksionimin e server\u00ebve fizik\u00eb dhe shkall\u00ebzimin e baz\u00ebs s\u00eb t\u00eb dh\u00ebnave. Kartat Nitro, hipervizori i personalizuar i bazuar n\u00eb KVM, baza e t\u00eb dh\u00ebnave Amazon Aurora \u2014 p\u00ebr t\u00eb gjitha k\u00ebto n\u00eb materialin \"Si i \u201cgatuan\u201d AWS sh\u00ebrbimet e veta elastike. Shkall\u00ebzimi i server\u00ebve dhe i baz\u00ebs s\u00eb t\u00eb dh\u00ebnave<\/a><\/noindex>\". Lexoni p\u00ebr t\u00eb zhytur n\u00eb kontekst, ose shikoni regjistrimin video<\/a><\/noindex> t\u00eb paraqitjes.<\/p>\n

N\u00eb k\u00ebt\u00eb pjes\u00eb do t\u00eb flasim p\u00ebr shkall\u00ebzimin e rrjetit \u2014 nj\u00eb nga sistemet m\u00eb t\u00eb komplikuara n\u00eb AWS. Evolucioni nga rrjeti i shesht\u00eb n\u00eb Rrjetin Privat Virtual dhe struktura e tij, sh\u00ebrbimet e brendshme Blackfoot dhe HyperPlane, problemi i fqinjit t\u00eb zhurmsh\u00ebm, dhe n\u00eb fund \u2014 shkall\u00ebt e rrjetit, backbone dhe kabujt fizik\u00eb. P\u00ebr t\u00eb gjitha k\u00ebto m\u00eb posht\u00eb.<\/p>\n

Paralajm\u00ebrim: gjith\u00e7ka m\u00eb posht\u00eb \u2014 mendim personal i Vasiliy, dhe mund t\u00eb mos p\u00ebrkoj\u00eb me pozitat e Amazon Web Services.<\/i>
\n<\/a><\/noindex><\/p>\n

Shkall\u00ebzimi i rrjetit<\/h2>\n

\nCloud AWS \u00ebsht\u00eb lan\u00e7uar n\u00eb vitin 2006. Rrjeti i tij ishte mjaft primitiv \u2014 me struktur\u00eb t\u00eb shesht\u00eb. Cil\u00ebsia e adresave private ishte e zakonshme p\u00ebr t\u00eb gjith\u00eb p\u00ebrdoruesit e cloud-it. Kur nisje nj\u00eb makin\u00eb virtuale t\u00eb re rast\u00ebsisht merrje nj\u00eb adres\u00eb IP t\u00eb disponueshme nga ky gam\u00eb.<\/p>\n

\"Si
\n
\nKjo qasje ishte e leht\u00eb p\u00ebr t'u implementuar, por substantialisht kufizonte p\u00ebrdorimin e cloud-it. N\u00eb ve\u00e7anti, ishte mjaft e v\u00ebshtir\u00eb t\u00eb zhvilloheshin zgjidhje hibride, ku bashkoheshin rrjetet private n\u00eb tok\u00eb dhe n\u00eb AWS. Problemi m\u00eb i zakonsh\u00ebm ishte n\u00eb p\u00ebrputhjen e gamave t\u00eb adresave IP.<\/p>\n

\"Si
\n<\/p>\n

Reku i Privat Virtual<\/h3>\n

\nReku ka qen\u00eb shum\u00eb i k\u00ebrkuar. Ka ardhur koha t\u00eb mendojm\u00eb p\u00ebr shkall\u00ebzueshm\u00ebrin\u00eb dhe mund\u00ebsin\u00eb e p\u00ebrdorimit t\u00eb tij nga miliona t\u00eb qiramar\u00ebs. Rrjeti i shesht\u00eb \u00ebsht\u00eb b\u00ebr\u00eb pengesa kryesore. Prandaj, kemi filluar t\u00eb mendojm\u00eb si t'i izolojm\u00eb p\u00ebrdoruesit nga nj\u00ebri-tjetri n\u00eb nivelin e rrjetit, n\u00eb m\u00ebnyr\u00eb q\u00eb ata t\u00eb mund t\u00eb zgjedhin vet\u00eb ranges IP.<\/p>\n

\"Si
\n
\n\u00c7ka t\u00eb par\u00ebn bie n\u00eb mendje kur mendoni p\u00ebr izolimin rrjetor? Sigurisht VLAN<\/b> dhe VRF \u2014 Rrug\u00ebzim dhe P\u00ebr\u00e7ues Virtual<\/b>.<\/p>\n

Fatkeq\u00ebsisht, kjo nuk funksionoi. VLAN ID \u00ebsht\u00eb vet\u00ebm 12 bit, q\u00eb na jep vet\u00ebm 4096 segmente t\u00eb izoluar. Edhe n\u00eb kalimtar\u00ebt m\u00eb t\u00eb m\u00ebdhenj, mund t\u00eb p\u00ebrdoren maksimumi 1-2 mij\u00eb VRF. Nd\u00ebrveprimi i VRF dhe VLAN na jep vet\u00ebm disa miliona n\u00ebnshembuj. Kjo \u00ebsht\u00eb me t\u00eb v\u00ebrtet\u00eb e pamjaftueshme p\u00ebr dhjet\u00ebra miliona t\u00eb qiramar\u00ebs, secili prej t\u00eb cil\u00ebve duhet t\u00eb ket\u00eb mund\u00ebsin\u00eb t\u00eb p\u00ebrdor\u00eb disa n\u00ebnshembuj.<\/p>\n

Po ashtu, ne thjesht nuk mund t\u00eb p\u00ebrballojm\u00eb blerjen e numrit t\u00eb k\u00ebrkuar t\u00eb kutive t\u00eb m\u00ebdha, p\u00ebr shembull, nga Cisco ose Juniper. Ka dy arsye: \u00ebsht\u00eb josh\u00ebs \u00e7mimi, dhe ne nuk duam t\u00eb b\u00ebhemi t\u00eb varur nga politika e tyre e zhvillimit dhe patching.<\/p>\n

P\u00ebrfundimi \u00ebsht\u00eb nj\u00eb \u2013 t\u00eb gatuajm\u00eb zgjidhjen ton\u00eb.<\/p><\/blockquote>\n

\nN\u00eb vitin 2009 ne shpall\u00ebm VPC<\/b> \u2014 Reku i Privat Virtual<\/b>. Emri u b\u00eb i njohur dhe tani shum\u00eb ofrues t\u00eb tjer\u00eb t\u00eb cloud-it e p\u00ebrdorin gjithashtu at\u00eb.<\/p>\n

VPC \u00ebsht\u00eb nj\u00eb rrjet virtual SDN<\/b> (Rrjeti e Definuar nga Softueri). Ne vendos\u00ebm t\u00eb mos shpikim protokolle t\u00eb ve\u00e7anta n\u00eb nivelet L2 dhe L3. Rrjeti funksionon mbi Ethernet dhe IP standard. P\u00ebr t\u00eb d\u00ebrguar trafikun, l\u00ebvizja e makinerive virtuale incapsulohet n\u00eb nj\u00eb mbules\u00eb t\u00eb protokollit ton\u00eb. Aty tregohet ID, i cili i p\u00ebrket VPC t\u00eb qiramar\u00ebs.<\/p>\n

\"Si
\n
\nD\u00ebgjohet e thjesht\u00eb. Megjithat\u00eb, duhet t\u00eb zgjidhim disa probleme teknike serioze. P\u00ebr shembull, ku dhe si t\u00eb ruajm\u00eb t\u00eb dh\u00ebnat mbi kartat e virtualizuara MAC\/IP, VPC ID dhe MAC\/IP t\u00eb p\u00ebrkatshme fizike. Nj\u00eb tabel\u00eb e till\u00eb q\u00eb do t\u00eb punoj\u00eb me vonesa minimale, \u00ebsht\u00eb nj\u00eb sfid\u00eb e madhe n\u00eb shkall\u00eb AWS. Kjo \u00ebsht\u00eb p\u00ebrgjegj\u00ebsi e sh\u00ebrbimit t\u00eb kart\u00ebs<\/b>, i cili \u00ebsht\u00eb shtrir\u00eb n\u00ebn nj\u00eb shtres\u00eb t\u00eb holl\u00eb n\u00eb t\u00eb gjith\u00eb rrjetin.<\/p>\n

N\u00eb makinat e brezit t\u00eb ri, incapsulimi kryhet nga kartat Nitro n\u00eb nivelin e harduerit. N\u00eb instancat e vjetra, incapsulimi dhe dekapitulimi jan\u00eb programore.\u00a0<\/p>\n

\"Si
\n
\nT\u00eb shohim se si funksionon n\u00eb terma t\u00eb p\u00ebrgjithsh\u00ebm. Le t\u00eb fillojm\u00eb nga niveli L2. Supozojm\u00eb se kemi nj\u00eb virtualk\u00eb me IP 10.0.0.2 n\u00eb serverin fizik 192.168.0.3. Ajo d\u00ebrgon t\u00eb dh\u00ebna n\u00eb makin\u00eb virtuale 10.0.0.3, e cila jeton n\u00eb 192.168.1.4. Krijohet nj\u00eb k\u00ebrkes\u00eb ARP, e cila shkon n\u00eb kart\u00ebn rrjetike Nitro. P\u00ebr thjeshtsi, le t\u00eb supozojm\u00eb se t\u00eb dy virtualkat jetojn\u00eb n\u00eb nj\u00eb VPC \"blu\".<\/p>\n

\"Si
\n
\nKarta z\u00ebvend\u00ebson adres\u00ebn e burimit me t\u00eb vet\u00ebn dhe d\u00ebrgon korniz\u00ebn ARP n\u00eb sh\u00ebrbimin e hart\u00ebs.<\/p>\n

\"Si
\n
\nSh\u00ebrbimi i hart\u00ebs kthen informacionin e nevojsh\u00ebm p\u00ebr transmetimin n\u00eb rrjetin fizik L2.<\/p>\n

\"Si
\n
\nNitro-karta n\u00eb p\u00ebrgjigjen ARP z\u00ebvend\u00ebson MAC-in n\u00eb rrjetin fizik me adres\u00ebn n\u00eb VPC.<\/p>\n

\"Si
\n
\nGjat\u00eb d\u00ebrgimit t\u00eb t\u00eb dh\u00ebnave, ne mb\u00ebshtjellim MAC dhe IP logjik n\u00eb nj\u00eb mb\u00ebshtjell\u00ebs VPC. T\u00eb gjitha k\u00ebto i d\u00ebrgojm\u00eb n\u00eb rrjetin fizik duke p\u00ebrdorur IP-t\u00eb p\u00ebrkat\u00ebse t\u00eb kartave Nitro t\u00eb burimit dhe destinacionit.<\/p>\n

\"Si
\n
\nMakin\u00eb fizike, p\u00ebr t\u00eb cil\u00ebn \u00ebsht\u00eb paketa, kryen nj\u00eb kontroll. Kjo \u00ebsht\u00eb e nevojshme p\u00ebr t\u00eb parandaluar mund\u00ebsin\u00eb e z\u00ebvend\u00ebsimit t\u00eb adresave. Makin\u00eb d\u00ebrgon nj\u00eb k\u00ebrkes\u00eb speciale n\u00eb sh\u00ebrbimin e hart\u00ebs dhe pyet: \"Nga makina fizike 192.168.0.3 kam marr\u00eb nj\u00eb paket\u00eb, e cila \u00ebsht\u00eb e destinuar p\u00ebr 10.0.0.3 n\u00eb VPC \"t\u00eb kalt\u00ebr\". A \u00ebsht\u00eb legjitime?\"\u00a0<\/p>\n

\"Si
\n
\nSh\u00ebrbimi i hart\u00ebs kontrollon me tabel\u00ebn e tij t\u00eb vendosjes s\u00eb burimeve dhe lejon, ose ndalon kalimin e paket\u00ebs. N\u00eb t\u00eb gjitha instancat e reja, nj\u00eb verifikim shtes\u00eb \u00ebsht\u00eb i koduar n\u00eb kartat Nitro. Kjo nuk mund t\u00eb shmangesh as teorikisht. Prandaj, spoofing n\u00eb burimet e VPC tjet\u00ebr nuk do t\u00eb funksionoj\u00eb.<\/p>\n

\"Si
\n
\nM\u00eb pas, t\u00eb dh\u00ebnat d\u00ebrgohen n\u00eb makin\u00ebn virtuale p\u00ebr t\u00eb cil\u00ebn ato jan\u00eb t\u00eb destinuara.\u00a0<\/p>\n

\"Si
\n
\nSh\u00ebrbimi i hart\u00ebs funksionon gjithashtu si nj\u00eb ruter logjik p\u00ebr transmetimin e t\u00eb dh\u00ebnave mes virtualkave n\u00eb n\u00ebnrrjeta t\u00eb ndryshme. Aty konceptualisht gjith\u00e7ka \u00ebsht\u00eb e thjesht\u00eb, nuk do ta shqyrtoj n\u00eb detaje.<\/p>\n

\"Si
\n
\nK\u00ebshtu q\u00eb, gjat\u00eb d\u00ebrgimit t\u00eb \u00e7do pakete, server\u00ebt i drejtohen sh\u00ebrbimit t\u00eb hart\u00ebs. Si t\u00eb luftojm\u00eb me vonesat e pashmangshme? Me cache<\/b>, sigurisht.<\/p>\n

E gjith\u00eb bukuria \u00ebsht\u00eb se nuk \u00ebsht\u00eb e nevojshme t\u00eb ruhet e gjith\u00eb tabela e madhe. N\u00eb serverin fizik jetojn\u00eb virtualka nga nj\u00eb num\u00ebr relativisht i vog\u00ebl VPC. Duhet t\u00eb ruhet informacioni vet\u00ebm p\u00ebr k\u00ebto VPC. D\u00ebrgimi i t\u00eb dh\u00ebnave n\u00eb VPC t\u00eb tjera n\u00eb konfigurimin \"default\" megjithat\u00eb nuk \u00ebsht\u00eb legjitim. N\u00ebse p\u00ebrdoret nj\u00eb funksionalitet si VPC-peering, at\u00ebher\u00eb informacioni mbi VPC-t\u00eb p\u00ebrkat\u00ebse ngarkohet shtes\u00eb n\u00eb cache.\u00a0<\/p>\n

\"Si
\n
\nKemi sqaruar d\u00ebrgimin e t\u00eb dh\u00ebnave n\u00eb VPC.<\/p>\n

Blackfoot<\/h3>\n

\nSi si t\u00eb veprojm\u00eb n\u00eb raste kur trafik duhet t\u00eb d\u00ebrgohet jasht\u00eb, p\u00ebr shembull n\u00eb Internet ose p\u00ebrmes VPN n\u00eb tok\u00eb? K\u00ebtu na ndihmon Blackfoot<\/b> \u2014 sh\u00ebrbimi i brendsh\u00ebm AWS. Ai \u00ebsht\u00eb zhvilluar nga ekipi yn\u00eb n\u00eb Afrik\u00ebn e Jugut. K\u00ebshtu q\u00eb sh\u00ebrbimi ka marr\u00eb emrin nga pinguini q\u00eb jeton n\u00eb Afrik\u00ebn e Jugut.<\/p>\n

\"Si
\n
\nBlackfoot dekapsulon trafikun dhe b\u00ebn me t\u00eb at\u00eb q\u00eb nevojitet. T\u00eb dh\u00ebnat n\u00eb Internet d\u00ebrgohen si\u00e7 jan\u00eb.<\/p>\n

\"Si
\n
\nT\u00eb dh\u00ebnat dekapsulohen dhe pastaj shtrihen p\u00ebrs\u00ebri n\u00eb paketat IPsec kur p\u00ebrdoret VPN.<\/p>\n

\"Si
\n
\nN\u00eb p\u00ebrdorimin e Direct Connect, trafiku etiketohen dhe d\u00ebrgohen n\u00eb VLAN-in p\u00ebrkat\u00ebs.<\/p>\n

\"Si
\n<\/p>\n

HyperPlane<\/h3>\n

\nKy \u00ebsht\u00eb nj\u00eb sh\u00ebrbim i brendsh\u00ebm p\u00ebr kontrollin e trafikut. Shum\u00eb sh\u00ebrbime rrjetesh k\u00ebrkojn\u00eb kontrollin e statusit t\u00eb trafikut t\u00eb dh\u00ebnash<\/b>. P\u00ebr shembull, n\u00eb p\u00ebrdorimin e NAT, kontrolli i trafikut duhet t\u00eb siguroj\u00eb q\u00eb \u00e7do \u00e7ift \"IP: porta e destinacionit\" t\u00eb korrespondon me nj\u00eb port t\u00eb vet\u00ebm dal\u00ebs. N\u00eb rastin e balancuesit NLB<\/b> \u2014 Balancuesi i Ngarkes\u00ebs n\u00eb Rrjet<\/b>, trafiku i t\u00eb dh\u00ebnave gjithmon\u00eb duhet t\u00eb drejtohet n\u00eb t\u00eb nj\u00ebjt\u00ebn makin\u00eb virtuale t\u00eb destinacionit. Grupet e Siguris\u00eb \u2014 jan\u00eb nj\u00eb firewall me ruajtjen e statusit. Ai ndjek trafikun e ardhsh\u00ebm dhe hap portat p\u00ebr trafikun dal\u00ebs n\u00eb m\u00ebnyr\u00eb t\u00eb heshtur.<\/p>\n

\"Si
\n
\nN\u00eb cloud-in AWS, k\u00ebrkesat p\u00ebr vonesa transmetimi jan\u00eb jasht\u00ebzakonisht t\u00eb larta. Prandaj HyperPlane<\/b> \u00ebsht\u00eb kritik p\u00ebr funksionalitetin e t\u00ebr\u00eb rrjetit.<\/p>\n

\"Si
\n
\nHyperplane \u00ebsht\u00eb nd\u00ebrtuar mbi makina virtuale EC2. K\u00ebtu nuk ka magji, vet\u00ebm mjesht\u00ebri. Mjesht\u00ebria q\u00ebndron n\u00eb faktin se k\u00ebto jan\u00eb makina virtuale me RAM t\u00eb madh. Operacionet jan\u00eb transaksionale dhe kryhen ekskluzivisht n\u00eb memorie. Kjo lejon t\u00eb arrijm\u00eb vonesa vet\u00ebm disa mikrosekondash. Nd\u00ebrveprimi me disqet do t\u00eb shkat\u00ebrronte t\u00ebr\u00eb performanc\u00ebn.\u00a0<\/p>\n

Hyperplane \u00ebsht\u00eb nj\u00eb sistem i shp\u00ebrndar\u00eb nga nj\u00eb num\u00ebr t\u00eb madh t\u00eb till\u00eb EC2-makina. \u00c7do makin\u00eb virtuale ka nj\u00eb kapacitet prej 5 GB\/s. N\u00eb shkall\u00ebn e t\u00ebr\u00eb rrjetit rajonal, kjo ofron terabite t\u00eb furishme kapaciteti dhe lejon trajtimin e miliona lidhjeve n\u00eb sekond\u00eb.<\/b>.<\/p>\n

HyperPlane punon vet\u00ebm me rrjedha. VPC incapsulimi i pakot \u00ebsht\u00eb plot\u00ebsisht transparent p\u00ebr t\u00eb. Nj\u00eb potencial p\u00ebr t\u00eb b\u00ebr\u00eb d\u00ebm n\u00eb k\u00ebt\u00eb sh\u00ebrbim t\u00eb brendsh\u00ebm s\u00ebrish nuk do t'i lejonte t\u00eb kalonte izolimin VPC. Siguria mbrohet nga nivelet m\u00eb posht\u00eb.<\/p>\n

Fqinja e zhurmshme<\/h3>\n

\nKa gjithashtu nj\u00eb problem me fqinj\u00ebt e zhurmsh\u00ebm<\/b> \u2014 fqinj i zhurmsh\u00ebm<\/b>. Le t\u00eb supozojm\u00eb se kemi 8 node. K\u00ebto node p\u00ebrpunojn\u00eb flukset e t\u00eb gjith\u00eb p\u00ebrdoruesve t\u00eb cloud-it. Duket se gjith\u00e7ka \u00ebsht\u00eb n\u00eb rregull dhe ngarkesa duhet t\u00eb shp\u00ebrndahet n\u00eb m\u00ebnyr\u00eb t\u00eb barabart\u00eb mbi t\u00eb gjitha node-t. Node-t jan\u00eb shum\u00eb t\u00eb fuqishme dhe \u00ebsht\u00eb e v\u00ebshtir\u00eb t'i mbingarkosh ato.<\/p>\n

Por ne e nd\u00ebrtuam arkitektur\u00ebn ton\u00eb duke u bazuar edhe n\u00eb skenar\u00eb t\u00eb pamundur.\u00a0<\/p>\n

Nj\u00eb probabilitet i ul\u00ebt nuk do t\u00eb thot\u00eb se \u00ebsht\u00eb e pamundur.<\/p><\/blockquote>\n

\nMund ta imagjinojm\u00eb nj\u00eb situat\u00eb ku nj\u00eb ose disa p\u00ebrdorues do t\u00eb gjeneronin nj\u00eb ngarkes\u00eb shum\u00eb t\u00eb madhe. T\u00eb gjith\u00eb node-t e HyperPlane p\u00ebrfshihen n\u00eb p\u00ebrpunimin e k\u00ebsaj ngarkese dhe p\u00ebrdoruesit e tjer\u00eb potencialisht mund t\u00eb ndiejn\u00eb nj\u00eb r\u00ebnie t\u00eb performanc\u00ebs. Kjo shkat\u00ebrron konceptin e cloud-it, n\u00eb t\u00eb cilin tenant\u00ebt nuk kan\u00eb mund\u00ebsi t\u00eb ndikojn\u00eb n\u00eb nj\u00ebri-tjetrin.<\/p>\n

\"Si
\n
\nSi ta zgjidhim problemin e fqinjit t\u00eb zhurmsh\u00ebm? E para q\u00eb na vjen n\u00eb mendje \u00ebsht\u00eb shardimi. 8 node-t tona ndahen logjikisht n\u00eb 4 sharda me nga 2 node n\u00eb secilin. Tani fqinji i zhurmsh\u00ebm do t\u00eb pengoj\u00eb vet\u00ebm nj\u00eb t\u00eb kat\u00ebrt\u00ebn e t\u00eb gjith\u00eb p\u00ebrdoruesve, por shum\u00eb.<\/p>\n

\"Si
\n
\nLe t\u00eb veprojm\u00eb ndryshe. \u00c7do p\u00ebrdorues t\u00eb ket\u00eb vet\u00ebm 3 node.\u00a0<\/p>\n

\"Si
\n
\nTruku \u00ebsht\u00eb t\u00eb caktosh node t\u00eb ndryshme p\u00ebrdoruesve t\u00eb ndrysh\u00ebm rast\u00ebsisht. N\u00eb figur\u00ebn m\u00eb posht\u00eb, p\u00ebrdoruesi me ngjyr\u00eb blu prek node-t me nj\u00eb nga dy p\u00ebrdoruesit e tjer\u00eb \u2014 t\u00eb gjelb\u00ebrin dhe portokallin.<\/p>\n

\"Si
\n
\nMe 8 node dhe 3 p\u00ebrdorues, probabiliteti i p\u00ebrputhjes s\u00eb fqinjit t\u00eb zhursh\u00ebm me nj\u00eb nga p\u00ebrdoruesit \u00ebsht\u00eb 54%. Me k\u00ebt\u00eb probabilitet, p\u00ebrdoruesi blu do t\u00eb ndikoj\u00eb n\u00eb tenant\u00ebt e tjer\u00eb. N\u00eb k\u00ebt\u00eb rast, kjo do t\u00eb ndodh\u00eb vet\u00ebm me nj\u00eb pjes\u00eb t\u00eb ngarkes\u00ebs s\u00eb tij. N\u00eb shembullin ton\u00eb, ky ndikim do t\u00eb jet\u00eb i duksh\u00ebm vet\u00ebm p\u00ebr nj\u00eb t\u00eb tret\u00ebn e t\u00eb gjith\u00eb p\u00ebrdoruesve. Kjo \u00ebsht\u00eb tashm\u00eb nj\u00eb rezultat i mir\u00eb.<\/p>\n

Numri i p\u00ebrdoruesve q\u00eb do t\u00eb p\u00ebrputhen<\/p>\n

Probabiliteti n\u00eb p\u00ebrqindje<\/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

Le t\u00eb afrojm\u00eb situat\u00ebn me reale \u2014 t\u00eb marrim 100 node dhe 5 p\u00ebrdorues n\u00eb 5 node. N\u00eb k\u00ebt\u00eb rast, asnj\u00eb nga node-t nuk do t\u00eb p\u00ebrputhet me nj\u00eb probabilitet prej 77%.\u00a0<\/p>\n

Numri i p\u00ebrdoruesve q\u00eb do t\u00eb p\u00ebrputhen<\/p>\n

Probabiliteti n\u00eb p\u00ebrqindje<\/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

N\u00eb nj\u00eb situat\u00eb reale, me nj\u00eb num\u00ebr shum\u00eb t\u00eb madh node-sh HyperPlane dhe p\u00ebrdoruesish, ndikimi potencial i fqinjit t\u00eb zhurmsh\u00ebm ndaj p\u00ebrdoruesve t\u00eb tjer\u00eb \u00ebsht\u00eb minimal. Ky metod quhet shardim me p\u00ebrzierje<\/b> \u2014 shuffle sharding<\/b>. Ai minimizon efektin negativ nga dalja e node-ve jasht\u00eb funksionit.<\/p>\n

Shum\u00eb sh\u00ebrbime jan\u00eb nd\u00ebrtuar mbi baz\u00ebn e HyperPlane: Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway.<\/p>\n

Mast\u00ebr t\u00eb rrjetit<\/h3>\n

\nTani do flasim p\u00ebr p\u00ebrmasat e vet\u00eb rrjetit. N\u00eb tetor 2019, AWS ofron sh\u00ebrbimet e veta n\u00eb 22 rajone<\/b>, dhe jan\u00eb t\u00eb planifikuara edhe 9 t\u00eb tjera.<\/p>\n