Serwer SELS 10 wirtualizacja i dostępność

SUSE Linux Enterprise Server wersja 10 oferuje m.in. Xen i AppArmor - dwa nowe mechanizmy, które w sieci przedsiębiorstwa mogą być bardzo użyteczne, o ile Novell jeszcze je "doszlifuje".

SUSE Linux Enterprise Server wersja 10 oferuje m.in. Xen i AppArmor - dwa nowe mechanizmy, które w sieci przedsiębiorstwa mogą być bardzo użyteczne, o ile Novell jeszcze je "doszlifuje".

SLES 10, który pojawił się w połowie lipca, jest elementem serii SUSE Enterprise Linux, która obejmuje także SUSE Linux Desktop 10 i Novell Customer Care - portal zapewniający całodobowe (24/7) wsparcie techniczne (specjalnie nastawione na potencjalne problemy z tym wydaniem pakietu programowego) oraz aktualizację produktów pakietu SUSE Linux Enterprise.

Generalnie nowa wersja serwera jest porównywalna w zakresie szybkości działania z wcześniejszymi wydaniami. Przynosi też wiele nowych funkcji.

Powinny one zdobyć uznanie w przedsiębiorstwach i u usługodawców, o ile administratorzy poradzą sobie z kilkoma problemami, których istnienie ujawniły testy.

Pierwszą istotną zmianą w tym wydaniu jest rezygnacja z preferowania K Development Enviroment (KDE), które - chociaż nadal dostępne - ustępuje miejsca Gnome. Ten ostatni instaluje się teraz domyślnie jako podstawowy interfejs użytkownika i na dłuższą metę będzie prawdopodobnie lepiej obsługiwany przez Novella.

Kernel systemu jest wersją SUSE jądra Linux 2.6.16, którego szybkość działania jest trochę mniejsza w porównaniu z obsługą procesu bazowego w SLES 9. Na przykład wykonanie uniksowego "process fork + exec" (podstawowa miara szybkości działania) zabiera o 16% więcej czasu, ale obsługa we/wy i praca sieciowa są szybsze (zob. tabela).

Przy każdej instalacji system ten wykonuje selektywne autouaktualnianie, które jest bezbolesne i skuteczne, zwłaszcza gdy zostanie skoordynowane z programem Customer Care, rozsyłającym liczne powiadomienia o dostępnych łatkach, czasami nawet kilka razy dziennie. Uaktualnienia związane z bezpieczeństwem i megabajtowe uaktualnienia aplikacji mogą być sprowadzane automatycznie. Jakiekolwiek zależności od innych komponentów w takich uaktualnieniach są kontrolowane i podczas testów uaktualnienia zostały zainstalowane bez konieczności ręcznej interwencji. To stawia jakość usług wsparcia zapewnianych przez Novella na poziomie porównywalnym z Red Hat.

System operacyjny jest generalnie dobrze zaprojektowany w zakresie bezpieczeństwa. Aplikacje, które wpływają na bezpieczeństwo - takie jak Samba, oraz inne pliki konfiguracyjne aplikacji systemowych - są aktualne i bezpieczne. Jednak domyślne hasła są zbyt proste, nawet te zapewniające uprawnienia dostępu typu root. Bardziej pożądane byłoby wymuszanie trudniejszych haseł dla kont użytkowników, administratorów i root.

Do celów uwierzytelniania Novell wybrał Kerberos w wersji MIT (Massachusetts Institute of Technology), zamiast używanej w poprzednich wersjach systemu SUSE implementacji Heimdal.

Po stronie niedostatków należy wymienić niektóre z wychwalanych przez Novella mechanizmów zawartych w SLES 10. Xen - serwer open source wirtualizacji systemu operacyjnego - jest niepozbawiony błędów i trudny w użyciu. AppArmor - metoda definiowania charakterystyk wykonawczych aplikacji, działa, ale ma niedociągnięcia, m.in. brak użytecznego instrumentarium do zarządzania szablonami konfiguracyjnymi. Staną się one bardzo użyteczne, kiedy firma niektóre ich funkcje dopracuje.

<hr size="1" noshade>SUSE Linux Enterprise Server 10

Serwer SELS 10 wirtualizacja i dostępność

Producent: Novell

Zalety: Bogata obsługa sterowników dla różnych kombinacji CPU i płyt głównych oraz peryferii; dobry zestaw mechanizmów klasy przedsiębiorstwa; ulepszona obsługa serwisowa

Wady: Niektóre nowe mechanizmy wymagają żmudnego konfigurowania; część mechanizmów zapluskwiona

Cena: od 349 do 1499 USD rocznie, zależnie od zakresu wsparcia technicznego

<hr size="1" noshade>

System w działaniu

