Artykuł
10/30/2014

SoftGrid – wirtualizacja aplikacji, cz. II - Zarządzanie

Autor: Barbara Wróbel

Opublikowano: 3 lipca 2007

Zawartość strony

	Zarządzanie
	Od strony klienta
	Integracja SoftGrid
	Podsumowanie
	Dodatkowe informacje
	Przeczytaj pozostałe części tego artykułu

Zarządzanie

W pierwszej części artykułu utworzyliśmy pakiet aplikacji, czas zatem poddać go dystrybucji. W tym celu przenosimy się do SoftGrid Virtual Application Server, by skonfigurować wszelkie niezbędne parametry tego procesu. Otwieramy konsolę MMC, która na pewno w znacznym stopniu nam w tym pomoże (Rys. 10).

Rys. 10. Konsola MMC.

Zanim jednak zabierzemy się do wdrażania konkretnej aplikacji, najpierw należy zrobić jeszcze jedną bardzo ważną rzecz. Po podłączeniu się do danego serwera i kliknięciu w jego nazwę prawym przyciskiem będziemy mieć możliwość skonfigurowania tzw. „System options”. Należy tu wpisać ścieżkę prowadzącą do (wspomnianego już przy omawianiu sequencera) katalogu „content”, gdzie składowane będą pliki instalacyjne (Rys. 11). Ścieżka ta powinna być w formacie UNC (co oczywiście wymusza potrzebę wcześniejszego udostępnienia tego katalogu) lub w postaci URL (co z kolei wymaga stworzenia wirtualnego katalogu na serwerze WWW).

Rys. 11. Konfiguracja „System options”.

Jeśli ktoś już wcześniej zetknął się z SoftGrid, zapewne tutaj zastanowi się, po co takie udostępnianie, skoro SoftGrid funkcjonuje wykorzystując protokoły: RTSP (port TCP 554) lub RTSPS (port TCP 332). Wszystko się zgadza. Działa on na tych wymienionych portach, ale przede wszystkim w fazie przesyłania strumienia aplikacji. Skróty aplikacji, a ściślej powiązania plików .osd, które pojawią się na pulpicie klienta, ściągane są albo za pośrednictwem udziałów sieciowych lub wykorzystując serwer www. Do dokładniejszego przeanalizowania tego procesu powrócimy jeszcze w części artykułu poświęconej klientowi.

A przy okazji - jeszcze jedna bardzo ważna uwaga. Jeśli wykorzystamy nieszyfrowane RTSP, to oprócz portu 554 na serwerze do połączenia użyte zostaną również wybrane porty z zakresu 49152-65535, co oczywiście należy uwzględnić w konfiguracji ewentualnego firewalla. Choć udostępnienie przez firewall na zewnątrz tak dużego zakresu portów i tak chyba nie jest zbyt dobrym pomysłem. Więc jeśli zamierzamy umożliwić połączenia z zewnątrz sieci, raczej wypada użyć RTSPS lub innej formy zabezpieczenia, jak na przykład VPN.

Ale powróćmy może do naszej konsoli i rozpocznijmy import pakietu aplikacji. Jak widzieliśmy, w konsoli mamy dwie gałęzie, które teoretycznie mogą posłużyć temu celowi: „Applications” i „Packages”. I pomimo że skojarzenie nazewnicze kusi by wybrać „Packages” sugeruję, by kliknąć prawym przyciskiem „Applications” i wybrać z menu „Import applications…”. Pozwoli to nam na zaimportowanie całego projektu, a więc oprócz głównego pliku .sft również odpowiednich wskazań do plików .osd czy też .ico, oraz da możliwość zadecydowania przy okazji o kilku dodatkowych sprawach, jak np. kto ma mieć uprawnienia do uruchamiania pakietu, czy też jakie zasady licencyjne go dotyczą. Będziemy mieć również okazję do ewentualnej zmiany decyzji odnośnie miejsca położenia skrótów do aplikacji u klienta, czy też co do tego, jakie rozszerzenia mają być skojarzone z aplikacją (Rys. 12).

I tak naprawdę w tym momencie ukończyliśmy najprostszy możliwy wariant konfiguracji pakietu. Aplikacja jest już gotowa do dostarczenia klientowi.

Rys. 12. Dodatkowe właściwości.

