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.
Puede especificar protocolos
SIP o en los mandatos.
addRoutingRule
El mandato addRoutingRule añade una regla de política de direccionamiento.
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]](../images/v611x.gif)
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
- Utilizando Jacl:
$AdminTask addRoutingRule {-interactive}
- Utilizando serie de Jython:
AdminTask.addRoutingRule ('[-interactive]')
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
- Utilizando Jacl:
$AdminTask changeRoutingDefaultRulesAction {-interactive}
- Utilizando serie de Jython:
AdminTask.changeRoutingDefaultRulesAction ('[-interactive]')
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:
- Utilizando Jacl:
$AdminTask changeRoutingRuleAction {-odrname odr -nodename node1 -protocol SIP -priority 0 -multiclusterAction Failover -routingLocations cluster=*/*}
- Utilizando serie de Jython:
AdminTask.changeRoutingRuleAction('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -multiclusterAction WRR -routingLocations "cluster=myCell/*"]')
Ejemplo de utilización
de la modalidad interactiva
- Utilizando Jacl:
$AdminTask changeRoutingRuleAction {-interactive}
- Utilizando serie de Jython:
AdminTask.changeRoutingRuleAction ('[-interactive]')
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:
- Utilizando Jacl:
$AdminTask changeRoutingRuleExpression {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Utilizando serie de Jython:
AdminTask.changeRoutingRuleExpression('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "request.method = \'INVITE\'"]')
Ejemplo de utilización
de la modalidad interactiva
- Utilizando Jacl:
$AdminTask changeRoutingRuleExpression {-interactive}
- Utilizando serie de Jython:
AdminTask.changeRoutingRuleExpression ('[-interactive]')
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:
- Utilizando Jacl:
$AdminTask changeRoutingRulePriority {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Utilizando serie de Jython:
AdminTask.changeRoutingRulePriority('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "request.method = \'INVITE\'"]')
Ejemplo de utilización
de la modalidad interactiva
- Utilizando Jacl:
$AdminTask changeRoutingRulePriority {-interactive}
- Utilizando serie de Jython:
AdminTask.changeRoutingRulePriority ('[-interactive]')
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:
- Utilizando Jacl:
$AdminTask createRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Utilizando serie de Jython:
AdminTask.createRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Ejemplo de utilización
de la modalidad interactiva
- Utilizando Jacl:
$AdminTask createRoutingRules {-interactive}
- Utilizando serie de Jython:
AdminTask.createRoutingRules ('[-interactive]')
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:
- Utilizando Jacl:
$AdminTask listRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Utilizando serie de Jython:
AdminTask.listRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Ejemplo de utilización
de la modalidad interactiva
- Utilizando Jacl:
$AdminTask listRoutingRules {-interactive}
- Utilizando serie de Jython:
AdminTask.listRoutingRules ('[-interactive]')
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:
- Utilizando Jacl:
$AdminTask removeRoutingRule {-odrname odr -nodename node1 -protocol SIP -expression "request.method = 'getOperation'"}
- Utilizando serie de Jython:
AdminTask.removeRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -expression "request.method = \'INVITE\'"]')
Ejemplo de utilización
de la modalidad interactiva
- Utilizando Jacl:
$AdminTask removeRoutingRule {-interactive}
- Utilizando serie de Jython:
AdminTask.removeRoutingRule ('[-interactive]')