![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Autonomic Request Flow Manager konfigurieren
Sie können den Autonomic Request Flow Manager (ARFM) optimieren, indem Sie die Standardeinstellungen über die Administrationskonsole ändern. Sie können den knotenbasierten ARFM aktivieren, indem Sie eine angepasste Eigenschaft definieren.
Vorbereitende Schritte
Wenn Sie die Einstellungen für den Autonomic Request Flow Manager ändern möchten, müssen Sie die Verwaltungsberechtigungen der Rolle "Bedienung" (Operator), "Konfiguration" (Configurator) oder "Verwaltung" (Administrator) haben. Wenn Sie die Rolle "Bedienung" haben, können Sie nur die Informationen auf der Registerkarte "Konfiguration" anzeigen, aber die Einstellungen auf der Registerkarte "Laufzeit" nicht ändern. Wenn Sie die Rolle "Konfiguration" haben, können Sie die Einstellungen auf der Registerkarte "Konfiguration" ändern, aber nicht die Einstellungen auf der Registerkarte "Laufzeit". Wenn Sie die Rolle "Verwaltung" haben, haben Sie alle Berechtigungen.
Wenn die Sicherheit aktiviert ist, können einige Felder nur mit der entsprechenden Sicherheitsberechtigung editiert werden.
Informationen zu diesem Vorgang
- Ein Controller pro Zielzelle, wie z. B. eine Zelle, an die ein ARFM-Gateway Anforderungen direkt sendet. Es handelt sich hierbei um einen HAManagedItem-Prozess, der in einem beliebigen Node Agent oder Deployment Manager ausgeführt werden kann.
- Ein Gateway pro verwendeter Kombination von Protokollfamilie, Proxy-Prozess und Implementierungsziel. Ein Gateway wird in einem eigenen Proxy-Prozess ausgeführt. Für HTTP-Anforderungen und SIP-Anforderungen sind die On Demand Router die Proxy-Prozesse. Für JMS-Anforderungen (Java™ Message Service) und IIOP-Anforderungen sind die Anwendungsserver von WebSphere Application Server die Proxy-Prozesse.
- Ein Schätzprogramm für den Arbeitsfaktor pro Zelle. Dabei handelt es sich um einen HAManagedItem-Prozess, der in einem Node Agent, ODR oder Deployment Manager ausgeführt werden kann.
Die Funktion für dynamische Verteilung wird mit dem Job-Scheduler auf z/OS-Servern nicht unterstützt.
Vorgehensweise
Knotenbasierten ARFM aktivieren
Feld | Zweck | Tipps für die Einstellung |
---|---|---|
Aggregationszeitraum | Jedes ARFM-Gateway verteilt in gewissen Zeitabständen aggregierte Statistiken. Mit diesem Parameter wird das Verteilungsintervall definiert. Die von den Gateways berichteten Statistiken unterstützen Folgendes: Erstellung von Laufzeitdiagrammen in der Administrationskonsole, Betrieb von ARFM-Controllern, Betrieb des Controllers für die Verteilung von Anwendungen und Betrieb von Work-Profilern. | Der Aggregationszeitraum muss so eingestellt werden, dass eine ausreichende Anzahl von Leistungsproben erfasst werden kann. Die Gateways erfassen Proben für jede HTTP-Anforderung. Es sind mehrere Hundert Proben erforderlich, um eine zuverlässige Bemessungsgrundlage für die Statistiken zu schaffen. Beispiel: Die Ausführungsdauer von Anforderungen, die einer Serviceklasse zugeordnet sind, beträgt 250 Millisekunden, und es werden durchschnittlich 10 Anforderungen parallel ausgeführt. Der Wert für die parallele Ausführung wird automatisch basierend auf der Clustergröße und den Ressourcen in der Umgebung berechnet. Der Wert für die parallele Ausführung erscheint in der Konsole in den Visualisierungsanzeigen in der Kategorie "Laufzeitoperationen". Demzufolge verarbeitet die Serviceklasse ungefähr 40 Anforderungen pro Sekunde. Wenn Sie im Feld "Aggregationszeitraum" den Wert 15 Sekunden festlegen, werden in jedem Aggregationszeitraum 600 Proben erfasst. Die Messwerte, die auf einer Grundlage von 600 Proben basieren, sind hilfreich und zuverlässig. Die Wahl eines zu kurzen Aggregationszeitraums führt zu unzuverlässigen Leistungsmesswerten. Die Leistungsmesswerte, die auf einer geringeren Anzahl von Proben basieren, sind ungenauer und weniger zuverlässig. Da der ARFM-Controller beim Erzeugen neuer Statistiken aktiviert wird, werden die Steuereinstellungen bei der Wahl eines zu kurzen Aggregationszeitraums seltener neu berechnet. Deshalb reagiert Intelligent Management träger auf plötzliche Änderungen bei Intensität und Muster des Datenverkehrs. |
Mindestlänge des Steuerzyklus | Dieser Parameter definiert, wie oft der ARFM-Controller aktiviert wird. Die Controlleraktivierung ist der Prozess, bei dem die Eingaben ausgewertet und diesbezügliche neue Steuereinstellungen erzeugt werden. Der Aktivierungsprozess für den ARFM-Controller wird eingeleitet, wenn neue Statistiken von einem der Gateways empfangen werden und der Zeitraum seit der letzten Aktivierung größer-gleich der Mindestlänge des Steuerzyklus ist oder der Controller noch nie zuvor aktiviert worden ist. | Diese Einstellung bestimmt die Mindestdauer des Steuerzyklus. Wenn Sie beispielsweise nur einen ODR haben und den Aggregationszeitraum auf 30 Sekunden und die Mindestlänge des Steuerzyklus auf 60 Sekunden festlegen, stellen Sie möglicherweise fest, dass eine Aktivierung um 12:00:00.0 und die nächste 90,1 Sekunden später um 12:01:30.1 stattfindet, weil die vorherigen Statistiken um 12:00:59.9 empfangen wurden. Um einen zuverlässigen Steuerzyklus von ungefähr 60 Sekunden zu gewährleisten, müssen Sie eine Mindestdauer von 58 oder 59 Sekunden für den Steuerzyklus festlegen. |
Gleitende Bereichsgrenze | Diese Einstellung definiert durch Verkettung von Gateway-Statistiken, wie sensibel der ARFM-Controller auf die eingehenden Gateway-Statistiken reagiert. Der ARFM-Controller jedes Gateway verwendet einen gleitenden Durchschnittwert, den er aus den jeweils letzten für das Gateway gelieferten Statistiken ermittelt. Die gleitende Bereichsgrenze steuert, wie viele Statistiken kombiniert werden. | Wenn die gleitende Bereichsgrenze sehr klein ist, ist der Controller sensibler und reagiert schneller. Eine kleinere gleitende Bereichsgrenze ist jedoch auch anfälliger für Rauschen und Anomalien. Das Produkt aus gleitender Bereichsgrenze und Aggregationszeitraum sollte in etwa der Länge des Steuerungszyklus entsprechen, der manchmal geringfügig größer ist als die konfigurierte Mindestlänge. |
Maximale Warteschlangenlänge | Mit diesem Parameter wird die maximale Anzahl von Anforderungen für die ARFM-Warteschlangen festgelegt. ARFM teilt den gesamten eingehenden Datenverkehr in Anforderungsflüsse ein und verwendet für jeden Anforderungsfluss eine eigene Warteschlange. Zu den Besonderheiten eines Datenflusses gehören Anforderungen, die eine bestimmte Serviceklasse haben, auf einem bestimmten Implementierungsziel bearbeitet werden oder über einen bestimmten ODR weitergeleitet werden. Wenn eine Anforderung eingeht und die entsprechende Warteschlange voll ist, wird die Anforderung zurückgewiesen. |
Wenn Sie in diesem Feld einen niedrigen Wert angeben, erhöht sich die Wahrscheinlichkeit, dass eine Anforderung bei einem kurzfristig erhöhten Datenverkehrsaufkommen zurückgewiesen wird, wohingegen ein höherer Wert zu einer längeren Verweildauer von Anforderungen in den Warteschlangen führen kann. Anforderungen, die in Warteschlangen verweilen, verbrauchen Speicherressourcen. Die Standardeinstellung ist 1000. Sie können jedoch verschiedene Werte ausprobieren, um die für Ihre Umgebung am besten geeignete Einstellung zu finden. |
Maximale CPU-Belastung | Der ARFM bietet neben seinen Funktionen für Prioritätsvergabe auch Funktionen für Überlastungsschutz. Ein ARFM stellt Anforderungen in seine Gateway-Warteschlangen, um eine Überlastung der Anwendungsserver zu verhindern. In diesem Release wird die Last anhand der Prozessorauslastung in der ersten Schicht von Anwendungsservern ermittelt. Der Parameter "Maximale CPU-Auslastung" teilt dem ARFM mit, wie stark die Server belastet werden können. Bei extremen Auslastungsspitzen kann dieser Grenzwert kurzfristig überschritten werden. |
Mit höheren Werten wird eine bessere Ressourcennutzung, mit niedrigeren Werten einen stabileren Betrieb erreicht. In Produktionsumgebungen ist die Workload Schwankungen unterlegen und variabel. Die Leistungsverwaltungstechniken in Intelligent Management reagieren, wenn auch mit Verzögerung, auf Workloadschwankungen. In dieser Reaktionszeit kann das System außerhalb der konfigurierten Grenzen arbeiten. Dies kann beispielsweise bedeuten, dass eine höhere als die konfigurierte Prozessorauslastung erreicht wird. Beim Betrieb mit einem Anwendungsserver bei 100 % Prozessorauslastung über mehrere Minuten hinweg wurde beobachtet, dass einige interne Kommunikationsmechanismen zum Nachteil vieler Features ausfallen. Die Leistungsverwaltung in diesem Release von Intelligent Management funktioniert nicht gut, wenn die erste Schicht von Anwendungsservermaschinen zusätzlich zu den WebSphere-Anforderungen, die per HTTP über die ODR ankommen, noch andere Anforderungen abwickeln. Diese Einstellung wirkt sich auf die Verteilung der Anwendungen aus. Wenn der geschätzte Gesamtbedarf über dem Grenzwert für Maximale CPU-Auslastung liegt, reduziert der Verteilungscontroller den Bedarf aller dynamischen Cluster einheitlich, bevor er die beste Verteilung berechnet. Setzen Sie den Wert dieser angepassten Eigenschaft auf false, um den Überlastungsschutz des Prozessors zu inaktivieren und eine Ordnung nach Prioritäten anzufordern. "arfmManageCpu" ist eine angepasste Zelleneigenschaft, die erstellt werden muss. Sie können die CPU-Auslastung wie folgt ermitteln:
|
Zugangssteuerung für CPU-Überlastungsschutz | Der Zweck der Zugangssteuerung für den Überlastungsschutz des Prozessors ist der, Dialoge bewusst nicht zu akzeptieren, wenn Einschätzungen bezüglich der Last, die maximal akzeptiert werden kann, ohne die Rechenleistung der verwalteten Knoten und die Antwortzeiten der akzeptierten Nachrichten zu beeinträchtigen, dagegen sprechen. Der Wert für die Zugangssteuerung für den CPU-Überlastungsschutz gilt nur für HTTP- und SIP-Anforderungen, nicht für IIOP- und JMS-Anforderungen. Aktivieren Sie die Zugangssteuerung, wenn die Warteschlangensteuerung für den Überlastungsschutz des Prozessors nicht ausreicht und es wichtig ist, bestimmte angebotene Lasten bewusst ablehnen zu können. |
Diese Einstellung ist standardmäßig inaktiviert. Wenn Sie sie konfigurieren möchten, gehen Sie wie folgt vor:
Die Zugangssteuerung für den Überlastungsschutz des Prozessors funktioniert, wenn die Prozessorauslastung auf einem System mit hoher Arbeitslast mit der Einstellung für den Überlastungsschutz des Prozessors nahezu identisch ist. |
Informationen zum Speicherüberlastungsschutz | Gibt die maximale Menge des Heapspeichers für jeden Anwendungsserver in Prozent an. |
Maximale Größe des Heapspeichers von WebSphere Application Server in Prozent. Legen Sie einen Wert unter 100 fest. |
Zurückweisungsrichtlinie | Legt das Verhalten für HTTP-, SIP- und SOAP-Anforderungen fest, die einem Leistungsziel zugeordnet sind, wenn eine Überlastungsbedingung festgestellt wird. |
Wählen Sie eine der Optionen aus, um festzulegen, wann Nachrichten zurückgewiesen werden sollen, um eine Überlastung der CPU zu verhindern. Sie können angeben, dass keine Nachrichten zurückgewiesen werden sollen, oder einen Schwellenwert für die Zurückweisung angeben, der bestimmt, wann Nachrichten zurückgewiesen werden. Standardmäßig werden keine Nachrichten zurückgewiesen. Bei Arbeit des Typs 'Nach Ermessen' wird von einem Antwortzeitschwellenwert von 60 Sekunden ausgegangen. |
Zum Aktivieren des knotenbasierten ARFM müssen Sie die angepasste Eigenschaft arfmQueueMode auf den Wert node setzen. Wenn bei Verwendung dynamischer Cluster im Automatikmodus ein CPU-basierter Prädiktor für APC verwendet werden soll, müssen Sie die angepasste Eigenschaft APC.predictor auf CPU setzen.
Nächste Schritte
Verwenden Sie die mustGather-Dokumente, um Fehler beim Autonomic Request Flow Manager und bei der Anwendungsverteilung zu beheben.