Funkcjonalność systemu Solaris 10 to najlepszy dowód na to, że Sun, pomimo niedawnych kłopotów finansowych, ma szansę na nowo zawojować rynek korporacyjny.

O nowym systemie Solaris już od dłuższego czasu wiadomo było, że wniesie wiele nowości. Sun Microsystems milczał jednak na temat szczegółów, przebąkując jedynie o możliwości podziału systemu na partycje czy rozszerzone możliwości kontroli uprawnień użytkowników i procesów. Lista nowości Solaris 10 jest bardzo długa, a przy tym naszpikowana udoskonaleniami co najmniej równie interesującymi jak partycje systemowe, zwane przez Sun containers czy też zones.

Oprócz partycji wymienić trzeba nowy, skalowalny i niezawodny system plików ZFS, unikalne narzędzie do analizy problemów i optymalizacji wydajności DTrace, mechanizmy automatycznie wykrywające i usuwające nieprawidłowości w działaniu sprzętu i oprogramowania i zwiększoną wydajność funkcji sieciowych - by wymienić te najważniejsze. Pomniejszych, choć w wielu wypadkach bardzo użytecznych, nowości jest znacznie, znacznie więcej.

System jak kontenerowiec

Przełomową innowacją Solaris 10 jest możliwość podziału systemu operacyjnego na partycje. To ważny krok w ewolucji oferty, jako że Sun oferował dotychczas jedynie możliwość uruchamiania oddzielnych kopii całego systemu operacyjnego na oddzielnych płytach głównych większych serwerów. Podział zasobów systemu Unix na niezależne od siebie domeny oferuje od pewnego czasu IBM, który zaadaptował na te potrzeby technologię maszyn wirtualnych definiowanych w mikrokodzie procesora. W podobnym kierunku zmierza, jak się wydaje, również HP.

Sun przyjął inną filozofię. Zamiast uruchamiać wiele kopii systemu obok siebie, utrzymał jedno jądro i pojedyncze kopie wszystkich usług systemowych. Partycjonowanie w Solaris 10 polega na dodaniu warstwy logiki, dzięki której procesy, usługi i zasoby przypisywane są do jednego z wielu tzw. kontenerów czy też zon, definiowanych w ramach zony globalnej. Każdemu kontenerowi przypisywany jest wycinek mocy obliczeniowej i zasobów systemu (pamięci, systemu plików itp.).

Kontener prowadzi własną listę procesów i zarządza nimi niezależnie od pozostałych, zawiera własną przestrzeń nazw, własne pliki konfiguracyjne, biblioteki, skrypty, listy użytkowników, spisy haseł, konsole administracyjne itp. W ramach systemu jako całości istnieją pojedyncze kopie podstawowych usług. Działając wewnątrz kontenera procesy nie są "świadome" istnienia innych kontenerów w ramach tego samego systemu. Bezpośrednia komunikacja między procesami (mechanizm IPC - Inter-Process Communications) działa wyłącznie w ramach jednego kontenera. Aby skomunikować ze sobą procesy działające w różnych zonach, trzeba to zrobić za pośrednictwem wirtualnych interfejsów sieciowych.

Konsekwencją daleko idącej separacji kontenerów jest wysoka odporność na awarie systemu jako całości - ograniczone do minimum jądro realizuje właściwie jedynie funkcje kontroli dostępu do zasobów - wszystkie pozostałe funkcje działają w wyższych warstwach w ramach kontenerów. W rezultacie awaria aplikacji czy zagrożenie bezpieczeństwa w jednym kontenerze nie ma wpływu na działanie pozostałych. Można więc wyobrazić sobie wydajne klastry, których węzły działają w różnych zonach. Mimo separacji, aplikacji używanych w wielu kontenerach nie trzeba instalować oddzielnie w każdej z nich.

Narzędzia dla dociekliwych

Sun położył duży nacisk na to, by Solaris 10 wymagał możliwie jak najmniej interwencji administratora. Solaris Fault Manager to moduł, który w czasie rzeczywistym zbiera i analizuje informacje o zdarzeniach zachodzących w systemie. Gdy wykryje nieprawidłowości, uruchamia odpowiedni moduł Solaris Fault Agent, który automatycznie naprawia problem i raportuje rezultaty właściwemu administratorowi. Agent odpowiedzialny za pamięć będzie więc sprawdzać przyczyny błędów pamięci i, jeśli będą się powtarzać, wyłączy określone adresy z dostępnej puli pamięci. Jeśli problemem okaże się niestabilna aplikacja, odpowiedni agent sprawdzi jej zachowanie i ewentualnie wstrzyma, wyłączy lub zrestartuje.

Podobny mechanizm, zwany Solaris Service Manager, został stworzony na potrzeby monitorowania i zarządzania usługami systemowymi. W obu przypadkach rozwiązania zostały zaprojektowane tak, by w przyszłości możliwe było dodawanie/aktualizowanie modułów analizujących poszczególne kategorie zdarzeń (procesy, pamięć, operacje I/O itd.), jak i reagujących na nieprawidłowości. Sun stworzył do tego celu dedykowane interfejsy API.

Automatyzacja będzie nabierać znaczenia, ale na pewno nie wszystko będzie można naprawić automatycznie. Aby ułatwić administratorom dochodzenie prawdy o rzeczywistych przyczynach problemów, Sun wbudował w Solaris 10 narzędzie do śledzenia i optymalizacji pracy procesów o nazwie DTrace. Ten niepozorny program może okazać się w praktyce jednym z poważniejszych powodów do migracji do Solaris 10. Tym, co odróżnia DTrace od podobnych narzędzi spotykanych w innych systemach operacyjnych, jest śledzenie oparte na zmianie stanu procesu.

To przełom, ponieważ śledzenie oparte wyłącznie na czasie (które DTrace również umożliwia) nie jest w stanie wychwycić bardzo szybkich zmian w stanach procesów (trwających poniżej 10 ms), a w skrajnych przypadkach nawet w ogóle ich nie stwierdzić! Tymczasem zdarza się, że w systemie występuje sporo krótkich operacji, które zajmują większość czasu procesora podczas określonego przerwania. Możliwość poznania każdego bez wyjątku stanu procesu to obietnica znacznej optymalizacji wydajności aplikacji. Aby poprawić wydajność śledzenia, Sun po prostu zrezygnował z translacji formatu zapisu czasu w języku maszynowym na format czytelny dla narzędzi używanych przez administratorów. Translacja jest wykonywana dopiero wtedy, gdy administrator chce analizować dane.