Halló allir, ég heiti Sergey Emelyanchik. Ég er yfirmaður Audit-Telecom fyrirtækisins, aðalframleiðandi og höfundur Veliam kerfisins. Ég ákvað að skrifa grein um hvernig ég og vinur minn stofnuðum útvistunarfyrirtæki, skrifuðum hugbúnað fyrir okkur sjálf og fórum í kjölfarið að dreifa honum til allra í gegnum SaaS kerfið. Um það hvernig ég trúði því ekki að þetta væri hægt. Greinin mun innihalda ekki aðeins sögu, heldur einnig tæknilegar upplýsingar um hvernig Veliam varan var búin til. Þar á meðal nokkur stykki af frumkóða. Ég skal segja þér hvaða mistök við gerðum og hvernig við leiðréttum þau síðar. Efasemdir voru uppi um að birta ætti slíka grein. En ég hélt að það væri betra að gera það, fá viðbrögð og bæta, en að birta ekki greinina og hugsa um hvað hefði gerst ef...
Forsaga
Ég vann í einu fyrirtæki sem IT starfsmaður. Fyrirtækið var nokkuð stórt með víðtæka netuppbyggingu. Ég ætla ekki að fjölyrða um starfsskyldur mínar, ég ætla aðeins að segja að þær fólu örugglega ekki í sér þróun á neinu.
Við höfðum eftirlit, en eingöngu vegna fræðilegs áhuga langaði mig að reyna að skrifa mitt eigið einfaldasta. Hugmyndin var þessi: Ég vildi að það væri á vefnum, svo að ég gæti auðveldlega farið inn án þess að setja upp neina viðskiptavini og séð hvað var að gerast með netið úr hvaða tæki sem er, þar á meðal farsíma í gegnum Wi-Fi, og ég líka virkilega langaði til að skilja fljótt hvað Það er búnaður í herberginu sem er orðinn „mopey“ vegna þess að... voru mjög strangar kröfur um viðbragðstíma við slíkum vandamálum. Fyrir vikið fæddist það plan í hausnum á mér að skrifa einfalda vefsíðu þar sem jpeg bakgrunnur var með netskýringarmynd, klippa út tækin sjálf með IP tölunum á þessari mynd og sýna kraftmikið efni ofan á mynd á tilskildum hnitum í formi græns eða blikkandi rauðs IP tölu. Verkefnið hefur verið sett, við skulum byrja.
Áður var ég að forrita í Delphi, PHP, JS og mjög yfirborðslega C++. Ég veit alveg hvernig netkerfi virka. VLAN, leið (OSPF, EIGRP, BGP), NAT. Þetta var nóg fyrir mig til að skrifa frumstæða vöktunarfrumgerð sjálfur.
Ég skrifaði það sem ég ætlaði í PHP. Apache og PHP þjónninn var á Windows vegna þess að... Linux fyrir mér á því augnabliki var eitthvað óskiljanlegt og mjög flókið, eins og síðar kom í ljós, mér skjátlaðist mjög og víða er Linux miklu einfaldara en Windows, en þetta er sérstakt umræðuefni og við vitum öll hversu margir holivarar eru á þetta umræðuefni. Windows verkefnaáætlunin dró með litlu millibili (ég man ekki nákvæmlega, en eitthvað eins og einu sinni á þriggja sekúndna fresti) PHP forskrift sem spurði alla hluti með banal ping og vistaði ástandið í skrá.
system(“ping -n 3 -w 100 {$ip_address}“);
Já, já, að vinna með gagnagrunn á því augnabliki var heldur ekki töfrandi fyrir mig. Ég vissi ekki að það væri hægt að samhliða ferlum og að fara í gegnum alla nethnúta tók langan tíma, vegna þess að... þetta gerðist á einum þræði. Vandamál komu sérstaklega upp þegar nokkrir hnútar voru ekki tiltækir, vegna þess að hver þeirra seinkaði handritinu um 300 ms. Á biðlarahlið var einföld lykkjuaðgerð sem, með nokkurra sekúndna millibili, sótti uppfærðar upplýsingar frá þjóninum með Ajax beiðni og uppfærði viðmótið. Jæja, þá, eftir 3 misheppnuð ping í röð, ef vefsíða með vöktun var opin í tölvunni, lék glaðvær tónsmíð.
Þegar allt gekk upp var ég mjög innblásin af niðurstöðunni og hélt að ég gæti bætt meira við hana (vegna þekkingar minnar og getu). En mér líkaði alltaf ekki við kerfi með milljón töflur, sem ég hélt þá, og held enn þann dag í dag, séu óþörf í flestum tilfellum. Ég vildi setja þar aðeins inn það sem myndi raunverulega hjálpa mér í starfi mínu. Þessi meginregla er enn grundvallaratriði í þróun Veliam til þessa dags. Ennfremur áttaði ég mig á því að það væri mjög flott ef ég þyrfti ekki að halda vöktun opinni og vita um vandamál, og þegar það gerðist, opnaðu síðan síðuna og sjáðu hvar þessi vandamála nethnútur er staðsettur og hvað á að gera við hann næst . Einhvern veginn las ég ekki tölvupóst þá, ég einfaldlega notaði hann ekki. Ég rakst á það á netinu að það eru SMS gáttir sem þú getur sent GET eða POST beiðni á og þeir senda SMS í farsímann minn með textanum sem ég skrifa. Ég áttaði mig strax á því að mig langaði í þetta. Og ég byrjaði að kynna mér skjölin. Eftir nokkurn tíma tókst mér það og nú fékk ég SMS um vandamál á netinu í farsímanum mínum með nafni „fallins hluts“. Þrátt fyrir að kerfið væri frumstætt var það skrifað af mér sjálfum og það mikilvægasta sem hvatti mig til að þróa það var að þetta var forrit sem hjálpaði mér virkilega í starfi.
Og svo rann upp dagurinn þegar ein af netrásunum fór niður í vinnunni og eftirlitið mitt lét mig ekki vita af því. Þar sem Google DNS pingaði enn fullkomlega. Það er kominn tími til að huga að því hvernig hægt er að fylgjast með því að samskiptarásin sé lifandi. Það voru mismunandi hugmyndir um hvernig ætti að gera þetta. Ég hafði ekki aðgang að öllum búnaði. Við þurftum að finna út hvernig við áttum að skilja hvaða af rásunum er í beinni, en án þess að geta einhvern veginn séð það á netbúnaðinum sjálfum. Þá kom samstarfsmaður með þá hugmynd að hugsanlegt væri að leiðarrakning til opinberra netþjóna gæti verið mismunandi eftir því hvaða samskiptarás er notuð til að komast á netið. Ég athugaði og það reyndist þannig. Það voru mismunandi leiðir þegar leitað var.
system(“tracert -d -w 500 8.8.8.8”);
Svo birtist annað handrit, eða réttara sagt, af einhverjum ástæðum var ummerki bætt við enda sama handrits, sem pingaði öll tæki á netinu. Enda er þetta enn eitt langt ferli sem var framkvæmt í sama þræði og hægði á vinnunni við allt handritið. En þá var það ekki svo augljóst. En á einn eða annan hátt vann hann vinnuna sína, kóðinn skilgreindi nákvæmlega hvers konar rekja ætti að vera fyrir hverja rásina. Svona byrjaði kerfið að virka, sem þegar fylgdist með (hátt sagt, vegna þess að það var ekkert safn af neinum mæligildum, heldur bara ping) nettækjum (beini, rofar, Wi-Fi o.s.frv.) og samskiptaleiðum við umheiminn . SMS-skilaboð bárust reglulega og skýringarmyndin sýndi alltaf vel hvar vandamálið var.
Ennfremur, í daglegu starfi þurfti ég að fara yfir kross. Og ég varð þreytt á að fara í Cisco rofa í hvert skipti til að sjá hvaða viðmót ég ætti að nota. Hversu flott það væri að smella á hlut í vöktun og sjá lista yfir viðmót hans með lýsingum. Það myndi spara mér tíma. Þar að auki, í þessu kerfi væri engin þörf á að keyra Putty eða SecureCRT til að slá inn reikninga og skipanir. Ég smellti bara á eftirlitið, sá hvað þurfti og fór að vinna vinnuna mína. Ég fór að leita leiða til að hafa samskipti við rofa. Ég rakst strax á 2 valkosti: SNMP eða að skrá mig inn á rofann í gegnum SSH, slá inn skipanirnar sem ég þurfti og flokka niðurstöðuna. Ég vísaði SNMP frá vegna þess hversu flókin framkvæmd þess er; ég var óþolinmóður að fá niðurstöðuna. með SNMP, þú þyrftir að grafa í MIB í langan tíma og, byggt á þessum gögnum, búa til gögn um tengi. Það er frábært lið hjá CISCO
show interface statusÞað sýnir nákvæmlega hvað ég þarf fyrir krossaferðir. Af hverju að nenna SNMP þegar ég vil bara sjá úttak þessarar skipunar, hugsaði ég. Eftir nokkurn tíma áttaði ég mig á þessu tækifæri. Smellt er á hlut á vefsíðu. Atburður kom af stað þar sem AJAX viðskiptavinurinn hafði samband við netþjóninn og hann tengdist síðan í gegnum SSH við rofann sem ég þurfti (skilríkin voru harðkóðun inn í kóðann, það var engin löngun til að betrumbæta hann, til að búa til sérstakar valmyndir þar sem það væri hægt að skipta um reikninga úr viðmótinu , ég þurfti niðurstöðuna og það fljótt) Ég setti ofangreinda skipun þar inn og sendi hana aftur í vafrann. Svo ég fór að sjá upplýsingar um viðmót með einum músarsmelli. Þetta var einstaklega þægilegt, sérstaklega þegar þú þurftir að skoða þessar upplýsingar á mismunandi rofum í einu.
Vöktun á rekjarásum var á endanum ekki besta hugmyndin, vegna þess að... stundum var unnið á netinu og rakningin gat breyst og eftirlitið fór að öskra á mig að það væru vandamál með rásina. En eftir að hafa eytt miklum tíma í greiningu áttaði ég mig á því að allar rásir virkuðu og eftirlit mitt var að blekkja mig. Þar af leiðandi bað ég samstarfsmenn mína sem stjórnuðu rásamyndandi rofum að senda mér einfaldlega kerfisskrá þegar sýnileikastaða nágranna breyttist. Samkvæmt því var það miklu einfaldara, hraðvirkara og nákvæmara en að rekja. Atburður eins og nágranni týndur er kominn og ég sendi strax tilkynningu um rásina niður.
Ennfremur birtust nokkrar skipanir í viðbót þegar smellt var á hlut og SNMP var bætt við til að safna nokkrum mælingum, og það er í rauninni það. Kerfið þróaðist aldrei frekar. Það gerði allt sem ég þurfti, þetta var gott tæki. Margir lesendur munu líklega segja mér að það sé nú þegar mikið af hugbúnaði á netinu til að leysa þessi vandamál. En í rauninni googlaði ég ekki slíkar ókeypis vörur þá og mig langaði virkilega að þróa forritunarhæfileika mína, og hvaða betri leið til að ýta undir þetta en alvöru forritunarvandamál. Á þessum tímapunkti var fyrstu útgáfu vöktunar lokið og var henni ekki lengur breytt.
Stofnun fyrirtækisins Audit-Telecom
Eftir því sem tíminn leið fór ég að vinna hlutastarf í öðrum fyrirtækjum, sem betur fer leyfði vinnuáætlunin mér þetta. Þegar þú vinnur í mismunandi fyrirtækjum vex færni þín á ýmsum sviðum mjög hratt og sjóndeildarhringur þinn þróast vel. Það eru fyrirtæki þar sem þú ert Svíi, klippimaður og trompetleikari, eins og sagt er. Annars vegar er það erfitt, hins vegar ef þú ert ekki latur þá verður þú alhæfingur og það gerir þér kleift að leysa vandamál hraðar og skilvirkari vegna þess að þú veist hvernig viðkomandi svið virkar.
Vinur minn Pavel (einnig upplýsingatæknifræðingur) reyndi stöðugt að hvetja mig til að stofna eigið fyrirtæki. Það voru óteljandi hugmyndir með mismunandi afbrigðum af því sem þær voru að gera. Þetta hefur verið rætt í mörg ár. Og á endanum hefði það ekki átt að verða að neinu því ég er efasemdamaður og Pavel er draumóramaður. Í hvert skipti sem hann lagði fram hugmynd trúði ég henni ekki og neitaði að taka þátt. En við vildum virkilega opna okkar eigið fyrirtæki.
Loksins gátum við fundið valkost sem hentaði okkur báðum og gerðum það sem við kunnum að gera. Árið 2016 ákváðum við að stofna upplýsingatæknifyrirtæki sem myndi hjálpa fyrirtækjum að leysa upplýsingatæknivandamál. Þetta er uppsetning upplýsingatæknikerfa (1C, flugstöðvarþjónn, póstþjónn o.s.frv.), viðhald þeirra, klassískt HelpDesk fyrir notendur og netstjórnun.
Í hreinskilni sagt, þegar ég stofnaði fyrirtækið, trúði ég ekki á það um 99,9%. En einhvern veginn tókst Pavel að fá mig til að reyna og þegar ég horfði fram á veginn reyndist hann hafa rétt fyrir sér. Ég og Pavel spjölluðum inn 300 rúblur hvor, skráðum nýtt LLC „Audit-Telecom“, leigðum pínulitla skrifstofu, gerðum flott nafnspjöld, ja, almennt, eins og líklega flestir óreyndir, nýir kaupsýslumenn, og byrjuðum að leita að viðskiptavinum. Að finna viðskiptavini er allt önnur saga. Kannski munum við skrifa sérstaka grein sem hluta af fyrirtækjablogginu ef einhver hefur áhuga. Kald símtöl, flugblöð o.fl. Þetta gaf engar niðurstöður. Eins og ég les núna úr mörgum sögum um viðskipti, á einn eða annan hátt, veltur mikið á heppni. Við vorum heppin. og bókstaflega nokkrum vikum eftir stofnun fyrirtækisins leitaði Vladimir bróðir minn til okkar, sem færði okkur fyrsta viðskiptavininn. Ég mun ekki leiða þig með smáatriðin í því að vinna með viðskiptavinum, það er ekki það sem greinin fjallar um, ég segi bara að við fórum í úttekt, greindum mikilvæg svæði og þessi svæði biluðu á meðan ákvörðun var tekin um hvort vera í stöðugu samstarfi við okkur sem útvistaraðilar. Eftir þetta var strax tekin jákvæð ákvörðun.
Síðan, aðallega í gegnum munnlega í gegnum vini, fóru önnur þjónustufyrirtæki að birtast. Þjónustuverið var í einu kerfi. Tengingar við netbúnað og netþjóna eru mismunandi, eða öllu heldur ólíkar. Sumir vistuðu flýtileiðir, aðrir notuðu RDP heimilisfangabækur. Eftirlit er annað sérstakt kerfi. Það er mjög óþægilegt fyrir teymi að vinna í ólíkum kerfum. Mikilvægar upplýsingar glatast sjónar á. Jæja, til dæmis varð útstöðvarþjónn viðskiptavinarins ekki tiltækur. Umsóknir frá notendum þessa viðskiptavinar berast strax. Stuðningssérfræðingurinn opnar beiðni (hún barst í síma). Ef atvik og beiðnir væru skráðar í eitt kerfi myndi stuðningssérfræðingurinn strax sjá hvert vandamál notandans er og segja honum frá því, um leið og hann tengdist tilskildum hlut til að vinna úr aðstæðum. Allir eru meðvitaðir um taktíska ástandið og vinna samfellt. Við höfum ekki fundið kerfi þar sem allt þetta er sameinað. Það varð ljóst að það var kominn tími til að búa til okkar eigin vöru.
Áframhaldandi vinna við eftirlitskerfið þitt
Ljóst var að kerfið sem skrifað var áðan hentaði með öllu óhæft í núverandi verkefni. Hvorki hvað varðar virkni né hvað varðar gæði. Og ákveðið var að skrifa kerfið frá grunni. Myndrænt hefði það átt að líta allt öðruvísi út. Það varð að vera stigveldiskerfi svo hægt væri að opna réttan hlut á fljótlegan og þægilegan hátt fyrir réttan viðskiptavin. Kerfið eins og í fyrstu útgáfu var alls ekki réttlætanlegt í núverandi tilviki, vegna þess að Viðskiptavinir eru ólíkir og það skipti engu máli í hvaða húsnæði búnaðurinn var staðsettur. Þetta hefur þegar verið flutt í skjölin.
Svo, verkefnin:
- Stigveldisskipan;
- Einhvers konar miðlarahluti sem hægt er að setja á athafnasvæði viðskiptavinarins í formi sýndarvélar til að safna þeim mælingum sem við þurfum og senda á miðlæga netþjóninn, sem mun draga allt þetta saman og sýna okkur það;
- Viðvaranir. Þeir sem ekki má missa af því... á þessum tíma var ekki hægt að einhver sat og horfði bara á skjáinn;
- Umsóknarkerfi. Viðskiptavinir fóru að birtast sem við þjónuðum ekki aðeins netþjónum og netbúnaði heldur einnig vinnustöðvum;
- Geta til að tengjast fljótt við netþjóna og búnað úr kerfinu;
Verkefnin hafa verið sett, við byrjum að skrifa. Í leiðinni, afgreiðsla beiðna frá viðskiptavinum. Á þeim tíma vorum við þegar 4. Við byrjuðum að skrifa báða hlutana í einu: miðþjóninn og netþjóninn til uppsetningar fyrir viðskiptavini. Á þessum tímapunkti var Linux ekki lengur ókunnugt okkur og það var ákveðið að sýndarvélarnar sem viðskiptavinir myndu hafa væru á Debian. Það verða engin uppsetningarforrit, við gerum bara hlutaverkefni miðlara á einni tiltekinni sýndarvél og síðan klónum við það bara í viðkomandi viðskiptavin. Þetta voru önnur mistök. Síðar varð ljóst að í slíku kerfi var uppfærslukerfið algjörlega óþróað. Þeir. við vorum að bæta við einhverjum nýjum eiginleikum og svo var allt vandamálið við að dreifa honum á alla netþjóna viðskiptavina, en við munum koma aftur að þessu síðar, allt í röð og reglu.
Við gerðum fyrstu frumgerðina. Hann gat pingað netkerfi viðskiptavinarins og netþjóna sem við þurftum og sent þessi gögn á miðlæga netþjóninn okkar. Og hann, aftur á móti, uppfærði þessi gögn í lausu á miðlæga þjóninum. Hér mun ég skrifa ekki aðeins sögu um hvernig og hvað tókst, heldur einnig hvaða áhugamanna mistök voru gerð og hvernig ég þurfti síðar að borga fyrir það með tímanum. Þannig að allt tré hlutanna var geymt í einni skrá í formi raðaðs hlutar. Á meðan við tengdum nokkra viðskiptavini við kerfið var allt meira og minna eðlilegt, þó stundum hafi verið einhverjir gripir sem voru algjörlega óskiljanlegir. En þegar við tengdum tugi netþjóna við kerfið fóru kraftaverk að gerast. Stundum, af einhverjum óþekktum ástæðum, hurfu allir hlutir í kerfinu einfaldlega. Hér er mikilvægt að hafa í huga að netþjónarnir sem viðskiptavinirnir höfðu sent gögn til miðlæga netþjónsins á nokkurra sekúndna fresti með POST beiðni. Athyglisverð lesandi og reyndur forritari giskuðu þegar á að vandamál væri með margfaldan aðgang að skránni þar sem raðhlutinn var geymdur úr mismunandi þráðum á sama tíma. Og einmitt þegar þetta var að gerast gerðust kraftaverk þegar hlutir hurfu. Skráin varð einfaldlega tóm. En allt þetta uppgötvaðist ekki strax, heldur aðeins í rekstri með nokkrum netþjónum. Á þessum tíma var gáttaskönnunarvirkni bætt við (þjónarnir sendu miðstöðvar ekki aðeins upplýsingar um framboð tækja heldur einnig um gáttirnar sem eru opnar á þeim). Þetta var gert með því að kalla skipunina:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
niðurstöðurnar voru oft rangar og langan tíma tók að klára skannanir. Ég gleymdi alveg pinginu, það var gert í gegnum fping:
system("fping -r 3 -t 100 {$this->ip}");
Þetta var heldur ekki samhliða og því var ferlið mjög langt. Síðar var allur listi yfir IP tölur sem þarf til staðfestingar sendur til fping í einu og til baka fengum við tilbúinn lista yfir þá sem svöruðu. Ólíkt okkur gat fping samhliða ferlum.
Annað algengt venjubundið starf var að setja upp einhverja þjónustu í gegnum WEB. Jæja, til dæmis, ECP frá MS Exchange. Í grundvallaratriðum er þetta bara hlekkur. Og við ákváðum að við þyrftum að geta bætt slíkum tenglum beint inn í kerfið, til að þurfa ekki að leita í skjölunum eða einhvers staðar annars staðar í bókamerkjum hvernig á að nálgast ECP tiltekins viðskiptavinar. Svona virtist hugmyndin um auðlindatengla fyrir kerfið, virkni þeirra er tiltæk enn þann dag í dag og hefur ekki breyst, ja, næstum því.
Hvernig auðlindatenglar virka í Veliam
Fjartengingar
Svona lítur það út í aðgerð í núverandi útgáfu af Veliam
Eitt af verkefnunum var að tengjast á fljótlegan og þægilegan hátt við netþjóna, sem þegar voru margir (meira en eitt hundrað) og að flokka í gegnum milljónir fyrirfram vistaðra RDP flýtileiða var afar óþægilegt. Það vantaði tæki. Það er hugbúnaður á netinu sem er eitthvað eins og heimilisfangaskrá fyrir slíkar RDP tengingar, en þær eru ekki samþættar eftirlitskerfinu og ekki er hægt að vista reikninga. Að slá inn reikninga fyrir mismunandi viðskiptavini í hvert skipti er hreint helvíti þegar þú tengist tugum sinnum á dag við mismunandi netþjóna. Með SSH eru hlutirnir aðeins betri, það er mikið af góðum hugbúnaði sem gerir þér kleift að skipuleggja slíkar tengingar í möppur og muna reikningana frá þeim. En það eru 2 vandamál. Hið fyrsta er að við fundum ekki eitt forrit fyrir RDP og SSH tengingar. Annað er að ef ég á einhverjum tímapunkti er ekki við tölvuna mína og þarf að tengjast hratt, eða ég setti kerfið upp aftur, þá þarf ég að fara inn í skjölin til að skoða reikninginn frá þessum viðskiptavini. Það er óþægilegt og tímasóun.
Stigveldisskipanin sem við þurftum fyrir netþjóna viðskiptavina var þegar fáanleg í innri vörunni okkar. Ég þurfti bara að finna út hvernig ég ætti að tengja hraðtengingar við nauðsynlegan búnað þar. Til að byrja með, að minnsta kosti innan netkerfisins þíns.
Með hliðsjón af þeirri staðreynd að viðskiptavinurinn í kerfinu okkar var vafri sem hefur ekki aðgang að staðbundnum auðlindum tölvunnar, til þess að einfaldlega ræsa forritið sem við þurftum með einhverri skipun, var hann fundinn upp til að gera allt í gegnum „Windows sérsniðið slóð kerfi“. Svona birtist ákveðið „viðbót“ fyrir kerfið okkar, sem einfaldlega innihélt Putty og Remote Desktop Plus og, meðan á uppsetningu stóð, skráði einfaldlega URI kerfið í Windows. Nú, þegar við vildum tengjast hlut í gegnum RDP eða SSH, smelltum við á þessa aðgerð á kerfinu okkar og sérsniðin URI virkaði. Hið staðlaða mstsc.exe sem er innbyggt í Windows eða kítti, sem var hluti af „viðbótinni“, var hleypt af stokkunum. Ég set orðið viðbót innan gæsalappa því þetta er ekki vafraviðbót í klassískum skilningi.
Það var allavega eitthvað. Þægileg heimilisfangabók. Þar að auki, í tilfelli Putty, var allt almennt í lagi; það gæti verið gefið IP tengingar, innskráningu og lykilorð sem innsláttarfæribreytur. Þeir. Við höfum þegar tengst Linux netþjónum á netinu okkar með einum smelli án þess að slá inn lykilorð. En með RDP er þetta ekki svo einfalt. Staðlað mstsc getur ekki gefið upp skilríki sem færibreytur. Remote Desktop Plus kom til bjargar. Hann leyfði þessu að gerast. Nú getum við verið án þess, en lengi vel var það dyggur aðstoðarmaður í kerfinu okkar. Með HTTP(S) síðum er allt einfalt, slíkir hlutir einfaldlega opnaðir í vafranum og það er allt. Þægilegt og hagnýtt. En þetta var hamingja aðeins á innra netinu.
Þar sem við leystum langflest vandamálin lítillega frá skrifstofunni var auðveldast að gera VPN aðgengileg fyrir viðskiptavini. Og svo var hægt að tengjast þeim úr kerfinu okkar. En það var samt nokkuð óþægilegt. Fyrir hvern viðskiptavin var nauðsynlegt að halda fullt af VPN-tengingum sem minnst var á á hverri tölvu og áður en hægt var að tengjast einhverjum var nauðsynlegt að virkja samsvarandi VPN. Við notuðum þessa lausn í nokkuð langan tíma. En viðskiptavinum fjölgar, VPN-kerfum fjölgar líka og allt þetta byrjaði að þrengjast og eitthvað varð að gera í þessu. Tárin komu sérstaklega í augun á mér eftir að hafa sett kerfið upp aftur, þegar ég þurfti að slá inn tugi VPN-tenginga aftur í nýtt Windows prófíl. Hættu að þola þetta, sagði ég og fór að hugsa um hvað ég gæti gert í þessu.
Svo fór að allir viðskiptavinir voru með tæki frá hinu þekkta fyrirtæki Mikrotik sem beina. Þeir eru mjög hagnýtir og þægilegir til að framkvæma nánast hvaða verkefni sem er. Gallinn er sá að þeim er „rænt“. Við leystum þetta vandamál einfaldlega með því að loka öllum aðgangi að utan. En það var nauðsynlegt að einhvern veginn hafa aðgang að þeim án þess að koma til viðskiptavinarins, því ... það er langt. Við gerðum einfaldlega göng fyrir hvern slíkan Mikrotik og aðskildum þau í sérstaka laug. án nokkurrar leiðar, þannig að það er engin tenging netkerfisins þíns við net viðskiptavina og net þeirra við hvert annað.
Hugmyndin var fædd til að ganga úr skugga um að þegar ég smelli á hlutinn sem ég þarf í kerfinu, þá tengist miðlægi eftirlitsþjónninn, sem þekkir SSH reikninga allra viðskiptavina Mikrotik, við þann sem óskað er eftir, býr til áframsendingarreglu til viðkomandi hýsils með nauðsynleg höfn. Það eru nokkrir punktar hér. Lausnin er ekki algild - hún mun aðeins virka fyrir Mikrotik, þar sem setningafræði skipana er mismunandi fyrir alla beina. Einnig þurfti að eyða slíkum áframsendingum á einhvern hátt og miðlarahluti kerfisins okkar gat í rauninni ekki fylgst með því á nokkurn hátt hvort ég hefði lokið RDP lotunni minni. Jæja, slík framsending er gat fyrir viðskiptavininn. En við sóttumst ekki eftir algildi, vegna þess að... varan var eingöngu notuð innan fyrirtækisins okkar og það var ekki hugsað um að gefa hana út til almennings.
Hvert vandamálið var leyst á sinn hátt. Þegar reglan var búin til var þessi framsending aðeins tiltæk fyrir eina tiltekna ytri IP tölu (þar sem tengingin var frumstillt). Þannig var komið í veg fyrir öryggisgat. En við hverja slíka tengingu var Mikrotik reglu bætt við NAT síðuna og var ekki hreinsað. Og allir vita að því fleiri reglur sem eru, því meira hlaðast örgjörvi leiðarinnar. Og almennt gat ég ekki sætt mig við að einn daginn myndi ég fara í eitthvað Mikrotik, og það yrðu hundruð dauðra, gagnslausra reglna.
Þar sem þjónninn okkar getur ekki fylgst með tengingarstöðu, láttu Mikrotik rekja þá sjálft. Og ég skrifaði smáforrit sem fylgdist stöðugt með öllum framsendingarreglum með ákveðinni lýsingu og athugaði hvort TCP tengingin hefði viðeigandi reglu. Ef það hefur ekki verið einn í nokkurn tíma, þá hefur tengingunni líklega þegar verið lokið og hægt er að eyða þessari framsendingu. Allt gekk upp, handritið virkaði vel.
Við the vegur, hér er það:
global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={
local dstport [/ip firewall nat get value-name="dst-port" $i]
local dstaddress [/ip firewall nat get value-name="dst-address" $i]
local dstaddrport "$dstaddress:$dstport"
#log warning message=$dstaddrport
local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
if ($thereIsCon = "") do={
set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
#:log warning message=($atmonrulecounter->$dstport)
if (($atmonrulecounter->$dstport) > 5) do={
#log warning message="Removing nat rules added automaticaly by atmon_script"
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
set ($atmonrulecounter->$dstport) 0
}
} else {
set ($atmonrulecounter->$dstport) 0
}
}
Vissulega hefði mátt gera hana fallegri, hraðvirkari o.s.frv., en hún virkaði, hlóð ekki Mikrotik og stóð sig frábærlega. Við gátum loksins tengst netþjónum viðskiptavina og netbúnaði með einum smelli. Án þess að opna VPN eða slá inn lykilorð. Kerfið er orðið mjög þægilegt að vinna með. Þjónustutími var styttur og við eyddum öllum tíma í að vinna frekar en að tengjast nauðsynlegum hlutum.
Mikrotik öryggisafrit
Við stilltum öryggisafrit af öllu Mikrotik yfir á FTP. Og í heildina var allt í lagi. En þegar þú þurftir að fá öryggisafrit þurftirðu að opna þennan FTP og leita að honum þar. Við erum með kerfi þar sem allir beinir eru tengdir; við getum átt samskipti við tæki í gegnum SSH. Af hverju gerum við það ekki þannig að kerfið sjálft tekur afrit af öllum Mikrotik daglega, hugsaði ég. Og hann byrjaði að framkvæma það. Við tengdumst, tókum öryggisafrit og fórum með það í geymslu.
Forskriftarkóði í PHP til að taka öryggisafrit frá Mikrotik:
<?php
$IP = '0.0.0.0';
$LOGIN = 'admin';
$PASSWORD = '';
$BACKUP_NAME = 'test';
$connection = ssh2_connect($IP, 22);
if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;
ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
stream_get_contents($connection);
ssh2_exec($connection, '/export file="atmon.rsc"');
stream_get_contents($connection);
sleep(40); // Waiting bakup makes
$sftp = ssh2_sftp($connection);
// Download backup file
$size = filesize("ssh2.sftp://$sftp/atmon.backup");
$stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
@fclose($stream);
sleep(3);
// Download RSC file
$size = filesize("ssh2.sftp://$sftp/atmon.rsc");
$stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
@fclose($stream);
ssh2_exec($connection, '/file remove atmon.backup');
ssh2_exec($connection, '/file remove atmon.rsc');
?>
Afritið er tekið í tvennu formi - tvöfaldur og textastilling. Tvöfaldurinn hjálpar til við að endurheimta á fljótlegan hátt nauðsynlegar stillingar og textinn einn gerir þér kleift að skilja hvað þarf að gera ef það er þvinguð skipti á búnaði og ekki er hægt að hlaða tvöfaldanum upp á það. Fyrir vikið fengum við aðra þægilega virkni í kerfinu. Þar að auki, þegar nýjum Mikrotik var bætt við, var engin þörf á að stilla neitt; ég bætti einfaldlega hlutnum við kerfið og setti reikning fyrir það í gegnum SSH. Þá sá kerfið sjálft um að taka afrit. Núverandi útgáfa af SaaS Veliam er ekki enn með þessa virkni, en við munum flytja hana fljótlega.
Skjáskot af því hvernig það leit út í innra kerfinu
Umskipti í venjulega gagnagrunnsgeymslu
Ég skrifaði þegar hér að ofan að gripir birtust. Stundum hvarf allur listi yfir hluti í kerfinu einfaldlega, stundum þegar hlutur var breytt voru upplýsingarnar ekki vistaðar og endurnefna þurfti hlutinn þrisvar sinnum. Þetta pirraði alla hræðilega. Hlutir hvarf sjaldan og var auðvelt að endurheimta með því að endurheimta þessa skrá, en bilanir við að breyta hlutum áttu sér stað nokkuð oft. Sennilega gerði ég þetta upphaflega ekki í gegnum gagnagrunninn vegna þess að það passaði ekki í mínum huga hvernig hægt var að halda tré með öllum tengingum í flatri töflu. Það er flatt, en tréð er stigskipt. En góð lausn fyrir margfaldan aðgang, og í kjölfarið (eftir því sem kerfið verður flóknara) viðskipta, er DBMS. Ég er líklega ekki sá fyrsti sem lendi í þessu vandamáli. Ég byrjaði að googla. Það kom í ljós að allt hafði þegar verið fundið upp á undan mér og það eru nokkrir reiknirit sem byggja tré úr flötu borði. Eftir að hafa skoðað hvern og einn útfærði ég eina þeirra. En þetta var nú þegar ný útgáfa af kerfinu, því... Reyndar, vegna þessa, þurfti ég að endurskrifa töluvert mikið. Niðurstaðan var eðlileg, vandamálin með tilviljunarkennda hegðun kerfisins fóru í burtu. Sumir gætu sagt að villurnar séu mjög áhugamannalegar (einþráðar forskriftir, geymsla upplýsinga sem var aðgengist mörgum sinnum samtímis úr mismunandi þráðum í skrá o.s.frv.) á sviði hugbúnaðarþróunar. Kannski er þetta satt, en aðalstarfið mitt var stjórnun og forritun var aukaverk fyrir sálina mína, og ég hafði einfaldlega ekki reynslu af því að vinna í teymi forritara, þar sem svona grunnatriði hefði strax verið stungið upp á mér af eldri mínum. félagar. Þess vegna fyllti ég allar þessar hnökrar á eigin spýtur, en ég lærði efnið mjög vel. Og starf mitt felur einnig í sér fundi með viðskiptavinum, aðgerðum sem miða að því að koma fyrirtækinu á framfæri, fullt af stjórnunarmálum innan fyrirtækisins og margt, margt fleira. En með einum eða öðrum hætti var eftirspurn eftir því sem fyrir var. Sjálfir notuðum við strákarnir vöruna í daglegu starfi. Það voru satt að segja misheppnaðar hugmyndir og lausnir sem tímanum var sóað í, en á endanum kom í ljós að þetta var ekki vinnutæki og enginn notaði það og það endaði ekki í Veliam.
Hjálparþjónusta - Hjálparþjónusta
Það væri ekki rangt að nefna hvernig HelpDesk var stofnað. Þetta er allt önnur saga, því... í Veliam er þetta nú þegar þriðja algjörlega nýja útgáfan, sem er frábrugðin öllum fyrri. Nú er það einfalt kerfi, leiðandi án óþarfa bjöllur og flautur, með getu til að samþætta við lén, sem og getu til að fá aðgang að sama notandasniði hvar sem er með hlekk úr tölvupósti. Og síðast en ekki síst, það er hægt að tengjast umsækjanda í gegnum VNC hvar sem er (heima eða á skrifstofunni) beint úr forritinu án VPN eða framsendingar hafna. Ég skal segja þér hvernig við komum að þessu, hvað gerðist áður og hvaða hræðilegu ákvarðanir voru teknar.
Við tengdumst notendum í gegnum hið þekkta TeamViewer. Allar tölvur sem við þjónum notendum eru með sjónvarp uppsett. Það fyrsta sem við gerðum rangt og fjarlægðum það í kjölfarið var að tengja hvern HD viðskiptavin við vélbúnað. Hvernig skráði notandinn sig inn á HD kerfið til að skilja eftir beiðni? Auk sjónvarpsins voru allir með sérstakt tól uppsett á tölvunum sínum, skrifað í Lazarus (margir hérna munu reka upp stór augu og kannski fara að gúgla hvað það er, en besta samsetta tungumálið sem ég vissi var Delphi, og Lazarus er næstum því það sama, aðeins ókeypis). Almennt sett setti notandinn sérstaka lotuskrá af stað sem ræsti þetta tól, sem aftur las HWID kerfisins og eftir það var vafrinn ræstur og heimild átti sér stað. Hvers vegna var þetta gert? Í sumum fyrirtækjum er fjöldi þjónustunotenda talinn fyrir sig og er þjónustuverð hvers mánaðar miðað við fjölda fólks. Þetta er skiljanlegt, segir þú, en hvers vegna er þetta bundið við vélbúnað? Það er mjög einfalt, sumir einstaklingar komu heim og báðu beiðni úr fartölvu heima í stíl við „gerðu allt fallegt fyrir mig hér“. Auk þess að lesa kerfið HWID, dró tólið núverandi Teamviewer auðkenni úr skránni og sendi það einnig til okkar. Teamviewer er með API fyrir samþættingu. Og við gerðum þessa samþættingu. En það var einn afli. Í gegnum þessi API er ómögulegt að tengjast tölvu notandans þegar hann hefur ekki beinlínis upphaf þessa lotu og eftir að hafa reynt að tengjast henni verður hann einnig að smella á „staðfesta“. Á þeim tíma þótti okkur rökrétt að enginn ætti að tengjast án beiðni notandans og þar sem viðkomandi er við tölvuna mun hann hefja lotuna og svara beiðninni um fjartengingu játandi. Allt reyndist vitlaust. Umsækjendur gleymdu að ýta á initiate the session og urðu að segja þeim þetta í símtali. Þetta sóaði tíma og var pirrandi á báðum hliðum ferlisins. Þar að auki er alls ekki óalgengt fyrir slík augnablik þegar einstaklingur skilur eftir beiðni, en er aðeins heimilt að tengjast þegar hann fer í hádegismat. Vegna þess að vandamálið er ekki krítískt og hann vill ekki að vinnuferli hans verði truflað. Í samræmi við það mun hann ekki ýta á neina hnappa til að leyfa tengingu. Svona birtist viðbótarvirkni þegar þú skráðir þig inn í HelpDesk - lestur Teamviewer auðkenni. Við vissum varanlega lykilorðið sem var notað þegar Teamviewer var sett upp. Nánar tiltekið, aðeins kerfið vissi það, þar sem það var innbyggt í uppsetningarforritið og inn í kerfið okkar. Í samræmi við það var tengihnappur frá forritinu með því að smella á sem ekki þurfti að bíða eftir neinu, en Teamviewer opnaði strax og tenging varð. Þar af leiðandi voru tvenns konar mögulegar tengingar. Í gegnum opinbera Teamviewer API og okkar sjálfsmíðaða. Mér til undrunar hættu þeir að nota þann fyrsta nánast samstundis, þó að fyrirmæli hafi verið um að nota hann aðeins í sérstökum tilfellum og þegar notandinn sjálfur gefur leyfi. Gefðu mér samt öryggi núna. En í ljós kom að kærendur þurftu ekki á þessu að halda. Þeir eru allir alveg í lagi með að vera tengdir þeim án staðfestingarhnapps.
Skiptir yfir í multithreading í Linux
Spurningin um að flýta fyrir yfirferð netskanni fyrir opnun fyrirfram ákveðins lista yfir höfn og einfaldan ping á nethlutum er löngu farin að vakna. Hér er auðvitað fyrsta lausnin sem kemur upp í hugann fjölþráður. Þar sem aðaltíminn sem fer í ping er að bíða eftir að pakkanum sé skilað og næsta ping getur ekki byrjað fyrr en fyrri pakkanum er skilað, í fyrirtækjum sem voru jafnvel með 20+ netþjóna auk netbúnaðar, þá virkaði þetta nú þegar frekar hægt. Málið er að einn pakki gæti horfið, en ekki láta kerfisstjóra vita strax um það. Hann mun einfaldlega hætta að samþykkja svona ruslpóst mjög fljótt. Þetta þýðir að þú þarft að pinga hvern hlut oftar en einu sinni áður en þú kemst að niðurstöðu um óaðgengi. Án þess að fara út í of mikil smáatriði er nauðsynlegt að samhliða því vegna þess að ef það er ekki gert, þá mun kerfisstjórinn líklegast læra um vandamálið frá viðskiptavininum, en ekki frá eftirlitskerfinu.
PHP sjálft styður ekki multithreading út úr kassanum. Hægt að fjölvinnslu, þú getur gaffla. En í raun var ég nú þegar búinn að skrifa skoðanakönnun og ég vildi gera það þannig að ég myndi einu sinni telja alla hnúta sem ég þurfti úr gagnagrunninum, pinga allt í einu, bíða eftir svari frá hverjum og aðeins eftir það skrifa strax gögnin. Þetta sparar fjölda lestrarbeiðna. Multithreading passaði fullkomlega inn í þessa hugmynd. Fyrir PHP er PThreads eining sem gerir þér kleift að gera alvöru multithreading, þó það hafi þurft talsverða flækju til að setja þetta upp á PHP 7.2, en það var gert. Gáttarskönnun og ping eru nú hröð. Og í stað þess að vera til dæmis 15 sekúndur á hring fyrr, byrjaði þetta ferli að taka 2 sekúndur. Það var góður árangur.
Fljótleg úttekt á nýjum fyrirtækjum
Hvernig varð virknin til að safna ýmsum mæligildum og vélbúnaðareiginleikum til? Það er einfalt. Stundum er okkur einfaldlega skipað að endurskoða núverandi upplýsingatækniinnviði. Jæja, það sama er nauðsynlegt til að flýta endurskoðun nýs viðskiptavinar. Okkur vantaði eitthvað sem myndi gera okkur kleift að koma til meðalstórs eða stórs fyrirtækis og komast fljótt að því hvað þeir hafa. Að mínu mati er ping á innra neti aðeins lokað af þeim sem vilja flækja eigið líf og okkar reynsla er að þeir eru fáir. En það er líka til slíkt fólk. Í samræmi við það geturðu fljótt skannað netkerfi fyrir tilvist tækja með einföldum ping. Síðan getum við bætt þeim við og leitað að opnum höfnum sem vekja áhuga okkar. Reyndar var þessi virkni þegar til; það var aðeins nauðsynlegt að bæta skipun frá miðlæga þjóninum við þrælinn svo hann myndi skanna tilgreind netkerfi og bæta öllu sem hann fann á listann. Ég gleymdi að nefna, það var gert ráð fyrir að við værum nú þegar með tilbúna mynd með stilltu kerfi (þrælvöktunarþjónn) sem við gætum einfaldlega rúllað út frá viðskiptavininum meðan á endurskoðun stendur og tengt það við skýið okkar.
En niðurstaða endurskoðunar inniheldur venjulega fullt af mismunandi upplýsingum og ein þeirra er hvers konar tæki eru á netinu. Í fyrsta lagi höfðum við áhuga á Windows netþjónum og Windows vinnustöðvum sem hluta af léni. Þar sem í meðalstórum og stórum fyrirtækjum er skortur á léni líklega undantekning frá reglunni. Til að tala eitt tungumál er meðaltalið að mínu mati 100+ manns. Nauðsynlegt var að finna leið til að safna gögnum frá öllum Windows vélum og netþjónum, vitað um IP og lénsstjórareikning þeirra, en án þess að setja upp hugbúnað á hverja þeirra. WMI viðmótið kemur til bjargar. Windows Management Instrumentation (WMI) þýðir bókstaflega Windows stjórnunarverkfæri. WMI er ein af grunntækni fyrir miðstýrða stjórnun og eftirlit með rekstri ýmissa hluta tölvuinnviða sem keyra Windows vettvang. Tekið af wiki. Næst þurfti ég að fikta aftur til að setja saman wmic (þetta er WMI viðskiptavinur) fyrir Debian. Eftir að allt var tilbúið var allt sem var eftir að skoða nauðsynlega hnúta í gegnum wmic til að fá nauðsynlegar upplýsingar. Í gegnum WMI er hægt að fá nánast allar upplýsingar úr Windows tölvu og þar að auki er líka hægt að stjórna tölvunni í gegnum hana, til dæmis senda hana í endurræsingu. Svona virtist söfnun upplýsinga um Windows stöðvar og netþjóna í kerfinu okkar. Í viðbót við þetta voru núverandi upplýsingar um núverandi kerfisálagsvísa. Við óskum eftir þeim oftar og upplýsingar um vélbúnað sjaldnar. Eftir þetta varð endurskoðun aðeins skemmtilegri.
Ákvörðun um dreifingu hugbúnaðar
Við sjálf notum kerfið daglega og það er alltaf opið fyrir hvern tæknimann. Og við héldum að við gætum deilt með öðrum því sem við höfum nú þegar. Kerfið var ekki enn tilbúið til dreifingar. Margt þurfti að endurvinna svo staðbundin útgáfa myndi breytast í SaaS. Má þar nefna breytingar á ýmsum tæknilegum þáttum kerfisins (fjartengingar, stuðningsþjónusta), greiningu á einingum fyrir leyfisveitingar, sundrun gagnagrunna viðskiptavina, stærðarstærð hverrar þjónustu og þróun sjálfvirkrar uppfærslukerfa fyrir alla hluta. En þetta verður seinni hluti greinarinnar.
Uppfæra
Heimild: www.habr.com