Anhang A Java ES- und Solaris 10-Zonen

Dieser Anhang beschreibt mögliche Probleme bei der Installation und Konfiguration von Java ES-Komponenten in Solaris 10-Zonen und stellt verschiedene Methoden vor, mit denen Sie diesen Problemen begegnen können. Dieser Anhang enthält die folgenden Abschnitte:

• Was sind Zonen?

• Gründe für die Verwendung von Zonen für Java ES

• Zonenbeschränkungen für Java ES-Komponenten

• Zonenunterstützung im Java ES-Installationsprogramm

• Empfohlene Verwendung von Zonen mit Java ES

• Sonderfälle und Ausnahmen

• Beispiel zur Veranschaulichung: Installation von Application Server in einer Sparse-Root-Zone

Was sind Zonen?

Zonen sind eine Anwendungs- und Ressourcenverwaltungsfunktion des Betriebssystems Solaris 10. Über diese Funktion kann das Betriebssystem gegenüber Anwendungen als eine oder mehrere virtuelle Betriebssystemumgebungen (Zonen) dargestellt werden, die isoliert und sicher sind. Diese Zonen bieten den Vorteil der Betriebssystemunabhängigkeit mit einem bestimmten Grad an zentralisierter Ressourcenverwaltung. Anwendungen können so voneinander isoliert werden, indem Sie in verschiedenen Zonen installiert und ausgeführt werden, während gleichzeitig bestimmte Betriebssystemressourcen zentral zugewiesen und verwaltet werden können.

Aus Sicht eines Betriebssystems mit Unterstützung für mehrere Zonen umfassen die Betriebssystemressourcen beispielsweise Prozessverwaltung, Arbeitsspeicher, Netzwerkkonfiguration, Dateisysteme, Paketregistrierung, Benutzerkonten, gemeinsam genutzte Bibliotheken und in einigen Fällen installierte Anwendungen.

Struktur einer Multi-Zonen-Umgebung

Eine Multi-Zonen-Umgebung besteht aus einer globalen Zone (dem Standardbetriebssystem) und mindestens einer nicht globalen Zone. Die globale Zone enthält Ressourcen, die den nicht globalen Zonen von einem globalen (Zonen-) Administrator zugewiesen werden können. Nicht globale Zonen weisen die folgenden Eigenschaften auf:

• Sicherheit. Durch die Ausführung verteilter Dienste in nicht globalen Zonen wird der mögliche Schaden im Fall einer Sicherheitsverletzung begrenzt. Ein Eindringling, der sich eine Sicherheitslücke in einer Softwareanwendung innerhalb der Zone erfolgreich zunutze macht, bleibt auf diese Zone beschränkt. Die für eine nicht globale Zone geltenden Berechtigungen stellen eine Untermenge der Berechtigungen in der globalen Zone dar.

• Laufzeitisolierung. Nicht globale Zonen ermöglichen die Bereitstellung verschiedener Anwendungen auf demselben Computer, selbst wenn für diese Anwendungen unterschiedliche Sicherheitsstufen gelten oder exklusiver Zugriff auf globale Ressourcen oder eine individuelle Konfiguration erforderlich ist. Beispielsweise können mehrere Anwendungen, die in unterschiedlichen Zonen ausgeführt werden, an denselben Netzwerkport gebunden sein, indem sie die eindeutige IP-Adresse der jeweiligen nicht globalen Zone verwenden. Die Anwendungen werden daran gehindert, den Netzwerkdatenverkehr, Dateisystemdaten oder Prozessaktivitäten für die anderen Zonen zu überwachen oder zu unterbrechen.

• Administrative Isolierung. Die virtuelle Betriebssystemumgebung ermöglicht eine separate Verwaltung jeder nicht globalen Zone. Die von einem Zonenadministrator (im Gegensatz zum Administrator der globalen Zone) durchgeführte Operationen – z. B. das Erstellen von Benutzerkonten, das Installieren und Konfigurieren von Software sowie die Verwaltung von Prozessen – haben keinerlei Auswirkung auf andere Zonen.

Es gibt zwei Arten von nicht globalen Zonen: Whole-Root-Zonen und Sparse-Root-Zonen.

• Whole-Root-Zonen. Enthält eine Kopie des Dateisystems der globalen Zone, in der Lese- und Schreibvorgänge ausgeführt werden können. Bei der Erstellung einer Whole-Root-Zone werden alle in der globalen Zone installierten Pakete für die Whole-Root-Zone verfügbar gemacht: Es wird eine Paketdatenbank erstellt, und alle Dateien werden zur dedizierten und unabhängigen Nutzung der Zone in die Whole-Root-Zone kopiert.

• Sparse-Root-Zonen. Enthält eine Kopie für einen Teil des Dateisystems der globalen Zone (daher der Name Sparse-Root). Weitere Dateisysteme werden als schreibgeschützte, virtuelle Loopback-Dateisysteme geladen. Bei der Erstellung einer Sparse-Root-Zone legt der globale Administrator fest, welche Dateisysteme mit der Sparse-Root-Zone gemeinsam genutzt werden (per Voreinstellung werden die Verzeichnisse /usr, /lib, /sbin und /platform als schreibgeschützte Dateisysteme freigegeben). Alle Pakete, die in der globalen Zone installiert werden, werden in der Sparse-Root-Zone zur Verfügung gestellt: Es wird eine Paketdatenbank erstellt, und alle Dateien im geladenen Dateisystem werden gemeinsam mit der Zone genutzt.

Whole-Root-Zonen und Sparse-Root-Zonen im Vergleich

Ob Sie sich für eine nicht globale Whole-Root-Zone oder eine nicht globale Sparse-Root-Zone entscheiden, richtet sich danach, welche Schwerpunkte Sie in Bezug auf Ressourcenoptimierung und administrative Steuerung setzen möchten. Whole-Root-Zonen ermöglichen eine Maximierung der administrativen Steuerung (Unabhängigkeit und Isolierung), jedoch auf Kosten der Nutzung von Speicher und anderen Ressourcen. Sparse-Root-Zonen hingegen optimieren die gemeinsame Nutzung von ausführbaren Dateien und Bibliotheken (wodurch weniger Speicherplatz beansprucht wird), dies jedoch auf Kosten der administrativen Unabhängigkeit. Es gibt derzeit keine Möglichkeit, den Leistungsvorteil von Sparse-Root-Zonen gegenüber Whole-Root-Zonen zu messen; dieser ist sehr wahrscheinlich softwareabhängig.

Paketverbreitung

Die in einer globalen Zone installierten Pakete werden (standardmäßig) in allen nicht globalen Zonen zur Verfügung gestellt. Dieser Vorgang wird als Paketverbreitung bezeichnet. (Damit eine Paketverbreitung durchgeführt wird, muss eine neu erstellte nicht globale Zone vollständig geladen sein, d. h. ausgeführt werden.) Durch die Verbreitung werden in der globalen Zone installierte Pakete lokal sichtbar und verfügbar. Die Verbreitung ermöglicht eine zentrale Lebenszyklusverwaltung für Anwendungspakete (Installation, Upgrade, Deinstallation) durch einen globalen Administrator, während die Anwendungskonfiguration und Laufzeitverwaltung durch (nicht globale) Zonenadministratoren erfolgt.

Bei Whole-Root-Zonen wird die Verbreitung durch automatisches Kopieren der installierten Dateien von der globalen Zone in die Whole-Root-Zonen sowie durch automatische Synchronisierung der Registrierungsinformationen erreicht. Bei Sparse-Root-Zonen wird die Verbreitung über schreibgeschützte Dateisysteme erreicht, die von der globalen Zone und den Sparse-Root-Zonen gemeinsam genutzt werden, sowie durch die automatische Synchronisierung von Registrierungsinformationen.

