Zuweilen ändert sich mit einem Releasewechsel ja kaum mehr als die Versionsnummer. Dem neuen Solaris darf man das nicht nachsagen: Über 600 Neuerungen haben Eingang in die zehnte Auflage gefunden, darunter das innovative DTrace oder das Container-Konzept, das einen Blick über den Linux-Tellerrand lohnt.

Weil Totgesagte bekanntlich länger leben, haben Mainframes entgegen allen Prophezeiungen einen festen und sicheren Platz in den Rechenzentren der Industrie, bei Banken und Versicherungen. Mehr noch: Zunehmend besinnt man sich auch im Server-Lager wieder ihrer Tugenden. Viele Server auf einer Maschine, so die Rechnung, senken die Betriebskosten, verursachen geringeren Aufwand für Hardware, Software und Support, vereinfachen Administration oder Hochverfügbarkeitslösungen und lasten die Ressourcen besser aus.

Wege ins Virtuelle

Alle Serverhersteller versuchen, sich von diesem Kuchen ein Sahnestück zu sichern, und unterstützen die Server-Konsolidierung nach Kräften. Allerdings mit einer etwas anderen Strategie, als sie die Kollegen von der Host-Fraktion verfolgen. Dort nämlich ist Hardware-Partitionierung das Mittel der Wahl: Einzelnen Applikationen werden dabei Teile der physischen Ressourcen (Platten, CPUs, RAM) zugeordnet, die unabhängig voneinander operieren. Weil diese Technik jedoch dem Highend-Segment vorbehalten ist, bedient man sich in den Klassen darunter stattdessen verschiedener Spielarten der Virtualisierung.

Eine Möglichkeit sind virtuelle Maschinen, wie sie etwa das kommerzielle VMware oder das freie Xen unter Linux bereitstellen (siehe Artikel in diesem Heft). Sie können – so wie einzelne Hardware-Partitionen – auf Wunsch unter verschiedenen Betriebssystemen laufen und bieten dabei vergleichsweise mehr Freiheiten bei der Ressourcenverwaltung als die Aufteilung der Hardware.

Doch multipliziert sich der administrative Aufwand mit der Anzahl der Software-Maschinen. Außerdem beeinträchtigt der Overhead, den die Emulation eines kompletten Rechnersystems erzeugt, die Performance merklich. Deshalb verfolgt ein zweiter Ansatz das Ziel, statt eines kompletten Systems nur die Laufzeitumgebung zu virtualisieren. Diesen Weg verfolgen etwa das VServer-Projekt unter Linux [1] oder die aus FreeBSD bekannten Jails.

Anders als bei virtuellen Maschinen gibt es hier nur einen Betriebssystemkern, der aber völlig voneinander isolierte Applikationen bedienen kann. Das senkt den Administrationsaufwand und verursacht nur sehr geringe Performanceverluste. Jedoch sind alle virtuellen Instanzen auf eine Version und einen Patch-Stand eines Betriebssystems festgelegt.

Gefangen in der Zone

Auch Sun hat sich mit dem neuen Solaris für den zweiten Weg entschieden und ihn in Gestalt der Zonen (oder auch Solaris Container) implementiert. Jede Zone erscheint nach außen als separates System und ist nach innen vollständig von anderen Zonen isoliert. Obwohl dieselbe Betriebssysteminstanz alle Zonen bedient, ist es für eine Applikation innerhalb einer Zone unmöglich, nebenan laufende Prozesse zu beobachten, geschweige zu beeinflussen.

Abbildung 1: Innerhalb der globalen Zone lassen sich fast beliebig viele lokale Container einrichten, die ihren Inhalt isolieren und nach außen wie separate Rechner erscheinen.

Stattdessen erscheint der so kreierte Applikations-Container den Anwendungen transparent, sodass sie darin ohne Anpassungen installierbar sind und laufen. Die Rechte von Usern (inklusive Root) sind auf ihre Zone und die ihr zugeordneten Ressourcen beschränkt. Manche Aktionen – zum Beispiel die Zugriffe auf »/dev/kmem« – sind aus Sicherheitsgründen generell unmöglich.

Eine besondere Rolle spielt die so genannte globale Zone, die als einzige immer existiert und alle anderen Zonen umhüllt. In ihr allein ist Root noch der omnipotente Herrscher über das System, der alles darf und kann. Von hier aus ist es möglich, alle Prozesse aller Zonen zu beobachten und zu steuern, neue Zonen anzulegen oder zu löschen, die ihnen zur Verfügung stehenden Ressourcen zu managen und bei Bedarf deren Inanspruchnahme zu protokollieren (Abbildung 1). Die Zonen selbst verursachen so gut wie keine Leistungsverluste – Suns eigenen Angaben zufolge liegen die Einbußen im Bereich einiger Zehntelprozent [2].