Podczas testów SLES 10 odnalazł większość komponentów sprzętowych dość łatwo, zatrzymując się jedynie na osobliwościach interfejsu ACPI i starszym sprzęcie Compaqa (zob. "Jak testowano"). Obsługa urządzeń USB jest teraz bardziej gruntowna i transparentna, chociaż niektóre urządzenia wykorzystujące USB, dostępne w laboratorium testowym, nie zostały zidentyfikowane , m.in. pamięć flash USB (w wersji 1.1).

Bardziej oszczędna instalacja domyślna zapewnia większość tego, co jest potrzebne. Wzbogacony administracyjny interfejs użytkownika Yet another System Tool (YaST) często zapewnia wiele dróg prowadzących do tego samego celu, oferując te same aplikacje w różnym menu. Jednak instrumentarium zapewniane przez YaST ma pewne braki na poziomie funkcjonalnym wierszy komend.

Xen do dopracowania

Serwer SELS 10 wirtualizacja i dostępność

Menu główne YaST

Novell zachwalał Xen jako niedrogą metodę efektywnego używania dostępnego sprzętu do obsługi wielu instancji sytemu operacyjnego w sposób wydzielony (a więc tym samym bezpiecznie). Gościnny system operacyjny, niebędący systemem SUSE, miał być bez przeszkód używany w sposób podobny do licznych metod wirtualizacji (przypominających VMware), które uczyniły Linux popularną platformą goszczącą. W rzeczywistości podczas testów napotkano wiele trudności w uzyskaniu stabilnej pracy Xen: liczne wyjątki wymagające obsłużenia i wiele zmian konfiguracyjnych niezbędnych do ustawienia wirtualizowanych sesji SLES 10. Novell ma na uwadze te problemy i zapowiedział przygotowanie odpowiednich łatek.

Xen wywiera bardzo mały wpływ na goszczony system operacyjny. Gościnny system operacyjny komunikuje się z systemem hostowym metodą podobną do Named Pipes, dedykowanego schematu "urządzenie fizyczne do urządzenia wirtualnego", używanego w OS/2 i Windows NT.

Xen jest aktywowany przez utworzenie tzw. hipervisora, który ładuje się do maszyny jako mikrojądro, które z kolei ładuje system operacyjny SLES 10 ze zmodyfikowanym pod Xen jądrem. Taka kombinacja tworzy podłoże dla kolejnych sesji systemu operacyjnego, które pojawiają się jako niezależne instancje SUSE Linux na tej samej maszynie. Obie sesje są ograniczone w przywilejach do profili używanych w obsługiwanych aplikacjach (Linux, Apache, MySQL, Perl, Python i PHP, Web, poczta elektroniczna lub inne). SUSE Enterprise 10 może także pracować pod VMware jako wirtualizowany system operacyjny.

Xen przekształca adresy pamięci rzeczywistej dla goszczonego systemu operacyjnego oraz jego jądra i sterowników, a także wirtualizuje dostępność sprzętu. Jest to pięta achillesowa Xen, ponieważ sterowniki open source, które mogą być modyfikowane, pracują lepiej niż zamknięte sterowniki źródłowe sprzętu. Konsekwencje są takie, że zamknięte sterowniki źródłowe dla monitorów, różnorodnych urządzeń sieci bezprzewodowych i innych nie działają lub dają nieoczekiwane rezultaty.

Dobra wiadomość to taka, że jeżeli używane są odpowiednie CPU (aktualnie akceptowane są jedynie Intel Vanderpool Technology i AMD SVM/Socket AM2), jądra mogą wirtualizować i inicjować wątki CPU, radząc sobie z obsługą systemów goszczonych. Brak odpowiednich CPU ogranicza hypervisor do jednej instancji gościnnego zmodyfikowanego jądra SUSE 2.6.16, czyli praktycznie do testów wdrożeniowych, a nie rzeczywistej wirtualizacji.

Xen okazał się także niezdolny do korzystania z wielu procesorów w systemie wielordzeniowym, ponieważ jest ograniczony do pierwszego CPU, który znajdzie, zamiast do wszystkich kolejnych. Xen ma wiele zadatków na dobry system wirtualizacji, ale na razie okazał się niestabilny i wymagający znacznego dostrajania, którego zakres zmienia się w zależności od hosta sprzętowego. Uzyskane wyniki pokazują znaczący wpływ na wydajność goszczonych jąder Xen. Na przykład test "process fork + exit" pracował ok. 89% dłużej na jądrze Xen niż na rodzimym, niezmodyfikowanym jądrze. Także przetwarzanie we/wy sieciowego na poziomie jądra Xen jest o ok. 40% mniej wydajne niż na niezmodyfikowanym jądrze SLES 10.

Skomplikowany AppArmor

Serwer SELS 10 wirtualizacja i dostępność

SLES 10 - konfigurowanie sprzętu

