Omnissa App Volumes – czym jest i jak działa?

Przygotowanie pierwszego golden image w środowisku VDI zazwyczaj nie jest szczególnie skomplikowane. Instalujemy system Windows, wymagane agenty, podstawowe aplikacje, wykonujemy optymalizację, tworzymy snapshot i na jego podstawie publikujemy pulę wirtualnych desktopów.

Problemy zaczynają się później, gdy środowisko zaczyna rosnąć.

Dział finansowy potrzebuje aplikacji księgowej, z której nie korzystają pozostali pracownicy. Zespół techniczny wymaga dodatkowych narzędzi administracyjnych, a dział sprzedaży korzysta z własnego zestawu programów. Po kilku miesiącach okazuje się, że jedna wersja golden image przestaje wystarczać. Powstaje kolejny obraz, później następny, a każda aktualizacja systemu lub aplikacji wymaga sprawdzenia kilku różnych konfiguracji.

Można oczywiście zainstalować wszystkie programy w jednym obrazie i ograniczyć do nich dostęp za pomocą uprawnień. Takie rozwiązanie szybko jednak prowadzi do powstania dużego i trudnego w utrzymaniu golden image. Nawet niewielka aktualizacja aplikacji wymaga wtedy przejścia przez cały proces przygotowania, testowania i publikowania nowej wersji obrazu.

Omnissa App Volumes jest rozwiązaniem, które pozwala oddzielić aplikacje od systemu operacyjnego i zarządzać ich cyklem życia niezależnie od golden image.

Dlaczego aplikacje w golden image stają się problemem?

Golden image jest jednym z najważniejszych elementów środowiska Omnissa Horizon. To na jego podstawie tworzone są wirtualne desktopy, dlatego powinien być stabilny, odpowiednio zabezpieczony i możliwie prosty w utrzymaniu.

W praktyce bardzo łatwo doprowadzić do sytuacji, w której obraz bazowy przestaje być prosty.

Na początku znajdują się w nim tylko Windows, Horizon Agent, podstawowa przeglądarka i pakiet biurowy. Później pojawia się kilka aplikacji biznesowych, dodatkowe komponenty, biblioteki, rozszerzenia oraz narzędzia wykorzystywane tylko przez część organizacji. Każdy kolejny program zwiększa liczbę zależności, które trzeba brać pod uwagę podczas aktualizowania systemu.

Jeżeli aktualizujemy Windows, musimy sprawdzić, czy wszystkie zainstalowane aplikacje nadal działają poprawnie. Jeżeli aktualizujemy jedną z aplikacji, często musimy ponownie przygotować obraz, wykonać optymalizację, utworzyć snapshot i opublikować nową wersję puli. Sama zmiana może być niewielka, ale proces wokół niej pozostaje taki sam.

Jeszcze trudniej robi się wtedy, gdy różne grupy użytkowników potrzebują innych aplikacji albo różnych wersji tego samego programu. W klasycznym modelu może to oznaczać konieczność utrzymywania kilku obrazów lub instalowania wszystkich wersji w jednym systemie i późniejszego rozwiązywania konfliktów pomiędzy nimi.

App Volumes zmienia to podejście. Zamiast traktować system operacyjny i wszystkie aplikacje jako jedną całość, pozwala zarządzać nimi jako niezależnymi warstwami. System może być aktualizowany we własnym cyklu, natomiast aplikacje mogą być przygotowywane, testowane i aktualizowane niezależnie.

Czym jest Omnissa App Volumes?

Omnissa App Volumes jest rozwiązaniem przeznaczonym do pakowania, dostarczania i zarządzania cyklem życia aplikacji Windows. Aplikacje nie muszą być instalowane bezpośrednio w golden image ani oddzielnie na każdym wirtualnym desktopie. Zamiast tego są instalowane na specjalnie przygotowanej maszynie, przechwytywane do pakietu, a następnie dostarczane do urządzeń użytkowników za pomocą wirtualnych dysków.

W środowisku Omnissa Horizon działającym na vSphere pakiet aplikacji może być przechowywany jako plik VMDK. Gdy użytkownik otrzymuje dostęp do programu, odpowiedni wirtualny dysk jest podłączany do jego maszyny. App Volumes Agent integruje zawartość pakietu z systemem plików i rejestrem Windows, dzięki czemu aplikacja wygląda i działa tak, jakby została normalnie zainstalowana w systemie.

Użytkownik nie musi otwierać dodatkowego dysku i ręcznie szukać pliku wykonywalnego. Widzi normalny skrót w menu Start, skojarzenia plików oraz pozostałe elementy utworzone podczas instalacji programu. Z jego punktu widzenia nie ma większego znaczenia, czy aplikacja znajduje się w golden image, czy została dostarczona przez App Volumes.

