Konfigurationszuordnung während der Migration der Produktkonfiguration

Bei der Migration der Produktkonfiguration werden verschiedene Konfiguration zugeordnet.

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

Bei der Migration wird immer ein einzelnes Profil auf ein anderes einzelnes Profil auf demselben IBM i-Server kopiert. Die Migrationstools ordnen Objekte und Attribute, die in der Version, von der Sie die Migration durchführen, vorhanden sind, den entsprechenden Objekten und Attributen in der Umgebung mit Version 9.0 zu.

Es sind zahlreiche Migrationsszenarien möglich. Die Migrationstools ordnen Objekte und Attribute, die in der Version, von der Sie die Migration durchführen, vorhanden sind, den entsprechenden Objekten und Attributen in der Umgebung mit Version 9.0 zu.

Bootstrap-Port

Die Migrationstools übertragen den Wert aus dem alten Release in die Umgebung mit Version 9.0.

Wenn für den Parameter -setPorts während des Aufrufs von WASPostUpgrade der Wert generateNew oder ein Portwert festgelegt wird, wird der Portwert aber jedem Anwendungsserver zugeordnet, der auf Version 9.0 migriert wird.

Befehlszeilenparameter

Die Migrationstools konvertieren entsprechende Befehlszeilenparameter in JVM-Einstellungen (Java™ Virtual Machine) in der Serverprozessdefinition. Die meisten Einstellungen werden direkt zugeordnet. Einige Einstellungen werden nicht migriert, weil keine entsprechenden Rollen in der Konfiguration von WebSphere Application Server Version 9.0 vorhanden sind, die Einstellungen eine andere Bedeutung haben oder anderen Geltungsbereichen zugewiesen sind.

Informationen zum Ändern der Prozessdefinitionseinstellungen finden Sie im Artikel Einstellungen für Prozessdefinition im Information Center. Informationen zum Ändern der JVM-Einstellungen finden Sie unter Java virtual machine settings.

Generischer Server
In Version 7.0 oder höher hat ein generischer Server einen eigenen Typ mit dem Namen GENERIC_SERVER. Bei der Migration wird diese Konvertierung zwar durchgeführt, aber die externen Ressourcen auf die der generische Server verweist, können nicht exakt migriert werden. Nach der Migration der Einstellungen für den generischen Server müssen Sie zusätzliche Aktionen ausführen. Falls die alte Ressource, die der generische Server verwaltet hat, nicht in der alten Installation von WebSphere Application Server enthalten ist, führen Sie die folgenden Aktionen aus:
  1. Kopieren Sie alle zugehörigen Dateien in die neue Installation.
  2. Führen Sie alle erforderlichen Konfigurationsschritte für die externe Anwendung aus, damit sie wieder funktioniert.

    Es empfiehlt sich, die Ressource im neuen Verzeichnis von WebSphere Application Server erneut zu installieren. In jedem Fall muss im letzten Schritt die Referenz auf die neue Position der Anwendung eingestellt werden.

Falls die alte Ressource, die der generische Server verwaltet hat, nicht in der alten Installation von WebSphere Application Server enthalten ist, sind keine weiteren Aktionen erforderlich.

Migration eines Knotens mit Version 7.0 oder höher auf einen Knoten mit Version 9.0

Sie können einen Knoten mit WebSphere Application Server Version 7.0 oder höher, der zu einer Zelle gehört, migrieren, ohne den Knoten aus der Zelle zu entfernen.

Migrieren Sie zuerst den Deployment Manager, bevor Sie in der Zelle Basisknoten migrieren.

Wichtig: Verwenden Sie denselben Zellennamen, wenn Sie WebSphere Application Server Network Deployment von Version 7.0 oder höher auf Version 9.0 migrieren. Sollten Sie einen anderen Zellennamen verwenden, können eingebundene Knoten nicht erfolgreich in die Zelle mit WebSphere Application Server Network Deployment Version 9.0 migriert werden.

Wenn Sie einen Knoten mit dem Basisprodukt WebSphere Application Server, der in eine Zelle eingebunden ist, auf Version 9.0 migrieren, wird auch der Node Agent auf Version 9.0 migriert. Eine Zelle kann einige Knoten mit Version 9.0 und einige Knoten mit Version 7.0 oder höher enthalten.