Die Verbreitung von Paketen auf nicht globale Zonen wird auf Paketebene gesteuert und erfolgt unter Verwendung interner Paketattribute. Für einige Attributwerte (zumindest für die Standardwerte) kann die Verbreitung bei Installation deaktiviert werden, indem die Option pkgadd —G gesetzt wird, welche die Attributwerte überschreibt. Nach Abschluss der Installation kann das Verhalten für die Paketverbreitung nicht mehr geändert werden, ausgenommen Sie deinstallieren das Paket und installieren es anschließend neu. Patches können das Verbreitungsverhalten eines Pakets nicht ändern. Tatsächlich müssen Patches gemäß des Verbreitungsverhaltens für das Paket angewendet werden, das aktualisiert wird.

Gründe für die Verwendung von Zonen für Java ES

Die Isolierung, die durch die Anwendungsausführung in unterschiedlichen Zonen erreicht wird, ähnelt der Isolierung, die bei der Ausführung von Anwendungen unter den Betriebssystemen unterschiedlicher Computer erzielt wird. Anstatt also Java ES-Komponenten auf unterschiedlichen Computern zu installieren, zu konfigurieren und auszuführen, um die gewünschte Isolierung und Sicherheit zu gewährleisten, können die Komponenten in unterschiedlichen Zonen auf einem einzigen Computer installiert, konfiguriert und ausgeführt werden.

Diese Zusammenführung der Java ES-Komponenten ermöglicht darüber hinaus eine effizientere Ressourcennutzung. Java ES-Komponenten, die derzeit auf dedizierten Computern mit niedriger Auslastung ausgeführt werden, können stattdessen in nicht globalen Zonen auf einem einzigen Computer installiert werden. Globale Administratoren können in Abhängigkeit von den Ressourcenanforderungen für die in den jeweiligen Zonen ausgeführten Komponenten eine dynamische Ressourcenzuweisung für die unterschiedlichen Zonen vornehmen. (Beachten Sie, dass für die Ressourcenzuweisung weitergehende Kenntnisse der Ressourcenanforderungen für die unterschiedlichen Komponenten erforderlich sind, die zurzeit möglicherweise noch nicht allgemein verfügbar sind.)

Mit einer Multi-Zonen-Umgebung können Sie darüber hinaus Folgendes erreichen:

• Versionstrennung. Unterschiedliche Versionen von Java ES-Komponenten können in unterschiedlichen Zonen installiert und somit parallel ausgeführt werden. Auf diese Weise muss eine Migration von einer Java ES-Version auf eine andere nicht zu einem bestimmten Zeitpunkt erfolgen. Beispielsweise können Java ES-Komponenten der Version 4 in einer nicht globalen Zone ausgeführt werden, parallel zu Java ES-Komponenten der Version 5 in einer anderen nicht globalen Zone. Zum Erreichen dieser Art von Versionstrennung wird die Lebenszyklusverwaltung (sowie die Konfigurations- und Laufzeitverwaltung) an Zonenadministratoren delegiert.

• Zentrale Lebenszyklusverwaltung. Wenngleich aufgrund von Java ES-Beschränkungen derzeit keine vollständige Unterstützung gegeben ist, kann mithilfe von Zonen die Lebenszyklusverwaltung von Java ES-Komponenten zentralisiert werden: Komponenten können in der globalen Zone installiert, aktualisiert und deinstalliert werden, die Konfiguration und Ausführung erfolgt jedoch in den verschiedenen nicht globalen Zonen. Auf diese Weise wird den Ansprüchen in Bezug auf Laufzeitisolierung, Sicherheit, Skalierbarkeit und anderen Anforderungen Rechnung getragen. Die zentrale Lebenszyklusverwaltung hat Vorteile, wenn verschiedene Instanzen einer Komponente in unterschiedlichen Zonen ausgeführt werden, oder wenn Sie sicherstellen möchten, dass diese Instanzen zur Verwendung derselben Version synchronisiert werden.

  Sie können beispielsweise Application Server in der globalen Zone installieren und mehrere Instanzen in unterschiedlichen nicht globalen Zonen ausführen. Die verschiedenen Application Server-Instanzen können Access Manager, Portal Server oder weitere Java ES-Komponenten unterstützen (es kann sich um dieselben oder unterschiedliche Komponenten in verschiedenen nicht globalen Zonen handeln). Alternativ können unterschiedliche Application Server-Instanzen von verschiedenen Entwicklungsteams in unterschiedlichen Zonen verwendet werden.

  Zum Erreichen dieses Ziels wird die Lebenszyklusverwaltung durch einen globalen Administrator durchgeführt, während die Konfigurations- und Laufzeitverwaltung an die jeweiligen Zonenadministratoren delegiert wird. Dieser Ansatz erfordert einigen Koordinationsaufwand, wenn Lebenszyklusverwaltungsaufgaben (z. B. ein Upgrade) durchgeführt werden.

• Organisationsunabhängigkeit. Unterschiedliche Organisationen können verschiedene Bereitstellungen oder separate Laufzeitinstanzen von Java ES-Komponenten verwalten, die alle auf demselben Computer vorliegen und ausgeführt werden. Beispielsweise können unterschiedliche Entwicklerteams eigene Instanzen von Java ES-Komponenten verwenden, oder unterschiedliche Organisationen können für das Testing, Vorproduktion oder Produktion verschiedene Bereitstellungen von Java ES einsetzen. Eine Unabhängigkeit der verschiedenen Organisationen untereinander kann auf verschiedene Arten erreicht werden. Dies hängt von den jeweiligen Zielen ab: entweder erfolgt die Lebenszyklusverwaltung für Java ES-Komponenten zentral, d. h. die Konfigurations- und Laufzeitverwaltung wird an die Zonenadministratoren delegiert, oder sämtliche Verwaltungsaufgaben (Lebenszyklus, Konfiguration und Laufzeit) werden an die Zonenadministratoren delegiert.

Die verschiedenen Ziele, die mit Java ES in einer Multi-Zonen-Umgebung erreicht werden können, sowie die zugehörigen Verwendungsszenarien erfordern andere Strategien für die Bereitstellung und Administration von Java ES-Komponenten. Sie können sich entweder die Isolierung der verschiedenen Zonen zunutze machen, um verschiedene Java ES-Komponenten und die zugehörigen Laufzeitinstanzen unabhängig voneinander zu verwalten, oder Sie nutzen die Verbreitungsfunktionen der globalen Zone, um die Lebenszyklusverwaltung von Java ES-Komponenten zu vereinfachen.

Im nächsten Abschnitt werden einige der Einschränkungen besprochen, die in der Multi-Zonen-Umgebung für die Java ES-Software gelten. Im Anschluss werden Strategien für die Installation und Administration für den Einsatz von Java ES in einer Multi-Zonen-Umgebung vorgestellt.

Zonenbeschränkungen für Java ES-Komponenten

Java ES-Komponenten sind in unterschiedliche Kategorien gruppiert, wie in Sun Java Enterprise System 5 – Technische Übersicht beschrieben. Gemäß der in diesem Dokument bereitgestellten Informationen stellen Systemdienstkomponenten die Hauptdienste der Java ES-Infrastruktur bereit, während Dienstqualitätkomponenten diese Systemdienste erweitern. Diese zwei Arten von Java ES-Komponenten werden hier zusammenfassend als Produktkomponenten bezeichnet, also die Komponenten, die im Java ES-Installationsprogramm auswählbar sind.

