Hübriidpilv
Hübriidpilv on IT-arhitektuur, mis ühendab kohapealse või privaatse infrastruktuuri ühe või mitme avaliku pilveteenuse pakkujaga üheks kooskõlastatud keskkonnaks, mitte eraldiseisvateks silodeks. Organisatsioonid paigutavad töökoormused, andmed ja halduse sinna, kuhu kulu, jõudlus, latentsus või vastavusnõuded dikteerivad, kasutades tavaliselt ühiseid tööriistu, et kõike järjepidevalt provisioneerida, turvata ja jälgida.
Praktikas tähendab hübriidpilv tavaliselt seda, et organisatsioon hoiab osa süsteeme oma riistvaral — andmekeskuses, kolokatsioonirajatises või enda omandis või rendil olevatel bare-metal serveritel —, samal ajal kui teised süsteemid töötavad avaliku pilve pakkujate juures, nagu AWS, Azure või Google Cloud. Jaotus on teadlik: latentsustundlikud või reguleeritud töökoormused jäävad sageli ettevõttele lähedale, samas kui töökoormused, mis saavad kasu elastsest võimsusest, hallatavatest teenustest või geograafilisest levikust, kolivad pilve. Hübriidpilv erineb multipilvest, mis tähendab kahe või enama avaliku pilve pakkuja koos kasutamist; hübriidkeskkond sisaldab alati vähemalt üht mitte-avaliku-pilve komponenti, olgu selleks privaatne andmekeskus, servaseadmed või kohapealsed serverid. Paljud organisatsioonid rakendavad mõlemat mustrit korraga — hübriidmudelit kohapealse infrastruktuuri ja pilve vahel ning multipilve mitme pakkuja vahel pilve osas.
Levinud põhjused hübriidmudeli kasutuselevõtuks on andmete asukohanõuded ja regulatiivsed nõuded, mis hoiavad teatud andmed infrastruktuuril, mida organisatsioon otseselt kontrollib, olemasolev kapitaliinvesteering riistvarasse, mis pole veel amortiseerunud, stabiilse ja prognoositava koormusega töökoormused, mida on odavam käitada oma serveritel kui renditud pilvevõimsusel, ning soov vältida sõltuvust ühest pakkujast. Hübriidülesehitused on levinud ka migratsioonide käigus: meeskond viib töökoormused pilve järk-järgult, käitades vanu ja uusi süsteeme kõrvuti kuude või aastate jooksul, selle asemel et kõike korraga ümber lülitada. Kompromiss on operatiivne: kohapealsetel ja pilvekeskkondadel on tavaliselt eraldi konsoolid, eraldi mandaadid, eraldi jälgimine ja eraldi paikamisprotsessid, seega tuleb sama turvapoliitika või intsidentidele reageerimise protseduur rakendada kaks korda, kahel erineval viisil.
Miks hübriidpilv on oluline
Hübriidpilv on oluline, sest enamik reaalseid infrastruktuurikeskkondi on hübriidsed, olenemata sellest, kas meeskond seda nii planeeris — ettevõte omandab teise ettevõtte koos selle enda andmekeskusega, vastavusnõue sunnib teatud andmeid kohapeal hoidma või pärandrakendust ei saa lihtsalt majanduslikult mõistlikult üle kolida. Kui käsitleda kohapealset infrastruktuuri ja pilve eraldi maailmadena, tähendab see turvakontrollide, ligipääsupoliitikate ja auditijälgede dubleerimist, ning just seal tekivad lüngad: tulemüürireegel, mida rakendatakse pilvekonsoolis, kuid mis unustatakse bare-metal poolel, või intsidentidele reageerimise juhend, mis töötab ainult ühes keskkonnas. Reguleeritud tööstusharudes ja kõigi jaoks, kes vastutavad audiitorite ees, vajab küsimus „kes ja millal seda serverit muutis" sama vastust olenemata sellest, kas server asub kolokatsiooniriiulis või avaliku pilve regioonis — seda on raske tagada ilma ühise kihita mõlema kohal.
Kuidas Sencai aitab
Sencai käsitleb kohapealseid ja bare-metal servereid esmaklassiliste sihtmärkidena, mitte lisandusena: sama kergekaaluline fleet-agent, mis töötab pilveinstantsidel, töötab ka igal Linuxi serveril, pakkudes identset jälgimist, paikamist, tarkvarainventuuri ja heakskiiduga juhitud runbook-automatiseerimist, nii et üks kord kirjutatud intsidendile reageerimise protseduur töötab kõikjal ühtemoodi. Pilve poolel ühendab Sencai olemasolevad kontod 11 pakkuja lõikes (BYOC, midagi ei migreerita) või provisioneerib ja arveldab hallatavat võimsust enda konto all, inventeerib ressursid kohe, kui konto ühendatakse, ning logib iga tegevuse muutumatusse, räsiahelaga auditijälge — üks juhtimiskeskus, üks auditijälg, mõlemas maailmas.
Hübriid- ja kohapealne haldus →