Fehler in Umgebungen mit mehreren Servern

Verwenden Sie die Informationen in diesem Artikel, um Probleme bei der Konfiguration von Umgebungen mit mehreren Servern zu beheben.

Sollten Sie den Fehler anhand der Fehlerbehebungsbeschreibungen nicht beheben können, gehen Sie wie folgt vor:
  1. Durchsuchen Sie die Protokolle der betroffenen Deployment Manager und Anwendungsserver.

    [AIX Solaris HP-UX Linux Windows][IBM i]Rufen Sie den Artikel JVM-Protokolle auf.

    1. Suchen Sie alle Fehlernachrichten. Wählen Sie hierfür im Information Center die Ansicht Referenz aus und erweitern Sie in der Navigationsstruktur den Eintrag Nachrichten.
    2. Wenn Java-Ausnahmen in den Protokolldateien erscheinen, versuchen Sie, die tatsächliche, direkt vom Problem betroffene Unterkomponente zu ermitteln. Überprüfen Sie den Trace-Stack auf eine Klasse, die sich auf WebSphere Application Server bezieht (Namen, die mit com.ibm.websphere oder com.ibm.ws beginnen) und die Ausnahme ausgelöst hat.

      Wenn die Ausnahme scheinbar von einer Klasse im Paket com.ibm.websphere.naming ausgelöst wurde, lesen Sie den Artikel Tipps zur Fehlerbehebung bei Namensservices.

  2. Setzen Sie den Befehl ping an alle Maschinen in Ihrer Konfiguration ab, dass die TCP/IP-Konnektivität gewährleistet ist:
    1. Von jedem physischen Server an den Deployment Manager
    2. Vom Deployment Manager an jeden physischen Server
  3. Obwohl das Problem in einer Clusterumgebung auftritt, hängt das eigentliche Problem möglicherweise nur indirekt mit dem Clustering zusammen. Prüfen Sie alle relevanten Möglichkeiten:
    1. Wenn eine Enterprise-Bean auf einem oder mehreren Servern keine Anforderungen bearbeitet, lesen Sie die Artikel Kein Zugriff auf Enterprise-Beans über ein Servlet, eine JSP-Datei, ein eigenständiges Programm oder einen anderen Client und Probleme beim Anwendungszugriff.
    2. Wenn Fehler scheinbar nach der Aktivierung der Sicherheitskomponente auftreten, lesen Sie den Artikel Zugriffsfehler nach Aktivierung der Sicherheitskomponente.
    3. Falls ein Anwendungsserver plötzlich nicht mehr auf Anforderungen reagiert oder abstürzt (der Anwendungsserverprozess wird geschlossen), lesen Sie den Abschnitt Webmodul oder Anwendungsserver verarbeitet keine Anforderungen mehr.
    4. Wenn SOAP-Anforderungen von einigen Servern nicht bearbeitet werden, lesen Sie den Artikel Tipps zur Fehlerbehebung bei SOAP-Anforderungen für Anwendungsclients.
    5. Wenn Sie Probleme haben, eine Anwendung auf Servern zu installieren oder zu implementieren, die sich auf einem oder mehreren Knoten befinden, lesen Sie den Artikel Probleme bei der Anwendungsimplementierung.
  4. Wenn sich Ihre Topologie aus einem Windows-basierten Deployment Manager mit UNIX-basierten Servern zusammensetzt, können Sie die zuvor aktualisierten Dateien mit den Erweiterungen .xml und .policy auf der UNIX-basierten Plattform mit dem vi-Editor anzeigen, um sicherzustellen, dass keine Zeilenumbruchzeichen (Strg-M) in den Dateien enthalten sind. Editieren Sie diese Dateien auf der UNIX-Plattform mit dem vi-Editor, damit diese Zeichen nicht eingefügt werden.
  5. Prüfen Sie, welche Schritte zurFehlerbehebung beim Workload-Management erforderlich sind.
  6. Prüfen Sie, ob der Fehler bekannt ist und dokumentiert wurde. Lesen Sie dazu die entsprechenden Informationen in der verfügbaren Onlineunterstützung (Hinweise und Tipps, technische Anmerkungen und Fixes).
[AIX Solaris HP-UX Linux Windows]

Beim Versuch, in einer heterogenen Zellenumgebung ein neues Profil zu erstellen, kann eine Diskrepanz bei den Schablonen auftreten

Dieses Problem tritt auf, weil bei der Installation eines Fixpack der Version 6.0.x in WebSphere Application Server Version 6.0.x Profilschablonen nicht aktualisiert werden. Sie können einen Befehl im Verzeichnis bin des Installationsstammverzeichnisses von WebSphere Application Server ausführen, um das Profil zu aktualisieren und so die Einschränkungen für eine heterogene Zellenumgebung aufzuheben.

