Bevor Sie mit der Migration auf eine neue Version von WebSphere ESB beginnen,
sollten Sie die folgenden Aspekte beachten.
Die folgenden Regeln, Einschränkungen und Hinweise gelten für die Migration und Koexistenz, wenn WebSphere ESB Version 6.2 installiert ist.
Installationsvoraussetzungen für WebSphere ESB
- WebSphere ESB Version 6.2
kann in einer Umgebung installiert werden, in der das Produkt mit vorherigen Versionen von WebSphere ESB
koexistiert.
Erweiterung
- Ein Profil der Version Version 6.0.2.x oder Version 6.1.x kann nur dann auf ein Profil der Version 6.2 migriert werden, wenn beide Profile dieselbe Erweiterungsebene aufweisen.
- Eine gemischte (heterogene) Zelle kann sowohl erweiterte als auch nicht erweiterte verwaltete Knoten enthalten, sofern der Deployment Manager auf die höchste Erweiterungsebene erweitert wurde, die seine verwalteten Knoten aufweisen. Wird ein Deployment Manager beispielsweise für WebSphere ESB erweitert, kann er erfolgreich Knoten verwalten, die für WebSphere ESB und WebSphere Application Server erweitert wurden. Ein Deployment Manager, der lediglich für WebSphere Application Server erweitert wurde, kann jedoch nur WebSphere Application Server-Knoten verwalten.
Cluster
- Auf den Membern eines Clusters können nicht unterschiedliche Versionen (6.0.2.x, 6.1.x, 6.2) von WebSphere ESB ausgeführt werden. Wenn Sie einen Cluster konfiguriert haben, der Server enthält, auf denen jeweils unterschiedliche Versionen ausgeführt werden, so müssen Sie zuerst alle Member stoppen, auf denen ältere Versionen von WebSphere ESB ausgeführt werden, bevor Sie das erste Cluster-Member der Version 6.2 starten.
Sobald Sie ein Cluster-Member der Version 6.2 gestartet haben, dürfen Sie keine anderen Cluster-Member von Version 6.0.x oder 6.1.x in diesem Cluster starten.
Datenbanken
- Bevor Sie eine Cloudscape- oder Derby-Datenbank migrieren, müssen Sie sicherstellen, dass alle Server heruntergefahren werden, die per Hosting Anwendungen bereitstellen, die diese Cloudscape-Datenbank verwenden. Andernfalls schlägt die
Cloudscape-Migration
fehl.
HTTP-Transport
Bei der Migration von
WebSphere ESB Version 6.0.2.x werden HTTP-Transporte in Web-Container-Transportketten vom Typ Channel Framework konvertiert.
Anmerkung: Dies gilt nur für Migrationen von Version 6.0.2.x.
Weitere Informationen zur Unterstützung von Transportmethoden bei
Version 6.2 enthalten die folgenden Abschnitte:
Java/JDK (Java Development Kit)
- Wenn Sie eine Migration von Version 6.0.2.x ausführen, sollten Sie, bevor Sie von JDK 1.4 auf JDK 5 migrieren (das ab WebSphere Application Server Version
6.1 und somit ab WebSphere ESB Version 6.2 eingeführt würde), anhand der Java™-Spezifikation von Sun Microsystems prüfen, ob Änderungen an Ihren Anwendungen vorgenommen werden müssen.
Anmerkung: Diese Task ist nicht erforderlich, wenn Sie von Version 6.1.x migrieren.
Weitere Informationen finden Sie im Artikel
API- und Spezifikationsmigration.
- Wenn Sie eine Zelle mit mehreren Knoten migrieren, müssen die Anwendungen so lange auf der
niedrigsten JDK-Version verbleiben, bis alle Knoten migriert wurden.
Wichtig: Stellen Sie
sicher, dass alle für die einzelnen Server angegebenen generischen JVM-Parameter
(JVM = Java Virtual Machine) mit der neuen Java-Version kompatibel sind. Entfernen
Sie die Parameter, wenn sie nicht kombatibel sind.
Prüfen Sie, ob andere JVM-bezogene Anwendungen (z. B. Wily Agents) an die neue
Java-Version angepasst werden müssen. Inaktivieren Sie die betreffenden Anwendungen
vor der Migration und aktivieren Sie sie nach erfolgter Migration.
JNI (Java Native Interface)
JNI-Anwendungen (JNI = Java Native
Interface), die mit WebSphere ESB Version
6.0.2 auf Systemen mit Solaris x64 ausgeführt werden, müssen in einer 64-Bit-Umgebung erneut kompiliert werden, damit sie mit WebSphere ESB Version 6.2 zusammenarbeiten. Dazu zählen alle JNI-Anwendungen, die in einem
WebSphere ESB-Prozess ausgeführt werden
— wie z. B. Code, der in einer Enterprise JavaBean (EJB) aufgerufen wird. Auf Systemen mit
Solaris x64 wird WebSphere ESB Version
6.0.2 auch dann als 32-Bit-Anwendung ausgeführt, wenn die zugrunde liegende Plattform eine
64-Bit-Architektur aufweist. Dies liegt daran, dass die zugrunde liegende Java-VM (Java Virtual Machine)
eine 32-Bit-Version ist. WebSphere ESB Version 6.2 wird als 64-Bit-Anwendung ausgeführt, weil die zugrunde liegende JVM (JVM = Java Virtual Machine) eine 64-Bit-Version ist. JNI-Anwendungen, die in einer 32-Bit-Umgebung für Version 6.0.2 kompiliert wurden, können in der 64-Bit-Umgebung von Version 6.2 nicht ausgeführt werden.
Rollback von Umgebungen durchführen
- Wenn Sie einen Knoten auf WebSphere ESB Version 6.2 migrieren und im weiteren Verlauf feststellen, dass Sie das System auf Version 6.0.x oder 6.1.x zurücksetzen müssen, lesen Sie die Informationen unter Rollback der Umgebung durchführen.
Speicher
- Der erforderliche Speicherplatz, den Ihr System für die Migration auf Version 6.2 benötigt, hängt sowohl von Ihrer Umgebung als auch vom verwendeten Migrationstool ab.
- Speicherbedarf für WBIPreUpgrade
- Verzeichnis: Das Sicherungsverzeichnis, das als Parameter für den Befehl WBIPreUpgrade angegeben wurde.
- Speicherbedarf: Sie erhalten eine grobe Schätzung des Speicherbedarfs für diesen Befehl,
indem Sie folgende Größen addieren.
- Größe der folgenden Elemente für alle Profile von WebSphere ESB oder WebSphere Application Server in der alten Konfiguration:
- Verzeichnis profilstammverzeichnis/installableApps
- Verzeichnis profilstammverzeichnis/installedApps
- Verzeichnis profilstammverzeichnis/config
- Verzeichnis profilstammverzeichnis/properties
- Gemeinsam genutzte Bibliotheken, die den Konfigurationsdateien libraries.xml referenziert werden
- RAR-Dateien (RAR = Resource Adapter Archive), die in den Konfigurationsdateien resources.xml referenziert werden
- Bei aktiviertem Trace (Standardeinstellung) bis zu 200 MB (abhängig von Größe und Komplexität Ihrer Konfiguration)
Weitere Informationen zu diesem Befehl finden Sie unter Befehlszeilendienstprogramm 'WBIPreUpgrade'.
- Speicherbedarf für WBIPostUpgrade
- Verzeichnis: Neue Konfiguration relativ zum Verzeichnis profilstammverzeichnis.
- Speicherbedarf: Sie erhalten eine grobe Schätzung des Speicherbedarfs für diesen Befehl,
indem Sie folgende Größen addieren.
- Größe der folgenden Elemente für das alte Profil von WebSphere ESB oder WebSphere Application Server, das Sie migrieren:
- Verzeichnis profilstammverzeichnis/installableApps
- Verzeichnis profilstammverzeichnis/installedApps
- Verzeichnis profilstammverzeichnis/config
- Verzeichnis profilstammverzeichnis/properties
- Gemeinsam genutzte Bibliotheken, die den Konfigurationsdateien libraries.xml referenziert werden
- RAR-Dateien (RAR = Resource Adapter Archive), die in den Konfigurationsdateien resources.xml referenziert werden
- Bei aktiviertem Trace (Standardeinstellung) bis zu 200 MB (abhängig von Größe und Komplexität Ihrer Konfiguration)
Weitere Informationen zu diesem Befehl finden Sie unter Befehlszeilendienstprogramm 'WBIPostUpgrade'.

Einstellung 'ulimit'
- Um nach der Migration einen Fehler durch zu viele geöffnete Dateien zu vermeiden,
erhöhen Sie unbedingt den Wert für die Einstellung 'ulimit'. Anweisungen zum Erhöhen der Einstellung
für 'ulimit' enthält der Abschnitt Linux-Systeme vorbereiten.