Saluton al ĉiuj, mia nomo estas Sergey Emelyanchik. Mi estas la estro de la kompanio Audit-Telecom, la ĉefa programisto kaj aŭtoro de la sistemo Veliam. Mi decidis skribi artikolon pri kiel mi kaj mia amiko kreis subkontraktan kompanion, verkis programaron por ni mem kaj poste komencis distribui ĝin al ĉiuj per la sistemo SaaS. Pri kiel mi kategorie ne kredis, ke tio eblas. La artikolo enhavos ne nur rakonton, sed ankaŭ teknikajn detalojn pri kiel la produkto Veliam estis kreita. Inkluzive de kelkaj pecoj de fontkodo. Mi rakontos al vi kiajn erarojn ni faris kaj kiel ni korektis ilin poste. Estis duboj, ĉu publikigi tian artikolon. Sed mi pensis, ke estas pli bone fari ĝin, ricevi komentojn kaj plibonigi, ol ne publikigi la artikolon kaj pensi pri kio okazus se...
antaŭhistorio
Mi laboris en unu firmao kiel IT-dungito. La firmao estis sufiĉe granda kun ampleksa retostrukturo. Mi ne traktos miajn laborrespondecojn, mi nur diros, ke ili certe ne inkluzivis la evoluon de io ajn.
Ni havis monitoradon, sed nur pro akademia intereso mi volis provi skribi mian plej simplan. La ideo estis jena: mi volis, ke ĝi estu en la reto, por ke mi facile povu eniri sen instali ajnajn klientojn kaj vidi kio okazas kun la reto de iu ajn aparato, inkluzive de poŝtelefono per Wi-Fi, kaj mi ankaŭ vere. volis rapide kompreni kio Estas ekipaĵo en la ĉambro, kiu fariĝis "mopey" ĉar... estis tre striktaj postuloj por responda tempo al tiaj problemoj. Kiel rezulto, en mia kapo naskiĝis plano skribi simplan retpaĝon sur kiu estis jpeg-fono kun retdiagramo, eltranĉi la aparatojn mem kun iliaj IP-adresoj en ĉi tiu bildo, kaj montri dinamikan enhavon supre de la bildo en la postulataj koordinatoj en formo de verda aŭ fulmanta ruĝa IP-adreso. La tasko estas fiksita, ni komencu.
Antaŭe, mi programis en Delphi, PHP, JS kaj tre supraĵe C++. Mi scias sufiĉe bone kiel funkcias retoj. VLAN, Vokado (OSPF, EIGRP, BGP), NAT. Ĉi tio sufiĉis por mi mem verki primitivan monitoran prototipon.
Mi skribis tion, kion mi planis en PHP. La Apache kaj PHP-servilo estis en Vindozo ĉar... Linukso por mi tiumomente estis io nekomprenebla kaj tre kompleksa, kiel montriĝis poste, mi tre eraris kaj multloke Linukso estas multe pli simpla ol Vindozo, sed ĉi tio estas aparta temo kaj ni ĉiuj scias, kiom da holivaroj estas. ĉi tiu temo. La Vindoza taskoplanilo tiris je malgranda intervalo (mi ne memoras precize, sed ion kiel unufoje ĉiujn tri sekundojn) PHP-skripton kiu sondis ĉiujn objektojn per banala ping kaj konservis la staton al dosiero.
system(“ping -n 3 -w 100 {$ip_address}“);
Jes, jes, labori kun datumbazo en tiu momento ankaŭ ne estis majstrita por mi. Mi ne sciis, ke eblas paraleligi procezojn, kaj trairi ĉiujn retajn nodojn daŭros longa tempo, ĉar... tio okazis en unu fadeno. Problemoj precipe ekestis kiam pluraj nodoj estis neatingeblaj, ĉar ĉiu el ili prokrastis la skripton je 300 ms. Ĉe la klientflanko estis simpla loop-funkcio kiu, je intervaloj de kelkaj sekundoj, elŝutis ĝisdatigitajn informojn de la servilo kun Ajax-peto kaj ĝisdatigis la interfacon. Nu, do, post 3 malsukcesaj ping-oj en vico, se retpaĝo kun monitorado estis malfermita en la komputilo, gaja komponaĵo ludis.
Kiam ĉio funkciis, mi estis tre inspirita de la rezulto kaj pensis ke mi povus aldoni pli al ĝi (pro miaj scio kaj kapabloj). Sed mi ĉiam ne ŝatis sistemojn kun miliono da leteroj, kiujn mi tiam pensis, kaj ankoraŭ pensas ĝis hodiaŭ, estas nenecesaj en la plej multaj kazoj. Mi volis enmeti tien nur tion, kio vere helpus min en mia laboro. Ĉi tiu principo restas fundamenta por la evoluo de Veliam ĝis hodiaŭ. Plue, mi konsciis, ke estus tre mojose, se mi ne devus daŭrigi monitoradon malfermita kaj scii pri problemoj, kaj kiam ĝi okazis, tiam malfermu la paĝon kaj vidu kie troviĝas ĉi tiu problema retnodo kaj kion fari kun ĝi poste. . Iel mi tiam ne legis retpoŝton, mi simple ne uzis ĝin. Mi trovis en la Interreto, ke ekzistas SMS-enirejoj, al kiuj vi povas sendi GET aŭ POST-peton, kaj ili sendos SMS al mia poŝtelefono kun la teksto, kiun mi skribas. Mi tuj komprenis, ke mi vere volas ĉi tion. Kaj mi komencis studi la dokumentadon. Post iom da tempo mi sukcesis, kaj nun mi ricevis SMS pri problemoj en la reto sur mia poŝtelefono kun la nomo de "falinta objekto". Kvankam la sistemo estis primitiva, ĝi estis verkita de mi mem, kaj la plej grava afero, kiu instigis min evoluigi ĝin, estis ke ĝi estis aplika programo kiu vere helpis min en mia laboro.
Kaj tiam venis la tago, kiam unu el la interretaj kanaloj malfunkciis en la laboro, kaj mia monitorado ne informis min pri tio. Ĉar Google DNS ankoraŭ pingis perfekte. Estas tempo pensi pri kiel vi povas kontroli, ke la komunika kanalo vivas. Estis malsamaj ideoj pri kiel fari tion. Mi ne havis aliron al ĉiuj ekipaĵoj. Ni devis eltrovi kiel kompreni kiu el la kanaloj estas viva, sed sen povi iel vidi ĝin sur la reto ekipaĵo mem. Tiam kolego elpensis la ideon, ke eblas, ke la itinero spuranta al publikaj serviloj povas malsami depende de kiu komunika kanalo estas nuntempe uzata por aliri la Interreton. Mi kontrolis kaj ĝi rezultis tiel. Estis malsamaj vojoj dum spurado.
system(“tracert -d -w 500 8.8.8.8”);
Do aperis alia skripto, aŭ pli ĝuste, ial la spuro estis aldonita al la fino de la sama skripto, kiu pingis ĉiujn aparatojn en la reto. Post ĉio, ĉi tio estas alia longa procezo, kiu estis efektivigita en la sama fadeno kaj malrapidigis la laboron de la tuta skripto. Sed tiam ĝi ne estis tiel evidenta. Sed iel aŭ alimaniere, li faris sian laboron, la kodo strikte difinis kian spuron devus esti por ĉiu el la kanaloj. Tiel ekfunkciis la sistemo, kiu jam monitoris (laŭte dirite, ĉar ne estis kolekto de iuj metrikoj, sed nur ping) retajn aparatojn (enkursigiloj, ŝaltiloj, wi-fi ktp.) kaj komunikajn kanalojn kun la ekstera mondo. . SMS-mesaĝoj alvenis regule kaj la diagramo ĉiam klare montris kie estas la problemo.
Plue, en ĉiutaga laboro mi devis fari kruckruciĝon. Kaj mi laciĝis iri al Cisco-ŝaltiloj ĉiufoje por vidi kiun interfacon uzi. Kiel mojose estus klaki sur objekto en monitorado kaj vidi liston de ĝiaj interfacoj kun priskriboj. Ĝi ŝparus al mi tempon. Krome, en ĉi tiu skemo ne necesus ruli Putty aŭ SecureCRT por enigi kontojn kaj komandojn. Mi nur klakis sur la monitorado, vidis tion, kio estas bezonata kaj iris fari mian laboron. Mi komencis serĉi manierojn interagi kun ŝaltiloj. Mi tuj renkontis 2 opciojn: SNMP aŭ ensaluti en la ŝaltilon per SSH, enigante la komandojn, kiujn mi bezonis, kaj analizante la rezulton. Mi malakceptis SNMP pro la komplekseco de ĝia efektivigo; mi estis senpacienca ricevi la rezulton. kun SNMP, vi devus fosi en la MIB dum longa tempo kaj, surbaze de ĉi tiuj datumoj, generi datumojn pri la interfacoj. Estas mirinda teamo ĉe CISCO
show interface statusĜi montras precize kion mi bezonas por kruciĝoj. Kial ĝeni SNMP kiam mi nur volas vidi la eligon de ĉi tiu komando, mi pensis. Post iom da tempo, mi konstatis ĉi tiun ŝancon. Klakis objekton sur retpaĝo. Okazaĵo estis deĉenigita per kiu la AJAX-kliento kontaktis la servilon, kaj ĝi, siavice, konektiĝis per SSH al la ŝaltilo, kiun mi bezonis (la akreditaĵoj estis malmolkodigitaj en la kodon, ne estis deziro rafini ĝin, fari kelkajn apartajn menuojn kie eblus ŝanĝi kontojn de la interfaco , mi bezonis la rezulton kaj rapide) mi enigis la supran komandon tie kaj resendis ĝin al la retumilo. Do mi ekvidis informojn pri interfacoj per unu klako de la muso. Ĉi tio estis ege oportuna, precipe kiam vi devis rigardi ĉi tiujn informojn pri malsamaj ŝaltiloj samtempe.
Spur-bazita kanalmonitorado finis ne esti la plej bona ideo, ĉar... foje laboro estis farita en la reto, kaj la paŭsaĵo povis ŝanĝiĝi kaj la monitorado komencis krii al mi, ke estas problemoj kun la kanalo. Sed pasiginte multan tempon por analizo, mi rimarkis, ke ĉiuj kanaloj funkcias, kaj mia monitorado trompas min. Kiel rezulto, mi petis miajn kolegojn, kiuj administris kanalformajn ŝaltilojn, simple sendi al mi syslog kiam la videbleco de najbaroj ŝanĝiĝis. Sekve, ĝi estis multe pli simpla, pli rapida kaj pli preciza ol spurado. Okazaĵo kiel perdita najbaro alvenis, kaj mi tuj elsendas sciigon pri la malfunkcio de la kanalo.
Plue, pluraj pliaj komandoj aperis klakante sur objekto, kaj SNMP estis aldonita por kolekti iujn metrikojn, kaj tio estas esence. La sistemo neniam evoluis plu. Ĝi faris ĉion, kion mi bezonis, ĝi estis bona ilo. Multaj legantoj verŝajne diros al mi, ke jam ekzistas multe da programaro en la Interreto por solvi ĉi tiujn problemojn. Sed fakte, mi ne guglis tiajn senpagajn produktojn tiam kaj mi vere volis evoluigi miajn programajn kapablojn, kaj kia pli bona maniero por puŝi ĉi tion ol vera aplika problemo. Je ĉi tiu punkto, la unua versio de monitorado estis kompletigita kaj ne plu estis modifita.
Kreo de la Audit-Telecom-firmao
Kun la paso de la tempo, mi komencis labori partatempe en aliaj kompanioj, feliĉe mia laborhoraro permesis al mi fari tion. Kiam vi laboras en malsamaj kompanioj, viaj kapabloj en diversaj areoj kreskas tre rapide, kaj viaj horizontoj bone disvolviĝas. Estas kompanioj en kiuj, kiel oni diras, vi estas svedo, rikoltisto kaj trumpetisto. Unuflanke, ĝi estas malfacila, aliflanke, se vi ne estas maldiligenta, vi fariĝas ĝeneralisto kaj tio ebligas al vi solvi problemojn pli rapide kaj pli efike ĉar vi scias kiel funkcias la rilata kampo.
Mia amiko Pavel (ankaŭ IT-specialisto) senĉese provis instigi min komenci sian propran entreprenon. Estis sennombraj ideoj kun malsamaj varioj de tio, kion ili faris. Ĉi tio estas diskutita dum jaroj. Kaj finfine, ĝi ne devintus atingi ion ajn ĉar mi estas skeptikulo, kaj Pavel estas sonĝulo. Ĉiufoje kiam li proponis ideon, mi ĉiam ne kredis je ĝi kaj rifuzis partopreni. Sed ni vere volis malfermi nian propran komercon.
Fine, ni povis trovi eblon, kiu konvenis al ni ambaŭ kaj fari tion, kion ni scias fari. En 2016, ni decidis krei IT-kompanion, kiu helpus entreprenojn solvi IT-problemojn. Ĉi tio estas la disfaldiĝo de IT-sistemoj (1C, fina servilo, poŝtservilo, ktp.), ilia bontenado, klasika HelpDesk por uzantoj kaj reto-administrado.
Sincere parolante, en la momento de la kreado de la kompanio, mi ne kredis je ĝi ĉirkaŭ 99,9%. Sed iel Paŭlo povis igi min provi, kaj rigardante antaŭen, li montriĝis prava. Pavel kaj mi pecetis po 300 rubloj, registris novan LLC "Aŭdit-Telecom", luis etan oficejon, faris bonegajn vizitkartojn, nu, ĝenerale, kiel verŝajne plej nespertaj, komencaj komercistoj, kaj komencis serĉi klientojn. Trovi klientojn estas tute alia rakonto. Eble ni skribos apartan artikolon kadre de la kompania blogo se iu interesiĝas. Malvarmaj vokoj, flugfolioj, ktp. Ĉi tio ne donis rezultojn. Kiel mi legas nun el multaj rakontoj pri komerco, iel aŭ alie, multe dependas de sorto. Ni estis bonŝancaj. kaj laŭvorte kelkajn semajnojn post la kreo de la firmao, mia frato Vladimiro kontaktis nin, kiu alportis al ni nian unuan klienton. Mi ne enuos vin per la detaloj pri laboro kun klientoj, pri tio ne temas la artikolo, mi nur diros, ke ni iris por revizio, identigis kritikajn areojn kaj ĉi tiuj areoj rompiĝis dum la decido estis farita ĉu fari. kunlaboru kun ni daŭrante kiel subkontraktantoj. Post tio, pozitiva decido tuj estis farita.
Tiam, ĉefe per buŝo-de-buŝo tra amikoj, komencis aperi aliaj servaj kompanioj. Helpdesk estis en unu sistemo. Konektoj al retaj ekipaĵoj kaj serviloj estas malsamaj, aŭ pli ĝuste malsamaj. Kelkaj homoj konservis ŝparvojojn, aliaj uzis RDP-adreslibrojn. Monitorado estas alia aparta sistemo. Estas tre maloportune por teamo labori en malsimilaj sistemoj. Gravaj informoj estas perditaj de vido. Nu, ekzemple, la fina servilo de la kliento fariĝis neatingebla. Aplikoj de uzantoj de ĉi tiu kliento tuj ricevas. La subtena specialisto malfermas peton (ĝi estis ricevita per telefono). Se incidentoj kaj petoj estus registritaj en unu sistemo, tiam la subtena specialisto tuj vidos, kio estas la problemo de la uzanto kaj rakontus al li pri ĝi, samtempe konektiĝi al la postulata objekto por ellabori la situacion. Ĉiuj konscias pri la taktika situacio kaj harmonie laboras. Ni ne trovis sistemon, kie ĉio ĉi estas kombinita. Evidentiĝis, ke estas tempo fari nian propran produkton.
Daŭra laboro pri via monitora sistemo
Estis klare, ke la sistemo, kiu estis skribita pli frue, estas tute maltaŭga por la nunaj taskoj. Nek laŭ funkcieco nek laŭ kvalito. Kaj oni decidis skribi la sistemon de nulo. Grafike ĝi devus aspekti tute alie. Ĝi devis esti hierarkia sistemo, por ke eblus rapide kaj oportune malfermi la ĝustan objekton por la ĝusta kliento. La skemo kiel en la unua versio estis absolute ne pravigita en la nuna kazo, ĉar La klientoj estas malsamaj kaj tute ne gravis, en kiu loko troviĝas la ekipaĵo. Ĉi tio jam estis transdonita al la dokumentado.
Do, la taskoj:
- Hierarkia strukturo;
- Ia servila parto, kiu povas esti metita en la lokon de la kliento en la formo de virtuala maŝino por kolekti la metrikojn, kiujn ni bezonas kaj sendi ĝin al la centra servilo, kiu resumos ĉion ĉi kaj montros ĝin al ni;
- Atentigoj. Tiuj, kiujn oni ne povas maltrafi, ĉar... tiutempe ne eblis al iu sidi kaj nur rigardi la monitoron;
- Aplika sistemo. Komenciĝis aperi klientoj, por kiuj ni servis ne nur servilojn kaj retajn ekipaĵojn, sed ankaŭ laborstaciojn;
- Kapablo rapide konekti al serviloj kaj ekipaĵoj de la sistemo;
La taskoj estas fiksitaj, ni komencas skribi. Survoje, prilaborado de petoj de klientoj. Tiutempe ni estis jam 4. Ni komencis skribi ambaŭ partojn samtempe: la centra servilo kaj la servilo por instalado al klientoj. Ĝis ĉi tiu punkto, Linukso ne plu estis fremda al ni kaj estis decidite ke la virtualaj maŝinoj kiujn klientoj havus estus sur Debiano. Ne estos instaliloj, ni nur faros servilan partprojekton sur unu specifa virtuala maŝino, kaj poste ni nur klonos ĝin al la dezirata kliento. Ĉi tio estis alia eraro. Poste evidentiĝis, ke en tia skemo la ĝisdatiga mekanismo estis tute neevoluinta. Tiuj. ni estis aldonantaj iun novan funkcion, kaj tiam estis la tuta problemo distribui ĝin al ĉiuj klientserviloj, sed ni revenos al ĉi tio poste, ĉio en ordo.
Ni faris la unuan prototipon. Li povis ping la klientajn retajn aparatojn kaj servilojn, kiujn ni bezonis, kaj sendi ĉi tiujn datumojn al nia centra servilo. Kaj li, siavice, ĝisdatigis ĉi tiujn datumojn amase sur la centra servilo. Ĉi tie mi skribos ne nur rakonton pri kiel kaj kio sukcesis, sed ankaŭ kiaj amatorecaj eraroj estis faritaj kaj kiel poste mi devis pagi por ĝi kun la tempo. Do, la tuta arbo de objektoj estis konservita en unu ununura dosiero en la formo de seriigita objekto. Dum ni konektis plurajn klientojn al la sistemo, ĉio estis pli-malpli normala, kvankam foje estis kelkaj artefaktoj kiuj estis tute nekompreneblaj. Sed kiam ni konektis dekduon da serviloj al la sistemo, mirakloj komencis okazi. Foje, pro iu nekonata kialo, ĉiuj objektoj en la sistemo simple malaperis. Gravas rimarki ĉi tie, ke la serviloj, kiujn la klientoj sendis datumojn al la centra servilo ĉiujn kelkajn sekundojn per POST-peto. Atenta leganto kaj sperta programisto jam divenis, ke ekzistas problemo de multobla aliro al la dosiero mem, en kiu la seriigita objekto estis stokita de malsamaj fadenoj samtempe. Kaj ĝuste kiam tio okazis, mirakloj okazis kun la malapero de objektoj. La dosiero simple fariĝis malplena. Sed ĉio ĉi ne estis malkovrita tuj, sed nur dum funkciado kun pluraj serviloj. Dum ĉi tiu tempo, haveno skanado funkcio estis aldonita (la serviloj sendis al la centra ne nur informojn pri la havebleco de aparatoj, sed ankaŭ pri la havenoj malfermitaj sur ili). Ĉi tio estis farita per vokado de la komando:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
la rezultoj ofte estis malĝustaj kaj skanadoj daŭris longan tempon por kompletigi. Mi tute forgesis pri ping, ĝi estis farita per fping:
system("fping -r 3 -t 100 {$this->ip}");
Ĉi tio ankaŭ ne estis paraleligita kaj tial la procezo estis tre longa. Poste, la tuta listo de IP-adresoj necesaj por konfirmo estis tuj sendita al fping, kaj reen ni ricevis pretan liston de tiuj, kiuj respondis. Male al ni, fping povis paraleligi procezojn.
Alia komuna rutina laboro estis starigi kelkajn servojn per RETEJO. Nu, ekzemple, ECP de MS Exchange. Esence ĝi estas nur ligilo. Kaj ni decidis, ke ni devas povi aldoni tiajn ligilojn rekte al la sistemo, por ne devi serĉi en la dokumentaro aŭ ie aliloke en legosignoj kiel aliri la ECP de specifa kliento. Jen kiel aperis la koncepto de ligiloj de rimedoj por la sistemo, ilia funkcieco disponeblas ĝis hodiaŭ kaj ne ŝanĝiĝis, nu, preskaŭ.
Kiel rimedligoj funkcias en Veliam
Foraj konektoj
Jen kiel ĝi aspektas en ago en la nuna versio de Veliam
Unu el la taskoj estis rapide kaj oportune konektiĝi al serviloj, el kiuj jam estis multaj (pli ol cent) kaj ordigi milionojn da antaŭkonservitaj RDP-mallongigoj estis ege maloportuna. Necesis ilo. Estas programaro en la Interreto, kiu estas io kiel adresaro por tiaj RDP-konektoj, sed ili ne estas integritaj kun la monitora sistemo, kaj kontoj ne povas esti konservitaj. Enigi kontojn por malsamaj klientoj ĉiufoje estas pura infero kiam vi konektas dekojn da fojoj tage al malsamaj serviloj. Kun SSH, aferoj estas iom pli bonaj; ekzistas multaj bonaj programoj, kiuj permesas vin organizi tiajn konektojn en dosierujojn kaj memori la kontojn de ili. Sed estas 2 problemoj. La unua estas, ke ni ne trovis ununuran programon por RDP kaj SSH-konektoj. La dua estas, ke se iam mi ne estas ĉe mia komputilo kaj mi devas rapide konekti, aŭ mi nur reinstalis la sistemon, mi devos iri en la dokumentadon por rigardi la konton de ĉi tiu kliento. Estas maloportuna kaj tempoperdo.
La hierarkia strukturo, kiun ni bezonis por klientserviloj, jam estis disponebla en nia interna produkto. Mi nur devis eltrovi kiel ligi rapidajn konektojn al la necesaj ekipaĵoj tie. Por komenci, almenaŭ ene de via reto.
Konsiderante la fakton, ke la kliento en nia sistemo estis retumilo, kiu ne havas aliron al la lokaj rimedoj de la komputilo, por simple lanĉi la aplikaĵon, kiun ni bezonis per iu komando, oni inventis fari ĉion per la "Vindozo". kutima url-skemo”. Tiel aperis certa "kromaĵo" por nia sistemo, kiu simple inkludis Putty kaj Remote Desktop Plus kaj, dum instalado, simple registris la URI-skemon en Vindozo. Nun, kiam ni volis konektiĝi al objekto per RDP aŭ SSH, ni klakis ĉi tiun agon en nia sistemo kaj la Propra URI funkciis. La norma mstsc.exe konstruita en Vindozo aŭ mastiko, kiu estis parto de la "kromaĵo", estis lanĉita. Mi metis la vorton kromaĵo inter citiloj ĉar ĉi tio ne estas retumilo en la klasika senco.
Almenaŭ tio estis io. Konvena adreslibro. Krome, en la kazo de Putty, ĉio estis ĝenerale bona; oni povus doni al ĝi IP-konektojn, ensaluton kaj pasvorton kiel enigajn parametrojn. Tiuj. Ni jam konektiĝis al Linukso-serviloj en nia reto per unu klako sen enigi pasvortojn. Sed kun RDP ne estas tiel simpla. Norma mstsc ne povas provizi akreditaĵojn kiel parametrojn. Remote Desktop Plus venis al la savo. Li permesis tion okazi. Nun ni povas fari sen ĝi, sed dum longa tempo ĝi estis fidela asistanto en nia sistemo. Kun HTTP(S) retejoj ĉio estas simpla, tiaj objektoj simple malfermiĝas en la retumilo kaj jen ĝi. Konvena kaj praktika. Sed ĉi tio estis feliĉo nur en la interna reto.
Ĉar ni solvis la vastan plimulton de problemoj malproksime de la oficejo, la plej facila afero estis disponigi VPN-ojn al klientoj. Kaj tiam eblis konekti al ili de nia sistemo. Sed ĝi estis ankoraŭ iom maloportuna. Por ĉiu kliento, estis necese konservi amason da memoritaj VPN-konektoj sur ĉiu komputilo, kaj antaŭ ol konekti al iu ajn, necesis ebligi la respondan VPN. Ni uzis ĉi tiun solvon dum sufiĉe longa tempo. Sed la nombro da klientoj pliiĝas, la nombro da VPN-oj ankaŭ pliiĝas, kaj ĉio ĉi komencis streĉi kaj io devis esti farita pri tio. Larmoj precipe venis al miaj okuloj post reinstalado de la sistemo, kiam mi devis reenigi dekojn da VPN-konektoj en nova Vindoza profilo. Ĉesu toleri ĉi tion, mi diris, kaj ekpensis pri tio, kion mi povus fari pri tio.
Okazis, ke ĉiuj klientoj havis aparatojn de la konata kompanio Mikrotik kiel enkursigiloj. Ili estas tre funkciaj kaj oportunaj por plenumi preskaŭ ajnan taskon. La malavantaĝo estas, ke ili estas "kaptitaj". Ni solvis ĉi tiun problemon simple fermante ĉian aliron de ekstere. Sed necesis iel havi aliron al ili sen veni al la loko de la kliento, ĉar... ĝi estas longa. Ni simple faris tunelojn por ĉiu tia Mikrotik kaj apartigis ilin en apartan naĝejon. sen iu ajn enrutigo, por ke ne estu konekto de via reto kun la retoj de klientoj kaj iliaj retoj inter si.
La ideo naskiĝis por certigi, ke kiam mi alklakas la objekton, kiun mi bezonas en la sistemo, la centra monitora servilo, konante la SSH-kontojn de ĉiuj kliento Mikrotik, konektas al la dezirata, kreas plusendan regulon al la dezirata gastiganto kun la postulata haveno. Estas pluraj punktoj ĉi tie. La solvo ne estas universala - ĝi funkcios nur por Mikrotik, ĉar la komanda sintakso estas malsama por ĉiuj enkursigiloj. Ankaŭ, tiaj plusendoj tiam devis esti iel forigitaj, kaj la servila parto de nia sistemo esence ne povis spuri iel ajn ĉu mi finis mian RDP-sesion. Nu, tia plusendo estas truo por la kliento. Sed ni ne serĉis universalecon, ĉar... la produkto estis uzata nur ene de nia kompanio kaj ne estis pensoj liberigi ĝin al la publiko.
Ĉiu el la problemoj estis solvita laŭ sia maniero. Kiam la regulo estis kreita, ĉi tiu plusendo estis disponebla nur por unu specifa ekstera IP-adreso (de kiu la konekto estis pravigita). Do sekureca truo estis evitita. Sed kun ĉiu tia konekto, Mikrotik-regulo estis aldonita al la NAT-paĝo kaj ne estis malbarita. Kaj ĉiuj scias, ke ju pli da reguloj estas, des pli la procesoro de la enkursigilo estas ŝarĝita. Kaj ĝenerale, mi ne povis akcepti, ke iam mi iros al iu Mikrotik, kaj estos centoj da mortintaj, senutilaj reguloj.
Ĉar nia servilo ne povas spuri la konektan staton, lasu Mikrotik spuri ilin mem. Kaj mi skribis skripton, kiu konstante monitoris ĉiujn plusendajn regulojn kun specifa priskribo kaj kontrolis ĉu la TCP-konekto havas taŭgan regulon. Se ne ekzistas unu dum iom da tempo, tiam la konekto verŝajne jam finiĝis kaj ĉi tiu plusendado povas esti forigita. Ĉio funkciis, la skripto funkciis bone.
Cetere, jen ĝi:
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
}
}
Certe oni povus fari ĝin pli bela, pli rapide, ktp., sed ĝi funkciis, ne ŝargis Mikrotik kaj faris bonegan laboron. Ni finfine povis konektiĝi al serviloj kaj retaj ekipaĵoj de klientoj per nur unu klako. Sen malfermi VPN aŭ enigi pasvortojn. La sistemo fariĝis vere oportuna por labori. Servotempo estis reduktita, kaj ni ĉiuj pasigis tempon laborante prefere ol konektiĝi al la necesaj objektoj.
Mikrotik Rezervo
Ni agordis sekurkopion de ĉiuj Mikrotik al FTP. Kaj entute ĉio estis bona. Sed kiam vi bezonis akiri sekurkopion, vi devis malfermi ĉi tiun FTP kaj serĉi ĝin tie. Ni havas sistemon, kie ĉiuj enkursigiloj estas konektitaj; ni povas komuniki kun aparatoj per SSH. Kial ni ne faras, ke la sistemo mem prenas sekurkopiojn de ĉiuj Mikrotik ĉiutage, mi pensis. Kaj li komencis efektivigi ĝin. Ni konektis, faris sekurkopion kaj portis ĝin al stokado.
Skriptokodo en PHP por preni sekurkopion de 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');
?>
La sekurkopio estas prenita en du formoj - duuma kaj teksta agordo. La binaro helpas rapide restarigi la bezonatan agordon, kaj la teksta ebligas al vi kompreni, kion oni devas fari, se estas devigita anstataŭigo de ekipaĵo kaj la binaro ne povas esti alŝutita al ĝi. Kiel rezulto, ni ricevis alian oportunan funkcion en la sistemo. Krome, aldonante novan Mikrotik, ne necesis agordi ion ajn; mi simple aldonis la objekton al la sistemo kaj starigis konton por ĝi per SSH. Tiam la sistemo mem zorgis pri sekurkopioj. La nuna versio de SaaS Veliam ankoraŭ ne havas ĉi tiun funkcion, sed ni portos ĝin baldaŭ.
Ekrankopioj de kiel ĝi aspektis en la interna sistemo
Transiro al normala datumbaza stokado
Mi jam skribis supre, ke aperis artefaktoj. Foje la tuta listo de objektoj en la sistemo simple malaperis, foje dum redaktado de objekto, la informoj ne estis konservitaj kaj la objekto devis esti renomita trifoje. Ĉi tio terure incitis ĉiujn. La malapero de objektoj okazis malofte, kaj estis facile restarigita per restarigo de ĉi tiu sama dosiero, sed malsukcesoj dum redaktado de objektoj okazis sufiĉe ofte. Verŝajne, mi komence ne faris tion per la datumbazo ĉar ne kongruis en mia menso, kiel eblis konservi arbon kun ĉiuj konektoj en plata tabelo. Ĝi estas plata, sed la arbo estas hierarkia. Sed bona solvo por multobla aliro, kaj poste (ĉar la sistemo iĝas pli kompleksa) transakcia, estas DBMS. Mi verŝajne ne estas la unua, kiu renkontis ĉi tiun problemon. Mi komencis gugli. Montriĝis, ke ĉio jam estis inventita antaŭ mi kaj ekzistas pluraj algoritmoj, kiuj konstruas arbon el plata tablo. Rigardante ĉiun, mi efektivigis unu el ili. Sed ĉi tio jam estis nova versio de la sistemo, ĉar... Fakte, pro tio, mi devis reverki sufiĉe multe. La rezulto estis natura, la problemoj de hazarda konduto de la sistemo foriris. Iuj povus diri, ke la eraroj estas tre amatoraj (unu-fadenaj skriptoj, konservado de informoj, kiuj estis aliritaj plurfoje samtempe de malsamaj fadenoj en dosiero, ktp.) en la kampo de programaro. Eble ĉi tio estas vera, sed mia ĉefa tasko estis administrado, kaj programado estis flanka tumulto por mia animo, kaj mi simple ne havis sperton laboranta en teamo de programistoj, kie tiaj bazaj aferoj estus tuj proponitaj al mi de mia altrangulo. kamaradoj. Tial mi plenigis ĉiujn ĉi tiujn ŝvelaĵojn per mi mem, sed mi lernis la materialon tre bone. Kaj ankaŭ, mia laboro implikas renkontiĝojn kun klientoj, agojn celantajn provi promocii la firmaon, amason da administraj aferoj ene de la firmao, kaj multe, multe pli. Sed iel aŭ alie, kio jam estis tie estis postulata. La infanoj kaj mi mem uzis la produkton en nia ĉiutaga laboro. Estis sincere malsukcesaj ideoj kaj solvoj, pri kiuj tempo malŝparis, sed finfine evidentiĝis, ke tio ne estas laborilo kaj neniu uzis ĝin kaj ĝi ne finiĝis en Veliam.
Helpdesk - Helpdesk
Ne estus malbone mencii kiel HelpDesk estis formita. Ĉi tio estas tute alia rakonto, ĉar... en Veliam tio jam estas la 3-a tute nova versio, kiu estas malsama al ĉiuj antaŭaj. Nun ĝi estas simpla sistemo, intuicia sen nenecesaj sonoriloj kaj fajfoj, kun la kapablo integriĝi kun domajno, kaj ankaŭ la kapablo aliri la saman uzantprofilon de ie ajn uzante ligilon de retpoŝto. Kaj plej grave, estas eble konekti al la kandidato per VNC de ie ajn (hejme aŭ en la oficejo) rekte de la aplikaĵo sen VPN aŭ haveno plusendado. Mi rakontos al vi kiel ni venis al ĉi tio, kio okazis antaŭe kaj kiaj teruraj decidoj estis faritaj.
Ni konektis al uzantoj per la konata TeamViewer. Ĉiuj komputiloj, kies uzantoj ni servas, havas televidilon instalita. La unua afero, kiun ni faris malbone, kaj poste forigis ĝin, estis ligi ĉiun HD-klienton al aparataro. Kiel la uzanto ensalutis en la HD-sistemon por lasi peton? Krom televido, ĉiuj havis specialan ilon instalitan en siaj komputiloj, skribitan en Lazaro (multaj homoj ĉi tie turnos la okulojn, kaj eble eĉ iros Guglon kio ĝi estas, sed la plej bona kompilita lingvo kiun mi konis estis Delfo, kaj Lazaro estas preskaŭ la sama afero, nur senpage). Ĝenerale, la uzanto lanĉis specialan batan dosieron, kiu lanĉis ĉi tiun ilon, kiu siavice legis la HWID de la sistemo kaj post tio la retumilo estis lanĉita kaj rajtigo okazis. Kial ĉi tio estis farita? En iuj kompanioj, la nombro da servitaj uzantoj estas kalkulita individue, kaj la servoprezo por ĉiu monato baziĝas sur la nombro da homoj. Ĉi tio estas komprenebla, vi diras, sed kial ĝi estas ligita al aparataro? Ĝi estas tre simpla, kelkaj individuoj venis hejmen kaj faris peton de sia hejma tekkomputilo en la stilo "faru ĉion bela por mi ĉi tie." Krom legi la sistemon HWID, la utileco eltiris la nunan Teamviewer-ID el la registro kaj ankaŭ transdonis ĝin al ni. Teamviewer havas API por integriĝo. Kaj ni faris ĉi tiun integriĝon. Sed estis unu kapto. Per ĉi tiuj API-oj, estas neeble konektiĝi al la komputilo de la uzanto kiam li ne eksplicite iniciatas ĉi tiun sesion kaj post provi konektiĝi al ĝi, li ankaŭ devas alklaki "konfirmi". Tiutempe ŝajnis al ni logike, ke neniu konektu sen la peto de la uzanto, kaj ĉar la persono estas ĉe la komputilo, li komencos la sesion kaj respondos jese al la fora konektopeto. Ĉio rezultis malbone. Kandidatoj forgesis premi komenci la sesion, kaj devis diri tion al ili en telefona konversacio. Ĉi tiu malŝparis tempon kaj estis frustranta ambaŭflanke de la procezo. Krome, estas tute ne malofte por tiaj momentoj, kiam homo lasas peton, sed rajtas konekti nur kiam li foriras por tagmanĝi. Ĉar la problemo ne estas kritika kaj li ne volas, ke lia laborprocezo estu interrompita. Sekve, li ne premos neniujn butonojn por permesi konekton. Tiel aperis plia funkcio dum ensaluto en HelpDesk - legante la ID de Teamviwer. Ni sciis la konstantan pasvorton, kiu estis uzata dum la instalado de Teamviwer. Pli precize, nur la sistemo sciis ĝin, ĉar ĝi estis enkonstruita en la instalilon kaj en nian sistemon. Sekve, estis konekta butono de la aplikaĵo klakante sur kiu ne necesis atendi ion ajn, sed Teamviewer tuj malfermiĝis kaj konekto okazis. Kiel rezulto, ekzistis du specoj de eblaj ligoj. Per la oficiala Teamviewer API kaj nia memfarita. Je mia surprizo, ili ĉesis uzi la unuan preskaŭ tuj, kvankam estis instrukcio uzi ĝin nur en specialaj kazoj kaj kiam la uzanto mem donas la permeson. Tamen donu al mi sekurecon nun. Sed montriĝis, ke la kandidatoj ne bezonas ĉi tion. Ili ĉiuj tute bone estas konektitaj al ili sen konfirma butono.
Ŝanĝi al multifadenado en Linukso
La demando pri rapidigo de la trairejo de reto-skanilo por la malfermo de antaŭdeterminita listo de havenoj kaj simpla pingado de retaj objektoj jam delonge ekestis. Ĉi tie, kompreneble, la unua solvo, kiu venas al la menso, estas multifadenado. Ĉar la ĉefa tempo pasigita por ping atendas ke la pako estos resendita, kaj la sekva ping ne povas komenciĝi ĝis la antaŭa pako estas resendita, en kompanioj kiuj eĉ havis 20+ servilojn plus retajn ekipaĵojn, tio jam funkciis sufiĉe malrapide. La afero estas, ke unu pakaĵo povas malaperi, sed ne tuj sciigu pri ĝi la sistemadministranton. Li simple ĉesos akcepti tian spamon tre rapide. Ĉi tio signifas, ke vi devas pingi ĉiun objekton pli ol unufoje antaŭ ol fari konkludon pri nealirebleco. Sen eniri tro da detaloj, necesas paraleligi ĝin, ĉar se ĉi tio ne estas farita, tiam plej verŝajne la administranto de la sistemo lernos pri la problemo de la kliento, kaj ne de la monitora sistemo.
PHP mem ne subtenas multfadenadon el la skatolo. Kapabla de multiprocesado, vi povas forkiĝi. Sed, fakte, mi jam havis voĉdonan mekanismon skribitan kaj mi volis fari ĝin tiel, ke mi iam kalkulu ĉiujn nodojn, kiujn mi bezonis el la datumbazo, ping ĉion samtempe, atendu respondon de ĉiu kaj nur post tio tuj skribu la datumoj. Ĉi tio ŝparas la nombron da legpetoj. Multithreading perfekte persvadas en ĉi tiu ideo. Por PHP ekzistas PThreads-modulo, kiu ebligas al vi fari veran multifadenadon, kvankam necesis sufiĉe da ĝustigado por agordi ĉi tion sur PHP 7.2, sed ĝi estis farita. Portskanado kaj ping nun estas rapidaj. Kaj anstataŭ, ekzemple, 15 sekundojn po rondiro pli frue, ĉi tiu procezo komencis daŭri 2 sekundojn. Estis bona rezulto.
Rapida revizio de novaj kompanioj
Kiel okazis la funkcieco por kolekti diversajn metrikojn kaj aparatarajn karakterizaĵojn? Ĝi estas simpla. Foje ni simple estas ordonitaj revizii la nunan IT-infrastrukturon. Nu, la sama afero estas necesa por akceli la revizion de nova kliento. Ni bezonis ion, kio permesus al ni veni al meza aŭ granda kompanio kaj rapide eltrovi, kion ili havas. Laŭ mi, ping en la interna reto estas blokita nur de tiuj, kiuj volas kompliki sian propran vivon, kaj laŭ nia sperto estas malmultaj el ili. Sed ekzistas ankaŭ tiaj homoj. Sekve, vi povas rapide skani retojn por la ĉeesto de aparatoj per simpla ping. Tiam ni povas aldoni ilin kaj skani por malfermitaj havenoj kiuj interesas nin. Fakte, ĉi tiu funkcio jam ekzistis; necesis nur aldoni komandon de la centra servilo al la sklava por ke ĝi skanu la specifitajn retojn kaj aldonu ĉion, kion ĝi trovis al la listo. Mi forgesis mencii, oni supozis, ke ni jam havis pretan bildon kun agordita sistemo (sklava monitora servilo), kiun ni simple povus elŝuti de la kliento dum revizio kaj konekti ĝin al nia nubo.
Sed la rezulto de revizio kutime inkluzivas amason da malsamaj informoj, kaj unu el ili estas kiaj aparatoj estas en la reto. Antaŭ ĉio, ni interesiĝis pri Vindozaj serviloj kaj Vindozaj laborstacioj kiel parto de domajno. Ĉar en mezaj kaj grandaj kompanioj la manko de domajno verŝajne estas escepto al la regulo. Por paroli unu lingvon, la mezumo, laŭ mi, estas 100+ homoj. Necesis elpensi manieron kolekti datumojn de ĉiuj Vindozaj maŝinoj kaj serviloj, sciante ilian IP kaj domajnan administran konton, sed sen instali ajnan programaron sur ĉiu el ili. La interfaco WMI venas al la savo. Windows Management Instrumentation (WMI) laŭvorte signifas Vindozaj administradiloj. WMI estas unu el la bazaj teknologioj por centralizita administrado kaj monitorado de la funkciado de diversaj partoj de la komputila infrastrukturo prizorganta la Vindozan platformon. Prenite el vikio. Poste, mi devis denove tuŝeti por kompili wmic (ĉi tio estas WMI-kliento) por Debiano. Post kiam ĉio estis preta, restis nur simple baloti la necesajn nodojn per wmic por la necesaj informoj. Per WMI oni povas ricevi preskaŭ ajnajn informojn de Vindoza komputilo, kaj krome, oni povas ankaŭ kontroli la komputilon per ĝi, ekzemple, sendi ĝin por rekomenci. Tiel aperis la kolekto de informoj pri Vindozaj stacioj kaj serviloj en nia sistemo. Aldone al ĉi tio, estis aktuala informo pri nunaj sistemaj ŝarĝindikiloj. Ni petas ilin pli ofte, kaj informojn pri aparataro malpli ofte. Post tio, revizio fariĝis iom pli agrabla.
Decido pri distribuo de programaro
Ni mem uzas la sistemon ĉiutage, kaj ĝi ĉiam estas malfermita por ĉiu teknika dungito. Kaj ni pensis, ke ni povus dividi kun aliaj tion, kion ni jam havas. La sistemo ankoraŭ ne estis preta por esti distribuata. Multo devis esti reverkita por ke la loka versio fariĝu SaaS. Ĉi tiuj inkluzivas ŝanĝojn en diversaj teknikaj aspektoj de la sistemo (foraj konektoj, helpservo), analizo de moduloj por licencado, sharding de klientdatumbazoj, skalo de ĉiu servo, kaj evoluo de aŭto-ĝisdatigaj sistemoj por ĉiuj partoj. Sed ĉi tio estos la dua parto de la artikolo.
Ĝisdatigu
fonto: www.habr.com