Pozdrav svima, moje ime je Sergey Emelyanchik. Ja sam na čelu kompanije Audit-Telecom, glavnog programera i autora sistema Veliam. Odlučio sam da napišem članak o tome kako smo moj prijatelj i ja stvorili outsourcing kompaniju, pisali softver za sebe i nakon toga počeli da ga distribuiramo svima putem SaaS sistema. O tome kako kategorički nisam vjerovao da je to moguće. Članak će sadržavati ne samo priču, već i tehničke detalje o tome kako je nastao Veliam proizvod. Uključujući neke dijelove izvornog koda. Kasnije ću vam reći koje smo greške napravili i kako smo ih ispravili. Bilo je nedoumica da li objaviti takav članak. Ali mislio sam da je bolje to učiniti, dobiti povratnu informaciju i poboljšati, nego ne objaviti članak i razmisliti šta bi se dogodilo da...
prapovijest
Radio sam u jednoj firmi kao IT službenik. Kompanija je bila prilično velika sa širokom mrežnom strukturom. Neću se zadržavati na svojim radnim obavezama, samo ću reći da one definitivno nisu uključivale razvoj bilo čega.
Imali smo monitoring, ali čisto iz akademskog interesa htio sam pokušati napisati svoj najjednostavniji. Ideja je bila sljedeća: želio sam da bude na webu, tako da mogu lako ući bez instaliranja klijenta i vidjeti što se događa s mrežom s bilo kojeg uređaja, uključujući i mobilni uređaj putem Wi-Fi-ja, a također sam zaista želeo je da brzo shvati šta se nalazi u prostoriji koja je postala "mopey" jer... postojali su vrlo strogi zahtjevi za vrijeme odgovora na takve probleme. Kao rezultat toga, u mojoj glavi se rodio plan da napišem jednostavnu web stranicu na kojoj je bila jpeg pozadina sa mrežnim dijagramom, izrežem same uređaje sa njihovim IP adresama na ovoj slici i prikažem dinamički sadržaj na vrhu slika u traženim koordinatama u obliku zelene ili trepćuće crvene IP adrese. Zadatak je postavljen, počnimo.
Ranije sam programirao u Delphiju, PHP-u, JS-u i vrlo površno C++. Znam prilično dobro kako mreže rade. VLAN, rutiranje (OSPF, EIGRP, BGP), NAT. Ovo mi je bilo dovoljno da sam napišem primitivni prototip za praćenje.
Napisao sam šta sam planirao u PHP-u. Apache i PHP server je bio na Windows-u jer... Linux je za mene u tom trenutku bio nešto neshvatljivo i vrlo složeno, kako se kasnije pokazalo, jako sam se prevario i na mnogim mjestima je Linux mnogo jednostavniji od Windowsa, ali ovo je posebna tema i svi znamo koliko ima holivara na ovu temu. Windows planer zadataka je u malom intervalu (ne sećam se tačno, ali otprilike jednom u tri sekunde) povukao PHP skriptu koja je prozivala sve objekte banalnim pingom i sačuvala stanje u datoteku.
system(“ping -n 3 -w 100 {$ip_address}“);
Da, da, rad sa bazom podataka u tom trenutku mi takođe nije bio savladan. Nisam znao da je moguće paralelizirati procese, a prolazak kroz sve mrežne čvorove je dugo trajao, jer... ovo se desilo u jednoj temi. Problemi su posebno nastajali kada je nekoliko čvorova bilo nedostupno, jer svaki od njih je odgodio skriptu za 300 ms. Na strani klijenta postojala je jednostavna funkcija petlje koja je, u intervalima od nekoliko sekundi, preuzimala ažurirane informacije sa servera uz Ajax zahtjev i ažurirala sučelje. Pa, onda, nakon 3 neuspješna pinga zaredom, ako je na računalu otvorena web stranica sa nadzorom, svirala je vesela kompozicija.
Kada je sve ispalo, bio sam veoma inspirisan rezultatom i pomislio sam da mu mogu dodati još (zbog svog znanja i mogućnosti). Ali uvek nisam voleo sisteme sa milion grafikona, za koje sam tada mislio, a i dan-danas mislim, da su u većini slučajeva nepotrebni. Hteo sam da unesem samo ono što bi mi zaista pomoglo u radu. Ovo načelo ostaje temeljno za razvoj Veliama do danas. Nadalje, shvatio sam da bi bilo super da ne moram držati otvoren monitoring i znati za probleme, a kada se to dogodi, onda otvorim stranicu i vidim gdje se nalazi ovaj problematični mrežni čvor i šta dalje s njim . Nekako tada nisam čitao mejlove, jednostavno ga nisam koristio. Naišla sam na internetu da postoje SMS gatewayi na koje možete poslati GET ili POST zahtjev, a oni će poslati SMS na moj mobilni telefon sa tekstom koji ja napišem. Odmah sam shvatio da ovo zaista želim. I počeo sam proučavati dokumentaciju. Nakon nekog vremena uspio sam, a sada sam na mobilni telefon dobio SMS o problemima na mreži sa imenom “palog predmeta”. Iako je sistem bio primitivan, napisao sam ga sam, a najvažnije što me je motivisalo da ga razvijem je to što je to bio aplikativni program koji mi je zaista pomogao u radu.
A onda je došao dan kada je jedan od internet kanala pokvario rad, a moj monitoring me nije obavijestio o tome. Pošto je Google DNS i dalje savršeno pingovao. Vrijeme je da razmislite o tome kako možete pratiti da li je komunikacioni kanal živ. Bilo je različitih ideja kako to učiniti. Nisam imao pristup svoj opremi. Morali smo smisliti kako da shvatimo koji od kanala je uživo, ali bez mogućnosti da ga nekako pogledamo na samoj mrežnoj opremi. Tada je kolega došao na ideju da je moguće da se praćenje rute do javnih servera može razlikovati ovisno o tome koji se komunikacijski kanal trenutno koristi za pristup Internetu. Provjerio sam i ispalo je tako. Bilo je različitih ruta prilikom praćenja.
system(“tracert -d -w 500 8.8.8.8”);
Tako se pojavila još jedna skripta, odnosno iz nekog razloga je trag dodan na kraj iste skripte, koji je pingovao sve uređaje na mreži. Na kraju krajeva, ovo je još jedan dug proces koji je izvršen u istoj niti i usporio rad cijele skripte. Ali tada to nije bilo tako očigledno. Ali na ovaj ili onaj način, on je odradio svoj posao, kod je striktno definirao kakvo praćenje treba biti za svaki od kanala. Tako je počeo da radi sistem koji je već nadzirao (glasno rečeno, jer nije bilo prikupljanja nikakve metrike, već samo pingovanje) mrežnih uređaja (ruteri, prekidači, wi-fi itd.) i kanala komunikacije sa spoljnim svetom . SMS poruke su stizale redovno i dijagram je uvijek jasno pokazivao gdje je problem.
Dalje, u svakodnevnom radu morao sam da radim cross-crossing. I dosadilo mi je da svaki put odlazim na Cisco prekidače da vidim koji interfejs da koristim. Kako bi bilo cool kliknuti na objekat u nadzoru i vidjeti listu njegovih interfejsa sa opisima. Uštedelo bi mi vreme. Štaviše, u ovoj šemi ne bi bilo potrebe da pokrećete Putty ili SecureCRT za unos naloga i komandi. Samo sam kliknuo na monitoring, vidio šta treba i otišao da radim svoj posao. Počeo sam da tražim načine za interakciju sa prekidačima. Odmah sam naišao na 2 opcije: SNMP ili prijavljivanje na switch preko SSH-a, unos komandi koje su mi bile potrebne i raščlanjivanje rezultata. Odbacio sam SNMP zbog složenosti njegove implementacije, bio sam nestrpljiv da dobijem rezultat. sa SNMP-om, morali biste dugo kopati po MIB-u i na osnovu ovih podataka generirati podatke o interfejsima. U CISCO-u postoji divan tim
show interface statusPokazuje tačno šta mi treba za križanja. Zašto se mučiti sa SNMP-om kada samo želim vidjeti izlaz ove komande, pomislio sam. Nakon nekog vremena, shvatio sam ovu priliku. Kliknuo na objekt na web stranici. Pokrenuo se događaj kojim je AJAX klijent kontaktirao server, a on se, zauzvrat, preko SSH-a povezao sa svičom koji mi je bio potreban (akreditivi su bili tvrdo kodirani u kodu, nije bilo želje da se to pročišćava, da se prave neki zasebni meniji gdje bilo bi moguće promijeniti račune iz interfejsa, trebao mi je rezultat i to brzo) Uneo sam gornju komandu tamo i poslao je nazad u pretraživač. Tako sam počeo da vidim informacije o interfejsima jednim klikom miša. Ovo je bilo izuzetno zgodno, posebno kada ste morali da vidite ove informacije na različitim prekidačima odjednom.
Praćenje kanala zasnovano na tragovima na kraju nije bila najbolja ideja, jer... ponekad se radilo na mreži, a praćenje se moglo promijeniti i monitoring je počeo da vrišti na mene da ima problema sa kanalom. Ali nakon što sam potrošio dosta vremena na analizu, shvatio sam da svi kanali rade, a moje praćenje me vara. Kao rezultat toga, zamolio sam svoje kolege koji su upravljali prekidačima za formiranje kanala da mi jednostavno pošalju syslog kada se status vidljivosti susjeda promijeni. Shodno tome, bilo je mnogo jednostavnije, brže i preciznije od praćenja. Stigao je događaj kao što je komšija je izgubio, i odmah dajem obaveštenje o prekidu kanala.
Nadalje, pojavilo se još nekoliko komandi prilikom klika na objekt, a dodat je SNMP za prikupljanje nekih metrika, i to je u suštini to. Sistem se nikada nije dalje razvijao. Uradio je sve što mi je trebalo, bio je dobar alat. Mnogi čitaoci će mi vjerovatno reći da već postoji mnogo softvera na internetu za rješavanje ovih problema. Ali u stvari, tada nisam guglao takve besplatne proizvode i zaista sam želio razviti svoje vještine programiranja, a ima li boljeg načina da se potrudim za to od pravog problema sa aplikacijom. U ovom trenutku, prva verzija praćenja je završena i više nije modificirana.
Osnivanje kompanije Audit-Telecom
Kako je vrijeme prolazilo, počeo sam raditi honorarno u drugim kompanijama, srećom moj raspored mi je to omogućio. Kada radite u različitim kompanijama, vaše vještine u različitim oblastima rastu vrlo brzo, a vaši horizonti se dobro razvijaju. Ima kompanija u kojima si, kako kažu, Šveđanin, kosac i trubač. S jedne strane je teško, s druge strane, ako nisi lijen, postaješ generalista i to ti omogućava da brže i efikasnije rješavaš probleme jer znaš kako srodna oblast funkcionira.
Moj prijatelj Pavel (također informatičar) me stalno pokušavao ohrabriti da pokrenem vlastiti posao. Bilo je bezbroj ideja sa različitim varijacijama onoga što su radili. O tome se raspravlja godinama. I na kraju, nije trebalo ni do čega doći jer ja sam skeptik, a Pavel sanjar. Svaki put kada je predložio ideju, ja uvek nisam verovao u nju i odbijao sam da učestvujem. Ali zaista smo željeli otvoriti vlastiti posao.
Konačno, uspjeli smo pronaći opciju koja nam oboje odgovara i radimo ono što znamo. 2016. godine odlučili smo da napravimo IT kompaniju koja bi pomogla preduzećima da reše IT probleme. To je postavljanje IT sistema (1C, terminal server, mail server itd.), njihovo održavanje, klasični HelpDesk za korisnike i mrežna administracija.
Iskreno govoreći, u vrijeme stvaranja kompanije nisam vjerovao u nju oko 99,9%. Ali nekako me Pavel uspio natjerati da pokušam, i gledajući unaprijed, pokazalo se da je bio u pravu. Pavel i ja smo ubacili po 300 rubalja, registrovali novo LLC „Audit-Telecom“, iznajmili malu kancelariju, napravili cool vizit karte, pa, generalno, kao verovatno većina neiskusnih, početnika biznismena, i počeli da tražimo klijente. Pronalaženje klijenata je sasvim druga priča. Možda ćemo napisati poseban članak kao dio korporativnog bloga ako nekoga zanima. Hladni pozivi, letci itd. To nije dalo nikakve rezultate. Kako sada čitam iz mnogih priča o biznisu, na ovaj ili onaj način, mnogo zavisi od sreće. Imali smo sreće. i bukvalno par sedmica nakon nastanka firme prišao nam je brat Vladimir koji nam je doveo prvog klijenta. Neću vas zamarati detaljima rada sa klijentima, nije o tome u članku, samo ću reći da smo išli na reviziju, identifikovali kritične oblasti i te oblasti su se pokvarile dok se donosila odluka da li se sarađujete sa nama na stalnoj osnovi kao autsorci. Nakon toga je odmah donesena pozitivna odluka.
Tada su, uglavnom usmenom predajom preko prijatelja, počele da se pojavljuju i druge uslužne kompanije. Helpdesk je bio u jednom sistemu. Veze na mrežnu opremu i servere su različite, odnosno različite. Neki ljudi su sačuvali prečice, drugi su koristili RDP adresare. Monitoring je još jedan poseban sistem. Veoma je nezgodno da tim radi u različitim sistemima. Važne informacije se gube iz vida. Pa, na primjer, klijentov terminal server postao je nedostupan. Prijave korisnika ovog klijenta se odmah primaju. Stručnjak za podršku otvara zahtjev (primljen je telefonom). Ako bi se incidenti i zahtjevi registrovali u jednom sistemu, onda bi stručnjak za podršku odmah vidio u čemu je problem korisnika i rekao mu o tome, dok bi se istovremeno povezao na traženi objekt kako bi riješio situaciju. Svi su svjesni taktičke situacije i rade skladno. Nismo našli sistem u kojem se sve ovo kombinuje. Postalo je jasno da je vrijeme da napravimo vlastiti proizvod.
Nastavak rada na vašem sistemu za praćenje
Bilo je jasno da je sistem koji je ranije napisan potpuno neprikladan za sadašnje zadatke. Ni po funkcionalnosti ni po kvaliteti. I odlučeno je da se sistem napiše od nule. Grafički je trebalo izgledati potpuno drugačije. Morao je biti hijerarhijski sistem da bi bilo moguće brzo i povoljno otvoriti pravi objekat za pravog klijenta. Šema kao u prvoj verziji apsolutno nije bila opravdana u trenutnom slučaju, jer Klijenti su različiti i uopšte nije bilo važno u kojim prostorijama se nalazi oprema. Ovo je već prebačeno u dokumentaciju.
Dakle, zadaci:
- Hijerarhijska struktura;
- Neka vrsta serverskog dijela koji se može postaviti u prostorije klijenta u vidu virtuelne mašine za prikupljanje metrike koja nam je potrebna i slanje na centralni server, koji će sve to sumirati i pokazati nam;
- Alerts. One koje se ne mogu propustiti, jer... u to vrijeme nije bilo moguće da neko sjedi i samo gleda u monitor;
- Sistem aplikacija. Počeli su se pojavljivati klijenti za koje smo servisirali ne samo serversku i mrežnu opremu, već i radne stanice;
- Mogućnost brzog povezivanja sa serverima i opremom iz sistema;
Zadaci su postavljeni, počinjemo pisati. Usput, obrada zahtjeva klijenata. Tada nas je već bilo 4. Počeli smo pisati oba dijela odjednom: centralni server i server za instalaciju klijentima. Do ovog trenutka, Linux nam više nije bio stranac i odlučeno je da virtualne mašine koje će klijenti imati budu na Debianu. Neće biti instalatera, samo ćemo napraviti projekat serverskog dela na jednoj određenoj virtuelnoj mašini, a onda ćemo ga samo klonirati na željenog klijenta. Ovo je bila još jedna greška. Kasnije je postalo jasno da je u takvoj šemi mehanizam ažuriranja potpuno nerazvijen. One. dodavali smo neku novu funkciju, a onda je nastao cijeli problem distribucije na sve klijentske servere, ali na to ćemo se vratiti kasnije, sve po redu.
Napravili smo prvi prototip. Bio je u mogućnosti da pinguje klijentske mrežne uređaje i servere koji su nam bili potrebni i pošalje ove podatke na naš centralni server. A on je, zauzvrat, ažurirao ove podatke na veliko na centralnom serveru. Ovdje ću napisati ne samo priču o tome kako i šta je bilo uspješno, već i koje su amaterske greške napravljene i kako sam kasnije to morao platiti vremenom. Dakle, cijelo stablo objekata je pohranjeno u jednu datoteku u obliku serijaliziranog objekta. Dok smo na sistem povezivali nekoliko klijenata, sve je bilo manje-više normalno, iako je ponekad bilo nekih artefakata koji su bili potpuno nerazumljivi. Ali kada smo na sistem povezali desetak servera, počela su se dešavati čuda. Ponekad, iz nekog nepoznatog razloga, svi objekti u sistemu jednostavno nestanu. Ovdje je važno napomenuti da su serveri kojima su klijenti slali podatke centralnom serveru svakih nekoliko sekundi putem POST zahtjeva. Pažljivi čitalac i iskusni programer već su pretpostavili da postoji problem višestrukog pristupa samoj datoteci u kojoj je serijalizovani objekat pohranjen iz različitih niti istovremeno. I baš kada se to dešavalo, dešavala su se čuda sa nestankom objekata. Fajl je jednostavno postao prazan. Ali sve to nije otkriveno odmah, već samo tokom rada sa nekoliko servera. Za to vrijeme dodana je funkcionalnost skeniranja portova (serveri su slali centrali ne samo informacije o dostupnosti uređaja, već i o otvorenim portovima na njima). Ovo je urađeno pozivanjem komande:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
rezultati su često bili netačni i skeniranje je trajalo dugo da se završi. Potpuno sam zaboravio na ping, radilo se preko fpinga:
system("fping -r 3 -t 100 {$this->ip}");
To također nije bilo paralelno i stoga je proces bio veoma dug. Kasnije je cijela lista IP adresa potrebnih za verifikaciju odjednom poslata fpingu, a nazad smo dobili gotovu listu onih koji su odgovorili. Za razliku od nas, fping je bio u stanju da paralelizira procese.
Još jedan uobičajeni rutinski posao bilo je postavljanje nekih usluga putem WEB-a. Pa, na primjer, ECP iz MS Exchange-a. U suštini to je samo veza. I odlučili smo da moramo biti u mogućnosti da dodamo takve linkove direktno u sistem, kako ne bismo morali tražiti u dokumentaciji ili negdje drugdje u bookmarkovima kako pristupiti ECP-u određenog klijenta. Tako se pojavio koncept linkova resursa za sistem, njihova funkcionalnost je dostupna do danas i nije se promijenila, pa, skoro.
Kako veze resursa rade u Veliamu
Udaljene veze
Ovako to izgleda u akciji u trenutnoj verziji Veliama
Jedan od zadataka je bio brzo i praktično povezivanje sa serverima, kojih je već bilo mnogo (više od sto), a sortiranje kroz milione unapred sačuvanih RDP prečica je bilo izuzetno nezgodno. Bio je potreban alat. Na internetu postoji softver koji je nešto poput adresara za takve RDP veze, ali oni nisu integrisani sa sistemom za praćenje, a nalozi se ne mogu sačuvati. Svaki put unositi račune za različite klijente je pravi pakao kada se povežete na desetine puta dnevno na različite servere. Sa SSH-om stvari su malo bolje; postoji mnogo dobrog softvera koji vam omogućava da organizirate takve veze u foldere i zapamtite račune iz njih. Ali postoje 2 problema. Prvi je da nismo pronašli niti jedan program za RDP i SSH konekciju. Drugo je da ako u nekom trenutku nisam za kompjuterom i trebam brzo da se povežem, ili sam samo ponovo instalirao sistem, moraću da uđem u dokumentaciju da pogledam nalog sa ovog klijenta. To je nezgodno i gubljenje vremena.
Hijerarhijska struktura koja nam je bila potrebna za klijentske servere je već bila dostupna u našem internom proizvodu. Samo sam morao smisliti kako da spojim brze veze na potrebnu opremu tamo. Za početak, barem unutar vaše mreže.
Uzimajući u obzir činjenicu da je klijent u našem sistemu bio pretraživač koji nema pristup lokalnim resursima računara, da bismo jednostavno nekom komandom pokrenuli aplikaciju koja nam je bila potrebna, izmišljeno je da sve radi preko „Windows prilagođena url šema”. Tako se pojavio određeni „dodatak“ za naš sistem, koji je jednostavno uključivao Putty i Remote Desktop Plus i tokom instalacije jednostavno registrovao URI šemu u Windows-u. Sada, kada smo želeli da se povežemo sa objektom preko RDP-a ili SSH-a, kliknuli smo na ovu akciju na našem sistemu i prilagođeni URI je proradio. Pokrenut je standardni mstsc.exe ugrađen u Windows ili putty, koji je bio dio „dodatka“. Stavio sam riječ plugin pod navodnike jer ovo nije dodatak za pretraživač u klasičnom smislu.
Barem je to bilo nešto. Pogodan adresar. Štaviše, u slučaju Putty-a, generalno je sve bilo u redu, mogli su mu se dati IP konekcije, login i lozinka kao ulazni parametri. One. Već smo se povezali sa Linux serverima na našoj mreži jednim klikom bez unosa lozinki. Ali sa RDP-om to nije tako jednostavno. Standardni mstsc ne može dostaviti vjerodajnice kao parametre. Remote Desktop Plus je priskočio u pomoć. On je dozvolio da se ovo desi. Sada možemo i bez njega, ali je dugo vremena bio vjeran asistent u našem sistemu. Sa HTTP(S) sajtovima je sve jednostavno, takvi objekti se jednostavno otvaraju u pretraživaču i to je to. Zgodno i praktično. Ali ovo je bila sreća samo na internoj mreži.
Budući da smo veliku većinu problema rješavali na daljinu iz ureda, najlakše je bilo učiniti VPN-ove dostupnim klijentima. I tada je bilo moguće povezati se s njima iz našeg sistema. Ali i dalje je bilo pomalo nezgodno. Za svakog klijenta bilo je potrebno zadržati gomilu zapamćenih VPN veza na svakom računalu, a prije povezivanja na bilo koji, bilo je potrebno omogućiti odgovarajući VPN. Ovo rješenje smo koristili dosta dugo. Ali broj klijenata se povećava, povećava se i broj VPN-ova, a sve je to počelo naprezati i trebalo je nešto poduzeti po tom pitanju. Suze su mi posebno navrle nakon ponovne instalacije sistema, kada sam morao ponovo da unesem desetine VPN konekcija u novom Windows profilu. Prestani da trpiš ovo, rekao sam, i počeo da razmišljam šta bih mogao da uradim povodom toga.
Tako se dogodilo da su svi klijenti kao rutere imali uređaje poznate kompanije Mikrotik. Vrlo su funkcionalni i praktični za obavljanje gotovo svih zadataka. Nedostatak je što su „oteti“. Ovaj problem smo riješili jednostavno tako što smo zatvorili sav pristup izvana. Ali bilo je potrebno nekako doći do njih bez dolaska kod klijenta, jer... dugo je. Jednostavno smo za svaki takav Mikrotik napravili tunele i odvojili ih u poseban bazen. bez ikakvog rutiranja, tako da nema veze vaše mreže sa mrežama klijenata i njihovih mreža međusobno.
Rodila se ideja da se, kada kliknem na objekat koji mi je potreban u sistemu, centralni server za praćenje, znajući SSH naloge svih klijenata Mikrotik, poveže sa željenim, kreira pravilo prosleđivanja do željenog hosta sa potreban port. Ovdje postoji nekoliko tačaka. Rješenje nije univerzalno - radit će samo za Mikrotik, budući da je sintaksa naredbi različita za sve rutere. Također, takva prosljeđivanja su se tada morala nekako izbrisati, a serverski dio našeg sistema u suštini nije mogao ni na koji način pratiti da li sam završio svoju RDP sesiju. Pa takvo prosljeđivanje je rupa za klijenta. Ali nismo težili univerzalnosti, jer... proizvod se koristio samo u našoj kompaniji i nije bilo razmišljanja o puštanju u javnost.
Svaki od problema je riješen na svoj način. Kada je pravilo kreirano, ovo prosljeđivanje je bilo dostupno samo za jednu specifičnu vanjsku IP adresu (sa koje je veza inicijalizirana). Tako je izbjegnuta sigurnosna rupa. Ali sa svakom takvom vezom, Mikrotik pravilo je dodano na NAT stranicu i nije obrisano. I svi znaju da što je više pravila, to je više opterećen procesor rutera. I generalno, nisam mogao prihvatiti da ću jednog dana otići u neki Mikrotik, a tamo će postojati stotine mrtvih, beskorisnih pravila.
Budući da naš server ne može pratiti status veze, neka ih Mikrotik sam prati. I napisao sam skriptu koja je stalno pratila sva pravila prosljeđivanja sa određenim opisom i provjeravala da li TCP veza ima odgovarajuće pravilo. Ako ga nije bilo neko vrijeme, onda je veza vjerovatno već završena i ovo prosljeđivanje se može izbrisati. Sve je ispalo, scenario je dobro funkcionisao.
Usput, evo ga:
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
}
}
Moglo se sigurno napraviti ljepšim, bržim itd., ali radilo je, nije opteretilo Mikrotik i odradilo odličan posao. Konačno smo se mogli povezati na klijentove servere i mrežnu opremu samo jednim klikom. Bez otvaranja VPN-a ili unosa lozinki. Sistem je postao zaista zgodan za rad. Vrijeme servisiranja je smanjeno, a svi smo provodili vrijeme radeći umjesto povezivanja na potrebne objekte.
Mikrotik Backup
Konfigurisali smo backup svih Mikrotik na FTP. I generalno sve je bilo u redu. Ali kada je trebalo da dobijete rezervnu kopiju, morali ste da otvorite ovaj FTP i da ga tamo potražite. Imamo sistem u kojem su svi ruteri povezani, možemo komunicirati sa uređajima preko SSH-a. Zašto ne bismo napravili tako da sam sistem svakodnevno preuzima sigurnosne kopije od cijelog Mikrotika, pomislio sam. I počeo je da ga sprovodi. Povezali smo se, napravili rezervnu kopiju i odnijeli u skladište.
Kod skripte u PHP-u za pravljenje rezervne kopije sa Mikrotika:
<?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');
?>
Sigurnosna kopija se uzima u dva oblika - binarnoj i tekstualnoj konfiguraciji. Binarna datoteka pomaže da se brzo vrati potrebna konfiguracija, a tekstualna vam omogućava da shvatite šta treba učiniti ako dođe do prisilne zamjene opreme i binarni fajl se ne može učitati u njega. Kao rezultat toga, dobili smo još jednu zgodnu funkcionalnost u sistemu. Štaviše, prilikom dodavanja novog Mikrotika nije bilo potrebe ništa da konfigurišem, jednostavno sam dodao objekat u sistem i postavio nalog za njega preko SSH-a. Zatim se sam sistem pobrinuo za pravljenje rezervnih kopija. Trenutna verzija SaaS Veliam još uvijek nema ovu funkcionalnost, ali ćemo je uskoro portirati.
Snimke ekrana kako je to izgledalo u internom sistemu
Prelazak na normalno skladištenje baze podataka
Već sam gore napisao da su se pojavili artefakti. Ponekad je cijela lista objekata u sistemu jednostavno nestala, ponekad prilikom uređivanja objekta informacija nije bila sačuvana i objekt je morao biti tri puta preimenovan. Sve je to strašno iznerviralo. Nestanak objekata se dešavao retko i lako se vraćao vraćanjem ovog fajla, ali su se kvarovi prilikom uređivanja objekata dešavali prilično često. Vjerovatno to u početku nisam radio preko baze podataka jer mi nije stalo na pamet kako je moguće držati stablo sa svim vezama u ravnoj tablici. Ravan je, ali je drvo hijerarhijsko. Ali dobro rješenje za višestruki pristup, a potom (kako sistem postaje složeniji) transakcijski, je DBMS. Verovatno nisam prvi koji se susreo sa ovim problemom. Počeo sam da guglam. Ispostavilo se da je sve već bilo izmišljeno prije mene i da postoji nekoliko algoritama koji grade drvo od ravnog stola. Nakon što sam pogledao svaki, implementirao sam jedan od njih. Ali ovo je već bila nova verzija sistema, jer... Zapravo, zbog toga sam morao dosta toga da prepisujem. Rezultat je bio prirodan, problemi nasumičnog ponašanja sistema su nestali. Neki bi mogli reći da su greške vrlo amaterske (jednonitne skripte, pohranjivanje informacija kojima se pristupalo više puta istovremeno iz različitih niti u datoteci, itd.) u polju razvoja softvera. Možda je to i istina, ali moj glavni posao je bila administracija, a programiranje mi je bila sporedna gužva za dušu i jednostavno nisam imao iskustva u radu u timu programera, gdje bi mi takve osnovne stvari odmah sugerirao moj stariji drugovi. Stoga sam sve te neravnine sam popunio, ali sam jako dobro naučio gradivo. Takođe, moj posao uključuje sastanke sa klijentima, akcije u cilju promocije kompanije, gomilu administrativnih pitanja unutar kompanije i još mnogo, mnogo više. Ali, na ovaj ili onaj način, tražilo se ono što je već postojalo. Dečki i ja koristili smo proizvod u svakodnevnom radu. Bilo je iskreno neuspješnih ideja i rješenja na koja je izgubljeno vrijeme, ali je na kraju postalo jasno da to nije radni alat i niko ga nije koristio i nije završio u Veliamu.
Helpdesk - HelpDesk
Ne bi bilo loše spomenuti kako je HelpDesk formiran. Ovo je sasvim druga priča, jer... u Veliamu je ovo već treća potpuno nova verzija, koja se razlikuje od svih prethodnih. Sada je to jednostavan sistem, intuitivan bez nepotrebnih zvona i zvižduka, sa mogućnošću integracije sa domenom, kao i mogućnošću pristupa istom korisničkom profilu sa bilo kog mesta koristeći link iz e-pošte. I što je najvažnije, moguće je povezati se s aplikantom putem VNC-a s bilo kojeg mjesta (kod kuće ili u uredu) direktno iz aplikacije bez VPN-a ili prosljeđivanja portova. Reći ću vam kako smo došli do ovoga, šta se dešavalo ranije i koje su strašne odluke donete.
Povezali smo se sa korisnicima preko dobro poznatog TeamViewera. Svi računari čije korisnike opslužujemo imaju instaliran TV. Prva stvar koju smo pogriješili, a potom i uklonili, bilo je povezivanje svakog HD klijenta sa hardverom. Kako se korisnik prijavio na HD sistem da bi ostavio zahtjev? Pored TV-a, svi su imali instaliran poseban uslužni program na svojim računarima, napisan na Lazarusu (mnogi ljudi ovdje će prevrnuti očima, pa možda čak i guglati šta je to, ali najbolji kompajlirani jezik koji sam znao je Delphi, a Lazarus je skoro ista stvar, samo besplatna). Općenito, korisnik je pokrenuo posebnu batch datoteku koja je pokrenula ovaj uslužni program, koji je zauzvrat pročitao HWID sistema i nakon toga je pokrenut pretraživač i došlo je do autorizacije. Zašto je to urađeno? U nekim kompanijama broj servisiranih korisnika se računa pojedinačno, a cijena usluge za svaki mjesec se zasniva na broju ljudi. To je razumljivo, kažete, ali zašto je to vezano za hardver? Vrlo je jednostavno, neki pojedinci su dolazili kući i sa svog kućnog laptopa uputili zahtjev u stilu „uljepšajte mi sve ovdje“. Osim čitanja sistemskog HWID-a, uslužni program je povukao trenutni Teamviewer ID iz registra i također nam ga prenio. Teamviewer ima API za integraciju. I mi smo uradili ovu integraciju. Ali postojala je jedna kvaka. Preko ovih API-ja nemoguće je povezati se sa računarom korisnika kada on eksplicitno ne inicira ovu sesiju i nakon pokušaja da se poveže sa njom, takođe mora da klikne „potvrdi“. Tada nam se činilo logičnim da se niko ne povezuje bez zahtjeva korisnika, a pošto je osoba za računarom, ona će pokrenuti sesiju i odgovoriti potvrdno na zahtjev za daljinsko povezivanje. Sve je ispalo po zlu. Podnosioci zahteva su zaboravili da pritisnu da započnu sednicu i morali su da im to kažu u telefonskom razgovoru. Ovo je izgubljeno vrijeme i bilo je frustrirajuće na obje strane procesa. Štaviše, nisu nimalo neuobičajeni takvi trenuci kada osoba ostavi zahtjev, ali joj je dozvoljeno da se poveže tek kada ode na ručak. Jer problem nije kritičan i ne želi da mu se prekida radni proces. Shodno tome, on neće pritisnuti nijedno dugme da bi omogućio vezu. Ovako se pojavila dodatna funkcionalnost prilikom prijavljivanja na HelpDesk - čitanje Teamviwer ID-a. Znali smo trajnu lozinku koja se koristila prilikom instaliranja Teamviwera. Tačnije, samo sistem je to znao, jer je ugrađen u instalater i u naš sistem. Shodno tome, postojalo je dugme za povezivanje iz aplikacije klikom na koje nije trebalo ništa čekati, ali se Teamviewer odmah otvorio i došlo je do konekcije. Kao rezultat, postojale su dvije vrste mogućih veza. Preko zvaničnog Teamviewer API-ja i našeg samo-napravljenog API-ja. Na moje iznenađenje, prvu su gotovo odmah prestali koristiti, iako je postojalo uputstvo da se koristi samo u posebnim slučajevima i kada sam korisnik da zeleno svjetlo. Ipak, daj mi sigurnost sada. Ali ispostavilo se da podnosiocima predstavke ovo nije bilo potrebno. Svi su potpuno u redu sa povezivanjem na njih bez dugmeta za potvrdu.
Prelazak na multithreading u Linuxu
Pitanje ubrzavanja prolaska mrežnog skenera radi otvorenosti unaprijed određene liste portova i jednostavnog pingovanja mrežnih objekata odavno se počelo postavljati. Ovdje, naravno, prvo rješenje koje vam pada na pamet je multithreading. Pošto je glavno vrijeme provedeno na pingu čekanje da se paket vrati, a sljedeći ping ne može početi dok se ne vrati prethodni paket, u kompanijama koje su imale čak 20+ servera plus mrežnu opremu, to je već funkcionisalo prilično sporo. Poenta je da jedan paket može nestati, ali nemojte odmah o tome obavijestiti administratora sistema. Jednostavno će vrlo brzo prestati da prihvata takvu neželjenu poštu. To znači da morate pingovati svaki objekat više puta prije nego što donesete zaključak o nepristupačnosti. Ne ulazeći previše u detalje, potrebno je to paralelizirati jer ako se to ne uradi, onda će najvjerovatnije sistem administrator saznati za problem od klijenta, a ne od nadzornog sistema.
PHP sam po sebi ne podržava multithreading iz kutije. Sposoban za višestruku obradu, možete se račvati. Ali, u stvari, već sam imao napisan mehanizam prozivanja i htio sam to napraviti tako da jednom prebrojim sve čvorove koji su mi potrebni iz baze podataka, pingujem sve odjednom, čekam odgovor od svakog i tek nakon toga odmah napišem podatke. Ovo štedi na broju zahtjeva za čitanje. Multithreading se savršeno uklapa u ovu ideju. Za PHP postoji PThreads modul koji vam omogućava da radite stvarno višenitnost, iako je bilo potrebno dosta petljanja da se ovo podesi na PHP 7.2, ali je urađeno. Skeniranje portova i ping su sada brzi. I umjesto, na primjer, 15 sekundi po krugu ranije, ovaj proces je počeo da traje 2 sekunde. Bio je to dobar rezultat.
Brza revizija novih kompanija
Kako je nastala funkcionalnost za prikupljanje različitih metrika i hardverskih karakteristika? To je jednostavno. Ponekad nam je jednostavno naređeno da izvršimo reviziju postojeće IT infrastrukture. Pa, ista stvar je neophodna da bi se ubrzala revizija novog klijenta. Trebalo nam je nešto što bi nam omogućilo da dođemo u srednju ili veliku kompaniju i brzo shvatimo šta oni imaju. Po mom mišljenju, ping na internoj mreži blokiraju samo oni koji žele sebi zakomplicirati život, a prema našem iskustvu takvih je malo. Ali ima i takvih ljudi. U skladu s tim, možete brzo skenirati mreže za prisustvo uređaja jednostavnim pingom. Zatim ih možemo dodati i skenirati otvorene portove koji nas zanimaju. Zapravo, ova funkcionalnost je već postojala, bilo je potrebno samo dodati komandu sa centralnog servera na slave kako bi skenirao navedene mreže i dodao sve što nađe na listu. Zaboravio sam da napomenem, pretpostavljalo se da već imamo gotovu sliku sa konfigurisanim sistemom (slave monitoring server) koju možemo jednostavno izbaciti iz klijenta tokom revizije i povezati je sa našim oblakom.
Ali rezultat revizije obično uključuje gomilu različitih informacija, a jedna od njih je kakvi su uređaji na mreži. Prije svega, zanimali su nas Windows serveri i Windows radne stanice kao dio domene. Budući da je u srednjim i velikim kompanijama nedostatak domene vjerovatno izuzetak od pravila. Da govorim jedan jezik, prosek je, po mom mišljenju, 100+ ljudi. Bilo je potrebno smisliti način prikupljanja podataka sa svih Windows mašina i servera, znajući njihov IP i nalog administratora domene, ali bez instaliranja bilo kakvog softvera na svakom od njih. WMI interfejs dolazi u pomoć. Windows Management Instrumentation (WMI) doslovno znači Windows alati za upravljanje. WMI je jedna od osnovnih tehnologija za centralizovano upravljanje i praćenje rada različitih delova računarske infrastrukture na Windows platformi. Preuzeto sa wikija. Zatim sam morao ponovo da petljam kako bih kompajlirao wmic (ovo je WMI klijent) za Debian. Nakon što je sve bilo spremno, sve što je preostalo bilo je jednostavno anketiranje potrebnih čvorova preko wmic-a za potrebne informacije. Preko WMI-ja možete dobiti skoro sve informacije sa Windows računara, a štaviše, preko njega možete i kontrolisati računar, na primer, poslati ga na ponovno pokretanje. Tako je nastala zbirka informacija o Windows stanicama i serverima u našem sistemu. Pored toga, postojale su i trenutne informacije o trenutnim indikatorima opterećenja sistema. Tražimo ih češće, a informacije o hardveru rjeđe. Nakon toga, revizija je postala malo ugodnija.
Odluka o distribuciji softvera
I sami koristimo sistem svaki dan, a on je uvijek otvoren za svakog tehničkog djelatnika. I mislili smo da možemo podijeliti s drugima ono što već imamo. Sistem još nije bio spreman za distribuciju. Mnogo toga je trebalo preraditi kako bi se lokalna verzija pretvorila u SaaS. To uključuje promjene u različitim tehničkim aspektima sistema (daljinske veze, usluga podrške), analizu modula za licenciranje, dijeljenje korisničkih baza podataka, skaliranje svake usluge i razvoj sistema za automatsko ažuriranje za sve dijelove. Ali ovo će biti drugi dio članka.
Ažuriranje
izvor: www.habr.com