Jede Produktkomponente hängt von einer oder mehreren lokal freigegebenen Bibliotheken ab, die als gemeinsam genutzte Java ES-Komponenten bezeichnet werden. Gemeinsam genutzte Komponenten werden, in Abhängigkeit von der installierten Produktkomponente, während der Installation einer Produktkomponente vom Java ES-Installationsprogramm automatisch installiert. Sie werden bei der Bereitstellung von Java ES-Produktkomponenten weder einzeln ausgewählt, installiert noch konfiguriert.

Gemeinsam genutzte Java ES-Komponenten und Zonen

Die Erläuterung im Abschnitt Gründe für die Verwendung von Zonen für Java ES konzentriert sich auf die Verwendung von Zonen durch Java ES-Produktkomponenten: diese können im Java ES-Installationsprogramm explizit ausgewählt und in verschiedenen Zonen installiert und konfiguriert werden, um die gewünsche Bereitstellungsarchitektur und Funktionalität zu erzielen. Die gemeinsam genutzten Komponenten jedoch, von denen die Produktkomponenten abhängen, führen zu verschiedenen Beschränkungen in Bezug auf die Java ES-Bereitstellung in einer Multi-Zonen-Umgebung. Für gemeinsam genutzte Java ES-Komponenten und Zonen gelten insbesondere die folgenden zwei Einschränkungen:

Synchronisierung gemeinsam genutzter Komponenten

Die Schwierigkeit, sämtliche der (etwa 30) komplexen Interaktionen zwischen den gemeinsam genutzten Java ES-Komponenten und Java ES-Produktkomponenten zu testen und zu unterstützen, macht es erforderlich, dass alle gemeinsam genutzten Komponenten innerhalb einer Betriebssysteminstanz für dieselbe Java ES-Version synchronisiert werden müssen. Anders ausgedrückt: Alle in einer Nicht-Zonen-Umgebung oder in einer einzelnen Zone mit einer Solaris 10-Umgebung installierten gemeinsam genutzten Java ES-Komponenten müssen dieselbe Version aufweisen. Diese Anforderung führt zu gewissen Einschränkungen in Bezug auf die Verwendung von Java ES in einer Multi-Zonen-Umgebung.

Diese Synchronisierungsanforderung hat folgende Auswirkungen:

• Unterschiedliche Versionen von gemeinsam genutzten Java ES-Komponenten können nur in unterschiedlichen Zonen vorliegen. Sie können beispielsweise die gemeinsam genutzten Komponenten von Java ES Version 4 in einer Zone und gemeinsam genutzte Komponenten von Java ES Version 5 in einer anderen Zone installieren, eine Kombination in derselben Zone ist jedoch nicht möglich.

• Wenn eine gemeinsam genutzte Komponente in einer Zone aktualisiert oder eine neue gemeinsam genutzte Komponente einer höheren Version eingeführt wird, dann müssen alle gemeinsam genutzten Komponenten in dieser Zone ebenfalls aktualisiert werden. (Gemeinsam genutzte Komponenten bieten Abwärtskompatibilität, daher stellt es kein Problem dar, Produktkomponenten der Version 4 mit gemeinsam genutzten Komponenten der Version 5 auszuführen.) Angenommen, eine Produktkomponente der Version 5 wird in einer Zone installiert, in der mindestens eine Produktkomponente der Version 4 installiert ist. Da die Version 5-Produktkomponente einige der gemeinsam genutzten Komponenten für Version 5 benötigt, muss während der Installation der Version 5-Produktkomponente eine Synchronisierung aller gemeinsam genutzten Komponenten für Version 4 in dieser Zone auf Version 5 erfolgen. Dies ist auch dann der Fall, wenn die zu installierende Version 5-Produktkomponente gemeinsam genutzte Komponenten erfordert, die von den bereits in der Zone installierten gemeinsam genutzten Komponenten abweichen.

• Wenn gemeinsam genutzte Komponenten in der globalen Zone installiert und von dort verbreitet werden (siehe Java ES-Verbreitungsrichtlinien), dann muss besonders auf die Synchronisierung der gemeinsam genutzten Komponenten in allen Zonen geachtet werden. Anderenfalls wäre es möglich, dass gemeinsam genutzte Komponenten einer früheren Version in einer nicht globalen Zone mit den gemeinsam genutzten Komponenten für Version 5 gemischt werden, die über die globale Zone verbreitet wurden. (Als Vorsichtsmaßnahme wird die Lebenszyklusverwaltung für gemeinsam genutzte Komponenten normalerweise ausschließlich in der globalen Zone durchgeführt: Weitere Informationen finden Sie in Tabelle A–2 sowie unter Sonderfälle bei gemeinsam genutzten Komponenten.)

Die Synchronisierungsanforderung für gemeinsam genutzte Komponenten führt zu Beschränkungen für das Java ES-Installationsprogramm in einer Multi-Zonen-Umgebung (siehe Zonenunterstützung im Java ES-Installationsprogramm) und hat darüber hinaus Auswirkung auf die Verfahren zur Installation und Aktualisierung von Java ES-Produktkomponenten in einer Multi-Zonen-Umgebung.

Gemeinsam genutzte Komponenten und Sparse-Root-Zonen

Ein weiterer Aspekt bei der Verwendung von Java ES in einer Multi-Zonen-Umgebung ist der, dass zahlreiche gemeinsam genutzte Komponenten in Sparse-Root-Zonen nicht installiert werden können, da in Sparse-Root-Zonen mit schreibgeschützten Dateisystemen gearbeitet wird. Aus diesem Grund müssen gemeinsam genutzte Komponenten mit dem Basisverzeichnis /usr (ein Verzeichnis, das per Voreinstellung in der globalen Zone freigegeben ist) in der globalen Zone installiert werden, damit sie in einer Sparse-Root-Zone zur Verfügung stehen.

Die Unfähigkeit, verschiedene der gemeinsam genutzten Java ES-Komponenten in Sparse-Root-Zonen zu installieren, macht es erforderlich, dass zur erfolgreichen Installation von Produktkomponenten, die von diesen gemeinsam genutzten Komponenten abhängen, die Produktkomponenten zunächst in der globalen Zone installiert und anschließend auf die nicht globalen Zonen verbreitet werden müssen.

Java ES-Produktkomponenten und Zonen

Einige der im Abschnitt Gründe für die Verwendung von Zonen für Java ES besprochenen Ziele in Bezug auf die Verwendung von Java ES in einer Multi-Zonen-Umgebung sowie die damit verbundenen Verwendungsszenarien setzen die Verbreitungsfunktionalität der globalen Zone ein, um die Lebenszyklusverwaltung der Java ES-Produktkomponenten zu vereinfachen. In diesen Szenarien erfolgt die Lebenszyklusverwaltung der Java ES-Produktkomponenten in der globalen Zone durch den globalen Administrator, während die Konfigurations- und Laufzeitverwaltung dieser Komponenten in den nicht globalen Zonen durch Zonenadministratoren durchgeführt wird.

Anders gesagt: Produktkomponenten werden in der globalen Zone installiert und aktualisiert, die Instanzen jedoch werden in nicht globalen Zonen konfiguriert und ausgeführt. Dieses Verwendungsszenario kombiniert die Vorteile der zentralen Lebenszyklusverwaltung mit der Isolierung und Sicherheit nicht globaler Zonen.

