![[z/OS]](../images/ngzos.gif)
Gleiche Verteilung von HTTP-Anforderungen innerhalb des WLM
Die WLM-Komponente von z/OS (Workload-Management) unterstützt die Verteilung eingehender HTTP-Anforderungen ohne Servant-Affinität auf die Servants. Dazu wird ein Round-Robin-Verfahren eingesetzt. Dieses Leistungsmerkmal ist vorgesehen für lang andauernde, im Speicher verwaltete HTTP-Sitzungsobjekte, Stateless-Session-EJBs (Enterprise JavaBeans) und die Methode "create" für Stateful-Session-Enterprise-Beans. Sie können das Produkt so konfigurieren, dass er mit dieser Funktionalität HTTP-Anforderungen auf aktive Servants verteilt, die gegenwärtig an dieselbe Warteschlange für Vorgangsbearbeitung gebunden sind wie die eingehenden Anforderungen.
Das folgende Diagramm stellt eine Cluster-Server-Instanz dar. Der Cluster enthält die Anwendungsserverinstanz azsr01a. In der Anwendungsserverinstanz befinden sich ein Controller, die WLM-Warteschlange und die Servants, in denen Anwendungen ausgeführt werden. Der Controller ist der HTTP- und IIOP-Abschlusspunkt. Die WLM-Warteschlange steuert den Arbeitsablauf vom Controller zu einem der Servants. Jeder der Servants enthält Worker-Threads, die Arbeitsvorgänge aus der WLM-Warteschlange auswählen.
In der obigen Abbildung ist der Anwendungsserver so konfiguriert, dass die Mindest- und Höchstanzahl der Servants 3 beträgt.
Service-Class Xref Notes Options Help
--------------------------------------------------------------------------
Modify a Service Class Row 1 to 2 of 2
Command ===> ______________________________________________________________
Service Class Name . . . . . : AZAMS1
Description . . . . . . . . . WAS Enclave Work
Workload Name . . . . . . . . ONL_WKL (name or ?) Base Resource Group . . . . . ________ (name or ?) Cpu Critical . . . . . . . . . NO (YES or NO)
Specify BASE GOAL information. Action Codes: I=Insert new period,
E=Edit period, D=Delete period.
---Period--- ---------------------Goal---------------------
Action # Duration Imp. Description
__
__ 1 1 Execution velocity of 50
******************************* Bottom of data ********************************
Subsystem-Type Xref Notes Options Help
--------------------------------------------------------------------------
Modify Rules for the Subsystem Type Row 11 to 20 of 20
Command ===> ____________________________________________ SCROLL ===> CSR
Subsystem Type . : CB Fold qualifier names? Y (Y or N)
Description . . . Component Broker requests
Action codes: A=After C=Copy M=Move I=Insert rule
B=Before D=Delete row R=Repeat IS=Insert Sub-rule
More ===>
--------Qualifier-------- -------Class--------
Action Type Name Start Service Report
DEFAULTS: AZAMS1 RBBDEFLT
____ 1 CN AZSR01 ___ AZAMS1 RAZAMS1
____ 1 CN AZSR02 ___ AZAMS2 RAZAMS2
____ 1 CN AZSR03 ___ AZAMS3 RAZAMS3
****************************** BOTTOM OF DATA *****************************
Das Produkt unterstützt die Verwendung von HTTP-Sitzungsobjekten im Speicher für Anwendungsserver mit mehreren Servants, auch bezeichnet als Hot-Servant-Strategie. In der folgenden Abbildung haben zwei Benutzer auf eine Anwendung in der Anwendungsserverinstanz azsr01a zugegriffen. Benutzer 1 hat ein HTTP-Sitzungsobjekt in Servant 3 erstellt. Benutzer 2 hat ein HTTP-Sitzungsobjekt in Servant 2 erstellt.
- Die Konfiguration lässt die Erstellung neuer Servants zu.
- Die Logik des Workload Manager bestimmt, dass das System einen zusätzlichen Servant verwalten kann.
- Das Hinzufügen eines weiteren Servant reduziert die Verzögerungen in der Warteschlange und lässt zu, dass Enklaven innerhalb des angegebenen Ziels abgeschlossen werden.
Wenn mehrere Servants an dieselbe Serviceklasse gebunden sind, versucht WLM, die neuen Anforderungen einem Hot Servant zuzuteilen. Ein Hot Servant hat Threads verfügbar, und es wird ihm eine neue Anforderung zugeteilt. Wenn der Hot Servant einen Arbeitsrückstand aufweist, teilt WLM die Arbeit einem anderen Servant zu.
Normalerweise ist es sinnvoll, eine Hot-Servant-Strategie einzusetzen, denn der Hot Servant hat wahrscheinlich alle notwendigen Seiten im Speicher, die mit JIT (Just-In-Time) kompilierten Anwendungsmethoden sind in der Nähe gespeichert und es gibt einen Cache voller Daten für den schnellen Datenabruf. In folgenden Situationen kann diese Strategie jedoch ein Problem darstellen:
- Es werden HTTP-Sitzungsobjekte im Hauptspeicher verwendet, wodurch Zuteilungsaffinitäten entstehen.
- Die HTTP-Sitzungsobjekte bleiben viele Stunden oder gar Tage bestehen.
- Eine große Anzahl von Clients mit HTTP-Sitzungsobjekten, die im Speicher gehalten werden müssen.
- Der Verlust eines Sitzungsobjekts stört den Client oder Server, und der Zeitraum zwischen Anforderungen, die HTTP-Sitzungen erstellen, ist groß.
- Wenn die Anwendung viele Objekte in einem einzelnen Servant erstellt, können lange Zeiträume für die Garbage-Collection die Folge sein.
- Wenn alle HTTP-Sitzungsobjekte an einen Servant gebunden sind, können Anforderungen lange in der Warteschlange gehalten werden, da die Arbeit nicht von WLM gesteuert und somit auch keinem Servant zugeteilt werden kann.
- Wenn alle HTTP-Sitzungsobjekte sich in einem oder zwei Servants befinden, kann ein Zeitlimit in einem einzelnen Servant eine größere Anzahl von Benutzern beeinflussen, als wenn die HTTP-Sitzungsobjekte gleichmäßig auf mehrere Servants verteilt wären.
Wenn in Ihrer Konfiguration eine der beschriebenen Situationen eintritt, die ein Problem mit der Hot-Servant-Strategie verursacht, können Sie Ihren Anwendungsserver so konfigurieren, dass die Verteilung eingehender HTTP-Anforderungen auf Servants ohne Servant-Affinität unterstützt wird. Wenn Sie diese Funktionalität aktivieren, verwendet der Anwendungsserver ein Round-Robin-Verfahren für die Verteilung von HTTP-Anforderungen auf die Servants.
Nehmen Sie im folgenden Beispiel an, dass der Anwendungsserver konfiguriert wurde, das Round-Robin-Verfahren für die Verteilung von HTTP-Anforderungen auf die Servants zu verwenden, und dass für die Anforderungen der Warteschlange für Vorgangsbearbeitung, denen dieselbe Serviceklasse zugeordnet ist, mehrere Servants gestartet wurden.
Wenn eine neue HTTP-Anforderung ohne Affinität in einer Warteschlange für Vorgangsbearbeitung eingeht, prüft WLM, ob es einen Servant gibt, in dem mindestens ein Worker-Thread auf Arbeit wartet. Gibt es in keinem Servant verfügbare Worker-Threads, stellt WLM die Anforderung in die Warteschlange, bis ein Worker-Thread in einem der Servants verfügbar wird. Wenn es verfügbare Worker-Threads gibt, ermittelt WLM den Servant mit der kleinsten Anzahl von Affinitäten. Wenn es Servant-Regionen mit einer gleichen Anzahl von Affinitäten gibt, teilt WLM die Arbeit der Servant-Region mit der kleineren Anzahl aktiver Server-Threads zu.
Das Ziel dieses Algorithmus ist, dass WLM die eingehenden Anforderungen ohne Servant-Affinität auf die wartenden Servants verteilt, während eine Änderung der Bedingungen erwogen wird. Der Algorithmus ordnet nicht einfach Servern Anforderungen in einem echten Round-Robin-Verfahren zu. Die folgende Abbildung zeigt die ausgewogene Verteilung von HTTP-Sitzungsobjekten auf Servants.
Dieses Verteilungsverfahren funktioniert für alle eingehenden Anforderungen ohne Affinität. Nachdem das HTTP-Sitzungsobjekt erstellt ist, werden alle Clientanforderungen an diesen Servant übertragen, bis das HTTP-Sitzungsobjekt entfernt wird.
Wenn Sie entscheiden, die Verteilung eingehender HTTP-Anforderungen ohne Servant-Affinität zu ermöglichen, müssen Sie möglicherweise Änderungen an Ihrer Klassifikationszuordnungsdatei vornehmen. Falls Sie die Datei für die Zuordnung der Klassifikation so definiert haben, dass sie für die Round-Robin-Unterstützung des Produkts mehrere Transaktionsklassen in einer Zuordnungsregel angibt, sollten Sie diesen Abschnitt aus der Datei für die Zuordnung der Klassifikation entfernen.