Aplikační virtualizace jako standard deploymentu aplikací?

autor: Jan Vávra, Microsoft ČR

O aplikační virtualizaci toho bylo v poslední době vyřčeno opravdu hodně. Drtivá většina materiálů zabývajících se aplikační virtualizací však k těmto technologiím přistupuje, a to bez ohledu na výrobce či dodavatele, jako k nástroji, který je určen především k řešení problémových situací. Podobně je tomu i u nástrojů z dílny Microsofu, jako jsou Microsoft Application Virtualization (App-V, dříve Softgrid) a Microsoft Enterprise Desktop Virtualization (MEDV, dříve Kidaro), jenž byly mnohokrát popisovány právě jako nástroje pro řešení konfliktů mezi aplikacemi na jednom systému (App-V) nebo konfliktů mezi aplikacemi a podkladovým operačním systémem (MEDV).

Podívejme se však nyní na tyto nástroje z širšího pohledu a představme si je v souvislostech, které nezachycují krizovou situaci, nýbrž možný standard aplikačního deploymentu. Přesněji řečeno budeme hovořit o technologii App-V. MEDV již z podstaty své funkce počítá s faktem, že na primárním OS použije k běhu aplikace jádro svého vlastního OS, tedy v tomto případě se skutečně jedná spíše o nástroj k řešení krizových stavů.

Situace

Než se pustíme do popisu toho, jak by mohl scénář využití aplikační virtualizace ve standardním procesu aplikačního deploymentu vypadat, podívejme se na fiktivní situaci v IT fiktivního podniku. Jedná se o společnost střední velikosti, řekněme, s tisíci uživateli, která využívá několik desítek externích zaměstnanců. Předmět podnikání není důležitý, ale externisté např. využívají terminálových připojení ze svých notebooků ke spouštění podnikových aplikací, stejných, jako jsou v lokální síti k dispozici přes „tlustého“ klienta, a ještě existují tací, kteří potřebují stejné aplikace spouštět na notebooku lokálně, offline a provádějí jednorázové činnosti, tedy jejich spolupráce s danou společností je výslovně krátkodobá.

Je tedy třeba zajistit, aby se co nejjednodušší cestou zpřístupnily tytéž aplikace uživatelům v lokální síti klasickou formou, přes terminálové služby a online nebo offline na mobilních zařízeních. Zároveň samozřejmě nejde jen o zpřístupnění aplikací, ale také o patch management a o to, aby aplikace byly včas a správně odstraněny ze stanic, na nichž již nemají být funkční (např. při ukončení spolupráce s externistou).

Oprosťme se nyní od pohledu na standardní deployment aplikací, jak ho známe (instalace aplikace buď jako existující součást image stanice, nebo do již existujícího OS, klasický patch management atd.), a pojďme se podívat na to, jak by tento proces mohl vypadat s použitím kombinace nástrojů App-V a System Center Configuration Manager (SCCM) 2007 SP1. Nutno dodat, že se bavíme o poslední verzi těchto produktů, a to o verzi 4.5 u App-V a SCCM 2007 SP1 (případně SMS 2003 R2). Toto je důležitá informace, neboť verze App-V 4.2 nepodporovala vzájemnou interakci jednotlivých virtualizovaných aplikací, stejně jako základní verze SCCM 2007 (SMS 2003) nepodporovala spolupráci s App-V při doručení balíčků aplikací na koncové stanice. V současné době spolu již všechny tyto technologie přímo spolupracují.

Jak na to?

Nejprve si připomeňme, co vše potřebujeme pro funkci vlastního App-V. Základním předpokladem pro využití ve velké organizaci je přítomnost Active Directory (App-V agent je schopen na koncové stanici spustit virtualizovanou aplikaci i samostatně, ale AD řídí distribuci uživatelům), dále System Center Application Virtualization Streaming Server (dále jen App-V server), který se ve spolupráci s AD stará o přidělování aplikací uživatelům, kteří na ně mají nárok (streamování) a nakonec nějaká izolovaná stanice, na které se balíčky aplikací připravují (ideální je použít opět virtualizaci – hardwarovou a pracovat nad čistou instalací OS, např. ve Virtual PC, které po skončení přípravy balíčku můžeme ukončit bez uložení změn a zachovat si tak čistý OS pro přípravu dalších balíčků).

V zásadě by toto mohlo stačit, avšak v konfiguraci bez užití SCCM hrozí přetěžování sítě, především v okamžiku, kdy uživatelé budou ve větší míře přistupovat k aplikaci, kterou ještě nepoužili, a najednou ji začnou streamovat pomocí App-V serveru do svých stanic. Chybí též pobočkový scénář, distribuční body atd. Jak je vidět na obrázku níže, použití v kombinaci se SCCM 2007 SP1 (příp. SMS 2003 R2) nabízí možnost kombinovat výhody nezávislosti virtualizované aplikace na operačním systému s principy automatizovaného doručení aplikace na koncovou stanici v časech a způsobem, který administrátor určí, aby co nejefektivněji využil „jalových časů“ a propustnosti pásma sítě, včetně užití samostatných distribučních bodů v pobočkovém scénáři.

