Datei "plugin-cfg.xml"
Die Datei plugin-cfg.xml enthält Konfigurationsdaten, die bestimmen, wie Web-Server-Plug-ins Anforderungen weiterleiten.
WebSphere Application Server Traditional
Sie können zwei Typen von plugin-cfg.xml-Dateien erstellen: anwendungsorientiert und topologieorientiert.

Eine anwendungsorientierte Konfigurationsdatei hat eine Anwendung, die Web-Server- und Anwendungsserverdefinitionen zugeordnet ist. Änderungen, die Sie am Plug-in über die Administrationskonsole vornehmen, werden bei der Generierung persistent in der Datei plugin-cfg.xml gespeichert. Die anwendungsorientierte Konfiguration bietet eine höhere Flexibilität und mehr Unterstützung für dynamische Funktionen, wie z. B. Intelligent Management.
Eine topologieorientierte Datei stellt alles dar, was in der Umgebung definiert ist. Gewöhnlich wird die Datei plugin-cfg.xml verwendet, wenn keine Web-Server definiert sind.
- Wenn die Datei plugin-cfg.xml im Verzeichnis Stammverzeichnis_des_Anwendungsservers\dmgr\cells enthalten ist, ignoriert der Plug-in-Generierungsprozess die aktualisierten Werte in der Anzeige der Administrationskonsole und verwendet die vorhandenen Werte in der XML-Datei. In diesem Fall müssen Sie die XML-Datei manuell aktualisieren, damit diese Werte beibehalten werden.
- Wenn sich die Datei plugin-cfg.xml nicht im Verzeichnis Stammverzeichnis_des_Anwendungsservers\dmgr\cells befindet, erstellt der Plug-in-Generierungsprozess die Datei plugin-cfg.xml. Der Prozess behält die Werte bei, die zuletzt in der Anzeige der Administrationskonsole angegeben wurden.


