[AIX Solaris HP-UX Linux Windows][z/OS]

Intelligent Management: Häufig gestellte Fragen zu Anwendungsverteilung

Gelegentlich können Sie ein Verhalten bei der Verteilung von Anwendungen feststellen, das Sie nicht erwarten. Dieser Artikel befasst sich mit einigen häufig gestellten Fragen und erläutert, welche Punkte Sie beachten müssen, wenn die Anwendungsverteilung nicht erwartungsgemäß funktioniert.

Wo wird der Controller für die Verteilung von Anwendungen ausgeführt?

Verwenden Sie die Administrationskonsole oder Scripts, um zu bestimmen, wo der Controller für die Verteilung von Anwendungen ausgeführt wird. Zum Überprüfen der Position klicken Sie in der Administrationskonsole auf Laufzeitoperationen > Komponentenstabilität > Basiskomponenten. Führen Sie auch das Script "checkPlacementLocation.jacl" aus, um den Server anzuzeigen, auf dem der Controller für die Verteilung von Anwendungen ausgeführt wird.

Wann startet der Controller für die Verteilung von Anwendungen einen Server?

Der Controller für die Verteilung von Anwendungen startet einen Server,
  • um die Anforderungen hinsichtlich der Mindestanzahl der für den dynamischen Cluster definierten Anwendungsinstanzen zu erfüllen,
  • wenn eine Anforderung, die sich auf einen inaktivierten dynamischen Cluster bezieht, an einen On Demand Router weitergeleitet wird,
  • wenn ein dynamischer Cluster von zusätzlicher Kapazität profitieren kann. Der Autonomic Request Flow Manager sendet ein Signal, das angibt, welchen Nutzen ein dynamischer Cluster von zusätzlicher Kapazität hätte, und es werden weitere Instanzen für den dynamischen Cluster gestartet.
Die Nachrichten in der Datei "SystemOut.log" geben Aufschluss darüber, welche Komponenten im Hinblick auf den Controller für die Verteilung von Anwendungen aktiv sind.

Wann stoppt der Controller für die Verteilung von Anwendungen einen Server?

Der Controller für die Verteilung von Anwendungen stoppt einen Server aus folgenden Gründen:

  • Es gibt Vorgaben hinsichtlich des Speicherplatzes für den Knoten. Der Controller für die Verteilung von Anwendungen kennt die Mindestanforderungen für den dynamischen Cluster oder die für den dynamischen Cluster benötigte Kapazität und die Systemvorgaben hinsichtlich Prozessorleistung und Speicherplatz. Wenn der auf einem Knoten verfügbare Speicher knapp wird, versucht der Controller für die Verteilung von Anwendungen, Instanzen zu stoppen und die Auslagerungsvorgänge des Knotens zu verhindern.
  • Der dynamische Cluster ist für verzögerten Anwendungsstart und proaktiven Stopp wegen Inaktivität konfiguriert, und es besteht keine Nachfrage nach dem dynamischen Cluster. Wenn keine Nachfrage nach dem dynamischen Cluster besteht, versucht der Controller für die Verteilung von Anwendungen, Instanzen dieses Clusters zu stoppen, um die Ressourcennutzung eines inaktiven dynamischen Clusters zu beenden.

Warum hat der Controller für die Verteilung von Anwendungen keinen Server gestartet?