Dieses Szenario hängt jedoch von der Fähigkeit jeder Produktkomponente ab, in der globalen Zone installiert und in einer nicht globalen Zone konfiguriert und ausgeführt werden zu können. Diese Trennung richtet sich danach, wie eine Produktkomponente konfiguriert wird, wo Konfigurations- und dynamische Anwendungsdaten gespeichert werden, wie Konfigurationsdaten durch Ausführung von Binärdateien ermittelt und wie Upgrades durchgeführt werden. Die Trennung kann beispielsweise davon abhängen, was bei der Ausführung von vor- oder nachbereitenden Installations- oder Upgrade-Skripts geschieht: Start oder Stopp von Komponenteninstanzen, Einrichtung von Links zu Konfigurationsdaten oder Durchführung von anderen Aufgaben, welche die Grenze zwischen Lebenszyklus- und Konfigurationsverwaltung verwischen.

Diese Trennung kann auch davon abhängen, ob die Konfiguration in einer Whole-Root- oder Sparse-Root-Zone erfolgt. Wenn beispielsweise ein Konfigurationsskript für eine Produktkomponente versucht, einen Schreibvorgang in einem schreibgeschützten Dateisystem in einer Sparse-Root-Zone durchzuführen (z. B. /usr), oder wenn ein nicht standardmäßiges Dateisystem (z. B./opt) gemeinsam mit einer Sparse-Root-Zone verwendet wird, kann die Konfiguration einer Komponente fehlschlagen.

---

Hinweis –

Nahezu alle Java ES-Komponenten werden im Verzeichnis /opt installiert, das per Voreinstellung in Sparse-Root-Zonen beschreibbar ist. Weitere Informationen finden Sie in Sun Java Enterprise System 5 Installationsreferenz für UNIX.

---

Zurzeit wird für die etwa 20 Java ES-Produktkomponenten die Trennung von Lebenszyklusverwaltung und Konfigurations-/Laufzeitverwaltung zwischen globalen und nicht globalen Zonen noch nicht unterstützt. Die verschiedenen Produktkomponenten verwenden verschiedene Ansätze für Konfiguration und Upgrade. Aufgrund dieser Situation kann sich die Verbreitung der meisten Java ES-Produktkomponenten (ausgenommen Message Queue) schwierig gestalten. Weitere Informationen finden Sie in den Java ES-Verbreitungsrichtlinien.

Zonenunterstützung im Java ES-Installationsprogramm

Basierend auf den in Gründe für die Verwendung von Zonen für Java ES genannten Verwendungsszenarien sowie den in Zonenbeschränkungen für Java ES-Komponenten beschriebenen Anforderungen und Beschränkungen für Java ES-Komponenten bietet das Java ES-Installationsprogramm qualifizierte Zonenunterstützung für Installation (und Upgrade) von Java ES-Produktkomponenten und die Synchronisierung von gemeinsam genutzten Komponenten. Es wurden Richtlinien im Installationsprogramm implementiert, mit deren Hilfe problematische Installations- und Upgrade-Szenarien vermieden werden.

Java ES-Verbreitungsrichtlinien

Basierend auf den in Abschnitt 3 beschriebenen Einschränkungen implementiert das Java ES-Installationsprogramm zwei Java ES-Verbreitungsrichtlinien:

• Wenn Produktkomponenten in der globalen Zone installiert werden, wird die Verbreitung auf nicht globale Zonen standardmäßig deaktiviert (Message Queue stellt eine Ausnahme dar). Dies bedeutet, dass sie in den Registrierungen nicht globaler Zonen nicht sichtbar sind und ein Zugriff auf die installierten Komponenten nicht möglich ist.

• Wenn gemeinsam genutzte Komponenten in der globalen Zone installiert werden (z. B. als Bestandteil der Installation von Produktkomponenten), werden sie für die Verbreitung auf nicht globale Zonen festgelegt. Dies bedeutet, dass sie in den Registrierungen nicht globaler Zonen angezeigt werden und ein Zugriff auf die installierten gemeinsam genutzten Komponenten möglich ist. Diese Richtlinie trägt der Anforderung Rechnung, dass die Versionen gemeinsam genutzter Komponenten in allen Zonen synchronisiert werden müssen, wie in Abschnitt Gemeinsam genutzte Java ES-Komponenten und Zonen beschrieben.

Installation von Produktkomponenten

Das Java ES-Installationsprogramm ermöglicht sowohl die Installation von Produktkomponenten sowie die Installation von gemeinsam genutzten Komponenten, die zur Unterstützung der Produktkomponenten erforderlich sind. Bevor Sie eine ausgewählte Produktkomponente installieren, prüft das Installationsprogramm, ob aktuelle oder ältere Versionen der gemeinsam genutzten Komponenten vorhanden sind. Wenn das Installationsprogramm ermittelt, dass eine gemeinsam genutzte Komponente für die ausgewählte Produktkomponente nur in einer älteren Version vorliegt oder fehlt, werden alle zurzeit installierten gemeinsam genutzten Komponenten aktualisiert und fehlende, von der ausgewählten Produktkomponente benötigte gemeinsam genutzte Komponenten werden installiert. Dieses Verhalten entspricht den Anforderungen aus dem Abschnitt Synchronisierung gemeinsam genutzter Komponenten und gilt für Betriebssysteme ohne Zonen, globale und alle nicht globalen Zonen.

Es gelten jedoch zwei Ausnahmen:

• In Sparse-Root-Zonen können einige gemeinsam genutzte Komponenten nicht installiert oder aktualisiert werden (siehe Gemeinsam genutzte Komponenten und Sparse-Root-Zonen), und die Installation wird unterbrochen, bis die gemeinsam genutzten Komponenten in der globalen Zone installiert oder aktualisiert wurden. Das Installationsprogramm gibt folgende Meldung aus: "Die folgenden gemeinsam genutzten Komponenten sind für die ausgewählten Komponenten erforderlich, können jedoch in einer Sparse-Root-Zone weder installiert noch aktualisiert werden. Bitte installieren oder aktualisieren Sie diese gemeinsam genutzten Komponenten in der globalen Zone, bevor Sie fortfahren. Verwenden Sie die Option 'Alle gemeinsam genutzten Komponenten'." Weitere Informationen finden Sie im Abschnitt Synchronisieren aller gemeinsam genutzten Komponenten.

• In einer globalen Zone wird bei Vorhandensein nicht globaler Zonen anstelle einer Aktualisierung der derzeit installierten gemeinsam genutzten Komponenten sowie einer Installation der fehlenden gemeinsam genutzten Komponenten durch das Installationsprogramm eine Synchronisierung aller gemeinsam genutzten Java ES-Komponenten durchgeführt, unabhängig davon, ob diese von einer spezifischen Produktkomponente benötigt werden oder nicht. Auf diese Weise können alle gemeinsam genutzen Komponenten auf die nicht globalen Zonen verbreitet werden, und es wird sichergestellt, dass in den nicht globalen Zonen nur eine Version der gemeinsam genutzten Komponenten verwendet wird.

Aktualisierung von Produktkomponenten

Ein neues Feature in Java ES 5 ermöglicht die Aktualisierung der folgenden Produktkomponenten: Application Server, Message Queue, HADB und Java DB. Wenn das Java ES-Installationsprogramm Vorgängerversionen dieser Produktkomponenten ermittelt, werden diese auf der Seite "Komponentenauswahl" für die Aktualisierung markiert. Wenn eine dieser vier Produktkomponenten ausgewählt wurde, erfolgt die Aktualisierung durch das Installationsprogramm ähnlich wie bei einer Neuinstallation.