Vielfache Prozessmütter

Es liegt auf der Hand, dass dieses Konzept zu tiefen Eingriffen in das System zwingt. So kann es jetzt beispielsweise aus der Perspektive der globalen Zone mehrere Prozesse mit derselben User-ID geben, die tatsächlich aber zu verschiedenen Nutzern in verschiedenen Zonen gehören, denn die Benutzerverwaltung regelt jede Zone autonom.

Abbildung 2: Zwei Init-Prozesse wirken auf den ersten Blick verblüffend. Hier stammen sie aus zwei verschiedenen virtuellen Welten, wie sie sich im neuen Solaris mit wenigen Handgriffen erzeugen lassen.

Aus demselben Grund sieht man aus der globalen Zone auch mehrere Init-Prozesse (Abbildung 2). Deshalb mussten das Prozessmodell, die Interprozess-Kommunikation oder der Netzwerkverkehr nach innen auf das Territorium der Zone begrenzt und nach außen durch eine Zonenkennung unterscheidbar gemacht werden. Der direkte Zugriff auf Devices wurde limitiert und auch vom Filesystem sieht eine Zone nur den ihr zugeordneten Sektor (Effekt vergleichbar »chroot«).

Server im Handumdrehen

Die Administration bleibt trotz aller komplizierten Mechanismen im Hintergrund erfreulich einfach. Wenige Befehle genügen, um in einigen Minuten eine neue Zone aufzusetzen und zu booten. Mit zwei Kommandos und einigen Optionen ist alles getan.

01 bash-3.00# zonecfg -z zone1 'create; set zonepath=/export/home/zone1'
02 
03 bash-3.00# zoneadm list -vc
04   ID NAME             STATUS         PATH
05    0 global           running        /
06    - zone1            configured     /export/home/zone1
07 
08 bash-3.00# zoneadm -z zone1 install
09 Preparing to install zone <zone1>.
10 Creating list of files to copy from the global zone.
11 Copying <77572> files to the zone.
12 ...
13 Initializing zone product registry.
14 Determining zone package initialization order.
15 Preparing to initialize <1098> packages on the zone.
16 ...
17 Initialized <1098> packages on zone.
18 Zone <zone1> is initialized.
19 bash-3.00# zoneadm list -vc
20   ID NAME             STATUS         PATH
21    0 global           running        /
22    - zone1            installed      /export/home/zone1
23 
24 
25 bash-3.00# zoneadm -z zone1 boot
26 bash-3.00# zoneadm list -vc
27   ID NAME             STATUS         PATH
28    0 global           running        /
29    1 zone1            running        /export/home/zone1
30 
31 sh-3.00# zlogin zone1
32 [Verbunden mit Zone 'zone1' pts/6]
33 Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
34 # ptree
35 5715  /sbin/init
36 5717  /lib/svc/bin/svc.startd
37 ...

In Listing 1 dokumentiert »zoneadm list« nach jedem Schritt die Zustandsänderungen der neuen Zone. Mit den schon in Solaris 9 vorhandenen und jetzt weiterentwickelten Konzepten für das Ressourcen-Management ist es möglich, Zonen Ressourcen-Pools zuzuordnen, die beschreiben, wie viel Platz oder Rechenzeit sie in Anspruch nehmen dürfen. Dabei sind sowohl Obergrenzen wie Garantiezusagen definierbar.

Das Konzept eignet sich beispielsweise für Provider, die virtuelle Server an Kunden vermieten. Genauso sind aber auch Szenarien möglich, bei denen etwa eine Datenbank, ein Webserver und ein Entwicklungssystem neben weiteren Applikationen in mehreren Zonen auf einem Server koexistieren. Der Datenbank, die zu einer geschäftskritischen Anwendung gehört, kann der Admin entsprechend den vereinbarten Service Level Agreements Ressourcen fest zusagen. Zugleich ist sie in ihrem Container vor Unbefugten sicher.

Vielseitig verwendbar

Gleichzeitig können die Entwickler auf derselben Maschine unabhängig davon ihre Umgebung konfigurieren, dürfen aber nur einen bestimmten Teil der verfügbaren Rechenleistung konsumieren. Dafür arbeiten sie unter demselben Betriebssystem und auf derselben Hardware, für die auch ihr Produkt bestimmt ist. Unterläuft ihnen in einer Zwischenversion ein sicherheitsrelevanter Fehler, könnte ein Angreifer maximal ihre Zone kompromittieren. Gerät ihnen ein Test außer Kontrolle, wirkt sich das auf keine der Anwendungen in einer Nachbarzone aus. Notfalls dürfen sie ihre virtuelle Entwicklungsplattform jederzeit rebooten, ohne dass andere Anwender davon etwas merkten.

