Container (Solaris)

Solaris-Container oder Solaris-Zonen sind die Realisation der Betriebssystem-Virtualisierung für x86- und SPARC-Systeme, die 2005 von Sun Microsystems als Teil von Solaris 10 eingeführt wurde. Die Bezeichnungen Container und Zone werden normalerweise austauschbar verwendet; streng genommen heißt nur eine Zone mit Ressourcenverwaltung (also Begrenzung und verteilte Zuweisung von CPU, Arbeitsspeicher und Netzwerk) Container.

Zonen wirken als völlig isolierte virtuelle Server innerhalb einer Betriebssysteminstanz. Indem Gruppen von Anwendungsdiensten auf einem System konsolidiert und einzeln in isolierte Container platziert werden, können Systemadministratoren die Gesamtkosten eines Systems verringern und gleichzeitig die Schutzmechanismen zur Verfügung stellen, für die sonst separate Maschinen erforderlich wären.

Terminologie

Es gibt immer wenigstens eine Zone, die sogenannte globale Zone. Die weiteren Zonen werden von dieser verwaltet und heißen nichtglobale Zonen. Die Bezeichnung lokale Zone hat sich zwar eingebürgert, der Hersteller rät aber von ihrer Verwendung ab.

Die Globale Zone enthält alle Prozesse des Systems, auch diejenigen, die in einer nichtglobalen Zone laufen. Das Wort Zone steht (zum Beispiel auch in diesem Artikel) oft für nichtglobale Zone.

Beschreibung

Jeder Zone wird ein eigener Hostname, virtuelle Netzwerkkarten, und Speicher zugeordnet. Es gibt keine Anforderung, welche Hardware der Zone zugeordnet wird, außer dem für die Speicherung der Zonenkonfiguration erforderlichen Plattenplatz. Insbesondere müssen einer Zone keine dedizierte CPUs, Speicherbereiche, physische Netzwerkkarten oder Host-Bus-Adapter zugeordnet werden, obwohl das durchaus möglich ist.

Jede Zone ist von einer Sicherheitsbegrenzung umgeben, die verhindert, dass ein Prozess einer Zone mit denen anderer interagiert oder sie beobachtet. Jede Zone kann mit einer eigenen Liste von Benutzerkonten konfiguriert werden. Konflikte der numerischen Benutzerkennungen werden vom System automatisch aufgelöst; zum Beispiel können zwei Zonen eines Systems jeweils einen Benutzer mit der Kennung 10000 definiert haben; beide würden im Gesamtsystem eine eigene globale Kennung erhalten.

Eine Zone kann einem Ressourcen-Pool zugeordnet werden (einer Anzahl von Prozessoren und einer Prioritätsklasse), oder ihre Ressourcenanteile über das Fair-Share-Scheduling erhalten. Eine Zone kann sich in jeweils einem der folgenden Zustände befinden:

• Configured (konfiguriert): Die Konfiguration ist abgeschlossen und gespeichert
• Incomplete (unvollständig): Zwischenzustand während der Installation oder Deinstallation
• Installed (installiert): Die Pakete sind vollständig installiert
• Ready (fertig): Die virtuelle Plattform ist angelegt
• Running (aktiv): Die Zone wurde erfolgreich hochgefahren und läuft jetzt
• Shutting down (beim Runterfahren): Zwischenzustand: Die Zone wird runtergefahren; der Zustand endet im Down-Zustand.
• Down (Ausgeschaltet): Zwischenzustand: Die Zone wurde vollständig runtergefahren; der Zustand geht schließlich in Installed über.

Manche Programme können nicht von nichtglobalen Zonen aus ausgeführt werden. Da eine Zone keinen eigenen Kernel besitzt (Im Unterschied zu einer virtuellen Maschine) können Anwendungen, die den Systemkernel manipulieren oder auf den Speicherbereich des Systemkernels direkt zugreifen müssen, nicht innerhalb eines Containers laufen.

Ressourcenbedarf

Die zusätzliche Belastung für CPU und Speicher, die von den Zonen ausgeht, ist sehr niedrig. Es können 8191 nichtglobale Zonen innerhalb einer einzigen Betriebssysteminstanz angelegt werden. Sparse Zones, bei denen der größte Teil des Filesystem-Inhalts mit der globalen Zone gemeinsam genutzt wird, können mit lediglich 50 Megabyte Plattenplatz auskommen. Whole Root Zones, bei denen jede Zone ihren eigenen Satz von Betriebssystemfiles enthält, können zwischen ein paar hundert Megabytes bis hin zu mehreren Gigabytes beanspruchen, abhängig von der installierten Software.

Auch mit Whole-Root-Zonen kann der Plattenplatzbedarf vernachlässigbar sein, wenn das Filesystem der Zone ein ZFS-Klon des Speicherabbildes der globalen Zone ist, da nur die Blöcke, die sich vom Snapshot-Image unterscheiden, auf der Platte abgespeichert werden müssen. Dieses Verfahren ermöglicht auch die Neuanlage von Zonen in wenigen Sekunden.

Branded Zones

Obwohl alle Zonen den Kernel gemeinsam verwenden, erlauben die Branded Zones (oder BrandZ) die Anlage von Zonen, die ein von der globalen Zone abweichendes Betriebssystem haben. Die unterstützten Typen (Brands) fallen in zwei Kategorien (Stand Oktober 2009):

• Brands, die keine Übersetzung von Betriebssystemaufrufen erfordern:
  • native, die Voreinstellung für Solaris 10
  • ipkg, die Voreinstellung für OpenSolaris
  • cluster, das für Solaris-Cluster benutzt wird
  • labeled für Zonen in einer Solaris-Trusted-Extensions-Umgebung
• Brands mit Übersetzung von Betriebssystemaufrufen:
  • solaris8 stellt eine Solaris-8-Umgebung auf einem Solaris-10-System zur Verfügung (Nur für SPARC-Systeme)
  • solaris9 stellt eine Solaris-9-Umgebung auf einem Solaris-10-System zur Verfügung (Nur für SPARC-Systeme)
  • lx stellt eine Umgebung mit Red Hat Enterprise Linux 3 auf einem Solaris-10-System zur Verfügung (Nur für x86-Systeme)
  • s10brand stellt eine Solaris-10-Umgebung auf OpenSolaris oder auch Oracle Solaris 11 zur Verfügung.

Das Brand einer Zone wird zum Zeitpunkt ihrer Anlage festgelegt.

Einschränkung für NFS

Der Standard NFS-Server von Solaris ist im Kernel implementiert und kann daher nicht für Exporte in nichtglobalen Zonen benutzt werden. NFS-Server von Drittanbietern, die nicht im Solaris-Kernel implementiert sind, können aber möglicherweise funktionieren.

Weblinks

• Moving Solaris 10 Zones