Richtliniendateien
Beim Migrieren aller Richtliniendateien, die in Version 7.0 oder höher installiert sind, kopiert WebSphere Application Server Version 9.0 die Einstellungen wie folgt in die Richtliniendateien von Version 9.0:
  • Alle Kommentare in den Richtliniendateien von Version 9.0 bleiben erhalten. Alle Kommentare, die in den Richtliniendateien von Version 7.0 oder höher enthalten sind, gehen in der Datei von Version 9.0 verloren.
  • Bei der Migration wird nicht versucht, Berechtigungen oder grant-Berechtigungen zu mischen. Es werden nur Einstellungen hinzugefügt. Sollte eine Berechtigung oder eine grant-Berechtigung nicht in der Datei von Version 9.0 enthalten sein, wird sie bei der Migration kopiert.
  • Die Sicherheit ist ein kritischer Faktor. Deshalb fügt das Migrationsprogramm alle Einträge am Ende der ursprünglichen Dateien mit der Erweiterung .policy direkt hinter dem Kommentar MIGR0372I: Informationen zu den migrierten grant-Berechtigungen folgen. hinzu. Auf diese Weise können Administratoren alle während der Migration vorgenommenen Änderungen in den Richtliniendateien sofort erkennen.
Eigenschafts- und Klassenverzeichnisse

Bei der Migration werden Dateien von Verzeichnissen der Vorversion in die Konfiguration von WebSphere Application Server Version 9.0 kopiert.

Eigenschaftendateien

Beim Migrieren aller Eigenschaftendateien, die in Version 7.0 oder höher installiert sind, kopiert WebSphere Application Server Version 9.0 die Einstellungen in die Eigenschaftendateien von Version 9.0.

Von J2C-Ressourcen referenzierte RAR-Dateien (Resource Adapter Archives)

Von J2C-Ressourcen referenzierte RAR-Dateien werden migriert, wenn diese RAR-Dateien in der früheren Installation von WebSphere Application Server enthalten sind. In diesem Fall werden die RAR-Dateien in das entsprechende Verzeichnis der neuen Installation von WebSphere Application Server kopiert. RAR-Dateien für relationale Ressourcenadapter werden nicht migriert.

Migration von Clusterressourcen:
WebSphere Application Server Version 6.0 hat das Konzept der Ressourcen auf Clusterebene eingeführt. Diese werden in Dateien des Typs resourcexxx.xml unterhalb der Clusterverzeichnisse. Beispiel:
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" 
  name="ims" archivePath="${WAS_INSTALL_ROOT}\installedConnectors\x2.rar">
  ...
</resources.j2c:J2CResourceAdapter>

Wenn Sie eine Ressource auf Clusterebene verwenden, muss diese Ressource sich in jedem Cluster-Member (Knoten) an derselben Position befinden. Im obigen Beispiel muss daher für jedes Cluster-Member die RAR-Datei im Verzeichnis ${WAS_INSTALL_ROOT}\installedConnectors\x2.rar installiert sein. ${WAS_INSTALL_ROOT} wird in jedem Cluster-Member zur exakten Position aufgelöst.

Bei der Migration eines Deployment Manager migrieren die Tools die Clusterdateien im Deployment Manager, einschließlich der Dateien des Typs resourcexxx.xml.

Bei der Migration eines eingebundenen Knotens verarbeiten die Tools jeden J2C-Adapter.

Migration von RAR-Dateien von Version 7.0 auf Version 9.0:

Bei der Migration von Version 7.0 auf Version 9.0 werden Dateien wie die RAR-Dateien von WAS_INSTALL_ROOT nach WAS_INSTALL_ROOT und von USER_INSTALL_ROOT nach USER_INSTALL_ROOT kopiert.

Wenn beispielsweise eine RAR-Datei im Verzeichnis WAS_INSTALL_ROOT für Version 7.0 vorhanden ist, kopieren die Migrationstools die Datei nicht automatisch von WAS_INSTALL_ROOT in USER_INSTALL_ROOT. Dadurch wird die Integrität der J2C-Ressourcen auf Clusterebene aufrechterhalten.

Wenn Sie einen Pfad zu einer RAR-Datei (z. B. archivePath="C:/WAS/installedConnectors/x2.rar") in Version 7.0 fest codiert haben, können die Migrationstools von Version 9.0 das Attribut "archivePath" nicht entsprechend ändern, da andernfalls alle anderen Cluster-Member, die nicht migriert wurden, beschädigt würden.
Beispiele

