Einstellungen für On Demand Router

Verwenden Sie diesen Artikel, um eine erweiterte Konfiguration für einen On Demand Router (ODR) durchzuführen. Mit ODR-Einstellungen können Sie das Verhalten des ODR optimieren. Sie können die Verbindungen und Anforderungen für den Anwendungsserver konfigurieren, Caching aktivieren, die Anforderungen konfigurieren, die zurückgewiesen werden müssen, die Verarbeitung von Fehlerantworten definieren und die Position der ODR-Protokolle festlegen.

Nach der Erstellung erkennt der ODR-Server automatisch die Umgebung und kann Anforderungen an WebSphere Application Server weiterleiten. Sie können den ODR weitergehend konfigurieren, um ihn an die Anforderungen Ihrer spezifischen Umgebung anzupassen.

Klicken Sie zum Anzeigen dieser Seite der Administrationskonsole auf Server > On Demand Router > ODR-Name > Merkmale für On Demand Router > Einstellungen für On Demand Router.

Auf der Registerseite Konfiguration können Sie Einstellungen für den ODR editieren.

Content-Server-Verbindung

Basisparameter für die HTTP-Verbindung zwischen dem Proxy-Server und Content-Servern konfigurieren.

Alias für abgehende SSL-Anforderungen
Der Alias für das SSL-Repertoire (Secure Sockets Layer), der unter Sicherheit > SSL konfiguriert und zum Schutz von Verbindungen zum ODR-Content-Server verwendet wird. Wenn Anforderungen nur in SSL-Verbindungen verarbeitet werden können, wird empfohlen, einen neuen SSL-Alias zu erstellen, der die anerkannten Zertifizierungsstellen enthält und auf diesen Alias verweist. Klicken Sie zum Erstellen eines SSL-Alias in der Administrationskonsole auf Sicherheit > SSL > Neues JSSE-Repertoire.
Zeitlimit für abgehende Anforderungen
Diese Einstellung legt fest, wie lange (in Sekunden) der ODR standardmäßig auf Antworten von Content-Servern wartet. Gehen Sie beim Ändern des Wertes sorgfältig vor.
Verbindungspools für Content-Server erstellen
Diese Optimierungsoption ermöglicht, Verbindungen zum Server in einem Pool verwalten zu können. Indem Sie dem ODR erlauben, die Verbindungen in einem Pool zu verwalten und wiederzuverwenden, entfällt die Notwendigkeit, ständig Socket-Verbindungen zum Server zu erstellen und zu trennen.
Maximale Anzahl Verbindungen pro Server
Die maximale Anzahl an Verbindungen, die für einen Content-Server in den Pool gestellt werden. Die benutzerdefinierten Merkmale des ODR, die Verbindungen zu Content-Servern beeinflussen, sind im Folgenden aufgeführt:
  • key=http.maxTargetReconnects: Gibt an, wie oft Anforderung an den Ziel-Content-Server maximal wiederholt wird. Der Standardwert ist 5.
  • key=http.maxTargetRetries: Gibt an, wie oft der ODR maximal versucht, einen neuen Ziel-Content-Server für eine Anforderung auszuwählen. Der Standardwert ist 5.
  • key=http.routing.sendReverseProxyNameInHost: Legt fest, ob der ODR-Name für Inhalte, die für die Content-Server von WebSphere Application Server nicht spezifisch sind, in den Host-Header aufgenommen wird. Die gültigen Optionen sind true und false. Es wird nicht zwischen Groß-/Kleinschreibung unterschieden. Die Standardeinstellung ist false.
  • key=http.compliance.disable: Legt fest, ob die Konformität mit HTTP Version 1.1 in Verbindungen zwischen ODR und Content-Servern umgesetzt wird. Die gültigen Optionen sind true und false. Es wird nicht zwischen Groß-/Kleinschreibung unterschieden. Die Standardeinstellung ist false.
  • key=http.compliance.via: Der Wert des Header via, der für die HTTP-Konformität an Anforderungen und Antworten angefügt wird. Wenn der Wert null ist, wird kein Header via angefügt. Wenn der Wert true ist, wird ein via-Standardwert angefügt. Andernfalls wird die als via-Wert angegebene Zeichenfolge angefügt. Der Standardwert ist null.

Caching

Der ODR kann so konfiguriert werden, dass der Inhalt von Servern zwischengespeichert wird.