Z ważniejszych rzeczy, które możemy dodatkowo dokonfigurować warto tylko jeszcze zwrócić uwagę na pole „Application License Group”, umożliwiające przypisanie wybranej polityki licencjonowania. SoftGrid pozwala na skonstruowanie polityk licencjonowania w zakresie kontroli ilościowej równoczesnego wykorzystania licencji. Można też bezpośrednio wskazać numer licencji dla konkretnego, imiennie wymienionego (czyli mającego konto w Active Directory) użytkownika.

I na koniec wspomnę już tylko o gałęzi „Reports”, pozwalającej na kontrolowanie wykorzystania aplikacji przez użytkowników.

Do początku strony

Od strony klienta

SoftGrid for Windows Desktops Client jest oprogramowaniem klienckim, dzięki któremu klient jest w stanie połączyć się z serwerem SoftGrid i pobrać stamtąd niezbędne mu aplikacje.

Każda dostępna na serwerze dla danego klienta aplikacja, po ściągnięciu jej na stację klienta umieszczana jest w dwóch miejscach (Rys. 13). Ustawienia ogólne, które jej dotyczą domyślnie znajdą się w katalogu c:\documents and settings\all users\dokumenty natomiast te specyficzne dla danego użytkownika trafią do jego profilu, a dokładnie do %appdata%. I nawet gdyby pliki ściągniętego pakietu z któregoś z tych katalogów użytkownik usunął lub na skutek innego zdarzenia uległy one uszkodzeniu, nie będzie problemu. SoftGrid przy następnym uruchomieniu aplikacji naprawi taką awarię powtórnie pobierając niezbędne pliki.

Użyty model buforowania aplikacji ma jeszcze jedną bardzo ważną zaletę. Nawet gdy klient utraci połączenie z siecią, cały czas będzie w stanie aplikację uruchomić. Duży plus w porównaniu do na przykład usług terminalowych.

Jak widać poniżej, podczas instalacji następuje również nawiązanie do dysku Q:\, który będzie używany wyłącznie na potrzeby naszych wirtualnych aplikacji. Przy próbie otwarcia bezpośrednio takiego dysku otrzymujemy komunikat o braku praw dostępu. Zatem żaden z użytkowników nie będzie w stanie dokonać na nim jakiś szkodliwych zmian.

Rys. 13. Lokalizacja ściągniętej aplikacji.

Po instalacji oprogramowania klienta narzędziem, dzięki któremu użytkownik może kontrolować swoje podłączenie do serwera, jest konsola „SoftGrid Client Management”.

Pierwszą rzeczą, którą należy zawsze sprawdzić, jeśli mamy problemy z aplikacjami SoftGrid jest konfiguracja w gałęzi „Desktop Configuration Servers”. Znajdziemy tu adres serwera SoftGrid, do którego łączy się klient (Rys. 14).

Rys. 14. Adres serwera SoftGrid.

Po wejściu w jego właściwości zobaczymy, że wybieramy tutaj przede wszystkim typ serwera, z którym się łączymy. Na liście dostępnych typów mamy (Rys. 15):

SoftGrid Virtual Application Server
Secure SoftGrid Virtual Application Server
Standard HTTP Server
Secure HTTP Server

Przyznam się, że mnie początkowo ten wybór wprawił w małe zdumienie. A stało się tak w dużej mierze za sprawą artykułu, który wcześniej przeczytałam, a mianowicie: https://support.microsoft.com/default.aspx/kb/932017 (j. ang.).

W artykule tym w sekcjach „Streaming” i w „Desktop configuration refresh” wyraźnie dokonano rozróżnienia, które porty służą przesyłaniu skrótów do aplikacji, a które samemu strumieniowaniu aplikacji. Jak zatem teraz na jednej liście wyboru można mieszać dwa, tak różne od siebie, zastosowania? Okazuje się, że można, bo z tymi portami RTSP (RTSPS), to nie jest zupełnie tak, że służą one wyłącznie strumieniowaniu.

Jeśli wybierzemy tutaj SoftGrid Virtual Application lub Server Secure SoftGrid Virtual Application Server, to połączenie w początkowej fazie nastąpi odpowiednio po protokole RTSP lub RTSPS, by następnie za pośrednictwem udziałów sieciowych lub protokołu HTTP ściągnąć niezbędne pliki .osd, .ico (czyli pliki związane ze skrótami, służące uruchomieniu aplikacji). Uważny czytelnik zapewne zwrócił uwagę, że wymieniony tu został protokół HTTP – prawidłowo, to nie jest pomyłka, on też znajdzie tu zastosowanie. Jeśli we właściwościach aplikacji na serwerze ścieżkę do plików .osd i .ico zapiszemy w formie URL, to właśnie protokół HTTP zostanie użyty do ściągnięcia tych plików.

