Dieser Anhang beschreibt die Syntax der Inhaltsregel (des Musters) für die Komponente CBR und die Weiterleitungsmethode cbr der Komponente Dispatcher sowie Szenarien und Beispiele für ihre Verwendung.
Diese Angaben gelten nur, wenn Sie als Regeltyp "content" (Inhalt) ausgewählt haben.
Beachten Sie bei der Syntax des gewünschten Musters die folgenden Einschränkungen:
Auf reservierte Schlüsselwörter folgt immer ein Gleichheitszeichen „=".
Ein Browser, der http://www.firma.com/pfad/webseite.htm aufruft, kann folgende Werte zurückgeben:
Method=GET
URI=/pfad/webseite.htm
Version=HTTP/1.1
Host=www.firma.com
Connection=Keep-Alive
Referer=http://www.firma.com/pfad/elternwebseite.htm
Der folgende Befehl ist nur gültig, wenn Sie die Eingabeaufforderung cbrcontrol>> oder eine Konfigurationsdatei verwenden:
rule add 10.1.203.4:80:cbr_prod_rule_ek type content
pattern "uri=/nipoek/*"
Wenn Sie Sonderzeichen verwenden und derselbe Befehl über die Eingabeaufforderung des Betriebssystems funktionieren soll, müssen Sie den vollständigen Befehl in doppelte Anführungszeichen setzen:
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content
pattern uri=/nipoek/*"
Fehlen die Anführungszeichen, könnte beim Speichern der Regel in CBR ein Teil des Musters abgeschnitten werden.
Nachfolgend finden Sie eine Zusammenstellung möglicher Szenarien und Beispiele für die Mustersyntax.
Szenario 1:
Zur Konfiguration für einen Clusternamen gehört eine Gruppe von Webservern für Standard-HTML-Inhalt, eine weitere Gruppe von Webservern mit WebSphere Application Server für Servlet-Anforderungen, eine dritte Gruppe von Lotus-Notes-Servern für NSF-Dateien usw. Der Zugriff auf die Clientdaten ist erforderlich, um zwischen den angeforderten Seiten unterscheiden zu können. Die Daten müssen außerdem an die jeweils geeigneten Server gesendet werden. Die Erkennungsregeln für Inhaltsmustererkennung ermöglichen die für diese Tasks notwendige Trennung. Es wird eine Reihe von Regeln konfiguriert, die die nötige Trennung der Anforderungen automatisch vornehmen. Mit den folgenden Befehlen können Sie die genannte Trennung in drei Gruppen erreichen:
>>rule add cluster1:80:servlets type content pattern "uri=*/servlet/*" priority 1
>>rule uses Cluster1:80:servlets Server1+Server2
>>rule add cluster1:80:notes type content pattern "uri=*.nsf*" priority 2
>>rule uses Cluster1:80:notes Server3+Server4
>>rule add Cluster1:80:regular type true priority 3
>>rule uses Cluster1:80:regular Server5+Server6
Wenn Load Balancer eine Anforderung für eine NSF-Datei empfängt, wird zuerst die servlets-Regel angewendet, bei der jedoch keine Übereinstimmung gefunden wird. Anschließend wird die Anforderung mit der notes-Regel abgeglichen und eine Übereinstimmung festgestellt. Die Clientdaten werden auf Server3 und Server4 verteilt.
Szenario 2
Ein weiteres allgemeines Szenario ist die Steuerung unterschiedlicher interner Gruppen durch die Hauptwebsite. Beispiel: www.firma.com/software bezieht verschiedene Server und Inhalte aus dem Bereich www.firma.com/hardware ein. Da alle Anforderungen vom Root-Cluster www.firma.com ausgehen, sind Inhaltsregeln erforderlich, um die URI-Unterscheidung für den Lastausgleich vorzunehmen. Die Regel für dieses Szenario würde etwa wie folgt aussehen:
>>rule add cluster1:80:div1 type content pattern "uri=/software/*" priority 1
>>rule uses Cluster1:80:Bereich1 Server1+Server2
>>rule add cluster1:80:div2 type content pattern "uri=/hardware/*" priority 2
>>rule uses Cluster1:80:Bereich2 Server3+Server4
Szenario 3
Bei bestimmten Kombinationen ist die Reihenfolge wichtig, in der die Regeln durchsucht werden. Im Szenario 2 wurden die Clients beispielsweise ausgehend von einem Verzeichnis in ihrem Anforderungspfad aufgeteilt. Der Zielverzeichnispfad kann jedoch auf verschiedenen Ebenen dieses Pfades vorhanden sein und dort jeweils zu anderen Ergebnissen führen. So ist das Ziel www.firma.com/pcs/fixes/software beispielsweise von www.firma.com/mainframe/fixes/software verschieden. Die Regeln müssen dieser Möglichkeit Rechnung tragen und so konfiguriert werden, dass die nicht zu vielen Szenarien gleichzeitig gerecht werden. Die Platzhaltersuche „uri=*/software/*" wäre in diesem Falle zu breit angelegt. Alternative Regeln könnten wie folgt strukturiert sein:
Mit einer kombinierten Suche kann hier eine Eingrenzung vorgenommen werden:
>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)"
>>rule uses Cluster 1:80:pcs Server1
In Fällen, wo keine Kombinationen anwendbar sind, ist die Reihenfolge wichtig:
>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*"
>>rule uses Cluster1:80:pc1 Server2
Die zweite Regel wird angewendet, wenn „pcs" im Verzeichnis nicht an erster Stelle, sondern an einer späteren Stelle erscheint.
>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*"
>>rule uses Cluster1:80:pc2 Server3
In fast allen Fällen sollten Sie die Regeln durch eine Standardregel ergänzen, die immer wahr (always true) ist und für alles gelten soll, was nicht unter die übrigen Regeln fällt. In Szenarien, in denen alle Server für einen bestimmten Client nicht in Frage kommen, könnte dies auch ein Server mit der Antwort „Die Site ist derzeit nicht verfügbar, versuchen Sie es später erneut" sein.
>>rule add Cluster1:80:sorry type true priority 100
>>rule uses Cluster1:80:sorry Server5