Das Caching von Inhalten ist standardmäßig aktiviert. Die folgenden Merkmale gelten nur, wenn das Caching aktiviert ist:
Caching aktivieren
Aktiviert das Caching-Gerüst für den ODR und das Caching statischer Inhalte gemäß der Spezifikation HTTP 1.1.
Name der Cache-Instanz
Die Objekt-Cache-Instanz für Dynamic Cache, die unter Ressourcen > Cache-Instanzen > Objekt-Cache-Instanzen konfiguriert und für die Zwischenspeicherung aller statischen und dynamischen Inhaltsantworten verwendet wird. Diese Objekt-Cache-Instanz muss für die Unterstützung neuer E/A-APIs konfiguriert werden.
SSL-Inhalt zwischenspeichern
Bestimmt, ob die Antworten für SSL-Verbindungen zwischen dem Client und dem ODR, die vom ODR beendet werden, zwischengespeichert werden.
Aggressives Caching
Aktiviert das Caching für HTTP-Antworten die normalerweise nicht zwischengespeichert werden. Caching-Regeln, die nach HTTP 1.1 definiert wurden, können gebrochen werden, um eine Cache-Optimierung zu erzielen.
Dynamischen Inhalt zwischenspeichern
Bestimmt, ob dynamischer Inhalt, der von WebSphere Application Servern Version 6.02 oder höher generiert wird, zwischengespeichert wird. Das Zwischenspeichern dynamischer Inhalte, die von Content-Servern vor WebSphere Application Server Version 6.02 generiert werden, wird nicht unterstützt.
URI für Cache-Aktualisierung
Wenn Sie dynamische Inhalte zwischenspeichern, ist dies der relative URI einer installierten Content-Server-Anwendung, die verwendet wird, um zwischengespeicherte Einträge ungültig zu machen.

Ausschlüsse

Der ODR untersucht jede eingehende Anforderung. Sie können bestimmte Ausschlussmethoden definieren. Falls die angeforderte HTTP-Methode mit einer der konfigurierten Ausschlussmethoden übereinstimmt, weist der ODR die Anforderungen mit einem Fehler METHOD DISALLOWED zurück.

Inaktivierte HTTP-Methoden
Standardmäßig sind die Methoden CONNECT, PUT und DELETE inaktiviert.

Protokollierung

HTTP-Anforderungen werden in einem von drei Protokollen aufgezeichnet: Proxy, Cache oder lokal. Derzeit ist keine lokalen Protokollkonfiguration in der Administrationskonsole verfügbar, sondern nur unter ${SERVER_LOG_ROOT}local.log. Geben Sie die Position des Protokolls mit dem benutzerdefinierten Merkmal http.log.localFileName an. Für die Formatierung der Protokolle wird das allgemeine Protokollformat NCSA (National Center for Supercomputing Applications Common Log) verwendet.

Zugriffsprotokollierung aktivieren
Wählen Sie diese Option aus, um die Protokollierung zu aktivieren.
Maximale Größe des Zugriffsprotokolls
Die maximale Protokollgröße in Megabytes (MB). Der Wert UNLIMITED bedeutet unbegrenzt. Die Standardeinstellung sind 25 MB.
Proxy-Zugriffsprotokoll
In diesem Protokoll werden Antworten von fernen Servern aufgezeichnet.
Cache-Zugriffsprotokoll
In diesem Protokoll werden Antworten aufgezeichnet, die aus dem lokalen Cache bereitgestellt werden.
Lokales Zugriffsprotokoll
Enthält den Namen des lokalen Protokolls. Der Wert NULL zeigt an, dass das Standardprotokoll ${SERVER_LOG_ROOT}/local.log verwendet wird. In diesem Protokoll werden alle Antworten aufgezeichnet, die nicht aus dem lokalen Cache bereitgestellt werden, z. B. Umleitungen (Redirects) und interne Fehler. Dieser Inhalt stammt nicht aus dem ODR-Cache.

Sicherheit

In diesem Abschnitt können Sie Sicherheitsoptionen konfigurieren.

Anerkannte Sicherheits-Proxy-Server
In einigen Topologien ist oberhalb des ODR eine weitere Weiterleitungsschicht aktiviert. Beispielsweise lesen Webserver die eingehenden Anforderungen, um den ODR zu ermitteln, an den die Anforderungen weitergeleitet werden. Mit dieser Konfiguration können andere zwischengeschaltete Stationen als der ODR die Anforderung verarbeiten, indem der ODR explizit angewiesen wird, diesen Stationen zu vertrauen. Sie können eine IP-Adresse oder einen vollständig qualifizierten Hostnamen angeben.

Proxy-Policy für Plug-in-Konfiguration:

