WebSphere Virtual Enterprise, Version 6.1.1
             Sistemas operativos: AIX, HP-UX, Linux, Solaris, Windows,


Reglas para las tareas administrativas de política de direccionamiento de ODR

Puede utilizar tareas administrativas para configurar reglas HTTP o Session Initiation Protocol (SIP) para la política de direccionamiento del direccionador On Demand (ODR).

Las siguientes reglas son la forma preferida de configurar las políticas de direccionamiento, aunque hay otra opción que es utilizar la propiedad personalizada de propiedad de direccionamiento de varios clústeres (MCRP). Consulte el tema de propiedades personalizadas que se proporciona en los enlaces relacionados al final de este tema. La ventaja de utilizar las siguientes reglas es que se puede utilizar una expresión para determinar a qué solicitudes afecta la política, mientras que las propiedades personalizadas de MCRP sólo permiten el filtrado por aplicación o un módulo web de una aplicación. La otra ventaja de estas reglas es que puede seleccionar el destino (routingLocations) por clúster, servidor o módulo web, en lugar de sólo clúster.

addRoutingRule

El mandato addRoutingRule añade una regla de política de direccionamiento.
[Version 6.1.1 and later] Nota: Si tiene una edición de aplicaciones existente con una política de direccionamiento definida de varios clústeres e instala una nueva edición, debe crear una nueva política de direccionamiento de varios clústeres para la nueva edición.
Parámetros necesarios
  • -protocol: especifica el nombre del protocolo que se va a asociar con una regla. (String, necesario)
  • -priority: valor entero positivo que representa la prioridad de una regla. Cero es la prioridad máxima. (String, necesario)
  • -expression: especifica la expresión de regla La expresión se debe especificar entre comillas. Para obtener más información sobre la especificación de parámetros para la expresión de regla, consulte el tema de operandos SIP y el tema de operandos HTTP.(String, necesario)
  • -actionType: especifica el tipo de acción que se va a asociar con una regla. (String, necesario)
    La siguiente lista contiene los tipos de acciones que se van a asociar a reglas HTTP:
    • permit: permitir direccionamiento a
    • reject: rechazar direccionamiento con código de retorno
    • permitsticky: permitir direccionamiento con afinidad a
    • permitMM: permitir direccionamiento a servidores en modalidad de mantenimiento
    • permitstickyMM: permitir direccionamiento con afinidad a servidores en modalidad de mantenimiento
    La siguiente lista contiene los tipos de acciones que se van a asociar a reglas SIP:
    • permit: permitir direccionamiento a
    • reject: rechazar direccionamiento con código de retorno
Parámetros opcionales
  • -odrname: especifica el nombre del ODR al que se aplica la clase de trabajo de política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR.
  • -nodename: especifica el nombre del nodo en el que reside el ODR. El parámetro -nodename sólo es necesario si modifica un ODR.
  • -clustername : especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
  • -multiclusterAction: especifica el método para direccionar solicitudes si coinciden varios clústeres de ubicación de direccionamiento. El parámetro -multiclusterAction se aplica a todos los actionTypes permit y sólo es necesario si actionType es igual a permit, permitsticky, permitMM o permitstickyMM.
    • Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
    • WRR: equilibrio de carga de peso circular ponderado. Para la retransmisión de UDP, mantener la afinidad.
    • WLOR: solicitud pendiente mínima ponderada.
      Procedimiento recomendado: La recomendación es utilizar el valor WLOR en lugar del valor WRR.bprac
    La siguiente lista contiene los valores posibles para las reglas SIP:
    • Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
    • WRR: equilibrio de carga de peso circular ponderado. Para la retransmisión de UDP, mantener la afinidad.
    • Error: si hay varios clústeres entre los que seleccionar, se genera un error. Espera que haya un único clúster.
  • -routingLocations: especifica una lista de ubicaciones de destino para direccionar solicitudes. El parámetro -routingLocations sólo es necesario si actionType es igual a cualquiera de los actionTypes permit.
    Cada operando de la lista sigue uno de tres mandatos y puede incluir un valor comodín *, que coincide con cualquier valor:
    • cluster=cellName/clusterName
    • server=cellName/nodeName/serverName
    • module=cellName/applicationName/applicationVersion/moduleName
    Con sólo las reglas de direccionamiento SIP puede definir de forma alternativa clústeres de destino a través de una expresión de reglas. Los operadores válidos son AND, OR, NOT y la agrupación de paréntesis. Formatee de acuerdo con la siguiente lista:
    • cluster=cellName/clusterName
    • server=cellName/nodeName/serverName
    • modules=cellName/applicationName/applicationVersion/moduleName
    • server maintenance mode=true o false
    • node maintenance mode=true o false
    • protocol=PROTO_VALOR:
      PROTO_SIP = sip
      SIP sobre TCP
      PROTO_SIPS = sips
      SIP sobre SSL y TCP
      PROTO_SIPU = sipu
      SIP sobre UDP
      PROTO_SIPX = sipx
      SIP sobre XMEM
    Nota: Para las aplicaciones que no tienen el valor applicationVersion, deje el valor applicationVersion en blanco: module=cellName/application//moduleName.
  • -errorcode : código de error entero para rechazar una solicitud. El parámetro -errorcode sólo es necesario si actionType es igual a reject.

