Con la característica de reglas de direccionamiento de direccionamiento dinámico puede seleccionar solicitudes para un comportamiento de direccionamiento especial basado en la información de solicitud.
Antes de empezar
Habilite el direccionamiento dinámico en un controlador colectivo. Complete los pasos de Configuración del direccionamiento dinámico para los colectivos de Liberty.
Consejo: Para utilizar reglas de direccionamiento para direccionar a varios colectivos, cada colectivo debe tener un nombre distinto. Utilice la opción
--collectiveName cuando ejecute el mandato
collective create para dar nombre a un colectivo. Si el colectivo ya se ha creado, puede proporcionar un nombre lógico para el colectivo con la propiedad
connectorClusterName del elemento XML
<dynamicRouting>. Si se especifica la propiedad
connectorClusterName, el valor tiene prioridad sobre el
collectiveName especificado con la opción
--collectiveName. Consulte
Configuración del direccionamiento dinámico para varios colectivos de Liberty.
Acerca de esta tarea
De forma predeterminada, el direccionamiento dinámico equilibra la carga de la solicitud entre todos los servidores que pueden manejar la solicitud. Configure reglas de direccionamiento para alternar temporalmente el comportamiento predeterminado de forma que las reglas de direccionamiento puedan direccionar solicitudes a recursos de servidor específicos, redireccionar solicitudes o rechazar solicitudes.
Nota: Todos los controladores colectivos en el colectivo deben proporcionar el mismo conjunto de reglas de direccionamiento mediante el servicio de direccionamiento dinámico. Añada un archivo
.xml que contenga las reglas de direccionamiento al directorio
configDropins/defaults de uno de los controladores para garantizar que todos los controladores utilizan las mismas reglas de direccionamiento. Para obtener más
información, consulte
Compartición automática de configuraciones entre réplicas.
Procedimiento
- Añada el elemento <routingRules> como hijo del elemento
<dynamicRouting> en el archivo server.xml del controlador.
Especifique el atributo webServers del elemento
<routingRules>. Cada elemento <routingRules> puede definir el conjunto aplicable de servidores web donde se publican las reglas. Cuando un servidor web se conecta al servicio DynamicRouting, el servicio proporciona reglas a ese servidor web. Si no especifica ningún servidor web, el servicio proporciona reglas a todos los servidores que se conectan. Si especifica más de un servidor web, utilice la coma (,) como delimitador. Las reglas especificadas con un valor de atributo webServers de * se proporcionan a todos los servidores web.
Consulte el ejemplo siguiente:
<dynamicRouting>
<routingRules webServers="webserver1,webserver2">
...
</routingRules>
</dynamicRouting>
Especifique el atributo
overrideAffinity del elemento
<routingRules>. De forma predeterminada, una solicitud que tiene afinidad con un servidor determinado se envía a ese servidor, incluso si la solicitud coincide con una regla de direccionamiento que no contiene el servidor de afinidad como destino. Si la propiedad
overrideAffinity se establece en
true, la selección de un destino que está en una regla coincidente tiene prioridad sobre la selección del servidor de afinidad. Si el servidor de afinidad satisface la regla coincidente, se elige el servidor de afinidad, incluso si el servidor de afinidad está en un conjunto de puntos finales de migración tras error. La propiedad
overrideAffinity se aplica a todas las reglas de direccionamiento y no se puede establecer para reglas individuales.
<dynamicRouting>
<routingRules webServers="webserver1"
overrideAffinity=”true”>
...
</routingRules>
</dynamicRouting>
- Añada elementos <routingRule> como hijos del elemento
<routingRules>.
- Especifique un atributo order para la regla de direccionamiento y establézcalo en un entero.
El atributo order es necesario. Las reglas se evalúan según el número de orden, de menor a mayor. Si se asigna a más de una regla el mismo atributo order, se publica la primera regla que se encuentra y todas las demás reglas con el mismo atributo de orden se descartan. Se recomienda dejar huecos entre los números de orden de las reglas para proporcionar espacio para futuras reglas.
- Especifique un atributo matchExpression para la regla de direccionamiento. Establézcalo en una expresión que pueda encontrar solicitudes entrantes coincidentes. Las expresiones de coincidencia combinan un conjunto de operandos fijos con operadores. Puede combinar conjuntos de operandos y operadores utilizando los operadores
AND y OR.
<dynamicRouting>
<routingRules webServers="webserver1,webserver2">
<routingRule order="100" matchExpression="URI LIKE'/myapp%'">
...
</routingRule>
</routingRules>
</dynamicRouting>
Tabla 1. matchExpression operands. Incluye un operando en una definición matchExpression.Operando |
Sintaxis |
Descripción |
IPV4 de cliente |
clientipv4 |
La dirección IP del cliente que utiliza el tipo de dirección de cuatro elementos con puntos del Protocolo Internet versión 4 (IPv4) n.n.n.n. |
IPV6 de cliente |
clientipv6 |
El tipo de dirección de 128 bits x:x:x:x:x:x:x:x
del Protocolo Internet versión 6 (IPv6) que sigue la RFC (Request for Comments) 1924 del
sistema cliente. |
Nombre de cookie |
cookie$nombre |
Un nombre de cookie. Por ejemplo, la expresión
cookie$My_Cookie_Name='My_Cookie_Value' prueba una solicitud para ver si contiene una
cookie denominada My_Cookie_Name con un valor de My_Cookie_Value. Para comprobar si existe o no un cookie determinado, utilice una de las expresiones siguientes:
cookie$MyCookieName IS NOT NULL
cookie$MyCookieName IS NULL
|
Nombre de cabecera |
header$nombre |
Nombre de cabecera y el valor. Por ejemplo, la expresión
header$Host='localhost' prueba una solicitud para ver si contiene
una cabecera de host HTTP con un valor de locahost. Para probar la presencia o ausencia de la cabecera de host, utilice una de las siguientes expresiones:
header$Host IS NOT NULL
header$Host IS NULL
|
Porcentaje |
percentage$val |
El operando de porcentaje se evalúa en true algún porcentaje de tiempo. Por ejemplo, percentage$50 se evalúa en
true el 50% del tiempo aproximadamente.
|
Parámetro de consulta |
queryparm$nombre |
Un nombre y valor de parámetro de consulta. Por ejemplo, la expresión
queryparm$timezone='EST' prueba una solicitud para ver si la solicitud
contiene un parámetro de consulta HTTP denominado timezone con un valor de EST. Para probar si existe o no un parámetro de consulta, utilice uno de los formatos siguientes:
queryparm$timezone IS NOT NULL
queryparm$timezone IS NULL
|
URI |
uri |
Identificador uniforme de recursos |
Host virtual |
virtualhost |
Destino de host virtual de la solicitud |
Puerto virtual |
numérico |
Destino de puerto virtual de la solicitud |
Tabla 2. Operadores matchExpression. Incluir un operador en una definición matchExpression según se requiera.Operador |
Sintaxis |
Descripción |
Es igual |
= |
El operador de igualdad expresa una coincidencia de mayúsculas y minúsculas. |
Es igual a ignorar mayúsculas y minúsculas |
EQUALSIGNORECASE |
Idéntico a 'String = String', con la excepción de que no se tienen en cuenta las mayúsculas y minúsculas de las series. Por ejemplo, 'ABC' EQUALSIGNORECASE 'abc' se evalúa como true y ('ABC' = 'abc') se evalúa como
false. |
IN |
IN |
Expresa un operando con varios valores en una sola expresión. Por ejemplo, si, para un operando denominado port, desea expresar que el valor port puede ser cualquier entero o todos los enteros como, por ejemplo, 9080, 9090 y 9091, el fragmento de expresión es port IN
(9080,9090,9091). El modo como se expresan los valores dentro de los paréntesis depende del tipo de datos. Por ejemplo, si port es un entero, la sintaxis correcta es el valor sin comillas. Si port es una serie, la sintaxis correcta es port IN
('9080','9090','9091').
|
No es nulo |
IS NOT NULL |
Se evalúa como true si existe el operando especificado. |
Es nulo |
IS NULL |
Se evalúa como true si el operando especificado no existe. |
Similar a |
LIKE |
Expresa la coincidencia de patrón para los valores de operando de la serie. El valor debe contener el signo de porcentaje de carácter comodín (%) en la posición donde se inicia la coincidencia de patrón. Por
ejemplo:- La expresión host LIKE %blanca coincide con la palabra blanca o con cualquier otra palabra que finalice con blanca.
- La expresión host LIKE blanca% coincide con la palabra blanca o con cualquier otra palabra que empiece con blanca.
- La expresión host LIKE %blanca% coincide con la palabra blanca o cualquier otra palabra que contenga blanca.
|
Igual a ignorar mayúsculas y minúsculas |
LIKEIGNORECASE |
Idéntico a 'string LIKE string', con la excepción de que no se tienen en cuenta las mayúsculas y minúsculas de las series. |
Como en |
LIKEIN |
Evalúa si una serie existe en una lista de series. Por ejemplo, string likein
(string1%, string2%, string3%, etc.) se evalúa como true si
string coincide con una o varias de las series en los paréntesis. En este ejemplo, los paréntesis contienen tres valores string. |
- Especifique un tipo de acción para una regla de direccionamiento.
Los tres tipos de acción posibles son permitAction,
redirectAction o rejectAction. Especifique sólo uno de los tres tipos de acción para cada regla de direccionamiento.
- Especifique el tipo de acción permitAction para direccionar las solicitudes a los puntos finales identificados.
- Añada el elemento <permitAction> a un elemento <routingRule>.
- Opcionalmente, añada el atributo allowMaintenanceModeServers al elemento
<permitAction> para especificar si las solicitudes que coinciden con las reglas se envían a los servidores en modalidad de mantenimiento. El valor predeterminado de este atributo es false. Cuando este atributo se establece en true, las solicitudes que coinciden con esta regla se pueden enviar a los servidores que están en modalidad de mantenimiento.
- Añada uno o más elementos <loadBalanceEndPoints> al elemento
<permitAction>.
Si un elemento <permitAction> tiene más de un elemento <loadBalanceEndPoints>, el primer elemento
<loadBalanceEndPoints> actúa como el conjunto primario de destinos. Todos los elementos <loadBalanceEndPoints> subsiguientes actúan como destinos de migración tras error. El orden en el que se definen los elementos <loadBalanceEndPoints> determina la prioridad de la migración tras error.
- Añada uno o más elementos <endpoint> a cada elemento
<loadBalanceEndPoints>.
- Añada un atributo destination a cada elemento <endpoint>.
Establezca los atributos destination en un tipo de servidor o un tipo de clúster.
Para especificar un punto final de tipo servidor, especifique server= seguido por una especificación de servidor de cuatro partes, con las partes delimitadas por una coma:
<endpoint destination="server=nombre_colectivo,nombre_host,wlp.user.dir,nombre_servidor"/>
- nombre_colectivo es el nombre del colectivo donde el servidor es un miembro.
- nombre_host es la dirección del host.
- wlp.user.dir es el directorio de usuario de Liberty en el sistema host donde está definido el servidor. Posiblemente puede utilizar aquí la variable ${wlp.user.dir},
pero es posible que no sea adecuado. Cuando se evalúa este server.xml, el valor de ${wlp.user.dir} es el directorio donde está definido el servidor de controlador. Es posible que este no sea el mismo directorio donde está definido el servidor miembro.
- nombre_servidor es el nombre de servidor.
Para especificar un punto final de tipo clúster, especifique cluster= seguido por una especificación de servidor de dos partes, con las partes delimitadas por una coma:
<endpoint destination="cluster=nombre_colectivo,nombre_clúster"/>
- nombre_colectivo es el nombre del colectivo donde está definido el clúster.
- nombre_clúster es el nombre de clúster.
Todas las partes de una especificación de destino de servidor o clúster pueden utilizar el carácter comodín
(*) para que coincida con cualquier serie. Para utilizar reglas de direccionamiento para direccionar a varios colectivos, cada colectivo debe tener un nombre distinto. Si se especifica el atributo connectorClusterName
del elemento <dynamicRouting>, el nombre de colectivo es el valor del atributo connectorClusterName. Si no se especifica el atributo connectorClusterName de <dynamicRouting>, el nombre de colectivo es el valor utilizado para la opción --collectiveName al ejecutar el mandato collective create. Si no se especifica el atributo
connectorClusterName ni se utiliza la opción
--collectiveName, el nombre de colectivo es
defaultCollective.
El ejemplo siguiente muestra un elemento <permitAction> con un punto final de tipo servidor:
<dynamicRouting maxRetries="5" retryInterval="10000">
<routingRules webServers="myWebServer">
<routingRule order="100" matchExpression="URI LIKE '/myapp%'">
<permitAction>
<loadBalanceEndPoints>
<endpoint destination="server=collective1,myhost,/opt/IBM/liberty/wlp/usr,member1"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
</routingRules>
</dynamicRouting>
- Especifique el tipo de acción redirectAction para direccionar una solicitud a otra ubicación.
- Añada el elemento <redirectAction> a un elemento <routingRule>.
- Añada un atributo location al elemento <redirectAction>. Establezca el atributo location en el nuevo destino de la solicitud.
El ejemplo siguiente muestra un elemento <redirectAction>:
<dynamicRouting maxRetries="5" retryInterval="10000">
<routingRules webServers="myWebServer">
<routingRule order="200" matchExpression="URI LIKE '/myapp%'">
<redirectAction location="http://some.other.destination" />
</routingRule>
</routingRules>
</dynamicRouting>
- Especifique el tipo de acción rejectAction para rechazar una solicitud con un código de respuesta específico.
- Añada el elemento <rejectAction> a un elemento <routingRule>.
- Añada un atributo code al elemento <rejectAction>. Establezca el atributo code en el código de respuesta HTTP que se utilizará cuando la solicitud coincida con la regla. El código debe ser un código de error al que el servidor web dé soporte.
El ejemplo siguiente muestra un elemento <rejectAction>:
<dynamicRouting maxRetries="5" retryInterval="10000">
<routingRules webServers="myWebServer">
<routingRule order="300" matchExpression="URI LIKE '/myapp%'">
<rejectAction code="503" />
</routingRule>
</routingRules>
</dynamicRouting>
Resultados
Después de que se han definido las reglas, cuando un servidor web se conecta al servicio de direccionamiento dinámico, se suministran las reglas asociadas con ese servidor web y las reglas asociadas con todos los servidores web. El servidor web coincide con las solicitudes según las expresiones de coincidencia que se han encontrado en las reglas. Las expresiones se evalúan según el orden de las reglas, de menor a mayor. Se utiliza la primera regla con una expresión de coincidencia. La acción asociada con la regla determina cómo se manejará la solicitud. Si no hay ninguna regla coincidente, la carga de la solicitud se equilibrará entre todos los servidores que pueden manejar la solicitud.
De forma predeterminada, cuando una solicitud tiene afinidad de sesión, la selección de servidor se basa en la afinidad. Si se encuentra un servidor de afinidad, se elige ese servidor y las reglas de direccionamiento no se evalúan. Para habilitar las reglas de direccionamiento para alterar temporalmente la selección de afinidad, se puede añadir el atributo overrideAffinity al elemento
<routingRules> del archivo server.xml.
Ejemplo
El ejemplo siguiente combina varias reglas:
<dynamicRouting>
<routingRules webServers="myWebServer">
<routingRule order="100" matchExpression="URI LIKE '/myapp%'">
<permitAction>
<loadBalanceEndPoints>
<endpoint destination="server=collective1,*,*,member1"/>
</loadBalanceEndPoints>
<loadBalanceEndPoints>
<endpoint destination="server=collective2,*,*,member1"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
<routingRule order="200" matchExpression="uri like '/AppX%' AND queryparm$test = 'true'">
<permitAction allowMaintenanceModeServers="true">
<loadBalanceEndPoints>
<endpoint destination="cluster=collective1,clusterB"/>
<endpoint destination="cluster=collective2,clusterB"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
<routingRule order="300" matchExpression=" uri like '/AppX%' ">
<permitAction>
<loadBalanceEndPoints>
<endpoint destination="cluster=collective1,clusterA"/>
<endpoint destination="cluster=collective2,clusterA"/>
</loadBalanceEndPoints>
</permitAction>
</routingRule>
<routingRule order="400" matchExpression="URI LIKE '/myoldapp'">
<redirectAction location="http://mysite/mynewapp" />
</routingRule>
<routingRule order="500" matchExpression="URI LIKE '/myveryoldapp'">
<rejectAction code="503" />
</routingRule>
</routingRules>
</dynamicRouting>
La regla de coincidencia con -order 100 limita los destinos donde las solicitudes de
/AppX se direccionan a dos clústeres determinados entre dos colectivos.
La regla de direccionamiento con –order 200 muestra cómo habilitar la migración tras error de un conjunto de puntos finales a otro. La regla 200 direcciona todas las solicitudes que coinciden con la expresión a los servidores que pueden manejar la solicitud en collective1. Si ninguno de los servidores que pueden manejar la solicitud en collective1 está disponible, se eligen los servidores que pueden manejar la solicitud en
collective2 para las solicitudes que coinciden con la expresión de regla.
La regla de direccionamiento con –order 300 muestra un ejemplo de solicitudes de prueba de direccionamiento a un servidor que está en modalidad de mantenimiento. Si se añade test=true como un parámetro de consulta,
estas solicitudes se envían a server1 en collective1, incluso si ese servidor está en modalidad de mantenimiento.
La regla de direccionamiento con –order 400 muestra un ejemplo de una regla de direccionamiento. La regla de direccionamiento con –order 500 muestra un ejemplo de una regla de rechazo.