Hallo elkenien, myn namme is Sergey Emelyanchik. Ik bin it haad fan it Audit-Telecom-bedriuw, de haadûntwikkelder en skriuwer fan it Veliam-systeem. Ik besleat in artikel te skriuwen oer hoe't myn freon en ik in outsourcingbedriuw makken, software foar ússels skreaunen en dêrnei begon te fersprieden oan elkenien fia it SaaS-systeem. Oer hoe't ik kategoarysk net leaude dat dit mooglik wie. It artikel sil net allinich in ferhaal befetsje, mar ek technyske details oer hoe't it Veliam-produkt is makke. Ynklusyf guon stikken boarnekoade. Ik sil jo fertelle hokker flaters wy makken en hoe't wy se letter korrizjearre hawwe. Der wiene twifels oer it publisearjen fan sa'n artikel. Mar ik tocht dat it better wie om it te dwaan, feedback te krijen en te ferbetterjen, dan it artikel net te publisearjen en nei te tinken oer wat der bard wêze soe as ...
prehistoarje
Ik wurke yn ien bedriuw as IT-meiwurker. It bedriuw wie frij grut mei in wiidweidige netwurkstruktuer. Ik sil net dwaen oer myn taakferantwurdlikheden, ik sil allinich sizze dat se perfoarst de ûntwikkeling fan neat omfette.
Wy hienen tafersjoch, mar suver út akademyske belangstelling woe ik besykje myn eigen simpelste te skriuwen. It idee wie dit: ik woe dat it op it web soe wêze, sadat ik maklik yngean koe sûnder kliïnten te ynstallearjen en sjen wat der bart mei it netwurk fan elk apparaat, ynklusyf in mobyl apparaat fia Wi-Fi, en ik ek echt woe gau begripe wat D'r is apparatuer yn 'e keamer dy't "mopey" wurden is omdat ... der wiene tige strange easken foar reaksjetiid op sokke problemen. As resultaat waard in plan berne yn myn holle om in ienfâldige webside te skriuwen wêrop in jpeg-eftergrûn wie mei in netwurkdiagram, de apparaten sels mei har IP-adressen op dizze foto út te snijen, en dynamyske ynhâld boppe op 'e sjen litte. foto yn 'e fereaske koördinaten yn' e foarm fan in grien of blinkend read IP-adres. De taak is ynsteld, lit ús begjinne.
Earder programmearre ik yn Delphi, PHP, JS en heul oerflakkich C ++. Ik wit hiel goed hoe't netwurken wurkje. VLAN, Routing (OSPF, EIGRP, BGP), NAT. Dit wie genôch foar my om sels in primitive tafersjochprototype te skriuwen.
Ik skreau wat ik plande yn PHP. De Apache- en PHP-tsjinner wie op Windows omdat ... Linux wie foar my op dat stuit wat ûnbegrypliks en heul kompleks, sa't letter bliken die, hie ik my tige fersin en op in protte plakken is Linux folle ienfâldiger dan Windows, mar dit is in apart ûnderwerp en wy witte allegear hoefolle holivars der binne op dit ûnderwerp. De Windows-taakplanner luts op in lyts ynterval (ik wit it net krekt, mar soksawat as ien kear elke trije sekonden) in PHP-skript dat alle objekten mei in banale ping ûndersocht en de steat yn in bestân bewarre.
system(“ping -n 3 -w 100 {$ip_address}“);
Ja, ja, it wurkjen mei in databank wie op dat stuit foar my ek net behearske. Ik wist net dat it mooglik wie om prosessen te parallelisearjen, en troch alle netwurkknooppunten duorret in lange tiid, om't ... dit barde yn ien tried. Problemen ûntstienen benammen doe't ferskate knopen wiene net beskikber, omdat elk fan harren fertrage it skript foar 300 ms. Oan 'e kliïntkant wie d'r in ienfâldige loopingfunksje dy't mei yntervallen fan in pear sekonden bywurke ynformaasje fan 'e tsjinner downloade mei in Ajax-fersyk en de ynterface bywurke. No, dan, nei 3 mislearre pings op in rige, as in webside mei tafersjoch op 'e kompjûter iepene wie, spile in fleurige komposysje.
Doe't alles slagge wie ik tige ynspirearre troch it resultaat en tocht dat ik der mear oan taheakje koe (troch myn kennis en mooglikheden). Mar ik hie altyd net leuk systemen mei in miljoen charts, dat ik tocht doe, en noch tink oant hjoed de dei, binne net nedich yn de measte gefallen. Ik woe der allinnich yn sette wat my echt helpe soe yn myn wurk. Dit prinsipe bliuwt fûneminteel foar de ûntwikkeling fan Veliam oant hjoed de dei. Fierder realisearre ik dat it heul cool wêze soe as ik net iepen hoege te bliuwen en te witten oer problemen, en as it barde, iepenje dan de side en sjoch wêr't dit problematyske netwurkknooppunt leit en wat ik dermei dwaan moat . Op ien of oare manier haw ik doe gjin e-post lêzen, ik haw it gewoan net brûkt. Ik kaam op it ynternet tsjin dat d'r SMS-poarten binne wêr't jo in GET- of POST-fersyk kinne stjoere, en se sille in sms stjoere nei myn mobile tillefoan mei de tekst dy't ik skriuw. Ik realisearre fuortendaliks dat ik dit echt woe. En ik begon de dokumintaasje te studearjen. Nei in skoftke wie ik slagge, en no krige ik in SMS oer problemen op it netwurk op myn mobile tillefoan mei de namme fan in "fallen objekt". Hoewol it systeem primityf wie, waard it troch mysels skreaun, en it wichtichste ding dat my motivearre om it te ûntwikkeljen wie dat it in applikaasjeprogramma wie dat my echt holp yn myn wurk.
En doe kaam de dei dat ien fan 'e ynternetkanalen op it wurk gie, en myn tafersjoch liet my der net oer witte. Sûnt Google DNS noch perfekt pingde. It is tiid om nei te tinken oer hoe't jo kinne kontrolearje dat it kommunikaasjekanaal libbet. D'r wiene ferskate ideeën oer hoe't jo dit dwaan kinne. Ik hie gjin tagong ta alle apparatuer. Wy moasten útfine hoe't wy begripe hokker fan 'e kanalen live is, mar sûnder it op ien of oare manier te sjen op' e netwurkapparatuer sels. Doe kaam in kollega op it idee dat it mooglik is dat de tracing nei iepenbiere servers ferskille kin ôfhinklik fan hokker kommunikaasjekanaal op it stuit brûkt wurdt om tagong te krijen ta it ynternet. Ik kontrolearre en it draaide sa út. D'r wiene ferskate rûtes by it spoaren.
system(“tracert -d -w 500 8.8.8.8”);
Sa ferskynde in oar skript, of leaver, om ien of oare reden waard it spoar tafoege oan 'e ein fan itselde skript, dat alle apparaten op it netwurk pingde. Ommers, dit is in oar lang proses dat waard útfierd yn deselde tried en fertrage it wurk fan it hiele skript. Mar doe wie it net sa dúdlik. Mar op ien of oare manier, hy die syn wurk, de koade strikt definiearre hokker soarte fan tracing moat wêze foar elk fan 'e kanalen. Dit is hoe't it systeem begon te wurkjen, dat al kontrolearre (lûd sein, om't d'r gjin samling fan alle metriken wie, mar gewoan ping) netwurkapparaten (routers, switches, wi-fi, ensfh.) En kommunikaasjekanalen mei de bûtenwrâld . Der kamen regelmjittich sms-berjochten en it diagram liet altyd dúdlik sjen wêr't it probleem wie.
Fierders moast ik yn it deistich wurk cross-crossing dwaan. En ik waard wurch fan in gean nei Cisco switches eltse kear om te sjen hokker ynterface te brûken. Hoe cool soe it wêze om te klikken op in objekt yn tafersjoch en sjoch in list fan syn ynterfaces mei beskriuwings. It soe my tiid besparje. Boppedat soe d'r yn dit skema gjin need wêze om Putty of SecureCRT út te fieren om akkounts en kommando's yn te fieren. Ik klikte gewoan op 'e monitoaring, seach wat nedich wie en gong myn wurk te dwaan. Ik begon te sykjen nei manieren om te ynteraksje mei skeakels. Ik kaam daliks oer 2 opsjes: SNMP of ynlogge yn 'e skeakel fia SSH, ynfiere de kommando's dy't ik nedich wie en it resultaat analysearje. Ik haw SNMP ôfwiisd fanwegen de kompleksiteit fan syn ymplemintaasje; Ik wie ûngeduldich om it resultaat te krijen. mei SNMP, jo soene moatte grave yn de MIB foar in lange tiid en, basearre op dizze gegevens, generearje gegevens oer de ynterfaces. Der is in prachtich team by CISCO
show interface statusIt lit krekt sjen wat ik nedich haw foar krusingen. Wêrom lestich falle mei SNMP as ik gewoan de útfier fan dit kommando sjen wol, tocht ik. Nei in skoftke realisearre ik dizze kâns. Klik op in objekt op in webside. In barren waard aktivearre wêrby't de AJAX-kliïnt kontakt op mei de tsjinner, en it, op syn beurt, ferbûn fia SSH oan de skeakel dy't ik nedich (de bewiisbrieven waarden hardcoded yn de koade, der wie gjin winsk om te ferfine it, om guon aparte menu's dêr't it soe mooglik wêze om akkounts te feroarjen fan 'e ynterface , ik hie it resultaat nedich en fluch) Ik ynfierde it boppeste kommando dêr en stjoerde it werom nei de browser. Dat ik begon ynformaasje te sjen oer ynterfaces mei ien klik fan 'e mûs. Dit wie ekstreem handich, foaral as jo dizze ynformaasje op ferskate skeakels tagelyk besjen moasten.
Trace-basearre kanaalmonitoring wie úteinlik net it bêste idee, om't ... soms waard wurk útfierd op it netwurk, en de tracing koe feroarje en de tafersjoch begûn te skriemen op my dat der wiene problemen mei it kanaal. Mar nei't ik in protte tiid oan analyse bestege, realisearre ik dat alle kanalen wurken, en myn tafersjoch ferrifele my. As resultaat frege ik myn kollega's dy't kanaalfoarmjende skeakels behearden om my gewoan syslog te stjoeren as de sichtberensstatus fan buorlju feroare. Dêrtroch wie it folle ienfâldiger, rapper en krekter dan tracing. In evenemint lykas buorman ferlern is oankaam, en ik jou fuortendaliks in notifikaasje oer it kanaal del.
Fierder ferskynden ferskate mear kommando's as jo op in objekt klikke, en SNMP waard tafoege om wat metriken te sammeljen, en dat is it yn prinsipe. It systeem hat him nea fierder ûntwikkele. It die alles wat ik nedich wie, it wie in goed ark. In protte lêzers sille my nei alle gedachten fertelle dat der al in soad software op it ynternet is om dizze problemen op te lossen. Mar feitlik haw ik doe sokke fergese produkten net googled en ik woe wirklik myn programmearringsfeardigens ûntwikkelje, en wat bettere manier om hjir op te drukken dan in echt applikaasjeprobleem. Op dit punt wie de earste ferzje fan tafersjoch foltôge en waard net mear wizige.
Oprjochting fan it Audit-Telecom bedriuw
Nei ferrin fan tiid begon ik dieltiid te wurkjen yn oare bedriuwen, gelokkich liet myn wurkskema my dit dwaan. As jo yn ferskate bedriuwen wurkje, groeie jo feardigens op ferskate gebieten heul fluch, en jo horizonten ûntwikkelje goed. D'r binne bedriuwen wêryn't jo, sa't se sizze, in Sweed, in reaper en in trompetist binne. Oan de iene kant is it dreech, oan de oare kant, as jo net lui binne, wurde jo in generalist en kinne jo problemen flugger en effisjinter oplosse om't jo witte hoe't it relatearre fjild wurket.
Myn freon Pavel (ek in IT-spesjalist) besocht my konstant te stimulearjen om syn eigen bedriuw te begjinnen. D'r wiene ûntelbere ideeën mei ferskate farianten fan wat se diene. Dêr wurdt al jierren oer praat. En op it lêst hie it neat moatten komme om't ik in skeptikus bin, en Pavel is in dreamer. Elke kear as er in idee foarstelde, leaude ik der altyd net yn en wegere ik mei te dwaan. Mar wy woenen echt ús eigen bedriuw iepenje.
Uteinlik koene wy in opsje fine dy't ús beide passe en dwaan wat wy witte hoe te dwaan. Yn 2016 hawwe wy besletten om in IT-bedriuw te meitsjen dat bedriuwen soe helpe IT-problemen op te lossen. Dit is de ynset fan IT-systemen (1C, terminalserver, mailserver, ensfh.), Har ûnderhâld, klassike HelpDesk foar brûkers en netwurkbehear.
Earlik sein, op it momint fan it meitsjen fan it bedriuw, leaude ik der net oer 99,9% yn. Mar op ien of oare manier koe Pavel my krije om te besykjen, en foarút te sjen, die bliek dat hy gelyk hie. Pavel en ik chipten elk 300 roebel, registrearren in nije LLC "Audit-Telecom", hierden in lyts kantoar, makken koele visitekaartsjes, no, yn 't algemien, lykas wierskynlik de measte sûnder ûnderfining, begjinnende sakelju, en begon te sykjen nei kliïnten. Klanten fine is in folslein oar ferhaal. Miskien sille wy in apart artikel skriuwe as ûnderdiel fan it bedriuwsblog as immen ynteressearre is. Kâlde oproppen, flyers, ensfh. Dit joech gjin resultaten. As ik no lês fan in protte ferhalen oer bedriuw, op ien of oare manier, hinget in protte fan gelok ôf. Wy hiene gelok. en letterlik in pear wiken nei de oprjochting fan it bedriuw, myn broer Vladimir benadere ús, dy't brocht ús ús earste klant. Ik sil jo net ferfele mei de details fan it wurkjen mei kliïnten, dat is net wêr't it artikel oer giet, ik sil gewoan sizze dat wy foar in kontrôle gienen, krityske gebieten identifisearre en dizze gebieten bruts út wylst it beslút waard makke oer it gearwurkje mei ús op in trochgeande basis as outsourcers. Hjirnei is fuortendaliks in posityf beslút nommen.
Doe begûnen, benammen troch mouth-of-mouth fia freonen, oare tsjinstbedriuwen te ferskinen. Helpdesk wie yn ien systeem. Ferbinings mei netwurkapparatuer en servers binne oars, of leaver oars. Guon minsken hawwe fluchtoetsen bewarre, oaren brûkten RDP-adresboeken. Monitoring is in oar apart systeem. It is heul ûngemaklik foar in team om te wurkjen yn ferskate systemen. Wichtige ynformaasje wurdt út it each ferlern. No, bygelyks, de terminaltsjinner fan 'e kliïnt waard net beskikber. Oanfragen fan brûkers fan dizze klant wurde fuortendaliks ûntfongen. De stipe spesjalist iepenet in fersyk (it waard ûntfongen fia telefoan). As ynsidinten en fersiken waarden registrearre yn ien systeem, dan sil de stipe spesjalist fuortendaliks sjen wat it probleem fan de brûker is en him deroer fertelle, wylst tagelyk ferbine mei it fereaske objekt om de situaasje te beheinen. Elkenien is bewust fan de taktyske situaasje en wurket harmonieus. Wy hawwe net fûn in systeem dêr't dit alles wurdt kombinearre. It waard dúdlik dat it tiid wie om ús eigen produkt te meitsjen.
Trochgean wurk oan jo tafersjochsysteem
It wie dúdlik dat it systeem dat earder skreaun wie folslein net geskikt wie foar de hjoeddeiske taken. Noch kwa funksjonaliteit noch kwa kwaliteit. En it waard besletten om it systeem fanôf it begjin te skriuwen. Grafysk hie it der folslein oars útsjen moatten. It moast in hiërargysk systeem wêze, sadat it mooglik wêze soe om fluch en maklik it juste objekt foar de juste klant te iepenjen. De regeling lykas yn de earste ferzje wie perfoarst net rjochtfeardige yn it hjoeddeiske gefal, omdat De kliïnten binne oars en it makke hielendal net út yn hokker pân de apparatuer siet. Dit is al oerbrocht nei de dokumintaasje.
Dus, de taken:
- Hierarchyske struktuer;
- In soarte fan tsjinner diel dat kin wurde pleatst op it terrein fan de kliïnt yn 'e foarm fan in firtuele masine te sammeljen de metriken dy't wy nedich en stjoer it nei de sintrale tsjinner, dat sil gearfetsje dit alles en lit it oan ús;
- Alerts. Dy't net misse kinne, want... op dat stuit wie it net mooglik foar ien om te sitten en te sjen nei de monitor;
- Applikaasje systeem. Klanten begûnen te ferskinen foar wa't wy net allinich server- en netwurkapparatuer betsjinne, mar ek wurkstasjons;
- Mooglikheid om fluch ferbining te meitsjen mei servers en apparatuer fan it systeem;
De taken binne steld, wy begjinne te skriuwen. Underweis ferwurkjen oanfragen fan kliïnten. Wy wiene doe al mei 4. Wy begûnen beide dielen tagelyk te skriuwen: de sintrale tsjinner en de tsjinner foar ynstallaasje foar kliïnten. Op dit punt wie Linux net langer in frjemd foar ús en waard besletten dat de firtuele masines dy't kliïnten hawwe soene op Debian wêze. D'r sille gjin ynstallearders wêze, wy sille gewoan in tsjinner dielprojekt meitsje op ien spesifike firtuele masine, en dan sille wy it gewoan klone nei de winske kliïnt. Dit wie in oare flater. Letter waard dúdlik dat yn sa'n skema it updatemeganisme folslein ûnûntwikkele wie. Dy. wy wiene it tafoegjen fan wat nije funksje, en dan wie d'r it hiele probleem om it te fersprieden nei alle kliïntservers, mar wy komme letter op dit werom, alles yn oarder.
Wy makken it earste prototype. Hy koe de clientnetwurkapparaten en servers dy't wy nedich wiene pinge en dizze gegevens nei ús sintrale server stjoere. En hy, op syn beurt, bywurke dizze gegevens yn bulk op 'e sintrale tsjinner. Hjir sil ik net allinnich in ferhaal skriuwe oer hoe en wat slagge, mar ek hokker amateuristyske flaters makke binne en hoe letter ik der mei de tiid foar betelje moast. Dat, de heule beam fan objekten waard opslein yn ien inkeld bestân yn 'e foarm fan in serialisearre objekt. Wylst wy ferbûn ferskate kliïnten oan it systeem, alles wie mear of minder normaal, hoewol't soms wiene der guon artefakten dy't wiene hielendal ûnbegryplik. Mar doe't wy in tsiental tsjinners ferbûn oan it systeem, begûn wûnders te barren. Soms, foar wat ûnbekende reden, alle objekten yn it systeem gewoan ferdwûn. It is hjir wichtich om te notearjen dat de tsjinners dy't de kliïnten elke pear sekonden gegevens nei de sintrale tsjinner hawwe stjoerd fia in POST-fersyk. In oandachtige lêzer en in betûfte programmeur rieden al dat d'r in probleem wie fan meardere tagong ta it bestân wêryn't it serialisearre objekt tagelyk fan ferskate diskusjes waard opslein. En krekt doe't dit barde, barde wûnders mei it ferdwinen fan objekten. De triem waard gewoan leech. Mar dit alles waard net fuortendaliks ûntdutsen, mar allinich yn 'e operaasje mei ferskate servers. Yn dizze perioade waard poarte-scanfunksje tafoege (de tsjinners stjoerd nei de sintrale net allinich ynformaasje oer de beskikberens fan apparaten, mar ek oer de havens dy't op har iepen binne). Dit waard dien troch it kommando op te roppen:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
de resultaten wiene faak ferkeard en scans duorre lang om te foltôgjen. Ik fergeat ping folslein, it waard dien fia fping:
system("fping -r 3 -t 100 {$this->ip}");
Dit waard ek net parallelisearre en dêrom wie it proses tige lang. Letter waard de folsleine list fan IP-adressen dy't nedich binne foar ferifikaasje yn ien kear nei fping stjoerd, en werom krigen wy in klearmakke list fan dyjingen dy't reagearren. Oars as ús, koe fping prosessen parallelisearje.
In oare mienskiplike routine baan wie it opsetten fan guon tsjinsten fia WEB. No, bygelyks, ECP fan MS Exchange. Yn prinsipe is it gewoan in keppeling. En wy besletten dat wy sokke keppelings direkt oan it systeem taheakje moatte moatte, om net yn 'e dokumintaasje of earne oars yn blêdwizers te sykjen hoe't jo tagong krije ta de ECP fan in spesifike kliïnt. Dit is hoe't it konsept fan boarne keppelings foar it systeem ferskynde, har funksjonaliteit is oant hjoed de dei beskikber en is net feroare, goed, hast.
Hoe boarne keppelings wurkje yn Veliam
Ferbinings op ôfstân
Dit is hoe't it liket yn aksje yn 'e hjoeddeistige ferzje fan Veliam
Ien fan 'e taken wie om fluch en maklik te ferbinen mei servers, wêrfan d'r al in protte (mear as hûndert) wiene en it sortearjen troch miljoenen foarôf bewarre RDP-fluchtoetsen wie ekstreem ûngemaklik. In ark wie nedich. Der is software op it ynternet dat is wat as in adresboek foar sokke RDP ferbinings, mar se binne net yntegrearre mei it tafersjoch systeem, en akkounts kinne net bewarre wurde. Elke kear akkounts ynfiere foar ferskate kliïnten is pure hel as jo tsientallen kearen deis ferbine mei ferskate servers. Mei SSH binne dingen in bytsje better; d'r is in protte goede software wêrmei jo sokke ferbiningen yn mappen kinne organisearje en de akkounts fan har ûnthâlde. Mar d'r binne 2 problemen. De earste is dat wy gjin inkeld programma fûnen foar RDP- en SSH-ferbiningen. De twadde is dat as ik op in stuit net by myn komputer bin en ik moat fluch ferbine, of ik haw it systeem gewoan opnij ynstalleare, sil ik yn 'e dokumintaasje moatte gean om nei it akkount fan dizze kliïnt te sjen. It is ûngemaklik en in fergriemerij fan tiid.
De hiërargyske struktuer dy't wy nedich wiene foar kliïntservers wie al beskikber yn ús ynterne produkt. Ik moast gewoan útfine hoe't ik dêr flugge ferbinings oanmeitsje oan de nedige apparatuer. Om te begjinnen, teminsten binnen jo netwurk.
Mei it rekkenjen fan it feit dat de klant yn ús systeem in browser wie dy't gjin tagong hat ta de lokale boarnen fan 'e kompjûter, om gewoan de applikaasje te starten dy't wy nedich wiene mei wat kommando, waard it útfûn om alles te dwaan fia de "Windows oanpast url-skema”. Dit is hoe't in bepaalde "plugin" ferskynde foar ús systeem, dat gewoan Putty en Remote Desktop Plus omfette en, tidens de ynstallaasje, gewoan it URI-skema yn Windows registrearre. No, doe't wy wolle ferbine mei in objekt fia RDP of SSH, klikten wy dizze aksje op ús systeem en de Custom URI wurke. De standert mstsc.exe ynboud yn Windows of stopverf, dy't diel wie fan 'e "plugin", waard lansearre. Ik set it wurd plugin yn oanhalingstekens omdat dit gjin browser plugin is yn 'e klassike sin.
Alteast dat wie wat. Handig adresboek. Boppedat, yn it gefal fan Putty, alles wie oer it algemien goed; it koe wurde jûn IP-ferbiningen, oanmelden en wachtwurd as ynfier parameters. Dy. Wy hawwe al ferbûn mei Linux-tsjinners op ús netwurk mei ien klik sûnder wachtwurden yn te fieren. Mar mei RDP is it net sa ienfâldich. Standert mstsc kin gjin bewiisbrieven leverje as parameters. Remote Desktop Plus kaam ta de rêding. Hy liet dit barre. No kinne wy sûnder, mar foar in lange tiid wie it in trouwe assistint yn ús systeem. Mei HTTP(S)-siden is alles ienfâldich, sokke objekten wurde gewoan iepene yn 'e browser en dat is it. Handich en praktysk. Mar dit wie lok allinnich op it ynterne netwurk.
Om't wy de grutte mearderheid fan problemen op ôfstân fan it kantoar hawwe oplost, wie it maklikste om VPN's beskikber te meitsjen foar kliïnten. En dan wie it mooglik om te ferbinen mei harren út ús systeem. Mar it wie dochs wat ûngemaklik. Foar elke kliïnt wie it nedich om in boskje ûnthâlde VPN-ferbiningen op elke kompjûter te hâlden, en foardat jo ferbine mei ien, wie it nedich om de oerienkommende VPN yn te skeakeljen. Wy hawwe dizze oplossing foar in lange tiid brûkt. Mar it oantal kliïnten nimt ta, it oantal VPN's nimt ek ta, en dit alles begon ús te spannen en der moast wat oan dien wurde. Triennen kamen foaral yn myn eagen nei it opnij ynstallearjen fan it systeem, doe't ik tsientallen VPN-ferbiningen opnij moast ynfiere yn in nij Windows-profyl. Hâld op mei dit te setten, sei ik, en begon te tinken oer wat ik der oan dwaan koe.
It barde dat alle kliïnten apparaten fan it bekende bedriuw Mikrotik as router hiene. Se binne heul funksjoneel en handich foar it útfieren fan hast elke taak. It neidiel is dat se "kaapt". Wy hawwe dit probleem gewoan oplost troch alle tagong fan bûten ôf te sluten. Mar it wie nedich om op ien of oare manier tagong ta har te hawwen sûnder nei it plak fan 'e kliïnt te kommen, om't ... it is lang. Wy makken gewoan tunnels foar elk sa'n Mikrotik en skieden se yn in apart swimbad. sûnder routing, sadat der gjin ferbining is fan jo netwurk mei de netwurken fan kliïnten en har netwurken mei elkoar.
It idee waard berne om derfoar te soargjen dat as ik klik op it objekt dat ik nedich yn it systeem, de sintrale monitoaring tsjinner, wittende de SSH akkounts fan alle kliïnt Mikrotik, ferbynt mei de winske ien, makket in trochstjoere regel nei de winske host mei de fereaske haven. Der binne ferskate punten hjir. De oplossing is net universele - it sil allinich wurkje foar Mikrotik, om't de kommandosyntaksis oars is foar alle routers. Ek moasten sokke trochstjoerings dan op ien of oare manier wiske wurde, en it serverdiel fan ús systeem koe yn essinsje op gjin inkelde manier folgje oft ik myn RDP-sesje klear hie. No, sa'n trochstjoering is in gat foar de klant. Mar wy hawwe universaliteit net neistribbe, om't ... it produkt waard allinich binnen ús bedriuw brûkt en d'r wiene gjin gedachten om it oan it publyk frij te litten.
Elk fan 'e problemen waard op syn eigen manier oplost. Doe't de regel makke waard, wie dizze trochstjoering allinich beskikber foar ien spesifyk ekstern IP-adres (wêrfan de ferbining inisjalisearre waard). Sa waard in befeiligingsgat foarkommen. Mar mei elke sa'n ferbining waard in Mikrotik-regel tafoege oan 'e NAT-side en waard net wiske. En elkenien wit dat hoe mear regels der binne, hoe mear de prosessor fan de router wurdt laden. En yn 't algemien koe ik net akseptearje dat ik ien dei nei wat Mikrotik gean soe, en d'r soene hûnderten deade, nutteleaze regels wêze.
Sûnt ús tsjinner kin net track de ferbining status, lit Mikrotik track se sels. En ik skreau in skript dat alle trochstjoerregels konstant kontrolearre mei in spesifike beskriuwing en kontrolearre oft de TCP-ferbining in gaadlike regel hie. As der in skoft net ien west hat, dan is de ferbining wierskynlik al foltôge en kin dizze trochstjoering wiske wurde. Alles slagge, it skript wurke goed.
Trouwens, hjir is it:
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
}
}
It hie grif moaier, flugger, ensfh., mar it wurke, laadde Mikrotik net en die poerbêst wurk. Wy koene einlings ferbine mei de servers en netwurkapparatuer fan kliïnten mei mar ien klik. Sûnder in VPN te iepenjen of wachtwurden yn te fieren. It systeem is echt handich wurden om mei te wurkjen. Tsjinsttiid waard fermindere, en wy hawwe allegear tiid bestege oan it wurk ynstee fan te ferbinen mei de nedige objekten.
Mikrotik Backup
Wy konfigureare reservekopy fan alle Mikrotik nei FTP. En oer it algemien wie alles goed. Mar as jo in reservekopy moasten krije, moasten jo dizze FTP iepenje en dêr nei sykje. Wy hawwe in systeem wêryn alle routers binne ferbûn; wy kinne kommunisearje mei apparaten fia SSH. Wêrom meitsje wy it net sa dat it systeem sels deistich backups nimt fan alle Mikrotik, tocht ik. En hy begon it út te fieren. Wy ferbûn, makken in reservekopy en namen it nei opslach.
Skriptkoade yn PHP foar it nimmen fan in reservekopy fan 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');
?>
De reservekopy wurdt nommen yn twa foarmen - binêre en tekst konfiguraasje. De binêre helpt om de fereaske konfiguraasje fluch te herstellen, en de tekst ien lit jo begripe wat jo moatte dwaan as d'r in twongen ferfanging fan apparatuer is en it binêr kin net opladen wurde. As gefolch hawwe wy in oare handige funksjonaliteit yn it systeem krigen. Boppedat, by it tafoegjen fan nije Mikrotik, wie d'r net nedich om neat te konfigurearjen; Ik haw it objekt gewoan oan it systeem tafoege en in akkount foar it ynsteld fia SSH. Dêrnei soarge it systeem sels foar it nimmen fan backups. De hjoeddeistige ferzje fan SaaS Veliam hat dizze funksjonaliteit noch net, mar wy sille it gau portearje.
Skermôfbyldings fan hoe't it der útseach yn it ynterne systeem
Oergong nei normale databank opslach
Ik haw hjirboppe al skreaun dat artefakten ferskynden. Soms ferdwûn de hiele list fan objekten yn it systeem gewoan, soms by it bewurkjen fan in objekt waard de ynformaasje net bewarre en moast it objekt trije kear omneamd wurde. Dit irritearre elkenien ferskriklik. It ferdwinen fan objekten barde komselden, en waard maklik restaurearre troch weromsette dit tige triem, mar mislearrings by it bewurkjen fan objekten barde frij faak. Wierskynlik haw ik dit ynearsten net fia de databank dien, om't it net paste yn myn tinzen hoe't it mooglik wie om in beam mei alle ferbiningen yn in platte tafel te hâlden. It is flak, mar de beam is hiërargysk. Mar in goede oplossing foar meardere tagong, en dêrnei (as it systeem komplekser wurdt) transaksjoneel, is in DBMS. Ik bin wierskynlik net de earste dy't dit probleem tsjinkomt. Ik begûn te googlejen. It die bliken dat alles foar my al útfûn wie en der binne ferskate algoritmen dy't in beam bouwe fan in platte tafel. Nei it besjen fan elk, haw ik ien fan har ymplementearre. Mar dit wie al in nije ferzje fan it systeem, om't ... Yn feite, hjirtroch moast ik nochal in soad oerskriuwe. It resultaat wie natuerlik, de problemen fan willekeurige gedrach fan it systeem gongen fuort. Guon soene sizze dat de flaters tige amateuristysk binne (single-threaded scripts, opslaan fan ynformaasje dy't meardere kearen tagelyk tagong wie fan ferskate threads yn in bestân, ensfh.) Op it mêd fan softwareûntwikkeling. Miskien is dit wier, mar myn haadtaak wie administraasje, en programmearring wie in side-hurde foar myn siel, en ik hie gewoan gjin ûnderfining mei it wurkjen yn in team fan programmeurs, wêr't sokke basis dingen my daliks foarsteld wurde soe troch myn senior kameraden. Dêrom haw ik al dizze bulten sels foldien, mar ik learde it materiaal tige goed. En ek omfettet myn baan gearkomsten mei kliïnten, aksjes dy't rjochte binne om it bedriuw te befoarderjen, in bulte bestjoerlike problemen binnen it bedriuw, en folle, folle mear. Mar op ien of oare manier, wat der al wie, wie fraach. De jonges en ik sels brûkten it produkt yn ús deistich wurk. Der wiene earlik net suksesfolle ideeën en oplossings wêrop de tiid fergriemd wie, mar úteinlik waard dúdlik dat dit gjin wurkmiddel wie en gjinien brûkte it en it kaam net yn Veliam telâne.
Helpdesk - HelpDesk
It soe net mis wêze om te neamen hoe HelpDesk waard foarme. Dit is in folslein oar ferhaal, want... yn Veliam is dit al de 3e folslein nije ferzje, dy't oars is as alle eardere. No is it in ienfâldich systeem, yntuïtyf sûnder ûnnedige toeters en bellen, mei de mooglikheid om te yntegrearjen mei in domein, en ek de mooglikheid om tagong te krijen ta itselde brûkersprofyl fan oeral mei in keppeling fan in e-post. En it wichtichste is it mooglik om te ferbinen mei de oanfreger fia VNC fan oeral (thús of op it kantoar) direkt fan 'e applikaasje sûnder VPN of poarte trochstjoere. Ik sil jo fertelle hoe't wy hjirby kamen, wat earder bard is en hokker ferskriklike besluten binne makke.
Wy ferbûn mei brûkers fia de bekende TeamViewer. Alle kompjûters waans brûkers wy tsjinje hawwe TV ynstallearre. It earste ding dat wy ferkeard diene, en it dêrnei fuorthelle, wie it keppeljen fan elke HD-kliïnt oan hardware. Hoe hat de brûker oanmeld by it HD-systeem om in fersyk efter te litten? Neist de TV hie elkenien in spesjaal hulpprogramma ynstalleare op har kompjûters, skreaun yn Lazarus (in protte minsken hjir sille de eagen rolje, en miskien sels Google gean wat it is, mar de bêste gearstalde taal dy't ik wist wie Delphi, en Lazarus is hast itselde ding, allinich fergees). Yn 't algemien lansearre de brûker in spesjale batchbestân dy't dit hulpprogramma lansearre, dy't op syn beurt de HWID fan it systeem lêze en dêrnei waard de browser lansearre en autorisaasje barde. Wêrom is dit dien? Yn guon bedriuwen wurdt it oantal betsjinne brûkers yndividueel teld, en de tsjinstpriis foar elke moanne is basearre op it oantal minsken. Dit is begryplik, sizze jo, mar wêrom is it bûn oan hardware? Hiel gewoan kamen guon persoanen thús en makken in fersyk fan har thúslaptop yn 'e styl fan "meitsje hjir alles moai foar my." Neist it lêzen fan it systeem HWID, luts it hulpprogramma de hjoeddeistige Teamviewer ID út it register en stjoerde it ek oan ús. Teamviewer hat in API foar yntegraasje. En wy hawwe dizze yntegraasje dien. Mar der wie ien fangen. Troch dizze API's is it ûnmooglik om te ferbinen mei de kompjûter fan 'e brûker as hy dizze sesje net eksplisyt inisjearret en nei it besykjen om dêrmei te ferbinen, moat hy ek klikke op "befêstigje". Op dat stuit like it ús logysk dat gjinien soe ferbine sûnder it fersyk fan 'e brûker, en om't de persoan by de kompjûter is, sil hy de sesje begjinne en befêstigjend reagearje op it fersyk foar ferbining op ôfstân. Alles draaide ferkeard út. Oanfregers fergeaten te drukken op de sesje te begjinnen, en moasten har dit fertelle yn in tillefoanpetear. Dit fergriemde tiid en wie frustrerend oan beide kanten fan it proses. Boppedat is it hielendal net ûngewoan foar sokke mominten as in persoan in fersyk ferlit, mar kin allinich ferbine as hy foar it middeis giet. Want it probleem is net kritysk en hy wol net dat syn wurkproses ûnderbrutsen wurdt. Dêrtroch sil hy gjin knoppen drukke om ferbining mooglik te meitsjen. Dit is hoe't ekstra funksjonaliteit ferskynde by it oanmelden by HelpDesk - it lêzen fan Teamviewer's ID. Wy wisten it permaninte wachtwurd dat waard brûkt by it ynstallearjen fan Teamviewer. Mear krekter, allinich it systeem wist it, om't it yn 'e ynstallearder en yn ús systeem ynboud wie. Dêrtroch wie d'r in ferbiningsknop fan 'e applikaasje troch te klikken wêrop d'r net op hoege te wachtsjen, mar Teamviewer iepene fuortendaliks en in ferbining barde. As gefolch wiene der twa soarten mooglike ferbinings. Troch de offisjele Teamviewer API en ús selsmakke ien. Ta myn ferrassing stopten se hast fuortendaliks mei it brûken fan de earste, hoewol d'r in ynstruksje wie om it allinich te brûken yn spesjale gefallen en as de brûker sels it startsein jout. Dochs, jou my no feiligens. Mar it die bliken dat de oanfregers dit net nedich hiene. Se binne allegear absolút goed mei it ferbûn wêze mei har sûnder in befêstigingsknop.
Oerskeakelje nei multithreading yn Linux
De fraach fan it rapperjen fan 'e passaazje fan in netwurkscanner foar de iepenheid fan in foarbepaalde list fan havens en ienfâldige pinging fan netwurkobjekten is lang begon te ûntstean. Hjir is fansels de earste oplossing dy't yn 't sin komt multithreading. Sûnt de wichtichste tiid bestege oan ping wachtet foar it werombringen fan it pakket, en de folgjende ping kin net begjinne oant it foarige pakket wurdt weromjûn, yn bedriuwen dy't sels 20+ servers plus netwurkapparatuer hiene, wurke dit al frij stadich. It punt is dat ien pakket ferdwine kin, mar de systeembehearder der net daliks oer ynformearje. Hy sil gewoan ophâlde mei it akseptearjen fan sokke spam hiel fluch. Dit betsjut dat jo elk objekt mear as ien kear moatte pinge foardat jo in konklúzje meitsje oer ûnberikberens. Sûnder te folle detail te gean, is it nedich om it te parallelisearjen, om't as dit net dien is, dan sil de systeembehearder wierskynlik leare oer it probleem fan 'e kliïnt, en net fan it tafersjochsysteem.
PHP sels stipet gjin multithreading út it fak. By steat fan multiprocessing, kinne jo forke. Mar yn feite hie ik al in pollmeganisme skreaun en ik woe it sa meitsje dat ik ienris alle knooppunten telde dy't ik nedich wie fan 'e databank, alles yn ien kear pinge, wachtsje op in antwurd fan elk en pas dêrnei fuortendaliks skriuwe de gegevens. Dit besparret op it oantal lêsoanfragen. Multithreading past perfekt yn dit idee. Foar PHP is d'r in PThreads-module wêrmei jo echte multithreading kinne dwaan, hoewol it in flinke hoemannichte tinken duorre om dit op PHP 7.2 yn te stellen, mar it waard dien. Poarte skennen en ping binne no rap. En ynstee fan bygelyks 15 sekonden per rûnte earder, begûn dit proses 2 sekonden te nimmen. It wie in goed resultaat.
Fluch kontrôle fan nije bedriuwen
Hoe kaam de funksjonaliteit foar it sammeljen fan ferskate metriken en hardware-kenmerken? It is ienfâldich. Soms wurde wy gewoan besteld om de hjoeddeistige IT-ynfrastruktuer te kontrolearjen. No, itselde ding is nedich om de kontrôle fan in nije klant te rapperjen. Wy hiene wat nedich wêrmei't wy nei in medium of grut bedriuw komme kinne en gau útfine wat se hawwe. Yn myn miening wurdt ping op it ynterne netwurk allinich blokkearre troch dyjingen dy't har eigen libben komplisearje wolle, en yn ús ûnderfining binne d'r in pear fan har. Mar der binne ek sokke minsken. Dêrtroch kinne jo netwurken fluch scannen foar de oanwêzigens fan apparaten mei in ienfâldige ping. Dan kinne wy se tafoegje en scannen op iepen havens dy't ús ynteressearje. Yn feite bestie dizze funksjonaliteit al; it wie allinich nedich om in kommando fan 'e sintrale tsjinner ta te foegjen oan' e slaaf, sadat it de opjûne netwurken soe scannen en alles tafoegje wat it fûn oan 'e list. Ik fergeat te neamen, it waard oannommen dat wy al in ready-made ôfbylding hiene mei in konfigureare systeem (slave-monitoring-tsjinner) dat wy gewoan út 'e kliïnt kinne rôlje tidens in kontrôle en it ferbine mei ús wolk.
Mar it resultaat fan in kontrôle omfettet meastentiids in boskje ferskillende ynformaasje, en ien fan har is wat soarte apparaten binne op it netwurk. Alderearst wiene wy ynteressearre yn Windows-tsjinners en Windows-wurkstasjons as ûnderdiel fan in domein. Sûnt yn middelgrutte en grutte bedriuwen is it ûntbrekken fan in domein wierskynlik in útsûndering op 'e regel. Om ien taal te praten, is it gemiddelde, neffens my, 100+ minsken. It wie nedich om te kommen mei in manier om te sammeljen gegevens fan alle Windows masines en tsjinners, wittende harren IP en domein administrator account, mar sûnder it ynstallearjen fan software op elk fan harren. De WMI-ynterface komt ta de rêding. Windows Management Instrumentation (WMI) betsjut letterlik Windows behear ark. WMI is ien fan 'e basistechnologyen foar sintralisearre behear en tafersjoch op' e wurking fan ferskate dielen fan 'e kompjûterynfrastruktuer dy't it Windows-platfoarm draait. Oernommen fan wiki. Dêrnei moast ik wer tinken om wmic (dit is in WMI-kliïnt) foar Debian te kompilearjen. Neidat alles klear wie, wie der allinnich noch oer om de nedige knopen gewoan fia wmic te polljen foar de nedige ynformaasje. Fia WMI kinne jo hast alle ynformaasje krije fan in Windows-kompjûter, en boppedat kinne jo de kompjûter dêrtroch ek kontrolearje, bygelyks stjoere nei it opnij opstarten. Dit is hoe't de kolleksje fan ynformaasje oer Windows-stasjons en servers yn ús systeem ferskynde. Njonken dit wie d'r aktuele ynformaasje oer aktuele systeemlastyndikatoaren. Wy freegje se faker, en ynformaasje oer hardware minder faak. Hjirnei waard de auditing wat nofliker.
Software distribúsje beslút
Wy sels brûke it systeem alle dagen, en it is altyd iepen foar elke technyske meiwurker. En wy tochten dat wy mei oaren diele koene wat wy al hawwe. It systeem wie noch net klear om ferspraat te wurden. In protte moast opnij bewurke wurde sadat de lokale ferzje yn SaaS feroaret. Dizze omfetsje feroaringen yn ferskate technyske aspekten fan it systeem (ferbiningen op ôfstân, stipe tsjinst), analyse fan modules foar fergunningferliening, sharding fan klantdatabases, skaalfergrutting fan elke tsjinst, en ûntwikkeling fan auto-updatesystemen foar alle dielen. Mar dit sil it twadde diel fan it artikel wêze.
Update
Boarne: www.habr.com