Vor der Aktualisierung einer ausgewählten Produktkomponente prüft das Installationsprogramm, ob aktuelle oder frühere Versionen von gemeinsam genutzten Komponenten vorhanden sind. Wenn das Installationsprogramm ermittelt, dass eine gemeinsam genutzte Komponente für die ausgewählte Produktkomponente nur in einer älteren Version vorliegt oder fehlt, werden alle zurzeit installierten gemeinsam genutzten Komponenten aktualisiert und fehlende, von der ausgewählten Produktkomponente benötigte gemeinsam genutzte Komponenten werden installiert. Dieses Verhalten entspricht den Anforderungen, die in Synchronisieren aller gemeinsam genutzten Komponenten beschrieben werden und gilt für Betriebssysteme ohne Zonen, globale und alle nicht globalen Zonen.

Es gelten jedoch drei Ausnahmen:

• In Sparse-Root-Zonen können einige gemeinsam genutzte Komponenten nicht installiert oder aktualisiert werden, und die Installation wird unterbrochen, bis die gemeinsam genutzten Komponenten in der globalen Zone installiert oder aktualisiert wurden. (Weitere Informationen finden Sie im Abschnitt Gemeinsam genutzte Komponenten und Sparse-Root-Zonen.) Das Installationsprogramm zeigt folgende Fehlermeldung an: "Die folgenden gemeinsam genutzten Komponenten sind für die ausgewählten Komponenten erforderlich, können jedoch in einer Sparse-Root-Zone weder installiert noch aktualisiert werden. Bitte installieren oder aktualisieren Sie diese gemeinsam genutzten Komponenten in der globalen Zone, bevor Sie fortfahren. Verwenden Sie die Option 'Alle gemeinsam genutzten Komponenten'." (Weitere Informationen finden Sie in Abschnitt Synchronisieren aller gemeinsam genutzten Komponenten.)

• Application Server und Message Queue werden im Paket mit dem Solaris-Betriebssystem bereitgestellt. Keine dieser Versionen kann in einer Sparse-Root-Zone direkt aktualisiert werden. Genauere Informationen zu diesen zwei gebündelten Komponenten finden Sie in Abschnitt Sonderfälle bei den Produktkomponenten.

• In einer globalen Zone wird bei Vorhandensein nicht globaler Zonen anstelle einer Aktualisierung der derzeit installierten gemeinsam genutzten Komponenten sowie einer Installation der fehlenden gemeinsam genutzten Komponenten, die für die Installation ausgewählter Komponenten erforderlich sind, durch das Installationsprogramm eine Synchronisierung aller gemeinsam genutzten Java ES-Komponenten durchgeführt. Dies geschieht unabhängig davon, ob diese von einer ausgewählten Komponente für die Installation benötigt werden oder nicht. Auf diese Weise können alle gemeinsam genutzen Komponenten auf die nicht globalen Zonen verbreitet werden, und es wird sichergestellt, dass in den nicht globalen Zonen nur eine Version der gemeinsam genutzten Komponenten verwendet wird.

---

Hinweis –

Es gibt eine Vielzahl an Sonderfällen bzw. Ausnahmen, die die Installation oder das Upgrade von Produktkomponenten in nicht globalen Zonen behindern können. Diese Fälle werden in Abschnitt Sonderfälle und Ausnahmen beschrieben.

---

Synchronisieren aller gemeinsam genutzten Komponenten

Java ES bietet die Option zum Synchronisieren aller gemeinsam genutzten Komponenten, um bei Bedarf alle gemeinsam genutzten Komponenten synchronisieren zu können. Bei Auswahl der Option "Alle gemeinsam genutzten Komponenten" aktualisiert das Installationsprogramm alle derzeit installierten gemeinsam genutzten Komponenten und installiert fehlende gemeinsam genutzte Komponenten – unabhängig davon, ob diese von einer spezifischen Produktkomponente benötigt werden oder nicht. Dies gilt für globale Zonen und Whole-Root-Zonen, jedoch nicht für Sparse-Root-Zonen.

Die Option "Alle gemeinsam genutzten Komponenten" wird für die folgenden zwei Zonen-basierten Szenarios benötigt:

• Das Durchführen eines manuellen Upgrades von Produktkomponenten. Die Option "Alle gemeinsam genutzten Komponenten" wird benötigt, um die Installation und das Upgrade von gemeinsamen Komponenten durchzuführen, wenn ein Upgrade von Produktkomponenten erforderlich ist, die nicht durch das Java ES-Installationsprogramm aktualisiert werden können.

• Installationen oder Aktualisierungen in einer Sparse-Root-Zone Einige gemeinsame Komponenten lassen sich nicht in standardmäßigen Sparse-Root-Zonen installieren. (Weitere Informationen finden Sie in den Abschnitten Installation von Produktkomponenten und Aktualisierung von Produktkomponenten.) Zur Verwendung des Installationsprogramms in Sparse-Root-Zonen müssen die betroffenen gemeinsam genutzten Komponenten in der globalen Zone möglicherweise zunächst synchronisiert werden, je nachdem welche gemeinsamen Komponenten betroffen sind. Verwenden Sie die Option "Alle gemeinsam genutzten Komponenten" in der globalen Zone, um die in diesem Fall erforderliche Installation und Aktualisierung der gemeinsam genutzten Komponenten durchzuführen.

Verhalten des Java ES-Installationsprogramms in Bezug auf gemeinsam genutzte Komponenten – Zusammenfassung

Das oben beschriebene Verhalten des Java ES-Installationsprogramms in Bezug auf die gemeinsam genutzten Komponenten wird in der folgenden Tabelle zusammengefasst und richtet sich nach dem Zonenkontext sowie nach der Auswahl auf der Seite für die Komponentenauswahl.

Tabelle A–1 Verhalten des Installationsprogramms in Bezug auf gemeinsam genutzte Komponenten

Zonenkontext	Ausgewählte Produktkomponente	Alle ausgewählten gemeinsam genutzten Komponenten
Betriebssystem ohne Zonen	Aktualisierung aller derzeit installierten gemeinsam genutzten Komponenten.  Installation aller fehlenden gemeinsam genutzten Komponenten, die von der ausgewählten Produktkomponente benötigt werden.	Aktualisierung aller derzeit installierten gemeinsam genutzten Komponenten.  Installation aller fehlenden gemeinsam genutzten Komponenten, unabhängig davon, ob sie von einer spezifischen Produktkomponente benötigt werden oder nicht.
Globale Zone: Es sind keine nicht globalen Zonen vorhanden	Aktualisierung aller derzeit installierten gemeinsam genutzten Komponenten.  Installation aller fehlenden gemeinsam genutzten Komponenten, die von der ausgewählten Produktkomponente benötigt werden.	Aktualisierung aller derzeit installierten gemeinsam genutzten Komponenten.   Installation aller fehlenden gemeinsam genutzten Komponenten, unabhängig davon, ob sie von einer spezifischen Produktkomponente benötigt werden oder nicht.
Globale Zone: Es sind nicht globale Zonen vorhanden	Aktualisierung aller derzeit installierten gemeinsam genutzten Komponenten.   Installation aller fehlenden gemeinsam genutzten Komponenten, unabhängig davon, ob sie von einer spezifischen Produktkomponente benötigt werden oder nicht.	Aktualisierung aller derzeit installierten gemeinsam genutzten Komponenten sowie Installation aller fehlenden gemeinsam genutzten Komponenten, unabhängig davon, ob sie von einer spezifischen Produktkomponente benötigt werden oder nicht.
Whole-Root-Zone	Aktualisierung aller derzeit installierten gemeinsam genutzten Komponenten.  Installation aller fehlenden gemeinsam genutzten Komponenten, die von der ausgewählten Produktkomponente benötigt werden.	Aktualisierung aller derzeit installierten gemeinsam genutzten Komponenten.  Installation aller fehlenden gemeinsam genutzten Komponenten, unabhängig davon, ob sie von einer spezifischen Produktkomponente benötigt werden oder nicht.
Sparse-Root-Zone	Aktualisierung oder Installation einiger gemeinsam genutzter Komponenten in schreibgeschützten Verzeichnissen nicht möglich. Wenn das Installationsprogramm solche gemeinsam genutzten Komponenten ermittelt, wird die Installation unterbrochen und der Benutzer wird aufgefordert, zunächst die gemeinsam genutzten Komponenten in der globalen Zone zu verwalten.	Aktualisierung oder Installation einiger gemeinsam genutzter Komponenten in schreibgeschützten Verzeichnissen nicht möglich. Das Installationsprogramm unterbricht die Installation und der Benutzer wird aufgefordert, zunächst die gemeinsam genutzten Komponenten in der globalen Zone zu verwalten.

