Firemní virtualizace: Pozor na uklouznutí

V okamžiku, kdy začneme seriózně uvažovat o kroku směrem k virtualizaci, je určitě lepší několikrát měřit, než řízneme.

Prvotní starostí by mělo určitě být ujasnění si důvodů, proč virtualizujeme a co vlastně očekáváme. Odtud se totiž bude odvíjet co a jak dál.

Společnost vyvíjející software očekává jednoduchý způsob instalace a udržování vývojářských systémů, kde mohou být zkoušeny prototypy. Dále automatizovaný systém certifikace vyvíjeného softwaru na rozšiřující se řadě operačních systémů a v různých lokalizacích. Také očekává možnost nabízet svou aplikaci zákazníkům na vlastních systémech, přičemž se bude plně starat o správu a všechny související procedury.

Jiným příkladem může být firma provozující několik desítek pracovišť s běžnými uživateli. Zde je nutné udržovat běh aplikací, záplatovat, řešit problémy uživatelů atd. Také by měly aplikace nutné k práci prostě fungovat. Velmi často by společnost ráda zamezila uživatelům v manipulaci s daty mimo kontrolované kanály jako třeba zkopírování dat na USB disk, odeslání e-mailem atd. Typicky obchodní nebo účetní firma.

Oba výše uvedené příklady jsou zjednodušené popisy jak aktuálních situací, tak také některých reálných očekávání.

Možnosti řešení
Jestliže se zaměříme na první příklad, pak společnost bude zjevně v některých použitích klást důraz na efektivní využití dostupného hardwaru, možnosti jednoduše a rychle stroj vytvořit či jej změnit, přičemž bezpečnostní aspekty nemusí být prioritou. To bude ovšem vypadat zcela jinak v případě, kdy platící zákazníci budou na funkční virtualizaci závislí.

Bylo by nepříjemné, kdyby klienti neměli důsledně izolována data například chybou obsluhy. V obou případech je určitě výhodné využít možnost vytvoření šablony pro virtuální stroj. Ve druhém případě je velice důležité zajistit bezpečnost a vzhledem k počtu uživatelů také zajištění se proti výpadkům, které mohou velmi citelně zasáhnout do dění ve firmě.

Zde se přímo nabízí virtualizace provozovaných aplikací nebo desktopu před virtualizací celých uživatelských stanic. Tedy uživatel bude vybaven jednoduchým grafickým terminálem, kterým se bude připojovat k virtuálnímu desktopu běžícímu na serveru.

Z pohledu uživatele půjde o „přihlašování do počítače“, kdežto správce může velmi jednoduše záplatovat a konfigurovat všechny stroje najednou vzhledem k tomu, že běží na jednom serveru. 

Problém může nastat, pokud některé aplikace nelze virtualizovat. To bývají potíže obvykle těch starších. Dále bývá problematické například streamování kvalitního videa nebo audia mezi serverem a terminálem. To je ovšem většinou vyváženo centralizovanou správou bezpečnosti. Například zkopírování dat na USB disk je možné velmi jednoduše omezit. Také mohou uživatelé velmi jednoduše sdílet pracoviště, jelikož terminály nemusí být svázány přímo s konkrétními uživateli.

Oddělte testovací prostředí
Vrátíme-li se k prvnímu případu, pak vývojářské a testovací stroje mohou být virtualizací operačního systému, paravirtualizací nebo plnou virtualizací, případně kombinací všeho. Management těchto typů nasazení je možné omezit na základní tvorbu a rušení virtuálních strojů spolu s časovou expirací a správou přidělování zdrojů.

U vývojových i testovacích strojů je určitě dobře využitelná funkce vytvoření obrazu stroje (snapshot). Jestliže aplikace běží na platformě Unix/Linux, pak je pro například automatizovaná testování hezky využitelná funkce chroot pro opravdu efektivní využití hardwarových prostředků strojů.

Testovací systémy by měly být dobře odděleny od systémů poskytovaných zákazníkům, tedy tzv. produkčních systémů. Produkční systémy musí být naopak schopné spolehlivé funkce v maximální možné míře. Také je nutné mít možnost zajištění dostupnosti zdrojů podle kontraktu se zákazníkem (SLA – Service Level Agreement) a informací o potenciálním problému s dostupností zdrojů. Jde o to, že ve skutečnosti je součet požadavků virtuálních strojů obvykle vyšší než kapacita fyzického hardwaru. Tím má firma možnost poskytovat výhodnější cenu za službu, ovšem s rizikem nedostatku zdrojů při špičkovém zatížení. Zde pomáhá managementový software a různé funkce hypervizorů jako migrace virtuálního stroje za běhu atd.

Určitě je nezbytné zajímat se v případě produkčního systému také o bezpečnost hypervizoru a softwaru pro správu. Pokud pracujeme s daty či aplikacemi, které jsou extrémně citlivé, například finanční transakce, pak bezpečnost zřejmě bude na prvním místě a LPAR virtualizace je v tomto ohledu bezkonkurenčně nejlepší.

Pasti a pastičky
Na cestě k virtuální infrastruktuře je spousta míst, kde můžeme uklouznout. Velmi často dochází k míchání volných a komerčních hypervizorů podle konečného využití té které virtualizace. Jednoduché pravidlo je čím méně kritické řešení, tím více si může firma dovolit šetřit.

Krásným příkladem jsou licence, kterým jsme věnovali předchozí díl. Obecně se dá říci, že volně dostupná řešení virtualizací vyžadují více pozornosti ze strany firmy na jejich správné nasazení a hlavně správu. Kdežto komerční řešení jsou obvykle k dispozici v prověřených konfiguracích se softwarem pro správu. Ovšem co se týče správy licencí, jsou jednoznačně jednodušší řešení založená na volně dostupném softwaru.

Dalšími možnostmi uklouznutí jsou nedostatečná správa virtualizované infrastruktury a postupné rozbujení daleko za původně uvažované meze. Takový problém firma rychle pozná na toku financí směrem k virtuální infrastruktuře. Důsledkem nedostatečného návrhu a správy je také tzv. boot storm. Jde o startování vysokého počtu virtuálních strojů ve stejném okamžiku, a tím zahlcení celé infrastruktury.

Všechny tyto problémy mohou jednoduše vést k odmítání virtualizací jejími uživateli. Vzhledem k očekáváním firem, jako je zvýšení efektivity využití hardwarových zdrojů a vyšší dostupnosti a bezpečnosti virtualizovaných prostředí proti fyzickým, je odmítnutí uživateli opravdu palčivý problém.

Bezpečnostní strategie a její jasná definice by měly být nedílnou součástí řešení. Bezpečnostní politika obecně snižuje uživatelský komfort, a proto by měla její úroveň odpovídat nasazení.

Autor pracuje jako software engineering manager ve společnosti CA Technologies