Der Controller für die Verteilung von Anwendungen zeigt aus einem der folgenden Gründe nicht an, dass der Server gestartet ist:

  • In der Konfiguration ist die dynamische Verteilung von Anwendungen nicht aktiviert:
    1. Prüfen Sie, ob der Verteilungscontroller aktiviert ist. Klicken Sie in der Administrationskonsole auf Betriebsbedingte Richtlinien > Autonomic Manager > Controller für die Verteilung von Anwendungen.
    2. Stellen Sie sicher, dass die betroffenen Cluster dynamische Cluster sind. Der Controller für die Verteilung von Anwendungen funktioniert nur für dynamische Cluster. Klicken Sie in der Administrationskonsole auf Server > Dynamische Cluster. Vergewissern Sie sich, dass im Feld Betriebsmodus der betroffenen Cluster der Wert Automatisch ausgewiesen ist. Sollte dies nicht der Fall sein, wählen Sie die dynamischen Cluster, und klicken Sie anschließend auf den Betriebsmodus Automatisch. Nach der Auswahl des Betriebsmodus "Automatisch" für Ihre dynamischen Cluster klicken Sie auf Modus festlegen.
    3. Stellen Sie sicher, dass der konfigurierte Mindestzeitraum zwischen den Verteilungsänderungen nicht zu hoch gewählt ist. Klicken Sie in der Administrationskonsole auf Betriebsbedingte Richtlinien > Autonomic Manager > Controller für die Verteilung von Anwendungen. Geben Sie im Feld Zeitlicher Mindestabstand zwischen den Verteilungsänderungen einen geeigneten Wert ein. Die zulässigen Werte liegen zwischen 1 Minute und 24 Stunden.
  • Zeitlimit für Serveroperationen ist zu niedrig angesetzt.

    In manchen Fällen startet der Controller für die Verteilung von Anwendungen einen Server nicht, weil die Serveroperation das Zeitlimit überschreitet. Sie können das zulässige Zeitlimit in der Administrationskonsole konfigurieren. Klicken Sie auf Betriebsbedingte Richtlinien > Autonomic Manager > Controller für die Verteilung von Anwendungen. Bearbeiten Sie die Einstellung im Feld Zeitlimit für Serveroperation. Wenn Ihre Zelle groß oder das System langsam ist oder das System ein hohe Workload hat, geben Sie in diesem Feld einen höheren Wert an. Dieser Wert gibt die Startzeit für jeden Server an, das Zeitlimit richtet sich jedoch nach der Anzahl der Server in Ihrer Zelle. Wenn Sie z. B. fünf Server haben und der Wert auf 10 Minuten festgelegt ist, tritt die Zeitlimitüberschreitung nach 50 Minuten ein.

  • Verfügbarer Speicher nicht ausreichend:
    • Sie können feststellen, wann nicht genügend Speicher vorhanden ist, indem Sie in der Datei "SystemOut.log" die Anzahl der fehlgeschlagenen Starts feststellen.
    • Der Controller für die Verteilung von Anwendungen nutzt die folgenden Formeln, um die Speicherbelegung eines Members eines dynamischen Clusters zu berechnen:
      • Wenn keine anderen Instanzen des dynamischen Clusters aktiv sind (Kaltstart):
        Nutzung des Serverhauptspeichers = 1,2 * maximale_Größe_des_Heapspeichers + 64 MB
      • Wenn andere Instanzen des dynamischen Clusters aktiv sind, verwendet der Hauptspeicher-Profiler des Controllers für die Verteilung von Anwendungen die folgende Formel:
        Nutzung des Serverhauptspeichers = 0,667 * Größe_des_residenten_Speichers + 0,333 * Größe_des_virtuellen_Speichers
    • Speicherprofile bleiben beim Neustart des Controllers für die Verteilung von Anwendungen nicht bestehen.
    Wenn Sie Fehler beheben möchten, können Sie den Speicher-Profiler des Controllers für die Verteilung von Anwendungen inaktivieren, indem Sie die angepasste Eigenschaft "memoryProfile.isDisabled" auf true setzen.
Informationen zu fehlgeschlagenen Starts anzeigen
Hinweis: Die Liste der fehlgeschlagenen Starts bleibt beim Neustart des Controllers für die Verteilung von Anwendungen bzw. bei Verschiebungen des Controllers zwischen Knoten nicht bestehen.
Sie können Informationen zu fehlgeschlagenen Starts mit einer der folgenden Optionen anzeigen:
  • Verwenden Sie das Script PlacementControllerProcs.jacl, um fehlgeschlagene Serveroperationen abzufragen.
    Führen Sie den folgenden Befehl aus:
    ./wsadmin.sh -profile PlacementControllerProcs.jacl -c "anyFailedServerOperations"
  • Befehle im Tool "wsadmin" verwenden, um fehlgeschlagene Starts anzuzeigen.
    Sie können beispielsweise die folgenden Befehle ausführen:
    wsadmin>apc = AdminControl.queryNames('WebSphere:type=PlacementControllerMBean,process=dmgr,*')
    wsadmin>print AdminControl.invoke(apc,'anyFailedServerOperations')
    Wenn der Server wieder verfügbar ist, wird das Flag für den fehlgeschlagenen Start entfernt. Sie können mit dem folgenden Befehl des Tools "wsadmin" die Server aufzulisten, für die das Flag für fehlgeschlagenen Start aktiviert ist:
    wsadmin>print AdminControl.invoke(apc,'anyFailedServerOperations') OpsManTestCell/xdblade09b09/DC1_xdblade09b09
  • Fehlgeschlagene Starts in der Datei SystemOut.log anzeigen.

