Hinweise zur Migration

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

Unterstützte Konfigurationen Unterstützte Konfigurationen:

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.

sptcfg

Hinweise 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.
  • 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.
    Nach Abschluss der Migration oder nach einem Rollback auf die frühere Version können Sie die Server erneut starten, die mit diesen isolierten Datenrepositorys interagieren.
  • 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.
      • 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.

    Weitere Informationen finden Sie im Abschnitt "Sicherheitsdomänen in einer heterogenen Umgebung" des Artikels Mehrere Sicherheitsdomänen im Information Center.

  • 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.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-iseries&topic=cmig_pre
Dateiname:cmig_pre.html