Řídicí rovina cloudu
Řídicí rovina cloudu je vrstva rozhraní, API a služeb, která umožňuje infrastrukturu provisionovat, konfigurovat a spravovat — odděleně od datové roviny, jež reálně pouští vaše workloady a přenáší váš provoz. Vlastní řídicí rovinu má každý provider; pojem zároveň zahrnuje systémy, které spravují víc providerů jako jednu rovinu.
Každá infrastruktura má dvě oddělené vrstvy. Datová rovina je samotná infrastruktura: virtuální stroje, na kterých běží vaše aplikace, síť přenášející mezi nimi pakety, disk obsluhující čtení a zápis. Řídicí rovina je všechno, co používáte k rozhodování, jak má infrastruktura vypadat, a k jejím změnám — API, konzole, CLI, systém oprávnění, který určuje, kdo smí danou změnu provést. Když v cloudové konzoli vytvoříte VM, změníte velikost disku nebo otevřete port na firewallu, pracujete s řídicí rovinou. Instance, která naběhne, gigabajty navíc, které se zpřístupní, provoz, který se rozproudí — to je datová rovina reagující na to, co jí přikázala řídicí rovina.
Tohle rozlišení se stává užitečnější ve chvíli, kdy tým provozuje víc než jednoho providera. AWS má svou řídicí rovinu. Stejně tak Google Cloud, Azure, Hetzner a každý další provider — každý s vlastní konzolí, vlastním tvarem API, vlastními přístupovými údaji a vlastní představou o tom, jak se má jmenovat „security group" nebo „firewall rule". Tým provozující tři cloudy a dvacet bare-metal serverů ve skutečnosti obsluhuje tři nebo čtyři samostatné řídicí roviny vedle sebe, plus cokoliv, čím spravuje servery, které v žádném cloudu vůbec nejsou. Nic tyhle řídicí roviny nenutí, aby se mezi sebou shodovaly, a nic mimo váš vlastní proces nezajistí, aby změna provedená v jedné z nich byla vidět i tomu, kdo se dívá na druhou.
„Řídicí rovina cloudu" se používá i v užším významu — uvnitř Kubernetes je řídicí rovinou API server, scheduler a controller-manager, které rozhodují, kde poběží pody, na rozdíl od kubeletů a kontejnerů, jež je na uzlech skutečně spouštějí. „Multi-cloud" nebo „sjednocená" řídicí rovina rozšiřuje stejnou myšlenku napříč providery: jedno místo, odkud vidíte infrastrukturu fyzicky ležící v několika různých účtech, regionech a u různých dodavatelů a odkud s ní můžete pracovat, místo samostatného rozhraní pro každého providera. Nenahrazuje podkladové řídicí roviny jednotlivých providerů — požadavek pořád skončí jako API volání na AWS, na Hetzner, nebo na fleet agenta na bare-metal serveru — stojí před nimi, takže člověk, který změnu provádí, se musí naučit jen jeden systém.
Proč je toto rozlišení provozně důležité
Většina incidentů v infrastruktuře i mezer v auditu se dá vystopovat k problémům v řídicí rovině, ne v datové: změna, kterou nikdo nezalogoval, oprávnění, které nikdo neodebral, pravidlo firewallu otevřené v konzoli jednoho providera, které nikdo jiný z týmu nevidí. Když má každý cloud vlastní řídicí rovinu a vlastní auditní stopu, otázka „kdo tohle změnil a kdy" se zodpovídá přihlašováním do tří nebo čtyř různých konzolí a ručním porovnáváním časových razítek — nebo se nezodpoví vůbec. Pro týmy podléhající compliance rámcům jako NIS2 není tahle mezera jen nepříjemná: historie změn, řízení přístupu a důkazy o incidentu jsou přesně to, na co se auditor nebo regulátor zeptá jako první, a roztříštěná řídicí rovina je důvod, proč tyhle důkazy často neleží na jednom místě.
Jak do toho zapadá Sencai
Sencai je řídicí rovina, která stojí nad těmi nativními: napojuje se na účty napříč jedenácti cloudovými providery a navíc na on-premise a bare-metal servery přes odlehčeného fleet agenta, a ve chvíli, kdy se účet připojí, zinventarizuje, co už na něm běží — bez nutnosti migrace. Odtud pak provisioning, spouštění, zastavování, změna velikosti a mazání instancí funguje stejně bez ohledu na providera. Můžete připojit existující účty (nic se nepřesouvá, přístupové údaje zůstávají odvolatelné u providera), nebo nechat kapacitu provisionovat a fakturovat přímo Sencai, a obojí kombinovat v rámci jedné organizace. Každá akce napříč každým připojeným providerem se zapisuje do jediného auditního logu, do kterého lze pouze přidávat a jehož záznamy jsou navzájem provázané hashem, takže „kdo tohle změnil a kdy" je dotaz, ne pátrání.
Zobrazit inventarizaci a provisioning →