Warum hat der Controller für die Verteilung von Anwendungen mehr Server gestartet als erwartet?

Es werden möglichweise mehr Server gestartet werden als erwartet, wenn Probleme im Netz oder bei der Datenübertragung verhindern, dass der Controller für die Verteilung von Anwendungen die Bestätigungsnachricht zum Start eines Servers empfängt. Empfängt der Controller für die Verteilung von Anwendungen keine Bestätigung, startet er möglicherweise einen weiteren Server.

Warum hat der Controller für die Verteilung von Anwendungen mehrere Tasks für das Starten desselben Servers übergeben?

Ein möglicher Grund für dieses Verhalten kann die Tatsache sein, dass der Controller für die Verteilung von Anwendungen auf mehreren Servern ausgeführt wird. Dieses Szenario kommt häufig in heterogenen Topologien vor, in denen eine Zelle der WebSphere Application Server Version 8.5 auch einen Knoten der WebSphere Virtual Enterprise Version 6.1.x enthält. Der Controller für die Verteilung von Anwendungen wird auf beiden Knoten ausgeführt: auf dem Knoten der WebSphere Application Server Version 8.5 und auf dem Knoten der WebSphere Virtual Enterprise Version 6.1.x. Knoten der WebSphere Application Server Version 8.5 und der WebSphere Virtual Enterprise Version 6.1.x verwenden standardmäßig verschiedene Hochverfügbarkeitslösungen. Deshalb sind mehrere Controller für die Verteilung von Anwendungen aktiv. Sie können das Problem beheben, indem Sie das Script useBBSON.py im Deployment Manager ausführen und die Zelle erneut starten. Das Script setzt die angepassten Zelleneigenschaften, um sicherzustellen, dass überall in der Zelle dieselbe Hochverfügbarkeitslösung verwendet und dass nur ein einziger Controller für die Verteilung von Anwendungen gestartet wird.

Wie erfahre ich, wann der Controller für die Verteilung von Anwendungen eine Aktion abgeschlossen hat bzw. abschließen wird?

Sie können die Aktionen des Controllers für die Verteilung von Anwendungen mit Laufzeittasks überprüfen. Klicken Sie zum Anzeigen von Laufzeittasks auf Systemverwaltung > Taskverwaltung > Laufzeittasks. Die Liste der Laufzeittasks enthält Tasks, die vom Controller für die Verteilung von Anwendungen ausgeführt werden, und bestätigt, dass Änderungen vorgenommen wurden. Jede Laufzeittask hat den Status "Erfolgreich", "Fehlgeschlagen" oder "Unbekannt". Der Status "Unbekannt" bedeutet, dass keine Bestätigung vorliegt, dass die Task erfolgreich ausgeführt wurde.

Wie funktioniert der Controller für die Verteilung von Anwendungen mit VMware? Welche Hardwarevirtualisierungsumgebungen werden unterstützt?

Weitere Informationen zur Funktionsweise des Controllers für die Verteilung von Anwendungen mit VMware und anderen Hardwarevirtualisierungsumgebungen finden Sie in den Abschnitten zu Virtualisierung und Intelligent Management und zu den unterstützten Servervirtualisierungsumgebungen.

Wie kann ich einen Server starten oder stoppen, ohne den Controller für die Verteilung von Anwendungen zu beeinträchtigen?

