Arbeitslast wird nicht verteilt
Diese Informationen können Ihnen bei der Behebung eines Lastverteilungsproblems helfen.
- HTTP-Anforderungen werden nicht an alle Server verteilt
- EJB-Anforderungen werden nicht an alle Server verteilt
EJB-Anforderungen werden nicht gleichmäßig verteilt
- Ein fehlerhafter Server empfängt weiterhin Enterprise-Bean-Anforderungen (Failover wird nicht durchgeführt)
- Gestoppte oder blockierte Server teilen den Workload nach der Wiederherstellung nicht.
Die Arbeitslast eines Cluster wird nicht vom Ausweichcluster übernommen
Durchsuchen Sie die JVM-Protokolle der betroffenen Deployment Manager und Anwendungsserver.
- 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.
Verwenden Sie das Tool "Protokoll- und Traceanalyse", um das Serviceprotokoll (activity.log) des Deployment Manager und aller Knoten, bei denen Probleme auftreten, anzuzeigen und zu analysieren. Zeigen Sie die Dateien activity.log aus den Verzeichnissen Stammverzeichnis_des_Anwendungsservers/logs und Stammverzeichnis_des_Anwendungsservers/logs an.
Analysieren Sie das Serviceprotokoll (activity.log) des Deployment Manager und aller Knoten, auf denen Probleme auftreten. Zeigen Sie die Datei activity.log aus dem Verzeichnis Profilstammverzeichnis/logs an.
Wenn Java™-Ausnahmen in den Protokolldateien erscheinen, versuchen Sie, die tatsächliche, direkt vom Problem betroffene Subkomponente zu ermitteln. Überprüfen Sie den Trace-Stack auf eine Klasse, die sich auf das Produkt bezieht (Namen, die mit "com.ibm.websphere" oder "com.ibm.ws" beginnen) und die Ausnahme ausgelöst hat. Prüfen Sie die Schritte zur Fehlerbehebung für die entsprechenden Unterkomponente im Abschnitt Fehlerbehebung bei WebSphere-Anwendungen des Information Center.
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".
Durchsuchen Sie die JVM-Protokolle der betroffenen Deployment Manager und Anwendungsserver.
- 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.
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 das Produkt bezieht (Namen, die mit com.ibm.websphere oder com.ibm.ws beginnen) und die Ausnahme ausgelöst hat. Prüfen Sie die Schritte zur Fehlerbehebung für die entsprechenden Unterkomponente im Abschnitt Fehlerbehebung bei WebSphere-Anwendungen des Information Centers.
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".
- Setzen Sie den Befehl ping an alle Maschinen in Ihrer Konfiguration ab, dass
die TCP/IP-Konnektivität gewährleistet ist:
- Von jedem physischen Server an den Deployment Manager
- Vom Deployment Manager an jeden physischen Server
- 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:
- Wenn eine Enterprise-Bean in einem odere mehreren Servern keine Anforderungen bearbeitet, lesen Sie die Artikel Zugriff auf eine Enterprise-Bean über ein Servlet, eine JSP, ein eigenständiges Programm oder einen anderen Client nicht möglich und Objekt im Produkt wurde vom Servlet, der JSP-Datei oder einem anderen Client nicht gefunden.
- Wenn nach dem Aktivieren der Sicherheit Probleme aufzutreten scheinen, lesen Sie den Artikel "Fehler oder Zugriffsprobleme nach dem Aktivieren der Sicherheit".
- Falls ein Anwendungsserver plötzlich nicht mehr auf Anforderungen reagiert oder abstürzt (der Anwendungsserverprozess wird geschlossen), lesen Sie den Abschnitt "Webmodul oder Anwendungsserver stürzt ab oder blockiert".
- Wenn von einigen oder allen Servern keine SOAP-Anforderungen bearbeitet werden, lesen Sie den Artikel "Rückgabe von Fehlern an Clients, die versuchen, eine SOAP-Anforderung zu senden".
Wenn beim Installieren oder Implementieren einer Anwendung in Servern auf einem oder mehreren Knoten Probleme auftreten, lesen Sie den Artikel "Probleme bei der Codeimplementierung und -installation beheben".
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 vi anzeigen, um sicherzustellen, dass keine Zeilenumbruchzeichen (Strg-M) in den Dateien enthalten sind. Um dieses Problem in Zukunft zu umgehen, editieren Sie diese Dateien auf der UNIX-Plattform mit vi, damit diese Zeichen nicht eingefügt werden.
Prüfen Sie, ob Tipps zur Fehlerbehebung beim Workload-Management gegeben werden.
- 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).
HTTP-Anforderungen werden nicht an alle Server verteilt
- Prüfen Sie die Liste der primären Server. Das Plug-in verteilt die Last auf alle Server, die in der Liste der Primärserver definiert sind, wenn keine Affinität festgelegt wurde. Wurde keine Liste der Primärserver definiert, verteilt das Plug-in die vorhandene Last auf alle im Cluster definierten Server, wenn keine Affinität festgelegt wurde. Im Falle, dass Affinität festgelegt wurde, muss das Plug-in bei allen Anforderungen innerhalb einer HTTP-Sitzung eine direkte Verbindung zu diesem Server herstellen.
- Wenn einige Server Anforderungen bearbeiten, andere jedoch nicht, versuchen Sie, direkt auf einen fehlerhaften
Server zuzugreifen, um sicherzustellen, dass er betriebsbereit ist. Lassen Sie dabei Fragen der Auslastungsverwaltung außer Acht. Wenn
das nicht funktioniert, gehen Sie wie folgt vor:
- Prüfen Sie in der Administrationskonsole, ob der entsprechende Server aktiv ist.
- Weitere Informationen finden Sie im Artikel "Webressource wird nicht angezeigt".
- Weitere Informationen finden Sie im Artikel "Tipps zur Fehlerbehebung bei HTTP-Plug-in-Komponenten".
Überprüfen Sie die Schritte zum Diagnostizieren von Workload-Management-Problemen im Artikel "Fehlerbehebung bei der Workload-Management-Komponente".
EJB-Anforderungen werden nicht an alle Server verteilt
- Prüfen Sie in der Administrationskonsole, ob der entsprechende Server gestartet wurde. Versuchen Sie, den Server zu starten, bzw. erneut zu starten.
- Durchsuchen Sie die Administrationskonsole, und prüfen Sie, dass der Knoten, auf dem der Server ausgeführt wird, angezeigt wird. Ist
das nicht der Fall, gehen Sie wie folgt vor:
- Prüfen Sie, welche Schritte durchgeführt werden müssen, um einen Knoten einem Cluster hinzuzufügen.
- Prüfen Sie anhand des Abschnitts Ein oder mehrere Knoten werden in der Administrationskonsole nicht angezeigt, welche Schritte auszuführen sind.
- Versuchen Sie, wenn möglich, direkt auf die Enterprise-Beans auf dem fehlerhaften Server zuzugreifen, um zu prüfen, ob ein Problem mit der TCP/IP-Konnektivität, dem Status des Anwendungsservers bzw. ein anderes, nicht mit der Auslastungsverwaltung in Zusammenhang stehendes Problem vorliegt. Wenn dieser Versuch scheitert, lesen Sie den Artikel "Zugriff auf eine Enterprise-Bean über ein Servlet, eine JSP, ein eigenständiges Programm oder einen anderen Client nicht möglich".
Überprüfen Sie die Schritte zum Diagnostizieren von Workload-Management-Problemen im Artikel "Fehlerbehebung bei der Workload-Management-Komponente".
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
EJB-Anforderungen werden nicht gleichmäßig verteilt
- falsche Konfiguration
- Umgebungsfehler, wie z. B. die Verfügbarkeit von Servern oder Anwendungen
- eine große Anzahl von Anforderungen mit transaktionaler Affinität bzw.
- eine kleine Anzahl von Clients
Das Workload-Management im Produkt
verwendet für die Verteilung von Anforderungen an die Server ein Schema mit proportionaler Gewichtung. Dieses Schema bewirkt, dass der Lastausgleich durch die Anzahl der Anforderungen und nicht durch andere Kriterien bestimmt wird. Ein
echtes Problem mit dem Lastausgleich können Sie dadurch bestimmen, dass Sie die Anzahl der Anforderungen, die von jedem Member des Cluster verarbeitet werden, mit den Wertigkeiten, die für jedes dieser Member definiert werden, vergleichen. Führen Sie
hierfür die im Artikel "Fehlerbehebung bei der Workload-Management-Komponente" beschriebenen Schritte aus.
Das Workload-Management im Produkt basiert
auf einem Round-Robin-Schema der Anforderungsverteilung. Dieses Schema bewirkt, dass der Lastausgleich durch die Anzahl der Anforderungen und nicht durch andere Kriterien bestimmt wird. Ein
echtes Problem mit dem Lastausgleich können Sie dadurch bestimmen, dass Sie die Anzahl der Anforderungen, die von jedem Member des Cluster verarbeitet werden, mit den Wertigkeiten, die für jedes dieser Member definiert werden, vergleichen.
![[z/OS]](../images/ngzos.gif)
- Wenn der Prozentsatz der Anforderungen, die für jedes Member des Cluster eingehen, mit den Wertigkeiten konsistent ist, muss eine weitere Analyse der Anwendung durchgeführt werden, um die Ursache für das Ungleichgewicht bei der Lastverteilung, das trotz ausgeglichener Anforderungsmenge besteht, zu ermitteln.
- Wenn die Anzahl von numIncomingNonWLMObjectRequests nicht auf die Member des Cluster verteilt und im Verhältnis zu numIncomingRequests relativ groß ist, dann ist die Ursache für das Ungleichgewicht auf die nicht verteilbaren Komponenten zurückzuführen, die auf den Membern des Cluster installiert sind. Wenn Sie die Konfiguration entsprechend ändern, erhalten Sie eine ausgeglichenere Umgebung.
- Wenn die Anzahl von umIncomingStrongAffinityRequests nicht gleichmäßig auf die Member des Cluster verteilt und im Verhältnis zu numIncomingRequests relativ groß ist, dann ist die Ursache für das Ungleichgewicht auf die Anforderungen zurückzuführen, die in einer Transaktion aufgerufen werden. Sie können die Menge der Anforderungen dadurch verringern, dass Sie die an einer Transaktion beteiligten Objekte in demselben Cluster installieren.
Ein fehlerhafter Server empfängt weiterhin Enterprise-Bean-Anforderungen (Failover wird nicht durchgeführt)
Der Client wurde zusammen mit einer Enterprise-Bean auf dem Server, der abgestürzt ist, ausgeführt. Überprüfen Sie die JVM-Protokolle des Anwendungsservers mit der betroffenen Enterprise-Bean-Instanz. Wenn eine Anforderung mit der Ausnahme CORBA SystemException COMM_FAILURE org.omg.CORBA.completion_status.COMPLETED_MAYBE zurückgegeben wird, liegt möglicherweise kein Fehler vor. Laut Entwurf wird diese besondere Ausnahme an den Client zurückgegeben, da die Transaktion möglicherweise abgeschlossen ist. Wenn Sie diese Anforderung an einen anderen Server leiten, führt dies möglicherweise dazu, dass die Anforderung zweimal bearbeitet wird.
Der Client wurde zusammen mit einer Enterprise-Bean auf dem Server, der abgestürzt ist, ausgeführt. Überprüfen Sie die JVM-Protokolle des Anwendungsservers mit der betroffenen Enterprise-Bean-Instanz. Wenn eine Anforderung mit der Ausnahme CORBA SystemException COMM_FAILURE org.omg.CORBA.completion_status.COMPLETED_MAYBE zurückgegeben wird, liegt möglicherweise kein Fehler vor. Laut Entwurf wird diese besondere Ausnahme an den Client zurückgegeben, da die Transaktion möglicherweise abgeschlossen ist. Wenn Sie diese Anforderung an einen anderen Server leiten, führt dies möglicherweise dazu, dass die Anforderung zweimal bearbeitet wird.
Wenn die Anforderungen, die an die Server gesendet wurden, konsistent mit einer anderen Ausnahme an den Client zurückgegeben werden, sind möglicherweise keine Server verfügbar. In diesem Fall führen Sie die Problemlösungsschritte im Artikel "Fehlerbehebung bei der Workload-Management-Komponente" aus.
Wenn die Anforderungen, die an die Server gesendet wurden, konsistent mit einer anderen Ausnahme an den Client zurückgegeben werden, sind möglicherweise keine Server verfügbar.
![[z/OS]](../images/ngzos.gif)
Gestoppte oder blockierte Server teilen den Workload nach der Wiederherstellung nicht.
Dieser Fehler tritt auf, wenn zuvor nicht verfügbare Server von der Workload-Management-Komponente nicht erkannt werden, wenn diese Server wiederhergestellt werden. Die Eigenschaft "com.ibm.websphere.wlm.unusable.interval" gibt das Intervall unusable an. In diesem Zeitraum wartet die WLM-Komponente mit dem Senden von Daten an den Server, der als nicht verwendbar markiert wurde. Die Standardeinstellung gibt einen Zeitraum von 5 Minuten an.
Um sicherzustellen, dass das Problem hierauf zurückzuführen ist, vergewissern Sie sich, dass die Server, die vorher nicht aktiv waren, jetzt aktiv sind und Anforderungen bearbeiten können. Warten Sie dann, bis das Intervall "unusable" abgelaufen ist, bevor Sie prüfen, ob das Failover durchgeführt wurde.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Die Arbeitslast eines Cluster wird nicht vom Ausweichcluster übernommen
[10/11/04 13:11:10:233 CDT] 00000036 SelectionMana A WWLM0061W: Beim Senden
einer Anforderung an Cluster-Member {MEMBERNAME=FlorenceEJBServer1,
NODENAME=fwwsaix1Node01} ist ein Fehler aufgetreten, und das Member wurde für weitere Anforderungen an den
Cluster "" als nicht verwendbar markiert. Ausnahme: org.omg.CORBA.COMM_FAILURE:
CONNECT_FAILURE_ON_SSL_CLIENT_SOCKET - JSSL0130E: java.io.IOException: Zeigt
an, dass eine E/A-Ausnahme eingetreten ist. Reason: Connection refused
vmcid: 0x49421000 minor code: 70 completed: No"
- Überprüfen Sie im Deployment Manager den Hostnamen und Bootstrap-Port für jede Ausweichclustereinstellung.
- Überprüfen Sie die Peer-Ports für die Stammgruppenbrücke, um sicherzustellen, dass Hostnamen und DCS-Port (Distribution and Consistency Services) korrekt sind.
- Vergewissern Sie sich, dass die Namen des primären Cluster und des Ausweichcluster übereinstimmen.
- Wenn Ihre Anwendung für die Verbindung zum Ausweichcluster Sicherheitseinstellungen verwendet, überprüfen Sie Ihre Sicherheitskonfiguration. Möglicherweise müssen Sie Single Sign-On (SSO) verwenden und die LTPA-Schlüssel in die Backup-Zelle importieren.