System AppArmor, który Novell udostępnił jako oprogramowanie open source, kontroluje zachowanie aplikacji i chroni je przed ukrytymi modyfikacjami lub podstawieniami. Stosuje oparte na regułach polityki profile do kontroli aplikacji poprzez ograniczanie dostępu do takich zasobów, jak specyficzne porty sieciowe czy pliki. AppArmor jest uaktywniany w SUSE 10 domyślnie, ale nie jest przygotowany do obsługi specyficznych aplikacji z marszu. Novell zapewnia predefiniowane profile dla ograniczonej liczby aplikacji, obejmujących Secure Shell (SSH), RADIUS i LDAP (Lighweight Directory Access Protocol).

Podczas testów znaleziono kilka dodatkowych profili aplikacji, które Novell opatrzył w dokumentacji etykietką "niedojrzałe". Włączenie AppArmor dla minimalnego zestawu usług pracujących na maszynie testowej wymagało jednak użycia tych uzupełniających profili.

Dokumentacja sugeruje, że każdy może zaprojektować profile dostosowane. Okazuje się jednak, że jest to proces złożony, wymagający profilowania aplikacji i monitorowania ich użycia. Przeciętny użytkownik będzie zapewne rozpoczynał z predefiniowanymi profilami dla takich standardów, jak SSH, RADIUS i LDAP.

Ogólnie, AppArmor oferuje duży potencjał jako narzędzie ochronne, ale nie zastąpi hostowych systemów wykrywania wtargnięć czy prewencji, ponieważ oferuje zbyt mały wybór instrumentów do profilowania aplikacji, a kombinacja AppArmor (bez dziennika zdarzeń) z wbudowaną zaporą ogniową (z ubogą rejestracją zdarzeń) generuje niedostateczną ilość informacji niezbędnej do integracji z infrastrukturą zarządzania zdarzeniami na poziomie przedsiębiorstwa.

Uboga domyślność

Serwer SELS 10 wirtualizacja i dostępność

Wydajność SLES

W nowej wersji SUSE Linux brakuje wyższego stopnia kontroli bezpieczeństwa na poziomie domyślnym. Syslog jest używany do rejestrowania błędów i komunikatów sterujących (za pośrednictwem syslog-ng), ale reprezentuje podejście typu "wszystko lub nic". Co prawda możliwe jest użycie różnych skryptów do wyciągania specyficznych informacji z plików logu, ale ich użycie podczas testów dawało w kategorii błędów systemowych i zarejestrowanych zdarzeń albo nadmiar informacji, albo praktycznie ich brak.

Domyślna konfiguracja prowadzi także do problemów związanych z bezpieczeństwem. SLES 10 używa algorytmu Blowfish do uwierzytelniania i chociaż dostępny jest MD5, to nie jest instalowany domyślnie. Domyślna instalacja zawiera Network System File i procmail, które powinny być wyłączone, jeżeli system ma być uważany za wzmocniony pod względem bezpieczeństwa w konfiguracji domyślnej.

Serwer SELS 10 wirtualizacja i dostępność

Ocena SLES 10

Natrafiono także na trudności z inicjującymi i docelowymi komponentami/sterownikami iSCSI w dystrybucji SLES 10. Uzyskano połączenie serwerów SLES 10 za pośrednictwem systemu plików iSCSI, montując łatwo schemat wirtualizacji. Jednak napotkano trudności w przeszukiwaniu zdalnie montowanego systemu plików i podczas eksploracji jednego z takich systemów pojawiły się błędy szyny.

Podsumowanie

SLES 10 jest teraz komponentem strategii SUSE Linux Novella i zmiany, jakie można w nim zauważyć, są znaczące, ale wymagają pewnego dopracowania. Dobra wiadomość to taka, że z większością problemów można sobie poradzić przez konfigurowanie i dostrojenie. Stałym mankamentem jest niestabilność Xen, dlatego Novell powinien ustabilizować ten mechanizm, by SLES 10 znalazł powszechne zastosowanie w przedsiębiorstwach.

Jak testowano

SUSE Linux Enterprise Server 10 testowano na kilku platformach, w tym HP DL140s (dwa Xeony 32-bitowe), HP565 (cztery dwurdzeniowe CPU AMD 64-bitowe), IBM e326M (dwa CPU AMD Opteron) i kilka innych. Do określania wydajności używano programu LMBench3, kompilowanego na każdej platformie z ustawieniami domyślnymi, oraz domyślnej konfiguracji instalacyjnej SLES 10, która była identyczna na wszystkich platformach.

Testowano i przeprowadzono audyt konfiguracji systemu przy różnych wyborach instalacyjnych i następnie znane pliki konfiguracyjne użyto jako wskazania do ładowania różnych konfiguracji aplikacji i bezpieczeństwa.

AppArmor próbowano dla kilku standardowych demonów Linux, stwierdzając, że konfigurowanie reguł polityki bardziej niż można by się spodziewać polegało na eksperymentowaniu.

Wydajność Xen testowano na platformach 32- i 64-bitowych, używając SLES 9 i SLES 10 na kilku platformach. Wydajność zmieniała się wraz z platformami w stopniu niewielkim, ale istotnie pomiędzy różnymi wersjami systemu operacyjnego.


TOP 200