Wenn Sie einen Server starten oder stoppen, während der dynamische Cluster sich im Modus "Automatisch" befindet, kann es geschehen, dass der Controller für die Verteilung von Anwendungen Änderungen an Ihren Aktionen vornimmt. Um Beeinträchtigungen des Controllers für die Verteilung von Anwendungen beim Starten oder Stoppen eines Servers zu vermeiden, müssen Sie den dynamischen Cluster in den Modus "Manuell" versetzen, bevor Sie einen Server starten oder stoppen.

Wie legt der Controller für die Verteilung von Anwendungen in einem heterogenen System (gemischtes System mit Hardware oder Betriebssystemen) fest, wo ein Serverstart erfolgt?

Die Zugehörigkeitsrichtlinie für einen dynamischen Cluster definiert die auswählbaren Knoten, auf denen die Server gestartet werden können. In dieser Knotengruppe wählt der Controller für die Verteilung von Anwendungen einen Knoten aus, auf dem ein Server gestartet werden soll. Dabei berücksichtigt er Systemvorgaben, z. B. für verfügbare Prozessor- und Speicherkapazität. Der Controller für die Verteilung von Anwendungen legt die Verteilung von Servern nicht auf der Basis von Betriebssystemen fest.

Wann startet der Controller für die Verteilung von Anwendungen einen anderen Server, wenn mein dynamischer Cluster unter Last ist?

Der Controller für die Verteilung von Anwendungen wirkt mit dem Autonomic Request Flow Manager (ARFM) zusammen und verwendet definierte Servicerichtlinien, um den Zeitpunkt eines Serverstarts zu bestimmen. Servicerichtlinien legen für Anwendungen die Maximalwerte hinsichtlich Leistung und Priorität fest und unterstützen die autonomen Controller bei Entscheidungen hinsichtlich der Regulierung des Datenverkehrs und der Kapazitätsbereitstellung. Die Ziele von Servicerichtlinien beeinflussen indirekt die Aktionen, die vom Controller für die Verteilung von Anwendungen ausgeführt werden. Der Controller für die Verteilung von Anwendungen orientiert sich bei der Bereitstellung weiterer Server an den Informationen, die er vom Autonomic Request Flow Manager erhält. Diese Informationen machen eine Aussage darüber, wie viel Kapazität für die gleichzeitigen Anforderungen, die von den ARFM-Warteschlangen bearbeitet werden, erforderlich ist. Die Anzahl der Anforderungen hängt davon ab, wie viel Kapazität jede Anforderung bei der Verarbeitung benötigt, und davon, wie viele gleichzeitige Anforderungen der ARFM für angemessen hält. Die Anzahl der gleichzeitigen Anforderungen basiert auf der Anwendungspriorität, dem Anwendungsziel usw.

Die Leistungsziele, die von den Servicerichtlinien definiert werden, sind keine Garantien. Intelligent Management kann die Reaktionszeit einer Anwendung nicht kürzer machen, als durch den entsprechenden Grenzwert zugelassen. Wenn bereits genügend Kapazität bereitgestellt wurde, um die Nachfrage zu befriedigen, wird keine zusätzliche Kapazität bereitgestellt, selbst wenn das einen Verstoß gegen das Ziel der Servicerichtlinie bedeutet. Intelligent Management kann verhindern, dass unrealistische Ziele von Servicerichtlinien eine Instabilität der Umgebung zur Folge haben.

Wie bestimmt der Controller für die Verteilung von Anwendungen die maximale Größe des Heapspeichers für meinen Server?

Sie können die Größe des Heapspeichers für den Server in der Schablone des dynamischen Clusters ändern. Weitere Informationen finden Sie Abschnitt zum Ändern der Größe des JVM-Heapspeichers.

Warum übernehmen die dynamischen Cluster die Eigenschaften aus der Schablone nicht?

Sie müssen dynamische Cluster im Master-Repository speichern, bevor Sie Änderungen an der Serverschablone vornehmen. Wenn Sie feststellen, dass Member des dynamischen Clusters die Eigenschaften aus der Schablone nicht übernehmen, wurden wahrscheinlich in einem noch nicht gespeicherten Arbeitsbereich Änderungen an der Serverschablone vorgenommen. Sie können dieses Problem beheben, indem Sie den dynamischen Cluster löschen und anschließend erneut erstellen.

