{"id":97373,"date":"2020-10-17T14:42:32","date_gmt":"2020-10-17T12:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/seteviki-ne-nuzhny"},"modified":"2020-10-17T14:42:32","modified_gmt":"2020-10-17T12:42:32","slug":"seteviki-ne-nuzhny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Inxhinier\u00ebt e rrjetit (nuk) jan\u00eb t\u00eb nevojsh\u00ebm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

N\u00eb momentin e shkrimit t\u00eb k\u00ebtij artikulli, k\u00ebrkimi n\u00eb nj\u00eb nga faqet m\u00eb t\u00eb njohura p\u00ebr pun\u00eb p\u00ebr fraz\u00ebn \"Inxhinier rrjeti\" jepte rreth triqind vende pune n\u00eb t\u00eb gjith\u00eb Rusin\u00eb. Krahasimisht, k\u00ebrkimi p\u00ebr fraz\u00ebn \"administratori i sistemit\" jep pothuajse 2.5 mij\u00eb vende pune, nd\u00ebrsa \"Inxhinier DevOps\" - pothuajse 800.<\/p>\n

A do t\u00eb thot\u00eb kjo se inxhinier\u00ebt e rrjetit nuk nevojiten m\u00eb n\u00eb koh\u00ebn e skajshme t\u00eb mjeteve t\u00eb reja si reja, docker, kubernetes dhe wifi i gjithansh\u00ebm publik?
\nLe t\u00eb sqarojm\u00eb (c)<\/p>\n

\"Inxhinier\u00ebt
\n<\/a><\/noindex>
\nLe t\u00eb njihemi. Un\u00eb quhem Aleksei dhe jam inxhinier rrjeti. <\/p>\n

Kam m\u00eb shum\u00eb se 10 vjet q\u00eb merrem me rrjete dhe mbi 15 vjet q\u00eb punoj me sisteme t\u00eb ndryshme *nix (kam pasur mund\u00ebsin\u00eb t\u00eb punoj me Linux dhe FreeBSD). Kam punuar n\u00eb operator\u00eb t\u00eb komunikacionit dhe n\u00eb kompani t\u00eb m\u00ebdha q\u00eb zakonisht konsiderohen \"enterprise\", dhe koh\u00ebt e fundit kam punuar n\u00eb nj\u00eb fintech \"t\u00eb ri dhe t\u00eb guximsh\u00ebm\", ku reja, devops, kubernetes dhe terma t\u00eb tjer\u00eb t\u00eb friksh\u00ebm q\u00eb patjet\u00ebr do t\u00eb b\u00ebjn\u00eb q\u00eb un\u00eb dhe koleg\u00ebt e mi t\u00eb b\u00ebhemi t\u00eb panevojsh\u00ebm. Ndonj\u00ebher\u00eb. Ndoshta.<\/p>\n

disclaimer: \"N\u00eb jet\u00ebn ton\u00eb, jo gjith\u00e7ka \u00ebsht\u00eb gjithmon\u00eb dhe kudo, dhe disa gj\u00ebra ndodhin her\u00eb pas here dhe n\u00eb disa vende\" (c) Maksim Dorofejev.<\/p>\n

Gjith\u00e7ka e shkruar m\u00eb posht\u00eb mund dhe duhet t\u00eb merret si opinion personal i autorit, q\u00eb nuk pretendon t\u00eb jet\u00eb e v\u00ebrteta finale, dhe madje as nj\u00eb studim t\u00eb plot\u00eb. T\u00eb gjith\u00eb karakteret jan\u00eb fiktiv\u00eb, t\u00eb gjitha p\u00ebrputhjet jan\u00eb rast\u00ebsi.<\/p><\/blockquote>\n

Mir\u00eb se vini n\u00eb bot\u00ebn time.<\/p>\n

Ku mund t\u00eb takoni inxhinier\u00ebt e rrjetit?<\/h3>\n

\n1. Operator\u00ebt e komunikacionit, kompanit\u00eb e sh\u00ebrbimeve dhe integrator\u00eb t\u00eb tjer\u00eb<\/b>. K\u00ebtu gjith\u00e7ka \u00ebsht\u00eb e thjesht\u00eb: rrjeti p\u00ebr ta \u00ebsht\u00eb biznes. Ata ose shesin direkt lidhjen (operator\u00ebt), ose ofrojn\u00eb sh\u00ebrbime p\u00ebr nisjen\/mbajtjen e rrjeteve t\u00eb klient\u00ebve t\u00eb tyre. <\/p>\n

