Sterowniki na maszynie

Jednym z ważniejszych osiągnięć projektu Xen, a dokładniej Xen 2.0, jest wspomniana wyżej architektura i mechanizmy zarządzania sterownikami urządzeń, które - statystycznie rzecz biorąc - stanowią gros zagrożeń dla stabilności systemów operacyjnych. Aby uczynić sterowniki nieszkodliwymi dla dostępności środowiska jako całości, inżynierowie pracujący nad Xen postanowili umieścić je w oddzielnej maszynie wirtualnej, a dokładnie w działającym w jej środowisku jądrze Linuxa.

Można sobie wyobrazić, że z biegiem czasu każdy system będzie mógł dysponować dodatkową maszyną wirtualną, która będzie przechowywać właściwe dla niego sterowniki. Jeśli na tym samym sprzęcie miałyby działać systemy tak różne, jak Linux i Windows, a nie jedynie kilka odmian Linuxa, byłoby to rozwiązanie idealne - zarówno wygodne, jak i bezpieczne. Ale nawet obecnie awaria sterownika nie pociągnie za sobą ani awarii platformy wirtualizacyjnej, ani korzystających z niego systemów - gości - uszkodzony sterownik zostanie wyłączony i uruchomiony ponownie.

Jedynym zagrożeniem dla opisanej wyżej konstrukcji współdzielenia zasobów sprzętowych jest technologia bezpośredniego dostępu urządzeń do pamięci (DMA - Direct Memory Access). Jest tak, ponieważ współdzielenie zasobów opiera się na zarządzaniu przez Xen stronicowaniem współdzielonej pamięci. Jeżeli urządzenie - czy to przypadkowo, czy też na skutek działania złośliwego kodu, nadpisze pamięć bez kontroli mechanizmów Xen, może dojść do większej awarii sterowników. Architektura Xen jest na tyle elastyczna, że przewiduje możliwość udostępnienia systemowi operacyjnemu bezpośredniego dostępu do urządzenia, ale będzie to raczej dotyczyć zastosowań biurkowych, w których od efektywnej komunikacji oprogramowania ze sprzętem zależy wydajność grafiki lub dźwięku.

Wprost do pamięci

Drugim ważnym elementem platformy Xen jest architektura zarządzania pamięcią, która w bezpośredni sposób przekłada się na wydajność. W architekturach w pełni zwirtualizowanych zarządzanie pamięcią polega na przedstawianiu systemom operacyjnym pewnej reprezentacji pamięci, której związek z adresacją fizyczną jest co najwyżej luźny.

System widzi spójny obszar pamięci o określonym zakresie adresów, tymczasem w rzeczywistości jego dane są przeplecione z danymi innych systemów działających równolegle.

Takie podejście do sprawy wydaje się słuszne, ale analogie bazodanowe (surowe dane i indeksy) nie bardzo się tu sprawdzają. Ciągłe kojarzenie adresu z konkretnym systemem powoduje narzut na wydajność.

Znając ograniczenia dotychczasowych architektur wirtualnych, twórcy Xen postawili na pełną jawność. Xen otwarcie rezerwuje pewien zakres adresów pamięci dla systemu i pozwala mu na bezpośredni dostęp do nich, pilnując tylko, by system nie czytał i nie pisał do adresów wykraczających poza przyznany przedział. Mniej warstw abstrakcji do pokonania i bezpośredni dostęp do pamięci fizycznej wystarczą, by w dziedzinie wydajności Xen bił na głowę klasyczne rozwiązania wirtualizacyjne.

Mechanizm stronicowania pamięci w Xen działa na tyle sprawnie, że to na jego poziomie właśnie odbywa się współdzielenie informacji pomiędzy różnymi systemami. Xen śledzi to, do którego systemu - gościa konkretna strona pamięci jest aktualnie przypisana i stanowi gwarancję braku wzajemnego wchodzenia sobie w drogę przez systemy, np. przy wspólnym korzystaniu z jednej karty sieciowej itp. Powstające przy takiej konstrukcji komunikacji ze sprzętem opóźnienia związane np. ze zmianą kontekstu są w praktyce pomijalne - zwłaszcza w porównaniu z architekturą całkowicie zwirtualizowaną.

Pierwszeństwo procentuje

Pod koniec stycznia ukazała się poprawiona, stabilna wersja pakietu Xen 2.0.3. W tych dniach IBM ogłosił, że przeniesie na platformę Xen narzędzie sHype, służące do ustalania i wymuszania reguł współdzielenia zasobów między domenami o różnych poziomach uprawnień. W dalszej kolejności, choć bez deklarowania dat, IBM zamierza przenieść na Xen narzędzia wzmacniające izolację zasobów i automatyczną kontrolę uprawnień, a także narzędzia do bezpiecznego monitorowania stanu i pomiaru wykorzystania zasobów.

IBM do perfekcji opanował sztukę inwestowania w open source bez wydawania pieniędzy i zarabiania na tym, co ponoć nic nie kosztuje. Angażując się w rozwój Xen na pewno nie robi tego bezinteresownie. Z drugiej strony, sami twórcy Xen roztaczają wizje, w których rozproszone serwery Xen - tzw. Xenoservers - działają jako rozproszone, samoorganizujące się zasoby, co akurat jest zbieżne z lansowanymi przez IBM hasłami grid computing i autonomic computing.

Zdaje się jednak, że nie tylko IBM ma chrapkę na bycie tym pierwszym, który odniesie największe korzyści z nowej technologii. Na fali zainteresowania technologią Xen zamierza wypłynąć Mandrakesoft, wydając - prawdopodobnie jeszcze w tym roku - wersję systemy Mandrake Linux dla tej platformy. Novell i Red Hat miały być może własne plany w dziedzinie wirtualizacji, ale w świetle dojrzewającego w oczach i zyskującego poparcie ich wielkich partnerów Xen, muszą się jakoś ustosunkować. Na dłuższą metę raczej nie będą mogły go zignorować.

Szum wokół technologii Xen daje się zauważyć także wśród inwestorów. Fundusz Venture Capital Kleiner Perkins Caufield & Byers zainwestował 6 mln USD w firmę XenSource, która zamierza zarabiać na usługach wdrożeniowych i doradczych wokół Xen. Niewykluczone, że kiedyś taka specjalistyczna firma zostanie przejęta przez IBM lub inną firmę specjalizująca się w usługach.