{"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\/et\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"V\u00f5rgut\u00f6\u00f6tajad (ei) ole vajalikud","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

K\u00e4esoleva artikli kirjutamise ajal andis populaarne t\u00f6\u00f6h\u00f5ive veebileht otsing fraasi \"V\u00f5rgutehnika insener\" all umbes kolm sada t\u00f6\u00f6kohta kogu Venemaal. V\u00f5rdluseks: otsing fraasi \"s\u00fcsteemiadministraator\" all toob v\u00e4lja peaaegu 2.5 tuhat t\u00f6\u00f6kohta ja \"DevOps insener\" \u2013 peaaegu 800.<\/p>\n

Kas see t\u00e4hendab, et v\u00f5rguinseneride t\u00f6\u00f6j\u00f5ud on muutunud v\u00e4hem vajalikuks uute pilvede, dockerite, kubernetese ja k\u00f5ikjaloleva avaliku WiFi ajastul?
\nHakkame v\u00e4lja selgitama (c)<\/p>\n

\"V\u00f5rgut\u00f6\u00f6tajad
\n<\/a><\/noindex>
\nTere tulemast, mina olen Aleksei ja ma olen v\u00f5rguinsener. <\/p>\n

Olen viimase 10 aasta jooksul tegelenud v\u00f5rkudega ja t\u00f6\u00f6tanud rohkem kui 15 aastat erinevate *nix s\u00fcsteemidega (olen katsetanud nii Linuxit kui ka FreeBSD). Olen t\u00f6\u00f6tanud sideoperaatorites, suurtes ettev\u00f5tetes, mida tavaliselt peetakse \"ettev\u00f5tete\" kategooriaks, ning viimasel ajal t\u00f6\u00f6tan \"noores ja julges\" fintechis, kus pilved, devops'id, kubernetese ja muud hirmutavad s\u00f5nad, mis kindlasti muudavad mind ja mu kolleegid \u00fchel p\u00e4eval \u00fcleliigseks. V\u00f5ib-olla.<\/p>\n

Eemaldamine: \"Meie elus ei ole k\u00f5ik alati ja igal pool, vaid m\u00f5ni asi m\u00f5nikord ja teatud kohtades\" (c) Maksim Dorofeev.<\/p>\n

K\u00f5ike, mis allpool on kirjutatud, v\u00f5ib ja tuleb pidada autori isiklikuks arvamuseks, mis ei pretendeeri viimase instantsi t\u00f5ele ja isegi mitte p\u00f5hjalikule uurimist\u00f6\u00f6le. K\u00f5ik tegelased on v\u00e4ljam\u00f5eldud, k\u00f5ik kokkusattumised on juhuslikud.<\/p><\/blockquote>\n

Tere tulemast minu maailma.<\/p>\n

Kus saab v\u00f5rguinseneridega \u00fcldse kokku puutuda?<\/h3>\n

\n1. Sideoperaatorid, teenusepakkujad ja teised integreerijad<\/b>. Siin on k\u00f5ik lihtne: v\u00f5rgu ehitamine on nende jaoks \u00e4ri. Nad m\u00fc\u00fcvad kas otse \u00fchendust (operaatorid) v\u00f5i pakuvad teenuseid oma tellijate v\u00f5rkude k\u00e4ivitamiseks\/hooldamiseks. <\/p>\n

Siin on palju kogemusi, aga mitte eriti palju raha (kui te ei ole juht v\u00f5i edukas m\u00fc\u00fcgijuht). Sellegipoolest, kui teile meeldivad v\u00f5rgud ja olete alles oma teekonna alguses, siis karj\u00e4\u00e4r mingis mitte v\u00e4ga suuri operaatorit toetavas osakonnas oleks isegi praegu ideaalne koht alguseks (f\u00f6deraalses on k\u00f5ik v\u00e4ga skriptitud ja loominguliseks v\u00e4ljundiks on v\u00e4he ruumi). Ja lood selle kohta, et austusv\u00e4\u00e4rsest insenerist v\u00f5ib m\u00f5ne aastaga areneda C-taseme juhiks, on samuti t\u00e4iesti reaalsed, kuigi need on haruldased, arusaadavatel p\u00f5hjustel. T\u00f6\u00f6j\u00f5u vajadus on alati olemas, sest ringk\u00e4ive t\u00f5epoolest esineb. See on samaaegselt nii hea kui halb \u2013 alati on t\u00f6\u00f6kohti, kuid tihti lahkuvad k\u00f5ige aktiivsemad\/\u00e4gedamad \u00fcsna kiiresti kas ametik\u00f5rgenduseks v\u00f5i mujale, soojematesse kohtadesse.<\/p>\n

2. Tinglik \"ettev\u00f5te\"<\/b>. Oluline ei ole, kas ettev\u00f5tte peamine tegevus on seotud IT-ga v\u00f5i mitte. Peamine on, et seal on oma IT-osakond, mis tegeleb ettev\u00f5tte siseste s\u00fcsteemide toimimise tagamisega, sealhulgas kontorite v\u00f5rkude, filiaalide sidekanalite jne. Funktsioone nagu v\u00f5rgutehnik v\u00f5ib sellistes ettev\u00f5tetes t\u00e4ita \u201ek\u00f5rvaltegevusena\u201c s\u00fcsteemiadministraator (kui v\u00f5rgu infrastruktuur on v\u00e4ike v\u00f5i sellega tegeleb v\u00e4line allt\u00f6\u00f6v\u00f5tja), samas kui kui on olemas v\u00f5rgutehnik, v\u00f5ib ta samal ajal j\u00e4lgida ka telefonivooge ja SAN-i (noh, selline asi). Palgad on erinevad \u2014 see s\u00f5ltub palju ettev\u00f5tte kasumlikkusest, suurusest ja struktuurist. Olen t\u00f6\u00f6tanud nii ettev\u00f5tetes, kus Cisco seadmeid t\u00f5siselt \u201ekoormati\u201d, kui ka ettev\u00f5tetes, kus v\u00f5rk ehitati v\u00e4lja prahi, pulkade ja sinise isolatsiooniteibi abil, ning servereid ei uuendatud, \u00fctleme, kunagi (kas on vaja \u00f6elda, et mingisuguseid reserve ka ei olnud). Kogemusi on seal palju v\u00e4hem ja need on t\u00f5en\u00e4oliselt keskendunud tugevale vendor-lockile v\u00f5i \u201ekuidas teha midagi t\u00e4iesti t\u00fchjast\u201d. Isiklikult tundus see mulle v\u00e4ga igav, kuigi paljudele meeldib - k\u00f5ik on piisavalt rahulik ja etteennustatav (kui r\u00e4\u00e4gime suurtest ettev\u00f5tetest), \u201erahaga on kergelt ja nii edasi\u201d. Mitte harvemini kui kord aastas \u00fctleb m\u00f5ni suur tarnija, et on leidnud v\u00e4lja uue mega-super-sensatsiooni s\u00fcsteemi, mis n\u00fc\u00fcd automaatikaliselt k\u00f5ik automatiseerib ja k\u00f5iki s\u00fcsteemiadministraatoreid ja v\u00f5rgutehnikuid saab vallandada, j\u00e4ttes paar inimest kaunisse liidese nuppe vajutama. Reaalsus on aga see, et isegi kui rahalistest lahendustest k\u00f5rvale j\u00e4tta, ei kao v\u00f5rgutehnikud sinna kuhugi. Jah, v\u00f5ib-olla on veebi liides j\u00e4lle olemas (kuid mitte konkreetse riistvara, vaid suure s\u00fcsteemi, mis haldab k\u00fcmneid ja sadu selliseid seadmeid), kuid teadmised \u201ekuidas k\u00f5ik seestpoolt t\u00f6\u00f6tab\u201d on ikkagi vajalikud.<\/p>\n

3. Tooteettev\u00f5tted<\/b>, mille kasum tuleb mingisuguse tarkvara v\u00f5i platvormi arendamisest (ja sageli ka kasutamisest) \u2013 just sellest tootest. T\u00fc\u00fcpiliselt on need v\u00e4ikesed ja kiirete muudatustega, nendeni on veel kaugel ja ettev\u00f5tete b\u00fcrokraatiast. Just siin elavad massiliselt need arendajate, konteinerite ja muid hirmutavaid s\u00f5nu, mis kindlasti muudavad v\u00f5rgu ja v\u00f5rgutehnikud mittevajalikeks r\u00fcmpadeks. <\/p>\n

Kuidas erineb v\u00f5rgutehnik s\u00fcsteemiadministraatorist?<\/h3>\n

\nIn the understanding of people outside IT \u2014 nothing. Both look at a black screen and type some spells, sometimes muttering under their breath. <\/p>\n

Programmeerijate arusaam \u2014 see on pigem teemavaldkond. S\u00fcsteemiadministraatorid haldavad servereid, v\u00f5rguadministratoorid haldavad l\u00fcliteid ja marsruutereid. M\u00f5nikord haldavad nad halvasti, ja k\u00f5igil on probleemid. Noh, igasuguste kummaliste olukordade eest vastutavad ka v\u00f5rguadministratoorid. Just because fuck you, that's why.<\/p>\n

In reality, the main difference is the approach to work. Perhaps it's among network engineers that supporters of the \"If it works, don\u2019t touch it!\" approach are most frequently found. Typically, a certain task (within a single vendor) can usually only be done in one way, the entire configuration of the box \u2014 here it is, right in front of you. The cost of a mistake is high, and sometimes very high (for example, you might have to travel hundreds of kilometers to reboot a router, while several thousand people are left without connectivity \u2014 a completely common situation for a telecom operator).<\/p>\n

In my opinion, that\u2019s precisely why network engineers, on one hand, are extremely motivated for network stability (and changes are the main enemy of stability), and on the other hand, their knowledge goes deeper rather than broader (there\u2019s no need to configure dozens of different daemons; it's necessary to understand the technologies and their implementation by a specific equipment manufacturer). That\u2019s why a system administrator who Googles how to configure VLANs on Cisco is not yet a network engineer. And it\u2019s unlikely that he can support (and troubleshoot) a somewhat complex network effectively. <\/p>\n

But why do you need a network engineer if you have hostija<\/a>?<\/b><\/p>\n

For an additional fee (or if you are a very large and favored client \u2014 maybe even for free, \"out of friendship\"), the data center engineers will configure your switches according to your needs, and perhaps even help set up BGP peering with providers (if you have your own subnet of IP addresses<\/a> for announcement).<\/p>\n

Peamine probleem on see, et andmekeskus ei ole teie IT-osakond, vaid eraldi ettev\u00f5te, mille eesm\u00e4rk on teenida kasumit. Ka teie, kui kliendi arvelt. Andmekeskus pakub riiuleid, tagab nende elektriga varustamise ja jahutuse ning loob teatud \"vaikse\" \u00fchenduse internetiga. Selle infrastruktuuri p\u00f5hjal v\u00f5ib andmekeskus paigutada teie seadme (colocation), rentida teile serveri (dedicated server) v\u00f5i pakkuda haldusteenust (n\u00e4iteks OpenStack v\u00f5i K8s). Kuid andmekeskuse \u00e4riks ei ole (tavaliselt) klientide infrastruktuuri haldamine, kuna see protsess on \u00fcsna t\u00f6\u00f6mahukas, halvasti automatiseeritav (ja normaalses andmekeskuses on automatiseeritud k\u00f5ik, mis v\u00f5imalik) ning veel hullem, et sellele on raske \u00fchtlustada (iga klient on ainulaadne) ja see v\u00f5ib olla kannatuste allikas (\u201ete seadistate mulle serveri, aga n\u00fc\u00fcd see langes, see on teie s\u00fc\u00fc!!!111\"). Seet\u00f5ttu, kui hostija aitab teid mingil moel, siis p\u00fc\u00fcab ta seda teha v\u00f5imalikult lihtsalt ja \"konditsioneeritud\". Sest keeruline tegemine \u2014 ei ole kasulik, v\u00e4hemalt selle hostija inseneride t\u00f6\u00f6j\u00f5u kulude seisukohast (aga olukorrad v\u00f5ivad varieeruda, vt vabastus). See ei t\u00e4henda, et hostija teeb kindlasti k\u00f5ik halvasti. Kuid pole sugugi kindel, et ta teeb just seda, mida te tegelikult vajate.<\/p>\n

N\u00e4iliselt on see asi piisavalt ilmne, aga olen oma praktikas korduvalt kokku puutunud sellega, et ettev\u00f5tted hakkasid toetuma oma hosting-teenuse pakkujatele veidi rohkem, kui oli vajalik, ja see ei ole viinud millegi heani. Oli vaja kaua ja p\u00f5hjalikult selgitada, et \u00fckski SLA ei kata kahjusid seiskamisest (on erandeid, kuid tavaliselt on see kliendile v\u00e4ga, V\u00c4GA kallis) ja et hostija ei tea \u00fcldse, mis toimub kohalike infrastruktuuride juures (v\u00e4lja arvatud v\u00e4ga \u00fcldised n\u00e4itajad). Ja hostija ei tee teie eest ka varukoopiaid. Veel hullem on asi, kui teil on rohkem kui \u00fcks hostija. Kui tekivad mingi probleem, siis nad kindlasti ei hakka teie eest selgitama, mis l\u00e4ks valesti.<\/p>\n

Tegelikult on motiivid siin t\u00e4pselt samasugused nagu valides \"oma adminnide tiim vs allhange\". Kui riskid on hinnatud, kvaliteet rahuldav ja \u00e4ri ei ole vastu, miks mitte proovida. Teisest k\u00fcljest on v\u00f5rk \u00fcks k\u00f5ige p\u00f5hilisemaid infrastruktuuri kihte ja harva tasub see usaldada k\u00fclalistele, kui k\u00f5ik muu on ise hooldatud.<\/p>\n

Millal on vajalik v\u00f5rgut\u00f6\u00f6taja?<\/b><\/p>\n

Edasi r\u00e4\u00e4gime just kaasaegsetest tooteettev\u00f5tetest. Operaatorite ja ettev\u00f5tete osas on k\u00f5ik enam-v\u00e4hem selge \u2013 seal ei ole viimastel aastatel palju muutunud ja v\u00f5rgut\u00f6\u00f6tajad on seal olnud vajalikud juba varem, nad on vajalikud ka n\u00fc\u00fcd. Kuid nende \"noorte ja julgete\" puhul ei ole see nii \u00fcheselt m\u00f5istetav. Tihti paigutavad nad oma infrastruktuuri t\u00e4ielikult pilve, nii et isegi administraatorid pole neile eriti vajalikud \u2013 v\u00e4lja arvatud nende pilvede administraatorid, muidugi. Infrastruktuur on \u00fchel poolt \u00fcsna lihtne oma \u00fclesehituses, teisalt aga h\u00e4sti automatiseeritud (ansible\/puppet, terraform, ci\/cd... noh, te teate). Kuid isegi siin on olukordi, kus ilma v\u00f5rgutehnikuta ei saa l\u00e4bi.<\/p>\n

N\u00e4ide 1, klassikaline<\/b><\/p>\n

Oletame, et ettev\u00f5te alustab \u00fche serveriga avaliku IP-aadressiga, mis asub andmekeskuses. Siis serverite arv suureneb kahele. Siis veel rohkem... Varsti tekib vajadus serverite vahelisteks privaatseteks v\u00f5rkudeks. Sest \"v\u00e4lised\" andmeliiklus on piiratud nii ribalaiuse (noh, n\u00e4iteks mitte rohkem kui 100 Mbit\/s) kui ka igakuiste allalaadimiste ja edastamiste mahuga (erinevate hostide korral erinevad hinnapakettid, kuid v\u00e4lismaailmale suunatud ribalaius on tavaliselt oluliselt kallim kui privaatne v\u00f5rk).<\/p>\n

Hostija paigaldab serveritele t\u00e4iendavad v\u00f5rgukaardid ja \u00fchendab need oma l\u00fclititega eraldi vlan-is. Serverite vahel tekib \"lihtne\" kohalik v\u00f5rk. Mugav!<\/p>\n

Serverite arv kasvab, nagu ka liiklus privaatv\u00f5rgus - varukoopiad, replikatsioonid jne. Host pakub v\u00f5imalust viia teid eraldi l\u00fclititesse, et te ei segaks teisi kliente ja nemad ei segaks teid. Host paigaldab mingid l\u00fclitid ja seab need paika - t\u00f5en\u00e4oliselt j\u00e4ttes k\u00f5ikide teie serverite vahel \u00fche tasase v\u00f5rgu. K\u00f5ik t\u00f6\u00f6tab h\u00e4sti, kuid teatud hetkel tekivad probleemid: aeg-ajalt kasvavad viivitused hostide vahel, logides tekib probleem liiga suurte arp-pakettide arvu t\u00f5ttu sekundis, ja pen-testija auditi k\u00e4igus omandas kogu teie lokaalse v\u00f5rgu, katkestades vaid \u00fche serveri.<\/p>\n

Mida peaks tegema?<\/i><\/p>\n

Jagada v\u00f5rku segmentideks \u2014 VLAN'id. Igas VLAN'is seadistada oma adressatsioon, m\u00e4\u00e4rata v\u00e4rav, mis suunab liiklust erinevate v\u00f5rkude vahel. V\u00e4ravas seadistada ACL juurdep\u00e4\u00e4su piiramiseks segmentide vahel v\u00f5i paigaldada lihtsalt k\u00f5rvale eraldi tulem\u00fc\u00fcr.<\/p>\n

N\u00e4ide 1, j\u00e4tkub<\/b><\/p>\n

Serverid on kohalikku v\u00f5rku \u00fchendatud \u00fche kaabli abil. L\u00fclitid riiulites on omavahel millegip\u00e4rast \u00fchendatud, kuid avarii korral \u00fches riiulis kukub veel kolm k\u00fclgnevat v\u00e4lja. Skeeme on olemas, kuid nende kehtivuses on kahtlusi. Igal serveril on oma avalik aadress, mille v\u00e4ljastab host ja mis on seotud riiuliga. See t\u00e4hendab, et kui serverit liigutada, tuleb aadressi muuta.<\/p>\n

Mida peaks tegema?<\/i><\/p>\n

\u00dchendage serverid LAG (Link Aggregation Group) abil kahe kaabliga l\u00fclititesse riiulis (neid tuleb samuti varundada). \u00dchendused riiulite vahel varundada, \u00fcmber teha \u201et\u00e4rniga\u201c (v\u00f5i moes oleva CLOS), et \u00fche riiuli v\u00e4ljalangemine ei m\u00f5jutaks teisi. Eraldage \u201ekeskset\u201c riiulit, kus asub v\u00f5rgu s\u00fcda, ja kuhu \u00fchendatakse teised riiulid. Samuti viige avalik adresseerimine korda, v\u00f5tke hostilt (v\u00f5i RIR-ilt, kui v\u00f5imalik) alamv\u00f5rk, mida iseseisvalt (v\u00f5i hosti kaudu) maailmale v\u00e4lja kuulutada.<\/p>\n

Kas k\u00f5ike seda saab teha \u201etavaline\u201c s\u00fcsteemiadministraator, kellel pole s\u00fcgavaid teadmisi v\u00f5rkudest? Ei ole kindel. Kas host teeb seda? V\u00f5ib-olla, kuid teilt n\u00f5utakse \u00fcsna detailset tehnilist dokumentatsiooni, mille peate samuti kellelegi koostama, ja seej\u00e4rel kontrollima, et k\u00f5ik oleks \u00f5igesti tehtud.<\/p>\n

N\u00e4ide 2. Pilv<\/b><\/p>\n

Oletame, et teil on VPC m\u00f5nes avalikus pilves. Kui soovite p\u00e4\u00e4seda kontorist v\u00f5i kohalikust infrastruktuuri osast teie VPC-s asuvasse kohaliku v\u00f5rku, peate seadistama \u00fchenduse IPSeci v\u00f5i erakanali kaudu. \u00dchelt poolt \u2014 IPSec on odavam, kuna ei pea ostma lisas\u00fcsteeme, saate seadistada tunneli oma avaliku aadressiga serveri ja pilve vahel. Kuid \u2014 latentsus, piiratud j\u00f5udlus (sest kanalit peab kr\u00fcpteerima) ning lisaks ei ole garantii \u00fchenduvuse osas (sest juurdep\u00e4\u00e4s toimub tavalisest internetist). <\/p>\n

Mida peaks tegema?<\/i><\/p>\n

Seadistage \u00fchendus erakanali kaudu (n\u00e4iteks AWS-is nimetatakse seda Direct Connectiks). Selleks leidke partneroperaator, kes teid \u00fchendab, m\u00e4\u00e4rake l\u00e4him sissetuleku punkti (nii teie kui ka operaatori jaoks pilves) ning l\u00f5puks seadistage k\u00f5ik. Kas on v\u00f5imalik seda k\u00f5ik \u00e4ra teha ilma v\u00f5rgutehnika insenerita? Kindlasti on. Kuidas seda seej\u00e4rel probleemide korral lahendada \u2014 see on juba v\u00e4hem selge. <\/p>\n

Samuti v\u00f5ivad tekkida probleeme k\u00e4ttesaadavusega erinevate pilvede vahel (kui teil on mitme pilve lahendus) v\u00f5i probleemid latentsusega erinevate piirkondade vahel jne. Ilmselgelt on n\u00fc\u00fcd olemas palju t\u00f6\u00f6riistu, mis suurendavad l\u00e4bipaistvust selle suhtes, mis pilves toimub (n\u00e4iteks Thousand Eyes), kuid need on k\u00f5ik v\u00f5rguinseneri t\u00f6\u00f6riistad, mitte tema asendused.<\/p>\n

Ma v\u00f5iks tuua veel tosin sarnast n\u00e4idet oma praktikast, kuid ma arvan, et selge on, et meeskonnas peaks alates teatud taseme saavutamisest olema inimene (veel parem, rohkem kui \u00fcks), kes teab, kuidas v\u00f5rk t\u00f6\u00f6tab, suudab seadistada v\u00f5rguvarustust ja lahendada probleeme, kui need tekivad. Usuge mind, tal on piisavalt tegevust. <\/p>\n

Mida peaks v\u00f5rgutehnika insener teadma?<\/b><\/p>\n

Kaugelki ei ole kindlasti vajalik (ja m\u00f5nikord isegi kahjulik), et v\u00f5rgutehnika insener tegeleks ainult v\u00f5rgu ja mitte millegagi muuga. Isegi kui mitte arvestada variantidega, kus infrastruktuur elab peaaegu t\u00e4ielikult avalikus pilves (ja see, olgu kuidas on, muutub \u00fcha populaarsemaks), ja v\u00f5tta n\u00e4iteks kohapealsed v\u00f5i privaatsed pilved, kus pelgalt \u00abCCNP taseme teadmisest\u00bb ei piisa. <\/p>\n

Lisaks v\u00f5rkkonstruktsioonidele \u2014 kuigi see on lihtsalt \u00e4\u00e4retu \u00f5ppevaldkond, isegi kui keskenduda ainult \u00fchele suunale (teenusepakkujate v\u00f5rgud, ettev\u00f5tted, andmekeskused, Wi-Fi...)<\/p>\n

Muidugi, paljud teist meenutavad praegu Pythonit ja muud \"v\u00f5rguhalduse automatiseerimist\", kuid see on vaid vajalik, kuid mitte piisav tingimus. Et v\u00f5rguhalduse insener \"edukalt meeskonda sobituda\", peab ta oskama r\u00e4\u00e4kida nii arendajate kui ka kolleegide administraatoritega\/devopsidega \u00fches keeles. Mida see t\u00e4hendab?<\/p>\n