For distributed platformsFor z/OS platforms[17.0.0.1 and later]

Configuración de reglas de direccionamiento para el direccionamiento dinámico de Liberty

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

  1. 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>
  2. Añada elementos <routingRule> como hijos del elemento <routingRules>.
    1. 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.
    2. 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.
  3. 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.
      1. Añada el elemento <permitAction> a un elemento <routingRule>.
      2. 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.
      3. 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.

      4. Añada uno o más elementos <endpoint> a cada elemento <loadBalanceEndPoints>.
      5. 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.
      1. Añada el elemento <redirectAction> a un elemento <routingRule>.
      2. 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.
      1. Añada el elemento <rejectAction> a un elemento <routingRule>.
      2. 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.


Icono que indica el tipo de tema Tema de tarea

Nombre de archivo: twlp_wve_routing_rules.html