ISPsystem, andestage ja hüvasti! Miks ja kuidas me oma serverihalduspuldi kirjutasime

Tere! Me oleme «Hosting Technology» ja viis aastat tagasi lansseerisime VDSina — esimene VDS hostimine, mis on loodud spetsiaalselt arendajatele. Meie eesmärk on teha see sama mugavaks kui DigitalOcean, kuid vene toe, makseviiside ja serveritega Venemaal. Kuid DigitalOcean ei ole ainult usaldusväärsus ja hind, vaid ka teenus.

ISPsystemi tarkvara osutus nööriks, mis sidus meid kätega tagasituleku tee hulgas. Kolm aastat tagasi kasutasime arveldamisprogrammi Billmanager ja serverihaldustarkvara VMmanager ning mõistsime kiiresti, et kvaliteetse teenuse pakkumine ilma oma paneelita on peaaegu võimatu.

Kuidas ISPsystem tapab mugavuse

Vead

Me ei suutnud vigu ise parandada — iga kord pidime kirjutama kellegi teise tugiisikule ja ootama. Iga probleemi lahendamine nõudis kolmanda osapoole reageerimist.

ISPsystemi tugi vastas normaalselt, kuid parandused tulid alles pärast mitmeid uusi versioone, ja mitte alati ja mitte kõik. Mõningaid kriitilisi vigu parandati mitme nädala jooksul. Me pidime rahustama kliente, vabandama ja ootama, kuni ISPsystem vea parandab.

Ajavahemike oht

Uuendused võisid põhjustada ettenägematuid aegade, mis tekitas uusi vigu.

Iga värskendus oli loterii: pidime sulgema arveldamise ja tooma uuenduste jumalate juurde ohvreid — paar korda põhjustas uuendus umbes 10-15 minuti pikkuse seisaku. Meie administraatorid istusid sel ajal silme ees — me ei teadnud kunagi, kui kaua seisak kestab ja ei suutnud ennustada, millal ISPsystem otsustab välja anda uue uuenduse.

Billmanageri viiendat põlvkonda on saadud paremaks, kuid vajalike funktsioonide juurde pääsemiseks pidime installima beetaversiooni, mida uuendati igal nädalal. Kui midagi purunes, pidime andma juurdepääsu teiste arendajate jaoks, et nad midagi parandaksid.

Ebamugav paneeli liides

Kõik oli jagatud erinevatesse paneelidesse ja haldati erinevates kohtades. Näiteks maksid kliendid läbi Billmanageri, kuid VDS-i taaskäivitamine või reinstalleerimine pidi toimuma VMManageris. Meie töötajad pidid samuti akende vahel vahetama, et aidata kliendi puhul, kontrollida tema serveri koormust või vaadata, millist operatsioonisüsteemi ta kasutab.

Selline liides võtab aega — nii meie kui ka klientide aega. Sellises olukorras ei saa mugavusest, nagu DigitalOceanil, juttu olla.

Lühikesed elutsüklid sagedaste API värskendustega

Me oleme kirjutanud oma pluginaid – näiteks plugin, mis võimaldab täiendavaid makseviise, mida VMManager ei toeta.

Viimastel aastatel on VMManageril olnud suhteliselt lühike elutsükkel, kusjuures uutes versioonides võivad API muutuda muutuvas järjekorras muutuda muutuva järjekorraga muutuda muutuva järjekorraga – see rikkus meie pluginaid. Vanade versioonide tugi lõpetati kiiresti ja tuli uuendama.

Ei saa parandada

Täpsemalt on see võimalik, kuid äärmiselt ebatõhus. Litsentseerimispiirangud ei luba muudatusi lähtekoodis, saab ainult kirjutada pluginaid. Maksimaalne pluginate arv – mõned menüüelemendid, samm-sammult juhend. ISPsystem keskendub universaalsusele, kuid meie vajasime spetsialiseeritud lahendusi.

Nii sündis otsus kirjutada oma paneel. Seadsime eesmärgid:

• Kiire reageerimine vigadele, tõrgetele ja võimalus neid iseseisvalt lahendada, ilma et klient ootaks.
• Vabadus kohandada liidest vastavalt tööprotsessidele ja kliendi vajadustele.
• Tõsta kasutatavust puhta ja arusaadava disainiga.