Liberty
Sie können die Datei plugin-cfg.xml für Ihren Liberty-Server generieren, indem Sie die MBean WebSphere:name=com.ibm.ws.jmx.mbeans.generatePluginConfig in demselben Java SDK wie Ihr Server aufrufen.
Elemente und Attribute
Die Datei plugin-cfg.xml enthält die folgenden Elemente und Attribute. Sofern nicht anders angegeben, können Sie jedes Element und jedes Attribut nur einmal in der Datei plugin-cfg.xml angeben. Das Element Config ist erforderlich.
- Config
- IgnoreDNSFailures
- RefreshInterval
- ASDisableNagle
IISDisableNagle
- VHostMatchingCompat
- AppServerPortPreference
- ResponseChunkSize
- AcceptAllContent
- ChunkedResponse
- ESIEnableToPassCookies
- GetDWLMTable
OS400ConvertQueryStringToJobCCSID
- Log
- Property Name="esiEnable" Value="true/false"
- Property Name="esiMaxCacheSize" Value="Integer"
- Property Name="ESIInvalidationMonitor" Value="true/false"
- Property Name="FIPSEnable" Value="true/false"
- Property Name="PluginInstallRoot" Value="C:\IBM\WebSphere\Plugins"
- ServerCluster
- VirtualHostGroup
- UriGroup
- Route
- RequestMetrics
Config
Dieses erforderliche Element startet die HTTP-Plug-in-Konfigurationsdatei.
IgnoreDNSFailures
Gibt an, ob das Plug-in beim Start DNS-Fehler in einer Konfiguration ignoriert. Wenn die Einstellung true angegeben wird, ignoriert das Plug-in DNS-Fehler in einer Konfiguration und wird gestartet, wenn mindestens ein Server pro Server-Cluster den Hostnamen auflösen kann. Server, deren Hostname nicht aufgelöst werden kann, werden für die Lebensdauer der Konfiguration als nicht verfügbar markiert. Bei der Weiterleitung von Anforderungen werden keine Versuche unternommen, den Hostnamen aufzulösen. Tritt ein DNS-Fehler auf, wird eine Protokollnachricht in die Protokolldatei des Plug-ins geschrieben, und die Initialisierung des Plug-ins wird fortgesetzt. Der Start des Web-Servers wird nicht verhindert. Der Standardwert ist false. Dies bedeutet, dass DNS-Fehler dazu führen, dass der Web-Server nicht gestartet wird.
RefreshInterval
Gibt das Intervall (in Sekunden) an, in dem das Plug-in die Konfigurationsdatei auf Aktualisierungen oder Änderungen überprüft. Das Plug-in überprüft die Datei auf alle Änderungen, die seit dem Zeitpunkt, zu dem die Plug-in-Konfiguration geladen wurde, vorgenommen wurden.
ASDisableNagle
Gibt an, ob der Benutzer den Nagle-Algorithmus für die Verbindung zwischen Plug-in und Anwendungsserver inaktivieren möchte. Standardmäßig ist der Nagle-Algorithmus aktiviert.
Die gültigen Werte sind true und false.
![[Windows]](../images/windows.gif)
IISDisableNagle
Gibt an, ob der Benutzer den Nagle-Algorithmus in Microsoft Internet Information Services (IIS) inaktivieren möchte. Standardmäßig ist der Nagle-Algorithmus aktiviert.
Die gültigen Werte sind true und false.
VHostMatchingCompat
- true, wenn der Abgleich physisch, anhand der Portnummer durchgeführt werden soll, für die die Anforderung empfangen wurde.
- false wenn der Abgleich logisch, anhand der Portnummer im Host-Header durchgeführt werden soll.
Der Standardwert ist false.
AppServerPortPreference
- Verwenden Sie den Wert hostHeader, wenn die Portnummer aus dem Host-Header der eingehenden HTTP-Anforderung verwendet werden soll.
- Verwenden Sie webserverPort, wenn die Nummer des Port, an dem der Web-Server die Anforderung empfängt, verwendet werden soll.
Der Standardwert ist hostHeader.
ResponseChunkSize
Gibt die maximale Blockgröße an, die beim Lesen des Antworthauptteils verwendet werden soll. Geben Sie beispielsweise "Config ResponseChunkSize="N">" an, wobei N der Blockgröße in Kilobyte entspricht.
Das Plug-in liest den Hauptteil der Antwort in 64-KB-Blöcken, bis alle Antwortdaten gelesen sind. Diese Vorgehensweise führt zu Durchsatzproblemen bei Anforderungen, deren Antworthauptteil große Datenmengen enthält.
Falls die Inhaltslänge des Antworthauptteils nicht bekannt ist, wird eine Puffergröße von N KB zugeordnet, und der Hauptteil wird jeweils in N-KB-Blöcken gelesen, bis der gesamte Hauptteil gelesen wurde. Wenn die Inhaltslänge bekannt ist, wird als Puffergröße die Inhaltslänge oder die angegebene Größe N (der jeweils kleinere der beiden Werte) verwendet, um den Antworthauptteil zu lesen.
Die Standardblockgröße ist 64 K.
AcceptAllContent
- True, wenn für alle Anforderungen Inhalt erwartet und gelesen wird.
- False, wenn nur für POST- und PUT-Anforderungen Inhalt erwartet und gelesen wird.
Der Standardwert ist True.
ChunkedResponse
Gibt an, ob das Plug-in in der Antwort an den Client Blöcke verwenden muss, wenn ein Antwortheader des Typs "Transfer-Encoding: Chunked" in der Antwort enthalten ist.
Dieses Attribut gilt nur für IIS-, Oracle iPlanet- und Lotus Domino-Web-Server. IBM® HTTP Server führt die Aufteilung der Antwort an den Client automatisch durch.
Sie können für dieses Attribut einen der folgenden Werte angeben:
- true, wenn das Plug-in die Antwort an den Client in Blöcke aufteilen muss, wenn ein Antwortheader des Typs "Transfer-Encoding: Chunked" in der Antwort enthalten ist.
- false, wenn die Antwort nicht in Blöcke aufgeteilt werden muss.
Der Standardwert ist false.
ESIEnableToPassCookies
Gibt an, ob bei der Verarbeitung von ESI-Anforderungen die Weiterleitung von Sitzungscookies an WebSphere Application Server zugelassen werden soll. Wenn Sie den Wert true wählen, ist diese angepasste Eigenschaft aktiviert. Wenn Sie den Wert false wählen, ist die angepasste Eigenschaft inaktiviert. Der Standardwert ist false.
GetDWLMTable
Gibt an, ob der neu erstellte Plug-in-Prozess proaktiv eine Partitionstabelle von WebSphere Application Server anfordern soll, bevor er HTTP-Anforderungen ausführt. Diese angepasste Eigenschaft wird nur verwendet, wenn die speicherübergreifende Sitzungsverwaltung konfiguriert ist. Wenn Sie den Wert true wählen, ist diese angepasste Eigenschaft aktiviert. Wenn Sie den Wert false wählen, ist die angepasste Eigenschaft inaktiviert. Der Standardwert ist false.
![[IBM i]](../images/iseries.gif)
OS400ConvertQueryStringToJobCCSID
Gibt an, ob die Abfragezeichenfolge für eine HTTP-Anforderung in die Codepage des Jobs von IBM HTTP Server oder in EBCDIC Code Page 37 für interne Verarbeitung konvertiert wird. Der Standardwert ist "false", d. h., die Abfragezeichenfolge wird in EBCDIC Code Page 37 konvertiert.
TrustedProxyEnable
Ermöglicht dem Web-Server-Plug-in die Verknüpfung mit den Proxy-Servern und Lastausgleichsfunktionen, die für die angepasste Eigenschaft "TrustedProxyList" aufgelistet sind. Wenn diese Eigenschaft auf true gesetzt ist, können die Proxy-Server und Lastausgleichsfunktionen in dieser anerkannten Proxy-Liste Werte für die internen Header $WSRA und $WSRH festlegen. Der interne Header $WSRA ist die IP-Adresse des fernen Hosts (gewöhnlich der Browser) oder eine interne Adresse, die von Network Address Translation (NAT, Netzadressumsetzung) angefordert wird. Der interne Header $WSRH ist der Hostname des fernen Hosts. Mit diesen Headerinformationen ist eine Verknüpfung des Web-Server-Plug-ins mit einem bestimmten Proxy-Server oder einer bestimmten Lastausgleichsfunktion möglich.
Wenn Sie diese angepasste Eigenschaft verwenden, müssen Sie auch die angepasste Eigenschaft "TrustedProxyList" verwenden, um eine Liste anerkannter Proxy-Server und Laustausgleichsfunktionen anzugeben. Außerdem müssen Sie das Kontrollkästchen "Sonderheader entfernen" in der Anzeige "Anforderungsweiterleitung" der Administrationskonsole abwählen. Weitere Informationen finden Sie in der Dokumentation zu den Eigenschaften für die Anforderungsweiterleitung des Web-Server-Plug-ins.
TrustedProxyList
Gibt eine durch Kommas begrenzte Liste aller Proxy-Server oder Lastausgleichsfunktionen an, die für die Verknüpfung mit diesem Web-Server-Plug-in berechtigt sind. Sie müssen diese Eigenschaft mit der Einstellung TrustedProxyEnable=true für die angepasste Eigenschaft "TrustedProxyEnable" verwenden. Wenn die angepasste Eigenschaft "TrustedProxyEnable" auf false gesetzt ist, wird diese Liste ignoriert.
SSLConsolidate
Gibt an, ob das Web-Server-Plug-in die Konfiguration jedes SSL-Transports mit der Konfiguration anderer SSL-Transporte, die bereits in der Konfigurationsdatei definiert sind, vergleichen soll. Wenn Sie diese Eigenschaft auf true setzen und das Plug-in bestimmt, dass die für den neuen SSL-Transport angegebenen Schlüsselring- und CertLabel-Werte den für einen bereits definierten SSL-Transport angegebenen Werten entsprechen, verwendet das Plug-in die vorhandene SSL-Umgebung, anstatt eine neue SSL-Umgebung zu erstellen. Werden weniger SSL-Umgebungen erstellt, bedeutet dies, dass das Plug-in weniger Speicher benötigt und die Zeit für die Plug-in-Initialisierung reduziert wird, sodass Ihre gesamte GSkit-Umgebung optimiert wird.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
SSLPKCSDriver
Gibt den vollständig qualifizierten Namen des ladbaren Moduls an, das mit einem optionalen SSL-Koprozessor verknüpft ist. Der vollständig qualifizierte Name muss den Verzeichnispfad und den Modulnamen enthalten.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
SSLPKCSPassword
Gibt das Kennwort für den SSL-Koprozessor an, mit dem das für die angepasste Eigenschaft SSLPKCSDriver angegebene Modul verknüpft ist.
Wenn Sie IBM HTTP Server verwenden, können Sie das Programm "sslstash" für die Erstellung einer Datei, die dieses Kennwort enthält, verwenden. In dieser Situation können Sie den vollständig qualifizierten Namen dieser Datei anstelle des tatsächlichen Kennworts als Wert für diese angepasste Eigenschaft angeben.
Log
Beschreibt die Position und Ebene der Protokollnachrichten, die vom Plug-in geschrieben werden müssen. Wenn in der Konfigurationsdatei kein Element "Log" angegeben wird, werden die Protokollnachrichten in einigen Fällen in das Fehlerprotokoll des Web-Servers geschrieben.
Sie können beispielsweise die folgende Codezeile angeben:
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
<Log LogLevel="Error" Name="/opt/WebSphere/AppServer60/logs/http_plugin.log"/>
![[z/OS]](../images/ngzos.gif)
<Log LogLevel="Error" Name="/Protokollverzeichnis/Dateiname"/>
- Name
Gibt den vollständig qualifizierten Pfad zur Protokolldatei an, in die das Plug-in Fehlernachrichten schreibt. Geben Sie für jedes Protokoll genau ein Attribut an.
Wenn die Datei nicht existiert, wird sie erstellt. Wenn die Datei bereits vorhanden ist, wird sie im Anhängemodus geöffnet, und die vorherigen Protokollnachrichten des Plug-ins bleiben bestehen.
Hinweis zur Umstellung: Ab Version 7 werden kein Datum und keine Zeitmarke und keine Prozess-ID mehr an den Namen angehängt, den Sie für die Plug-in-Datei angeben. Deshalb wird eine einzige Web-Server-Plug-in-Datei anstelle mehrerer Protokolldateien erstellt, die anhand des Datums unterschieden werden können.trns
- LogLevel
Gibt die Detaillierungsebene der Protokollnachrichten an, die das Plug-in in das Protokoll schreibt. Geben Sie für jedes Protokoll null oder einen der folgenden Werte an.
Wert für Protokollebene Beschreibung der Protokollebene Trace Alle Schritte im Anforderungsprotokoll werden detailliert protokolliert. Stats Der für jede Anforderung ausgewählte Server und weitere Lastausgleichinformationen zur Anforderungsverarbeitung werden protokolliert. Warn Alle Warnungen und Fehlernachrichten, die Folge einer abnormalen Anforderungsverarbeitung sind, werden protokolliert. Error Es werden nur Fehlernachrichten, die Folge einer abnormalen Anforderungsverarbeitung sind, protokolliert. Debug Alle kritischen Schritte, die in Verarbeitungsanforderungen ausgeführt werden, werden protokolliert. Detail Alle Informationen zu Anforderungen und Antworten werden protokolliert. Wenn für das Element "Log" keine Protokollebene ("LogLevel") angegeben wird, wird der Standardwert "Error" verwendet.
Fehler vermeiden: Verwenden Sie die Einstellung "Trace" mit Vorsicht. Auf dieser Ebene werden viele Nachrichten protokolliert, die den Plattenspeicherplatz schnell belegen können. In einer normalen Betriebsumgebung sollte die Einstellung "Trace" nicht verwendet werden, weil sie sich nachteilig auf den Durchsatz auswirkt.gotcha
Fehler vermeiden: Verwenden Sie die Einstellung "Trace" mit Vorsicht. Auf dieser Ebene werden viele Nachrichten protokolliert, die das Dateisystem schnell belegen können. In einer normalen Betriebsumgebung sollte die Einstellung "Trace" nicht verwendet werden, weil sie sich nachteilig auf den Durchsatz auswirkt.gotcha
Property Name="esiEnable" Value="true/false"
Mit dieser Eigenschaft wird der ESI-Prozessor (Edge Side Include) aktiviert oder inaktiviert. Wenn der ESI-Prozessor inaktiviert ist, werden die anderen ESI-Elemente in dieser Datei ignoriert.
Sie können den Wert Value auf true oder false setzen. Der Wert ist standardmäßig auf false gesetzt, sodass der ESI-Prozessor inaktiviert ist.
Property Name="esiMaxCacheSize" Value="Integer"
Gibt die maximale Größe des Caches in 1-KB-Einheiten an. Standardmäßig wird eine maximale Größe von 1024 KB (1 MB) für den Cache verwendet. Wenn der Cache voll ist, wird zuerst der Eintrag im Cache gelöscht, der als nächstes verfallen würde.
Property Name="ESIInvalidationMonitor" Value="true/false"
Gibt an, ob der ESI-Prozessor Invalidierungen vom Anwendungsserver empfängt.
Sie können den Wert Value auf true oder false setzen. Standardmäßig ist diese Eigenschaft auf false gesetzt.
Property Name="FIPSEnable" Value="true/false"
Gibt an, ob Federal Information Processing Standard (FIPS) aktiviert ist, um SSL-Verbindungen (Secure Sockets Layer) zum Anwendungsserver herzustellen. Setzen Sie diese Eigenschaft auf den Wert true, wenn FIPS im Anwendungsserver aktiviert ist.
Sie können den Wert Value auf true oder false setzen. Standardmäßig ist diese Eigenschaft auf false gesetzt.
Property Name="PluginInstallRoot" Value="C:\IBM\WebSphere\Plugins"
Gibt den Installationspfad für das Plug-in an. Diese Eigenschaft ist obligatorisch, wenn Sie das GSKit (Global Security Kit) verwenden, weil WebSphere Application Server die lokale Installation von GSKit anstatt die globale Installation unterstützt. Als Attributwert wird ein vollständig qualifizierter Pfad zum Installationsstammverzeichnis des Plug-ins eingestellt.
Die unterstützten Namen, die vom Transport erkannt werden, sind "keyring", "stashfile" und "password". Standardmäßig ist diese Eigenschaft auf none gesetzt.
ServerCluster
Gibt eine Gruppe von Servern an, die so konfiguriert ist, dass sie hauptsächlich denselben Typ von Anforderungen bedient. Geben Sie für jede Konfiguration einen oder mehrere Cluster an.
Im einfachsten Fall enthält der Cluster nur eine Serverdefinition. Für den Fall, dass mehrere Server definiert sind, verteilt das Plug-in die Last auf die definierten Server, indem es einen Round-Robin-Algorithmus oder Zufallsalgorithmus ("Random") verwendet. Der Standardalgorithmus ist "Round Robin".
Der folgende Code ist ein Beispiel für ein ServerCluster-Element.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
<ServerCluster Name="Servers">
<ClusterAddress Name="Clusteradresse">
<Transport Hostname="192.168.1.2" Port="9080" Protocol="HTTP"/>
<Transport Hostname="192.168.1.2" Port="9443" Protocol="HTTPS">
<Property Name="Keyring" value="c:/WebSphere/AppServer/keys/keyring.kdb"/>
<Property Name="Stashfile" value="c:/WebSphere/AppServer/keys/keyring.sth"/>
</Transport>
</ClusterAddress>
<Server Name="Server1">
<Transport Hostname="192.168.1.3" Port="9080" Protocol="HTTP"/>
<Transport Hostname="192.168.1.3" Port="9443" Protocol="HTTPS">
<Property Name="Keyring" value="c:/WebSphere/AppServer/keys/keyring.kdb"/>
<Property Name="Stashfile" value="c:/WebSphere/AppServer/keys/keyring.sth"/>
</Transport>
</Server>
<Server Name=Server2>
<Transport Hostname="192.168.1.4" Port="9080" Protocol="HTTP"/>
<Transport Hostname="192.168.1.4" Port="9443" Protocol="HTTPS">
<Property Name="Keyring" value="c:/WebSphere/AppServer/keys/keyring.kdb"/>
<Property Name="Stashfile" value="c:/WebSphere/AppServer/keys/keyring.sth"/>
</Transport>
</Server>
<Server Name="Server3">
<Transport Hostname="192.168.1.5" Port="9080" Protocol="HTTP"/>
<Transport Hostname="192.168.1.5" Port="9443" Protocol="HTTPS">
<Property Name="Keyring" value="c:/WebSphere/AppServer/keys/keyring.kdb"/>
<Property Name="Stashfile" value="c:/WebSphere/AppServer/keys/keyring.sth"/>
</Transport>
</Server>
<PrimaryServers>
<Server Name="Server1"/>
<Server Name="Server2"/>
</PrimaryServers>
<BackupServers>
<Server Name="Server3"/>
</BackupServers>
</ServerCluster>
![[z/OS]](../images/ngzos.gif)
<ServerCluster CloneSeparatorChange="false"
LoadBalance="Round Robin" Name="Cluster1"
PostSizeLimit="10000000" RemoveSpecialHeaders="true"
RetryInterval="60">
<Server
CloneID="BA36BEC1EB243D8B000000E4000000030926301B"
ConnectTimeout="0" ExtendedHandshake="false"
LoadBalanceWeight="2" MaxConnections="0"
Name="SY1_ClusterMember1" WaitForContinue="false">
<Transport Hostname="BOSSXXXX.PLEX1.L2.IBM.COM" Port="9084" Protocol="http"/>
<Transport Hostname="BOSSXXXX.PLEX1.L2.IBM.COM" Port="0" Protocol="https">
<Property Name="Keyring" value="safkeyring:///mzjring1/"/>
<Property Name="Stashfile" value=""""/>
<Property Name="certLabel" Value="selfsigned"/>
</Transport>
</Server>
<Server CloneID="BA36BED017FDF40E000000E4000000030926301B"
ConnectTimeout="0" ExtendedHandshake="false"
LoadBalanceWeight="2" MaxConnections="0"
Name="SY1_ClusterMember2" WaitForContinue="false">
<Transport Hostname="BOSSXXXX.PLEX1.L2.IBM.COM" Port="9085" Protocol="http"/>
<Transport Hostname="BOSSXXXX.PLEX1.L2.IBM.COM" Port="0" Protocol="https">
<Property Name="Keyring" value="safkeyring:///mzjring1/">
<Property Name="Stashfile" value=""""/>
<Property Name="certLabel" Value="selfsigned"/>
</Transport>
</Server>
<PrimaryServers>
<Server Name="SY1_ClusterMember1"/>
<Server Name="SY1_ClusterMember2"/>
</PrimaryServers>
</ServerCluster>