Příprava aplikace k nasazení probíhá v zásadě stejným způsobem, jako v minulých verzích App-V (rozdíl může být např. v přiřazení runtime částí – viz možnost vzájemné interakce virtualizovaných aplikací od verze 4.5), ale proces nasazení virtuální aplikace na desktop je již výrazně rozdílný. Zatímco dříve se o doručení aplikace na koncovou stanici staral výhradně App-V server (vyjma offline řešení), nyní můžeme zapojit do procesu server SCCM, který v nejvhodnějším čase a s využitím všech svých vlastností může přednaplnit cache koncových stanic všemi administrátorem definovanými balíčky virtualizovaných aplikací. V momentě přihlášení uživatele pak dojde k tomu, že App-V server přiřadí dle svého záznamu ve spolupráci s Active Directory uživateli ty aplikace, na které má nárok. Na rozdíl od použití samotného App-V serveru bez SCCM ovšem v momentě požadavku na spuštění aplikace uživatelem již nedochází ke streamování aplikace z App-V serveru, pouze je překontrolována aktuálnost verze a aplikace je prakticky okamžitě spuštěna z lokální cache. Nedochází tedy ani k prodlevám vnímaným ze strany uživatele, ani k nadměrnému zatěžování sítě v okamžiku, kdy se o spuštění ještě nenastreamovaných aplikací snaží větší počet uživatelů najednou. Například ráno po příchodu na pracoviště.

Další obrovskou výhodou nové verze App-V je možnost vzájemné interakce virtualizovaných aplikací. Představte si, že na jedné stanici potřebujete využít dvě různé verze Java runtime, ale alespoň na jedné z nich poběží více aplikací. V minulých verzích bylo nutné „přibalit“ runtime k balíčku aplikace, aby ho mohla využít (více dat, složitější sekvencování, složitější případný patch management, např. nový runtime = upravit všechny aplikační balíčky apod.). Od verze 4.5 je možné připravit separátně balíčky s virtualizovaným runtime a aplikace pouze nastavit tak, aby použily balíček s runtimem, který je potřeba. Stejně tak spolu mohou komunikovat i jiné aplikace přímo bez interakce operačního systému, což zvyšuje použitelnost virtualizace aplikací obecně. Bohužel, ke škodě celého řešení je nutno podotknout, že trvá stav, kdy nelze virtualizovat rozhraní .NET Framework, čímž se poněkud komplikuje situace kolem aplikací využívajících právě tohoto rozhraní. Situace je dána tím, že rozhraní .NET Framework je v podstatě rozšířením operačního systému, které je natolik integrováno s vlastním systémem Windows, že jej nelze jednoznačně oddělit a virtualizovat samostatně.

S přihlédnutím k záměru využití aplikační virtualizace jako standardu deploymentu aplikací na různé formy koncového použití je dobrá vlastnost i to, že stejný balíček s virtualizovanou aplikací je možné použít jak pro koncovou stanici, tak pro zpřístupnění aplikace přes terminálové služby (toto vyžaduje pouze jinou licenci App-V, technicky funguje stejně). Odpadá tedy nutnost mnohonásobného testování jedné aplikace pro použití v různých scénářích. Patch management probíhá centrálně, administrátor řeší pouze aktualizaci jednoho balíčku pro všechny instance, a navíc, v momentě, kdy již nemá takto nasazená aplikace být uživateli k dispozici, není nutné ji nijak odinstalovávat. Stačí v App-V serveru nastavit, že aplikace již nemá být uživatelům přístupná. V případě nepřítomnosti konektivity na App-V server nebo AD (offline užití) lze nastavit i životnost cache na koncové stanici tak, aby po určeném počtu dní aplikace sama přestala v PC fungovat, o což se postará App-V agent, který umožňuje její spouštění (lze tak například zajistit, aby externí pracovník měl aplikaci k dispozici po určené časové období, a bez nutnosti následné odinstalace její funkčnost poté sama vypršela a aplikace přestala v systému existovat).

Závěr

Popsat všechny možnosti, jak se postavit k použití aplikační virtualizace jako k nástroji, který plně nahradí proces standardního deploymentu aplikací je v jednom článku prakticky nemožné, nicméně doufám, že alespoň jako námět k zamyšlení je to zajímavé téma.

Více o nástrojích App-V (dříve Softgrid) a SCCM 2007 se můžete dozvědět na stránkách společnosti Microsoft: https://www.microsoft.com/cze/windows/products/mdop/default.mspx a https://www.microsoft.com/cze/windowsserversystem/systemcenter/default.mspx.