Geben Sie für die Windows-Plattform den folgenden Befehl ein, der als Standardinstallationsstammverzeichnis C:\Programme\IBM\WebSphere\AppServer verwendet:
Stammverzeichnis_des_Anwendungsservers\bin\ws_ant.bat -buildfile updateNDProfileTemplates.xml
Geben Sie auf UNIX- und Linux-Plattformen die folgenden Befehle ein:
  • Für Nicht-AIX-Plattformen ist das Standardinstallationsstammverzeichnis /opt/IBM/WebSphere/AppServer.
  • Für AIX-Plattformen ist das Standardinstallationsstammverzeichnis /usr/IBM/WebSphere/AppServer.
    • Führen Sie für andere Plattformen als AIX den folgenden Befehl aus:
      USER_INSTALL_ROOT=Stammverzeichnis_des_Anwendungsservers/profiles/Name_Ihres_DM-Profils/
    • Für AIX setzen Sie den folgenden Befehl ab:
      USER_INSTALL_ROOT=Stammverzeichnis_des_Anwendungsservers/profiles/Name_Ihres_DM-Profils/ 
  1. export USER_INSTALL_ROOT
  2. Stammverzeichnis_des_Anwendungsservers/bin/ws_ant -buildfile updateNDProfileTemplates.xml

Nach dem Erstellen eines Cluster kann der Cluster nicht gestartet werden, und in den Protokollen wird angezeigt, dass keine Server in dem Cluster gefunden werden.

Dieser Fehler kann auftreten, wenn die Konfigurationen von Deployment Manager und Knoten nicht synchronisiert wurden. Warten Sie bei Aktivierung der automatischen Synchronisation, bis die Synchronisation abgeschlossen ist. Fordern Sie bei Verwendung der manuellen Synchronisation explizit eine Synchronisation für jeden Knoten im Cluster an.

Wenn Sie feststellen möchten, ob die Synchronisation durchgeführt wurde, prüfen Sie in der Administrationskonsole die Konfiguration auf den Knotenmaschinen, und vergewissern Sie sich, dass die neuen Cluster-Member auf allen Knoten definiert sind.

Ein oder mehrere Knoten werden in der Administrationskonsole nicht angezeigt

Dieser Fehler kann auftreten, wenn in der Konnektivität zwischen dem Deployment-Manager-Server und anderen Servern in der Topologie ein grundlegender Fehler vorliegt. Lokalisieren Sie die Datei serverindex.xml in der Verzeichnisstruktur des Deployment Manager:
  • Ist der fehlerhafte Knoten nicht in der Liste aufgeführt, prüfen Sie, welche Schritte durchgeführt werden werden müssen, um dem Cluster einen Knoten hinzuzufügen.
  • Wenn der fehlerhafte Knoten in der Liste aufgeführt ist, gehen Sie wie folgt vor:
    • Setzen Sie vom Deployment-Manager-Server den Befehl "ping" für den angezeigten Servernamen ab. Wenn die Ausgabe des Befehl ping anzeigt, dass keine Verbindung besteht, prüfen Sie, ob der Hostname in der Liste richtig angegeben ist. Korrigieren Sie den Namen gegebenenfalls, und starten Sie den Deployment Manager erneut.
    • Wenn der in der Liste aufgeführte Name der Kurzname ist, setzen Sie den Befehl "ping" mit dem vollständigen Netznamen ab. Können Sie mit dem korrigierten Namen eine Verbindung herstellen, aktualisieren Sie die Liste, und starten Sie den Deployment Manager erneut.
    • Wenn der fehlerhafte Server DHCP (Dynamic Host Configuration Protocol) verwendet, versuchen Sie, den logischen Hostnamen durch die IP-Adresse zu ersetzen, und starten Sie den Deployment Manager erneut. Wenn Sie den Fehler dadurch beheben können, beachten Sie, dass Sie die Datei serverindex.xml jedesmal, wenn die Adresse des fehlerhaften Servers geändert wird, entsprechend anpassen müssen. Das gilt auch, wenn Sie die fehlerhafte Maschine erneut starten müssen. Zur Vermeidung dieses Fehlers sollten Sie in Erwägung ziehen, dem Server eine statische IP-Adresse zuzuordnen.
  • Wenn Sie dann immer noch keine Verbindung zwischen den Servern herstellen können, wenden Sie sich zur Lösung des Problems an den Netzadministrator, und starten Sie den Deployment Manager erneut, nachdem Sie den Fehler behoben haben.

Der Befehl addNode schlägt fehl

