Die Validierung einer Edition ist der Prozess, mit dem festgestellt wird, ob eine neue Edition
für den Übergang in die Produktion und die Ersetzung der aktuellen Edition bereit ist.
Eine Edition kann unter realistischen Bedingungen installiert und validiert werden, während
die Anwendungsedition in der Produktion
weiterhin Anforderungen bedient.
Vorbereitungen
Probleme vermeiden: In den folgenden Konfigurationsszenarios funktioniert
die Editionsvalidierung nicht ordnungsgemäß:
- Anwendungen, die in einem dynamischen Cluster implementiert sind, das aus einem statischen Cluster konvertiert wurde.
- Anwendungen, die mehrere Webmodule oder mehrere EJB-Module (Enterprise
JavaBeans) enthalten. Die Editionsvalidierung kann nur in Anwendungen ausgeführt werden,
die ein einzelnes Webmodul, ein einzelnes EJB-Modul oder ein Webmodul und EJB-Modul enthalten.
gotcha
- Sie müssen eindeutige Routing-Regeln für Edition 2.0 definieren.
Wenn Sie Routing-Regeln definieren, können Editionen gleichzeitig ausgeführt
und HTTP-Anforderungen für die zu validierende Edition ordnungsgemäß an das Validierungsziel weitergeleitet
werden, ohne Edition 1.0 zu beeinträchtigen. Verwenden Sie für dieses Szenario die Anwendung
meine_Anwendung. Installieren Sie beide Anwendungseditionen,
1.0 und 2.0, im dynamischen Cluster dynamischer_Cluster_1.
Weitere Informationen zum Erstellen von Routing-Regeln für Anwendungseditionen
finden Sie im Artikel Routing-Richtlinien für Anwendungseditionen erstellen
.
- Wenn Sie für den geklonten Validierungscluster einen anderen Betriebsmodus
als den des Produktionsclusters einstellen möchten, erstellen Sie in der Administrationskonsole die
angepasste Eigenschaft VALIDATION_OPERATIONALMODE.
Andernfalls wird der Validierungscluster nach der Erstellung auf denselben Betriebsmodus wie der Produktionscluster eingestellt.
Geben Sie einen der Werte
automatic, manual oder supervised an.
Wenn Sie einen anderen Wert oder keinen Wert angeben, wird der manuelle Modus für den
dynamischen Validierungscluster eingestellt.
Einschränkung: Im Validierungsmodus können nur zwei Cluster-Member verwendet oder erstellt werden.
Sie können der Anwendung im Validierungsmodus Routing- und Servicerichtlinien zuordnen,
es werden aber nicht mehr als zwei Cluster-Member gestartet, die die Arbeit ausführen.
Sie können diese Einstellung nach der Erstellung des Validierungsclusters überschreiben, indem Sie die Mindest- und Maximalanzahl
dynamischer Clusterinstanzen ändern.
- Wenn Sie ein Benutzer sind,
der der Rolle "Überwachung" (Monitor) oder "Bedienung" (Operator) angehört, können Sie die Informationen zum Application Edition Manager
nur anzeigen.
Gehören Sie zur Rolle "Konfiguration" (Configurator) oder "Verwaltung" (Administrator), haben Sie alle Konfigurationsberechtigungen für den
Application Edition Manager.
- Zum Validieren einer neuen Edition fügen Sie das Validierungscluster dem SIB (Service Integration Bus) hinzu.
- Wenn Sie ein Release vor Version 6.1.0.5 ausführen, darf sich
zu einem bestimmten Zeitpunkt jeweils nur eine Anwendung pro Implementierungsziel im Validierungsmodus befinden.
Beginnend mit Version 6.1.0.5 können mehrere Anwendungen auf demselben Implementierungsziel im Validierungsmodus sein.
Es muss sich dabei jedoch um unterschiedliche Anwendungen handeln und nicht um unterschiedliche Editionen derselben Anwendung.
Informationen zu dieser Task
Betrachten Sie das folgende Szenario als Beispiel dafür, wie die Validierung in einer Edition ausgeführt wird:
Edition 1.0 einer Anwendung ist in einem dynamischen Cluster installiert und aktiv.
Edition 2.0 ist die Edition, die validiert werden soll. Sie ist in demselben Implementierungsziel installiert und inaktiv.
Bei der Validierung der Edition 2.0 wird das Implementierungsziel der Edition 2.0 geklont. Beispielsweise kann während der Validierung
ein neuer dynamischer Cluster, z. B. DC-Validation, erstellt und die Edition 2.0 diesem neuen Cluster
zugeordnet werden.
Der geklonte Cluster verwendet die vorhandenen Cluster-Member als Serverschablone für die Erstellung der geklonten Server.
Nach der Erstellung des Validierungsziels wird Edition 2.0 aktiviert, und es werden
Routing-Regeln definiert. Sie können die Edition starten, stoppen und rekonfigurieren.
Prozedur
-
Klicken Sie auf , um sich zu vergewissern,
dass die Anwendung zwei installierte Editionen hat, von denen nur eine aktiv ist.
- Optional:
Wenn Sie ein Validierungscluster
erstellen möchten, dessen Betriebsmodus von dem Ihres Produktionsclusters abweicht, können Sie im Produktionscluster
die angepasste Eigenschaft
VALIDATION_OPERATIONALMODE definieren.
Fügen Sie das Validierungscluster dem SIB (Service Integration Bus) hinzu.
Wenn Sie diese angepasste Eigenschaft nicht definieren, hat das Validierungscluster
denselben Betriebsmodus wie das Produktionscluster.
-
Aktualisieren Sie die EJB-Referenzbindungen (Enterprise JavaBeans), so dass diese den neuen Clusternamen angeben.
Bevor Sie ein Rollout der Anwendung aus dem Validierungscluster durchführen, müssen die Bindungen in den ursprünglichen Wert
zurückgeändert werden.
-
Klicken Sie auf die Anwendung meine_Anwendung.
-
Wählen Sie Edition 2.0 aus, und klicken Sie auf Validieren.
Auf der Seite "Validierungsstatus"
werden die Schritte für die Validierung des dynamischen Clusters "dynamischer_Cluster_1"
und die Implementierung von Edition 2.0 im geklonten Cluster angezeigt. Im Edition Control
Center der Anwendung wird angezeigt, dass sich eine der Editionen im Validierungsmodus befindet. Auf der Seite "Editionen verwalten"
wird gezeigt, dass das Ziel für die Edition 2.0 jetzt der dynamische Cluster dynamischer_Cluster_1-Validation ist.
Auf der Seite "Dynamischer Cluster" wird gezeigt, dass der dynamische Cluster dynamischer_Cluster_1-Validation erstellt wurde, und auf der Seite
"Server" werden die geklonten Server angezeigt.
Tipp: Wenn der Validierungscluster nach dem Rollout gespeichert werden soll, müssen Sie im Validierungscluster
die angepasste Eigenschaft "saveClonedCluster" erstellen.
Andernfalls wird das Validierungsziel nach dem Rollout der Edition oder nach einem Abbruch der Validierung
für alle Anwendungen im Validierungsziel gelöscht.
Wenn beispielsweise zwei Anwendungen im Validierungsziel implementiert sind
und wenn eine der Anwendungen validiert und ein Rollout dafür durchgeführt wird, dann wird das Validierungsziel
so lange nicht gelöscht, bis die zweite Anwendung validiert wurde.
Die angepasste Eigenschaft "saveClonedCluster" gilt nur für dynamische Cluster.
Weitere Informationen hierzu finden Sie im Artikel
Angepasste Eigenschaften des Application Edition Manager
.
-
Stellen Sie sicher, dass die Validierung ordnungsgemäß durchgeführt wurde.
Klicken Sie auf oder auf . Editieren Sie die Anwendung meine_Anwendung-edition2.0.
- Für PHP-Anwendungen und Anwendungen von
WebSphere Application Server Community
Edition:
Stellen Sie sicher, dass das Kontextstammverzeichnis, die Implementierungsziele
usw. auf den geklonten Cluster verweisen.
- Für Unternehmensanwendungen (Java 2
Platform, Enterprise Edition):
Wählen Sie Module
verwalten aus. Vergewissern Sie sich, dass die Edition 2.0 dem Validierungscluster zugeordnet ist.
Vergewissern Sie in der Anzeige "EJB-Referenzen zu Beans zuordnen", dass der JNDI-Namen (Java
Naming and Directory Interface) auf den Namen des neuen geklonten Ziels eingestellt ist.
Damit eine Anwendungsedition mit vollständig qualifizierten Bindungen, die auf
dem Namen des ursprünglichen Implementierungsziels basieren,
in einem Validierungsziel ordnungsgemäß funktioniert, müssen Sie die Bindungsnamen so ändern,
dass sie die vollständig qualifizierten Bindungsnamen widerspiegeln, die auf dem Namen des Validierungsziels basieren.
Für eine Anwendung mit einer Ressourcenreferenz, die an
/clusters/clusterb1/jdbc/CustomerData gebunden ist, muss die Bindung beispielsweise
in /clusters/cluster1-validation/jdbc/CustomerData geändert werden, da die Anwendung
für die Ausführung im Klon des Implementierungsziels vorbereitet ist.
-
Testen Sie die neue Edition.
Starten Sie den Validierungscluster, und senden Sie mit Ihren Routing-Regeln
eine Anforderungslast an
Edition 2.0, um diese Edition zu testen. Edition
1.0 verbleibt in der Produktion.
Nächste Schritte
Wenn Sie den Test der
Edition 2.0 erfolgreich abgeschlossen haben, können Sie
Edition 1.0 durch
Edition 2.0 ersetzen.
Wenn während des Tests Fehler auftreten,
können Sie den Validierungsmodus abbrechen.
- Gehen Sie wie folgt vor, um
Edition 1.0 durch Edition 2.0 zu ersetzen:
- Stoppen Sie das Validierungsziel, z. B. dynamischer_Cluster_1-Validation.
- Löschen Sie die spezifischen Routing-Regeln für Edition 2.0, damit alle Anforderungen für die Anwendung
an nur eine Edition weitergeleitet werden.
- Speichern Sie Ihre Änderungen, und synchronisieren Sie die Knoten.
- Führen Sie ein Rollout der neuen Edition durch. Klicken Sie auf . Wählen Sie
Edition 2.0 aus, und klicken Sie auf Rollout. Während des Rollout wird die Edition
2.0 wieder dem ursprünglichen Implementierungsziel, z. B. dynamischer_Cluster_1,
zugeordnet. Der Status der Edition ändert sich von "Validierung" in "Aktiv".
- Wenn Edition 2.0 Fehler enthält,
können Sie den Validierungsmodus abbrechen und
Edition 2.0 wieder in den Status "Inaktiv" versetzen. Daraufhin wird der duplizierte dynamische Cluster, der für die
Validierung erstellt wurde, entfernt.
Weitere Informationen hierzu finden Sie im Artikel Anwendungsvalidierung abbrechen
.