Computer-Röntgen

Mit der Entdeckung der Röntgenstrahlung und ihrer ersten Anwendung um die Wende zum 20. Jahrhundert gelangen erstmals ohne Skalpell Einblicke in den lebenden Körper, die sichere und präzise Diagnosen ermöglichten. Einen vergleichbaren Effekt für Solaris-Server verspricht ein völlig neu entwickeltes Tool, für das es kein direktes Vorbild gibt: DTrace [3].

Was den Anstoß zur Entwicklung gab, schildert das Entwicklerteam in einer Anekdote [4]: Sun wollte mit einem seiner großen Server, einer E10k, den Weltrekord in einem bestimmten Benchmark brechen, aber hin und wieder verlangsamte das System aus unerfindlichen Gründen sein Arbeitstempo drastisch. Die Top-Experten der Firma vergruben sich Tage und Nächte in das System und boten all ihre schwarze Magie auf, um die Ursache zu finden.

Unter anderem versuchten sie mit speziell instrumentierten Kernelmodulen dem Fehler auf die Schliche zu kommen. Die erzwangen mehrfache Reboots, von denen jeder allein jedes Mal zwei Stunden kostete. Als letzte Ursache einer Wirkungskette machten sie schließlich einen simplen Konfigurationsfehler aus und gewannen neben dem Rekord die Erkenntnis, dass es an einem effizienten Diagnosewerkzeug für die Tiefen des Betriebssystems fehlte.

Auskunftsfreudig

Nach zwei Jahren Entwicklungszeit bereichert dieses Werkzeug nun das neue Solaris. Es gestattet im laufenden, produktiven Betrieb über mehr als 30000 in der gesamten Systemsoftware installierte Messpunkte eine Vielzahl von Informationen abzufragen und zu Erkenntnissen zu verdichten, die anders kaum zu gewinnen wären. So lassen sich nicht allein Systemaufrufe verfolgen (wie mit »truss« oder »strace« unter Linux), sondern jeder Funktionsaufruf, ja jede einzelne Instruktion, und zwar inklusive ihres Zeitbedarfs, ihrer Häufigkeit oder der Werte bestimmter Argumente.

Untersuchungen, die früher für den Debugger-Einsatz neu kompilierte Applikationen oder gar wie beschrieben speziell präparierte Kernelmodule erforderten, kann der Admin nun mit einem Bruchteil des Aufwands dynamisch betreiben und iterativ verfeinern. Dabei bewegt er sich gefahrlos in der Produktivumgebung, was besonders bei Performanceproblemen ein Vorteil ist.

Mit DTrace kann der Inspekteur nicht nur Applikationen bei der Arbeit beobachten, sondern auch den Kernel. Und zwar ohne intime Kenntnisse der Datenstrukturen des Kerns, denn so genannte Provider bieten relativ einfach zu handhabende Schnittstellen. Im Unterschied zu Monitoring-Tools wie »iostat«, »vmstat« oder auch zum SE Toolkit, die Symptome augenfällig machen, ist es die Hauptaufgabe des neuen Werkzeugs, zur Wurzel vorzudringen.

DTrace ist ein Kommandozeilenwerkzeug, ein GUI gibt es nicht. Es gibt aber Überlegungen, zumindest Visualisierungstools für die gesammelten Daten beizusteuern. Komplexere Dinge sind in einer eigenen Skriptsprache namens D kodierbar, deren Syntax sich stark an C anlehnt, die aber auf Tracing-Skripte zugeschnitten wurde und eine Reihe fortgeschrittener Datentypen bereithält, etwa assoziative Arrays und Aggregate.

Gesundheitsreform

Selbstheilung, für lebende Wesen bei leichten Erkrankungen die Regel, aber auch bei schweren wissenschaftlich dokumentiert, erhebt Solaris mit dem Predictive Selfhealing nun im Reich der Technik für sich zur Regel: Jede Störung im Allgemeinbefinden des Rechners will es selbstständig diagnostizieren und zumindest lindern, wenn nicht kurieren. Dafür implementiert die jüngste Solaris-Version etliche neue Konzepte [5].

Ursachenforschung

So gibt es nun einen Fault Manager, der als erste Anlaufstelle Fehlermeldungen von Systemkomponenten einschließlich des Kernels entgegennimmt. Die schlechten Nachrichten erreichen ihn über einen neuen Kommunikationskanal in Form von Error-Events. Den herkömmlichen Syslog-Mechanismus gibt es parallel dazu weiter, unter anderem weil zahlreiche ältere Softwarekomponenten und Skripte noch darauf aufbauen. Der Fehlermanager leitet die eingehenden Berichte asynchron an eine Diagnoseeinheit (Diagnosis Engine) weiter, die dann versucht von den Symptomen auf die Ursachen zu schließen und eine sinnvolle automatische Gefahrenabwehr einzuleiten.