Ka shum\u00eb p\u00ebrvoj\u00eb k\u00ebtu, para nuk ka shum\u00eb (n\u00ebse nuk jeni drejtor ose menaxher i suksessh\u00ebm i shitjeve). Megjithat\u00eb, n\u00ebse ju p\u00eblqejn\u00eb rrjetet dhe jeni vet\u00ebm n\u00eb fillim t\u00eb rrug\u00ebs, nj\u00eb karrier\u00eb n\u00eb suport te ndonj\u00eb operator jo shum\u00eb t\u00eb madh do t\u00eb ishte, madje tani, pika ideale p\u00ebr t'u nisur (n\u00eb operator\u00ebt federal\u00eb gjith\u00e7ka \u00ebsht\u00eb shum\u00eb e strukturuar dhe ka pak hap\u00ebsir\u00eb p\u00ebr krijimtarin\u00eb). Po ashtu, tregimet p\u00ebr at\u00eb se si mund t\u00eb rritesh nga inxhinier dezhurn me kalimin e disa viteve n\u00eb menaxher C-level jan\u00eb gjithashtu t\u00eb v\u00ebrteta, megjith\u00ebse t\u00eb rralla, p\u00ebr arsye t\u00eb kuptueshme. Nevoja p\u00ebr staf \u00ebsht\u00eb gjithmon\u00eb, sepse rotacioni \u00ebsht\u00eb nj\u00eb realitet. Kjo \u00ebsht\u00eb e mir\u00eb dhe e keqe nj\u00ebkoh\u00ebsisht \u2013 gjithmon\u00eb ka vende t\u00eb lira, nga ana tjet\u00ebr \u2013 shpesh, ata m\u00eb aktiv\u00eb\/din\u00eb shk\u00ebmbejn\u00eb t\u00eb shpejt\u00eb ose p\u00ebrparojn\u00eb, ose shkojn\u00eb n\u00eb vende m\u00eb \"t\u00eb ngrohta\".<\/p>\n

2. \"Enterpraiz\" i kushtuar<\/b>Nuk \u00ebsht\u00eb e r\u00ebnd\u00ebsishme n\u00ebse aktiviteti kryesor \u00ebsht\u00eb i lidhur me IT-n\u00eb apo jo. E r\u00ebnd\u00ebsishme \u00ebsht\u00eb q\u00eb ka nj\u00eb departament IT, i cili merret me funksionimin e sistemeve t\u00eb brendshme t\u00eb kompanis\u00eb, p\u00ebrfshir\u00eb rrjetin n\u00eb zyrat, kanalet e komunikimit n\u00eb deg\u00eb, etj. Funksionet e inxhinierit t\u00eb rrjetit n\u00eb k\u00ebto kompani mund t\u00eb kryhen \"p\u00ebrkrahje\" nga nj\u00eb administrator sistemi (n\u00ebse infrastruktura e rrjetit \u00ebsht\u00eb e vog\u00ebl, ose merret nga nj\u00eb kontraktues i jasht\u00ebm), nd\u00ebrsa inxhinier\u00ebt e rrjetit, n\u00ebse ata ekzistojn\u00eb, mund t\u00eb mbik\u00ebqyrin gjithashtu telefonin\u00eb dhe SAN (nuk \u00ebsht\u00eb e thjesht\u00eb). Pagesat ndryshojn\u00eb \u2013 varen shum\u00eb nga marxhinaliteti i biznesit, p\u00ebrmasat e kompanis\u00eb dhe struktura. Kam punuar me kompani ku rrjetet Cisco ngarkoheshin rregullisht me ton, dhe me kompani ku rrjeti nd\u00ebrrminej nga plehra, shkopinj dhe ngjit\u00ebs i bluar, nd\u00ebrsa server\u00ebt nuk p\u00ebrdit\u00ebsoheshin pothuajse kurr\u00eb (nuk duhet t\u00eb p\u00ebrmendim se nuk ishin parashikuar as redaktor\u00ebt). Eksperienca k\u00ebtu \u00ebsht\u00eb shum\u00eb m\u00eb e vog\u00ebl, dhe ajo, pothuajse me siguri do t\u00eb jet\u00eb n\u00eb fush\u00ebn e bllokimit t\u00eb fort\u00eb nga shit\u00ebsit, ose \"si t\u00eb b\u00ebsh di\u00e7ka nga asgj\u00eb\". Personal, m\u00eb \u00ebsht\u00eb dukur shum\u00eb e m\u00ebrzitshme, megjithat\u00eb shum\u00eb i p\u00eblqen \u2013 gjith\u00e7ka \u00ebsht\u00eb mjaft e ngadalt\u00eb dhe e parashikueshme (n\u00ebse flasim p\u00ebr kompanit\u00eb e m\u00ebdha), \"do rahat-bahato\" etj. Jo m\u00eb pak se nj\u00eb her\u00eb n\u00eb vit, ndonj\u00eb furnizues i madh thot\u00eb se ka shpikur nj\u00eb sistem mega-super-puper, i cili tani automatikisht b\u00ebn gjith\u00e7ka dhe t\u00eb gjith\u00eb administrator\u00ebt dhe inxhinier\u00ebt e rrjetit mund t\u00eb shp\u00ebrndahen, duke l\u00ebn\u00eb disa p\u00ebr t\u00eb shtypur butonat n\u00eb nj\u00eb nd\u00ebrfaqe t\u00eb bukur. Realiteti \u00ebsht\u00eb se, edhe n\u00ebse abstrahohemi nga kostoja e zgjidhjes, inxhinier\u00ebt e rrjetit nuk do t\u00eb ngelen diku tjet\u00ebr. Po, ndoshta, n\u00eb vend t\u00eb konsol\u00ebs do t\u00eb ket\u00eb p\u00ebrs\u00ebri nj\u00eb nd\u00ebrfaqe uebesh (por nuk do t\u00eb jet\u00eb m\u00eb nj\u00eb pajisje e caktuar, por nj\u00eb sistem i madh, i cili menaxhon dhjetra dhe qindra t\u00eb till\u00eb), por njohurit\u00eb \"si \u00ebsht\u00eb gjith\u00e7ka brenda\" do t\u00eb jen\u00eb gjithsesi t\u00eb nevojshme.<\/p>\n

