[z/OS]

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.

Abbildung 1. Der Inhalt einer Cluster-Server-Instanz

Eingehende Anforderungen fließen in die Steuerregion und werden über die Warteschlange des Workload Manager Worker-Threads in einer bestimmten Servant-Region zugeordnet.

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 ********************************
Abbildung 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 in Servant 3 erstellt. Benutzer 2 hat ein HTTP-Sitzungsobjekt in Servant 2 erstellt.

Abbildung 4. Benutzer erstellen HTTP-Sitzungsobjekte

Benutzer 1 erstellt ein HTTP-Sitzungsobjekt in Servant 3. Benutzer 2 erstellt ein HTTP-Sitzungsobjekt in Servant 2.

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:

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.
Abbildung 5. HTTP-Sitzungsobjekte, die einem Hot Servant zugeordnet sind

HTTP-Sitzungsobjekte sind dem Hot Servant, Servant 1, zugeordnet.

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.

Abbildung 6. HTTP-Sitzungsobjekte, die Servants ohne Affinität zugeordnet sind

Jeder Servant empfängt etwa dieselbe Anzahl von HTTP-Sitzungsobjekten.

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.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_wlm_sessionplacement
Dateiname:crun_wlm_sessionplacement.html