Hinweise zur Migration
Vor der Migration auf WebSphere Application Server Version 9.0 müssen einige Punkte beachtet werden.

Dieser Artikel beschreibt die Migration von Profilkonfigurationen. Wenn Sie Ihre Anwendungen auf die aktuellste Version migrieren möchten, verwenden Sie WebSphere Application Server Migration Toolkit. Weitere Informationen finden Sie unter Migration Toolkit on WASdev.
sptcfgHinweise zu den Betriebssystemen AIX, HP-UX, IBM® i, Linux, Solaris und Windows
Berücksichtigen Sie die folgenden Informationen, bevor Sie den Anwendungsserver migrieren:- Informieren Sie sich vor der Migration über die in WebSphere Application Server
Version 9.0
als veraltet gekennzeichneten Funktionen.
Weitere Informationen finden Sie unter Veraltete, stabilisierte, ersetzte und entfernte Features.
- WebSphere Application Server
Version 7.0 oder höher
enthält den
High Availability Manager (HAM) und die Stammgruppenfunktionalität.
Der Artikel Hinweise zur Migration von Stammgruppen enthält nähere Informationen zur Konfiguration von Stammgruppen und Hinweise zur Topologie, die die Migration von Version 7.0 oder höher auf Version 9.0 beeinflussen können.
Anmerkung: In den meisten Fällen wird empfohlen, in einer Stammgruppe nicht mehr als 50 Server zu verwenden. Es wird eine Warnung angezeigt, wenn die Migrationstools einen Server hinzufügen und damit der empfohlene obere Grenzwert überschritten wird. - Die Konfigurationsmigrationstools konvertieren keine Anwendungen. Sie sorgen auch nicht dafür, dass Anwendungen mit der neuen Stufe des
Java SDK kompatibel sind. Verwenden Sie vor der Migration auf ein neues Java SDK das WebSphere Application Server Migration
Toolkit, um zu bewerten, ob für Ihre Anwendungen Änderungen vorgenommen werden müssen, und um Ihre Anwendungen zu testen, nachdem Sie erforderliche Aktualisierungen duchgeführt haben.
Informationen hierzu finden Sie unter Migration
Toolkit auf WASdev.
Weitere Informationen finden Sie im Artikel API und Spezifikationen migrieren.
- Die Migrationstools erstellen ein Migrationssicherungsverzeichnis, das eine Sicherungskopie
der Konfiguration der früheren Version enthält. Die Größe dieses Verzeichnis berechnet sich aus der Größe des Konfigurationsverzeichnisses und der Anwendungen aus dem früheren Profil, einschließlich der Tracedateien.
Ihr System muss Speicherplatz für das Zielprofil haben, das nach der Migration dieselbe Größe wie das Quellenprofil hat.
Der für das Sicherungsverzeichnis erforderliche Speicherplatz Ihres Systems richtet sich nach Ihrer Umgebung und nach dem verwendeten Migrationstool.
- Position: Sicherungsverzeichnisse, die als Parameter der Befehle WASPreUpgrade und WASPostUpgrade angegeben werden.
- Speicherbedarf: Für eine Schätzung des Speicherbedarfs, der sich bei Verwendung dieser
Befehle ergibt, addieren Sie folgende Mengen.
- Größe der folgenden Elemente für alle Profile in der vorherigen Konfiguration:
- Verzeichnis Profilstammverzeichnis/installableApps
- Verzeichnis Profilstammverzeichnis/installedApps
- Verzeichnis Profilstammverzeichnis/config
- Verzeichnis Profilstammverzeichnis/properties
- In den Konfigurationsdateien resources.xml referenzierte gemeinsam genutzte Bibliotheken
- In den Konfigurationsdateien resources.xml referenzierte RAR-Dateien (Resource Adapter Archive)
- Wenn der Trace aktiviert ist, lassen Sie die Verwendung von ausreichend Speicher für die Tracedateien zu. Der Speicherbedarf richtet sich nach der Größe und der Komplexität Ihrer Konfiguration.
- Größe der folgenden Elemente für alle Profile in der vorherigen Konfiguration:
- Wenn Sie isolierte Datenrepositorys verwenden, insbesondere nicht gemeinsam genutzte Datenrepositorys, wie z. B. Transaktionsprotokolle
für SIB und Apache Derby-Datenbanken, und eine Migration von einem früheren Release durchführen,
werden Ihre vorhandenen Datenbanken und Transaktionsprotokolle bei der Ausführung des Tools WASPreUpgrade gespeichert. Alle Datenbankänderungen,
die Sie nach der Ausführung des Tools WASPreUpgrade vornehmen, sind in der migrierten Umgebung nicht verfügbar.
- Wenn Sie geschäftskritische Informationen haben, die in diesen lokalen Datenrepositorys gespeichert sind, müssen Sie alle Server, die mit diesen Repositorys interagieren, sicher herunterfahren, bevor Sie die Migration durchführen. Diese Server müssen so lange offline bleiben, bis die Migration erfolgreich durchgeführt bzw. rückgängig gemacht wurde.
- Wenn Sie aufgrund eines unerwarteten Rollbacks oder zum Anwenden von Fixes mehrere Migrationsversuche unternehmen, führen Sie den Befehl WASPreUpgrade erneut aus, damit alle Änderungen an Ihren isolierten Datenrepositorys in der migrierten Umgebung übernommen werden.
- Vergewissern Sie sich vor der Migration einer Apache Derby-Datenbank, dass alle Anwendungsserver mit Anwendungen, die die Apache Derby-Datenbank verwenden, geschlossen wurden. Andernfalls schlägt die Apache Derby-Migration fehl.
- Beachten Sie die folgenden Regeln bei der Migration von Sicherheitsdomänen:
- Wenn Sie einen Deployment Manager migrieren, der eine Sicherheitsdomäne auf Zellenebene besitzt, führen die Migrationstools die folgenden Aktionen aus:
- Der Migrationsprozess erstellt eine Domäne mit dem Namen PassThroughToGlobalSecurity in der neuen Konfiguration, falls diese noch nicht vorhanden ist.
- Der Migrationsprozess fügt der neuen Konfiguration eine Clusterzuordnung für alle Cluster aus der alten Konfiguration hinzu.
- Die Zuordnungen der Cluster, die nur in der Deployment-Manager-Konfiguration von Version 9.0
vor der Migration enthalten waren, werden nicht in "PassThroughToGlobalSecurity" geändert.
- Wenn Zuordnungen für die Cluster von Version 9.0 vor der Migration vorhanden waren, sind sie nach der Migration weiterhin vorhanden.
- Wenn keine Zuordnungen für die Cluster von Version 9.0 vor der Migration vorhanden waren, sind sie nach der Migration auch weiterhin nicht vorhanden.
- Wenn ein Cluster in der früheren Konfiguration und in der Konfiguration von Version 9.0 vor der Migration vorhanden ist, wird der Cluster in der neuen Konfiguration der Domäne "PassThroughToGlobalSecurity" hinzugefügt und verhält sich wie der Cluster im früheren Release.
- Die Zuordnungen der Cluster, die nur in der Deployment-Manager-Konfiguration von Version 9.0
vor der Migration enthalten waren, werden nicht in "PassThroughToGlobalSecurity" geändert.
- Der Migrationsprozess fügt eine Buszuordnung für alle Busse hinzu, die in einer migrierten Konfiguration von Version
6.1.x enthalten sind.
Die Aktualisierung der Buszuordnungen erfolgt nach denselben Regeln wie für die Clusterzuordnung.
- Verwaltungsserver (Deployment Manager) werden der Domäne "PassThroughToGlobalSecurity" nicht hinzugefügt.
- Wenn Sie einen eingebundenen Knoten migrieren, der eine Sicherheitsdomäne auf Zellenebene besitzt, führen die Migrationstools die folgenden Aktionen aus:
- Der Migrationsprozess erstellt eine Domäne mit dem Namen PassThroughToGlobalSecurity in der neuen Konfiguration, falls diese noch nicht vorhanden ist.
- Der Migrationsprozess fügt für alle clusterunabhängigen Server in der Konfiguration des alten Knotens
eine Zuordnung auf Serverebene zur Domäne "PassThroughToGlobalSecurity" hinzu.
- Für Server auf dem zu migrierenden Knoten, die zu einem Cluster gehören, werden keine Einträge in der Domäne "PassThroughToGlobalSecurity" vorgenommen, weil dies
bereits über eine Clusterzuordnung während der Migration des Deployment Manager erfolgt ist.
Wenn Sie diese Zuordnung entfernt haben, behält der Migrationsprozess dieses Verhalten bei.
- Verwaltungsserver (Node Agents) werden der Domäne "PassThroughToGlobalSecurity" nicht hinzugefügt.
- Für Server auf dem zu migrierenden Knoten, die zu einem Cluster gehören, werden keine Einträge in der Domäne "PassThroughToGlobalSecurity" vorgenommen, weil dies
bereits über eine Clusterzuordnung während der Migration des Deployment Manager erfolgt ist.
Weitere Informationen finden Sie im Abschnitt "Sicherheitsdomänen in einer heterogenen Umgebung" des Artikels Mehrere Sicherheitsdomänen im Information Center.
- Wenn Sie einen Deployment Manager migrieren, der eine Sicherheitsdomäne auf Zellenebene besitzt, führen die Migrationstools die folgenden Aktionen aus:
- Der Prozess, mit dem die Aufforderung zur Eingabe von Berechtigungsnachweisen inaktiviert wird, hat sich geändert.
Wenn Sie die Aufforderung zur Eingabe von Berechtigungsnachweisen in Version 9.0 inaktivieren möchten, konfigurieren Sie "ipc.client.props" entsprechend, bevor Sie eine Migration von Version 6.1 auf Version 9.0 durchführen.
- Während der Migration können einige Anwendungsmetadaten auf die Standardwerte zurückgesetzt werden
und dazu führen, dass sich die Anwendung anders als erwartet verhält.
Wenn Sie eine Anwendung in Ihrer alten Umgebung mit ausgewählter Einstellung Metadaten aus Binärdateien verwenden installiert und während dieser Installation oder einer nachfolgenden Aktualisierung der Anwendung eine Änderung an den Metadaten der Anwendung (z. B. an den JNDI-Ressourcenreferenzen oder Datenbankeinträgen) vorgenommen haben, kann die Änderung bei der Migration verloren gehen.
Wenn die Einstellung Metadaten aus Binärdateien verwenden ausgewählt ist, aktualisiert der Verwaltungscode nur die Metadaten in der binären EAR-Datei. Diese Option wird in einer heterogenen Zelle nicht unterstützt und deshalb automatisch während der Migration abgewählt. In diesem Fall haben die erweiterten Metadaten in den Konfigurationsverzeichnissen Vorrang vor den Werten in der binären EAR-Datei. Dies bewirkt, dass die Werte aus der Installation der ursprünglichen EAR-Datei Vorrang vor allen anderen Aktualisierungen haben, die Sie möglicherweise vorgenommen haben.
Führen Sie eine der folgenden Aktionen aus, um dieses Problem zu lösen:- Aktualisieren Sie Ihre Anwendungen in der alten Umgebung vor der Migration und wählen Sie die Einstellung Metadaten aus Binärdateien verwenden ab. Stellen Sie sicher, dass die Anwendung mit der neuen Einstellung ordnungsgemäß funktionieren, und führen Sie dann die Migration durch.
- Nach der Migration aktualisieren Sie Ihre Anwendungen und korrigieren die Metadaten bei Bedarf, um eine ordnungsgemäße Funktionsweise der Anwendungen zu ermöglichen.
- Nachdem Sie mit den Migrationstools die Migration auf WebSphere Application Server
Version 9.0
durchgeführt haben, müssen Sie unter Umständen einige Aktionen ausführen, die
von den Migrationstools nicht automatisch ausgeführt werden.
- Überprüfen Sie alle
LTPA-Sicherheitseinstellungen, die Sie möglicherweise in WebSphere Application Server
Version 7.0 oder höher
verwendet haben, und stellen Sie sicher, dass die Sicherheit in
Version 9.0 ordnungsgemäß konfiguriert ist.
Nähere Informationen finden Sie im Artikel Lightweight Third Party Authentication.
- Durchsuchen Sie die Datei WASPostUpgrade.log im Verzeichnis logs
nach Einzelheiten zu JSP-Objekten (JavaServer Pages), die von den Migrationstools nicht migriert wurden.
Wenn Version 9.0 eine Ebene, für die JSP-Objekte konfiguriert sind, nicht unterstützt, erkennen die Migrationstools die Objekte in der Ausgabe und protokollieren sie.
- Überprüfen Sie die Ergebnisse der automatischen Migration der Apache Derby-Datenbank und migrieren Sie manuell alle
Apache Derby-Datenbanken, die von den Tools nicht automatisch migriert wurden.
Weitere Informationen finden Sie im Artikel Apache Derby-Datenbanken migrieren.
- Überprüfen Sie alle
LTPA-Sicherheitseinstellungen, die Sie möglicherweise in WebSphere Application Server
Version 7.0 oder höher
verwendet haben, und stellen Sie sicher, dass die Sicherheit in
Version 9.0 ordnungsgemäß konfiguriert ist.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-iseries&topic=cmig_pre
Dateiname:cmig_pre.html