Największa różnica widoczna jest po stronie administratora. Program można przygotować raz, przypisać wybranej grupie użytkowników, zaktualizować bez modyfikowania systemu operacyjnego, a w razie problemów wrócić do wcześniejszej wersji.

App Volumes nie jest również ograniczone wyłącznie do środowiska Omnissa Horizon. Agent może działać między innymi na wirtualnych desktopach, serwerach RDSH oraz obsługiwanych fizycznych urządzeniach Windows. Sposób przechowywania i podłączania pakietów zależy jednak od platformy, na której działa środowisko.

Jak działa App Volumes?

Najprościej można powiedzieć, że App Volumes przechwytuje zainstalowaną aplikację, zapisuje ją w pakiecie, a później udostępnia ten pakiet właściwemu użytkownikowi lub komputerowi w odpowiednim momencie.

Sam proces składa się jednak z kilku etapów.

Najpierw administrator przygotowuje czystą maszynę Windows, nazywaną Packaging Machine, Packaging VM albo Capture Machine. Powinna ona być możliwie zbliżona do systemu używanego w środowisku produkcyjnym. Jeżeli użytkownicy pracują na Windows 11 z określonym zestawem bibliotek i aktualizacji, maszyna pakująca powinna posiadać podobną konfigurację.

Na tej maszynie rozpoczynany jest proces przechwytywania, a następnie aplikacja instalowana jest w standardowy sposób. Można również wykonać wspólną konfigurację programu, która powinna znaleźć się w przygotowanym pakiecie.

App Volumes zapisuje w pakiecie elementy wymagane do działania aplikacji, takie jak jej pliki, katalogi i obsługiwane wpisy rejestru. Pakiet nie jest więc jedynie kopią instalatora. Zawiera aplikację po zakończeniu procesu instalacji, przygotowaną do dostarczenia do innych systemów Windows.

Omnissa określa ten sposób działania jako model one-to-many provisioning. Jedna aplikacja jest przygotowywana raz, ale utworzony pakiet może zostać dostarczony do wielu desktopów i użytkowników.

Po utworzeniu pakietu administrator przypisuje aplikację do użytkownika, grupy katalogowej, komputera lub grupy komputerów. Od tego momentu App Volumes Manager wie, kto powinien otrzymać dostęp do konkretnego programu.

Gdy użytkownik uruchamia wirtualny desktop, App Volumes Agent kontaktuje się z Managerem i pobiera informacje o obowiązujących przypisaniach. Jeżeli w środowisku vSphere rolę Machine Managera pełni vCenter Server, App Volumes Manager przekazuje do niego polecenie podłączenia właściwego pliku VMDK do maszyny użytkownika.

Po podłączeniu wirtualnego dysku Agent wykrywa pakiet i integruje aplikację z działającym systemem Windows. Program staje się dostępny w menu Start i może być uruchomiony tak samo jak aplikacja zainstalowana lokalnie.

Cały proces odbywa się bez klasycznej instalacji programu na każdym desktopie. Po wylogowaniu użytkownika lub wyłączeniu maszyny pakiet może zostać odłączony, a sam wirtualny desktop może zostać usunięty i utworzony ponownie. Podczas kolejnej sesji App Volumes ponownie dostarczy odpowiednie aplikacje na podstawie skonfigurowanych przypisań.

Takie podejście bardzo dobrze pasuje do pul Instant Clone. Maszyny mogą być nietrwałe, ale zestaw aplikacji dostępnych dla użytkownika jest odtwarzany podczas kolejnych sesji.

Z czego składa się środowisko App Volumes?

Centralnym elementem rozwiązania jest App Volumes Manager. Jest to serwer udostępniający konsolę administracyjną, za pomocą której tworzymy aplikacje i pakiety, konfigurujemy połączenia z infrastrukturą, zarządzamy przypisaniami oraz kontrolujemy cykl życia poszczególnych wersji oprogramowania.

Manager działa również jako broker dla agentów App Volumes. Agent kontaktuje się z nim, aby pobrać informacje o pakietach i Writable Volumes przypisanych do użytkownika lub komputera.

Manager nie przechowuje całej konfiguracji wyłącznie lokalnie. Korzysta z bazy Microsoft SQL Server, w której znajdują się informacje dotyczące aplikacji, pakietów, markerów, Writable Volumes oraz przypisań.

