Pilve juhttasand
Pilve juhttasand on liideste, API-de ja teenuste kiht, mis võimaldab infrastruktuuri hankida, seadistada ja hallata — eraldiseisev andmetasandist, mis tegelikult käitab teie töökoormusi ja liigutab teie andmeliiklust. Iga teenusepakkuja pakub oma juhttasandit; termin hõlmab ka süsteeme, mis haldavad mitut teenusepakkujat ühe tasandina.
Igal infrastruktuuril on kaks eraldi kihti. Andmetasand on infrastruktuur ise: virtuaalmasinad, mis käitavad teie rakendust, võrk, mis liigutab nendevahel pakette, ketas, mis teenindab lugemis- ja kirjutamistoiminguid. Juhttasand on kõik, mida kasutate, et otsustada, milline see infrastruktuur peaks välja nägema, ja seda muuta — API, konsool, käsurea liides (CLI), õiguste haldamise süsteem, mis otsustab, kellel on lubatud muudatusi teha. Kui loote pilvekonsoolis virtuaalmasina, muudate kettamahtu või avate tulemüüris pordi, kasutate juhttasandit. Käivituv eksemplar, lisandunud gigabaidid, mis muutuvad kättesaadavaks, liiklus, mis hakkab voolama — see kõik on andmetasand, mis reageerib sellele, mida juhttasand talle käskis teha.
See vahe muutub kasulikumaks, kui meeskond kasutab rohkem kui üht teenusepakkujat. AWS-il on oma juhttasand. Sama kehtib Google Cloudi, Azure'i, Hetzneri ja iga teise teenusepakkuja kohta — igaühel on oma konsool, oma API kuju, oma juurdepääsuandmed, oma arusaam sellest, kuidas nimetatakse 'turvarühma' (security group) või 'tulemüürireeglit'. Meeskond, kes kasutab kolme pilve ja kahtkümmet füüsilist serverit, opereerib tegelikult kolme või nelja eraldi juhttasandiga korraga, pluss kõike seda, mida nad kasutavad ühegi pilve alla mittekuuluvate serverite haldamiseks. Miski ei sunni neid juhttasandeid omavahel kokku sobima ja miski väljaspool teie enda protsessi ei taga, et ühes tehtud muudatus oleks nähtav kellelegi, kes vaatab teist.
Mõistet 'pilve juhttasand' kasutatakse ka kitsamalt — Kubernetese sees on juhttasand API-server, ajastaja (scheduler) ja kontrollerihaldur (controller-manager), mis otsustavad, kus podid töötavad, erinevalt kubelettidest ja konteineritest, mis neid sõlmedes tegelikult käitavad. 'Multi-cloud' ehk mitme pilve või 'ühtne' juhttasand laiendab sama ideed teenusepakkujate üleselt: üks koht, kust näha infrastruktuuri, mis füüsiliselt paikneb mitmes erinevas kontos, regioonis ja teenusepakkuja juures, ning selle üle tegutseda, selle asemel et kasutada iga teenusepakkuja jaoks eraldi liidest. See ei asenda aluseks olevaid teenusepakkujate juhttasandeid — päring jõuab ikkagi API-kõnena kohale AWS-i, Hetzneri või füüsilisel serveril töötava fleet agent'ini —, vaid asetseb nende ees, nii et muudatuse tegija peab õppima tundma ainult üht süsteemi.
Miks see vahe operatiivselt oluline on
Enamik infrastruktuuriga seotud intsidente ja auditilünki taandub juhttasandi, mitte andmetasandi probleemidele: muudatus, mida keegi ei logi, õigus, mida keegi ei tühista, tulemüürireegel, mis avatakse ühe teenusepakkuja konsoolis ja mida keegi teine meeskonnas ei näe. Kui igal pilvel on oma juhttasand ja oma auditijälg, muutub küsimus „kes ja millal seda muutis" küsimuseks, millele vastate, logides sisse kolme või nelja erinevasse konsooli ja võrreldes ajatemplid käsitsi — või ei vasta te sellele üldse. Vastavusraamistike, näiteks NIS2 alla kuuluvate meeskondade jaoks pole see lünk pelgalt ebamugav: muudatuste ajalugu, juurdepääsukontroll ja intsidenditõendid on täpselt see, mida audiitor või regulaator esimesena küsib, ning killustunud juhttasand on põhjus, miks need tõendid sageli ei asu ühes kohas.
Kuidas Sencai sobitub
Sencai on juhttasand, mis asetseb algupäraste juhttasandite kohal: see ühendub kontodega üheteistkümne pilveteenuse pakkuja juures ning kohapealsete (on-premise) ja füüsiliste serveritega kerge fleet agent'i kaudu ning loob ülevaate kõigest, mis juba töötab, kohe kui konto ühendatakse — migratsiooni pole vaja. Sealt edasi töötavad eksemplaride hankimine, käivitamine, peatamine, suuruse muutmine ja hävitamine ühtemoodi, olenemata teenusepakkujast. Saate ühendada olemasolevaid kontosid (midagi ei liigu, juurdepääsuandmed jäävad teenusepakkuja juures tühistatavaks) või lasta Sencail mahtu otse hankida ja selle eest arveldada, ning kombineerida mõlemat lähenemist ühes organisatsioonis. Iga tegevus igas ühendatud teenusepakkujas jõuab ühte lisamisele orienteeritud (append-only), räsiahelasse (hash-chained) lülitatud auditilogisse, mistõttu küsimus „kes ja millal seda muutis" on päring, mitte juurdlus.
Vaata inventuuri ja hankimist →