Dieser Fehler kann auftreten, wenn die DNS-Konfiguration (Domain Name Server) des Deployment Manager nicht ordnungsgemäß durchgeführt wurde. Die Standardinstallation unter Linux verwendet die Loopback-Adresse (127.0.0.1) als Hoststandardadresse. Möchten Sie sich vergewissern, dass dies die Ursache des Problems ist, fragen Sie den Hostnamen der entsprechenden Maschine ab. Wenn localhost 127.0.0.1 zurückgegeben wird oder die Dateiübertragungstraces auf dem Knoten anzeigen, dass der Knoten versucht, Dateien zu einer Webadresse hochzuladen, die die Angabe 127.0.0.1 beinhaltet, hat der Knoten eine ungültige DNS-Konfiguration.

Aktualisieren Sie zur Behebung dieses Fehlers die Datei /etc/hosts oder die Konfigurationsdatei des Namensservice, /etc/nsswitch.conf, um den DNS (Domain Name Server) oder NIS (Network Information Server), bevor Sie nach Hosts suchen.

Auf den Knoten sind keine Anwendungsdateien vorhanden.

[AIX Solaris HP-UX Linux Windows][z/OS]In der Umgebung von WebSphere Application Server Network Deployment werden die Binärdateien der Anwendung auf die einzelnen Knoten, auf denen Anwendungen als Teil der Operation "node synchronization" unterstützt werden, übertragen. Während der Operation "node synchronization" werden Anwendungsdateien nur weitergegeben, wenn für die entsprechenden Implementierungsdeskriptoren der Wert enableDistribution=true angegeben ist. Dieses Flag wird als Teil der Anwendungsinstallationsprozedur in der Administrationskonsole angegeben und als Eigenschaft Stammverzeichnis_des_Anwendungsservers/config/cells/Zellenname/applications/Anwendungsname/deployment.xml gespeichert.

[IBM i]In der Umgebung von WebSphere Application Server Network Deployment werden die Binärdateien der Anwendung auf die einzelnen Knoten, auf denen Anwendungen als Teil der Operation node sync unterstützt werden, übertragen. Während der Operation "node sync" werden Anwendungsdateien nur weitergegeben, wenn für die entsprechenden Implementierungsdeskriptoren der Wert enableDistribution=true angegeben ist. Dieses Flag wird als Teil der Anwendungsinstallationsprozedur in der Administrationskonsole angegeben und als Eigenschaft in der Datei Profilstammverzeichnis/config/cells/Zellenname/applications/Anwendungsname/deployment.xml gespeichert.

Wenn Sie sich vergewissern möchten, dass dies die Ursache des Problems ist, prüfen Sie, ob das Flag enableDistribution definiert ist. Ist das Flag bereits auf true, gesetzt, vergewissern Sie sich, dass der Zielknoten so konfiguriert ist, dass die automatische Dateisynchronisation ausgeführt wird.

Wenn beide Einstellungen richtig sind und der Fehler weiterhin auftritt, führen Sie manuell eine Synchronisation durch. Falls die Anwendungsdateien danach immer noch nicht im Installationsverzeichnis angezeigt werden, verwenden Sie das Tool EARExpander (im Verzeichnis Stammverzeichnis_des_Anwendungsservers/bin), um die EAR-Datei aus dem Repository im Installationsverzeichnis zu entpacken. Auf fernen Knoten muss das Repository im Verzeichnis config/cells/Zellenname/applications/Anwendungsname.ear/ erscheinen.

In einer Clusterumgebung wird ein Server mit aktiviertem Debug-Modus nicht gestartet.

Das Problem tritt auf, wenn die folgenden drei Bedingungen zutreffen:
  • Mehrere Serverprozesse wurden für denselben Knoten konfiguriert
  • Für mehrere Server wurde der Debug-Modus aktiviert
  • Die Debug-Argumente für mehrere Server wurden in der Standardeinstellung belassen, d. h., dass mehrere Server im Knoten versuchen, denselben Debug-Port zu verwenden (Portnummer 7777).

Der Server wird nicht gestartet, da mehrere Serverprozesse, die auf derselben physischen Hostmaschine mit aktiviertem Debug-Modus ausgeführt werden, nicht denselben Debug-Port verwenden können.

Führen Sie für jeden Server die folgenden Schritte aus:
  1. Klicken Sie in der Administrationskonsole auf Server > Anwendungsserver > Servername > Java- und Prozessverwaltung > Prozessdefinition > Java Virtual Machine.
  2. Aktualisieren Sie das Debug-Argument so, dass die Adresse des Debug-Port (Adresse = Portnummer) für jeden Serverprozess eindeutig ist.

Symbol, das den Typ des Artikels anzeigt. Referenzartikel



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