Ejemplo de utilización de la modalidad por lotes:

El siguiente ejemplo muestra una sustitución por anomalía de todas las aplicaciones de una célula en un clúster de servidores genéricos que apunta a otra célula:
  • Utilizando Jacl:
    $AdminTask addRoutingRule {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation'" -actionType permit -multiclusterAction Failover -routingLocations cluster=*/*}
  • Utilizando serie de Jython:
    AdminTask.addRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "request.method = \'INVITE\'" -actionType permit -multiclusterAction Failover -routingLocations "module=*/*/*/*,cluster=myCell/myFailoverGSCThatPointsToAnotherCell"]')
[Version 6.1.1 and later] El ejemplo siguiente crea una política de direccionamiento de varios clústeres para una nueva edición de aplicaciones:
  • Utilizando Jacl:
    $AdminTask addRoutingRule {-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN {'/contextRoot','/contextRoot/%'}" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName}
  • Utilizando serie de Jython:
    AdminTask.addRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN ('/contextRoot','/contextRoot/%')" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName]')

Ejemplo de utilización de la modalidad interactiva

changeRoutingDefaultRulesAction

El mandato changeRoutingDefaultRulesAction cambia la acción predeterminada de la política de direccionamiento para una regla.

Parámetros necesarios
  • -protocol: especifica el nombre del protocolo que se va a asociar con una regla. (String, necesario)
Parámetros opcionales
  • -odrname: especifica el nombre del ODR al que se aplica la clase de trabajo de política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR.
  • -nodename: especifica el nombre del nodo en el que reside el ODR. El parámetro -nodename sólo es necesario si modifica un ODR.
  • -clustername : especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
  • -multiclusterAction: especifica el método para direccionar solicitudes si coinciden varios clústeres de ubicación de direccionamiento. El parámetro -multiclusterAction se aplica a todos los actionTypes permit y sólo es necesario si actionType es igual a permit, permitsticky, permitMM o permitstickyMM.
    • Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
    • WRR: equilibrio de carga de peso circular ponderado. Para la retransmisión de UDP, mantener la afinidad.
    • WLOR: solicitud pendiente mínima ponderada.
      Procedimiento recomendado: La recomendación es utilizar el valor WLOR en lugar del valor WRR.bprac
    La siguiente lista contiene los valores posibles para las reglas SIP:
    • Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
    • WRR: equilibrio de carga de peso circular ponderado. Para la retransmisión de UDP, mantener la afinidad.
    • Error: si hay varios clústeres entre los que seleccionar, se genera un error. Espera que haya un único clúster.
  • -routingLocations: especifica una lista de ubicaciones de destino para direccionar solicitudes. El parámetro -routingLocations sólo es necesario si actionType es igual a cualquiera de los actionTypes permit.
    Cada operando de la lista sigue uno de tres mandatos y puede incluir un valor comodín *, que coincide con cualquier valor:
    • cluster=cellName/clusterName
    • server=cellName/nodeName/serverName
    • module=cellName/applicationName/applicationVersion/moduleName
    Con sólo las reglas de direccionamiento SIP puede definir de forma alternativa clústeres de destino a través de una expresión de reglas. Los operadores válidos son AND, OR, NOT y la agrupación de paréntesis. Formatee de acuerdo con la siguiente lista:
    • cluster=cellName/clusterName
    • server=cellName/nodeName/serverName
    • modules=cellName/applicationName/applicationVersion/moduleName
    • server maintenance mode=true o false
    • node maintenance mode=true o false
    • protocol=PROTO_VALOR:
      PROTO_SIP = sip
      SIP sobre TCP
      PROTO_SIPS = sips
      SIP sobre SSL y TCP
      PROTO_SIPU = sipu
      SIP sobre UDP
      PROTO_SIPX = sipx
      SIP sobre XMEM
    Nota: Para las aplicaciones que no tienen el valor applicationVersion, deje el valor applicationVersion en blanco: module=cellName/application//moduleName.
  • -errorcode : código de error entero para rechazar una solicitud. El parámetro -errorcode sólo es necesario si actionType es igual a reject.

Ejemplo de utilización de la modalidad por lotes:

Ejemplo de utilización de la modalidad interactiva

changeRoutingRuleAction

El mandato changeRoutingRuleAction cambia una acción de política de direccionamiento para una regla.

Parámetros necesarios
  • -protocol: especifica el nombre del protocolo que se va a asociar con una regla. (String, necesario)
  • -priority: valor entero positivo que representa la prioridad de una regla. Cero es la prioridad máxima. (String, necesario)
Parámetros opcionales
  • -odrname: especifica el nombre del ODR al que se aplica la clase de trabajo de política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR.
  • -nodename: especifica el nombre del nodo en el que reside el ODR. El parámetro -nodename sólo es necesario si modifica un ODR.
  • -clustername : especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.
  • -multiclusterAction: especifica el método para direccionar solicitudes si coinciden varios clústeres de ubicación de direccionamiento. El parámetro -multiclusterAction se aplica a todos los actionTypes permit y sólo es necesario si actionType es igual a permit, permitsticky, permitMM o permitstickyMM.
    • Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
    • WRR: equilibrio de carga de peso circular ponderado. Para la retransmisión de UDP, mantener la afinidad.
    • WLOR: solicitud pendiente mínima ponderada.
      Procedimiento recomendado: La recomendación es utilizar el valor WLOR en lugar del valor WRR.bprac
    La siguiente lista contiene los valores posibles para las reglas SIP:
    • Failover: buscar el primer clúster con un servidor disponible y equilibrar la carga en todo ese clúster. El orden de una lista de clústeres generada dinámicamente no se ha definido.
    • WRR: equilibrio de carga de peso circular ponderado. Para la retransmisión de UDP, mantener la afinidad.
    • Error: si hay varios clústeres entre los que seleccionar, se genera un error. Espera que haya un único clúster.
  • -routingLocations: especifica una lista de ubicaciones de destino para direccionar solicitudes. El parámetro -routingLocations sólo es necesario si actionType es igual a cualquiera de los actionTypes permit.
    Cada operando de la lista sigue uno de tres mandatos y puede incluir un valor comodín *, que coincide con cualquier valor:
    • cluster=cellName/clusterName
    • server=cellName/nodeName/serverName
    • module=cellName/applicationName/applicationVersion/moduleName
    Con sólo las reglas de direccionamiento SIP puede definir de forma alternativa clústeres de destino a través de una expresión de reglas. Los operadores válidos son AND, OR, NOT y la agrupación de paréntesis. Formatee de acuerdo con la siguiente lista:
    • cluster=cellName/clusterName
    • server=cellName/nodeName/serverName
    • modules=cellName/applicationName/applicationVersion/moduleName
    • server maintenance mode=true o false
    • node maintenance mode=true o false
    • protocol=PROTO_VALOR:
      PROTO_SIP = sip
      SIP sobre TCP
      PROTO_SIPS = sips
      SIP sobre SSL y TCP
      PROTO_SIPU = sipu
      SIP sobre UDP
      PROTO_SIPX = sipx
      SIP sobre XMEM
    Nota: Para las aplicaciones que no tienen el valor applicationVersion, deje el valor applicationVersion en blanco: module=cellName/application//moduleName.
  • -errorcode : código de error entero para rechazar una solicitud. El parámetro -errorcode sólo es necesario si actionType es igual a reject.

Ejemplo de utilización de la modalidad por lotes:

Ejemplo de utilización de la modalidad interactiva

changeRoutingRuleExpression

El mandato changeRoutingRuleExpression cambia una expresión de regla de política de direccionamiento.

Parámetros necesarios
  • -protocol: especifica el nombre del protocolo que se va a asociar con una regla. (String, necesario)
  • -priority: valor entero positivo que representa la prioridad de una regla. Cero es la prioridad máxima. (String, necesario)
  • -expression: especifica la expresión de regla La expresión se debe especificar entre comillas. Para obtener más información sobre la especificación de parámetros para la expresión de regla, consulte el tema de operandos SIP y el tema de operandos HTTP.(String, necesario)
Parámetros opcionales
  • -odrname: especifica el nombre del ODR al que se aplica la clase de trabajo de política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR.
  • -nodename: especifica el nombre del nodo en el que reside el ODR. El parámetro -nodename sólo es necesario si modifica un ODR.
  • -clustername : especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.

Ejemplo de utilización de la modalidad por lotes:

Ejemplo de utilización de la modalidad interactiva

changeRoutingRulePriority

El mandato changeRoutingRulePriority cambia una prioridad de regla de política de direccionamiento.

Parámetros necesarios
  • -protocol: especifica el nombre del protocolo que se va a asociar con una regla. (String, necesario)
  • -priority: valor entero positivo que representa la prioridad de una regla. Cero es la prioridad máxima. (String, necesario)
  • -expression: especifica la expresión de regla La expresión se debe especificar entre comillas. Para obtener más información sobre la especificación de parámetros para la expresión de regla, consulte el tema de operandos SIP y el tema de operandos HTTP.(String, necesario)
Parámetros opcionales
  • -odrname: especifica el nombre del ODR al que se aplica la clase de trabajo de política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR.
  • -nodename: especifica el nombre del nodo en el que reside el ODR. El parámetro -nodename sólo es necesario si modifica un ODR.
  • -clustername : especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.

Ejemplo de utilización de la modalidad por lotes:

Ejemplo de utilización de la modalidad interactiva

createRoutingRules

El mandato createRoutingRules crea una lista de reglas de política de direccionamiento.

Parámetros necesarios
  • -protocol: especifica el nombre del protocolo que se va a asociar con una regla. (String, necesario)
Parámetros opcionales
  • -odrname: especifica el nombre del ODR al que se aplica la clase de trabajo de política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR.
  • -nodename: especifica el nombre del nodo en el que reside el ODR. El parámetro -nodename sólo es necesario si modifica un ODR.
  • -clustername : especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.

Ejemplo de utilización de la modalidad por lotes:

Ejemplo de utilización de la modalidad interactiva

listRoutingRules

El mandato listRoutingRules suprime un clúster dinámico de la configuración.

Parámetros necesarios
  • -protocol: especifica el nombre del protocolo que se va a asociar con una regla. (String, necesario)
Parámetros opcionales
  • -odrname: especifica el nombre del ODR al que se aplica la clase de trabajo de política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR.
  • -nodename: especifica el nombre del nodo en el que reside el ODR. El parámetro -nodename sólo es necesario si modifica un ODR.
  • -clustername : especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.

Ejemplo de utilización de la modalidad por lotes:

Ejemplo de utilización de la modalidad interactiva

removeRoutingRule

El mandato removeRoutingRule elimina una regla de política de direccionamiento.

Parámetros necesarios
  • -protocol: especifica el nombre del protocolo que se va a asociar con una regla. (String, necesario)
  • -priority: valor entero positivo que representa la prioridad de una regla. Cero es la prioridad máxima. (String, necesario)
  • -expression: especifica la expresión de regla La expresión se debe especificar entre comillas. Para obtener más información sobre la especificación de parámetros para la expresión de regla, consulte el tema de operandos SIP y el tema de operandos HTTP.(String, necesario)
Parámetros opcionales
  • -odrname: especifica el nombre del ODR al que se aplica la clase de trabajo de política de direccionamiento. El parámetro -odrname sólo es necesario si modifica un ODR.
  • -nodename: especifica el nombre del nodo en el que reside el ODR. El parámetro -nodename sólo es necesario si modifica un ODR.
  • -clustername : especifica el nombre del clúster al que se aplica la regla. El parámetro -clustername sólo es necesario si modifica un clúster de ODR.

Ejemplo de utilización de la modalidad por lotes:

Ejemplo de utilización de la modalidad interactiva




Conceptos relacionados
Tipos de acción de la política de direccionamiento
Visión general de la prioridad del flujo de solicitudes
Tareas relacionadas
Configurar el direccionador On Demand para la sustitución por anomalía de varios clústeres y el direccionamiento del equilibrio de carga
Configuración de ODR
Creación de un clúster de direccionadores On Demand
Referencia relacionada
Operandos SIP
Operandos HTTP
Información relacionada
Reglas para las tareas administrativas de política de servicio de ODR
Tema de referencia    

Condiciones de uso | Comentarios

Última actualización: 22-sep-2009 09H42' EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r1m1/index.jsp?topic=/com.ibm.websphere.ops.doc/info/reference/rxdhttprules.html