W środowisku produkcyjnym może działać kilka serwerów App Volumes Manager korzystających ze wspólnej bazy danych. Pozwala to zapewnić redundancję warstwy zarządzającej. Sama baza danych również powinna zostać zaprojektowana w sposób zapewniający odpowiednią dostępność.

Drugim ważnym elementem jest App Volumes Agent. Instalujemy go w golden image, obrazie serwera RDSH albo na innym obsługiwanym urządzeniu docelowym. Agent odpowiada za komunikację z Managerem, rozpoznawanie przypisań oraz integrację podłączonych pakietów z systemem Windows.

To właśnie dzięki Agentowi aplikacja znajdująca się na dodatkowym wirtualnym dysku jest widoczna dla użytkownika jak zwykły, lokalnie zainstalowany program. Agent udostępnia warstwę abstrakcji systemu plików i rejestru, która łączy zawartość pakietu z działającym systemem.

W środowisku vSphere potrzebny jest również Machine Manager. Tę rolę najczęściej pełni vCenter Server. App Volumes Manager nie podłącza dysku VMDK bezpośrednio do maszyny. Przekazuje odpowiednie instrukcje do vCenter, a vCenter wykonuje operację podłączenia lub odłączenia dysku od właściwego wirtualnego desktopu.

Machine Manager nie zawsze musi jednak oznaczać vCenter. W środowiskach korzystających z pakietów VHD przechowywanych na zasobach SMB możliwe jest wykorzystanie mechanizmu In-Guest Services. W takim modelu Agent pobiera dysk bezpośrednio ze skonfigurowanego storage i montuje go wewnątrz systemu Windows.

Pakiety aplikacji oraz Writable Volumes muszą być przechowywane na storage dostępnym dla środowiska. W przypadku infrastruktury vSphere mogą to być pakiety VMDK umieszczone na odpowiednim datastore. W modelu In-Guest Services stosowane są pakiety VHD przechowywane na udziałach SMB. App Volumes może również korzystać z grup storage, które pomagają organizować lokalizacje przechowywania i replikować pakiety pomiędzy nimi.

Ostatnim elementem, o którym warto pamiętać już na etapie poznawania architektury, jest Packaging Machine. To na niej będziemy instalowali i przechwytywali aplikacje.

Nie powinien to być zwykły komputer administratora, na którym przez kilka lat instalowano różne wersje oprogramowania. Powinna to być kontrolowana i czysta maszyna, którą po zakończeniu każdego procesu pakowania można przywrócić do znanego stanu, na przykład za pomocą wcześniej przygotowanego snapshota.

Ma to duże znaczenie, ponieważ pozostałości po wcześniejszych instalacjach mogą wpłynąć na zawartość kolejnego pakietu. Jeżeli na maszynie znajdują się już biblioteki wymagane przez przechwytywaną aplikację, mogą one nie zostać dodane do pakietu. Program będzie wtedy działał na Packaging Machine, ale może nie uruchomić się na czystym desktopie użytkownika.

Po przygotowaniu pakietu aplikację należy przetestować na osobnej, czystej maszynie docelowej. Nie powinno się ograniczać testów wyłącznie do komputera, na którym przeprowadzono proces pakowania.

Application, Package, Program i Marker

Jednym z elementów, który na początku może być niejasny, jest nazewnictwo używane w konsoli App Volumes. Pojawiają się tam obiekty Application, Package, Program oraz Marker. Każdy z nich oznacza coś innego.

Application jest logicznym obiektem reprezentującym aplikację. Możemy utworzyć Application o nazwie Mozilla Firefox, 7-Zip albo Notepad++. Nie jest to jeszcze sam program ani zawierający go wirtualny dysk. Application można potraktować jako kontener grupujący przygotowane wersje danego oprogramowania.

Wewnątrz Application znajdują się pakiety, czyli Packages. Każdy pakiet może reprezentować konkretną wersję programu. W Application o nazwie Firefox możemy więc posiadać pakiet zawierający wcześniejszą wersję przeglądarki, aktualną wersję produkcyjną oraz nową wersję przeznaczoną na razie tylko dla użytkowników testowych.

Package jest woluminem tylko do odczytu zawierającym zainstalowaną aplikację. To właśnie pakiet jest dostarczany i podłączany do urządzenia użytkownika. Jeden obiekt Application może posiadać wiele pakietów, dzięki czemu nie musimy usuwać wcześniejszej wersji za każdym razem, gdy przygotowujemy nowe wydanie.

Program oznacza właściwe oprogramowanie wykryte wewnątrz pakietu. Jeden pakiet może zawierać więcej niż jeden Program. Dobrym przykładem jest pakiet biurowy, który może zawierać kilka osobnych aplikacji, mimo że wszystkie zostały przechwycone podczas jednego procesu pakowania.