3. Kompanit\u00eb produktive<\/b>, fitimi i t\u00eb cilave vjen nga zhvillimi (dhe, shpesh, operimi) i ndonj\u00eb programi ose platforme \u2013 nga ai produkt. Zakonisht ato jan\u00eb t\u00eb vogla dhe t\u00eb shpejta, akoma larg shkall\u00ebs s\u00eb nd\u00ebrmarrjeve dhe burokracis\u00eb s\u00eb tyre. Pik\u00ebrisht k\u00ebtu jan\u00eb t\u00eb pranishme ato DevOps, kuber, docker dhe fjal\u00ebt e tjera t\u00eb frikshme, t\u00eb cilat patjet\u00ebr do t'i b\u00ebjn\u00eb rrjetet dhe inxhinier\u00ebt e rrjetit nj\u00eb relikt t\u00eb pad\u00ebshiruar. <\/p>\n

\u00c7far\u00eb e ndan inxhinierin e rrjetit nga administratori i sistemit?<\/h3>\n

\nN\u00eb kuptimin e njer\u00ebzve q\u00eb nuk jan\u00eb n\u00eb IT \u2014 asgj\u00eb. T\u00eb dyshuarit shikojn\u00eb n\u00eb nj\u00eb ekran t\u00eb zi dhe shkruajn\u00eb ndonj\u00eb zakone, ndonj\u00ebher\u00eb duke mallkuar n\u00eb heshtje. <\/p>\n

N\u00eb kuptimin e programuesve \u2014 ndoshta vet\u00ebm nj\u00eb fush\u00eb subjekti. Administruesit e sistemeve menaxhojn\u00eb server\u00ebt, specialist\u00ebt e rrjetit menaxhojn\u00eb switch-et dhe router-\u00ebt. Ndonj\u00ebher\u00eb administrimi nuk b\u00ebhet si\u00e7 duhet, dhe gjith\u00e7ka bie. Po n\u00eb rast se ka ndonj\u00eb gj\u00eb t\u00eb \u00e7uditshme, gjithashtu jan\u00eb fajtor\u00eb specialist\u00ebt e rrjetit. Thjesht sepse t\u00eb p\u00ebrkushtohem, k\u00ebt\u00eb \u00ebsht\u00eb pse.<\/p>\n

N\u00eb t\u00eb v\u00ebrtet\u00eb, dallimi kryesor \u00ebsht\u00eb qasja ndaj pun\u00ebs. Ndoshta, pik\u00ebrisht mes specialist\u00ebve t\u00eb rrjetit ndodhen m\u00eb shum\u00eb mb\u00ebshtet\u00ebs t\u00eb qasjes \"Funksionon \u2014 mos e prek!\". Zgjidhja e ndonj\u00eb problemi (brenda nj\u00eb ofruesi) zakonisht mund t\u00eb b\u00ebhet vet\u00ebm n\u00eb nj\u00eb m\u00ebnyr\u00eb, e gjith\u00eb konfigurimi i pajisjes \u2014 ja ku \u00ebsht\u00eb, n\u00eb duar. \u00c7mimi i gabimit \u00ebsht\u00eb i lart\u00eb, ndonj\u00ebher\u00eb edhe shum\u00eb i lart\u00eb (p.sh., do t\u00eb duhet t\u00eb udh\u00ebtosh p\u00ebr disa qindra kilometra p\u00ebr t\u00eb rib\u00ebr\u00eb router-in, nd\u00ebrsa n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb disa mij\u00ebra njer\u00ebz do t\u00eb rrin\u00eb pa lidhje \u2014 nj\u00eb situat\u00eb krejt normale p\u00ebr nj\u00eb operator komunikimesh).<\/p>\n

