Privátní cloud, lehká cola a nízkotučný jogurt

Většina výrobců podnikového železa a aplikací se v posledním roce doslova vrhla na téma privátního cloudu. Jenže jak už to tak bývá, když chcete užívat výhody jisté technologie a odmítáte přijmout a nést rizika s nimi spojená, dostanete často něco jiného, než jste si představovali.

Ostatně ani definice privátního cloudu není úplně jasná a zřetelná. V zásadě se jedná o prostředí výpočetního mraku, které je vybudováno a využíváno jedinou organizací. Někdy je proto označováno i jako „interní cloud“, tento pojem je však poněkud matoucí, protože míchá dohromady funkcionalitu systému a jeho umístění. Navíc je to nepřesné, protože si lze snadno představit situaci, kdy jsou potřebný hardware, infrastruktury i software umístěny u dodavatelské společnosti, přesto je všechno toto vybavení používané pro cloud jedné společnosti – jde o privátní cloud, přitom mimo prostory využívající organizace.

Výrazně se v takovém případě liší i způsob financování – zatímco cloud vybudovaný ve vlastním datovém centru obvykle představuje výdaj kapitálový, privátní cloud provozovaný u dodavatele spadne spíše mezi položky výdajů provozních. Mnohá pozitiva privátních cloudů, tedy zejména vyřešení otázek bezpečnosti a umístění citlivých dat či možnost úprav aplikací na míru, navíc mají další potenciální skrytá úskalí.

Není pochyb, že privátní cloud je v mnoha směrech v rozporu se základními definicemi výpočetního mraku – vypůjčíme si protentokrát tu od Berkeley RAD Lab, hlavně proto, že je stručná a výstižná v pouhých třech bodech:

Obrovské zdroje: Výpočetní zdroje v cloud computingu jsou k dispozici podle potřeby a jsou z pohledu uživatele v zásadě neomezeně strukturovatelné, díky čemuž lze využívat vysoce agilní a škálovatelné aplikace. (Tyto zdroje jsou obvykle sdílené více či mnoha zákazníky – pozn. red.).

Žádný závazek: Výkon je k dispozici okamžitě a může být využíván bez nějakého závazku k průběžné či dlouhodobé smlouvě.

Platba za spotřebu: Zákazníci platí jen za skutečně spotřebované výpočetní zdroje, respektive výkon. Jakmile jsou uvolněné pro další spotřebitele, nejsou již za ně platby účtovány.

RAD Lab přímo uvádí, že nepovažují privátní (interní) cloudy za „skutečné“ představitele cloud computingu, protože ty mají výkonnostní či úložný strop, který je třeba rozšířit dalšími investicemi. Ostatně investice do infrastruktury znamenají porušení podmínky nulového závazku a platba za spotřebu je pouze položkou vytvářenou interně mezi IT oddělením a odběrateli jeho služeb – to sice není principiálně špatně, nicméně z hlediska celého podniku se stále jedná o kapitálové výdaje.

Klíčové jsou vlastní služby

Situaci příliš nepomáhají ani samotní výrobci infrastruktury, kteří popisují v první řadě hardware a software pro provoz privátního cloudu a skutečnou podstatu, tedy provoz interně poskytovaných aplikačních či infrastrukturních služeb, nechávají na zákaznících. O poznání lépe o problematice hovoří dodavatelé softwaru v čele s VMwarem, Citrixem a v poslední době i Microsoftem, kteří správně poukazují na to, že klíčem jsou vlastní služby dodávané uživatelům (jednotlivcům či oddělením), jejich automatizace, samoobslužnost a systémy pro billing podle reálné míry využívání (či dokonce podle reálného přínosu pro byznys – takové koncepty pro billing služeb privátního cloudu prosazuje například společnost Bayer).

O něco méně nahlas už ale i tyto firmy zdůrazňují, že největším oříškem při „migraci do cloudu“ mohou být podnikové aplikace, které je někdy nutné od základu přepsat nebo nahradit novými, a podpora mobilních uživatelů, respektive nativní podpora různých mobilních platforem a zařízení. Nic z toho by nemělo při úvahách o privátním cloudu zůstat opomenuto. Patřičné zohlednění může nakonec ukázat, že celkově vhodnější variantou je standardizované řešení ve veřejném cloudu.

