WebSphere Extended Deployment, Version 6.0.x     Betriebssysteme: AIX, HP-UX, Linux, Solaris, Windows, z/OS

Vitalitäts-Policy erstellen

Eine Vitalitäts-Policy ist die Definition bestimmter Vitalitätskriterien, gegen die sich WebSphere Extended Deployment schützen soll. Die Funktion für Vitalitätsüberwachung verwendet die definierte Policy, während sie die Anwendungsserverumgebung auf Softwarestörungen überprüft.

Gründe und Szenarios für die Ausführung dieser Task

Führen Sie die Schritte für diese Task aus. Sie können Vitalitäts-Policys auch mit Scripting erstellen und verwalten. Nähere Informationen hierzu finden Sie im Artikel Vitalitäts-Policys mit Scripting verwalten.
  1. Klicken Sie in der Administrationskonsole auf Betriebsbedingte Policys > Vitalitäts-Policys > Neu.
  2. Definieren Sie allgemeinen Merkmale für die Vitalitäts-Policy.
    1. Legen Sie einen Namen für die Vitalitäts-Policy fest. Der Name muss innerhalb der Vitalitäts-Policys eindeutig sein und bestimmten Namenskriterien entsprechen. Die Namenskriterien sind in der Hilfeanzeige zur Konsole für Vitalitäts-Policys beschrieben.
    2. OptionalColonSymbol Geben Sie eine Beschreibung für die Vitalitäts-Policy ein.
    3. Wählen Sie die Vitalitätsbedingung aus. Alle verfügbaren Bedingungen unterstützen einen Serverneustart als Reaktion. Die alters- und Workload-basierten Bedingungen sind präventive, die anderen erkennungsbasierte Bedingungen.
      • Eine altersbasierte Bedingung wird ausgelöst, wenn Member, die dieser Policy zugeordnet sind, ein bestimmtes Alter erreichen.
      • Eine Bedingung für überhöhte Anzahl von Überschreitungen des Anforderungszeitlimits trifft zu, wenn Anforderungen für ein zugehöriges Member das zulässige Zeitlimit überschreiten und der Prozentsatz der Zeitlimitüberschreitungen den angegebenen Wert überschreiten. Diese Bedingung unterstützt neben Serverneustarts auch die Ausgabe von Thread-Speicherauszügen.
        RestrictionColonSymbol Die Bedingung für überhöhte Anzahl von Überschreitungen des Anforderungszeitlimits gilt nicht für JMS- und IIOP-Datenverkehr.
      • Eine Bedingung für die Erkennung unangemessener Antwortzeiten trifft zu, wenn die Member, die dieser erkennungsbasierten Policy zugeordnet sind, durchschnittliche Antwortzeiten für Anforderungen aufweisen, die einen bestimmten Zeitwert überschreiten.
      • Eine Speicherbedingung: Überhöhte Speicherbelegung trifft zu, wenn die Member, die dieser erkennungsbasierten Policy zugeordnet sind, eine Speicherbelegung aufweisen, die für eine bestimmte Zeit einen bestimmten Prozentsatz der maximalen Größe des Heap-Speichers überschreiten.
      • Die Policy Speicherbedingung: Speicherverlust überwacht kontinuierliche Abwärtstrends bei der einem Server zur Verfügung stehenden freien Kapazität im Java-Heap-Speicher. Die eingestellte Erkennungsstufe bestimmt, wann diese Trends erkannt werden. Für die langsamere Erkennung werden die meisten Verlaufdaten benötigt. Für die normale und schnellere Erkennung wird dieselbe Menge von Verlaufdaten benötig, aber bei der schnelleren Erkennung ist eine Analyse der Daten möglich, bevor der Java-Heap-Speicher die konfigurierte Maximalgröße erreicht. Auf diese Weise ist eine frühere Erkennung möglich, die jedoch anfällig für Fehlalarme ist. Diese Bedingung unterstützt neben Serverneustarts die Erstellung von Heap-Speicherauszügen.
      • Eine Eskalationsbedingung erkennt Situationen, in denen Anforderungen an ein fehlerhaftes Cluster-Member weitergeleitet werden, das geringe Antwortzeiten aufweist. Die Erkennung von Eskalationen basiert auf der Erkennung von Änderungspunkten (oder Trendwenden) in Daten, die über einen bestimmten Zeitraum hinweg gemessen werden. Zum Erkennen von Änderungspunkten werden ein linker und ein rechter Durchschnittswert für einen bestimmten Punkt berechnet. Der linke Durchschnittswert eines Punkts umfasst N Proben, die vor diesem Punkt auftreten, und der rechte Durchschnittswert umfasst N Proben, einschließlich des Punkts selbst, die danach auftreten. Die Differenz zwischen dem linken und dem rechten Durchschnittswert wird gespeichert und mit anderen Differenzwerten in einem bestimmten Fenster N verglichen, um festzustellen, ob diese Differenz ein lokaler Maximalwert ist. Wenn dies die maximale Differenz ist, ist der Punkt, dem diese Differenz entspricht, ein Änderungspunkt (oder eine Trendwende). Die Messwerte, die für die Erkennung von Eskalationen verwendet werden, sind Antwortzeiten und dWLM-Wertigkeiten (Dynamic Workload Manager), die für den Server beobachtet werden.

        Die Policy mit einer schnelleren Erkennung und einer höheren Wahrscheinlichkeit von Fehlalarmen verwendet weniger Proben (N=10) für Antwortzeiten und dWLM-Wertigkeiten (Dynamisc Workload Manager) und versucht, basierend auf den Proben einen Änderungspunkt (oder eine Trendwende) in den Messwerten zu erkennen. Sie trifft Annahmen schneller, weil sie 20 Proben abwartet (10 für den linken Durchschnittswert und 10 für den rechten Durchschnittswert), um eine Abweichung bei den Durchschnittswerten zu berechnen und einen lokalen Maximalwert zu ermitteln. Die Proben werden in einem Intervall von 15 Sekunden erfasst. Eine Eskalation kann innerhalb von fünf Minuten nach ihrem Auftreten erkannt werden. Da die Anzahl der Proben geringer ist, besteht eine höhere Wahrscheinlichkeit falscher Alarme, wenn die Proben sehr viele Lastspitzen und -täler enthalten.

        Die Policy mit einer langsameren Erkennung und einer niedrigeren Wahrscheinlichkeit von Fehlalarmen verwendet mehr Proben (N=15) für Antwortzeiten und dWLM-Wertigkeiten (Dynamic Workload Manager). Sie trifft Annahmen weniger schnell, weil sie 30 Proben (15 für den linken Durchschnittswert und 15 für den rechten Durchschnittswert) abwarten muss, um eine Abweichung der Durchschnittswerte zu berechnen. Die Erkennungszeit beträgt sieben Minuten und 30 Sekunden. Da die Anzahl der Proben höher ist, wirken sich Proben mit Lastspitzen und -tälern nur geringfügig auf die Durchschnittswerte aus. Deshalb ist die Wahrscheinlichkeit von Fehlalarmen geringer.
        RestrictionColonSymbol Die Eskalationsbedingung gilt nicht für JMS- und IIOP-Datenverkehr.
      • Eine Workload-Bedingung trifft zu, wenn die Member, die dieser Policy zugeordnet sind, eine vom Benutzer definierte Anzahl von Anforderungen verarbeitet haben.
    4. Klicken Sie auf Weiter.
  3. Definieren Sie die Merkmale der Bedingung für die Vitalitäts-Policy. Die angezeigten Merkmale richten sich nach der ausgewählten Vitalitätsbedingung.
    Merkmale für Vitalitätsbedingung
    Maximales Alter
    In diesem Feld wird der Alterswert (Lebensdauer) für die altersbasierte Vitalitätsbedingung festgelegt. Die altersbasierte Vitalitäts-Policy startet die zugeordneten Member erneut, wenn sie ein bestimmtes Alter erreichen. Zulässige Werte sind positive ganze Zahlen zwischen 1 Stunde und 365 Tagen. Wenn Sie einen Wert wie beispielsweise 1,5 Tage angeben möchten, müssen Sie 36 Stunden angeben, da Dezimalzahlen nicht unterstützt werden.
    Prozentsatz der Anforderungen, die für Verstoß gegen die Bedingung das zulässige Zeitlimit überschreiten müssen
    In diesem Feld wird der Schwellenwert für den Prozentsatz der Zeitlimitüberschreitungen bei Anforderungen festgelegt. Die gültigen Werte für dieses Feld sind alle ganzen Zahlen zwischen 1 und 99.
    Antwortzeit
    Die Policy für die Erkennung unangemessener Antwortzeiten startet die Member erneut, wenn die Ausführung der durchschnittlichen Anzahl von Anforderungen eine bestimmte Dauer überschreitet. Die gültigen Werte für dieses Feld sind 1 Millisekunde bis 60 Minuten. Bei MDBs basiert die Antwortzeit auf der von der Methode onMessage genommenen Zeit. Bei synchronen Clients entspricht die Antwortzeit dem Zeitintervall zwischen Empfangsaufrufen eines Clients in demselben Sitzungsobjekt. Die Antwortzeit umfasst auch die Zeit, die in ARM-Warteschlangen verbracht wird.
    Prozentsatz der maximalen JVM-Heap-Speichergröße für Überwachung
    Die Policy für die Erkennung überhöhter Speicherbelegung startet die Member erneut, wenn die Speicherbelegung über einen bestimmten Zeitraum hinweg einen bestimmten Prozentsatz des Heap-Speichers überschreitet. Die gültigen Werte für dieses Feld sind alle ganzen Zahlen zwischen 1 und 99.
    Dauer der Überschreitung des Schwellenwertes für JVM-Heap-Speicher
    Die Policy für die Erkennung überhöhter Speicherbelegung startet die Member erneut, wenn die Speicherbelegung über einen bestimmten Zeitraum hinweg einen bestimmten Prozentsatz des Heap-Speichers überschreitet. Der Prozentsatz der Gesamtspeicherbelegung wird in Kombination mit dem Prozentsatz verwendet, um festzustellen, wann Member erneut gestartet werden müssen. Die gültigen Werte für dieses Feld sind 1 Sekunde bis 60 Minuten.
    Gesamtanzahl der Anforderungen
    Diese Feld ist verfügbar, wenn die ausgewählte Vitalitäts-Policy Workload-basiert ist. Die Workload-basierte Policy startet die Member erneut, wenn eine bestimmte, von Ihnen definierte Anzahl von Anforderungen bearbeitet wurde. Gültige Werte sind alle ganzen Zahlen zwischen 1000 und 9223372036854775807.
    Erkennungsstufe für Bedingung:
    Sie können zwischen den folgenden Optionen wählen:
    • Schnellere Erkennung, höhere Wahrscheinlichkeit von Fehlalarmen: Diese Option lässt eine schnellere Erkennung potenzieller Speicherverluste zu, hat aber eine höhere Wahrscheinlich von Fehlalarmen.
    • Standarderkennung, Standardwahrscheinlichkeit von Fehlalarmen: Diese Option lässt eine präzisere Erkennung von Speicherverlusten zu, ist aber langsamer.
    • Langsamere Erkennung, geringere Wahrscheinlichkeit von Fehlalarmen: Diese Option lässt eine präzise Erkennung potenzieller Speicherverluste zu.
    Reaktion der Vitalitätsüberwachung
    Reaktionsmodus
    Sie können zwischen Kontrolliert und Automatisch wählen. Der Reaktionsmodus definiert die Stufe der Benutzerinteraktion für den Fall, dass die Vitalitätsbedingung entscheidet, dass Korrekturmaßnahmen erforderlich sind. Im kontrollierten Modus können die empfohlenen Aktionspläne vor der Umsetzung genehmigt werden. Im Automatikmodus werden alle empfohlenen Aktionspläne ohne Genehmigung umgesetzt. Verwenden Sie den Automatikmodus mit Bedacht, insbesondere im Hinblick auf Serverneustarts. Durch Serverneustarts kann die ständige Verfügbarkeit der Services beeinträchtigt werden.
    Aktionen auswählen, die bei einem Verstoß gegen die Vitalitätsbedingung ausgeführt werden sollen
    Je nach Vitalitätsbedingung können Sie eine oder mehrere Aktionen auswählen, die bei einem Verstoß gegen eine Vitalitätsbedingung ausgeführt werden sollen:
    • Server erneut starten
    • Thread-Speicherauszüge erstellen
    • Nur JVM-Heap-Speicherauszüge für IBM Java Development Kit (JDK) erstellen
  4. Klicken Sie auf Weiter. In den folgenden Anzeigen werden Sie zur Auswahl der Ziele für Ihre Policy aufgefordert.
  5. Wählen Sie die Zugehörigkeiten aus, die Sie für Ihre Vitalitäts-Policy überwachen möchten. Wenn die Member-Typen in der Liste Verfügbar für Zugehörigkeit angezeigt werden, wählen Sie die zu überwachenden Typen aus und klicken Sie anschließend auf Hinzufügen.
    • Anwendungsserver und Knoten
    • Cluster
    • Dynamische Cluster
    • Zellen
    Auf überwachte Zugehörigkeiten können Logikebenen angewendet werden. Beispiel: Sie möchten eine bestimmte Vitalitäts-Policy auf alle Member eines Cluster und einen Anwendungsserver außerhalb des Cluster anwenden. Wählen Sie in der Anzeige "Anwendungsserver" den Anwendungsserver und den Cluster aus. Diese Auswahl schließt alle vorhandenen und potenziellen Anwendungsserver im Cluster ein. Cluster-Member wenden zusätzliche Logik an, um den Einfluss von Reaktionen auf den Service zu minimieren.
  6. Klicken Sie auf Weiter.
  7. Überprüfen Sie die neue Policy und klicken Sie anschließend auf Fertig stellen. In der Kopfzeile des Konsolfensters wird die Option "Speichern" angezeigt.
  8. Klicken Sie auf Speichern. Es erscheint ein Fenster mit den Optionen "Speichern" und "Verwerfen". Klicken Sie erneut auf Speichern, um die neue Policy festzuschreiben.

Ergebnis

Sie haben eine Vitalitäts-Policy erstellt und auf eine Zielumgebung angewendet.

Nächster Artikel

Jetzt können Sie die Vitalitätsüberwachung aktivieren. Wenn Sie die Vitalitätsüberwachung starten, trifft Ihre Vitalitäts-Policy "intelligente" Entscheidungen und arbeitet eng mit der Funktion für die Verteilung von Anwendungen zusammen, um sicherzustellen, dass Bedingungen, die einen Neustart erfordern, keine Auswirkungen auf die aktive Verarbeitung innerhalb der Anwendung haben. Nähere Informationen finden Sie im Artikel Vitalitätsüberwachung aktivieren und inaktivieren.



Related reference
Vitalitäts-Policys mit Scripting verwalten

Task-Topic    

Nutzungsbedingungen | Feedback Letzte Aktualisierung: Mar 23, 2006 9:51:53 AM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/odoe_task/todhealthpolicy.html

© Copyright IBM 2004, 2006. Alle Rechte vorbehalten.
Dieses Information Center beruht auf der Eclipse-Technologie. (http://www.eclipse.org)