Speichern Sie Ihre Änderungen im Master-Repository. Wenn Sie nach dem Anklicken von Fertig stellen sicherstellen möchten, dass die Änderungen auch wirklich im Master-Repository gespeichert werden, klicken Sie im Nachrichtenfenster auf Speichern. Klicken Sie im Fenster In Master-Konfiguration speichern erneut auf Speichern. Klicken Sie auf Änderungen mit Knoten synchronisieren.

Warum hat mein dynamischer Cluster zu wenige aktive Server?

Falls Fehler auftreten, weil nicht genügend Server im dynamischen Cluster aktiv sind, können Sie die folgenden Aktionen ausführen:
  • Falls die Knoten in der Knotengruppe nicht sehr häufig verwendet werden, überprüfen Sie, ob die Bedingungen der Servicerichtlinie erfüllt sind. Manchmal ist die Richtlinie nicht eindeutig definiert, und das System kann die Bedingungen entgegen Ihrer Erwartungen erfüllen. Zum Überprüfen oder Ändern einer Servicerichtlinie klicken Sie in der Administrationskonsole auf Betriebsbedingte Richtlinien > Servicerichtlinien > Vorhandene Richtlinie auswählen. Überprüfen Sie Zieltyp, Zielwert und Bedeutung der Richtlinie und nehmen Sie gegebenenfalls die erforderlichen Änderungen vor.
  • Falls die Knoten in der Knotengruppe stark ausgelastet sind, können Sie die Ziele der Servicerichtlinie dieses Clusters mit den Zielen der Servicerichtlinie anderer aktiver Cluster vergleichen. Sollte der diesem Cluster zugewiesene Datenverkehr im Vergleich mit den anderen Clustern eine geringere Bedeutung oder nicht so strenge Serviceziele haben, liegt es nahe, dass das System für diesen Cluster weniger Server instanziert. Zum Überprüfen oder Ändern einer Servicerichtlinie klicken Sie in der Administrationskonsole auf Betriebsbedingte Richtlinien > Servicerichtlinien > Vorhandene Richtlinie auswählen.
  • Wenn die Knotengruppe einen Kapazitätsüberschuss zu haben scheint, die Servicerichtlinien aber trotzdem nicht erfüllt werden, überprüfen Sie die Konfigurationseinstellungen für den dynamischen Cluster. Möglicherweise wurden aufgrund der Richtlinieneinstellung "maxInstances" zu wenig Instanzen des dynamischen Clusters erstellt.

Warum kann der Controller für die Verteilung von Anwendungen in einer dynamischen Clusterumgebung die verfügbaren Server nicht auf die Knoten verteilen?

Die dynamische Anwendungsverteilung basiert auf der Lastverteilung, der Servicerichtlinie und den verfügbaren Ressourcen. Wenn die maximale Anzahl an Anwendungsinstanzen in einem dynamischen Cluster reduziert wird, stoppt der Controller für die Verteilung von Anwendungen so viele Server auf Knoten mit der höchsten Workload, bis die Anzahl der Server den definierten Maximalwert erreicht ist. Wenn alle Knoten verfügbar sind, wählt der Controller für die Verteilung von Anwendungen den ersten Knoten in der Liste aus und fährt dann mit dem nächsten Knoten in der Liste fort, bis die maximale Anzahl erreicht ist.

Wenn die maximale Anzahl an Anwendungsinstanzen in mehreren dynamischen Clustern reduziert wird, die auf denselben Knoten ausgeführt werden, wird derselbe Prozess angewendet. Der Controller für die Verteilung von Anwendungen stoppt so viele Server in jedem dynamischen Cluster, bis die Anzahl der Server die definierte Maximalanzahl für jeden dynamischen Cluster erreicht. Da alle Server in jedem dynamischen Cluster auf denselben Knoten ausgeführt werden, ist die Knotenauswahlreihenfolge für das Stoppen der Server für jeden dynamischen Cluster dieselbe.
Anmerkung: Wenn mindestens ein Knoten unter Last steht, leitet der Controller für die Verteilung von Anwendungen eine dezentralere Verteilungslösung ein.

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=rwve_odappfail
Dateiname:rwve_odappfail.html