Cloud - komplexní změna pohledu na IT

Jakkoliv privátní „mrak“ porušuje řadu základních pravidel a konceptů, kterými se cloud computing coby nová forma informatiky vyznačuje (pro pořádek uveďme, že jako předchozí bývají obvykle označovány mainframe, klient–server, a internet/intranet), má své platné místo a smysl. Jedná se především o přechodnou, transformační fázi, během níž dojde ke změně způsobu, jakým jsou podniková infrastruktura a aplikace provozovány, poskytovány a účtovány uživatelům. Další kroky pak mohou být různé – například hybridní model, kdy budou některé funkce přeneseny k dodavatelům či z privátních do komunitních nebo veřejných cloudů, nebo model osamostatnění IT oddělení, které následně bude tyto služby poskytovat i dalším zákazníkům mimo mateřský podnik.

Zatímco malé či nově vznikající podniky mohou privátní cloud vesele ignorovat a svou relativně malou IT agendu rovnou umístit k poskytovatelům aplikačních služeb, pro velké a středně velké firmy, zejména ty, pro které je IT naprosto klíčové, je privátní cloud přes všechny zmíněné nedostatky (zejména kapitálovou náročnost) přinejmenším vhodným mezičlánkem. Střediskem privátního cloudu je pochopitelně datové centrum, jehož správci jsou odpovědní za řízení infrastruktury a dodávku jednotlivých služeb či funkcí:

Virtuální zdroje: Úložiště, stroje a síťové prvky. Každý z těchto zdrojů musí být na vyžádání k dispozici podnikovému IT (respektive byznys uživatelům), a to okamžitě a v nezbytném objemu, což ve výsledku vede k potřebě plné virtualizace zdrojů. Schopnost dodávat požadovanou kapacitu není jednoduchá věc, protože neudržovaný systém dříve či později narazí na své výkonové limity. Nicméně po většinu provozu jsou interní cloudy schopné zpracovat naprostou většinu požadavků, uměním je ale nalézt správnou míru mezi výkonovou rezervou a náklady. Ve správě výkonu je neocenitelným pomocníkem virtualizace, kde je hlavní oblastí zasluhující pozornost řízení kapacit a síťových prostředků. Ideálně by obojí mělo být škálovatelné a distribuovatelné bez lidského zásahu.

Automatizovaný systémový administrátor: Privátní cloudy se mnohdy snaží co nejvíce efektivně emulovat nabídku služeb poskytovatelů veřejného cloudu, jako jsou Google či Amazon, klíčovými body jsou zejména rychlost odezvy a náklady provozu. Proto je však nutné, aby se systémoví administrátoři posunuli od manuální či poloautomatické správy (většinou představované perl skripty, které jsou srozumitelné jen jejich autorům) k automatizovaným procesům, kdy není nutné dalšího zásahu pro akce, jako je například přidělení dodatečného úložného prostoru.

Jinak řečeno, jakmile je hardware uveden do plného provozu ve zcela virtualizovaném a otestovaném prostředí a ve stavu, kdy je možné začít přidělovat kapacity, neměl by být potřebný, žádoucí ani možný individuální lidský zásah vedoucí k dalšímu jednorázovému přerozdělování zdrojů. Pokud nastane situace, kdy je pro přidělení zdroje nutný zásah administrátora, znamená to, že privátní cloud má ve své struktuře systémový nedostatek.

Plánování kapacit: Výkonný privátní cloud s plně automatizovaným řízením kapacit, připravený uspokojovat rostoucí nároky na výpočetní i diskovou kapacitu, nutně vyžaduje věnovat velkou pozornost všem hardwarovým zdrojům, na kterých je cloud postaven. Je to jako se supermarketem, kde každá položka musí být automatizovaně monitorována a doplňována tak, aby nenastal nedostatek zboží. Podobně i privátní cloud musí být pod pečlivým monitoringem kapacit, aby vždy bylo možné uspokojit poptávku.