Empfohlene Verwendung von Zonen mit Java ES

Neben den allgemeinen Vorteilen einer Laufzeitisolierung von Produktkomponenten und einer effizienteren Ressourcennutzung können mit einer Multi-Zonen-Umgebung darüber hinaus verschiedene weitere Ziele erreicht werden. Diese Ziele werden in Abschnitt Gründe für die Verwendung von Zonen für Java ES erläutert. Die eingesetzten Strategien für die Installation und Administration von Java ES in einer Multi-Zonen-Umgebung hängen stark davon ab, welche dieser Ziele Sie erreichen möchten.

In Tabelle A–2 werden fünf Szenarien, die zugehörigen Installations- und Administrationsstrategien sowie deren jeweilige Ziele verglichen. Wenngleich eine Kombination dieser Szenarien in Einzelfällen möglich ist, kann ein solches Vorgehen zu Problemen bei der Administration führen. Für Java ES 5 werden daher im Allgemeinen keine Bereitstellungen unterstützt, bei denen die gezeigten Szenarien kombiniert werden.

Darüber hinaus werden die Szenarien 1 und 5 als problematisch eingestuft und von Java ES 5 derzeit nicht unterstützt (wenngleich Szenario 5 für spezifische Produktkomponenten verwendet werden kann).

Tabelle A–2 Strategien in Bezug auf die Zoneninstallation und -administration für Java ES

Szenario (Installationsstrategie)	Administrationsstrategie	Ziel (siehe Gründe für die Verwendung von Zonen für Java ES)	Kommentare
1: Produktkomponenten und gemeinsam genutzte Komponenten werden bei aktivierter Verbreitung in der globalen Zone installiert. In den nicht globalen Zonen werden keine Komponenten installiert.*	Lebenszyklusverwaltung für Komponenten: Globaler Administrator   Konfigurations- und Laufzeitverwaltung: Zonenadministratoren	Zentrale Lebenszyklusverwaltung für Produktkomponenten   Organisationsunabhängigkeit in Bezug auf Konfigurations- und Laufzeitverwaltung für Produktkomponenten	Problematisch: Noch nicht für Java ES-Produktkomponenten unterstützt, ausgenommen für Message Queue. Erfordert, dass die Produktkomponenten eine Installation in globalen Zonen, aber eine Konfigurations- und Laufzeitverwaltung in nicht globalen Zonen unterstützen.
2: Gemeinsam genutzte Komponenten werden in der globalen Zone, Produktkomponenten in Whole-Root-Zonen installiert.	Lebenszyklusverwaltung für gemeinsam genutzte Komponenten: Globaler Administrator   Lebenszyklusverwaltung für Produktkomponenten: Zonenadministratoren   Konfigurations- und Laufzeitverwaltung: Zonenadministratoren	Zentrale Lebenszyklusverwaltung für gemeinsam genutzte Komponenten   Organisationsunabhängigkeit in Bezug auf Lebenszyklus-, Konfigurations- und Laufzeitverwaltung für Produktkomponenten	Insbesondere dann sinnvoll, wenn alle Komponenten in derselben Java ES-Version ausgeführt oder alle Produktkomponenten in allen Whole-Root-Zonen aktualisiert werden.
3: Gemeinsam genutzte Komponenten werden in der globalen Zone, Produktkomponenten in Sparse-Root-Zonen installiert.**	Wie Szenario 2	Zentrale Lebenszyklusverwaltung für gemeinsam genutzte Komponenten   Organisationsunabhängigkeit in Bezug auf Lebenszyklus-, Konfigurations- und Laufzeitverwaltung für Produktkomponenten   Bessere Ressourcennutzung als in Szenario 2 (siehe Whole-Root-Zonen und Sparse-Root-Zonen im Vergleich)	Dieses Szenario wird empfohlen, um Produktkomponenten in Sparse-Root-Zonen zu installieren. (Einige gemeinsam genutzte Komponenten können nicht in Sparse-Root-Zonen installiert werden, die Installation muss daher in der globalen Zone erfolgen.)
4: Produktkomponenten und gemeinsam genutzte Komponenten werden in Whole-Root-Zonen installiert.	Lebenszyklusverwaltung für Komponenten: Zonenadministratoren, Konfigurations- und Laufzeitverwaltung: Zonenadministratoren	Versionstrennung	Es sollten in der globalen Zone keine gemeinsam genutzten Komponenten und keine Produktkomponenten installiert werden. Für Whole-Root-Zonen empfohlenes Szenario.
5: Produktkomponenten und gemeinsam genutzte Komponenten werden in Sparse-Root-Zonen installiert.	Wie Szenario 4	Organisationsunabhängigkeit in Bezug auf Lebenszyklus-, Konfigurations- und Laufzeitverwaltung für Produktkomponenten  Bessere Ressourcennutzung als in Szenario 4 (siehe Whole-Root-Zonen und Sparse-Root-Zonen im Vergleich)	Problematisch. Kann im Allgemeinen nicht implementiert werden, da verschiedene der gemeinsam genutzten Komponenten nicht in Sparse-Root-Zonen installiert werden können.

* Szenario 1 unterscheidet nicht zwischen Whole-Root- und Sparse-Root-Zonen-Umgebungen; es wird vorausgesetzt, dass in nicht globalen Zonen keine Produktkomponenten installiert werden. Die Installation von Produktkomponenten in nicht globalen Zonen wird in den Szenarien 2-5 abgedeckt.

** Szenario 3 setzt voraus, dass /opt nicht als schreibgeschütztes Verzeichnis in der Sparse-Root-Zone vorliegt. Wenn /opt schreibgeschützt ist, können die meisten Java ES-Produktkomponenten nicht in Sparse-Root-Zonen installiert werden. In diesem Fall müsste die Installation (wie in Szenario 1) stattdessen in der globalen Zone erfolgen.

Empfohlene Vorgehensweisen

Unter Berücksichtigung von Tabelle A–2, nachfolgend eine Auflistung der empfohlenen Vorgehensweisen:

• Planen Sie Ihre Strategie für die Java ES-Zonenbereitstellung im Vorfeld, und berücksichtigen Sie dabei die angestrebten Ziele, wie in Abschnitt Gründe für die Verwendung von Zonen für Java ES beschrieben. Verschiedene Ziele erfordern unterschiedliche Strategien für Installation und Administration, wie dargestellt in den verschiedenen Szenarien aus Tabelle A–2.