Ja alustasime arendust.

Uue paneeli arhitektuur

Meil on iseseisev arendustiim, seega kirjutasime paneeli ise.
Peamised tööd tegi kolm inseneri – tehnilise direktori Sergei välja mõeldud arhitektuur ja serveri agent, Aleksei tegi arveldussüsteemi ning meie frontend arendas frontendi, Artysh.

Samm 1. Serveri agent

Serveri agent on Pythonis loodud veebiserver, mis haldab raamatukogu libvirt, mis omakorda haldab hypervisor Qemu-kvm.

Agent haldab kõiki teenuseid serveris: VDS-i loomine, peatamine, kustutamine, operatsioonisüsteemide paigaldamine, parameetrite muutmine ja nii edasi raamatukogu libvirt kaudu. Artikli avaldamise ajal on neid rohkem kui nelikümmend erinevat funktsiooni, mida täiendame sõltuvalt ülesandest ja kliendi vajadustest.

Teoreetiliselt oleks libvirtiga võinud hallata otse arveldussüsteemist, kuid see nõudis liiga palju täiendavat koodi ja otsustasime need funktsioonid jaotada agendi ja arveldussüsteemi vahel – arveldussüsteem teeb lihtsalt päringud agendile läbi JSON API.

Agent oli esimene, mille me tegime, kuna see ei nõudnud mingit liidest ja seda sai testida otse serveri konsoolist.

Mida andis meile serveri agent: ilm on ilmunud kiht, mis lihtsustab elu kõigile — arveldamiseks ei pea edastama suurt hulka käske, vaid piisab üksnes päringu tegemisest. Agent teeb kõik vajalikud toimingud: näiteks eraldab kettaruumi ja RAM-i.

Samm 2. Arveldamine

Meie arendaja Aleksile polnud see esimene juhtpaneel — Aleks on hostimises ammu olnud, seega mõistis ta üldiselt, mida klient vajab ja mida hostija.

Arveldamist nimetame me omavahel "juhtpaneeliks": seal on mitte ainult raha ja teenuseid, vaid ka nende haldamine, klienditugi ja palju muud.

ISPSystemilt tarkvarale ülemiseks tuli täielikult säilitada klientide varasem funktsionaalsus, üle kanda kõik kasutajate finantstegevused vanast arveldussüsteemist uude ning ka kõik teenused ja nende vahelised seosed. Uurisime, mida pakub praegune toode, seejärel konkurentide lahendusi, peamiselt DO-d ja Vultrit. Vaatasime puudusi ja eeliseid, kogusime tagasisidet inimestelt, kes töötasid vana ISPsystemi toodetega.

Uues arveldamises kasutasime kahte tehnikat: klassikaline PHP, MySQL (ja tulevikus plaanime üle minna PostgreSQL-ile), Yii2 raamistikul tagaplaanil ja VueJS esiplaanil. Tehnikad töötavad üksteisest sõltumatult, neid arendavad erinevad inimesed ning nad suhtlevad JSON API kaudu. Arendamiseks kasutasime siis ja kasutame ka praegu PHPStorm ja WebStorm JetBrainsilt ja me armastame neid väga (poisid, tere!)

Paneel on projekteeritud moodulipõhiselt: maksesüsteemide moodul, domeeniregistraatorite moodul või näiteks SSL-sertifikaatide moodul. Uue funktsiooni lisamine või vana eemaldamine on lihtne. Arhitektuuri on sisseehitatud laienemisvõimalus, sealhulgas ka tagasi poole, "rauda".

Mida me saime: juhtpaneel, mille üle meil on täielik kontroll. Nüüd parandatakse vigu tundidega, mitte nädalatega, ja uusi funktsioone rakendatakse klientide soovi järgi, mitte ISPSystemi soovide järgi.

Samm 3. Liides

Liides on meie meeskonna ühine looming.

Esmalt vaatasime, mis juhtub, kui teha ISPsystemi API ülekatte, mitte midagi radikaalselt muutmata liideses. Tulemus ei olnud liiga hea ja otsustasime kõik nullist teha.