N\u00eb mendimin tim, pik\u00ebrisht p\u00ebr k\u00ebt\u00eb arsye inxhinier\u00ebt e rrjetit, nga nj\u00ebra an\u00eb, jan\u00eb jasht\u00ebzakonisht t\u00eb motivuar p\u00ebr stabilitetin e rrjetit (dhe ndryshimet jan\u00eb armiku kryesor i stabilitetit), dhe nga ana tjet\u00ebr, njohurit\u00eb e tyre shkojn\u00eb m\u00eb shum\u00eb thell\u00eb se sa gjer\u00eb (nuk \u00ebsht\u00eb e nevojshme t\u00eb dish si t\u00eb konfigurosh dhjet\u00ebra demon\u00eb t\u00eb ndrysh\u00ebm, \u00ebsht\u00eb e nevojshme t\u00eb njoh\u00ebsh teknologjit\u00eb dhe realizimin e tyre te nj\u00eb prodhues i caktuar pajisjeje). Kjo \u00ebsht\u00eb arsyeja pse nj\u00eb administrator sistemi, q\u00eb ka gjetur n\u00eb Google se si t\u00eb vendos\u00eb VLAN-in n\u00eb Cisco \u2014 nuk \u00ebsht\u00eb akoma nj\u00eb specialist rrjeti. Dhe v\u00ebshtir\u00eb se mund t\u00eb mb\u00ebshtes\u00eb (dhe gjithashtu t\u00eb zgjidh\u00eb problemet) nj\u00eb rrjet t\u00eb nd\u00ebrlikuar nga m\u00eb shum\u00eb se pak. <\/p>\n

Por p\u00ebrse \u00ebsht\u00eb e nevojshme nj\u00eb specialist rrjeti, n\u00ebse keni hosti<\/a>?<\/b><\/p>\n