• Vermeiden Sie die Kombination von Szenarien. Im Besonderen gilt:

  • Halten Sie Ihre Strategie für die Bereitstellung und Administration von Java ES-Zonen so einfach wie möglich. Kombinieren Sie keine Whole-Root- und Sparse-Root-Bereitstellungen von Java ES-Komponenten auf einem einzelnen Computer. (Verfahren und erforderliche Vorgehensweisen zur Unterstützung von von Sparse-Root-Zonenbereitstellungen wie in Szenario 3 können zu Konflikten mit Whole-Root-Zonenbereitstellungen wie in Szenario 4 führen.)

  • Installieren Sie eine Java ES-Produktkomponente nicht sowohl in der globalen Zone als auch in nicht globalen Zonen, selbst wenn es sich um unterschiedliche Versionen handelt. (Verfahren zur Aktualisierung einer globalen Zoneninstallation wie in Szenario 1 können die nicht globalen Zoneninstallationen wie in Szenario 4 beschädigen.)

  • Wenn Java ES-Komponenten der Version 4 (oder früher) in einer Whole-Root-Zone installiert wurden, installieren Sie keine Java ES-Komponenten der Version 5 (weder Produktkomponenten noch gemeinsam genutzte Komponenten), und führen Sie in der globalen Zone keine Aktualisierung der Java ES-Komponenten auf Version 5 durch. Anders ausgedrückt: Szenario 2 wird nicht unterstützt, wenn bereits Java ES-Installationen in einer Whole-Root-Zone vorliegen. (Eine Installation oder Aktualisierung in der globalen Zone könnte zu einer Vermischung von Dateien der Versionen 4 und 5 in der Whole-Root-Zone führen.)

• Empfohlene Vorgehensweisen bei der Installation:

  • Wenn Sie unterschiedliche Java ES-Produktkomponenten in unterschiedlichen Zonen ausführen möchten, installieren Sie die Produktkomponenten in nicht globalen Zonen (Szenario 2, 3, 4, 5).

  • Wenn Sie unterschiedliche Java ES-Produktkomponenten in unterschiedlichen Zonen installieren möchten, die Lebenszyklusverwaltung für gemeinsam genutzte Komponenten jedoch zentral erfolgen soll, synchronisieren Sie die gemeinsam genutzten Komponenten in der globalen Zone, und installieren Sie anschließend die Produktkomponenten in nicht globalen Zonen (Szenario 2, 3). (Dies ist eine empfohlene Vorgehensweise, wenn Produktkomponenten in Sparse-Root-Zonen installiert werden.)

  • Wenn Sie eine Versionstrennung für die Java ES-Produktkomponenten erzielen oder aus anderen Gründen Bereitstellungen von Java ES-Produktkomponenten isolieren möchten (Szenario 4), dann installieren und konfigurieren Sie alle Java ES-Komponenten in Whole-Root-Zonen. Installieren Sie keine Java ES-Komponenten in der globalen Zone.

• Empfohlene Vorgehensweisen beim Durchführen eines Upgrades:

  • Wenn Sie alle installierten Produktkomponenten der Version 4 auf Version 5 aktualisieren möchten, synchronisieren Sie alle gemeinsam genutzten Java ES-Komponenten in der globalen Zone. Führen Sie anschließend in den Zonen, in denen die Produktkomponente installiert ist, eine Aktualisierung der gewünschten Produktkomponenten durch. (Gemeinsam genutzte Komponenten der Version 5 sind abwärtskompatibel.)

  • Wenn Sie über Produktkomponenten der Versionen 4 oder 5 in einer Umgebung ohne Zonen verfügen und Sie der Umgebung nicht globale Zonen hinzufügen möchten, um Produktkomponenten in den neuen nicht globalen Zonen zu installieren, müssen Sie sicherstellen, dass Sie die Aktualisierung den aufgeführten empfohlenen Vorgehensweisen entsprechend durchführen. Dies kann bedeuten, dass Sie die Komponenten in der globalen Zone deinstallieren und eine Neuinstallation in den nicht globalen Zonen durchführen müssen.

Bereitstellungsarchitekturen

Die Szenariobeschreibungen in Tabelle A–2 sowie die oben genannten empfohlenen Vorgehensweisen enthalten keine empfohlenen Java ES-Bereitstellungsarchitekturen für eine Multi-Zonen-Umgebung. Derartige Architekturen würden eine Variante der Bereitstellungsarchitekturen für Multi-Computer-Netzwerkumgebungen darstellen. Anders ausgedrückt: Die Verfügbarkeit von Multi-Zonen-Umgebungen ändert nichts am grundlegenden Ansatz in Bezug auf den Bereitstellungsentwurf zum Erzielen hoher Leistung, Hochverfügbarkeit, Skalierbarkeit, Sicherheit und Betriebsfähigkeit für Java ES-Bereitstellungssysteme. Eine Multi-Zonen-Umgebung ermöglicht eine Konsolidierung dieser Bereitstellungsarchitekturen auf einer kleineren Anzahl an Computern.

Die Details der Anpassung einer Java ES-Bereitstellungsarchitektur in einer Multi-Zonen-Umgebung richten sich sehr stark nach dem gewünschten Administrationsmodell, wie bereits in den vorangegangenen Abschnitten erläutert. Bereitstellungsarchitekturen hängen darüber hinaus auch von der Strategie zur Erzielung von Hochverfügbarkeit ab.

Beachten Sie, dass Tabelle A–2 und die empfohlenen Vorgehensweisen keine Empfehlungen in Bezug auf die Implementierung der beschriebenen Szenarien umfassen. In einigen Fällen kann die Reihenfolge der Installation von Java ES-Produktkomponenten sowie die Reihenfolge der Erstellung von nicht lokalen Zonen von Bedeutung sein.

Sonderfälle und Ausnahmen

Es gibt verschiedene Sonderfälle, die sich maßgeblich aus der Tatsache ergeben, dass einige der gemeinsam genutzten Java ES-Komponenten und einige Java ES-Produktkomponenten mit Solaris 10 im Paket bereitgestellt werden. Durch diese Bündelung liegen diese Java ES-Komponenten in der globalen Zone vor und somit auch in jeder nicht globalen Zone, die aus der globalen Zone erstellt wird.

Sonderfälle bei den Produktkomponenten

• Message Queue wird im Paket mit Solaris 10 bereitgestellt und als Ergebnis automatisch verbreitet, wenn nicht globale Zonen erstellt werden (es sei denn, sie haben Message Queue zunächst aus der globalen Zone entfernt). Message Queue kann nicht in einer Sparse-Root-Zone installiert werden. Wenn Sie über das Java ES-Installationsprogramm eine Installation oder Aktualisierung in einer globalen Zone vornehmen, wird Message Queue per Voreinstellung – im Gegensatz zu anderen Produktkomponenten – auf die nicht globalen Zonen verbreitet.

• Application Server wird im Paket mit Solaris 10 bereitgestellt und als Ergebnis automatisch verbreitet, wenn nicht globale Zonen erstellt werden (es sei denn, sie haben Message Queue zunächst aus der globalen Zone entfernt). Bei einer Verbreitung auf diese Weise kann der im Paket bereitgestellte Application Server, der in /usr installiert ist, durch das Java ES-Installationsprogramm nicht in einer Sparse-Root-Zone aktualisiert werden (/usr ist standardmäßig schreibgeschützt). Um dieses Problem zu beseitigen, muss der im Paket bereitgestellte Application Server manuell aus der globalen Zone entfernt werden, bevor Application Server 5 in einer Sparse-Root-Zone installiert wird.

• Sun Cluster kann nur in einer globalen Zone installiert werden. Sun Cluster wird in nicht globalen Zonen nicht unterstützt.

Sonderfälle bei gemeinsam genutzten Komponenten

