WebSphere Enterprise Service Bus, Version 6.2.0 Betriebssysteme: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Konfigurationszuordnung während der Migration der Produktkonfiguration

Bei der Migration der Produktkonfiguration werden diverse Konfigurationen einander zugeordnet.

Bei der Migration wird immer ein einzelnes Profil in ein anderes einzelnes Profil auf demselben oder einem anderen System migriert. Beispiele hierfür sind die Migration eines Deployment Managers von WebSphere ESB Version 6.1 auf ein Deployment Manager-Profil der Version 6.2 oder die Migration eines eigenständigen Serverprofils der Version 6.1 in ein eigenständiges Serverprofil der Version 6.2.
Anmerkung: Nur ein eigenständiges Serverprofil kann auf ein anderes System migriert werden.

Es sind zahlreiche Migrationsszenarios möglich. Die Migrationstools ordnen Objekte und Attribute der zu migrierenden Version den entsprechenden Objekten und Attributen in der Umgebung der neuen Version zu.

Bootstrap-Port
Die Migrationstools ordnen einen vom Standardwert abweichenden Wert direkt in der Version 6.2-Umgebung zu. bei der Migration von Version 6.0.2.x erhält bei Angabe des Parameters -portBlock während des Aufrufs von WBIPostUpgrade jeder Server, der auf Version 6.2 wird, einen neuen Portwert.
Befehlszeilenparameter

Die Migrationstools konvertieren geeignete Befehlszeilenparameter in die entsprechenden JVM-Einstellungen (JVM = Java™ Virtual Machine) in der Serverprozessdefinition. Die meisten Einstellungen werden direkt zugeordnet. Einige Einstellungen können nicht migriert werden, weil ihre Aufgabenbereiche in der Konfiguration von WebSphere ESB Version 6.2 nicht existieren oder andere Bedeutungen oder Geltungsbereiche besitzen.

Informationen zum Ändern der Einstellungen von Prozessdefinitionen finden Sie unter Einstellungen für Prozessdefinitionen im WebSphere Application Server Network Deployment, Version 6.1 Information Center. Informationen zum Ändern der Java Virtual Machine-Einstellungen finden Sie in dem Abschnitt für Java Virtual Machine-Einstellungen im Information Center von WebSphere Application Server Network Deployment, Version 6.1.

Java-Heapspeichergröße für die Migration von EAR-Dateien

Bei der Migration der EAR-Dateien von WebSphere ESB mit dem Tool wsadmin auf Version 6.2 verwendet das Tool WBIPostUpgrade die standardmäßige maximale Java-Heapspeichergröße von 64 MB, um die EAR-Dateien zu installieren.

Wenn eine EAR-Datei während der Migration nicht installiert werden kann, weil die Größe des Java-Heapspeichers nicht ausreicht, wird eine Nachricht wie die folgende angezeigt:
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError 

Erhöhen Sie die maximale Java-Heapgröße, und verwenden Sie das nachfolgende Beispiel, um die Anwendung zu installieren.

Beispiel für die Installation einer Anwendung auf WebSphere ESB Version 6.2

