Questa appendice descrive come utilizzare la sintassi della regola di contenuto (modello) per il componente CBR e per il metodo di inoltro cbr del componente Dispatcher e contiene scenari ed esempi di uso.
Applicabile solo se È stato selezionato "content" per il tipo di regola.
Immettere la sintassi modello che si desidera utilizzare, con le seguenti restrizioni:
Le parole chiave riservate sono sempre seguite da un segno di uguale "=".
Un browser che punta a http://www.company.com/path/webpage.htm potrebbe avere valori analoghi a quelli seguenti:
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
Ad esempio, il seguente comando è valido solo quando si utilizza il prompt cbrcontrol>> o da un file di configurazione.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content
pattern "uri=/nipoek/*"
Quando si utilizzano i caratteri speciali, affinché questo stesso comando funzioni sul prompt del sistema operativo, è necessario aggiungere le doppie virgolette (" ") intorno all'intero comando:
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content
pattern uri=/nipoek/*"
Se non si utilizzano le virgolette, è possibile che il modello venga troncato quando la regola viene salvata nel componente CBR.
Di seguito viene riportata una raccolta di scenari possibili e di esempi di uso delle sintassi modello.
Scenario 1
La configurazione per un nome cluster prevede un gruppo di server Web per il contenuto HTML standard, un secondo gruppo di server Web che comprenda WebSphere Application Server per le richieste servlet, un terzo gruppo di server Lotus Notes per i file NSF e così via. È necessario accedere ai dati client per distinguere queste pagine richieste. È anche necessario inviarli ai server appropriati. Le regole di corrispondenza dei contenuti forniscono la separazione necessaria per completare queste attività. Viene inoltre configurata una serie di regole in modo che la necessaria separazione delle richieste venga eseguita automaticamente. Ad esempio, i seguenti comandi consentono di effettuare le tre suddivisioni menzionate:
>>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
Se a Load Balancer arriva una richiesta per un file NSF, viene controllata per prima la regola dei servlet, che non offre alcuna corrispondenza. La richiesta è quindi controllata dalla regola di Notes che restituisce una corrispondenza. Il carico del client viene bilanciato tra il server3 e il server4.
Scenario 2
Un altro scenario comune È un sito Web principale che controlla numerosi gruppi interni distinti. Ad esempio, www.company.com/software comporta un gruppo di server diversi e il contenuto della sezione www.company.com/hardware. Poiché le richieste si basano tutte sul cluster root www.company.com , le regole di contenuto sono necessarie per trovare le differenze di URI e completare il bilanciamento del carico. La regola dello scenario È simile a quanto segue:
>>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
Alcune combinazioni sono sensibili all'ordine in cui le regole vengono ricercate. Ad esempio, nello scenario 2, i client erano suddivisi in base a una directory del percorso delle rispettive richieste; tuttavia, la directory di destinazione potrebbe comparire a più livelli del percorso e comportare conseguenze diverse nel posizionamento. Ad esempio, www.company.com/pcs/fixes/software È una destinazione diversa da www.company.com/mainframe/fixes/software. Le regole devono essere definite sull'account per questa possibilità e non prevedere troppi scenari contemporaneamente. Ad esempio, il test "uri=*/software/* " in questo caso contiene troppi caratteri jolly e comporterebbe una ricerca troppo vasta. Delle regole alternative potrebbero essere strutturate nel seguente modo:
Una ricerca combinata può restringere il campo di ricerca:
>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)"
>>rule uses cluster 1:80:pcs server1
In caso non sia possibile utilizzare le combinazioni disponibili, diventa importante l'ordine:
>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*"
>>rule uses cluster1:80:pc1 server2
La seconda regola interviene quando "pcs" compare nelle posizioni successive di directory anziché nella prima.
>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*"
>>rule uses cluster1:80:pc2 server3
In quasi tutti i casi, è possibile completare le regole con una regola sempre true predefinita da applicare in tutti i casi in cui non possono essere applicate le altre regole. Questa potrebbe essere anche un server del tipo "Spiacenti, impossibile al momento collegarsi al sito, provare di nuovo" per scenari in cui tutti gli altri server non riescono a soddisfare la richiesta di questo client.
>>rule add cluster1:80:sorry type true priority 100
>>rule uses cluster1:80:sorry server5