En este apéndice se describe cómo utilizar la sintaxis de la norma de contenido (patrón) para el componente CBR y el método de reenvío CBR del componente Dispatcher, junto con los escenarios y ejemplos de su uso.
Aplicable sólo si se ha seleccionado "contenido" para el tipo de norma.
Entre la sintaxis de patrón que desea utilizar, con las siguientes restricciones
Las palabras claves reservadas siempre van seguidas de un signo igual "=".
Un valor con destino http://www.empresa.com/path/webpage.htm podría mostrar los valores siguientes:
Method=GET URI=/path/webpage.htm Version=HTTP/1.1 Host=www.empresa.com Connection=Keep-Alive Referer=http://www.empresa.com/path/parentwebpage.htm
Por ejemplo, el siguiente mandato sólo es válido cuando se utiliza el indicador cbrcontrol>> o desde un archivo de configuración:
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
Cuando se utilizan caracteres especiales, para que este mismo mandato funcione en el indicador del sistema operativo, debe colocar el mandato completo entre comillas:
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*"
Si no se utilizan las comillas, alguna parte del patrón puede truncarse cuando la norma se guarda en CBR.
A continuación se muestra una recopilación de posibles casos y ejemplos para el uso de sintaxis de patrón
Caso de ejemplo 1:
La configuración de un nombre de clúster incluye un conjunto de servidores Web para el contenido HTML estándar, otro conjunto para servidores Web con WebSphere Application Server para peticiones de servlet, otro conjunto de servidores Lotus Notes para archivos NSF, etc. Para distinguir entre estas páginas solicitadas es necesario tener acceso al cliente. También es necesario enviarlas a los servidores adecuados. Las normas de coincidencia de patrones de contenido proporcionan la separación necesaria para llevar a cabo estas tareas. Para que la separación de las peticiones necesaria se produzca automáticamente, se configura una serie de normas. Por ejemplo, los siguientes mandatos realizan las tres separaciones antes mencionadas:
>>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
Si una petición para un archivo NSF llega a Load Balancer, primero la examina la norma de servlets, pero no coincide. A continuación, la petición la examina la norma de notes y devuelve una coincidencia. La carga del cliente está equilibrada entre server3 y server4.
Caso de ejemplo 2:
Otro ejemplo común es cuando el sitio Web principal controla varios grupos internos distintos. Por ejemplo, www.empresa.com/software incluye un conjunto de servidores y un contenido distinto de la división www.empresa.com/hardware. Puesto que las peticiones están basadas en el clúster de www.empresa.com raíz, las normas de contenido tienen que encontrar las diferencias de URI y completar el equilibrio de carga. La norma del caso de ejemplo se parece a la siguiente:
>>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
Caso de ejemplo 3:
Determinadas combinaciones son susceptibles al orden en el que se realiza la búsqueda en las normas. Por ejemplo, en el caso de ejemplo 2, los clientes se separaron en función de un directorio de su vía de acceso de peticiones; sin embargo, el directorio de destino puede aparecer en varios niveles de la vía de acceso e indicar cosas distintas dependiendo del lugar en que se encuentren. Por ejemplo, www.empresa.com/pcs/fixes/software es un destino distinto de www.empresa.com/mainframe/fixes/software. Las normas deben definirse de forma que tengan prevista esta posibilidad y no identifique demasiados casos a la vez. Por ejemplo, la prueba "uri=*/software/*" es una búsqueda con comodín demasiado amplia en este caso. Pueden estructurarse normas alternativas de la siguiente forma:
Una búsqueda de combinación puede limitarla:
>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)" >>rule uses cluster 1:80:pcs server1
En los casos en los que no haya combinaciones, el orden pasa a ser importante:
>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*" >>rule uses cluster1:80:pc1 server2
La segunda norma detecta cuando "pcs" aparece en lugares de directorios posteriores en lugar del primero.
>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*" >>rule uses cluster1:80:pc2 server3
En casi cada caso, desea completar las normas con una norma siempre cierta por omisión para identificar todo lo que no puedan detectar otras normas. Esto también puede ser un servidor "Lo sentimos, el sitio está inactivo actualmente, inténtelo más adelante" para los casos en los que los demás servidores no pueden aceptar la petición de este cliente.
>>rule add cluster1:80:sorry type true priority 100 >>rule uses cluster1:80:sorry server5