Gleiche Verteilung von HTTP-Anforderungen innerhalb des WLM

Der z/OS® Die Workload-Management-Komponente (WLM) unterstützt die Verteilung eingehender HTTP-Anfragen ohne Servant-Affinität im Round-Robin-Verfahren auf die Servants. Diese Funktionalität ist für langlebige HTTP-Sitzungsobjekte gedacht, die im Speicher verwaltet werden, sowie für zustandslose Sitzungsobjekte im Enterprise-Bereich. JavaBeans (EJB) und die Create-Methode 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.

Eingehende Anforderungen werden über die Warteschlange des Workload-Managers an die Steuerregion weitergeleitet und Arbeitsthreads in einer bestimmten Servant-Region zugewiesen. — Abb. 1. Der Inhalt einer Cluster-Server-Instanz

In der obigen Abbildung ist der Anwendungsserver so konfiguriert, dass die Mindest- und Höchstanzahl der Servants 3 beträgt.

Es gibt WLM-Definitionen für die Anwendungsserver in diesem Cluster. Alle Anforderungen für eine Anwendungsserverinstanz im Cluster azsr01 werden derselben Serviceklasse zugeordnet. Die WLM-Klassifizierungsregeln ordnen alle Enklaven, die im Anwendungsserver azsr01a ausgeführt werden, der Serviceklasse AZAMS1 zu. Die folgenden Abbildungen enthalten ein Beispiel für die Definition der WLM-Serviceklasse und die Klassifizierungsregeln.

Abbildung 2. Die Definition der WLM-Serviceklasse

   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 ********************************

Abb. 3 Die Klassifizierungsregeln des WLM-CB-Subsystems


   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 im Servant 3 eingerichtet. Benutzer 2 hat ein HTTP-Sitzungsobjekt im Servant 2 eingerichtet.

Benutzer 1 richtet ein HTTP-Sitzungsobjekt im Servant 3 ein. Benutzer 2 richtet ein HTTP-Sitzungsobjekt in Servant 2 ein. — Abbildung 4. Benutzer erstellen HTTP-Sitzungsobjekte

Wenn ein Benutzer auf eine Servant-Region ohne ein erstelltes HTTP-Sitzungsobjekt zugreift, gibt es keine Affinität zu Servant-Regionen. Daher kann die Anforderungen jedem verfügbaren Servant zugeteilt werden. WLM startet möglicherweise einen neuen Servant, wenn jede der folgenden Bedingungen erfüllt ist:

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ß.

In der letzten Situation ist das Ergebnis eine unerwünschte Verzerrung bei der Verteilung von HTTP-Sitzungsobjekten. In der folgenden Abbildung wurden die meisten HTTP-Objekte Servant 1 zugeordnet.

HTTP-Sitzungsobjekte werden dem Hot Servant, Servant 1, zugewiesen. — Abbildung 5. HTTP-Sitzungsobjekte, die einem Hot Servant zugeordnet sind

Ein großer Prozentsatz von HTTP-Sitzungsobjekten befindet sich in einem oder zwei Servants, da meist nicht genug Anforderungen in der WLM-Warteschlange vorhanden sind, um die Verteilung der Arbeit auf viele Servants zu gewährleisten. Dieses Verhalten kann zu folgenden unerwünschten Ergebnissen führen:

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.

Jeder Servant empfängt ungefähr die gleiche Anzahl an HTTP-Sitzungsobjekten. — Abbildung 6. HTTP-Sitzungsobjekte, die Servants ohne Affinität zugeordnet sind

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.