Po dostarczeniu Application do urządzenia znajdujące się w pakiecie programy są widoczne w systemie Windows, między innymi w menu Start oraz w sekcji zainstalowanych aplikacji.

Marker pozwala wskazać, który pakiet powinien być traktowany jako aktualna wersja Application. Najczęściej wykorzystywany jest marker CURRENT. Administrator może dzięki temu przygotować nową wersję, przetestować ją na wybranych użytkownikach, a następnie zmienić marker bez przebudowywania wszystkich istniejących przypisań.

Jeżeli po aktualizacji pojawią się problemy, marker można ponownie skierować na wcześniejszy pakiet. Ułatwia to zarówno wdrażanie nowych wersji, jak i szybkie wycofywanie zmian.

Na początku taka struktura może wydawać się nadmiernie rozbudowana, ale rozdzielenie logicznej aplikacji od jej poszczególnych wersji jest jednym z najważniejszych elementów całego rozwiązania. App Volumes nie służy jedynie do montowania dysku z programem. Jego właściwym zadaniem jest zarządzanie pełnym cyklem życia aplikacji.

Classic Delivery i On-Demand

App Volumes może dostarczać aplikacje w dwóch podstawowych modelach. Pierwszym jest Classic Delivery.

W tym trybie pakiet jest podłączany podczas uruchamiania maszyny lub logowania użytkownika. Aplikacja jest więc gotowa do użycia od początku sesji. Jest to dobre rozwiązanie dla programów wykorzystywanych codziennie, ponieważ użytkownik nie musi czekać na podłączenie pakietu przy pierwszym uruchomieniu.

Classic Delivery ma jednak pewną wadę. Jeżeli użytkownik ma przypisanych wiele aplikacji, wszystkie odpowiednie pakiety muszą zostać podłączone podczas rozpoczynania sesji. Może to zwiększyć czas logowania i spowodować, że do maszyny zostaną podłączone również programy, z których użytkownik w danym dniu w ogóle nie skorzysta.

Drugim modelem jest On-Demand. W tym przypadku użytkownik widzi skrót do aplikacji, ale właściwy pakiet nie musi być podłączany podczas logowania. Operacja następuje dopiero wtedy, gdy użytkownik próbuje uruchomić program.

Pozwala to ograniczyć liczbę pakietów podłączanych na początku sesji. Jeżeli użytkownik ma dostęp do kilkunastu specjalistycznych programów, ale podczas konkretnej sesji korzysta tylko z dwóch, nie ma potrzeby montowania wszystkich wirtualnych dysków od razu.

Ceną za takie podejście jest krótkie opóźnienie podczas pierwszego uruchomienia aplikacji. App Volumes musi wtedy obsłużyć żądanie, sprawdzić przypisanie, podłączyć właściwy pakiet i zintegrować jego zawartość z systemem Windows.

Po podłączeniu pakietu kolejne uruchomienia aplikacji w ramach tej samej sesji odbywają się już normalnie.

Czym są Writable Volumes?

Pakiety aplikacji są woluminami tylko do odczytu. Użytkownik może uruchomić znajdujący się w nich program, ale nie może trwale zmienić zawartości samego pakietu.

App Volumes posiada również mechanizm Writable Volumes. Jest to indywidualny wolumin użytkownika działający w trybie odczytu i zapisu. Może przechowywać między innymi aplikacje zainstalowane przez użytkownika, ustawienia aplikacji, dane licencyjne lub inne zmiany wykonywane w systemie.

Writable Volume jest podłączany do urządzenia podczas sesji użytkownika i może podążać za nim pomiędzy kolejnymi wirtualnymi desktopami. Dzięki temu nawet w środowisku opartym na nietrwałych maszynach można zachować wybrane zmiany pomiędzy sesjami.

Nie oznacza to jednak, że Writable Volumes powinny automatycznie zastąpić rozwiązania do zarządzania profilami. Jeżeli potrzebujemy jedynie zachować ustawienia aplikacji i konfigurację środowiska użytkownika, właściwszym i prostszym rozwiązaniem może być Omnissa Dynamic Environment Manager.

Writable Volumes mają sens przede wszystkim w przypadkach, w których użytkownik musi samodzielnie instalować aplikacje lub korzysta z oprogramowania, którego nie możemy łatwo dostarczyć w standardowym pakiecie. Przed ich wdrożeniem warto więc dokładnie określić, jaki problem chcemy za ich pomocą rozwiązać.

