This appendix describes how to use the content rule (pattern) syntax for the CBR component and the Dispatcher component's cbr forwarding method, along with scenarios and examples of their usage.
Only applicable if you selected "content" for the rule type.
Enter the pattern syntax you want to use, with the following restrictions
Reserved keywords are always followed by an equal sign "=".
A browser targeting http://www.company.com/path/webpage.htm might result in values such as:
Method=GET URI=/path/webpage.htm Version=HTTP/1.1 Host=www.company.com Connection=Keep-Alive Referer=http://www.company.com/path/parentwebpage.htm
For example, the following command is valid only when using the cbrcontrol>> prompt or from a configuration file:
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
When using special characters, for this same command to work at the operating system's prompt you must place double quotation marks around the entire command:
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*"
If the quotation marks are not used, some of the pattern might be truncated when the rule is saved in CBR.
The following is a collection of possible scenarios and examples for using pattern syntaxes
Scenario 1:
The setup for one cluster name involves one set of Web servers for standard HTML content, another set of Web servers with WebSphere® Application Server for servlet requests, another set of Lotus® Notes® servers for NSF files, and so forth. Access to the client data is required to distinguish between those requested pages. It is also required to send them to the appropriate servers. The content pattern matching rules provide the separation needed to accomplish these tasks. A series of rules are configured so that the necessary separation of requests occurs automatically. For example, the following commands accomplish the three splits mentioned:
>>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
If a request for an NSF file arrives at Load Balancer, the servlets rule is checked first, but does not match. The request is then checked by the notes rule and returns a match. The client is load-balanced between server3 and server4.
Scenario 2
Another common scenario is when the main Web site controls several distinct internal groups. For example, www.company.com/software involves a different set of servers and content from www.company.com/hardware division. Because the requests are all based off the root www.company.com cluster, content rules are required to find the URI differences and complete load balancing. The scenario's rule looks similar to the following:
>>rule add cluster1:80:div1 type content pattern "uri=/software/*" priority 1 >>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern "uri=/hardware/*" priority 2 >>rule uses cluster1:80:div2 server3+server4
Scenario 3
Certain combinations are sensitive to the order in which rules are searched. For example, in Scenario 2, clients were split based on a directory in their request path; however, the target directory might appear at multiple levels of the path and mean different things on placement. For example, www.company.com/pcs/fixes/software is a different target from www.company.com/mainframe/fixes/software. The rules must be defined to account for this possibility and not catch too many scenarios at the same time. For example, the "uri=*/software/*" test is too broad a wildcard search in this case. Alternative rules could be structured in the following manner:
A combination search can narrow this down:
>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)" >>rule uses cluster 1:80:pcs server1
In cases where there are no combinations to use, the order becomes important:
>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*" >>rule uses cluster1:80:pc1 server2
The second rule catches when "pcs" appears in later directory spots instead of the first.
>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*" >>rule uses cluster1:80:pc2 server3
In almost every case, you want to complete the rules with a default always true rule to catch anything that falls through the other rules. This can also be a "Sorry, the site is currently down, please try again later" server for scenarios where all other servers fail for this client.
>>rule add cluster1:80:sorry type true priority 100 >>rule uses cluster1:80:sorry server5