Pokud chybí prvotřídní plánování kapacit, je velmi pravděpodobné, že dojde k jejich vyčerpání, nemožnosti uspokojit poptávku po výpočetním výkonu, načež následují spoustě lidí dobře známé schůze, kde se trapně řeší, jak že je to s tím výkonem, proč se ho nedostává, kde je chyba, v nejhorším případě kdo za to může. Kapacitní plánování je u privátního cloudu zvláště důležité, protože na jedné straně jeho uživatelé předpokládají, že zdroje dostanou podle potřeby, na druhé straně svou poptávku jen málokdy dokážou dostatečně jasně dopředu vyjádřit. Spíše ji nesdělí, ale čekají, že bude uspokojena.

Bezpečnost: V privátním cloudu nemůže být bezpečnost něco, co je posuzováno případ od případu prostřednictvím jednorázových review. V tomto smyslu musí být zabezpečení jednotlivých aplikací k dispozici stejně jako jednotlivé výpočetní zdroje – vyvolávané externími podněty a uplatňované automatizovaně. Na globální úrovni musí být definována politika bezpečnosti informací, která se následně promítá do jednotlivých pravidel uplatňovaných na aplikace podle jejich individuálních profilů.

Přenosová kapacita: Maximální možný objem přenosu dat patří mezi kritické zdroje a v budoucnu bude jeho důležitost dále narůstat. Přispívá k tomu tlak na rychlý chod aplikací s minimální odezvou, ty však potřebují stále větší objem dat, a to jak ukládaných, tak zpracovávaných. Navíc narůstá množství dat, která vcházejí a odcházejí z firmy od externích subjektů, ať již od velkých obchodních partnerů, tak spousty drobných zákazníků či dodavatelů. A nejde jen o dostupnost čisté přenosové kapacity, ale i o rychlost, s jakou jsou data zprostředkovávána, zejména při použití plně automatizovaného privátního cloudu, kde jsou veškeré požadavky na zdroje vyřizovány automaticky. To je v protipólu ke starým datovým centrům, kde se kapacita přidělovala individuálně a byl k tomu nutný zásah administrátora. Tento lidský prvek pak tvořil nejpomalejší součást přenosu dat. Přenosová kapacita a rychlost odezvy patří pravděpodobně k tomu nejdůležitějšímu zdroji, který by měl být sledován při plánování kapacit.

Identity management: Robustní správa identit je nezbytným předpokladem pro co nejvyšší stupeň automatizace provozu privátních cloudů. Požadavky na tento typ služeb nebudou přicházet jako výsledek jednotýdenních schůzí, kde se autentifikace a autorizace řeší na individuální bázi případ od případu, takže je možné pečlivě posoudit oprávněnost nároků jednotlivých uživatelů. Místo toho budou ve velkých organizacích takové požadavky přicházet, či již přicházejí, přes softwarové nástroje, jako jsou interní portály.

To znamená, že identity management musí fungovat tak, aby zahrnoval vstupy od všech potenciálních žadatelů i od všech administrátorů, kteří se tohoto procesu účastní. Takový management identit musí být rozšířen pro podporu všech rolí nutných pro nastavené workflow. Například projektový vývojář požaduje zdroj a identity management musí posoudit, že tento konkrétní pracovník může takový požadavek zadat. Žádost je pak předána nadřízenému pro schválení či zamítnutí a opět systém kontroluje, kdo je dotyčný nadřízený a zda má potřebná práva. A tak to dále pokračuje.

Politiky: Nezbytným doplňkem pro funkční identity management systém je databáze politik, která obsahuje pravidla pro požadavky na zdroje. Systém politik provazuje dohromady požadavky na zdroje, kontrolu oprávněnosti přístupu a jeho ověřování, přidělování zdrojů a odesílání přístupových informací zpět žadateli.

U privátního cloudu je důležité si pamatovat, že:

1. Více odděluje poskytování služeb a požadavky na ně.
2. Pravděpodobně zvýší celkové požadavky na služby, protože kvůli automatizaci tohoto procesu budou lidé ochotnější o ně žádat a využívat je.
3. Implementace automatizovaného datového centra vyžaduje dodatečné zdroje pro propojení zdrojů s jednotlivými instancemi aplikací.
4. Plánování kapacit se stane jednou z nejdůležitějších činností v provozu datových center.

U čtvrtého bodu je důležité podotknout, že plánování kapacit neznamená prostě jen zajištění nadbytečné úložné, výpočetní a přenosové kapacity, ale hlavně průběžné řízení tak, aby nedocházelo k financování zbytečně velkých hardwarových (ale i softwarových) aktiv.