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 z/OS

Lesen Sie die folgenden Informationen, bevor Sie WebSphere Application Server for z/OS migrieren:
  • Der Migrationsprozess gibt die Werte für benutzerdefinierte Variablen und Variablen, die von WebSphere Application Server definiert werden, gewöhnlich weiter. Im Folgenden sehen Sie eine Liste mit einigen speziellen Variablen, für die die Werte jedoch nicht weitergegeben werden:
    • WAS_INSTALL_ROOT
    • USER_INSTALL_ROOT
    • WAS_PRODUCT_ROOT
    • WAS_LIBS_DIR
    • WAS_PROPS_DIR
    • WAS_TEMP_DIR
    • APP_INSTALL_ROOT
    • DRIVER_PATH
    • WAS_INSTALL_LIBRARY
    • JAVA_HOME
    • DEPLOY_TOOL_ROOT
    • CONNECTOR_INSTALL_ROOT
    • TRANLOG_ROOT
    • MQJMS_LIB_ROOT
    • WAS_ETC_DIR
    • WEMPS_USER_ROOT
    • MQ_INSTALL_ROOT
    • WAS_DAEMON_ONLY_ICU_DATA
    • WAS_DAEMON_ONLY_CONFIG_ROOT
    • WAS_DAEMON_primordial_root
    • WAS_DAEMON_daemon_was_env_file
    Die Werte für diese Variablen werden der Profilschablone entnommen, wenn während der Migration Profile erstellt werden. Wenn Sie angepasste Werte für diese Variablen definiert haben, werden diese in dem Release von WebSphere Application Server, das das Migrationsziel ist, nicht übernommen. Diese Variablen werden nicht migriert, weil sie Eigenschaften von WebSphere Application Server sind, bei denen es sich um Profilattribute handelt. Wenn Sie die Werte dieser Variablen mit Einträgen überschreiben müssen, die vom Standard abweichen, müssen Sie die Werte außerhalb der Produktinstallations-, Profilerstellungs- und Migrationsprozesse ändern.
    Fehler vermeiden Fehler vermeiden: Beachten Sie insbesondere die Variable APP_INSTALL_ROOT. Selbst, wenn Sie für die Variable APP_INSTALL_ROOT eine angepasste Position definiert haben, installiert der Migrationsprozess Anwendungen standardmäßig an der folgenden Position:
    ${USER_INSTALL_ROOT}/installedApps
    gotcha
    Wenn der Migrationsprozess eine vom Standard abweichende Anwendungsinstallationsposition verwenden soll, müssen Sie die folgenden Aktionen ausführen:
    • Geben Sie die Position im Feld "Application Install Directory" von zMMT an.
    • Wählen Sie während der Migration die Option Anwendungen migrieren und das frühere Anwendungsinstallationsverzeichnis verwenden aus, damit der Installationspfad verwendet wird, ohne dass er erneut eingegeben werden muss. Wenn der Installationspfad für das frühere Release Variablenreferenzen enthält, löst WebSphere Application Server diese Variablen mit den migrierten Werten auf.
  • Nach der Installation von WebSphere Application Server Version 9.0 unter dem Betriebssystem z/OS empfiehlt es sich möglicherweise, eine vollständige WebSphere Application Server Network Deployment-Zellenkonfiguration zu erstellen und sich zu vergewissern, dass diese ordnungsgemäß funktioniert, bevor Sie versuchen, eine vorhandene Zelle oder einen vorhandenen Knoten zu migrieren.

    Damit stellen Sie sicher, dass Ihr System alle Voraussetzungen erfüllt und die neue Version des Produkts unterstützt.

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

  • Stellen Sie vor der Migration von WebSphere Application Server Version 7.0 oder höher auf Version 9.0 eine Verbindung zwischen der ID der Anwendungsservantregion und einem Schlüsselring her und vergewissern Sie sich, dass dem Schlüsselring das WebSphere-CA-Zertifikat zugeordnet ist. Andernfalls können Sicherheitsfehler auftreten, wenn die globale Sicherheit aktiviert ist.
  • WebSphere Application Server Version 7.0 oder höher stellt den High Availability Manager und die Stammgruppenfunktionalität bereit.

    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.

  • Wenn Sie einen IIOP-Client (Internet Inter-ORB Protocol) einer älteren Version als Version 6.1 ausführen möchten und dieser mit einem Server von Version 9.0 in derselben logischen Partition (LPAR) interagieren soll, muss die Prozedurenbibliothek für den Dämon von Version 9.0 die Bibliotheken SBBOLD2 und SBBOLPA des früheren Release in ihrer STEPLIB enthalten.
  • Damit die Migration unterstützt wird, müssen sich sowohl die Quellenkonfiguration als auch die Zielkonfiguration von WebSphere Application Server in derselben LPAR befinden.

    Aus diesem Grund können Sie keine vorhandene Konfiguration in eine andere z/OS-LPAR migrieren. Es ist außerdem nicht möglich, die Migration mit den Migrationsdienstprogrammen von WebSphere Application Server Version 9.0 von einem bzw. auf ein System mit einem anderen Betriebssystem als z/OS durchzuführen.

  • Die Migration von Zellen, die sich über mehrere Sysplex-Umgebungen oder Betriebssysteme erstrecken, sollte kein Problem darstellen. Sie migrieren auf Knotenebene und verwenden die Tools, die auf der Plattform des zu migrierenden Knotens bereitgestellt werden.

    Informationen zum Konfigurieren einer heterogenen Zelle, d. h. einer Zelle mit unterschiedlichen Plattformen, finden Sie im White Paper WebSphere for z/OS -- Heterogeneous Cells.

  • Die Befehlszeilentools WASPreUpgrade, WASPostUpgrade und manageprofiles, die von den verteilten Versionen und i5/OS-Versionen des Produkts unterstützt werden, werden von WebSphere Application Server unter dem Betriebssystem z/OS nicht unterstützt.

    Sie müssen die Migrationsjobs mit z/OS Migration Management Tool oder mit dem Befehl zmmt generieren, und sie anschließend gemäß den generierten Anweisungen übergeben.

  • Die Speichermenge, die Ihr System während der Migration auf Version 9.0 benötigt, hängt von Ihrer Umgebung ab.
    • Die Größe des Dateisystems wird mit dem Wert für die Zuordnung primärer Zylinder festgelegt, der mit z/OS Migration Management Tool oder mit dem Befehl zmmt bei der Generierung einer Migrationsdefinition angegeben wird. Außerdem ist dieses Dateisystem je nach Wert für die Zuordnung sekundärer Zylinder automatisch erweiterbar. Die von den Migrationstools bereitgestellten Standardwerte für diese Zuordnungen sind im Normalfall für die Konfigurationsdaten ausreichend.
    • Für das Migrationssicherungsverzeichnis ist ein beträchtlicher temporärer Speicherplatz erforderlich. Der genaue Speicherbedarf ist von verschiedenen Faktoren abhängig, aber 100 Zylinder reichen in den meisten Situationen (einschließlich Traceerstellung, sofern erforderlich) aus. Wenn Sie den für Ihr temporäres Verzeichnis verfügbaren Speicherplatz nicht genau kennen, verwenden Sie die Option in z/OS Migration Management Tool oder im Befehl zmmt, mit der das temporäre Verzeichnis an eine angepasste Position mit mehr Speicherplatz verschoben werden kann, und hängen Sie Ihr eigenes temporäres Dateisystem dort an. Wenn nicht genügend temporärer Speicherplatz verfügbar ist, kann dies zu einer vorzeitigen Beendigung des Migrationsprozesses führen.
  • IBM® SDK, Java™ Technology Edition Version 8 ist die SDK-Standardversion für WebSphere Application Server Version 9.0. .
    Fehler vermeiden Fehler vermeiden: Aktivieren Sie SDK, Java Technology Edition Version 8 nur, wenn alle Knoten auf Version 9.0 migriert sind. gotcha

    Weitere Informationen finden Sie im Artikel API und Spezifikationen migrieren.

  • Wenn Sie eine Zelle mit mehreren Knoten migrieren, müssen die Anwendungen auf dem Stand der niedrigsten Version des Java SDK bleiben, bis alle Knoten migriert wurden.
  • In den Artikeln zur Migration wird davon ausgegangen, dass WebSphere Application Server Version 9.0 in einer Umgebung installiert wird, in der bereits frühere Versionen von WebSphere Application Server vorhanden sind (Koexistenz).
    Berücksichtigen Sie beim Planen der Koexistenz die folgenden Punkte:
    • Aktualisieren Sie die vorausgesetzten Komponenten auf die für WebSphere Application Server Version 9.0 erforderlichen Stände.

      Vorgängerversionen von WebSphere Application Server können auch mit den höheren Ständen der vorausgesetzten Komponenten ausgeführt werden.

    • Überprüfen Sie die definierten Ports, um sicherzustellen, dass die Installation von WebSphere Application Server Version 9.0 konfliktfrei ist.

      Wenn Sie eine Installation für die Koexistenz mit WebSphere Application Server Version 7.0 oder höher durchführen, müssen Sie insbesondere darauf achten, dass die Standarddämonenportdefinitionen für beide Versionen identisch sind.

      Informationen zu den Standardports finden Sie im Artikel Standardportzuordnungen.

    Nähere Informationen enthält der Artikel Koexistierende Anwendungsserver ausführen.

  • Beachten Sie bei der Planung für die Verwendung von Zellen mit unterschiedlichen Releases folgende Aspekte:
    • Sie können für einen Teil der Knoten in einer Zelle ein Upgrade auf WebSphere Application Server Version 9.0 durchführen und andere Teile auf dem alten Releasestand belassen. Das bedeutet, dass Sie für einen bestimmten Zeitraum Server mit einem älteren Releasestand und Server mit dem neueren Releasestand in derselben Zelle verwalten.

      In dieser heterogenen Umgebung gelten möglicherweise einige Einschränkungen hinsichtlich der Operationen, die für die Server mit dem älteren Releasestand ausgeführt werden können. Detaillierte Informationen finden Sie unter Anwendungsserver erstellen. Es kann auch Einschränkungen bezüglich der Erstellung von Clustern und Cluster-Membern geben. Detaillierte Informationen finden Sie unter Cluster erstellen.

  • Bei der Migration auf WebSphere Application Server Version 9.0 werden die HTTP-Transporte in Transportketten für den Web-Container gemäß Channel Framework konvertiert.
    Weitere Informationen zur Transportunterstützung in WebSphere Application Server Version 9.0 finden Sie in den folgenden Artikeln:
    • Transportketten konfigurieren
    • Einstellungen für HTTP-Transportkanal
    • Transportketten
  • Denken Sie beim Entwickeln der Strategie für Ihr Konfigurationsdateisystem auch an die Wartung.

    Wenn Sie bei der Konfiguration der Umgebung mit WebSphere Application Server Network Deployment in z/OS Migration Management Tool den Standardwert für den Produktdateisystempfad verwenden, zeigen alle Knoten direkt auf den Mountpunkt des Produktdateisystems. Bei dieser Konfiguration ist eine unterbrechungsfreie Anwendung von Wartungspaketen beinahe unmöglich. Wenn eine Zelle in dieser Art und Weise konfiguriert ist, sind beim Anwenden der Wartung auf das Produktdateisystem alle Knoten gleichzeitig betroffen. Wenn mehrere Zellen in dieser Art und Weise konfiguriert sind, sind beim Anwenden der Wartung auf das Produktdateisystem alle Zellen gleichzeitig betroffen.

    Es empfiehlt sich, einen sogenannten "temporären symbolischen Link" zwischen dem Konfigurationsdateisystem jedes Knotens und dem tatsächlichen Mountpunkt des Produktdateisystems anzugeben. Diese Strategie wird im White Paper WebSphere Application Server for z/OS V5 - Planning for Test, Production and Maintenance erläutert.

    Weitere Informationen zu diesem Thema und seinem Bezug auf die Anwendung von Wartungspaketen finden Sie im White Paper Washington Systems Center Sample WebSphere for z/OS ND Configuration. Auf der Webseite WebSphere for z/OS: Updating an Existing Configuration HFS to Use Intermediate Symbolic Links finden Sie Anweisungen dazu, wie Sie ein Dienstprogramm anfordern und verwenden können, mit dem ein vorhandenes Konfigurations-HFS (Hierarchical Hile System, hierarchisches Dateisystem) für die Verwendung symbolischer Links aktualisiert werden kann.

  • Die Migrationstools erstellen ein Migrationssicherungsverzeichnis, das eine Sicherungskopie der Konfiguration der früheren Version enthält. Der in diesem Verzeichnis verfügbare Speicherplatz muss mindestens die Größe des Konfigurationsverzeichnisses und der Anwendungen der früheren Version zuzüglich der Ausgabe des Migrationsstapeljobs haben.

    Normalerweise ist die Ausgabe des Migrationsstapeljobs sehr klein, wenn der Trace nicht aktiviert ist. Die Größe der Traceausgabe hängt von davon ab, für welche Phasen der Migration die Traceerstellung aktiviert wird. Der meisten Traceausgaben finden in der WASPostUpgrade-Phase der Migration statt. Die typische Größe einer Traceausgabe für diese Phase sind 30 MB.

  • WebSphere Application Server Version 9.0 bietet keine Unterstützung für DB2 for zOS Local JDBC Provider (RRS).

    Wenn Sie DB2 for zOS Local JDBC Provider (RRS) in der Konfiguration von Version 7.0 oder höher verwenden und diese Konfiguration migriert werden soll, müssen Sie Ihre Konfiguration vor oder direkt nach der Migration auf Version 9.0 auf die Verwendung des DB2 Universal JDBC Driver Provider umstellen. Der Provider wird von den Migrationstools von Version 9.0 nicht migriert.

    Wenn Sie den DB2 for zOS Local JDBC Provider (RRS) in der zu migrierenden Version verwenden und Ihre Konfiguration vor der Migration auf Version 9.0 nicht auf den DB2 Universal JDBC Driver Provider umstellen, treten die folgenden Ereignisse ein:
    • Beim Ausführen der Migrationstools wird die folgende Nachricht angezeigt:
      MIGR0442W: Der JDBC-Provider DB2 for zOS Local JDBC Provider (RRS) wird nicht migriert.
      Erstellen Sie manuell einen Provider für DB2 Universal Driver als Ersatz. Weitere Einzelheiten finden Sie in der Dokumentation zu DB2.
    • Nach der Migration ist kein DB2-Zugriff mehr möglich und Sie erhalten die folgende Laufzeitnachricht:
      DSRA8213W: Der JDBC-Provider DB2 for zOS Local JDBC Provider (RRS) wird von
      WebSphere Application Server nicht mehr unterstützt. Anwendungen müssen DB2 Universal
      JDBC Driver Provider Type 2 verwenden.
    Wenn Sie bestimmen, dass Ihre Konfiguration so geändert werden muss, dass sie den DB2 Universal JDBC Driver Provider verwendet, können Sie dazu eine der folgenden Aufgaben ausführen:
    • Stellen Sie die Konfiguration von Version 7.0 oder höher vor der Migration auf Version 9.0 auf die Verwendung des DB2 Universal JDBC Driver Provider um.

      Wenn Sie diese Umstellung vornehmen, führen die Migrationstools von Version 9.0 die Migration auf den DB2 Universal JDBC Driver Provider durch. In diesem Fall sind nach der Migration keine weiteren Aktivitäten erforderlich.

      Führen Sie eine der folgenden Aktionen aus:
      • Ändern Sie Ihre Konfiguration manuell so, dass der DB2 Universal JDBC Driver Provider verwendet wird.
      • Wenn Sie eine Migration von Version 7.0 oder höher durchführen, verwenden Sie das Dienstprogramm JDBC Migration Utility for DB2 unter z/OS, um von DB2 for zOS Local JDBC Provider (RRS) auf DB2 Universal JDBC Driver Provider zu migrieren.

        Dieses Tool ist ein Script, das DB2 for zOS Local JDBC Providers (RRS) nacheinander auf jedem Knoten auf DB2 Universal JDBC Driver Provider migriert. In einem mit dem Tool bereitgestellten White Paper ist die Installation und Konfiguration von DB2 Universal JDBC Driver vor der Ausführung des Tools für die Migration Ihrer Konfiguration beschrieben.

    • Führen Sie nach der Migration auf Version 9.0 eine der folgenden Aktionen aus:
      • Ändern Sie Ihre Konfiguration manuell so, dass der DB2 Universal JDBC Driver Provider verwendet wird.
      • Verwenden Sie JDBC Migration Utility for DB2 unter z/OS, um eine Migration von DB2 for zOS Local JDBC Provider (RRS) auf DB2 Universal JDBC Driver Provider durchzuführen.

        Dieses Tool ist ein Script, das DB2 for zOS Local JDBC Providers (RRS) nacheinander auf jedem Knoten auf DB2 Universal JDBC Driver Provider migriert.

  • Nachdem Sie einen Basisanwendungsserver auf WebSphere Application Server Version 9.0 unter dem Betriebssystem z/OS migriert haben, werden die Verwaltungs- und Benutzeranwendungen wie im früheren Release weiterhin unter dem virtuellen Host "default_host" definiert. Unter dem virtuellen Host "admin_host", der in Version 6.1 eingeführt wurde, wird jedoch ein migrierter Deployment Manager definiert.
  • 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 gespeichert. 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.

    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.

  • Wenn Sie die Datei "java.security" in der früheren Version von WebSphere Application Server aktualisiert haben, vergewissern Sie sich, dass diese Aktualisierungen in der migrierten Datei "java.security" enthalten sind, die sich im Pfad V8WAS_HOME/properties/java.security befindet.
  • 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.

    • Erstellen Sie bei Bedarf neue SAF-Profile (System Authorization Facility), bevor Sie Ihre migrierten Server in WebSphere Application Server Version 9.0 starten.
      Ab Version 6.1 werden bestimmte Sicherheitsfunktionen über SAF-Profile gesteuert.
      • In Version 7.0 oder höher wird die Einstellung Anerkannte Anwendungen aktivieren über ein SAF-Sicherheitsprofil und nicht mehr wie in früheren Releases über eine interne WebSphere-Variable gesteuert.

        Die Option Anerkannte Anwendungen aktivieren, die der WebSphere Application Server-Laufzeitumgebung ermöglicht, bestimmte privilegierte Operationen für den Anwendungscode durchzuführen, ist für alle Server erforderlich, die die Registry des lokalen Betriebssystems (LocalOS) oder SAF-Berechtigung verwenden.

      • In Version 7.0 oder höher wird das Feature SynctoOSThread zulässig (das einer Anwendung ermöglicht, über eine von der Serveridentität abweichende Betriebssystemidentität auf Ressourcen zuzugreifen) über ein SAF-Sicherheitsprofil und die Variable "com.ibm.websphere.security.SyncToOSThread" gesteuert.

        Diese Implementierung ermöglicht es, dass sowohl der Administrator als auch der Administrator der Systemsicherheit festlegen können, ob das Feature verwendet wird oder nicht. Außerdem können in dieser Implementierung Einschränkungen bezüglich der von der Anwendung verwendeten Identitäten definiert werden.

      Wenn Sie eine Migration von einer früheren Version von WebSphere Application Server durchführen und diese Features benötigen, müssen Sie die erforderlichen SAF-Profile erstellen. Wenn diese Profile nicht vorhanden oder nicht ordnungsgemäß konfiguriert sind, kann eine Zelle, die die Benutzerregistry des lokalen Betriebssystems (LocalOS) oder SAF-Berechtigung verwendet, in Version 9.0 nicht gestartet werden.

      Verwenden Sie die folgenden Anweisungen, wenn Sie Resource Access Control Facility (RACF) für Ihr Sicherheitssystem verwenden. Wenn Sie ein anderes SAF-kompatibles Sicherheitssystem verwenden, müssen Sie entsprechende Informationen vom Lieferanten dieses Sicherheitssystems anfordern.
      • Überprüfen Sie anhand Ihres MVS-Systemprotokolls (Multiple Virtual Storage) oder über die Administrationskonsole, ob Anerkannte Anwendungen aktivieren für Ihren Server aktiviert ist.
        Suchen Sie im Startprotokoll nach control_region_security_enable_trusted_applications. Ist der Wert 1 angegeben, ist die Option Anerkannte Anwendungen aktivieren aktiviert. Wenn diese Option aktiviert ist, erstellen Sie das folgende SAF-Profil und gewähren Sie der Benutzer-ID für die Steuerregion des Anwendungsservers Lesezugriff:
        BBO.TRUSTEDAPPS.Kurzname_der_Zelle.Name_für_Clusterübergang
        Verwenden Sie die folgenden RACF-Befehle, um diese Aktion auszuführen:
        RDEFINE FACILITY 
          BBO.TRUSTEDAPPS.Kurzname_der_Zelle.Name_für_Clusterübergang
          UACC(NONE) 
        PERMIT FACILITY 
          BBO.TRUSTEDAPPS.Kurzname_der_Zelle.Name_für_Clusterübergang
          ID(Benutzer-ID_des_Controllers) ACCESS(READ)
        SETROPTS RACLIST(FACILITY) REFRESH

        Das SAF-Profil Clustername wird für Server, die nicht zu einem Cluster gehören, durch den Namen für Clusterübergang ersetzt. Wenn Sie die Option Anerkannte Anwendungen aktivieren für alle Server in der Zelle aktivieren möchten, ersetzen Sie den Clusternamen durch ein Platzhalterzeichen (*).

        Weitere Informationen finden Sie im Artikel SAF-Klassen und -Profile im Information Center.

      • Überprüfen Sie anhand Ihres MVS-Systemprotokolls (Multiple Virtual Storage) oder über die Administrationskonsole, ob SyncToOSThread zulässig für Ihren Server aktiviert ist.
        Wenn diese Option aktiviert ist, erstellen Sie das folgende SAF-Profil und gewähren Sie der Benutzer-ID für die Steuerregion des Anwendungsservers Lese- oder Steuerungszugriff:
        BBO.SYNC.Kurzname_der_Zelle.Name_für_Clusterübergang
        Das folgende Beispiel enthält RACF-Befehle, die Sie für die Ausführung dieser Aktion verwenden können:
        RDEFINE FACILITY 
          BBO.SYNC.Kurzname_der_Zelle.Name_für_Clusterübergang
          UACC(NONE) 
        PERMIT FACILITY 
        BBO.SYNC.Kurzname_der_Zelle.Name_für_Clusterübergang
          ID(Benutzer-ID_des_Controllers) ACCESS(CONTROL)
        SETROPTS RACLIST(FACILITY) REFRESH

        Der Clustername wird für Server, die nicht zu einem Cluster gehören, durch den Namen für Clusterübergang ersetzt. Wenn Sie das Feature SyncToOSThread zulässig für alle Server in der Zelle aktivieren möchten, ersetzen Sie den Clusternamen durch ein Platzhalterzeichen (*).

        Wichtig:
        • Wenn Sie der Steuerregion Lesezugriff auf die Benutzer-ID für die Steuerregion des Anwendungsservers gewähren, schränkt dies die Benutzer-IDs ein, in die die Thread-ID basierend auf SAF-SURROGAT-Profilen geändert werden kann.

          Wenn die Benutzer-ID des Controllers Lesezugriff auf das Profil BBO.SYNC hat und die Variable "com.ibm.websphere.security.SyncToOSThread" auf "true" gesetzt ist, kann eine Anwendung das Feature "SynctoOSThread" anfordern. Die Anwendung kann die Identität des Aufrufenden und eine rollenbezogene Benutzer-ID für den Zugriff auf Ressourcen verwenden. Damit der Servant mit einer anderen Anwendungs-ID ausgeführt werden kann, benötigt der Servant jedoch Schreibzugriff auf das SURROGAT-Profil (BBO.SYNC.Benutzer-ID_für_Anwendung).

        • Wenn Sie der Steuerregion Steuerungszugriff auf die Benutzer-ID der Steuerregion des Anwendungsservers gewähren, kann die Thread-ID in jede Benutzer-ID geändert werden, die SynctoOSThread anfordert.

          Wenn die Benutzer-ID des Controllers Steuerungszugriff auf das Profil BBO.SYNC hat und die Variable "com.ibm.websphere.security.SyncToOSThread" auf "true" gesetzt ist, kann eine Anwendung SynctoOSThread anfordern. Die Anwendung kann die Identität des Aufrufenden und jede rollenbezogene Benutzer-ID für den Zugriff auf Ressourcen verwenden. SURROGAT-Profile werden nicht geprüft.

        Weitere Informationen finden Sie im Artikel Synchronisation der Anwendung mit Betriebssystemthread zulässig im Information Center.

    • Wenn Sie SAF-EJBROLE-Profile für die rollenbasierte Berechtigung verwenden, müssen Sie EJBROLE-Profile für die beiden Verwaltungsrollen des Implementierers und des Managers der Verwaltungssicherheit erstellen, die in Version 6.1 eingeführt wurden.
    • Überprüfen Sie Ihre JVM-Einstellungen (Java Virtual Machine), um sicherzustellen, dass mindestens eine Heapspeichergröße von 50 für eine verbesserte Startleistung verwendet wird.

      Lesen Sie den Artikel zu den JVM-Einstellungen in der Dokumentation, um weitere Informationen zu erhalten.

      Falls Sie bisher mit einem kleineren Heapspeicher gearbeitet haben, können Sie die Standardheapgröße 50 verwenden.

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

    • Wenn Sie mehrere Node Agents in derselben logischen Partition (LPAR) haben, können nach der Ausführung der Migrationsjobs Konflikte bei den IPC_CONNECTOR_ADDRESS-Ports auftreten. Konfigurieren Sie die in Konflikt stehenden Ports neu.
    • Wenn Sie Anwendungen haben, die versuchen, über TLS (Transport Layer Security) eine Anforderung an einen SIP-URI (Session Initiation Protocol) zu senden, müssen Sie einen Unterschied im Verhalten von WebSphere Application Server Version 6.1 und Version 9.0 berücksichtigen.

      Wenn eine SIP-Anwendung in Version 6.1 eine Anforderung über TLS an einen SIP-URI sendet, ändert sich das Anforderungs-URI-Schema von "sip" in "sips". In Version 9.0 bleibt das Schema unverändert.

      Dieser Unterschied macht sich bemerkbar, wenn Ihre Anwendungen versuchen, eine SIP-Anforderung zu senden, in der der Anforderungs-URI das Schema "sip" und den Transportparameter "tls" enthält. Wenn eine Anwendung in Version 6.1 beispielsweise eine Anforderung mit dem Anforderungs-URI
      sip:alice@atlanta.com;transport=tls
      erstellt und an das Netz sendet, ändert der SIP-Container sowohl das Schema als auch den Transportparameter, um den folgenden Anforderungs-URI zu erstellen:
      sips:alice@atlanta.com;transport=tcp
      In Version 9.0 ändert der SIP-Container das Schema nicht.

      Wenn Sie das alte Verhalten nach der Migration des Anwendungsservers von Version 6.1 auf Version 9.0 beibehalten möchten, ändern Sie den Anwendungscode. Wenn die Anwendung beabsichtigt, einen URI mit dem Schema "sips" zu senden, muss sie den URI auf diese Weise erstellen, bevor sie das Senden der Nachricht anfordert. Mit einem URI, der das Schema "sips" enthält, bleibt das Verhalten wie in Version 6.1.


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-zos&topic=cmig_pre
Dateiname:cmig_pre.html