Trzeba również pamiętać, że Writable Volume jest elementem trwałym. W przeciwieństwie do pakietu aplikacji przechowuje zmiany użytkownika, dlatego wymaga odpowiedniego monitorowania, zabezpieczenia i uwzględnienia w planie odtwarzania środowiska.

Golden image, App Volumes i Dynamic Environment Manager

Najłatwiej zrozumieć rolę App Volumes, gdy spojrzymy na środowisko użytkownika jako na kilka oddzielnych warstw.

Golden image powinien dostarczać system operacyjny, agenty oraz podstawowe komponenty wymagane przez wszystkich użytkowników. Niektóre aplikacje również mogą pozostać w obrazie, szczególnie jeżeli są mocno powiązane z systemem, instalują sterowniki lub muszą być dostępne na bardzo wczesnym etapie uruchamiania Windows.

App Volumes odpowiada za dodatkowe aplikacje, które chcemy aktualizować niezależnie od systemu albo przypisywać tylko wybranym użytkownikom. Dzięki temu ten sam golden image może zostać wykorzystany przez kilka działów, mimo że każdy z nich korzysta z innego zestawu programów.

Dynamic Environment Manager odpowiada za konfigurację środowiska użytkownika i zachowanie ustawień aplikacji. Sam program może zostać dostarczony przez App Volumes, natomiast jego indywidualne ustawienia mogą zostać przechwycone i odtworzone przez DEM.

Przykładowo App Volumes może dostarczyć użytkownikowi program Notepad++, natomiast Dynamic Environment Manager może zachować jego ustawienia, wygląd interfejsu oraz inne elementy zapisane w profilu użytkownika.

Żadna z tych technologii nie rozwiązuje dokładnie tego samego problemu. Golden image dostarcza system bazowy, App Volumes dostarcza aplikacje, a DEM zarządza konfiguracją środowiska użytkownika. Dopiero ich połączenie pozwala stworzyć środowisko, w którym system, aplikacje, ustawienia i dane użytkownika mogą być utrzymywane niezależnie.

Czy każda aplikacja nadaje się do App Volumes?

App Volumes nie jest rozwiązaniem, które pozwala bezproblemowo zapakować dowolny program.

Szczególną ostrożność należy zachować przy aplikacjach instalujących sterowniki, filtry systemu plików, komponenty działające w trybie jądra albo mocno ingerujące w system operacyjny. Takie elementy mogą być wymagane jeszcze przed pełnym uruchomieniem App Volumes Agent, dlatego często bezpieczniej pozostawić je w golden image.

Problematyczne mogą być również aplikacje posiadające nietypowe mechanizmy licencjonowania, zależne od konkretnego sprzętu lub wymagające ściśle określonej kolejności instalowania komponentów.

Każda aplikacja powinna zostać przetestowana nie tylko samodzielnie, ale również w połączeniu z pozostałymi pakietami przypisanymi danej grupie użytkowników. Dwa pakiety mogą działać prawidłowo osobno, ale po jednoczesnym podłączeniu powodować konflikt plików, bibliotek, wpisów rejestru lub skojarzeń rozszerzeń.

Nie należy również usuwać z golden image wszystkich aplikacji za wszelką cenę. Celem App Volumes nie jest stworzenie całkowicie pustego obrazu. Chodzi o znalezienie rozsądnego podziału pomiędzy systemem bazowym a aplikacjami dostarczanymi dynamicznie.

Aplikacje wykorzystywane przez wszystkich użytkowników, ściśle powiązane z systemem lub zawierające sterowniki mogą nadal pozostać w obrazie. App Volumes najlepiej wykorzystać tam, gdzie rzeczywiście upraszcza ono przypisywanie, aktualizowanie i testowanie programów.

Podsumowanie

Omnissa App Volumes pozwala oddzielić aplikacje Windows od systemu operacyjnego i zarządzać nimi niezależnie od golden image.

Administrator przygotowuje aplikację na dedykowanej maszynie, przechwytuje ją do pakietu i przypisuje wybranym użytkownikom lub komputerom. Podczas logowania albo pierwszego uruchomienia programu odpowiedni wirtualny dysk zostaje podłączony do desktopu, a App Volumes Agent integruje jego zawartość z systemem Windows.

Użytkownik otrzymuje normalnie działającą aplikację, natomiast administrator może przygotowywać nowe wersje, przeprowadzać testy i wycofywać zmiany bez każdorazowej przebudowy całego golden image.

App Volumes nie eliminuje obrazu bazowego ani narzędzi takich jak Dynamic Environment Manager. Uzupełnia je, tworząc oddzielną warstwę odpowiedzialną za dostarczanie aplikacji i zarządzanie ich cyklem życia.