Das Paket z/OS PTF UK35083 enthält die SSL-Schnittstellenänderung für den z/OS-HTTP-Server der Version 5.3, der dieser Web-Server-Plug-in-Änderung entspricht. Deshalb muss diese vorläufige Programmkorrektur auf Ihr System angewendet werden, damit die neue SSL-Schnittstelle für das Web-Server-Plug-in ordnungsgemäß funktionieren kann.
Außerdem müssen Sie die Option SSLMODE=MULTI in die Datei httpd.conf für IBM HTTP Server for z/OS Version 5.3 einschließen. Die Option "SSLMODE=ON" wird in Version 7.0 und höher nicht unterstützt.
Wenn die Option SSLMode multi nicht in der Datei httpd.conf angegeben wird oder wenn Sie dasn Paket z/OS PTF UK35083 nicht auf Ihr System angewendet haben, kann die Fehlernachricht IMW0584W ausgegeben werden. Diese Nachricht zeigt an, dass der SSL-Modus, der für den HTTP-Server angegeben wurde, mit dem SSL-Modus für das Web-Server-Plug-in, das mit IBM HTTP Server for z/OS Version 5.3 verwendet wird, nicht kompatibel ist. In beiden Fällen können unvorhersehbare Ergebnisse eintreten.
- Wenn Sie eine kdb-Datei mit einer Stashdatei im hierarchischen Dateisystem
(HFS) verwenden, geben Sie wie im Beispiel oben
die Elemente Property Name=keyring und Property Name=stashfile an.
Fehler vermeiden: Das Format der Werte, die Sie für diese Elemente angeben, weicht von dem Format ab, das Sie in früheren Versionen des Produkts verwendet haben.gotcha
- Wenn Sie einen SAF-Schlüsselring (System Authorization Facility) verwenden,
müssen Sie anstelle einer
kdb-Datei die folgenden beiden angepassten Plug-in-Eigenschaften erstellen:
- KeyringLocation
- Geben sie die Verzeichnisposition des SAF-Schlüsselrings als Wert für diese Eigenschaft an. Wenn Sie diese Konfigurationsänderung speichern, wird diese Verzeichnisposition zum Wert der Eigenschaft "keyring" (Schlüsselring) in der Datei plugin-cfg.xml.
- StashfileLocation
- Geben Sie """"(null) als Wert für diese Eigenschaft an. Wenn Sie diese Konfigurationsänderung speichern, wird """"(null) als Wert für die Eigenschaft "stashfile" in der Datei plugin-cfg.xml verwendet.
Anweisungen zum Erstellen von KeyringLocation und StashfileLocation über die Administrationskonsole finden Sie unter Konfigurationseigenschaften für Web-Server-Plug-ins.
Verwenden Sie das folgende Beispiel für den SAF-Schlüsselring:<Transport Hostname="appserver.example.com" Port="9443" Protocol="https"> <Property name="keyring" value="safkeyring:///Name_des_SAF-Schlüsselrings"/> <Property Name="stashfile" value=""""/> </Transport>
- Name
Gibt den logischen Namen oder den Verwaltungsnamen an, der für diese Gruppe von Servern verwendet werden soll. Geben Sie für jeden Server-Cluster ein Attribut an.
- LoadBalance
Die folgenden Werte können für dieses Attribut angegeben werden:
Round Robin
Zufällig
Die Round-Robin-Implementierung hat einen willkürlichen Anfangspunkt. Der erste Anwendungsserver wird nach dem Zufallsprinzip gewählt. Danach werden die Anwendungsserver im Round-Robin-Verfahren ausgewählt. Diese Implementierung stellt sicher, dass in prozessbasierten Web-Servern nicht alle Prozesse sofort mit dem Senden der ersten Anforderung an denselben Application Server beginnen.
Die Random-Implementierung hat ebenfalls einen willkürlichen Anfangspunkt. Bei dieser Implementierung werden jedoch auch alle nachfolgenden Server zufällig ausgewählt. Deshalb kann unter Umständen derselbe Server mehrfach ausgewählt werden, während andere Server inaktiv bleiben.
Der Standardtyp für den Lastausgleich ist "Round Robin".
- IgnoreAffinityRequests
Gibt an, ob das Plug-in die Anzahl von Affinitätsanforderungen, die an einen Server abgesetzt werden, ignoriert, wenn Server basierend auf dem Round-Robin-Algorithmus ausgewählt werden. Geben Sie für jeden Server-Cluster null oder ein Attribut an. Die gültigen Werte sind true und false. Wenn der Wert false festgelegt wird, wird die Anzahl der Affinitätsanforderungen, die gestellt werden, bei der Serverauswahl berücksichtigt.
Der Standardwert ist false, d. h., die Anzahl der Affinitätsanforderungen, die gestellt werden, wird im Round-Robin-Algorithmus verwendet.
Hinweis zur Umstellung: Hinweis zur Umstellung: Dies ist eine Änderung gegenüber den früheren Versionen des Produkts. Der Standardwert in früheren Versionen von WebSphere Application Server lautet true.trns
- RetryInterval
Gibt einen ganzzahligen Wert für die Zeit an, die zwischen dem Zeitpunkt, zu dem ein Server als inaktiv markiert ist, und dem Zeitpunkt, zu dem das Plug-in eine Verbindungsanforderung wiederholt, vergeht. Die Standardeinstellung sind 60 Sekunden. Geben Sie für jeden Server-Cluster null oder ein Attribut an.
- RemoveSpecialHeaders
Das Plug-in fügt der Anforderung spezielle Header hinzu, bevor sie an den Anwendungsserver weitergeleitet wird. Diese Header speichern Informationen zu der Anforderung, die von der Anwendung verwendet wird. Standardmäßig entfernt das Plug-in diese Header aus aus eingehenden Anforderungen, bevor es die erforderlichen Header hinzufügt. Geben Sie für jeden Server-Cluster null oder ein Attribut an.
Die gültigen Werte sind true und false.Wird das Attribut auf "false" gesetzt, bedeutet das ein potenzielles Sicherheitsrisiko, wenn die Header nicht aus den eingehenden Anforderungen entfernt werden.
- CloneSeparatorChange
Diese Option gibt an, dass das Plug-in das Pluszeichen (+) als Trennzeichen für Klone erwarten soll. Einige Einheiten für Pervasive Computing können den Doppelpunkt (:), mit dem Klon-IDs in Verbindung mit der Sitzungsaffinität verwendet werden, nicht verarbeiten. Sie müssen die Konfigurationen der Anwendungsserver so ändern, dass Klon-IDs auch mit dem Pluszeichen getrennt werden können. Geben Sie für jeden Server-Cluster null oder ein Attribut an.
Die gültigen Werte sind true und false.
- PostSizeLimit
Die maximale Anzahl an KB-Blöcken (1024 Byte) mit Anforderungsinhalt, die das Plug-in in einer Anforderung an den Server senden kann. Wird eine Anforderung empfangen, die diesen Größenwert übersteigt, kann das Plug-in die Anforderung nicht durchführen. Der Standardwert ist -1 Byte. Dies bedeutet, dass es keinen Grenzwert für die Größe der gesendeten Anforderungen gibt. Geben Sie für jeden Server-Cluster null oder ein Attribut an.
- PostBufferSize
Gibt die maximale Puffergröße in KB an, die für das Lesen des Inhalts einer HTTP-Anforderung verwendet wird. Wenn der Anwendungsserver, der eine Anforderung zuerst empfängt, diese Anforderung nicht verarbeiten kann, werden die in diesem Puffer enthaltenen Daten zur Verarbeitung an einen anderen Anwendungsserver gesendet. Sie können diese Option auf null setzen, wenn Anforderungen mit Inhalten nicht gepuffert und dann wiederholt werden sollen.
Mit dieser Option wird die Verfügbarkeit des Plug-ins verbessert. Wenn Sie diese Option auf einen Wert ungleich null setzen, werden alle anstehenden Pakete, die Nutzdaten enthalten, erneut gesendet, wenn der ausgewählte Anwendungsserver nicht antwortet.
Gewöhnlich enthalten POST- und PUT-Anforderungen Nutzdaten, aber andere Anforderungen können auch Nutzdaten enthalten. Selbst wenn eine POST- oder PUT-Anforderung keine Nutzdaten enthält, wird sie wiederholt, wenn der für diese Option angegebene Wert ungleich null ist.
Der Standardwert ist 0.Geben Sie für jeden Server-Cluster null oder ein Attribut an.
- ServerIOTimeoutRetry
Gibt einenan, wie oft das HTTP-Plug-in maximal versucht, eine HTTP-Anforderung, die das zulässige Zeitlimit wegen eines ServerIOTimeout überschritten hat, zu wiederholen. Der Standardwert -1 zeigt an, dass keine weiteren Begrenzungen für die Anzahl der Wiederholungen gelten. Der Wert 0 zeigt an, dass es keine Wiederholungen gibt. Die Anzahl der Wiederholungen ist immer durch die Anzahl der verfügbaren Server im Cluster beschränkt.
Wichtig: Diese Anweisung gilt nicht für Verbindungsfehler oder Zeitlimitüberschreitungen aufgrund des ConnectTimeout des HTTP-Plug-ins. - ServerGibt eine Instanz von WebSphere Application Server an, die so konfiguriert ist, dass sie die Anforderungen, die an sie weitergeleitet werden, gemäß den Weiterleitungsregeln in der Plug-in-Konfiguration verarbeitet. Der Server entspricht einem Anwendungsserver, der auf der lokalen Maschine oder auf einer fernen Maschine ausgeführt wird. Geben Sie für jeden Server-Cluster null oder ein Attribut an.
- Name
Gibt den Verwaltungsnamen oder den logischen Namen für den Server an. Geben Sie für jeden Server genau ein Attribut an.
- CloneID
Wenn diese eindeutige ID im HTTP-Cookie-Header einer Anforderung vorhanden ist oder wenn der URL die URL-Umschreibung verwendet, wird die Anforderung vom Plug-in an diesen Server weitergeleitet, wenn alle anderen Weiterleitungsregeln erfüllt werden. Wird keine CloneID im Server angegeben, wird die Sitzungsaffinität für diesen Server nicht aktiviert. Für jeden Server kann null oder ein Attribut definiert sein.
Dieses Attribut wird mit der Sitzungsaffinität verwendet. Wenn dieses Attribut festgelegt ist, prüft das Plug-in, ob der ankommende Cookie-Header oder URL JSESSIONID enthält. Wenn JSESSIONID gefunden wird, sucht das Plug-in nach einer oder mehreren Klon-IDs. Falls Klon-IDs gefunden werden und eine Übereinstimmung mit dem für dieses Attribut angegebenen Wert festgestellt wird, wird die Anforderung an den Server weitergeleitet und nicht nach dem Lastausgleichsprinzip im Cluster verteilt.
Bewährtes Verfahren: Wenn Sie die Sitzungsaffinität nicht verwenden, entfernen Sie diese Klon-IDs aus der Konfiguration, weil im Plug-in eine zusätzliche Anforderungsverarbeitung anfällt, wenn diese Werte festgelegt sind. Wenn im Plug-in keine Klon-IDs enthalten sind, geht es davon aus, dass die Sitzungsaffinität nicht aktiviert ist, und die Anforderung wird im Lastausgleichsverfahren auf den Cluster verteilt.bprac
- WaitForContinue
Gibt an, ob die Unterstützung von HTTP 1.1 100 Continue verwendet werden soll, bevor der Anforderungsinhalt an den Anwendungsserver gesendet wird. Mögliche Attributwerte sind true oder false. Der Standardwert ist false. Das Plug-in wartet nicht auf die Antwort 100 Continue vom Anwendungsserver, bevor es den Anforderungsinhalt sendet, weil dies eine Leistungsbeeinträchtigung ist. Geben Sie für jeden Server null oder ein Attribut an.
Diese Eigenschaft wird für POST-Anforderungen ignoriert, um zu verhindern, dass ein Fehler auftritt, wenn der Anwendungsserver eine Verbindung aufgrund eines Keepalive-Zeitlimits schließt.
Aktivieren Sie diese Funktion, indem Sie sie auf true setzen, wenn sie das Plug-in für bestimmte Arten von Proxy-Firewalls konfigurieren.
- LoadBalanceWeight
Gibt die Wertigkeit dieses Servers an, wenn das Plug-in einen Wertigkeiten basierenden Round-Robin-Lastausgleich durchführt. Geben Sie für jeden Server null oder ein Attribut an. Der Anfangswert für einen Server kann eine ganze Zahl zwischen 0 und 20 sein. Geben Sie null nur für einen Server an, der nicht aktiv ist.
Der "LoadBalanceWeight"-Wert für jeden Server wird für jede vom Server verarbeitete Anforderung verringert. Wenn die Wertigkeit für einen bestimmten Server in einem Server-Cluster null erreicht, werden nur noch Anforderungen mit Sitzungsaffinität an diesen Server weitergeleitet. Wenn alle Server im Cluster die Wertigkeit null erreicht haben, werden die Wertigkeiten aller Server im Cluster zurückgesetzt, und der Algorithmus startet erneut.
Bewährtes Verfahren: Wenn ein Server nicht aktiv ist, wird die Wertigkeit dieses Servers auf null gesetzt. Daraufhin kann das Plug-in die Wertigkeiten der noch aktiven Server zurücksetzen und einen ordnungsgemäßen Lastausgleich sicherstellen.bprac
- ConnectTimeout
Ermöglicht es dem Plug-in, nicht blockierende Verbindungen mit dem Anwendungsserver aufzubauen. Nicht blockierende Anwendungen sind von Vorteil, wenn das Plug-in keine Verbindung zum Ziel herstellen kann, um festzustellen, ob der Port verfügbar ist. Geben Sie für jeden Server null oder ein Attribut an.
Wenn kein ConnectTimeout-Wert angegeben oder der Wert "0" angegeben wird, stellt das Plug-in eine geblockte Verbindung her, in der das Plug-in wartet, bis ein Betriebssystem das Zeitlimit überschreitet (je nach Plattform 2 Minuten) und dem Plug-in erlaubt, den Server als nicht verfügbar zu markieren. Der Wert 0 bewirkt, dass das Plug-in eine geblockte Verbindung herstellt. Ein Wert größer als null gibt die Anzahl Sekunden an, die das Plug-in auf eine erfolgreiche Verbindungsherstellung warten soll. Falls in diesem Zeitintervall keine Verbindung aufgebaut wird, markiert das Plug-in den Server als nicht verfügbar und wird von einem der anderen Server übernommen, die im Cluster definiert sind.
Der Standardwert ist 5.
- ExtendedHandshake
Wird verwendet, wenn eine Proxy-Firewall zwischen das Plug-in und den Anwendungsserver geschaltet ist. In einem solchen Fall funktioniert das Plug-in-Failover nicht wie erwartet. Geben Sie für jeden Server null oder ein Attribut an.
Das Plug-in markiert einen Server als inaktiv, wenn die Methode "connect()" fehlschlägt. Wenn sich jedoch eine Proxy-Firewall zwischen dem Plug-in und dem Anwendungsserver befindet, ist die Methode "connect()" auch dann erfolgreich, wenn der Back-End-Anwendungsserver inaktiv ist. Deshalb funktioniert das Plug-in-Failover an die anderen Anwendungsserver nicht ordnungsgemäß.
Das Plug-in führt Handshakes mit dem Anwendungsserver durch, um sicherzustellen, dass dieser gestartet ist, bevor das Plug-in die Anforderung sendet. In diesem Szenario ist ein Plug-in-Failover möglich, wenn der Anwendungsserver inaktiv ist.
Die gültigen Werte sind true und false.
- MaxConnections
Gibt die maximale Anzahl angehender Verbindungen zu einem Anwendungsserver an, die zu jeder Zeit über einen Web-Server-Prozess abgewickelt werden können. Geben Sie für jeden Server ein Element an.
Sehen Sie sich z. B. das folgende Szenario an:- Dem Anwendungsserver sind fünf Knoten vorangestellt, auf denen ein IBM HTTP Server ausgeführt wird.
- Jeder Knoten startet zwei Prozesse.
- Das Attribut "MaxConnections" ist auf 50 gesetzt.
In diesem Beispiel könnte der Application Server bis zu 500 Verbindungen erhalten. Multiplizieren Sie die Anzahl der Knoten (5) mit der Anzahl der Prozesse (2), und multiplizieren Sie anschließend diese Zahl mit der Zahl, die Sie für das Attribut "MaxConnections" (50) angegeben haben. Sie erhalten als das Gesamtergebnis 500 Verbinden.
Dieses Attribut ist unter dem Betriebssystem z/OS nicht erforderlich. Der z/OS-Controller, der mit Workload Manager (WLM) arbeitet, verarbeitet neue Verbindungen dynamisch.
Standardmäßig ist MaxConnections auf -1 gesetzt. Wenn dieses Attribut auf null oder -1 gesetzt wird, ist die Anzahl anstehender Verbindungen zu Anwendungsservern nicht beschränkt.
- Transport
Gibt den Transport für Lese- und Schreibanforderungen an eine bestimmte Instanz von WebSphere Application Server an. Der Transport stellt die Informationen bereit, die erforderlich sind, um die Position des Anwendungsservers zu bestimmen, an den die Anforderung gesendet wird. Das Plug-in erkennt nicht, wenn mehrere Transporte so definiert sind, dass sie dasselbe Protokoll verwenden. Es kann nicht vorhergesagt werden, welchen Transport das Plug-in auswählt. Das Plug-in wählt immer den ersten Transport aus, den es bei der Verarbeitung findet. Geben Sie für jeden Server ein oder mehrere Elemente an.
Der Server kann so konfiguriert werden, dass er einen nicht gesicherten Transport verwendet und einen Transport, der SSL verwendet. In dieser Konfiguration wird das Protokoll der eingehenden Anforderung abgeglichen, um den geeigneten Transport zum Senden der Anforderung an den Anwendungsserver zu ermitteln.
- Hostname
Gibt den Hostnamen oder die IP-Adresse des Systems an, auf dem die Instanz von WebSphere Application Server ausgeführt wird. Für jeden Transport gibt es genau ein Attribut.
- Port
Gibt den Port an, an dem die Instanz von WebSphere Application Server empfangsbereit ist. Für jeden Transport gibt es genau ein Attribut.
- Protocol
Gibt das Protokoll an, das für die Kommunikation über diesen Transport verwendet werden soll: HTTP oder HTTPS. Für jeden Transport gibt es genau ein Attribut.
- Hostname
- PropertyGeben Sie für jeden Transport null, ein oder mehrere Elemente an. Wenn als Protokoll des Transports HTTPS angegeben ist, verwenden Sie dieses Element um verschiedene Initialisierungsparameter, z. B. Kennwörter, Schlüsselring und Stashdatei, bereitzustellen. Der Abschnitt der Datei plugin-cfg.xml, der diese Elemente enthält, könnte z. B. wie der folgende Code aussehen:
<Transport Hostname="192.168.1.2" Port="9443" Protocol="HTTPS"> <Property Name="keyring" value="c:/WebSphere/AppServer/keys/keyring.kdb"/> <Property Name="stashfile" value="c:/WebSphere/AppServer/keys/keyring.sth"/> <Property Name="password" value="WebAS"/>
- Name
Gibt den Namen der Eigenschaft an, die definiert wird. Die unterstützten Namen, die vom Transport erkannt werden, sind keyring, stashfile und password.
Geben Sie für jede Eigenschaft nur jeweils ein Attribut an.Fehler vermeiden: Der einzige Name, der für das WebSphere-HTTP-Plug-in für z/OS angegeben werden kann, ist password. Wenn Sie keyring und stashfile angegeben, werden diese ignoriert. gotcha
- Value
Gibt den Wert der Eigenschaft an, die definiert wird. Geben Sie für jede Eigenschaft genau ein Attribut an.
- Name
- ServerIOTimeout
Ermöglicht dem Plug-in, einen Zeitlimitwert in Sekunden festzulegen, innerhalb dessen Anforderungen an den Anwendungsserver gesendet und Antworten vom Anwendungsserver gelesen werden können.
Wenn Sie für das Attribut "ServerIOTimeout" einen positiven Wert setzen, endet der Versuch, eine Verbindung zum Server herzustellen, nach Ablauf des Zeitlimits. Der Server wird jedoch nicht "nicht verfügbar" betrachtet und künftige Anforderungen werden weiterhin an den Server gesendet, für den das Zeitlimit wegen Nichtverfügbarkeit abgelaufen ist.
Wenn Sie das Attribut "ServerIOTimeout" auf einen negativen Wert setzen, wird der Server jedes Mal, wenn ein Zeitlimit eintritt, als nicht verfügbar betrachtet, und es werden keine weiteren Anforderungen an den Server, auf dem das Zeitlimit überschritten wurde, gesendet.
Wenn Sie keinen Wert für das Attribut "ServerIOTimeout" setzen, verwendet das Plug-in standardmäßig E/A-Operationen mit Blockierung, um Anforderungen in den Anwendungsserver zu schreiben und Antworten aus dem Anwendungsserver zu lesen, und verwendet kein Zeitlimit für TCP-Verbindungen. Sie können beispielsweise die folgende Einstellung angeben:
<Server Name="server1" ServerIOTimeout=300>
Wenn in diesem Fall ein Anwendungsserver aufhört, Anforderungen zu beantworten, wartet das Plug-in 300 Sekunden (5 Minuten), bevor es eine Zeitlimitüberschreitung für die TCP-Verbindung auslöst. Wenn Sie das Attribut "ServerIOTimeout" auf einen angemessenen Wert einstellen, kann das Plug-in die Verbindung bei einer Zeitlimitüberschreitung schneller beenden und Anforderungen, falls möglich, an einen anderen Anwendungsserver übertragen.
Wenn Sie einen Wert für dieses Feld auswählen, beachten Sie, dass ein Anwendungsserver möglicherweise ein paar Minuten benötigt, um eine Anforderung zu verarbeiten. Wenn Sie für das Attribut "ServerIOTimeout" einen zu niedrigen Wert festlegen, kann dies zur Folge haben, dass das Plug-in einen Fehler aufgrund eines falschen Servers an den Client zurückgibt.
Der Standardwert ist 900 (entspricht 15 Minuten).
Fehler vermeiden: Das Attribut "ServerIOTimeout" begrenzt die Zeitdauer, während der das Plug-in auf die Rückkehr jeder einzelnen Lese- oder Schreiboperation wartet. "ServerIOTimeout" ist kein Zeitlimit für die Gesamtanforderung. gotcha
Weitere Empfehlungen zum Konfigurieren des Attributs "ServerIOTimeout" finden Sie im technischen Hinweis zur Konfiguration von Web-Server-Plug-ins auf der Website des IBM Support.
Es ist nicht erforderlich, dass alle Anforderungen, die an den Anwendungsserver gesendet, oder Antworten, die vom Anwendungsserver gelesen werden, dieselben Zeitlimitregeln des Typs ServerIOTimeout, ServerIOTimeoutRetry, and Extended Handshake / 100 Continue verwenden. Nicht jede URL verhält sich gleich und bei der Verarbeitung ist möglicherweise für eine Anforderung ein kürzeres Zeitlimit erforderlich oder es ist nicht erforderlich, dass eine Anforderung auf jedem Server wiederholt wird. Sie können bestimmte URLs festlegen, die eine modifizierte Zeitlimitregel des Typs ServerIOTimeout, ServerIOTimeoutRetry oder ein kürzeres Zeitlimit für ExtendedHandshake oder 100-Continues verwendet. Andere URLs (die nicht modifiziert wurden) verwenden weiterhin die in der Datei "Plugin-cfg.xml" angegebenen Werte.
Wenn Sie für eine URL eine modifizierte Zeitlimitverarbeitung festlegen möchten, ändern Sie die Datei httpd.conf mit SetEnvIf-Anweisungen. Ähnlich wie für die Eigenschaften in der Datei "Plugin-cfg.xml" können sowohl für "websphere-serveriotimeout" als auch für "websphere-serveriotimeoutretry" dieselben Werte festgelegt werden. "WebSphere-shorten-handshake" kann nur auf "1" gesetzt werden. Damit wird dem Plug-in mitgeteilt, dass der "ConnectTimeout"-Wert als Wartezeit für "ExtendedHandshake"- oder "100-Continue"-Antwortet verwendet werden soll. Beispiel:SetEnvIf Request_URI "\.jsp$" websphere-serveriotimeout=10 SetEnvIf Request_URI "\.jsp$" websphere-serveriotimeoutretry=-1 SetEnvIf Request_URI "\.jsp$" websphere-shorten-handshake=1
- Name
- wsServerIOTimeout
Dieses Attribut legt einen Zeitlimitwert in Sekunden für anstehende Lese- und Schreibaktionen zwischen dem Web-Server-Plug-in und einer WebSocket-Anwendung fest. Wenn der angegebene Wert überschritten wird, werden Ressourcen, die von einem nicht antwortenden Anwendungsserver blockiert werden, freigegeben.
Der Standardwert ist 30 Sekunden.
- wsServerIdleTimeout
Dieses Attribut legt einen Zeitlimitwert in Sekunden fest, für den eine Verbindung zwischen dem Web-Server-Plug-in und einer WebSocket-Anwendung inaktiv sein kann. Wenn der angegebene Wert überschritten wird, werden Ressourcen, die von einem Anwendungsserver blockiert werden, freigegeben.
Der Standardwert ist 900 Sekunden.
- ClusterAddress
Eine Clusteradresse (ClusterAddress) ist wie ein Serverelement, da Sie hier dieselben Attribute und Elemente angeben können wie für ein Serverelement. Der Unterschied besteht darin, dass Sie nur eines der beiden Attribute in einem Server-Cluster (ServerCluster) definieren können. Verwenden Sie eine Clusteradresse, wenn Sie nicht wünschen, dass das Plug-in einen Lastausgleich durchführt, da bereits einen Lastausgleich zwischen dem Plug-in und dem Anwendungsserver besteht.
Fehler vermeiden: Wenn Sie den Tag "ClusterAddress" aufnehmen, müssen Sie in dieses Tag das Attribut Name einfügen. Das Plug-in verwendet das Attribut Name, um die Clusteradresse dem richtigen Host und Port zuzuordnen. Wenn Sie das Attribut Name nicht angeben, ordnet das Plug-in der Clusteradresse den Namen zu, der für den Server angegeben wurde, der denselben Host und Port verwendet.
gotcha<ClusterAddress Name="MyClusterAddr"> <Transport Hostname="192.168.1.2" Port="9080" Protocol="HTTP"/> <Transport Hostname="192.168.1.2" Port="9443" Protocol="HTTPS"> </ClusterAddress>
Wenn eine Anforderung eingeht, für die keine Affinität definiert ist, leitet das Plug-in sie an die Clusteradresse, falls definiert, weiter. Wurde Affinität definiert, leitet das Plug-in die Anforderung direkt an den Klon weiter und umgeht dabei die Clusteradresse vollständig. Wenn keine Clusteradresse für den Server-Cluster definiert ist, verteilt das Plug-in die Anforderungen gleichmäßig auf die Server, die in der Liste der primären Server enthalten sind.
Für jeden Server-Cluster können null oder ein Elemente vorhanden sein.
- PrimaryServers
Gibt eine Liste mit den Servern an, an die das Plug-in Anforderungen für diesen Cluster weiterleitet. Wenn keine Liste mit primären Servern definiert ist, leitet das Plug-in Anforderungen an Server weiter, die für den Server-Cluster definiert sind. Geben Sie für jeden Server-Cluster null oder ein Element an.
- BackupServers
Gibt eine Liste mit den Servern an, an die das Anforderungen gesendet werden, wenn alle in der Liste der primären Server angegebenen Server nicht verfügbar sind. Das Plug-in führt keinen Lastausgleich auf Ausweichservern durch, sondern durchläuft die Liste in der angegebenen Reihenfolge, bis keine weiteren Server in der Liste verfügbar sind oder bis eine Anforderung erfolgreich gesendet und eine Antwort von einem Anwendungsserver empfangen werden konnte. Geben Sie für jeden Server-Cluster null oder ein Element an.
VirtualHostGroup
Gibt eine Gruppe mit Namen virtueller Hosts an, die im HTTP-Host-Header angegeben sind. Verwenden Sie diese Eigenschaft, um Definitionen virtueller Hosts, die für denselben Typ Anforderungen konfiguriert wurden, zu gruppieren.
Das folgende Beispiel zeigt ein Element VirtualHostGroup und die zugeordneten Elemente und Attribute:
<VirtualHostGroup Name="Hosts">
<VirtualHost Name="www.x.com"/>
<VirtualHost Name="www.x.com:443"/>
<VirtualHost Name="*:8080"/>
<VirtualHost Name="www.x.com:*"/>
<VirtualHost Name="*:*"/>
</VirtualHostGroup>
- Name
Gibt den logischen Namen oder den Verwaltungsnamen an, der für diese Gruppe von virtuellen Hosts verwendet werden soll. Geben Sie für jede VirtualHostGroup genau ein Attribut an.
- VirtualHost
Gibt den Namen an, der für eine virtuelle oder reale Maschine verwendet wird und festlegt, ob ankommende Anforderungen von WebSphere Application Server ausgeführt werden müssen. Verwenden Sie dieses Element, um Hostnamen anzugeben, die HTTP-Host-Header enthalten sind und die für vom Anwendungsserver auszuführende Anforderungen sichtbar sein müssen. Sie können bestimmte Hostnamen und Ports für eingehende Anforderungen angeben oder einen Stern (*) für den Hostnamen und/oder den Port angeben.
Für jede "VirtualHostGroup" können Sie ein oder mehrere Elemente angeben.
- Name
Gibt den Namen im HTTP-Host-Header an, der mit dem Namen im "VirtualHost" übereinstimmt. Geben Sie für jeden "VirtualHost" genau ein Attribut an.
Der Wert ist eine Kombination aus Hostname bzw. IP-Adresse und Port, bei der die Angaben durch einen Doppelpunkt getrennt sind.
Sie können das Plug-in so konfigurieren, dass es Anforderungen basierend auf dem eingehenden HTTP-Host-Header und dem Port für die Anforderungen an den Anwendungsserver weiterleitet. Das Attribut Name legt diese Kombinationen fest.
Sie können ein Platzhalterzeichen für dieses Attribut verwenden. Die einzigen akzeptablen Lösungen sind ein Stern (*) für den Hostnamen, ein Stern für den Port oder ein Stern für beides. Ein Stern für beide Elemente bedeutet, dass alle Anforderungen mit dieser Regel übereinstimmen. Wird in der Definition kein Port angegeben, wird der HTTP-Standardport 80 angenommen.
- Name
UriGroup
Legt eine Gruppe von URIs fest, die in der Zeile mit der HTTP-Anforderung angegeben werden. Derselbe Anwendungsserver muss in der Lage sein, die URIs zu bearbeiten. Die Route vergleicht den ankommenden URI mit den URIs in der Gruppe, um festzulegen, welcher Anwendungsserver die Anforderung verarbeitet.
Das folgende Beispiel zeigt ein Element "UriGroup" und die zugordneten Elemente und Attribute.
<UriGroup Name="Uris">
<Uri Name="/servlet/snoop/">
<Uri Name="/webapp/*/">
<Uri Name="*.jsp/">
</UriGroup>
- Name
Gibt den logischen Namen oder den Verwaltungsnamen an, der für diese Gruppe von URIs verwendet werden soll. Geben Sie für jede "UriGroup" genau ein Attribut an.
- Uri
Gibt den virtuellen Pfad zu der Ressource an, die von WebSphere Application Server bedient wird. Jeder URI gibt die ankommenden URLs an, die der Anwendungsserver bearbeiten muss. In diesen Definitionen können Platzhalterzeichen verwendet werden. Für jede "UriGroup" können Sie ein oder mehrere Attribut angeben.
- Name
Gibt die tatsächliche Zeichenfolge an, die in der Zeile mit der HTTP-Anforderung angegeben werden muss, damit eine Übereinstimmung mit dieser URI erzielt wird. In der URI-Definition können Platzhalterzeichen verwendet werden. Sie können Regeln wie "*.jsp" oder "/servlet/*" angeben, die von WebSphere Application Server ausgeführt werden sollen. Wenn Sie beim Assemblieren Ihrer Anwendung angeben, dass der Dateiservice aktiviert wird, wird nur ein URI mit Platzhaltern für die Webanwendung generiert, unabhängig von anderen expliziten Servletzuordnungen. Wenn Sie Servlets nach Klassennamen bereitstellen angeben, wird der folgende URI generiert: <Uri Name="URI_der_Webanwendung/servlet/*">
Für jeden URI gibt es genau ein Attribut.
- AffinityCookie
Gibt den Namen des Cookie an, das das Plug-in verwendet, wenn es versucht festzustellen, ob die eingehende Anforderung Sitzungsaffinität hat. Der Standardwert ist JSESSIONID.
Weitere Informationen zur Sitzungsaffinität finden Sie in der Beschreibung des Attributs "CloneID".
Für jeden URI kann null oder ein Attribut definiert sein.
- AffinityURLIdentifier
Gibt den Namen der Kennung an, die das Plug-in verwendet, wenn es versucht festzustellen, ob für die eingehende Anforderung im URL eine Affinität zu einem bestimmten Klon angegeben ist. Der Standardwert ist jsessionid.
Weitere Informationen zur Sitzungsaffinität finden Sie in der Beschreibung des Attributs "CloneID".
Für jeden URI kann null oder ein Attribut definiert sein.
- Name
Route
Gibt eine Weiterleitungsregel für die Anforderung an, anhand der das Plug-in feststellt, ob eine eingehende Anforderung von WebSphere Application Server ausgeführt werden muss.
Die Routendefinition ist das zentrale Element einer Plug-in-Konfiguration. Sie legt anhand bestimmten Merkmale der Anforderungen fest, wie das Plug-in die Anforderungen ausführt. Die Routendefinition enthält die anderen Hauptelemente: einen erforderlichen Server-Cluster, eine Gruppe virtueller Hosts und/oder eine URI-Gruppe.
Anhand der Informationen, die in der Gruppe virtueller Hosts ("VirtualHostGroup") und der URI-Gruppe ("UriGroup") für die Route definiert sind, ermittelt das Plug-in, ob die eingehende Anforderung an das in dieser Route definierte Element "ServerCluster" gesendet wird.
Nachfolgend sehen Sie ein Beispiel für dieses Element:
<Route VirtualHostGroup="Hosts" UriGroup="Uris" ServerCluster="servers"/>
- VirtualHostGroup
Gibt die Gruppe virtueller Hosts an, die für das Bestimmen der Route verwendet werden. Der eingehende Host-Header und Server-Port werden abgeglichen, um festzustellen, ob diese Anforderung vom Anwendungsserver ausgeführt wird.
Diese Eigenschaft kann in der Routendefinition weggelassen werden. Wenn sie nicht angegeben wird, gelten beim Abgleich des virtuellen Hosts in der Routenbestimmung alle Anforderungen als übereinstimmend.
Für jede Route kann null oder ein Attribut definiert sein.
- UriGroup
Gibt die Gruppe der URIs an, die bei der Routenbestimmung verwendet werden sollen. Wählen Sie für jede Route null oder ein Attribut aus. Der eingehende URI für die Anforderung wird mit den in dieser Gruppe definierten URIs abgeglichen, um zu bestimmen, ob diese Anforderung vom Anwendungsserver ausgeführt werden soll.
Diese Eigenschaft kann in der Routendefinition weggelassen werden. Wenn sie nicht angegeben wird, gelten beim Abgleich des URI in der Routenbestimmung alle Anforderungen als übereinstimmend.
- ServerCluster
Gibt den Cluster für die Anforderungen an, die mit der Route übereinstimmen. Wählen Sie für jede Route genau einen Cluster aus.
Der Cluster wird für die Bearbeitung dieser Anforderung verwendet. Wenn sowohl der URI als auch der virtuelle Host für diese Route erfolgreich abgeglichen wurden, wird die Anforderung an einen in diesem Cluster definierten Server gesendet.
RequestMetrics
Hiermit wird festgelegt, ob die Request Metrics aktiviert sind und wie die Anforderungen basierend auf IP-Filtern (Internet Protocol) und URI-Filtern (Uniform Resource Identifier) gefiltert werden sollen, wenn die Request Metrics aktiviert sind.
Nachfolgend sehen Sie ein Beispiel für dieses Element:
<RequestMetrics armEnabled="false" loggingEnabled="true"
rmEnabled="false" traceLevel="PERF_DEBUG">
- armEnabled
Gibt an, ob der Agent ARM 4 im Plug-in aktiviert ist. Wenn Sie diese Einstellung auf true setzen, wird der ARM-4-Agent aufgerufen.
Fehler vermeiden: Für den Web-Server SunOne (iPlanet) muss die folgende Anweisung in die Datei obj.conf eingeschlossen werden, um die Unterstützung für ARM 4 zu aktivieren:
Wenn diese Anweisung nicht aufgenommen wird, wird die Prozedur "arm_stop" niemals aufgerufen. gotchaAddLog fn="as_term"
Wählen Sie für "RequestMetrics" null oder ein Attribut aus.
- loggingEnabled
Gibt an, ob die Request-Metrics-Protokollierung im Plug-in aktiviert ist. Wenn Sie den Wert true festlegen und für "traceLevel" nicht NONE angegeben ist, werden die Antwortzeit der Anforderung und andere Informationen zur Anforderung protokolliert. Wird der Wert false angegeben, werden Anforderungen nicht protokolliert. Der Wert von "loggingEnabled" ist abhängig von dem Wert, den Sie für die Systemeigenschaft "com.ibm.websphere.pmi.reqmetrics.loggingEnabled" angegeben haben. Wenn diese Systemeigenschaft nicht vorhanden ist, wird "loggingEnable" auf den Wert true gesetzt. Geben Sie für "RequestMetrics" genau ein Attribut an.
- rmEnabled
Gibt an, ob die Request Metrics im Plug-in aktiviert sind. Wenn Sie die Eigenschaft auf true setzen, prüft das Plug-in (Request Metrics) die Filter und protokolliert den Tracesatz der Anforderung in der Plug-in-Protokolldatei. Diese Aktion wird ausgeführt, wenn eine Anforderung die Filter übergibt. Wenn Sie dieses Attribut auf den Wert false setzen, werden die übrigen Request-Metrics-Attribute ignoriert. Geben Sie für "RequestMetrics" genau ein Attribut an.
- traceLevel
Zeigt an, wie viele Informationen protokolliert werden, wenn das Attribut rmEnabled auf true gesetzt ist. Wenn dieses Attribut auf NONE gesetzt ist, findet keine Anforderungsprotokollierung statt. Wenn für dieses Attribut nicht der Wert NONE festgelegt ist und "loggingEnabled" auf true gesetzt ist, werden bei Ausführung der Anforderung die Antwortzeit der Anforderung und andere Informationen zur Anforderung protokolliert. Geben Sie für "RequestMetrics" genau ein Attribut an.
- filters
Wenn "rmEnabled" auf true gesetzt ist, steuern die Filter, für welche Anforderungen ein Trace durchgeführt wird. Geben Sie für "RequestMetrics" null, ein oder zwei Attribute an.
- enable
Wenn dieses Attribut auf true gesetzt ist, ist der Filtertyp aktiv und die Anforderungen müssen den Filter übergeben. Geben Sie für jeden Filter genau ein Attribut an.
- type
Es gibt zwei Arten von Filtern: SOURCE_IP (z. B. Client-IP-Adresse) und URI. Beim Filter-Typ SOURCE_IP werden die Anforderungen basierend auf einer bekannten IP-Adresse gefiltert. Mit dem Stern (*) können Sie eine Maske für eine IP-Adresse angeben. Wenn Sie den Stern verwenden, muss dieser immer das letzte Zeichen der Maske sein, z. B. 127.0.0.*, 127.0.*, 127*. Aus Gründen der Leistungsfähigkeit vergleicht die Mustererkennung Zeichen für Zeichen, bis entweder im Filter ein Stern vorkommt, eine Abweichung auftritt oder der Filter als exakte Übereinstimmung erkannt wird.
Beim Filter-Typ URI werden die Anforderungen basierend auf dem URI der eingehenden HTTP-Anforderung gefiltert. Die Regeln für die Mustererkennung sind dieselben wie für die SOURCE_IP-Adressfilter.
Wenn Filter für URIs und Client-IP-Adressen aktiviert sind, setzt Request Metrics eine Übereinstimmung für beide Filtertypen voraus. Ist keiner von beiden aktiv, werden alle Anforderungen als Übereinstimmung betrachtet.
Für jeden Filter gibt es genau ein Attribut.
- filterValues
Gibt die detaillierten Filterinformationen an. Geben Sie für jeden Filter ein oder mehrere Attribute an.
- value
Gibt den Filterwert für den entsprechenden Filtertyp an. Bei diesem Wert kann es sich um eine Client-IP-Adresse oder um einen URI handeln. Geben Sie für jeden Filterwert ("filterValue") genau ein Attribut an.
- value
- enable