Pozdrav svima, moje ime je Sergey Emelyanchik. Voditelj sam tvrtke Audit-Telecom, glavni programer i autor sustava Veliam. Odlučio sam napisati članak o tome kako smo moj prijatelj i ja stvorili tvrtku za outsourcing, napisali softver za sebe i potom ga počeli distribuirati svima putem SaaS sustava. 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 proizvod Veliam nastao. Uključujući neke dijelove izvornog koda. Kasnije ću vam reći koje smo pogreške napravili i kako smo ih ispravili. Bilo je dvojbi treba li objaviti takav članak. Ali mislio sam da je bolje to učiniti, dobiti povratne informacije i poboljšati se, nego ne objaviti članak i razmisliti što bi se dogodilo da...
prapovijest
Radio sam u jednoj firmi kao informatičar. Tvrtka je bila prilično velika s razgranatom mrežnom strukturom. Neću duljiti o svojim radnim obvezama, samo ću reći da one definitivno nisu uključivale razvoj bilo čega.
Imali smo praćenje, 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 klijenata i vidjeti što se događa s mrežom s bilo kojeg uređaja, uključujući mobilni uređaj putem Wi-Fi-ja, a također sam stvarno Htio je brzo shvatiti što U sobi postoji oprema koja je postala "mukljava" jer... postojali su vrlo strogi zahtjevi za vrijeme odgovora na takve probleme. Kao rezultat toga, u mojoj se glavi rodio plan da napišem jednostavnu web stranicu na kojoj je jpeg pozadina s mrežnim dijagramom, izrežem same uređaje s njihovim IP adresama na ovoj slici i prikažem dinamički sadržaj na vrhu sliku u traženim koordinatama u obliku zelene ili trepćuće crvene IP adrese. Zadatak je postavljen, krenimo.
Prethodno sam programirao u Delphiju, PHP-u, JS-u i vrlo površno C++. Vrlo dobro znam kako mreže funkcioniraju. VLAN, usmjeravanje (OSPF, EIGRP, BGP), NAT. To mi je bilo dovoljno da sam napišem primitivni prototip nadzora.
Napisao sam ono što sam planirao u PHP-u. Apache i PHP poslužitelj bili su na Windowsima 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 Linux je puno jednostavniji od Windowsa, ali to je posebna tema, a svi znamo koliko holivara ima na ova tema. Windows planer zadataka je u malim intervalima (ne sjećam se točno, ali otprilike jednom svake tri sekunde) izvlačio PHP skriptu koja je ispitivala sve objekte banalnim pingom i spremala stanje u datoteku.
system(“ping -n 3 -w 100 {$ip_address}“);
Da, da, rad s bazom podataka u tom trenutku također nisam savladao. Nisam znao da je moguće paralelizirati procese, a prolazak kroz sve mrežne čvorove je dugo trajao, jer... ovo se dogodilo u jednoj temi. Problemi su se posebno javljali 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 s poslužitelja s Ajax zahtjevom i ažurirala sučelje. Pa, onda, nakon 3 neuspješna pinganja zaredom, ako je na računalu bila otvorena web stranica s nadzorom, svirala je vesela kompozicija.
Kad je sve uspjelo, bio sam vrlo inspiriran rezultatom i mislio sam da mogu dodati još više (s obzirom na svoje znanje i mogućnosti). Ali uvijek mi se nisu sviđali sustavi s milijunskim grafikonima, za koje sam tada, a i dan danas smatram, u većini slučajeva nepotrebni. Želio sam staviti samo ono što bi mi stvarno pomoglo u mom radu. Ovo načelo ostaje temeljno za razvoj Veliama do danas. Nadalje, shvatio sam da bi bilo jako cool da ne moram držati otvoren nadzor i znati za probleme, a kada se to dogodi, onda otvorim stranicu i vidim gdje se nalazi taj problematični mrežni čvor i što dalje s njim . Tada nekako nisam čitao e-poštu, jednostavno je nisam koristio. Naišao sam na internetu da postoje SMS gatewayi na koje možete poslati GET ili POST zahtjev, a oni će mi poslati SMS na mobitel s tekstom koji napišem. Odmah sam shvatio da ovo stvarno želim. I počeo sam proučavati dokumentaciju. Nakon nekog vremena sam uspio, a sada sam dobio SMS o problemima na mreži na mobitelu s nazivom “palog predmeta”. Iako je sustav bio primitivan, napisao sam ga sam, a najvažnije što me motiviralo da ga razvijem je to što je to bio aplikativni program koji mi je stvarno pomogao u radu.
A onda je došao dan kada je jedan od internetskih kanala pao na poslu, a moje praćenje me nije obavijestilo o tome. Budući da je Google DNS i dalje savršeno pingao. Vrijeme je da razmislite o tome kako možete pratiti da li je komunikacijski kanal živ. Bilo je različitih ideja kako to učiniti. Nisam imao pristup svoj opremi. Morali smo smisliti kako razumjeti koji je od kanala 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 poslužitelja 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 trasiranja.
system(“tracert -d -w 500 8.8.8.8”);
Tako se pojavila još jedna skripta, odnosno iz nekog razloga trag je dodan na kraj iste skripte, koja je pingala sve uređaje na mreži. Uostalom, radi se o još jednom dugom procesu koji se izvodio u istom threadu i usporavao rad cijele skripte. Ali tada to nije bilo tako očito. Ali na ovaj ili onaj način, on je obavio svoj posao, kodeks je strogo definirao kakvo bi praćenje trebalo biti za svaki od kanala. Tako je počeo raditi sustav koji je već pratio (glasno rečeno, jer nije bilo skupljanja nikakve metrike, nego samo ping) mrežne uređaje (routere, switcheve, wi-fi itd.) i komunikacijske kanale s vanjskim svijetom. . SMS poruke su stizale redovito i dijagram je uvijek jasno pokazivao gdje je problem.
Nadalje, u svakodnevnom radu morao sam raditi križanje. I dosadilo mi je svaki put ići do Cisco preklopnika da vidim koje sučelje koristiti. Kako bi bilo cool kliknuti na objekt u nadzoru i vidjeti popis njegovih sučelja s opisima. Uštedjelo bi mi vrijeme. Štoviše, u ovoj shemi ne bi bilo potrebe pokretati Putty ili SecureCRT za unos računa i naredbi. Samo sam kliknuo na monitoring, vidio što treba i otišao raditi svoj posao. Počeo sam tražiti načine za interakciju s prekidačima. Odmah sam naišao na 2 opcije: SNMP ili prijava na switch preko SSH-a, unos naredbi koje su mi trebale i parsiranje rezultata. Odbacio sam SNMP zbog složenosti njegove implementacije; bio sam nestrpljiv da dobijem rezultat. sa SNMP-om bi morali dugo kopati po MIB-u i na temelju tih podataka generirati podatke o sučeljima. U CISCO-u postoji prekrasan tim
show interface statusPokazuje točno ono što mi treba za križanje. Zašto se gnjaviti sa SNMP-om kada samo želim vidjeti izlaz ove naredbe, pomislio sam. Nakon nekog vremena shvatio sam ovu priliku. Kliknuo na objekt na web stranici. Pokrenuo se događaj kojim je AJAX klijent kontaktirao poslužitelj, a on se zauzvrat povezao preko SSH-a na preklopnik koji mi je trebao (vjerodajnice su bile tvrdo kodirane u kodu, nije bilo želje da ga dorađujem, da pravim neke zasebne izbornike gdje bilo bi moguće promijeniti račune iz sučelja, trebao sam rezultat i to brzo) tamo sam unio gornju naredbu i poslao je natrag u preglednik. Tako sam počeo vidjeti informacije o sučeljima jednim klikom miša. Ovo je bilo izuzetno zgodno, pogotovo kada ste te podatke morali vidjeti na različitim prekidačima odjednom.
Praćenje kanala na temelju praćenja na kraju nije bila najbolja ideja, jer... ponekad se radilo na mreži, a praćenje se moglo promijeniti i nadzor je počeo vrištati na mene da postoje problemi s kanalom. Ali nakon dosta vremena provedenog na analizi, shvatio sam da svi kanali rade, a 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 promijeni status vidljivosti susjeda. Sukladno tome, bilo je puno jednostavnije, brže i točnije od trasiranja. Stigao je događaj kao što je susjed izgubljen i odmah izdajem obavijest o padu kanala.
Nadalje, pojavilo se još nekoliko naredbi prilikom klika na objekt, a dodan je i SNMP za prikupljanje nekih metrika, i to je u biti to. Sustav se nikada nije dalje razvijao. Radio je sve što sam trebao, bio je dobar alat. Mnogi će mi čitatelji vjerojatno reći da na internetu već postoji mnogo softvera za rješavanje ovih problema. Ali zapravo, tada nisam guglao takve besplatne proizvode i stvarno sam želio razviti svoje programerske vještine, a postoji li bolji način za to od stvarnog problema s aplikacijom. U ovom trenutku je prva verzija praćenja završena i više nije mijenjana.
Osnivanje tvrtke Audit-Telecom
Kako je vrijeme prolazilo, počeo sam honorarno raditi u drugim tvrtkama, srećom, raspored rada mi je to dozvoljavao. Kada radite u različitim tvrtkama, vaše vještine u raznim područjima rastu vrlo brzo, a vaši horizonti se dobro razvijaju. Ima firmi u kojima si, kako kažu, i Šveđanin, i kosac, i trubač. S jedne strane je teško, s druge strane, ako nisi lijen, postaješ generalist i to ti omogućuje brže i učinkovitije rješavanje problema jer znaš kako to područje funkcionira.
Moj prijatelj Pavel (također informatičar) neprestano me pokušavao potaknuti da pokrenem vlastiti posao. Bilo je bezbroj ideja s različitim varijacijama onoga što su radili. O tome se raspravlja godinama. I na kraju nije trebalo biti ništa jer ja sam skeptik, a Pavel je sanjar. Svaki put kad bi predložio neku ideju, uvijek nisam vjerovao u nju i odbijao sudjelovati. Ali jako smo željeli otvoriti vlastiti obrt.
Napokon smo uspjeli pronaći opciju koja nam oboma odgovara i raditi ono što znamo. U 2016. godini odlučili smo napraviti IT tvrtku koja će pomagati poduzećima u rješavanju IT problema. To je implementacija IT sustava (1C, terminal server, mail server itd.), njihovo održavanje, klasični HelpDesk za korisnike i mrežna administracija.
Iskreno govoreći, u vrijeme stvaranja tvrtke 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 ubacili smo po 300 rubalja svaki, registrirali novo LLC preduzeće "Audit-Telecom", iznajmili maleni ured, napravili cool posjetnice, pa, općenito, kao vjerojatno većina neiskusnih poslovnih ljudi početnika, i počeli tražiti klijente. Pronalaženje klijenata je sasvim druga priča. Možda ćemo napisati poseban članak kao dio korporativnog bloga ako netko bude zainteresiran. Hladni pozivi, letci itd. To nije dalo nikakve rezultate. Kako sada čitam iz mnogih priča o poslu, na ovaj ili onaj način, puno ovisi o sreći. Imali smo sreće. i doslovno nekoliko tjedana nakon osnivanja tvrtke, obratio nam se moj brat Vladimir koji nam je doveo prvog klijenta. Neću vas zamarati detaljima rada s klijentima, nije o tome članak, samo ću reći da smo išli u reviziju, identificirali kritična područja i ta područja su se pokvarila dok se odlučivalo hoće li surađuju s nama na trajnoj osnovi kao vanjski suradnici. Nakon toga je odmah donesena pozitivna odluka.
Zatim su se, uglavnom usmenom predajom preko prijatelja, počele pojavljivati druge uslužne tvrtke. Helpdesk je bio u jednom sustavu. Veze s mrežnom opremom i poslužiteljima su različite, bolje rečeno drugačije. Neki su ljudi spremili prečace, drugi su koristili RDP adresare. Monitoring je još jedan zasebni sustav. Vrlo je nezgodno za tim raditi u različitim sustavima. Važne informacije su izgubljene iz vida. Pa, na primjer, terminalski poslužitelj klijenta postao je nedostupan. Prijave korisnika ovog klijenta primaju se odmah. Stručnjak za podršku otvara zahtjev (primljen je telefonom). Ako bi se incidenti i zahtjevi registrirali u jednom sustavu, tada bi stručnjak za podršku odmah vidio koji je problem korisnika i rekao mu o tome, dok bi se istovremeno povezivao sa traženim objektom kako bi riješio situaciju. Svi su svjesni taktičke situacije i djeluju složno. Nismo pronašli sustav gdje se sve to kombinira. Postalo je jasno da je vrijeme da napravimo vlastiti proizvod.
Nastavak rada na vašem sustavu nadzora
Bilo je jasno da je ranije napisani sustav potpuno neprikladan za sadašnje zadatke. Ni po funkcionalnosti ni po kvaliteti. I odlučeno je napisati sustav od nule. Grafički je trebao izgledati potpuno drugačije. To je morao biti hijerarhijski sustav kako bi bilo moguće brzo i povoljno otvoriti pravi objekt za pravog klijenta. Shema kao u prvoj verziji apsolutno nije bila opravdana u trenutnom slučaju, jer Klijenti su različiti i uopće nije bilo važno u kojem se prostoru oprema nalazi. To je već prebačeno u dokumentaciju.
Dakle, zadaci:
- Hijerarhijska struktura;
- Neka vrsta poslužiteljskog dijela koji se može smjestiti kod klijenta u obliku virtualnog stroja za prikupljanje potrebnih metrika i slanje na središnji poslužitelj koji će sve to sažeti i pokazati nam;
- upozorenja. One koje se ne propuštaju, jer... u to vrijeme nije bilo moguće da netko sjedi i samo gleda u monitor;
- Sustav primjene. Počeli su se javljati klijenti za koje smo servisirali ne samo serversku i mrežnu opremu, već i radne stanice;
- Mogućnost brzog spajanja na servere i opremu iz sustava;
Zadaci su postavljeni, počinjemo pisati. Usput, obrada zahtjeva klijenata. Tada nas je već bilo 4. Počeli smo pisati oba dijela odjednom: središnji poslužitelj i poslužitelj za instalaciju klijentima. Do tog trenutka Linux nam više nije bio stranac i odlučeno je da će virtualni strojevi koje će klijenti imati biti na Debianu. Neće biti instalatera, samo ćemo napraviti serverski dio projekta na jednom konkretnom virtualnom računalu, a onda ćemo ga samo klonirati na željenog klijenta. Ovo je bila još jedna greška. Kasnije je postalo jasno da je u takvoj shemi mehanizam ažuriranja potpuno nerazvijen. Oni. dodavali smo neku novu značajku, a onda se pojavio cijeli problem distribucije na sve klijentske poslužitelje, ali vratit ćemo se na ovo kasnije, svemu po redu.
Napravili smo prvi prototip. Uspio je pingati klijentske mrežne uređaje i poslužitelje koji su nam bili potrebni i poslati te podatke našem središnjem poslužitelju. A on je zauzvrat ažurirao ove podatke u skupu na središnjem poslužitelju. Ovdje ću napisati ne samo priču o tome kako i što je bilo uspješno, nego i koje su amaterske greške napravljene i kako sam kasnije to morao platiti vremenom. Dakle, cijelo stablo objekata pohranjeno je u jednu datoteku u obliku serijaliziranog objekta. Dok smo nekoliko klijenata spajali na sustav, sve je bilo više-manje normalno, iako je ponekad bilo artefakata koji su bili potpuno nerazumljivi. Ali kada smo u sustav spojili desetak servera, počela su se događati čuda. Ponekad su iz nekog nepoznatog razloga svi objekti u sustavu jednostavno nestali. Ovdje je važno napomenuti da su poslužitelji koje su klijenti imali slali podatke središnjem poslužitelju svakih nekoliko sekundi putem POST zahtjeva. Pažljivi čitatelj i iskusni programer već su pogodili da postoji problem višestrukog pristupa samoj datoteci u kojoj je serijalizirani objekt pohranjen iz različitih niti u isto vrijeme. I baš kad se to događalo događala su se čuda s nestankom predmeta. Datoteka je jednostavno postala prazna. Ali sve to nije otkriveno odmah, već tek tijekom rada s nekoliko poslužitelja. Tijekom tog vremena dodana je funkcija skeniranja portova (poslužitelji su centrali slali ne samo informacije o dostupnosti uređaja, već i o portovima koji su na njima otvoreni). To je učinjeno pozivom naredbe:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
rezultati su često bili netočni i skeniranje je dugo trajalo. 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 jako dug. Kasnije je fpingu odjednom poslan cijeli popis IP adresa potrebnih za provjeru, a natrag smo dobili gotov popis onih koji su se javili. Za razliku od nas, fping je mogao paralelizirati procese.
Još jedan uobičajeni rutinski posao bilo je postavljanje nekih usluga putem WEB-a. Pa, na primjer, ECP iz MS Exchangea. Uglavnom to je samo poveznica. I odlučili smo da moramo moći dodati takve poveznice izravno u sustav, kako ne bismo morali tražiti u dokumentaciji ili negdje drugdje u oznakama kako pristupiti ECP-u određenog klijenta. Tako se pojavio koncept poveznica resursa za sustav, njihova funkcionalnost je dostupna do danas i nije se promijenila, pa, gotovo.
Kako veze resursa rade u Veliamu
Daljinske veze
Ovako to izgleda na djelu u trenutnoj verziji Veliama
Jedan od zadataka bio je brzo i praktično povezivanje s poslužiteljima, kojih je već bilo mnogo (više od stotinu) i sortiranje kroz milijune unaprijed spremljenih RDP prečaca bilo je izuzetno nezgodno. Bio je potreban alat. Na internetu postoji softver koji je nešto poput adresara za takve RDP veze, ali oni nisu integrirani sa sustavom za nadzor, a računi se ne mogu spremiti. Upisivanje računa za različite klijente svaki put je čisti pakao kada se na desetke puta dnevno spajate na različite servere. S SSH-om stvari stoje malo bolje; postoji mnogo dobrog softvera koji vam omogućuje organiziranje takvih veza u mape i pamćenje računa iz njih. Ali postoje 2 problema. Prvi je da nismo pronašli niti jedan program za RDP i SSH veze. Drugi je da ako u nekom trenutku nisam za svojim računalom i trebam se brzo spojiti ili sam samo ponovno instalirao sustav, morat ću ući u dokumentaciju da pogledam račun ovog klijenta. Nezgodno je i gubljenje vremena.
Hijerarhijska struktura koju smo trebali za klijentske poslužitelje već je bila dostupna u našem internom proizvodu. Samo sam morao smisliti kako spojiti brze veze na potrebnu opremu tamo. Za početak, barem unutar svoje mreže.
Uzimajući u obzir činjenicu da je klijent u našem sustavu bio preglednik koji nema pristup lokalnim resursima računala, kako bismo nekom naredbom jednostavno pokrenuli aplikaciju koja nam je potrebna, izmišljeno je da se sve radi kroz “Windows prilagođena url shema”. Tako se pojavio određeni “plugin” za naš sustav, koji je jednostavno uključio Putty i Remote Desktop Plus i tijekom instalacije jednostavno registrirao URI shemu u Windowsima. Sada, kada smo se htjeli povezati s objektom putem RDP-a ili SSH-a, kliknuli smo ovu radnju na našem sustavu i Custom URI je proradio. Pokrenut je standardni mstsc.exe ugrađen u Windows ili putty, koji je bio dio "plugina". Riječ plugin stavljam pod navodnike jer ovo nije plugin za preglednik u klasičnom smislu.
Barem je to bilo nešto. Zgodan adresar. Štoviše, u slučaju Puttyja, općenito je sve bilo u redu, mogli su mu se dati IP veze, prijava i lozinka kao ulazni parametri. Oni. Već smo se spojili na Linux poslužitelje na našoj mreži jednim klikom bez unosa lozinki. Ali s RDP-om to nije tako jednostavno. Standardni mstsc ne može dostaviti vjerodajnice kao parametre. Remote Desktop Plus priskočio je u pomoć. On je dopustio da se ovo dogodi. Sada možemo i bez njega, ali dugo je bio vjeran pomoćnik u našem sustavu. Kod HTTP(S) stranica sve je jednostavno, takvi objekti se jednostavno otvore u pregledniku i to je to. Zgodan i praktičan. 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 dostupnima klijentima. I tada se moglo na njih spojiti iz našeg sustava. Ali ipak je bilo pomalo nezgodno. Za svakog klijenta bilo je potrebno držati hrpu zapamćenih VPN veza na svakom računalu, a prije spajanja na bilo koje bilo je potrebno uključiti odgovarajući VPN. Koristili smo ovo rješenje dosta dugo. Ali broj klijenata je sve veći, broj VPN-ova također je sve veći i sve nas je to počelo opterećivati i trebalo je nešto poduzeti po tom pitanju. Posebno su mi suze krenule nakon reinstalacije sustava, kada sam morao ponovno unijeti desetke VPN veza u novi Windows profil. Prestani to trpjeti, rekla sam i počela razmišljati što bih mogla učiniti u vezi s tim.
Dogodilo se da su svi klijenti kao routere imali uređaje poznate tvrtke Mikrotik. Vrlo su funkcionalni i prikladni za obavljanje gotovo svih zadataka. Loša strana je što su "oteti". Taj smo problem jednostavno riješili zatvaranjem svih pristupa izvana. Ali bilo je potrebno nekako pristupiti njima bez dolaska kod klijenta, jer... dugačak je. Jednostavno smo za svaki takav Mikrotik napravili tunele i odvojili ih u poseban bazen. bez ikakvog usmjeravanja, tako da nema veze vaše mreže s mrežama klijenata i njihovih mreža međusobno.
Rodila se ideja da se, kada kliknem na objekt koji mi treba u sustavu, središnji nadzorni server, poznavajući SSH račune svih klijenata Mikrotika, spoji na željeni, kreira pravilo prosljeđivanja na željeni host s potrebna luka. Ovdje postoji nekoliko točaka. Rješenje nije univerzalno - radit će samo za Mikrotik, jer je sintaksa naredbi različita za sve rutere. Također, takva prosljeđivanja su tada morala biti nekako izbrisana, a poslužiteljski dio našeg sustava u biti nije mogao ni na koji način pratiti jesam li završio svoju RDP sesiju. Pa takvo prosljeđivanje je rupa za klijenta. Ali nismo težili univerzalnosti, jer... proizvod je korišten samo unutar naše tvrtke i nije bilo razmišljanja o njegovom puštanju u javnost.
Svaki od problema riješen je na svoj način. Kada je pravilo stvoreno, ovo prosljeđivanje je bilo dostupno samo za jednu određenu vanjsku IP adresu (s koje je veza inicijalizirana). Tako je izbjegnuta sigurnosna rupa. Ali sa svakom takvom vezom, Mikrotik pravilo je dodano na NAT stranicu i nije izbrisano. A svi znaju da što je više pravila, to je procesor usmjerivača više opterećen. I općenito, nisam mogao prihvatiti da ću jednog dana otići u neki Mikrotik, a tamo će biti 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 stalno prati sva pravila prosljeđivanja s određenim opisom i provjerava ima li TCP veza odgovarajuće pravilo. Ako ga nema neko vrijeme, onda je veza vjerojatno već završena i ovo prosljeđivanje se može izbrisati. Sve je uspjelo, scenarij je dobro funkcionirao.
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
}
}
Sigurno je mogao biti ljepši, brži itd., ali radio je, nije opterećivao Mikrotik i radio je odlično. Napokon smo se mogli spojiti na servere i mrežnu opremu klijenata samo jednim klikom. Bez otvaranja VPN-a ili unosa lozinki. Sustav je postao stvarno zgodan za rad. Vrijeme usluge je smanjeno, a svi smo vrijeme provodili radeći umjesto povezivanja na potrebne objekte.
Mikrotik sigurnosna kopija
Konfigurirali smo backup svih Mikrotika na FTP. I općenito je sve bilo u redu. Ali kada ste trebali dobiti sigurnosnu kopiju, morali ste otvoriti ovaj FTP i tamo ga potražiti. Imamo sustav u kojem su svi routeri povezani, s uređajima možemo komunicirati putem SSH-a. Zašto ne bismo napravili tako da sam sustav svakodnevno preuzima sigurnosne kopije sa svih Mikrotika, pomislio sam. I počeo ga je provoditi. Spojili smo se, napravili backup i odnijeli u skladište.
Kod skripte u PHP-u za pravljenje backupa iz 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 preuzima u dva oblika - binarnoj i tekstualnoj konfiguraciji. Binarna datoteka pomaže u brzom vraćanju potrebne konfiguracije, a tekstualna vam omogućuje da razumijete što treba učiniti ako dođe do prisilne zamjene opreme i binarna datoteka se ne može učitati u nju. Kao rezultat toga, dobili smo još jednu prikladnu funkcionalnost u sustavu. Štoviše, prilikom dodavanja novog Mikrotika nije bilo potrebno ništa konfigurirati, jednostavno sam objekt dodao u sustav i postavio mu račun preko SSH-a. Zatim se sam sustav pobrinuo za izradu sigurnosnih kopija. Trenutna verzija SaaS Veliama još nema ovu funkcionalnost, ali ćemo je uskoro prenijeti.
Slike zaslona kako je to izgledalo u internom sustavu
Prijelaz na normalno skladištenje baze podataka
Već sam gore napisao da su se pojavili artefakti. Ponekad je cijeli popis objekata u sustavu jednostavno nestao, ponekad prilikom uređivanja objekta podaci nisu bili spremljeni i objekt je morao biti preimenovan tri puta. To je sve užasno iritiralo. Nestanak objekata događao se rijetko i lako se obnovio vraćanjem ove datoteke, ali su se kvarovi prilikom uređivanja objekata događali prilično često. Vjerojatno to u početku nisam radio kroz bazu podataka jer mi nije bilo jasno kako je moguće držati stablo sa svim vezama u ravnoj tablici. Ravno je, ali stablo je hijerarhijsko. Ali dobro rješenje za višestruki pristup, a kasnije (kako sustav postaje složeniji) transakcijski, je DBMS. Vjerojatno nisam prvi koji se susreo s ovim problemom. Počeo sam guglati. Ispostavilo se da je sve već bilo izmišljeno prije mene i postoji nekoliko algoritama koji grade stablo od ravnog stola. Nakon što sam pogledao svaki od njih, implementirao sam jedan od njih. Ali to je već bila nova verzija sustava, jer... Zapravo, zbog toga sam dosta toga morao prepisivati. Rezultat je bio prirodan, problemi slučajnog ponašanja sustava su nestali. Neki bi mogli reći da su pogreške vrlo amaterske (skripte s jednom niti, pohranjivanje informacija kojima se pristupilo više puta istovremeno iz različitih niti u datoteci, itd.) u području razvoja softvera. Možda je to istina, ali moj glavni posao je bio administracija, a programiranje je bila sporedna stvar za moju dušu i jednostavno nisam imao iskustva raditi u timu programera, gdje bi mi takve osnovne stvari odmah sugerirao stariji drugovi. Stoga sam sve te kvrge popunila sama, ali sam jako dobro naučila gradivo. A također, moj posao uključuje sastanke s klijentima, akcije usmjerene na promociju tvrtke, hrpu administrativnih pitanja unutar tvrtke i još puno, puno toga. Ali na ovaj ili onaj način, tražilo se ono što je već bilo. Dečki i ja osobno koristimo proizvod u svakodnevnom radu. Bilo je iskreno neuspješnih ideja i rješenja na koja se gubilo vrijeme, ali se na kraju pokazalo da to nije radni alat i da ga nitko nije koristio i da nije završio u Veliamu.
Helpdesk - HelpDesk
Ne bi bilo naodmet spomenuti kako je nastao HelpDesk. Ovo je sasvim druga priča, jer... u Veliamu je ovo već 3. potpuno nova verzija, koja se razlikuje od svih dosadašnjih. Sada je to jednostavan sustav, intuitivan bez nepotrebnih nabora, s mogućnošću integracije s domenom, kao i mogućnošću pristupa istom korisničkom profilu s bilo kojeg mjesta koristeći poveznicu iz e-pošte. I što je najvažnije, moguće je povezati se s podnositeljem zahtjeva putem VNC-a s bilo kojeg mjesta (kod kuće ili u uredu) izravno iz aplikacije bez VPN-a ili prosljeđivanja portova. Reći ću vam kako smo došli do ovoga, što se dogodilo prije i kakve su strašne odluke donesene.
S korisnicima smo se povezali preko poznatog TeamViewera. Sva računala čije korisnike opslužujemo imaju instaliran TV. Prvo što smo pogriješili i kasnije uklonili bilo je povezivanje svakog HD klijenta s hardverom. Kako se korisnik prijavio u HD sustav da bi ostavio zahtjev? Osim TV-a, svatko je na svojim računalima imao instaliran poseban uslužni program, napisan u Lazarusu (mnogi ljudi ovdje će zakolutati očima, pa će možda čak otići na Google što je to, ali najbolje kompilirani jezik koji sam znao bio je Delphi, a Lazarus je gotovo ista stvar, samo besplatno). Općenito, korisnik je pokrenuo posebnu batch datoteku koja je pokrenula ovaj uslužni program, koji je zauzvrat pročitao HWID sustava i nakon toga je pokrenut preglednik i došlo je do autorizacije. Zašto je to učinjeno? U nekim se tvrtkama broj korisnika usluga računa pojedinačno, a cijena usluge za svaki mjesec temelji se na broju ljudi. To je razumljivo, kažete, ali zašto je to vezano uz hardver? Vrlo je jednostavno, neki pojedinci su došli kući i sa svog kućnog laptopa uputili zahtjev u stilu “neka mi ovdje bude sve lijepo”. Osim čitanja HWID-a sustava, uslužni program izvukao je trenutni Teamviewer ID iz registra i također nam ga prenio. Teamviewer ima API za integraciju. I napravili smo ovu integraciju. Ali postojala je jedna kvaka. Putem ovih API-ja nemoguće je spojiti se na računalo korisnika ako on eksplicitno ne inicira ovu sesiju i nakon pokušaja povezivanja mora kliknuti i "potvrdi". Tada nam se činilo logičnim da se nitko ne smije spojiti bez zahtjeva korisnika, a budući da je osoba za računalom, on će pokrenuti sesiju i odgovoriti potvrdno na zahtjev za daljinsko povezivanje. Sve je ispalo krivo. Podnositelji zahtjeva zaboravili su pritisnuti za pokretanje sesije, pa su im to morali reći u telefonskom razgovoru. Time je izgubljeno vrijeme i bilo je frustrirajuće za obje strane procesa. Štoviše, uopće nisu neuobičajeni trenuci kada osoba ostavi zahtjev, ali se smije spojiti tek kada ode na ručak. Jer problem nije kritičan i ne želi da mu se prekida radni proces. Sukladno tome, on neće pritisnuti nijedan gumb da bi omogućio povezivanje. Ovako se pojavila dodatna funkcionalnost prilikom prijave na HelpDesk - očitavanje Teamviwer ID-a. Znali smo trajnu lozinku koja se koristila prilikom instaliranja Teamviwera. Točnije, znao ga je samo sustav, budući da je ugrađen u instalater iu naš sustav. Sukladno tome, tu je bio gumb za spajanje iz aplikacije klikom na koji nije trebalo ništa čekati, već se Teamviewer odmah otvorio i došlo je do povezivanja. Kao rezultat, postojale su dvije vrste mogućih veza. Putem službenog Teamviewer API-ja i onog koji smo sami napravili. Na moje iznenađenje, prvi su gotovo odmah prestali koristiti, iako je postojala uputa da se koristi samo u posebnim slučajevima i kada sam korisnik da zeleno svjetlo. Ipak, sada mi daj sigurnost. No pokazalo se da to podnositeljima zahtjeva nije trebalo. Svi su sasvim u redu s povezivanjem s njima bez gumba za potvrdu.
Prelazak na višenitnost u Linuxu
Pitanje ubrzanja prolaska mrežnog skenera za otvorenost unaprijed određenog popisa priključaka i jednostavnog pinganja mrežnih objekata odavno se počelo postavljati. Ovdje je, naravno, prvo rješenje koje pada na pamet multithreading. Budući da je glavno vrijeme potrošeno na ping čekanje da se paket vrati, a sljedeći ping ne može započeti dok se prethodni paket ne vrati, u tvrtkama koje su imale čak 20+ servera plus mrežnu opremu, ovo je već radilo prilično sporo. Poanta je da jedan paket može nestati, ali nemojte odmah obavijestiti administratora sustava o tome. Jednostavno će vrlo brzo prestati prihvaćati takav spam. To znači da trebate pingati svaki objekt više od jednom prije nego što donesete zaključak o nedostupnosti. Ne ulazeći previše u detalje, potrebno ga je paralelizirati jer ako se to ne učini, onda će najvjerojatnije administrator sustava saznati za problem od klijenta, a ne od sustava za nadzor.
PHP sam po sebi ne podržava višenitnost odmah. Sposoban za multiprocesiranje, možete račvati. Ali, zapravo, već sam imao napisan polling mehanizam i htio sam ga napraviti tako da jednom prebrojim sve čvorove koje trebam iz baze, pingam sve odjednom, čekam odgovor od svakog i tek nakon toga odmah pišem podatak. Time se štedi na broju zahtjeva za čitanje. Multithreading se savršeno uklapa u ovu ideju. Za PHP postoji modul PThreads koji vam omogućuje pravi multithreading, iako je bilo potrebno dosta petljanja da se to postavi na PHP 7.2, ali je učinjeno. Skeniranje priključaka i ping sada su brzi. I umjesto, primjerice, 15 sekundi po krugu ranije, ovaj proces je počeo trajati 2 sekunde. Bio je to dobar rezultat.
Brza revizija novih tvrtki
Kako je nastala funkcionalnost za prikupljanje raznih metrika i karakteristika hardvera? Jednostavno je. Ponekad nam se jednostavno naredi revizija trenutne IT infrastrukture. Pa, isto je potrebno za ubrzanje revizije novog klijenta. Trebalo nam je nešto što će nam omogućiti da dođemo do srednje ili velike tvrtke i brzo shvatimo što imaju. Po mom mišljenju, ping na internoj mreži blokiraju samo oni koji si žele zakomplicirati život, a takvih je prema našem iskustvu malo. Ali ima i takvih ljudi. U skladu s tim, možete brzo skenirati mreže na prisutnost uređaja jednostavnim pingom. Tada ih možemo dodati i skenirati otvorene portove koji nas zanimaju. Ta je funkcionalnost zapravo već postojala, samo je bilo potrebno dodati naredbu sa središnjeg poslužitelja na podređeni kako bi on skenirao navedene mreže i sve što nađe dodao na popis. Zaboravio sam napomenuti, pretpostavljalo se da već imamo gotovu sliku s konfiguriranim sustavom (slave monitoring server) koju možemo jednostavno izbaciti s klijenta tijekom revizije i povezati je s našim oblakom.
No rezultat revizije obično uključuje hrpu različitih informacija, a jedna od njih je kakvi su uređaji na mreži. Prije svega, zanimali su nas Windows poslužitelji i Windows radne stanice kao dio domene. Budući da je u srednjim i velikim tvrtkama nedostatak domene vjerojatno iznimka od pravila. Govoriti jedan jezik, prosjek je, po meni, 100+ ljudi. Bilo je potrebno smisliti način prikupljanja podataka sa svih Windows strojeva i poslužitelja, znajući njihovu IP adresu i račun administratora domene, ali bez instaliranja bilo kakvog softvera na svakom od njih. WMI sučelje dolazi u pomoć. Windows Management Instrumentation (WMI) doslovno znači Windows alati za upravljanje. WMI je jedna od osnovnih tehnologija za centralizirano upravljanje i praćenje rada različitih dijelova računalne infrastrukture na Windows platformi. Preuzeto sa wiki. Zatim sam morao ponovno petljati kako bih kompajlirao wmic (ovo je WMI klijent) za Debian. Nakon što je sve bilo spremno, preostalo je jednostavno prozvati potrebne čvorove putem wmic-a za potrebne informacije. Putem WMI-ja možete dobiti gotovo sve informacije s računala sa sustavom Windows, a štoviše, preko njega možete kontrolirati računalo, na primjer, poslati ga na ponovno pokretanje. Tako se pojavila zbirka informacija o Windows stanicama i poslužiteljima u našem sustavu. Osim toga, tu su bile i aktualne informacije o trenutnim pokazateljima opterećenja sustava. Češće ih tražimo, a rjeđe podatke o hardveru. Nakon ovoga, revizija je postala malo ugodnija.
Odluka o distribuciji softvera
I sami svakodnevno koristimo sustav i uvijek je otvoren za svakog tehničkog djelatnika. I mislili smo da možemo podijeliti s drugima ono što već imamo. Sustav još nije bio spreman za distribuciju. Trebalo je puno toga preraditi kako bi se lokalna verzija pretvorila u SaaS. To uključuje promjene u različitim tehničkim aspektima sustava (daljinske veze, usluga podrške), analizu modula za licenciranje, dijeljenje korisničkih baza podataka, skaliranje svake usluge i razvoj sustava za automatsko ažuriranje za sve dijelove. Ali ovo će biti drugi dio članka.
Nadopune
Izvor: www.habr.com