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.