Może zatem powstać pytanie, po co na poniższej liście opcje „Standard HTTP Server” i „Secure HTTP Server”, skoro HTTP jest możliwe do realizacji również przy dwóch pierwszych? Otóż w tym przypadku oczywiście połączenie od razu jest realizowane bezpośrednio po protokole HTTP (czy też HTTPS). Dodatkowo daje to możliwość posłużenia się specjalnym, stworzonym przez nas plikiem XML, który po umieszczeniu na danym serwerze WWW będzie zawierał wskazania do aplikacji SoftGrid.

Rys. 15. Lista dostępnych typów serwera.

W naszym przykładzie wybraliśmy z listy „SoftGrid Virtual Application Server” i za pomocą tego typu serwera nastąpi połączenie. Domyślnie takie połączenie następuje w momencie logowania się klienta, lecz można również dodatkowo ustawić, by co pewien czas odbywało się sprawdzanie czy nie zaszły jakieś zmiany w konfiguracji.

Przenieśmy się może teraz do gałęzi „Applications”. Zobaczymy tutaj wszystkie aplikacje, które zostały wykryte przez klienta SoftGrid jako przypisane danemu użytkownikowi. Zwróćmy uwagę na kolumnę „Package status” (Rys. 16). Informuje nas ona, ile danych z pakietu aplikacji już zostało ściągniętych na stację. Odbywa się to zgodnie z opisaną przy sequencerze polityką ściągania aplikacji (podział aplikacji na dwie części).

Rys. 16. Kolumna „Package status”.

Dodatkowo, jeśli prawym przyciskiem klikniemy taką aplikację możemy w razie potrzeby dokonać na niej paru przydatnych operacji, typu ściągnięcie jej w całości do klienta (co może się okazać przydatne, gdy przewidujemy, że będziemy później odłączeni od sieci a chcielibyśmy mieć dostęp do wszystkich funkcjonalności aplikacji), czy też usunięcie jej z dysku.

I w ten sposób dotarliśmy do końca naszego procesu przygotowywania aplikacji w środowisku SoftGrid. Pozostaje już chyba tylko uruchomienie aplikacji. Uff… działa :-)

Rys. 17. Uruchomiona aplikacja.

Do początku strony

Integracja SoftGrid

Zbliżamy się powolutku również do końca artykułu. Zanim to jednak nastąpi sądzę, że warto wspomnieć jeszcze jeden kierunek rozwoju SoftGrid – jego integrację z dotychczasowymi rozwiązaniami. O integracji z usługami terminalowymi już wspominałam, teraz mam na myśli integrację z SMS (ang. System Management Server).

Dzięki zainstalowaniu dodatku Microsoft SoftGrid SMS Connector można bowiem wykorzystać istniejącą infrastrukturę SMS do udostępniania aplikacji SoftGrid. SMS staje się niejako pośrednikiem pomiędzy serwerem SoftGrid, a klientem pozwalając na wykorzystanie dwóch metod dystrybucji:

Dynamic – w której to metodzie mamy tradycyjne podejście SoftGrid do podziału pakietu aplikacji na dwie części
Push – kiedy SMS wysyła od razu do klienta cały pakiet w całości

Takie połączenie SMS i SoftGrid pozwoli w jednym punkcie skupić zarówno zarządzanie aplikacjami instalowanymi lokalnie, jak i tymi wirtualnymi.

Do początku strony

Podsumowanie

Jak widać SoftGrid jest dość ciekawym rozwiązaniem. W pierwszej chwili, gdy się z nim stykamy mogłoby się wydawać, że jest to kolejne oprogramowanie bazujące na usługach terminalowych. Tak jednak nie jest. Albowiem aplikacje są tutaj dostarczane na zupełnie innych zasadach i co najważniejsze, wykorzystują moc lokalnych komputerów, na których są uruchamiane. Czerpią jednak z idei działania usług terminalowych to co najlepsze, czyli brak konieczności ingerencji w system operacyjny klienta.

Jako że produkt jest jeszcze dość nowym rozwiązaniem, może tylko troszkę martwić zaskakująco uboga dokumentacja do niego. Miejmy nadzieję, że niedługo jednak to się zmieni i tym samym umożliwi jeszcze dokładniejsze zapoznanie się z SoftGrid, bo osobiście sądzę, że naprawdę warto.

Do początku strony