Me uskusime, et peamine on luua loogiline liides, puhta ja minimalistliku disainiga, et saada ilus juhtpaneel. Arutasime elementide paigutust Megaplanis ja järk-järgult kujunes see liides, mida kasutajad näevad praegu juhtpaneelil.

Esimesena tekkis arvepidamise lehe disain, kuna olime juba loonud maksepluginad ISPsystemile.

Eesmine joon

Otsustasime, et paneel on SPA rakendus — madalate ressursside nõudmistega ja kiire andmete laadimisega. Meie eesmine arendaja Artšis otsustas kirjutada selle Vue'is — sellel hetkel oli Vue just ilmuma hakanud. Arvasime, et raamistik areneb dünaamiliselt nagu React, ja mõne aja pärast kasvab Vue kogukond ning ilmuvad hulk raamatukogusid. Me panustasime Vue-le ja ei kahetsenud — nüüd on front-endile uute funktsioonide lisamine, mis on juba tagaplaanil programmeeritud, kiire. Räägime paneeli eesmisest joonest eraldi artiklis.

Eesmise jooni ja tagaplaani ühendamine

Eesmine joon ühendati tagaplaaniga pushide kaudu. Palusime pingutada ja kirjutada oma töötleja, kuid nüüd toimub teabe värskendamine lehel peaaegu koheselt.

Mida me saime: paneeli liides sai lihtsamaks. Muutsime selle adaptiivseks, ning kiire koormamine võimaldab selle kasutamist isegi mobiiltelefonidel viimasel minutil enne tõusmist, ilma et oleks vaja installeerida eraldi rakendust paneeli kasutamiseks.

Samm 4. Testimine ja migreerimise skeem

Kui kõik toimis ja esimesed testid olid läbitud, tuli ülesanne migreerida. Esmalt paigaldasime arvepidamise ja alustasime selle töö testimist serveriagendi küljes.

Siis kirjutasime lihtsa skripti, mis kannab andmebaasi vanast arvepidamisest uude.

Pidime testima ja üle kontrollima peaaegu kõike, kuna andmed koondusid kolmest vanast: Billmanager, VMmanager ja IPmanager. Võib-olla olid testmigratsioonid kõige keerulisem asi, millega me uue paneeli arendamise käigus silmitsi seisime.

Pärast ümberkontrollimist sulgesime vana arvepidamise. Andmete lõplik migratsioon oli väga ärev hetk, kuid õnneks toimus see mõne minuti jooksul ja ilma märgatavate probleemideta. Oli väikesi vigu, mida me parandasime nädala jooksul. Peamine aeg kulus selle testimiseks, mis välja tuli.

Seejärel saatsime klientidele uusi kirju uue paneeli ja arveldamise aadressiga ning suunasime ümber.

Tulemus: SEE ON ELUS!

Õnnelik lõpp

Esimestest tundidest oma tarkvara tööle hakkamisest tundsime, kuidas üleminek toob endaga kaasa kõik eelised. Kood oli täielikult meie ja mugava arhitektuuriga, ning liides - puhas ja loogiline.

Esimene ülevaade pärast uue paneeli käivitamist

Käivitamise protsessi alustasime detsembris, just enne 2017. aasta uut aastat, kui koormus oli madalaim, et muuta üleminek klientidele lihtsamaks - peaaegu keegi ei tööta enne pühi.

Peamine, mida saime oma süsteemile üleminekul (välja arvatud üldine usaldusväärsus ja mugavus) - võimalus kiiresti lisada funktsioone võtmeklientidele - olla neile ees, mitte taga.

Mis edasi?

Me kasvame, kasvab andmete, klientide ja klientide andmete arv. Tagaplaanile tuli lisada Memcached-server ja kaks järjekorrahaldurit erinevate ülesannete jaoks. Esiplaanil on vahemälu ja oma järjekorrad.

Muidugi oli meil arengute käigus veel seiklusi, kui näiteks lisasime HighLoad.

Järgmises artiklis räägime, kuidas käivitasime Hi-CPU plaani: riistvara, tarkvara, milliseid ülesandeid me lahendasime ja mis me saavutame.

Allikas: habr.com