• SJWC-Pakete, die gebündelt mit Solaris 10 (Update 1 und Update 2) bereitgestellt werden, können über das Java ES-Installationsprogramm nicht entfernt werden. Für diese älteren SJWC-Pakete ist SUNW_PKG_ALLZONES auf True gesetzt, d. h. das Paket muss in allen Zonen identisch sein und kann nur durch den globalen Administrator verwaltet werden. Als Ergebnis müssen diese Pakete manuell aus der globalen Zone entfernt werden, um durch die richtigen Pakete ersetzt zu werden.

  Wenn das Java ES-Installationsprogramm versucht, eine ausgewählte Komponente in einer nicht globalen Zone zu installieren und ermittelt, dass SJWC aktualisiert werden muss, wird die Installation unterbrochen. Dies ist der Fall, wenn die Installation unter Solaris 10, Update 1 und 2 erfolgt.

  Zur Umgehung dieses Problems wurde ein spezielles Skript entwickelt, das die alten SJWC-Pakete aus der globalen Zone entfernt und durch entsprechende SJWC 2.2.6-Pakete ersetzt, welche die richtige Attributeinstellung für die Zonenverbreitung aufweisen. Das führt dazu, dass SJWC 2 2.6 auf alle nicht globalen Zonen übertragen wird.

• Common Agent Container. Version 1.1 wird installiert, wenn Sun Cluster, Sun Cluster GE oder Sun Cluster-Agents installiert werden. Die Installation wird nicht vorgenommen, wenn die Option "Alle gemeinsam genutzten Komponenten" aktiviert ist. In diesem Fall wird nur Version 2.0 installiert.

• Sun Explorer Data Collector. Diese gemeinsam genutzte Komponente wird nur installiert, wenn Sun Cluster, Sun Cluster GE oder Sun Cluster-Agents installiert werden. Die Installation wird nicht vorgenommen, wenn die Option "Alle gemeinsam genutzten Komponenten" aktiviert ist.

Beispiel zur Veranschaulichung: Installation von Application Server in einer Sparse-Root-Zone

Das folgende Beispiel soll verdeutlichen, wo die Schwierigkeiten bei der Java ES-Zonenunterstützung liegen. In diesem Beispiel liegt die Schwierigkeit darin, Application Server in einer Solaris 10 Sparse-Root-Zone zu installieren. Diese Installation wird durch die Tatsache verkompliziert, dass Application Server (ebenso wie Message Queue, von dem Application Server abhängt), im Paket mit Solaris 10 bereitgestellt wird, und daher die Paketversion in einer nicht globalen Zone installiert wird. Weitere Informationen finden Sie in Abschnitt Sonderfälle bei den Produktkomponenten.

Für die Installation von Application Server in einer Sparse-Root-Zone muss die Paketversion zunächst aus der globalen Zone entfernt werden. (Sie können nicht einfach eine Aktualisierung der Paketversion in der Sparse-Root-Zone durchführen, da die Version in einem schreibgeschützten Verzeichnis installiert ist). Um die Paketversion aus der Sparse-Root-Zone zu entfernen, müssen Sie diese in der globalen Zone entfernen.

Zusätzlich ist Message Queue in der globalen Zone installiert, was eine Abweichung von Szenario 3 in Tabelle A–2 darstellt, nach dem nur gemeinsam genutzte Komponenten (keine Produktkomponenten) in der globalen Zone installiert werden sollten. Message Queue kann jedoch nicht in einer Sparse-Root-Zone installiert werden, da dies in einem schreibgeschützten Verzeichnis installiert wird. Deshalb müssen Installation und Upgrade in einer globalen Zone erfolgen.

Die Vorgehensweise lautet wie folgt:

1. Stellen Sie sicher, dass Solaris 10 auf Ihrem System ausgeführt wird.

   In diesem Beispiel wird vorausgesetzt, dass Sie eine Neuinstallation von Solaris 10 ohne Java ES-Komponenten vornehmen, die explizit in der globalen Zone erfolgt.

2. Erstellen Sie eine Sparse-Root-Zone (konfigurieren, installieren und starten Sie sie).

   Diese Zone wird alle Java ES-Komponenten umfassen, die bereits in der globalen Zone installiert sind, und zwar die Versionen von Message Queue und Application Server, die zusammen mit Solaris 10 bereitgestellt werden.

3. Entfernen Sie die Paketversion von Application Server aus der globalen Zone.

   Sie müssen die Application Server-Pakete manuell entfernen:

   pkgrm SUNWascmnse SUNWaslb SUNWasut ...

   Der vollständige Paketsatz kann über den folgenden Befehl abgerufen werden:

   pkginfo -I|grep -I application server

   Die Ergebnisse können folgende Pakete umfassen:

   SUNWascmnse, SUNWaslb, SUNWasut, SUNWasac, SUNWasdem, SUNWasman, SUNWaswbcr, SUNWasacee, SUNWashdm, SUNWasmanee, SUNWascml, SUNWasJdbcDrivers, SUNWasu, SUNWascmn, SUNWasjdoc, SUNWasuee

   Darüber hinaus können folgende Lokalisierungspakete aufgeführt werden:

   SUNWLocaleasacee, SUNWLocaleascmnse, SUNWLocaleasu, SUNWLocaleasuee

   Die Entfernung von Application Server aus der globalen Zone wird auf die Sparse-Root-Zone verbreitet, die in Schritt 2 erstellt wurde. (Dieser Schritt und Schritt 2 können in umgekehrter Reihenfolge ausgeführt werden.)

4. Installieren Sie die gemeinsam genutzten Java ES 5-Komponenten in der globalen Zone.

   1. Führen Sie das Java ES-Installationsprogramm in der globalen Zone aus.

   2. Wählen Sie auf der Seite für die Komponentenauswahl die Option "Alle gemeinsam genutzten Komponenten". Wählen Sie keine weitere Komponente aus.

   3. Schließen Sie die Synchronisierung der gemeinsam genutzten Komponenten ab. Alle gemeinsam genutzten Java ES-Komponenten werden nun in der globalen Zone synchronisiert und auf alle nicht globalen Zonen verbreitet.

5. Aktualisieren Sie Message Queue in der globalen Zone.

   Die im Paket mit Solaris 10 bereitgestellte Version von Message Queue ist aufgrund von Schritt 2 bereits in der Sparse-Root-Zone installiert. Führen Sie zur Aktualisierung von Message Queue in der Sparse-Root-Zone lediglich eine Aktualisierung in der globalen Zone aus; die Aktualisierung wird anschließend auf die Sparse-Root-Zone verbreitet. (Message Queue ist die einzige Produktkomponente, die nicht in einer Sparse-Root-Zone installiert werden kann. Wenn Message Queue jedoch in der globalen Zone installiert ist, erfolgt eine Verbreitung auf die nicht globalen Zonen.)

   1. Führen Sie das Java ES-Installationsprogramm in der globalen Zone aus.

   2. Wählen Sie auf der Seite für die Komponentenauswahl die Option "Message Queue". Wählen Sie keine weitere Komponente aus.

   3. Schließen Sie die Aktualisierung von Message Queue ab.

6. Installieren Sie Application Server in der Sparse-Root-Zone.

   1. Führen Sie das Java ES-Installationsprogramm in der Sparse-Root-Zone aus.

   2. Wählen Sie auf der Seite für die Komponentenauswahl die Option "Application Server". Wählen Sie keine weitere Komponente für die Aktualisierung aus. Deaktivieren Sie gegebenenfalls die Option "Message Queue" (sofern aktiviert).

   3. Schließen Sie die Installation von Application Server ab.