Abbildung 3: Die installierten Gesundheitshelfer, die nach Erhalt der Diagnose die Selbstheilung bewerkstelligen sollen, listet ein neues Kommandozeilen-Tool.

Die Diagnoseeinheit generiert dafür aus dem Error-Event einen Fault-Event und sendet diesen per Broadcast an eine Gruppe von Reconfiguration Agents, die jeweils für bestimmte Systemkomponenten zuständig sind. Zurzeit existieren Agents für CPU, Memory und für I/O-Devices (Abbildung 3). So könnte beispielsweise der zuständige Agent vorausschauend den Kernel darum bitten, eine bestimmte Speicherseite auszumappen, nachdem der zugehörige physische RAM mehrmals Fehler verursachte.

Leserliche Logs

Außerdem protokolliert die Diagnosemaschine ihre Untersuchungsergebnisse in den Logs, die dadurch deutlich aussagekräftiger und lesbarer ausfallen. Dazu trägt auch bei, dass jede Diagnose zu einem vereinheitlichten Log-Eintrag verarbeitet wird, der zusätzlich auf einen weiterführenden Knowledge Article verweisen kann. Kryptische Meldungen mit irrelevanten oder unverständlichen Informationen oder Meldungen, die nur auf dem Terminal, aber nicht in den Logs landen, müssten damit der Vergangenheit angehören.

Keine Panik

Kippen mehrere Speicherbits, ist es wohl zu spät, um vorzubauen. Aber auch dann beweist der integrierte Troubleshooter Intelligenz. Statt den betroffenen Prozess blindlings abzuschießen oder gar den ganzen Rechner per Kernelpanic außer Gefecht zu setzen, erkundigt er sich zuvor bei einer weiteren Instanz nach den Zusammenhängen.

Die Service Management Facility (SMF) weiß, welche Prozesse zu welchen Services gehören und welcher Dienst unter Umständen von welchem anderen abhängt. Diese Verknüpfungen merkt sich die Management Facility in einem speziellen XML-File. So kann jeder Service geordnet beendet und danach gegebenenfalls in richtiger Reihenfolge neu gestartet werden.

Vertraglich geregelt

Für den Wiederanlauf nach einem Hard- oder Softwarefehler ist ein eigener Restarter-Prozess pro Service zuständig, der in einer speziellen Kernelressource, einem so genannten Contract, konfiguriert wird. Alle Ressourcen dieses Typs verwaltet der Kernel in dem Pseudo-Filesystem »/system/contract«.

Jeder der dort hinterlegten Verträge legt fest, wie der Restarter auf bestimmte Ereignisse wie Soft- oder Hardwarefehler oder die normale Beendigung des Prozesses reagieren soll. Für den Admin wird es damit gewissermaßen zur Pflicht, die SMF-Komandozeilen-Tools zu benutzen: In den aus Kompatibilitätsgründen nach wie vor bestehenden »rc«-Verzeichnissen findet er womöglich kein passendes Startskript für seinen Service mehr und ein schlichtes »kill Prozess-ID« würde nichts als einen Neustart des Service binnen weniger Sekunden bewirken.

Neues allerorten

Das Wissen um die Abhängigkeiten der Services voneinander ist noch in einer weiteren Hinsicht relevant. Beim Booten starten nun dank dieser Informationen voneinander unabhängige Prozesse parallel, was den Vorgang speziell auf großen Maschinen merklich beschleunigt. Ebenfalls mit deutlich mehr Tempo arbeitet auch der in die Jahre gekommenen IP-Stack, dem die Solaris-Entwickler eine Frischzellenkur verordneten.

Mit »smpatch« gibt es ein neues Tool, das nach dem Vorbild mancher Linux-Verwandten sehr bequem Solaris-Patches über das Internet besorgt, mit dem System abgleicht und auf Wunsch installiert. Die Rechteverwaltung wurde weiter verfeinert, alle Binaries sind zum Schutz gegen Verfälschung digital signiert, NFS gibt\’s jetzt in Version 4 – die Aufzählung ließe sich noch eine Weile fortsetzen.

Ausblick

Weitere wichtige Neuerung sind noch für dieses Jahr zu erwarten, darunter ZFS, das neue 128-Bit-Filesystem samt eingebautem Volume Manager, das die schier unvorstellbare Kapazität von 256 Quadrillionen Zettabyte bewältigen soll (1 Zettabyte = 1 Milliarde Terabyte) und Janus, die Systemkomponente, die nativ Linux-Applikationen unter Solaris ausführen wird.