P\u00ebr nj\u00eb pages\u00eb shtes\u00eb (dhe n\u00ebse jeni nj\u00eb klient shum\u00eb i madh dhe i dashur \u2014 ndoshta edhe falas, \"p\u00ebr miq\u00ebsi\") inxhinier\u00ebt e qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave do t\u00eb konfigurojn\u00eb switch-et tuaj sipas nevojave tuaja, dhe ndoshta edhe do t\u00eb ndihmojn\u00eb n\u00eb ngritjen e lidhjes BGP me ofruesit (n\u00ebse keni nj\u00eb subnet tuaj t\u00eb vetin adresa IP<\/a> p\u00ebr njoftimin).<\/p>\n

Problemi kryesor \u00ebsht\u00eb se qendrat e t\u00eb dh\u00ebnave nuk jan\u00eb departamenti juaj IT, por nj\u00eb kompani e ve\u00e7ant\u00eb, q\u00ebllimi i s\u00eb cil\u00ebs \u00ebsht\u00eb t\u00eb p\u00ebrfitoj\u00eb. Po ashtu, duke p\u00ebrfituar nga ju si klient. Qendra e t\u00eb dh\u00ebnave ofron rafte, siguron energji elektrike dhe aj\u00ebr t\u00eb fresk\u00ebt, si dhe ofron nj\u00eb lidhje \"default\" me internetin. N\u00eb baz\u00eb t\u00eb k\u00ebsaj infrastrukture, qendra e t\u00eb dh\u00ebnave mund t\u00eb vendos\u00eb pajisjet tuaja (colocation), t'ju jap\u00eb nj\u00eb server me qira (dedicated server), ose ofroj\u00eb sh\u00ebrbime t\u00eb menaxhuara (p.sh., OpenStack apo K8s). Por biznesi i qendr\u00ebs s\u00eb t\u00eb dh\u00ebnave (zakonisht) nuk \u00ebsht\u00eb administrimi i infrastruktur\u00ebs s\u00eb klient\u00ebve, pasi ky proces \u00ebsht\u00eb mjaft i lodhsh\u00ebm, keq automatizohet (dhe n\u00eb nj\u00eb qend\u00ebr t\u00eb mir\u00eb t\u00eb t\u00eb dh\u00ebnave, \u00e7do gj\u00eb q\u00eb \u00ebsht\u00eb e mundur \u00ebsht\u00eb automatizuar), dhe akoma m\u00eb keq unifikohet (\u00e7do klient \u00ebsht\u00eb i ve\u00e7ant\u00eb) dhe gjithashtu \u00ebsht\u00eb i rreziksh\u00ebm p\u00ebr pretendime (\"ju konfiguroni serverin tim dhe tani ka r\u00ebn\u00eb, ju jeni fajtor p\u00ebr gjith\u00e7ka!!!111\"). Prandaj, n\u00ebse ofruesi i strehimit do t'ju ndihmoj\u00eb ndonj\u00ebher\u00eb, do t\u00eb p\u00ebrpiqet ta b\u00ebj\u00eb k\u00ebt\u00eb sa m\u00eb t\u00eb thjesht\u00eb dhe \"t\u00eb drejtp\u00ebrdrejt\u00eb\". Sepse t\u00eb b\u00ebsh gj\u00ebra t\u00eb nd complicated - \u00ebsht\u00eb joefikase, t\u00eb pakt\u00ebn nga perspektiva e cost-it t\u00eb inxhinier\u00ebve t\u00eb atij ofruesi strehimi (por ndodhin situata t\u00eb ndryshme, shih udh\u00ebzuesin). Kjo nuk do t\u00eb thot\u00eb q\u00eb ofruesi i strehimit do t\u00eb b\u00ebj\u00eb gjithmon\u00eb keq. Por nuk \u00ebsht\u00eb aspak e sigurt se ai do t\u00eb b\u00ebj\u00eb at\u00eb q\u00eb ju nevojitej v\u00ebrtet.<\/p>\n

Duket e qart\u00eb, por ndonj\u00ebher\u00eb kam hasur n\u00eb praktik\u00ebn time q\u00eb kompanit\u00eb filluan t\u00eb mb\u00ebshteten te ofruesi i tyre i sh\u00ebrbimeve t\u00eb strehimit m\u00eb shum\u00eb se sa duhet, dhe kjo nuk \u00e7oi n\u00eb asgj\u00eb t\u00eb mir\u00eb. Duhej t\u00eb shpjegoja p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb dhe n\u00eb detaje se asnj\u00eb SLA nuk do t\u00eb mbuloj\u00eb humbjet nga ndalesat (ka p\u00ebrjashtime, por zakonisht \u00ebsht\u00eb shum\u00eb, SHUM\u00cb e shtrenjt\u00eb p\u00ebr klientin) dhe se ofruesi i strehimit nuk \u00ebsht\u00eb n\u00eb dijeni se \u00e7far\u00eb po ndodh n\u00eb infrastruktur\u00ebn e klient\u00ebve (p\u00ebrve\u00e7 t\u00eb dh\u00ebnave shum\u00eb t\u00eb p\u00ebrgjithshme). Dhe ofruesi i strehimit nuk b\u00ebn asnj\u00eb backup p\u00ebr ju. Edhe m\u00eb keq \u00ebsht\u00eb situata, n\u00ebse keni m\u00eb shum\u00eb se nj\u00eb ofrues strehimi. N\u00eb rast t\u00eb ndonj\u00eb problemi mes tyre, ata sigurisht q\u00eb nuk do t\u00eb zgjidhin p\u00ebr ju se \u00e7far\u00eb po ndodhte.<\/p>\n

Motivet jan\u00eb pik\u00ebrisht t\u00eb nj\u00ebjta si kur zgjidhni \"ekipin tuaj t\u00eb administrator\u00ebve vs outsourcing\". N\u00ebse rreziqet jan\u00eb vler\u00ebsuar, cil\u00ebsia \u00ebsht\u00eb e k\u00ebnaqshme, dhe biznesi nuk ka ndonj\u00eb problem \u2014 pse t\u00eb mos e provoni? Nga ana tjet\u00ebr, rrjeti \u00ebsht\u00eb nj\u00eb nga nivelet m\u00eb bazike t\u00eb infrastruktur\u00ebs, dhe nuk ka kuptim t\u00eb dor\u00ebzohet n\u00eb duar t\u00eb tjer\u00ebve, n\u00ebse gjith\u00e7ka tjet\u00ebr e mbani vet\u00eb.<\/p>\n

N\u00eb cilat raste nevojitet nj\u00eb inxhinier rrjeti?<\/b><\/p>\n

M\u00eb posht\u00eb do t\u00eb flasim p\u00ebrshtatsh\u00ebm p\u00ebr kompanit\u00eb moderne t\u00eb produkteve. Me operator\u00ebt dhe enterprise-n gjith\u00e7ka \u00ebsht\u00eb m\u00eb ose m\u00eb pak e qart\u00eb \u2014 atje nuk ka pasur shum\u00eb ndryshime n\u00eb vitet e fundit dhe inxhinier\u00ebt e rrjetit kan\u00eb qen\u00eb t\u00eb nevojsh\u00ebm m\u00eb par\u00eb, jan\u00eb t\u00eb nevojsh\u00ebm dhe tani. Por me ata t\u00eb quajtur \"t\u00eb rinjt\u00eb dhe guximtar\u00ebt\", situata nuk \u00ebsht\u00eb aq e qart\u00eb. Shpesh ata vendosin infrastruktur\u00ebn e tyre krejt\u00ebsisht n\u00eb \u043e\u0431\u043b\u0430\u043a\u0430, k\u00ebshtu q\u00eb madje as administrator\u00ebt zakonisht nuk u duhen \u2014 p\u00ebrve\u00e7 administrator\u00ebve t\u00eb k\u00ebtyre \u043e\u0431\u043b\u0430\u043a\u00ebve, sigurisht. Infrastruktura, nga nj\u00ebra an\u00eb, \u00ebsht\u00eb mjaft e thjesht\u00eb n\u00eb nd\u00ebrtimin e saj, dhe nga ana tjet\u00ebr \u2014 \u00ebsht\u00eb mir\u00eb t\u00eb automatizuar (ansible\/puppet, terraform, ci\/cd... e dini tashm\u00eb). Por edhe k\u00ebtu ka situata kur nuk mund t\u00eb kaloni pa nj\u00eb inxhinier rrjeti.<\/p>\n

Shembulli 1, klasik<\/b><\/p>\n

Supozoni se kompania fillon me nj\u00eb server me nj\u00eb IP publike, i cili ndodhet n\u00eb nj\u00eb data center. Pastaj numri i server\u00ebve b\u00ebhet dy. M\u00eb pas m\u00eb shum\u00eb... Her\u00ebt a von\u00eb, shfaqet nevoja p\u00ebr nj\u00eb rrjet privat midis server\u00ebve. Sepse trafiku \"jasht\u00eb\" \u00ebsht\u00eb i limituar si n\u00eb gjer\u00ebsi (n\u00eb maksimum 100Mbit\/s, p\u00ebr shembull) ashtu edhe n\u00eb volum t\u00eb shkarkuar\/transferuar n\u00eb muaj (\u00e7mime t\u00eb ndryshme nga t\u00eb ndryshmit hoster, por gjer\u00ebsia p\u00ebr n\u00eb bot\u00ebn jasht\u00eb, zakonisht \u00ebsht\u00eb shum\u00eb m\u00eb e shtrenjt\u00eb se nj\u00eb rrjet privat).<\/p>\n

Hosteri shton karta t\u00eb tjera rrjeti n\u00eb serverat e tij dhe i lidh ato n\u00eb switchet e tij n\u00eb nj\u00eb vlan t\u00eb ve\u00e7ant\u00eb. Midis server\u00ebve shfaqet nj\u00eb rrjet lokal \"i shesht\u00eb\". E p\u00ebrshtatshme!<\/p>\n

Numri i server\u00ebve po rritet, ashtu si edhe trafiku n\u00eb rrjetin privat \u2014 kopjet rezerv\u00eb, replikimet etj. Hosti ofron t\u00eb ju ndaj\u00eb n\u00eb switch-e t\u00eb ve\u00e7ant\u00eb, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb mos pengoni nj\u00ebri-tjetrin. Hosti instalon disa switch-e dhe i konfiguron n\u00eb nj\u00eb m\u00ebnyr\u00eb \u2014 shum\u00eb gjasa, duke l\u00ebn\u00eb nj\u00eb rrjet t\u00eb shesht\u00eb midis t\u00eb gjith\u00eb server\u00ebve tuaj. Gjith\u00e7ka funksionon mir\u00eb, por n\u00eb nj\u00eb moment fillojn\u00eb problemet: her\u00eb pas here ka rritje t\u00eb vonesave midis hosteve, n\u00eb log-et ka probleme p\u00ebr numrin e tep\u00ebrt t\u00eb paketave arp p\u00ebr sekond\u00eb, dhe p\u00ebntesti gjat\u00eb auditit ka goditur t\u00eb gjith\u00eb rrjetin tuaj lokal, duke thyer vet\u00ebm nj\u00eb server.<\/p>\n

\u00c7far\u00eb duhet b\u00ebr\u00eb?<\/i><\/p>\n

T\u00eb ndash rrjetin n\u00eb segmente \u2014 VLAN-e. T\u00eb konfigurosh adresimin n\u00eb \u00e7do VLAN, t\u00eb vendos\u00ebsh nj\u00eb gateway q\u00eb do t\u00eb kaloj\u00eb trafikun midis rrjeteve. N\u00eb gateway, t\u00eb konfigurosh ACL p\u00ebr t\u00eb kufizuar qasjen midis segmenteve, ose madje t\u00eb vendos\u00ebsh nj\u00eb firewall t\u00eb ve\u00e7ant\u00eb p\u00ebrkrah.<\/p>\n

Shembulli 1, vazhdim<\/b><\/p>\n

Server\u00ebt jan\u00eb t\u00eb lidhur me rrjetin lokal me nj\u00eb kabllo. Switch-et n\u00eb raft jan\u00eb t\u00eb lidhura nd\u00ebrlidh\u00ebse, por n\u00eb rast avarie n\u00eb nj\u00eb raft, edhe tri t\u00eb tjera fqinj\u00eb bien. Ekzistojn\u00eb skema, por ka dyshime mbi aktualitetin e tyre. \u00c7do server ka nj\u00eb adres\u00eb publike t\u00eb vet, e cila jepet nga hosti dhe \u00ebsht\u00eb e lidhur me raftin. K\u00ebshtu q\u00eb, duke l\u00ebvizur serverin, adresa duhet t\u00eb ndryshohet.<\/p>\n

\u00c7far\u00eb duhet b\u00ebr\u00eb?<\/i><\/p>\n

T\u00eb lidhni server\u00ebt me LAG (Grupi i Agregat\u00ebs s\u00eb Lidhjes) me dy kabllo n\u00eb switch-et n\u00eb raft (ato gjithashtu duhen rezerva). Lidhjet midis raftave duhen rezervuar, dhe t\u00eb rikonfigurohen n\u00eb \u2018yll\u2019 (ose moda e fundit CLOS), n\u00eb m\u00ebnyr\u00eb q\u00eb nj\u00eb humbje e nj\u00eb rafti t\u00eb mos ndikoj\u00eb n\u00eb t\u00eb tjer\u00ebt. T\u00eb caktohen rafteve \u2018qendrore\u2019, ku do t\u00eb vendoset thelbi rrjetor dhe ku do t\u00eb lidhen raftet e tjera. Nj\u00ebkoh\u00ebsisht, t\u00eb rregullohet adresimi publik, t\u00eb merret nga hosti (ose nga RIR, n\u00ebse ka mund\u00ebsi) nj\u00eb n\u00ebndeg\u00eb q\u00eb do t\u00eb shpallet n\u00eb bot\u00eb nga ju vet\u00eb (ose p\u00ebrmes hostit).<\/p>\n

A mund ta b\u00ebj\u00eb gjith\u00e7ka kjo nj\u00eb \u2018administrator i zakonsh\u00ebm\u2019 pa njohuri t\u00eb thella n\u00eb rrjeta? Nuk jam i sigurt. A do ta b\u00ebj\u00eb hosti? Ndoshta, por do t'ju k\u00ebrkohet nj\u00eb detaj i holl\u00ebsish\u00ebm q\u00eb gjithashtu duhen p\u00ebrgatitur. Pastaj do t\u00eb kontrolloni q\u00eb \u00e7do gj\u00eb \u00ebsht\u00eb b\u00ebr\u00eb si\u00e7 duhet.<\/p>\n

Shembulli 2. Objekti<\/b><\/p>\n

Supozoni se keni nj\u00eb VPC n\u00eb ndonj\u00eb cloud publik. P\u00ebr t\u00eb marr\u00eb qasje nga zyra ose pjesa on-prem e infrastruktur\u00ebs n\u00eb rrjetin lokal brenda VPC, duhet t\u00eb konfiguroni nj\u00eb lidhje p\u00ebrmes IPSec ose nj\u00eb kanali t\u00eb dedikuar. Nga nj\u00ebra an\u00eb, IPSec \u00ebsht\u00eb m\u00eb i lir\u00eb, pasi nuk keni nevoj\u00eb t\u00eb blini pajisje shtes\u00eb, mund t\u00eb konfiguroni nj\u00eb tunel midis serverit tuaj me adres\u00eb publike dhe cloud-it. Por, ka vonesa, performanc\u00eb t\u00eb kufizuar (pasi kanali k\u00ebrkon enkriptim), plus lidhje t\u00eb pap\u00ebrcaktuar (sepse qasja b\u00ebhet p\u00ebrmes internetit t\u00eb zakonsh\u00ebm). <\/p>\n

\u00c7far\u00eb duhet b\u00ebr\u00eb?<\/i><\/p>\n

T\u00eb ngrini lidhjen p\u00ebrmes nj\u00eb kanali t\u00eb dedikuar (p\u00ebr shembull, n\u00eb AWS kjo quhet Direct Connect). P\u00ebr k\u00ebt\u00eb, gjeni nj\u00eb operator-partner q\u00eb do t'ju lidh\u00eb, p\u00ebrcaktoni pik\u00ebn m\u00eb t\u00eb af\u00ebrt t\u00eb lidhjes me ju si te operatori, ashtu edhe te operatori n\u00eb cloud, dhe n\u00eb fund, konfiguroni gjith\u00e7ka. A mund ta b\u00ebni k\u00ebt\u00eb pa nj\u00eb inxhinier rrjeti? Sigurisht, po. Por si t\u00eb trajtoni problemet pa t\u00eb, nuk \u00ebsht\u00eb aq e qart\u00eb. <\/p>\n

Gjithashtu mund t\u00eb lindin probleme me disponueshm\u00ebrin\u00eb midis cloud-eve (n\u00ebse keni multi-cloud) ose probleme me vonesat midis rajoneve t\u00eb ndryshme dhe k\u00ebshtu me radh\u00eb. Sigurisht, tani jan\u00eb shfaqur shum\u00eb mjete q\u00eb rrisin transparenc\u00ebn e asaj q\u00eb ndodh n\u00eb cloud (si\u00e7 \u00ebsht\u00eb edhe Thousand Eyes), por k\u00ebto jan\u00eb mjete p\u00ebr inxhinier\u00ebt e rrjetit dhe jo z\u00ebvend\u00ebsimi i tyre.<\/p>\n

Mund t\u00eb sjell edhe nj\u00eb dhjet\u00eb k\u00ebsi shembujsh nga praktika ime, por mendoj se \u00ebsht\u00eb e qart\u00eb se n\u00eb nj\u00eb ekip, duke filluar nga nj\u00eb nivel i caktuar zhvillimi t\u00eb infrastruktur\u00ebs, duhet t\u00eb ket\u00eb nj\u00eb njeri (ose m\u00eb mir\u00eb m\u00eb shum\u00eb se nj\u00eb), q\u00eb di si funksionon rrjeti, q\u00eb mund t\u00eb konfiguronte pajisjet rrjet\u00ebsore dhe t\u00eb trajtonte problemet n\u00ebse ato shfaqen. Besoni, ai do t\u00eb ket\u00eb pun\u00eb p\u00ebr t\u00eb b\u00ebr\u00eb. <\/p>\n

\u00c7far\u00eb duhet t\u00eb dij\u00eb nj\u00eb inxhinier rrjeti?<\/b><\/p>\n

Aspak nuk \u00ebsht\u00eb e nevojshme (dhe madje ndonj\u00ebher\u00eb, d\u00ebmshme), q\u00eb nj\u00eb inxhinier rrjeti t\u00eb merret vet\u00ebm me rrjetin dhe asgj\u00eb tjet\u00ebr. Edhe n\u00ebse nuk e marrim parasysh opsionin e infrastruktur\u00ebs q\u00eb jeton gati t\u00ebr\u00ebsisht n\u00eb cloud publik (dhe ai, sado t\u00eb doni, po b\u00ebhet gjithnj\u00eb e m\u00eb popullor), dhe marrim, p\u00ebr shembull, on premise ose cloud privat, ku vet\u00ebm me \"dijen n\u00eb nivelin CCNP\" nuk do t\u00eb shkoni shume larg. <\/p>\n

P\u00ebrve\u00e7 rrjeteve, n\u00eb thelb \u2014 kjo \u00ebsht\u00eb nj\u00eb fush\u00eb e pafund p\u00ebr studim, madje n\u00ebse p\u00ebrqendrohemi vet\u00ebm n\u00eb nj\u00eb drejtim t\u00eb vet\u00ebm (rrjetet e ofruesve, nd\u00ebrmarrje, qendrat e t\u00eb dh\u00ebnave, Wi-Fi...)<\/p>\n

Sigurisht, shum\u00eb prej jush tani do t\u00eb kujtohen p\u00ebr Python dhe \u00e7do lloj \"automatizimi t\u00eb rrjetit\", por kjo \u00ebsht\u00eb vet\u00ebm nj\u00eb kusht i nevojsh\u00ebm, por jo i mjaftuesh\u00ebm. P\u00ebr t\u00eb qen\u00eb nj\u00eb inxhinier rrjeti q\u00eb \"integron n\u00eb ekip\" me sukses, ai duhet t\u00eb dij\u00eb t\u00eb flas\u00eb me nj\u00eb gjuh\u00eb t\u00eb p\u00ebrbashk\u00ebt me programuesit dhe koleg\u00ebt admin\u00eb\/devopsa. \u00c7far\u00eb do t\u00eb thot\u00eb kjo?<\/p>\n