Hej alla, mitt namn Àr Sergey Emelyanchik. Jag Àr chef för Audit-Telecom-företaget, huvudutvecklaren och författaren till Veliam-systemet. Jag bestÀmde mig för att skriva en artikel om hur jag och min vÀn skapade ett outsourcingföretag, skrev mjukvara Ät oss sjÀlva och började sedan distribuera det till alla via SaaS-systemet. Om hur jag kategoriskt inte trodde att detta var möjligt. Artikeln kommer att innehÄlla inte bara en berÀttelse, utan ocksÄ tekniska detaljer om hur Veliam-produkten skapades. Inklusive nÄgra delar av kÀllkoden. Jag ska berÀtta vilka misstag vi gjorde och hur vi rÀttade till dem senare. Det fanns tvivel om att publicera en sÄdan artikel. Men jag tyckte det var bÀttre att göra det, fÄ feedback och förbÀttra, Àn att inte publicera artikeln och fundera pÄ vad som skulle ha hÀnt om...
förhistoria
Jag arbetade i ett företag som IT-anstÀlld. Företaget var ganska stort med en omfattande nÀtverksstruktur. Jag kommer inte att uppehÄlla mig vid mina arbetsuppgifter, jag kommer bara att sÀga att de definitivt inte inkluderade utvecklingen av nÄgonting.
Vi hade bevakning, men av rent akademiskt intresse ville jag försöka skriva min egen enklaste. Tanken var denna: jag ville att den skulle finnas pÄ webben, sÄ att jag enkelt kunde gÄ in utan att installera nÄgra klienter och se vad som hÀnde med nÀtverket frÄn vilken enhet som helst, inklusive en mobil enhet via Wi-Fi, och jag verkligen ville snabbt förstÄ vad Det finns utrustning i rummet som har blivit "mopeig" eftersom... det fanns mycket strÀnga krav pÄ svarstid pÄ sÄdana problem. Som ett resultat föddes en plan i mitt huvud att skriva en enkel webbsida dÀr det fanns en jpeg-bakgrund med ett nÀtverksdiagram, klippa ut sjÀlva enheterna med deras IP-adresser pÄ den hÀr bilden och visa dynamiskt innehÄll ovanpÄ bild i erforderliga koordinater i form av en grön eller blinkande röd IP-adress. Uppgiften Àr klar, lÄt oss komma igÄng.
Tidigare har jag programmerat i Delphi, PHP, JS och vÀldigt ytligt C++. Jag vet ganska vÀl hur nÀtverk fungerar. VLAN, Routing (OSPF, EIGRP, BGP), NAT. Detta rÀckte för att jag sjÀlv skulle skriva en primitiv övervakningsprototyp.
Jag skrev vad jag planerade i PHP. Apache- och PHP-servern var pÄ Windows eftersom... Linux för mig i det ögonblicket var nÄgot obegripligt och mycket komplext, som det visade sig senare, jag hade vÀldigt fel och pÄ mÄnga stÀllen Àr Linux mycket enklare Àn Windows, men detta Àr ett separat Àmne och vi vet alla hur mÄnga holivar det finns pÄ det hÀr Àmnet. Windows-uppgiftsschemalÀggaren drog med ett litet intervall (jag kommer inte ihÄg exakt, men ungefÀr en gÄng var tredje sekund) ett PHP-skript som pollade alla objekt med en banal ping och sparade tillstÄndet i en fil.
system(âping -n 3 -w 100 {$ip_address}â);
Ja, ja, att arbeta med en databas just dÄ var inte heller behÀrskad för mig. Jag visste inte att det var möjligt att parallellisera processer, och att gÄ igenom alla nÀtverksnoder tog lÄng tid, eftersom... detta hÀnde i en trÄd. Problem uppstod sÀrskilt nÀr flera noder var otillgÀngliga, pga var och en av dem försenade skriptet med 300 ms. PÄ klientsidan fanns en enkel looping-funktion som med nÄgra sekunders intervall laddade ner uppdaterad information frÄn servern med en Ajax-förfrÄgan och uppdaterade grÀnssnittet. Tja, dÄ, efter 3 misslyckade pingar i rad, om en webbsida med övervakning var öppen pÄ datorn, spelade en glad komposition.
NÀr allt löste sig blev jag vÀldigt inspirerad av resultatet och tÀnkte att jag kunde tillföra mer (pÄ grund av mina kunskaper och förmÄgor). Men jag har alltid inte gillat system med en miljon diagram, vilket jag trodde dÄ, och fortfarande tycker Àn idag, Àr onödigt i de flesta fall. Jag ville bara lÀgga in det som verkligen skulle hjÀlpa mig i mitt arbete. Denna princip förblir grundlÀggande för utvecklingen av Veliam till denna dag. Vidare insÄg jag att det skulle vara vÀldigt coolt om jag inte behövde hÄlla övervakningen öppen och veta om problem, och nÀr det hÀnde, öppna sidan och se var den hÀr problematiska nÀtverksnoden finns och vad jag ska göra med den hÀrnÀst . PÄ nÄgot sÀtt lÀste jag inte e-post dÄ, jag anvÀnde det helt enkelt inte. Jag hittade pÄ Internet att det finns SMS-gateways som du kan skicka en GET eller POST-förfrÄgan till, och de kommer att skicka ett SMS till min mobiltelefon med texten som jag skriver. Jag insÄg direkt att jag verkligen ville det hÀr. Och jag började studera dokumentationen. Efter en tid lyckades jag, och nu fick jag ett SMS om problem pÄ nÀtverket pÄ min mobiltelefon med namnet pÄ ett "nedfallet föremÄl". Trots att systemet var primitivt skrevs det av mig sjÀlv, och det viktigaste som motiverade mig att utveckla det var att det var ett applikationsprogram som verkligen hjÀlpte mig i mitt arbete.
Och sÄ kom dagen dÄ en av internetkanalerna gick ner pÄ jobbet, och min övervakning meddelade mig inte om det. Eftersom Google DNS fortfarande pingade perfekt. Det Àr dags att fundera över hur du kan övervaka att kommunikationskanalen lever. Det fanns olika idéer om hur man skulle göra detta. Jag hade inte tillgÄng till all utrustning. Vi var tvungna att ta reda pÄ hur vi skulle förstÄ vilken av kanalerna som Àr live, men utan att pÄ nÄgot sÀtt kunna se det pÄ sjÀlva nÀtverksutrustningen. DÄ kom en kollega pÄ idén att det Àr möjligt att ruttspÄrningen till publika servrar kan skilja sig beroende pÄ vilken kommunikationskanal som för nÀrvarande anvÀnds för att komma Ät Internet. Jag kollade och det blev sÄ. Det fanns olika vÀgar vid spÄrning.
system(âtracert -d -w 500 8.8.8.8â);
SÄ ett annat skript dök upp, eller snarare, av nÄgon anledning lades spÄret till i slutet av samma skript, vilket pingade alla enheter i nÀtverket. Detta Àr trots allt en annan lÄng process som kördes i samma trÄd och saktade ner arbetet med hela manuset. Men dÄ var det inte sÄ sjÀlvklart. Men pÄ ett eller annat sÀtt gjorde han sitt jobb, koden definierade strikt vilken typ av spÄrning som skulle vara för var och en av kanalerna. Det var sÄ systemet började fungera, som redan övervakade (högt sagt, eftersom det inte fanns nÄgon samling av nÄgra mÀtvÀrden, utan bara ping) nÀtverksenheter (routrar, switchar, wi-fi, etc.) och kommunikationskanaler med omvÀrlden . SMS kom in regelbundet och diagrammet visade alltid tydligt var problemet lÄg.
Vidare var jag tvungen att göra cross-crossing i det dagliga arbetet. Och jag tröttnade pÄ att gÄ till Ciscos switchar varje gÄng för att se vilket grÀnssnitt jag skulle anvÀnda. Hur coolt det skulle vara att klicka pÄ ett objekt i övervakningen och se en lista över dess grÀnssnitt med beskrivningar. Det skulle spara mig tid. Dessutom skulle det i detta schema inte finnas nÄgot behov av att köra Putty eller SecureCRT för att ange konton och kommandon. Jag klickade bara pÄ övervakningen, sÄg vad som behövdes och gick för att göra mitt jobb. Jag började leta efter sÀtt att interagera med switchar. Jag stötte omedelbart pÄ 2 alternativ: SNMP eller logga in pÄ switchen via SSH, ange de kommandon jag behövde och analysera resultatet. Jag avfÀrdade SNMP pÄ grund av komplexiteten i dess implementering; jag var otÄlig pÄ att fÄ resultatet. med SNMP skulle du behöva grÀva i MIB under lÄng tid och, baserat pÄ dessa data, generera data om grÀnssnitten. Det finns ett underbart team pÄ CISCO
show interface statusDen visar precis vad jag behöver för korsningar. Varför bry sig om SNMP nÀr jag bara vill se resultatet av det hÀr kommandot, tÀnkte jag. Efter ett tag insÄg jag denna möjlighet. Klickade pÄ ett objekt pÄ en webbsida. En hÀndelse utlöstes genom vilken AJAX-klienten kontaktade servern, och den i sin tur kopplades via SSH till switchen jag behövde (referenserna var hÄrdkodade i koden, det fanns ingen önskan att förfina den, för att göra nÄgra separata menyer dÀr det skulle vara möjligt att byta konton frÄn grÀnssnittet, jag behövde resultatet och snabbt) Jag skrev in ovanstÄende kommando dÀr och skickade tillbaka det till webblÀsaren. SÄ jag började se information om grÀnssnitt med ett musklick. Detta var extremt bekvÀmt, speciellt nÀr du var tvungen att se den hÀr informationen pÄ olika switchar samtidigt.
SpÄrbaserad kanalövervakning slutade inte vara den bÀsta idén, eftersom... ibland utfördes arbete pÄ nÀtet, och spÄrningen kunde Àndras och övervakningen började skrika Ät mig att det var problem med kanalen. Men efter att ha spenderat mycket tid pÄ analys insÄg jag att alla kanaler fungerade, och min övervakning lurade mig. Som ett resultat bad jag mina kollegor som hanterade kanalbildande switchar att helt enkelt skicka mig syslog nÀr synlighetsstatusen för grannar Àndrades. Följaktligen var det mycket enklare, snabbare och mer exakt Àn spÄrning. En hÀndelse som granne förlorad har anlÀnt, och jag utfÀrdar omedelbart ett meddelande om kanalen nere.
Vidare dök flera kommandon upp nÀr man klickade pÄ ett objekt, och SNMP lades till för att samla in nÄgra mÀtvÀrden, och det Àr i princip allt. Systemet utvecklades aldrig vidare. Den gjorde allt jag behövde, det var ett bra verktyg. MÄnga lÀsare kommer sÀkert att berÀtta för mig att det redan finns en hel del mjukvara pÄ Internet för att lösa dessa problem. Men i sjÀlva verket googlade jag inte pÄ sÄdana gratisprodukter dÄ och jag ville verkligen utveckla mina programmeringskunskaper, och vilket bÀttre sÀtt att driva pÄ för detta Àn ett verkligt applikationsproblem. Vid denna tidpunkt var den första versionen av övervakningen klar och modifierades inte lÀngre.
Skapandet av företaget Audit-Telecom
Allteftersom tiden gick började jag jobba deltid pÄ andra företag, lyckligtvis tillÀt mitt arbetsschema mig att göra detta. NÀr du arbetar i olika företag vÀxer din kompetens inom olika omrÄden vÀldigt snabbt och dina horisonter utvecklas vÀl. Det finns företag dÀr man, som man sÀger, Àr en svensk, en skördare och en trumpetare. à ena sidan Àr det svÄrt, Ä andra sidan, om du inte Àr lat blir du en generalist och det gör att du kan lösa problem snabbare och mer effektivt eftersom du vet hur det relaterade fÀltet fungerar.
Min vÀn Pavel (ocksÄ IT-specialist) försökte stÀndigt uppmuntra mig att starta eget. Det fanns otaliga idéer med olika varianter av vad de gjorde. Detta har diskuterats i Äratal. Och i slutÀndan borde det inte ha blivit nÄgot eftersom jag Àr en skeptiker och Pavel Àr en drömmare. Varje gÄng han föreslog en idé trodde jag alltid inte pÄ den och vÀgrade att delta. Men vi ville verkligen öppna ett eget företag.
Ăntligen kunde vi hitta ett alternativ som passade oss bĂ„da och göra det vi vet hur vi ska göra. 2016 beslutade vi att skapa ett IT-företag som skulle hjĂ€lpa företag att lösa IT-problem. Detta Ă€r utbyggnaden av IT-system (1C, terminalserver, e-postserver, etc.), deras underhĂ„ll, klassisk HelpDesk för anvĂ€ndare och nĂ€tverksadministration.
Ărligt talat, nĂ€r jag skapade företaget trodde jag inte pĂ„ det till 99,9%. Men pĂ„ nĂ„got sĂ€tt kunde Pavel fĂ„ mig att försöka, och nĂ€r han tittade framĂ„t visade det sig att han hade rĂ€tt. Pavel och jag chippade in 300 000 rubel vardera, registrerade ett nytt LLC "Audit-Telecom", hyrde ett litet kontor, gjorde coola visitkort, ja, i allmĂ€nhet, som förmodligen de flesta oerfarna, nybörjare affĂ€rsmĂ€n, och började leta efter kunder. Att hitta kunder Ă€r en helt annan historia. Kanske kommer vi att skriva en separat artikel som en del av företagsbloggen om nĂ„gon Ă€r intresserad. Kalla samtal, flygblad osv. Detta gav inga resultat. Som jag nu lĂ€ser frĂ„n mĂ„nga historier om företag, pĂ„ ett eller annat sĂ€tt, beror mycket pĂ„ tur. Vi hade tur. och bokstavligen ett par veckor efter skapandet av företaget kontaktade min bror Vladimir oss, som gav oss vĂ„r första kund. Jag ska inte trĂ„ka ut dig med detaljerna om att arbeta med kunder, det Ă€r inte vad artikeln handlar om, jag ska bara sĂ€ga att vi gick pĂ„ en revision, identifierade kritiska omrĂ„den och dessa omrĂ„den gick sönder medan beslutet togs om huruvida vi skulle samarbeta med oss ââlöpande som uppdragsgivare. Efter detta fattades omedelbart ett positivt beslut.
Sedan, frĂ€mst genom mun till mun via vĂ€nner, började andra tjĂ€nsteföretag dyka upp. Helpdesk fanns i ett system. Anslutningar till nĂ€tverksutrustning och servrar Ă€r olika, eller snarare olika. Vissa mĂ€nniskor sparade genvĂ€gar, andra anvĂ€nde RDP-adressböcker. Ăvervakning Ă€r ett annat separat system. Det Ă€r vĂ€ldigt obekvĂ€mt för ett team att arbeta i olika system. Viktig information förloras ur sikte. Tja, till exempel blev klientens terminalserver otillgĂ€nglig. Ansökningar frĂ„n anvĂ€ndare av denna klient tas emot omedelbart. Supportspecialisten öppnar en förfrĂ„gan (den togs emot via telefon). Om incidenter och förfrĂ„gningar registrerades i ett system, skulle supportspecialisten omedelbart se vad anvĂ€ndarens problem Ă€r och berĂ€tta för honom om det, samtidigt som han ansluter till det önskade objektet för att lösa situationen. Alla Ă€r medvetna om den taktiska situationen och arbetar harmoniskt. Vi har inte hittat ett system dĂ€r allt detta Ă€r kombinerat. Det blev tydligt att det var dags att göra vĂ„r egen produkt.
Fortsatt arbete med ditt övervakningssystem
Det var tydligt att systemet som skrevs tidigare var helt olÀmpligt för de aktuella uppgifterna. Varken funktionsmÀssigt eller kvalitetsmÀssigt. Och det beslutades att skriva systemet frÄn grunden. Rent grafiskt borde det ha sett helt annorlunda ut. Det mÄste vara ett hierarkiskt system sÄ att det skulle vara möjligt att snabbt och bekvÀmt öppna rÀtt objekt för rÀtt klient. Systemet som i den första versionen var absolut inte motiverat i det aktuella fallet, eftersom Kunderna Àr olika och det spelade ingen roll i vilken lokal utrustningen fanns. Detta har redan överförts till dokumentationen.
SÄ arbetsuppgifterna Àr:
- Hierarkisk struktur;
- NÄgon sorts serverdel som kan placeras pÄ klientens lokaler i form av en virtuell maskin för att samla in den statistik vi behöver och skicka den till den centrala servern, som kommer att sammanfatta allt detta och visa det för oss;
- Varningar. De som inte gÄr att missa, för... pÄ den tiden var det inte möjligt för nÄgon att sitta och bara titta pÄ monitorn;
- Applikationssystem. Det började dyka upp kunder för vilka vi servade inte bara server- och nÀtverksutrustning utan Àven arbetsstationer;
- Möjlighet att snabbt ansluta till servrar och utrustning frÄn systemet;
Uppgifterna Àr satta, vi börjar skriva. LÀngs vÀgen, behandla förfrÄgningar frÄn kunder. PÄ den tiden var vi redan 4 stycken. Vi började skriva bÄda delarna pÄ en gÄng: den centrala servern och servern för installation till klienter. Vid det hÀr laget var Linux inte lÀngre frÀmmande för oss och det beslutades att de virtuella maskinerna som klienterna skulle ha skulle finnas pÄ Debian. Det kommer inte att finnas nÄgra installatörer, vi gör bara ett serverdelprojekt pÄ en specifik virtuell maskin och sedan klonar vi den till önskad klient. Detta var Ànnu ett misstag. Senare blev det klart att i ett sÄdant schema var uppdateringsmekanismen helt outvecklad. De dÀr. vi lade till nÄgon ny funktion, och sedan var det hela problemet med att distribuera det till alla klientservrar, men vi kommer tillbaka till detta senare, allt i ordning.
Vi gjorde den första prototypen. Han kunde pinga de klientnÀtverksenheter och servrar vi behövde och skicka dessa data till vÄr centrala server. Och han i sin tur uppdaterade denna data i bulk pÄ den centrala servern. HÀr kommer jag att skriva inte bara en berÀttelse om hur och vad som var framgÄngsrikt, utan ocksÄ vilka amatörmÀssiga misstag som gjordes och hur jag senare fick betala för det med tiden. SÄ, hela trÀdet av objekt lagrades i en enda fil i form av ett serialiserat objekt. Medan vi kopplade flera klienter till systemet var allt mer eller mindre normalt, Àven om det ibland fanns nÄgra artefakter som var helt obegripliga. Men nÀr vi kopplade ett dussin servrar till systemet började mirakel hÀnda. Ibland, av nÄgon okÀnd anledning, försvann helt enkelt alla objekt i systemet. Det Àr viktigt att notera hÀr att servrarna som klienterna hade skickade data till den centrala servern med nÄgra sekunders mellanrum via en POST-förfrÄgan. En uppmÀrksam lÀsare och en erfaren programmerare gissade redan att det fanns ett problem med flera Ätkomst till sjÀlva filen dÀr det serialiserade objektet lagrades frÄn olika trÄdar samtidigt. Och precis nÀr detta hÀnde intrÀffade mirakel med försvinnandet av föremÄl. Filen blev helt enkelt tom. Men allt detta upptÀcktes inte omedelbart, utan bara under drift med flera servrar. Under denna tid lades portskanningsfunktionalitet till (servrarna skickade till centralen inte bara information om tillgÀngligheten för enheter utan ocksÄ om portarna som Àr öppna pÄ dem). Detta gjordes genom att anropa kommandot:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
resultaten var ofta felaktiga och skanningarna tog lÄng tid att slutföra. Jag glömde helt bort ping, det gjordes via fping:
system("fping -r 3 -t 100 {$this->ip}");
Detta var inte heller parallelliserat och dÀrför blev processen mycket lÄng. Senare skickades hela listan med IP-adresser som krÀvs för verifiering till fping pÄ en gÄng och tillbaka fick vi en fÀrdig lista pÄ de som svarat. Till skillnad frÄn oss kunde fping parallellisera processer.
Ett annat vanligt rutinjobb var att sÀtta upp vissa tjÀnster via WEB. Jo, till exempel ECP frÄn MS Exchange. I grund och botten Àr det bara en lÀnk. Och vi bestÀmde oss för att vi mÄste kunna lÀgga till sÄdana lÀnkar direkt till systemet, för att inte behöva leta i dokumentationen eller nÄgon annanstans i bokmÀrken efter hur man kommer Ät ECP för en specifik klient. SÄ hÀr sÄg konceptet med resurslÀnkar för systemet ut, deras funktionalitet Àr tillgÀnglig till denna dag och har inte förÀndrats, ja, nÀstan.
Hur resurslÀnkar fungerar i Veliam
FjÀrranslutningar
SÄ hÀr ser det ut i aktion i den aktuella versionen av Veliam
En av uppgifterna var att snabbt och bekvÀmt ansluta till servrar, som det redan fanns mÄnga av (mer Àn hundra) och att sortera igenom miljontals försparade RDP-genvÀgar var extremt obekvÀmt. Ett verktyg behövdes. Det finns programvara pÄ Internet som Àr ungefÀr som en adressbok för sÄdana RDP-anslutningar, men de Àr inte integrerade med övervakningssystemet och konton kan inte sparas. Att lÀgga in konton för olika klienter varje gÄng Àr ett rent helvete nÀr du ansluter dussintals gÄnger om dagen till olika servrar. Med SSH gÄr det lite bÀttre, det finns mycket bra programvara som lÄter dig organisera sÄdana anslutningar i mappar och komma ihÄg konton frÄn dem. Men det finns 2 problem. Det första Àr att vi inte hittade ett enda program för RDP- och SSH-anslutningar. Det andra Àr att om jag vid nÄgot tillfÀlle inte Àr vid min dator och jag behöver ansluta snabbt, eller om jag bara installerade om systemet, mÄste jag gÄ in i dokumentationen för att titta pÄ kontot frÄn den hÀr klienten. Det Àr obekvÀmt och slöseri med tid.
Den hierarkiska struktur vi behövde för klientservrar fanns redan i vÄr interna produkt. Jag var bara tvungen att ta reda pÄ hur man fÀster snabbkopplingar till nödvÀndig utrustning dÀr. Till att börja med, Ätminstone inom ditt nÀtverk.
Med hĂ€nsyn till det faktum att klienten i vĂ„rt system var en webblĂ€sare som inte har tillgĂ„ng till de lokala resurserna pĂ„ datorn, för att helt enkelt starta applikationen vi behövde med nĂ„got kommando, uppfanns den för att göra allt genom "Windows anpassat webbadressschemaâ. SĂ„ hĂ€r dök ett visst "plugin" ut för vĂ„rt system, som helt enkelt inkluderade Putty och Remote Desktop Plus och, under installationen, helt enkelt registrerade URI-schemat i Windows. Nu, nĂ€r vi ville ansluta till ett objekt via RDP eller SSH, klickade vi pĂ„ den hĂ€r Ă„tgĂ€rden pĂ„ vĂ„rt system och den anpassade URI:n fungerade. Standarden mstsc.exe inbyggd i Windows eller kitt, som var en del av "plugin", lanserades. Jag sĂ€tter ordet plugin inom citattecken eftersom detta inte Ă€r ett webblĂ€sarplugin i klassisk mening.
Det var Ätminstone nÄgot. BekvÀm adressbok. Dessutom, i fallet med Putty, var allt i allmÀnhet bra, det kunde ges IP-anslutningar, inloggning och lösenord som indataparametrar. De dÀr. Vi har redan anslutit till Linux-servrar i vÄrt nÀtverk med ett klick utan att ange lösenord. Men med RDP Àr det inte sÄ enkelt. Standard mstsc kan inte tillhandahÄlla autentiseringsuppgifter som parametrar. Remote Desktop Plus kom till undsÀttning. Han lÀt detta hÀnda. Nu klarar vi oss utan den, men den var lÀnge en trogen assistent i vÄrt system. Med HTTP(S)-sajter Àr allt enkelt, sÄdana objekt öppnas helt enkelt i webblÀsaren och det Àr allt. BekvÀmt och praktiskt. Men detta var bara lycka pÄ det interna nÀtverket.
Eftersom vi löste de allra flesta problem pÄ distans frÄn kontoret var det enklaste att göra VPN:er tillgÀngliga för kunderna. Och sedan var det möjligt att ansluta till dem frÄn vÄrt system. Men det var ÀndÄ nÄgot obekvÀmt. För varje klient var det nödvÀndigt att ha ett gÀng ihÄgkomna VPN-anslutningar pÄ varje dator, och innan du ansluter till nÄgon var det nödvÀndigt att aktivera motsvarande VPN. Vi har anvÀnt denna lösning ganska lÀnge. Men antalet kunder ökar, antalet VPN ökar ocksÄ, och allt detta började anstrÀnga sig och nÄgot mÄste göras Ät det. TÄrarna kom sÀrskilt i ögonen efter att jag installerat om systemet, nÀr jag var tvungen att Äterinföra dussintals VPN-anslutningar i en ny Windows-profil. Sluta stÄ ut med det hÀr, sa jag och började fundera pÄ vad jag skulle kunna göra Ät det.
Det hÀnde sig att alla klienter hade enheter frÄn det vÀlkÀnda företaget Mikrotik som routrar. De Àr mycket funktionella och bekvÀma för att utföra nÀstan alla uppgifter. Nackdelen Àr att de Àr "kapade". Vi löste detta problem helt enkelt genom att stÀnga all Ätkomst frÄn utsidan. Men det var nödvÀndigt att pÄ nÄgot sÀtt ha tillgÄng till dem utan att komma till kundens plats, eftersom... Den Àr lÄng. Vi gjorde helt enkelt tunnlar för varje sÄdan Mikrotik och separerade dem i en separat pool. utan nÄgon routing, sÄ att det inte finns nÄgon koppling mellan ditt nÀtverk och klienternas nÀtverk och deras nÀtverk med varandra.
Idén föddes för att se till att nÀr jag klickar pÄ objektet jag behöver i systemet, ansluter den centrala övervakningsservern, som kÀnner till SSH-kontona för alla klienter Mikrotik, till den önskade, skapar en vidarebefordranregel till den önskade vÀrden med önskad port. Det finns flera punkter hÀr. Lösningen Àr inte universell - den fungerar bara för Mikrotik, eftersom kommandosyntaxen Àr olika för alla routrar. Dessutom mÄste sÄdana vidarebefordran raderas pÄ nÄgot sÀtt, och serverdelen av vÄrt system kunde i princip inte spÄra pÄ nÄgot sÀtt om jag hade avslutat min RDP-session. Tja, sÄdan vidarebefordran Àr ett hÄl för kunden. Men vi strÀvade inte efter universalitet, eftersom... produkten anvÀndes endast inom vÄrt företag och det fanns inga tankar pÄ att slÀppa den till allmÀnheten.
Vart och ett av problemen löstes pÄ sitt eget sÀtt. NÀr regeln skapades var denna vidarebefordran endast tillgÀnglig för en specifik extern IP-adress (frÄn vilken anslutningen initierades). SÄ ett sÀkerhetshÄl undveks. Men med varje sÄdan anslutning lades en Mikrotik-regel till pÄ NAT-sidan och rensades inte. Och alla vet att ju fler regler det finns, desto mer laddas routerns processor. Och i allmÀnhet kunde jag inte acceptera att jag en dag skulle gÄ till nÄgon Mikrotik, och det skulle finnas hundratals döda, vÀrdelösa regler.
Eftersom vÄr server inte kan spÄra anslutningsstatus, lÄt Mikrotik spÄra dem sjÀlv. Och jag skrev ett skript som stÀndigt övervakade alla vidarebefordransregler med en specifik beskrivning och kontrollerade om TCP-anslutningen hade en lÀmplig regel. Om det inte har funnits en pÄ ett tag, har anslutningen förmodligen redan slutförts och denna vidarebefordran kan raderas. Allt löste sig, manuset fungerade bra.
Förresten, hÀr Àr den:
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
}
}
Visst kunde den ha gjorts vackrare, snabbare osv, men den fungerade, laddade inte Mikrotik och gjorde ett utmÀrkt jobb. Vi kunde Àntligen ansluta till klienternas servrar och nÀtverksutrustning med bara ett klick. Utan att öppna ett VPN eller ange lösenord. Systemet har blivit riktigt bekvÀmt att arbeta med. Servicetiden minskade och vi Àgnade alla tid Ät att arbeta snarare Àn att ansluta till de nödvÀndiga objekten.
Mikrotik Backup
Vi konfigurerade sÀkerhetskopiering av alla Mikrotik till FTP. Och överlag var allt bra. Men nÀr du behövde fÄ en sÀkerhetskopia var du tvungen att öppna denna FTP och leta efter den dÀr. Vi har ett system dÀr alla routrar Àr anslutna, vi kan kommunicera med enheter via SSH. Varför gör vi det inte sÄ att sjÀlva systemet tar sÀkerhetskopior frÄn alla Mikrotik dagligen, tÀnkte jag. Och han började implementera det. Vi kopplade upp, gjorde en sÀkerhetskopia och tog den till lagring.
Skriptkod i PHP för att ta en sÀkerhetskopia frÄn 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');
?>
SÀkerhetskopieringen tas i tvÄ former - binÀr och textkonfiguration. BinÀren hjÀlper till att snabbt ÄterstÀlla den nödvÀndiga konfigurationen, och texten en lÄter dig förstÄ vad som behöver göras om det finns ett pÄtvingat utbyte av utrustning och binÀren inte kan laddas upp till den. Som ett resultat fick vi ytterligare en bekvÀm funktionalitet i systemet. Dessutom, nÀr jag lade till ny Mikrotik, behövde jag inte konfigurera nÄgonting, jag lade helt enkelt till objektet i systemet och satte ett konto för det via SSH. Sedan tog systemet sjÀlv hand om att ta backuper. Den nuvarande versionen av SaaS Veliam har Ànnu inte den hÀr funktionen, men vi kommer att portera den snart.
SkÀrmdumpar pÄ hur det sÄg ut i det interna systemet
ĂvergĂ„ng till normal databaslagring
Jag skrev redan ovan att artefakter dök upp. Ibland försvann helt enkelt hela listan med objekt i systemet, ibland nÀr man redigerade ett objekt sparades inte informationen och objektet fick döpas om tre gÄnger. Detta irriterade alla fruktansvÀrt. Försvinnandet av objekt intrÀffade sÀllan och ÄterstÀlldes enkelt genom att ÄterstÀlla just den hÀr filen, men misslyckanden vid redigering av objekt intrÀffade ganska ofta. Förmodligen gjorde jag frÄn början inte detta genom databasen eftersom det inte passade in i mina tankar hur det var möjligt att hÄlla ett trÀd med alla anslutningar i en platt tabell. Det Àr platt, men trÀdet Àr hierarkiskt. Men en bra lösning för multipel Ätkomst, och dÀrefter (i takt med att systemet blir mer komplext) transaktionella, Àr ett DBMS. Jag Àr förmodligen inte den första som stöter pÄ det hÀr problemet. Jag började googla. Det visade sig att allt redan hade uppfunnits före mig och det finns flera algoritmer som bygger ett trÀd frÄn ett platt bord. Efter att ha tittat pÄ var och en implementerade jag en av dem. Men detta var redan en ny version av systemet, eftersom... PÄ grund av detta var jag faktiskt tvungen att skriva om ganska mycket. Resultatet var naturligt, problemen med systemets slumpmÀssiga beteende försvann. Vissa kanske sÀger att felen Àr mycket amatörmÀssiga (entrÄdade skript, lagring av information som Ätkoms flera gÄnger samtidigt frÄn olika trÄdar i en fil, etc.) inom omrÄdet mjukvaruutveckling. Kanske Àr detta sant, men mitt huvudsakliga jobb var administration, och programmering var ett sidojobb för min sjÀl, och jag hade helt enkelt ingen erfarenhet av att arbeta i ett team av programmerare, dÀr sÄdana grundlÀggande saker omedelbart skulle ha föreslagits för mig av min senior kamrater. DÀrför fyllde jag alla dessa gupp pÄ egen hand, men jag lÀrde mig materialet vÀldigt bra. Och mitt jobb innebÀr ocksÄ möten med kunder, ÄtgÀrder som syftar till att försöka frÀmja företaget, en massa administrativa frÄgor inom företaget och mycket, mycket mer. Men pÄ ett eller annat sÀtt efterfrÄgades det som redan fanns. Jag och killarna anvÀnde sjÀlv produkten i vÄrt dagliga arbete. Det fanns uppriktigt sagt misslyckade idéer och lösningar som man slösade tid pÄ, men till slut stod det klart att detta inte var ett fungerande verktyg och ingen anvÀnde det och det hamnade inte i Veliam.
Helpdesk - HelpDesk
Det skulle inte vara fel att nÀmna hur HelpDesk bildades. Det hÀr Àr en helt annan historia, för... i Veliam Àr detta redan den tredje helt nya versionen, som skiljer sig frÄn alla tidigare. Nu Àr det ett enkelt system, intuitivt utan onödiga ringsignaler, med möjlighet att integrera med en domÀn, samt möjlighet att komma Ät samma anvÀndarprofil var som helst med hjÀlp av en lÀnk frÄn ett e-postmeddelande. Och viktigast av allt, det Àr möjligt att ansluta till sökanden via VNC var som helst (hemma eller pÄ kontoret) direkt frÄn applikationen utan VPN eller portvidarebefordran. Jag ska berÀtta hur vi kom fram till det hÀr, vad som hÀnde tidigare och vilka hemska beslut som togs.
Vi kopplade till anvĂ€ndare genom den vĂ€lkĂ€nda TeamViewer. Alla datorer vars anvĂ€ndare vi betjĂ€nar har TV installerad. Det första vi gjorde fel, och sedan tog bort det, var att lĂ€nka varje HD-klient till hĂ„rdvara. Hur loggade anvĂ€ndaren in i HD-systemet för att lĂ€mna en förfrĂ„gan? Förutom TV hade alla ett speciellt verktyg installerat pĂ„ sina datorer, skrivet i Lazarus (mĂ„nga mĂ€nniskor hĂ€r kommer att himla med ögonen, och kanske till och med googla vad det Ă€r, men det bĂ€sta kompilerade sprĂ„ket jag visste var Delphi, och Lazarus Ă€r nĂ€stan samma sak, bara gratis). I allmĂ€nhet lanserade anvĂ€ndaren en speciell batchfil som startade detta verktyg, som i sin tur lĂ€ste systemets HWID och efter det startades webblĂ€saren och auktorisering skedde. Varför gjordes detta? I vissa företag rĂ€knas antalet betjĂ€nade anvĂ€ndare individuellt och servicepriset för varje mĂ„nad baseras pĂ„ antalet personer. Detta Ă€r förstĂ„eligt, sĂ€ger du, men varför Ă€r det knutet till hĂ„rdvara? Mycket enkelt, nĂ„gra individer kom hem och gjorde en förfrĂ„gan frĂ„n sin hemlaptop i stil med "gör allt vackert för mig hĂ€r." Förutom att lĂ€sa systemets HWID, hĂ€mtade verktyget det aktuella Teamviewer-ID:t frĂ„n registret och överförde det Ă€ven till oss. Teamviewer har ett API för integration. Och vi gjorde den hĂ€r integrationen. Men det fanns en hake. Genom dessa API:er Ă€r det omöjligt att ansluta till anvĂ€ndarens dator nĂ€r han inte uttryckligen initierar denna session och efter att ha försökt ansluta till den mĂ„ste han ocksĂ„ klicka pĂ„ "bekrĂ€fta". Vid den tiden verkade det logiskt för oss att ingen skulle ansluta utan anvĂ€ndarens begĂ€ran, och eftersom personen Ă€r vid datorn kommer han att initiera sessionen och svara jakande pĂ„ begĂ€ran om fjĂ€rranslutning. Allt blev fel. Sökande glömde att trycka pĂ„ initiera sessionen och var tvungna att berĂ€tta detta för dem i ett telefonsamtal. Detta slösade bort tid och var frustrerande pĂ„ bĂ„da sidor av processen. Dessutom Ă€r det inte alls ovanligt med sĂ„dana ögonblick nĂ€r en person lĂ€mnar en förfrĂ„gan, men fĂ„r bara ansluta nĂ€r han gĂ„r för lunch. För problemet Ă€r inte kritiskt och han vill inte att hans arbetsprocess ska avbrytas. Han kommer dĂ€rför inte att trycka pĂ„ nĂ„gra knappar för att tillĂ„ta anslutning. SĂ„ hĂ€r dök ytterligare funktionalitet upp nĂ€r du loggade in pĂ„ HelpDesk - lĂ€sning av Teamviewers ID. Vi kĂ€nde till det permanenta lösenordet som anvĂ€ndes vid installationen av Teamviewer. Mer exakt var det bara systemet som kĂ€nde till det, eftersom det var inbyggt i installatören och i vĂ„rt system. Följaktligen fanns det en anslutningsknapp frĂ„n applikationen genom att klicka pĂ„ vilken det inte behövdes vĂ€nta pĂ„ nĂ„got, men Teamviewer öppnades omedelbart och en anslutning uppstod. Som ett resultat fanns det tvĂ„ typer av möjliga kopplingar. Genom det officiella Teamviewer API och vĂ„rt egentillverkade. Till min förvĂ„ning slutade de att anvĂ€nda den första nĂ€stan omedelbart, Ă€ven om det fanns en instruktion att anvĂ€nda den endast i speciella fall och nĂ€r anvĂ€ndaren sjĂ€lv ger klartecken. ĂndĂ„, ge mig trygghet nu. Men det visade sig att de sökande inte behövde detta. De Ă€r alla helt okej med att vara anslutna till dem utan en bekrĂ€ftelseknapp.
Byter till multithreading i Linux
FrÄgan om att pÄskynda passagen av en nÀtverksskanner för öppenheten av en förutbestÀmd lista över portar och enkel pingning av nÀtverksobjekt har lÀnge börjat uppstÄ. HÀr Àr naturligtvis den första lösningen som kommer att tÀnka pÄ multithreading. Eftersom den huvudsakliga tiden som spenderas pÄ ping Àr att vÀnta pÄ att paketet ska returneras, och nÀsta ping inte kan börja förrÀn det föregÄende paketet returneras, i företag som till och med hade 20+ servrar plus nÀtverksutrustning, fungerade detta redan ganska lÄngsamt. PoÀngen Àr att ett paket kan försvinna, men meddela inte systemadministratören omedelbart om det. Han kommer helt enkelt att sluta acceptera sÄdan spam vÀldigt snabbt. Det betyder att du mÄste pinga varje objekt mer Àn en gÄng innan du drar en slutsats om otillgÀnglighet. Utan att gÄ in pÄ för mycket detaljer Àr det nödvÀndigt att parallellisera det, för om detta inte görs kommer systemadministratören troligen att lÀra sig om problemet frÄn klienten och inte frÄn övervakningssystemet.
PHP i sig stöder inte multithreading ur lÄdan. Kan multibearbeta, du kan gaffel. Men i sjÀlva verket hade jag redan en omröstningsmekanism skriven och jag ville göra det sÄ att jag en gÄng skulle rÀkna alla noder jag behövde frÄn databasen, pinga allt pÄ en gÄng, vÀnta pÄ ett svar frÄn var och en och först efter det skriva omedelbart uppgifterna. Detta sparar pÄ antalet lÀsbegÀranden. Multithreading passade perfekt in i denna idé. För PHP finns det en PThreads-modul som lÄter dig göra riktig multithreading, Àven om det krÀvdes en hel del mixtrande för att sÀtta upp detta pÄ PHP 7.2, men det gjordes. Portskanning och ping Àr nu snabba. Och istÀllet för till exempel 15 sekunder per varv tidigare började denna process ta 2 sekunder. Det blev ett bra resultat.
Snabbrevision av nya företag
Hur kom funktionaliteten för att samla in olika mÀtvÀrden och hÄrdvaruegenskaper? Det Àr enkelt. Ibland blir vi helt enkelt beordrade att granska den nuvarande IT-infrastrukturen. Tja, samma sak Àr nödvÀndigt för att pÄskynda granskningen av en ny kund. Vi behövde nÄgot som skulle göra det möjligt för oss att komma till ett medelstort eller stort företag och snabbt ta reda pÄ vad de har. Enligt min mening blockeras ping pÄ det interna nÀtverket endast av de som vill komplicera sina egna liv, och enligt vÄr erfarenhet finns det fÄ av dem. Men det finns ocksÄ sÄdana mÀnniskor. Följaktligen kan du snabbt skanna nÀtverk för nÀrvaron av enheter med en enkel ping. Sedan kan vi lÀgga till dem och söka efter öppna portar som intresserar oss. Faktum Àr att denna funktionalitet redan existerade; det var bara nödvÀndigt att lÀgga till ett kommando frÄn den centrala servern till slaven sÄ att den skulle skanna de angivna nÀtverken och lÀgga till allt den hittade till listan. Jag glömde att nÀmna, det antogs att vi redan hade en fÀrdig bild med ett konfigurerat system (slavövervakningsserver) som vi helt enkelt kunde rulla ut frÄn klienten under en revision och koppla den till vÄrt moln.
Men resultatet av en granskning innehÄller vanligtvis en massa olika information, och en av dem Àr vilken typ av enheter som finns i nÀtverket. Först och frÀmst var vi intresserade av Windows-servrar och Windows-arbetsstationer som en del av en domÀn. Eftersom i medelstora och stora företag Àr avsaknaden av en domÀn förmodligen ett undantag frÄn regeln. För att tala ett sprÄk Àr genomsnittet, enligt min mening, 100+ personer. Det var nödvÀndigt att komma pÄ ett sÀtt att samla in data frÄn alla Windows-maskiner och servrar, med kunskap om deras IP- och domÀnadministratörskonto, men utan att installera nÄgon programvara pÄ var och en av dem. WMI-grÀnssnittet kommer till undsÀttning. Windows Management Instrumentation (WMI) betyder bokstavligen Windows-hanteringsverktyg. WMI Àr en av de grundlÀggande teknikerna för centraliserad hantering och övervakning av driften av olika delar av datorinfrastrukturen som kör Windows-plattformen. Taget frÄn wiki. DÀrefter var jag tvungen att mixtra igen för att kompilera wmic (detta Àr en WMI-klient) för Debian. Efter att allt var klart var allt som Äterstod att helt enkelt polla de nödvÀndiga noderna genom wmic för den nödvÀndiga informationen. Genom WMI kan du fÄ nÀstan all information frÄn en Windows-dator, och dessutom kan du ocksÄ styra datorn genom den, till exempel skicka den till omstart. SÄ hÀr sÄg insamlingen av information om Windows-stationer och servrar i vÄrt system ut. Utöver detta fanns aktuell information om aktuella systembelastningsindikatorer. Vi begÀr dem oftare och information om hÄrdvara mer sÀllan. Efter detta blev auditeringen lite roligare.
Beslut om distribution av programvara
SjÀlva anvÀnder vi systemet varje dag och det Àr alltid öppet för varje teknisk medarbetare. Och vi tÀnkte att vi kunde dela med andra vad vi redan har. Systemet var Ànnu inte klart att distribueras. Mycket behövde omarbetas för att den lokala versionen skulle förvandlas till SaaS. Dessa inkluderar förÀndringar i olika tekniska aspekter av systemet (fjÀrranslutningar, supporttjÀnst), analys av moduler för licensiering, sönderdelning av kunddatabaser, skalning av varje tjÀnst och utveckling av automatiska uppdateringssystem för alla delar. Men det hÀr blir den andra delen av artikeln.
Uppdatering
KĂ€lla: will.com