Die Beispiele aus früheren Versionen werden nicht migriert. Es gibt äquivalente Beispiele in WebSphere Application Server Version 9.0, die Sie installieren können.

Sicherheit

Die Java-2-Sicherheit ist standardmäßig aktiviert, wenn Sie die Sicherheit in WebSphere Application Server Version 9.0 aktivieren. Für die Java-2-Sicherheit müssen Sie explizit Sicherheitsberechtigungen erteilen.

Es gibt verschiedene Methoden, um unterschiedliche Ebenen der Java-2-Sicherheit in Version 9.0 zu definieren. Eine Methode besteht darin, die Datei was.policy als Teil der Anwendung zu erstellen, um alle Sicherheitsberechtigungen zu aktivieren. Die Migrationstools rufen den Befehl wsadmin auf, um bei der Migration von Unternehmensanwendungen eine vorhandene Datei was.policy zum Verzeichnis properties von Version 9.0 hinzuzufügen.

Wenn Sie eine Migration auf WebSphere Application Server Version 9.0 durchführen und dabei die Unterstützung der Scriptkompatibilität einschließen bzw. ausschließen möchten, führt das zu folgenden Ergebnissen.
  • Wenn Sie die Migration mit Unterstützung der Scriptkompatibilität durchführen möchten, wird Ihre Sicherheitskonfiguration ohne Änderungen nach Version 9.0 kopiert.

    Dies ist die Standardeinstellung.

  • Wenn Sie die Migration ohne Unterstützung der Scriptkompatibilität durchführen möchten, wird die Sicherheitskonfiguration in die Standardkonfiguration für WebSphere Application Server Version 9.0 konvertiert. Die Standardsicherheitskonfiguration für Version 7.0 oder höher funktioniert beinahe genauso wie in den früheren Versionen. Es gibt jedoch einige Änderungen.

    Beispielsweise werden vorhandene Schlüssel- und Trustdateien aus dem SSL-Konfigurationsrepertoire entfernt, und neue Keystore- und Truststore-Objekte werden erstellt.

Weitere Informationen zur Migration Ihrer Sicherheitskonfigurationen auf Version 9.0 finden Sie im Artikel "Sicherheitsaspekte bei Migration, Koexistenz und Interoperation" in der Dokumentation.

Verzeichnisse für stdin, stdout, stderr, Auslagerungs- und Arbeitsverzeichnis

In der Regel befinden sich diese Verzeichnisse im Verzeichnis logs unterhalb des Profilverzeichnisses von WebSphere Application Server. Standardmäßig werden Dateien aus stdin, stdout und stderr für WebSphere Application Server Version 9.0 im Verzeichnis logs des Profilverzeichnisses von WebSphere Application Server gespeichert. Das Protokollverzeichnis (logs) für das Standardprofil ist beispielsweise /QIBM/UserData/WebSphere/AppServer/V80/Base/profiles/default/logs.

Die Migrationstools versuchen, vorhandene Auslagerungs- und Arbeitsverzeichnisse zu migrieren. Andernfalls werden die entsprechenden Standardeinstellungen von Version 9.0 verwendet.

Fehler vermeiden Fehler vermeiden: Die Verwendung gemeinsamer Verzeichnisse durch verschiedene Versionen in einem Koexistenzszenario kann zu Problemen führen.gotcha
Webmodule

Die Spezifikationsstufe von Java Platform, Enterprise Edition (Java EE), die in WebSphere Application Server Version 7.0 implementiert ist, erfordert Verhaltensänderungen im Web-Container, damit der Inhaltstyp festgelegt werden kann. Wenn der Autor eines Standardservlets den Inhaltstyp nicht festlegt, kann der Web-Container keinen Standardinhaltstyp mehr festlegen. Außerdem gibt der Web-Container auf den Aufruf hin einen "Nullwert" zurück. Dies kann dazu führen, dass einige Browser die Tags des Web-Containers falsch anzeigen. Bei der Migration von Unternehmensanwendungen wird die IBM® Erweiterung "autoResponseEncoding" für Webmodule auf "true" gesetzt, um dieses Problem zu vermeiden.


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_configmap
Dateiname:cmig_configmap.html