Voraussetzungen:
Installationsstammverzeichnis
C:\WebSphere\DeploymentManager
Nummernzeichen (###)
Der Wert für maximale Heapspeichergröße.
<EAR_dateiname>
Der Name der EAR-Datei.
anwendungsname
Der Name der Anwendung.
clustername
Der Name des Clusters, in dem die EAR-Datei installiert werden soll.
Der Befehl wird zur besseren Übersicht in mehreren Zeilen dargestellt.
wsadmin -conntype NONE
        -javaoption 
        -Xmx###m 
        -c "$AdminApp install 
            C:\\WebSphere\\ProcServer
                   <EAR_dateiname> 
        {-nodeployejb 
         -appname anwendungsname 
         -cluster clustername}"
Migration eines Knotens von Version 6.0.x oder 6.1.x auf Version 6.2

Sie können einen WebSphere ESB Version 6.0.x oder 6.1.x-Knoten, der zu einer Zelle gehört, auf WebSphere ESB Version 6.2 migrieren, ohne den Knoten aus der Zelle entfernen zu müssen.

Migrieren Sie zunächst den Deployment Manager, bevor Sie andere Basisknoten in der Zelle migrieren.

Verwenden Sie bei der Migration von Version 6.0.x oder 6.1.x auf Version 6.2 denselben Zellennamen. Wenn Sie einen anderen Zellennamen verwenden, können eingebundene Knoten nicht erfolgreich in die Zelle der WebSphere ESB Version 6.2 migriert werden.

Wenn Sie einen Basisknoten von WebSphere ESB, der sich in einer Zelle befindet, auf Version 6.2 migrieren, wird der Knotenagent ebenfalls auf Version 6.2 migriert.

eine Zelle kann unterschiedliche (heterogene) Knoten enthalten, d. h. sie kann Knoten der Version 6.2 und gleichzeitig auch Knoten der Version 6.1.x enthalten.
Anmerkung: Gemischte (heterogene) Knoten werden nicht unterstützt, wenn die Migration von Version 6.0.2.x erfolgt.
Richtliniendatei
WebSphere ESB Version 6.2 migriert alle mit Version 6.0.x oder 6.1.x installierten Richtliniendateien. Dabei gelten folgende Richtlinien:
  • Alle Kommentare in der Richtliniendatei der Version 6.2 werden beibehalten. Kommentare, die sich in der Richtliniendatei der Version 6.0.x oder 6.1.x befinden, werden nicht in Version 6.2 übernommen.
  • Die Migration fasst keine Berechtigungen oder Grants zusammen; sie erfolgt als reine Hinzufügeoperation. Falls eine Berechtigung oder ein Grant in der Datei der Version 6.2 fehlt, wird die Berechtigung bzw. der Grant bei der Migration übernommen.
  • Sicherheit ist ein wesentlicher Aspekt; aus diesem Grund werden sämtliche Informationen am Ende der ursprünglichen Datei .policy (nach dem Kommentar MIGR0372I: Migrated grant permissions follow) eingefügt. Dies geschieht, damit Administratoren die bei der Migration vorgenommenen Änderungen an der Richtliniendatei leichter nachvollziehen können.
Merkmale und Verzeichnisse lib/app

Bei der Migration werden Dateien aus Verzeichnissen der früheren Version in die Konfiguration von WebSphere ESB Version 6.2 kopiert.

Merkmaldateien

WebSphere migriert alle Merkmaldateien, die mit Version 6.0.x oder 6.1.x installiert werden, indem es die Einstellungen in den Merkmaldateien der Version 6.2 zusammenführt.

Bei der Migration werden keine Merkmaldateien überschrieben.

RAR-Archive, die von J2C-Ressourcen referenziert werden

RAR- und JAR-Dateien, die von J2C-Ressourcen referenziert werden, werden folgendermaßen migriert:

Ressourcen auf Clusterebene migrieren

Ressourcen auf Clusterebene werden in den Dateien mit dem Namen resourcexxx.xml konfiguriert, die sich in den Clusterverzeichnissen befinden. Beispiel:
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" 
  name="ims" archivePath="${WAS-INSTALLATIONSSTAMMVERZEICHNIS}\installedConnectors\x2.rar">
  ...
</resources.j2c:J2CResourceAdapter>

Wenn Sie eine Ressource auf Clusterebene besitzen, muss sich diese auf allen Cluster-Membern (Knoten) im gleichen Verzeichnis befinden. Im obigen Beispiel muss sich die RAR-Datei demzufolge auf allen Cluster-Membern im folgenden Verzeichnis befinden: ${WAS-INSTALLATIONSSTAMMVERZEICHNIS}\installedConnectors\x2.rar. Die Variable ${WAS-INSTALLATIONSSTAMMVERZEICHNIS} wird auf den einzelnen Cluster-Membern in das jeweils zutreffende Verzeichnis aufgelöst.

Bei der Migration eines Deployment Managers migrieren die Tools die Clusterdateien auf dem Deployment Manager; dies beinhaltet auch die Dateien 'resourcexxx.xml'.

Bei der Migration eines verwalteten Knotens verarbeiten die Tools alle J2C-Adapter. Dateien wie zum Beispiel RAR-Dateien werden wie folgt von Version 6.0.x oder 6.1.x auf Version 6.2 migriert:
  • Migration von Version 6.0.2.x auf Version 6.2: Bei der Migration werden Dateien wie zum Beispiel RAR- oder JAR-Dateien aus dem Verzeichnis WAS-INSTALLATIONSSTAMMVERZEICHNIS in das Verzeichnis WAS-INSTALLATIONSSTAMMVERZEICHNIS und aus dem Verzeichnis BENUTZERINSTALLATIONSSTAMMVERZEICHNIS in das Verzeichnis BENUTZERINSTALLATIONSSTAMMVERZEICHNIS kopiert.
  • Migration von Version 6.1.x auf Version 6.2: Bei der Migration werden Konfigurationsdateien wie folgt kopiert:
    • Wenn Sie RAR- oder JAR-Dateien im Rahmen der WebSphere ESB-Installation installieren, werden die Konfigurationsdateien auf das Migrationszielprofil migriert und so aktualisiert, dass sie auf die neue Version der RAR- und JAR-Dateien verweisen.
    • Wenn Sie RAR- oder JAR-Dateien nach der Installation von WebSphere ESB installieren, geschieht Folgendes:
      • Wenn die Installation der RAR- oder JAR-Dateien unter der Vorgängerinstallation von WebSphere ESB erfolgt, werden lediglich die Konfigurationsdateien migriert. Sie müssen diese RAR- oder JAR-Dateien kopieren oder auf dem Migrationszielprofil installieren und vor dem Starten des Servers sicherstellen, dass die Konfiguration korrekt ist.
      • Wenn die Installation der RAR- oder JAR-Dateien außerhalb der Vorgängerversion von WebSphere ESB wie empfohlen erfolgt, werden die Konfigurationsdateien migriert. Nach der Migration müssen daher keine weiteren Maßnahmen ergriffen werden.

Wenn Sie einen Pfad zu einer RAR-Datei in Version 6.0.x oder 6.1.x fest codiert haben (z. B. archivePath="C:/WAS/installedConnectors/x2.rar") können die Migrationstools der Version 6.2 das Attribut archivePath nicht entsprechend ändern, da hierdurch alle Cluster-Member ungültig würden, die nicht migriert wurden.

Beispiele

Bei der Migration eines eigenständigen Profils werden keine WebSphere ESB-Beispiele migriert. Für alle Beispiele der Version 6.2 stehen der Version 6.2 funktional entsprechende Beispiele zur Verfügung.

Sicherheit
Anmerkung: Die folgenden Sicherheitsinformationen gelten nur für die Migration von Version 6.0.2.x

Wenn Sie die Sicherheit in WebSphere ESB Version 6.2 aktivieren, wird standardmäßig die Java 2-Sicherheit aktiviert. Die Java 2-Sicherheit erfordert das explizite Erteilen von Sicherheitsberechtigungen.

Es gibt mehrere Verfahren, um unterschiedliche Java 2-Sicherheitsebenen in Version 6.2 zu definieren. Das eine Verfahren besteht darin, eine Datei was.policy innerhalb der Anwendung zu erstellen, um alle Sicherheitsberechtigungen zu aktivieren. Die Migrationstools rufen den Befehl wsadmin auf, um eine bestehende Datei was.policy im Verzeichnis properties von Version 6.2 zu Enterprise-Anwendungen, die gerade migriert werden, hinzuzufügen.

Bei der Migration von WebSphere ESB Version 6.0.2.x auf Version 6.2 führt Ihre Entscheidung, die Migration wahlweise mit oder ohne Unterstützung der Scriptkompatibilität zu migrieren, zu zwei unterschiedlichen Ergebnissen.
  • Wenn Sie sich für die Migration mit Unterstützung für Scriptkompatibilität entscheiden, wird Ihre Sicherheitskonfiguration unverändert in Version 6.2 übernommen.

    Hierbei handelt es sich um die Standardeinstellung.

  • Wenn Sie sich für die Migration ohne Unterstützung für Scriptkompatibilität entscheiden, wird die Sicherheitskonfiguration in die Standardkonfiguration für WebSphere ESBVersion 6.2 konvertiert. Die standardmäßige Sicherheitskonfiguration für Version 6.2 enthält einige Änderungen gegenüber früheren Versionen, verhält sich jedoch weitestgehend identisch.

    Zum Bespiel wurden vorhandene Schlüsseldateien und Trust-Dateien aus dem SSLConfig-Repertoire entfernt und neue Keystore- und Truststore-Objekte erstellt.

Damit die Sicherheitseinstellungen beibehalten werden können, müssen Sie die Sicherheitseinstellungen von WebSphere Application Server migrieren, die für Version 6.0.2.x festgelegt wurden. Informationen zur Migration von Sicherheitskonfigurationen auf Version 6.2 finden Sie unter Migration, Koexistenz und Interoperabilität - Sicherheitsaspekte im WebSphere Application Server Network Deployment, Version 6.1 Information Center.

Standardeingabe, Standardausgabe, Standardfehler, Auslagerungs- und Arbeitsverzeichnisse

Diese Verzeichnisse befinden sich normalerweise unterhalb des Installationsverzeichnisses einer früheren Version. Das Standardverzeichnis für stdin, stdout und stderr ist das Verzeichnis logs des Installationsstammverzeichnisses von WebSphere ESB Version 6.2.

Die Migrationstools versuchen, vorhandene Auslagerungs- und Arbeitsverzeichnisse zu migrieren. Andernfalls werden geeignete Standardwerte für Version 6.2 verwendet.

Weitere Informationen zu Auslagerungsverzeichnissen finden Sie unter Einstellungen für EJB-Container. Weitere Informationen zu Arbeitsverzeichnissen enthält der Artikel Einstellungen für Prozessdefinitionen.

In einem Koexistenzszenario kann die gemeinsame Verwendung von Verzeichnissen für verschiedene Versionen zu Problemen führen.

Transportports

Die Migrationstools migrieren sämtliche Ports. Die Tools protokollieren eine Warnung, wenn ein Portkonflikt auftritt, weil ein Port in der Konfiguration bereits definiert ist. Sie müssen alle Portkonflikte auflösen, bevor mehrere Server zur gleichen Zeit ausgeführt werden können.

Bei Angabe des Parameters -portBlock im Befehl WBIPostUpgrade wird jedem migrierten Transport ein neuer Wert zugewiesen.

Weitere Informationen zum Befehl WBIPostUpgrade finden Sie in Befehlszeilendienstprogramm 'WBIPostUpgrade'.

Weitere Informationen zu Transportketten und Kanälen finden Sie im Artikel Transportketten konfigurieren.

Aliasnamenseinträge für virtuelle Hosts müssen Sie für jeden Port manuell hinzufügen. Weitere Informationen finden Sie im Artikel Virtuelle Hosts konfigurieren.

Webmodule

Für die in WebSphere ESB Version 6.0.x oder 6.1.x implementierte J2EE-Spezifikationsstufe (J2EE = Java 2 Platform, Enterprise Edition) musste das Verhalten des Web-Containers in Bezug auf die Festlegung des Inhaltstyps geändert werden. Wenn ein standardmäßiger Servlet-Writer den Inhaltstyp nicht festlegt, wird dieser nicht mehr als Standardwert für den Web-Container verwendet und der Web-Container gibt den Aufruf als "null" zurück. Diese Situation kann in einigen Browsern dazu führen, dass nachfolgende Web-Container-Tags nicht ordnungsgemäß angezeigt werden. Um dieses Problem zu vermeiden, wird bei der Migration von Enterprise-Anwendungen die IBM® Erweiterung autoResponseEncoding für Webmodule auf "true" festgelegt.


concept Konzeptabschnitt

Nutzungsbedingungen | Feedback


Zeitmarkensymbol Letzte Aktualisierung: 05 Juli 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/cmig_vtv_configmap.html
Copyright IBM Corporation 2005, 2010. Alle Rechte vorbehalten.
Dieses Information Center basiert auf Eclipse-Technologie (http://www.eclipse.org).