Plug-in-Konfiguration generieren
Dieser Parameter unterstützt die Generierung einer ODR-Plug-in-Konfigurationsdatei, die in einem Webserver verwendet werden kann, der dem ODR vorgeschaltet ist. Mit dieser Konfigurationsdatei ist das Plug-in in der Lage, den URI zu bestimmen, an dem der ODR stellvertretend für den Anwendungsserver Anforderungen bearbeitet. Außerdem kann das Plug-in den Endpoint und die Grenzen des ODR bestimmen, um die empfangenen Anforderungen ordnungsgemäß an den ODR weiterzuleiten. Dieses Feature ist hilfreich, wenn Sie einen bewährten Webserver in der Demilitarized Zone (DMZ) implementieren möchten, der die Funktionen des ODR vollständig nutzen kann.

Sie können eine Stufe definieren, auf der das Plug-in generiert werden soll. Für die Zellenebene generiert der Proxy-Server eine Plug-in-Konfiguration, die alle URIs enthält, die von allen Proxy-Servern in der Zelle bearbeitet werden können. Für die Knotenebene wird eine Konfiguration generiert, die alle URIs enthält, die für den Knoten definiert sind. Die für die Serverebene generierte Plug-in-Konfigurationsdatei ist ausschließlich für den Proxy-Server bestimmt, der derzeit konfiguriert ist.

Script für Änderung der Plug-in-Konfiguration
Gibt den Pfad zu einem Script an, das nach der Generierung der Plug-in-Konfiguration von WebSphere Application Server ausgeführt wird.

Policy für benutzerdefinierte Fehlerseite

Verwenden Sie dieses Feld für die Unterstützung benutzerdefinierter Fehlerseiten zu aktivieren, die ausgegeben werden können, wenn während der Verarbeitung der Anforderung Fehler auftreten.

Standardmäßig werden keine benutzerdefinierten Fehlerseiten generiert. Die folgenden Merkmale aktivieren die Verwendung benutzerdefinierte Fehlerseiten beim Auftreten von Fehlern während der Anforderungsverarbeitung:
Anwendungs-URI für die Generierung von Fehlerseiten
Wenn Sie keinen gültigen URI einer installierten Anwendung angeben, verarbeitet die Policy für benutzerdefinierte Fehlerseiten keine Anforderungen.
Ferne Fehler behandeln
Wenn Sie diese Option nicht auswählen, werden nur Fehlerstatuscodes zu HTTP-Antworten, die der ODR generiert, behandelt. Wenn Sie die Option auswählen, werden die vom ODR und die von anderen Komponenten hinter dem ODR (in der Verbindung zwischen ODR und Content-Servern) generierten Fehlerstatuscodes zu HTTP-Antworten behandelt. Es empfiehlt sich, eine Anwendung für Fehlerseiten auf derselben Maschine zu konfigurieren, auf der auch der ODR ausgeführt wird.
An Anwendung für Fehlerseiten weiterzuleitende Header
Gibt zusätzliche Header-Werte aus der Clientanforderung an, die als Abfrageparameter an die Anwendung für Fehlerseiten weitergeleitet werden sollen. Neben den konfigurierten Abfrageparametern werden die Parameter responseCode und URI immer an die Anwendung für Fehlerseiten gesendet. Der Parameter responseCode gibt den HTTP-Statuscode an, der intern generiert oder vom Content-Server zurückgegeben wird. Der Parameter URI gibt den Anforderungs-URI für den Client an.
Beispiel - Der URI für Fehlerseiten ist /ErrorPageApp/ErrorPage, die weiterzuleitenden Header enthalten Host, und ein Client sendet die folgende Anforderung:
GET  /house/rooms/kitchen.jpg HTTP/1.1
Host:  homeserver.companyx.com
Die Anforderung führt zu einer Antwort HTTP 404 (lokal oder fern), und der Anforderungs-URI zur Anwendung für Fehlerseiten ist:
/ErrorPageApp/ErrorPage?responseCode=404&uri=/house/rooms/kitchen.jpg&Host= homeserver.companyx.com
Als Fehler einzustufende HTTP-Statuscodes
Die Statuscodes, für die die Policy für Fehlerseiten eine Antwort bereitstellt. Wenn ein Statuscode angegeben ist, wird der ursprüngliche Inhalt der Antworten mit diesem Statuscode zurückgegeben. Wenn keine HTTP-Statuscodes angegeben sind, werden die Standardwerte 404 und 5XX verwendet. Anstatt die Statuscodes einzeln anzugeben, können Sie mit der folgenden Methode einen Bereich von Statuscodes angeben:
  • 5XX: 500-599
  • 4XX: 400-499
  • 3XX: 300-399
  • 2XX: 200-299