WebSphere Virtual Enterprise, Version 6.1.1
             Betriebssysteme: AIX, HP-UX, Linux, Solaris, Windows,


Autonomic Request Flow Manager konfigurieren

Sie können den Autonomic Request Flow Manager (ARFM) optimieren, indem Sie die Standardeinstellungen über die Administrationskonsole ändern.

Vorbereitungen

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 dieser Task

Der Autonomic Request Flow Manager enthält die folgenden Komponenten:
  • Ein Controller für die Rechenleistung pro Zielzelle, wie z. B. eine Zelle, an die einige ARFM-Gateways Anforderungen direkt senden. Es handelt sich hierbei um ein HAManagedItem-Objekt, das in einem Node Agent, On Demand Router oder Deployment Manager ausgeführt wird.
  • 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 Gateways fangen die eingehenden HTTP-, SIP-, JMS- und IIOP-Anforderungen ab und reihen sie in eine Warteschlange ein, während der Controller Steuersignale oder Anweisungen an die Gateways und den Verteilungscontroller übermittelt. Basierend auf der Beobachtung des Systembetriebs schätzt der Work-Profiler fortlaufend die Anforderungen bezüglich der Rechenleistung für die verschiedenen Arten von Anforderungen. In Zusammenarbeit sorgen diese Komponenten dafür, dass die Prioritäten für die eingehenden Anforderungen ordnungsgemäß vergeben werden.

Wenn Sie das Produkt Compute Grid zusammen mit dem Produkt WebSphere Virtual Enterprise verwenden, wird die dynamische Anwendungsverteilung mit dem Job-Scheduler unterstützt. Der Controller für die Verteilung von Anwendungen sorgt zusammen mit dem Scheduler und dem Autonomic Request Flow Manager für einen Überlastungsschutz, solange die Online- und Stapel-Workloads in dynamischen Clustern verarbeitet werden. Dieser Überlastungsschutz wird für statische Cluster nicht unterstützt. Da Stapeljobs sehr viel Prozessorkapazität konsumieren und eine lange Laufzeit haben können, kann das Nutzungslimit für den Server überschritten werden.

Wenn das Produkt WebSphere Virtual Enterprise zusammen mit dem Produkt Compute Grid installiert ist, konsultiert der Job-Scheduler während der Auswahl seines Endpunkts den Controller für die Verteilung von Anwendungen. Sie können die angepasste Eigenschaft "UseAPCEndpointSelection" mit dem Wert false im Job-Scheduler konfigurieren, um die Integration des Controllers für die Verteilung von Anwendungen und des Job-Schedulers zu inaktivieren. Verwenden Sie diese angepasste Eigenschaft, um den Controller für die Verteilung von Anwendungen während des Endpunktauswahlprozesses des Job-Schedulers zu inaktivieren.

Prozedur

  1. Ändern Sie die entsprechenden Einstellungen des Autonomic Request Flow Manager. Klicken Sie in der Administrationskonsole auf Betriebsbedingte Richtlinien > Autonome Manager > Autonomic Request Flow Manager.
  2. Klicken Sie auf OK oder Anwenden, nachdem Sie Ihre Änderungen vorgenommen haben.
  3. Klicken Sie auf Speichern, um die Änderungen im Master-Repository zu speichern.
  4. Testen Sie die soeben definierten Einstellungen und nehmen Sie gegebenenfalls so oft weitere Anpassungen vor, bis die gewünschte Leistung für den Anforderungsfluss erreicht ist.

Beispiel

Die folgende Tabelle enthält spezifische Anleitungen für die Konfiguration jeder einzelnen Einstellung.
Tabelle 1. Konfigurationseigenschaften des Autonomic Request Flow Manager
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 WebSphere Virtual Enterprise 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 WebSphere Virtual Enterprise reagieren, wenn auch mit Verzögerung, auf Workload-Schwankungen. 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 WebSphere Virtual Enterprise 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.

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:
  1. Definieren Sie Servicerichtlinien mit erreichbaren Leistungszielen, und setzen Sie den Zieltyp der Richtlinien auf "Antwortzeit" oder "Perzentil", aber nicht auf "Nach Ermessen".
  2. Definieren Sie in der ARFM-Anzeige einen Grenzwert für die CPU-Auslastung, der nicht höher ist als 90 %. Wählen Sie die dritte Schaltfläche für Zurückweisungsrichtlinie aus. Die Zurückweisungsrichtlinie bestimmt, ob die Zugangssteuerung für Überlastungsschutz des Prozessors aktiviert wird, und, wenn ja, in welchem Bezug der Schwellenwert für die Antwortzeit, der für die Zugangssteuerung verwendet wird, zum Schwellenwert für die Antwortzeit steht, der im Leistungsziel angegeben ist.
  3. Definieren Sie auf Zellenebene eine angepasste Eigenschaft mit dem Namen "arfmInitialMsgDlgRatio". Der Wert dieser Eigenschaft ist ein Gleitkommawert, der die erste Schätzung für das Verhältnis jedes dialogfortsetzenden Nachrichtenflusses zum dialogeinleitenden Nachrichtenfluss derselben Protokollfamilie/Implementierungsziel-Kombination darstellt, d. h. die Anzahl der eingehenden Folgenachrichten pro Dialog. Setzen Sie "arfmInitialMsgDlgRatio" auf einen für die Sammlung aller dialogfortsetzenden Nachrichtenflüsse vergleichbaren Wert.

    Diese angepasste Eigenschaft ist auch relevant, wenn die Dialogorientierung für den Überlastungsschutz des Prozessors und einen differenzierten Service aktiviert ist.

  4. Speichern Sie Ihre Änderungen.

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.

Weitere Informationen finden Sie im Artikel Schutz vor Speicherüberlastung .

Gibt die maximale Menge des Heap-Speichers für jeden Anwendungsserver in Prozent an.

Maximale Größe des Heap-Speichers 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 Überlastbedingung 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.

Nächste Schritte

Verwenden Sie die mustGather-Dokumente, um Fehler beim Autonomic Request Flow Manager und bei der Anwendungsverteilung zu beheben. Die mustGather-Dokumente werden vom Unterstützungsteam für jede Version von WebSphere Extended Deployment bereitgestellt und verwaltet.




Zugehörige Konzepte
Schutz vor Speicherüberlastung
Zugehörige Tasks
Umgebung von WebSphere Virtual Enterprise verwalten
Geschwindigkeitsfaktoren in Konfigurationen mit mehreren Schichten konfigurieren
Eine Servicerichtlinie definieren
Zugehörige Verweise
Verwaltungsrollen und Berechtigungen
Script arfmController.py
Zugehörige Informationen
Angepasste Eigenschaften für den Autonomic Request Flow Manager
Erweiterte angepasste Eigenschaften für den Autonomic Request Flow Manager
Task-Artikel    

Nutzungsbedingungen | Feedback

Letzte Aktualisierung: 24.09.2009 16.39 Uhr EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/odoe_task/todtunearfm.html