É possível usar tarefas administrativas para configurar regras de HTTP ou Session Initiation Protocol (SIP) para a política de roteamento do On Demand Router (ODR).
As seguintes regras são a maneira preferida de configurar políticas de roteamento, mas o uso da propriedade customizada Multi-Cluster Routing Property (MCRP) é outra opção. Consulte o tópico de propriedades customizadas fornecido nos links relacionados no final deste tópico. A vantagem de usar as seguintes regras é que uma expressão pode ser usada para determinar quais pedidos são afetados pela política, enquanto que as propriedades customizadas MCRP apenas permitem a filtragem por um aplicativo e/ou módulo da Web do aplicativo.
A outra vantagem dessas regras é que você pode selecionar o destino (routingLocations) pelo cluster, servidor ou módulo da Web, em oposição apenas ao cluster.
É possível especificar protocolos
SIP ou HTTP nos comandos.
addRoutingRule
O comando
addRoutingRule inclui uma regra de política de roteamento.
Nota: Se
você tiver uma edição de aplicativo existente com uma política de roteamento
de múltiplos clusters definida e instalar uma nova edição, crie uma nova política de
roteamento de múltiplos clusters para a nova edição.
Parâmetros Requeridos
- -protocol: Especificar o nome do protocolo para
associar a uma regra. (Cadeia, obrigatória)
- -priority: Valor de número inteiro
positivo representando a prioridade de uma regra. Zero é a prioridade mais alta. (Cadeia,
obrigatória)
- -expression: Especificar a expressão da regra. A expressão deve ser delimitada por aspas duplas. Para obter informações adicionais sobre como especificar os parâmetros para a expressão da regra, consulte os tópicos de operandos SIP e HTTP.
(Cadeia, obrigatória)
- -actionType: Especificar o tipo de ação para associar a uma
regra. (Cadeia, obrigatória)
A seguinte lista contém os tipos de ações a serem associadas às regras de HTTP:
- permit: Permitir roteamento para
- reject: Rejeitar roteamento com código de retorno
- permitsticky: Permitir roteamento com afinidade
- permitMM: Permitir o roteamento para servidores em modo de
manutenção
- permitstickyMM: Permitir o roteamento com afinidade para
servidores em modo de manutenção
A seguinte lista contém os tipos de ações a serem associadas às regras de SIP:
- permit: Permitir roteamento para
- reject: Rejeitar roteamento com código de retorno
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a
classe de trabalho da política de roteamento se aplica. O
parâmetro -odrname é necessário somente se você modificar um
ODR.
- -nodename: Especificar o nome do nó no qual o ODR reside. O
parâmetro -nodename é necessário somente se você modificar um ODR.
- -clustername : Especificar o nome do
cluster ao qual a regra se aplica. O parâmetro -clustername
é necessário somente se você modificar um cluster do ODR.
- -multiclusterAction: Especificar o método para rotear pedidos se
múltiplos clusters de local de roteamento corresponderem.
O parâmetro -multiclusterAction se aplica a qualquer um dos actionTypes permit, e será necessário apenas se actionType for igual a permit, permitsticky, permitMM ou permitstickyMM.
- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin.
Para a retransmissão de UDP, mantenha a afinidade.
- WLOR: Weighted Least Outstanding Request.
Boas Práticas: A recomendação é usar o valor de
WLOR em vez do valor de
WRR.
bprac
A seguinte lista contém os valores possíveis para regras de SIP:
- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin.
Para a retransmissão de UDP, mantenha a afinidade.
- Erro: Se houver vários clusters, será emitido um erro, se forem selecionados. Um e apenas um cluster é esperado.
- -routingLocations: Especifica uma lista de locais de destino
para pedidos de rota. O parâmetro -routingLocations apenas será necessário, se actionType for igual a qualquer um dos actionTypes permit.
Cada operando na lista segue um dos três formatos, e pode conter um valor de curinga *, que corresponde a qualquer valor:
- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulo=cellName/applicationName/applicationVersion/moduleName
Com apenas regras de roteamento do SIP, é possível definir alternativamente os clusters de destino através de uma expressão da regra. Os operadores válidos são AND, OR, NOT e agrupamento parentético. Formato de acordo com a seguinte lista:
- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulos=cellName/applicationName/applicationVersion/moduleName
- modo de manutenção do servidor=verdadeiro ou falso
- modo de manutenção do nó=verdadeiro ou falso
- protocolo=PROTO_VALUE:
- PROTO_SIP = sip
- SIP sobre TCP
- PROTO_SIPS = sips
- SIP sobre SSL e TCP
- PROTO_SIPU = sipu
- SIP sobre UDP
- PROTO_SIPX = sipx
- SIP sobre XMEM
Nota: Para aplicativos que não possuem
valor applicationVersion, deixe em branco o valor de applicationVersion:
module=cellName/application//moduleName.
- -errorcode : Código de erro de número
inteiro para rejeitar o pedido. O parâmetro -errorcode é necessário
somente se actionType for igual a reject.
Exemplo de uso do modo em lote
O
exemplo a seguir mostra um failover de todos os aplicativos em uma célula para um
cluster de servidor genérico que aponta para outra 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 a cadeia 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)
O
exemplo a seguir cria uma política de roteamento com múltiplos clusters para uma nova
edição do aplicativo:
- 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 a cadeia Jython:
AdminTask.addRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "uri LIKEIN ('/contextRoot','/contextRoot/%')" -actionType permit -multiclusterAction Failover -routingLocations cluster=cellName/clusterName]')
Uso de exemplo do modo interativo
- Utilizando Jacl:
$AdminTask addRoutingRule {-interactive}
- Utilizando a cadeia Jython:
AdminTask.addRoutingRule ('[-interactive]')
changeRoutingDefaultRulesAction
O comando changeRoutingDefaultRulesAction altera a ação padrão da política de roteamento para uma regra.
Parâmetros Requeridos
- -protocol: Especificar o nome do protocolo para
associar a uma regra. (Cadeia, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a
classe de trabalho da política de roteamento se aplica. O
parâmetro -odrname é necessário somente se você modificar um
ODR.
- -nodename: Especificar o nome do nó no qual o ODR reside. O
parâmetro -nodename é necessário somente se você modificar um ODR.
- -clustername : Especificar o nome do
cluster ao qual a regra se aplica. O parâmetro -clustername
é necessário somente se você modificar um cluster do ODR.
- -multiclusterAction: Especificar o método para rotear pedidos se
múltiplos clusters de local de roteamento corresponderem.
O parâmetro -multiclusterAction se aplica a qualquer um dos actionTypes permit, e será necessário apenas se actionType for igual a permit, permitsticky, permitMM ou permitstickyMM.
- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin.
Para a retransmissão de UDP, mantenha a afinidade.
- WLOR: Weighted Least Outstanding Request.
Boas Práticas: A recomendação é usar o valor de
WLOR em vez do valor de
WRR.
bprac
A seguinte lista contém os valores possíveis para regras de SIP:
- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin.
Para a retransmissão de UDP, mantenha a afinidade.
- Erro: Se houver vários clusters, será emitido um erro, se forem selecionados. Um e apenas um cluster é esperado.
- -routingLocations: Especifica uma lista de locais de destino
para pedidos de rota. O parâmetro -routingLocations apenas será necessário, se actionType for igual a qualquer um dos actionTypes permit.
Cada operando na lista segue um dos três formatos, e pode conter um valor de curinga *, que corresponde a qualquer valor:
- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulo=cellName/applicationName/applicationVersion/moduleName
Com apenas regras de roteamento do SIP, é possível definir alternativamente os clusters de destino através de uma expressão da regra. Os operadores válidos são AND, OR, NOT e agrupamento parentético. Formato de acordo com a seguinte lista:
- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulos=cellName/applicationName/applicationVersion/moduleName
- modo de manutenção do servidor=verdadeiro ou falso
- modo de manutenção do nó=verdadeiro ou falso
- protocolo=PROTO_VALUE:
- PROTO_SIP = sip
- SIP sobre TCP
- PROTO_SIPS = sips
- SIP sobre SSL e TCP
- PROTO_SIPU = sipu
- SIP sobre UDP
- PROTO_SIPX = sipx
- SIP sobre XMEM
Nota: Para aplicativos que não possuem
valor applicationVersion, deixe em branco o valor de applicationVersion:
module=cellName/application//moduleName.
- -errorcode : Código de erro de número
inteiro para rejeitar o pedido. O parâmetro -errorcode é necessário
somente se actionType for igual a reject.
Exemplo de uso do modo em lote
Uso de exemplo do modo interativo
- Utilizando Jacl:
$AdminTask changeRoutingDefaultRulesAction {-interactive}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingDefaultRulesAction ('[-interactive]')
changeRoutingRuleAction
O comando changeRoutingRuleAction altera a ação da política de roteamento para uma regra.
Parâmetros Requeridos
- -protocol: Especificar o nome do protocolo para
associar a uma regra. (Cadeia, obrigatória)
- -priority: Valor de número inteiro
positivo representando a prioridade de uma regra. Zero é a prioridade mais alta. (Cadeia,
obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a
classe de trabalho da política de roteamento se aplica. O
parâmetro -odrname é necessário somente se você modificar um
ODR.
- -nodename: Especificar o nome do nó no qual o ODR reside. O
parâmetro -nodename é necessário somente se você modificar um ODR.
- -clustername : Especificar o nome do
cluster ao qual a regra se aplica. O parâmetro -clustername
é necessário somente se você modificar um cluster do ODR.
- -multiclusterAction: Especificar o método para rotear pedidos se
múltiplos clusters de local de roteamento corresponderem.
O parâmetro -multiclusterAction se aplica a qualquer um dos actionTypes permit, e será necessário apenas se actionType for igual a permit, permitsticky, permitMM ou permitstickyMM.
- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin.
Para a retransmissão de UDP, mantenha a afinidade.
- WLOR: Weighted Least Outstanding Request.
Boas Práticas: A recomendação é usar o valor de
WLOR em vez do valor de
WRR.
bprac
A seguinte lista contém os valores possíveis para regras de SIP:
- Failover: Localizar o primeiro cluster com um servidor disponível e o balanceamento de carga através do cluster. A ordem de uma lista de clusters gerada dinamicamente é indefinida.
- WRR: Balanceamento de carga Weighted Round Robin.
Para a retransmissão de UDP, mantenha a afinidade.
- Erro: Se houver vários clusters, será emitido um erro, se forem selecionados. Um e apenas um cluster é esperado.
- -routingLocations: Especifica uma lista de locais de destino
para pedidos de rota. O parâmetro -routingLocations apenas será necessário, se actionType for igual a qualquer um dos actionTypes permit.
Cada operando na lista segue um dos três formatos, e pode conter um valor de curinga *, que corresponde a qualquer valor:
- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulo=cellName/applicationName/applicationVersion/moduleName
Com apenas regras de roteamento do SIP, é possível definir alternativamente os clusters de destino através de uma expressão da regra. Os operadores válidos são AND, OR, NOT e agrupamento parentético. Formato de acordo com a seguinte lista:
- cluster=cellName/clusterName
- servidor=cellName/nodeName/serverName
- módulos=cellName/applicationName/applicationVersion/moduleName
- modo de manutenção do servidor=verdadeiro ou falso
- modo de manutenção do nó=verdadeiro ou falso
- protocolo=PROTO_VALUE:
- PROTO_SIP = sip
- SIP sobre TCP
- PROTO_SIPS = sips
- SIP sobre SSL e TCP
- PROTO_SIPU = sipu
- SIP sobre UDP
- PROTO_SIPX = sipx
- SIP sobre XMEM
Nota: Para aplicativos que não possuem
valor applicationVersion, deixe em branco o valor de applicationVersion:
module=cellName/application//moduleName.
- -errorcode : Código de erro de número
inteiro para rejeitar o pedido. O parâmetro -errorcode é necessário
somente se actionType for igual a reject.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask changeRoutingRuleAction {-odrname odr -nodename node1 -protocol SIP -priority 0 -multiclusterAction Failover -routingLocations cluster=*/*}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRuleAction('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -multiclusterAction WRR -routingLocations "cluster=myCell/*"]')
Uso de exemplo do modo interativo
- Utilizando Jacl:
$AdminTask changeRoutingRuleAction {-interactive}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRuleAction ('[-interactive]')
changeRoutingRuleExpression
O comando changeRoutingRuleExpression altera uma expressão da regra de política de roteamento.
Parâmetros Requeridos
- -protocol: Especificar o nome do protocolo para
associar a uma regra. (Cadeia, obrigatória)
- -priority: Valor de número inteiro
positivo representando a prioridade de uma regra. Zero é a prioridade mais alta. (Cadeia,
obrigatória)
- -expression: Especificar a expressão da regra. A expressão deve ser delimitada por aspas duplas. Para obter informações adicionais sobre como especificar os parâmetros para a expressão da regra, consulte os tópicos de operandos SIP e HTTP.
(Cadeia, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a
classe de trabalho da política de roteamento se aplica. O
parâmetro -odrname é necessário somente se você modificar um
ODR.
- -nodename: Especificar o nome do nó no qual o ODR reside. O
parâmetro -nodename é necessário somente se você modificar um ODR.
- -clustername : Especificar o nome do
cluster ao qual a regra se aplica. O parâmetro -clustername
é necessário somente se você modificar um cluster do ODR.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask changeRoutingRuleExpression {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRuleExpression('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "request.method = \'INVITE\'"]')
Uso de exemplo do modo interativo
- Utilizando Jacl:
$AdminTask changeRoutingRuleExpression {-interactive}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRuleExpression ('[-interactive]')
changeRoutingRulePriority
O comando changeRoutingRulePriority altera uma prioridade da regra de política de roteamento.
Parâmetros Requeridos
- -protocol: Especificar o nome do protocolo para
associar a uma regra. (Cadeia, obrigatória)
- -priority: Valor de número inteiro
positivo representando a prioridade de uma regra. Zero é a prioridade mais alta. (Cadeia,
obrigatória)
- -expression: Especificar a expressão da regra. A expressão deve ser delimitada por aspas duplas. Para obter informações adicionais sobre como especificar os parâmetros para a expressão da regra, consulte os tópicos de operandos SIP e HTTP.
(Cadeia, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a
classe de trabalho da política de roteamento se aplica. O
parâmetro -odrname é necessário somente se você modificar um
ODR.
- -nodename: Especificar o nome do nó no qual o ODR reside. O
parâmetro -nodename é necessário somente se você modificar um ODR.
- -clustername : Especificar o nome do
cluster ao qual a regra se aplica. O parâmetro -clustername
é necessário somente se você modificar um cluster do ODR.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask changeRoutingRulePriority {-odrname odr -nodename node1 -protocol SIP -priority 0 -expression "request.method = 'getOperation0'"}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRulePriority('[-odrname odr -nodename node1 -protocol HTTP -priority 0 -expression "request.method = \'INVITE\'"]')
Uso de exemplo do modo interativo
- Utilizando Jacl:
$AdminTask changeRoutingRulePriority {-interactive}
- Utilizando a cadeia Jython:
AdminTask.changeRoutingRulePriority ('[-interactive]')
createRoutingRules
O comando createRoutingRules cria uma lista de regras de política de roteamento.
Parâmetros Requeridos
- -protocol: Especificar o nome do protocolo para
associar a uma regra. (Cadeia, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a
classe de trabalho da política de roteamento se aplica. O
parâmetro -odrname é necessário somente se você modificar um
ODR.
- -nodename: Especificar o nome do nó no qual o ODR reside. O
parâmetro -nodename é necessário somente se você modificar um ODR.
- -clustername : Especificar o nome do
cluster ao qual a regra se aplica. O parâmetro -clustername
é necessário somente se você modificar um cluster do ODR.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask createRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Utilizando a cadeia Jython:
AdminTask.createRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Uso de exemplo do modo interativo
- Utilizando Jacl:
$AdminTask createRoutingRules {-interactive}
- Utilizando a cadeia Jython:
AdminTask.createRoutingRules ('[-interactive]')
listRoutingRules
O listRoutingRules exclui um cluster dinâmico da configuração.
Parâmetros Requeridos
- -protocol: Especificar o nome do protocolo para
associar a uma regra. (Cadeia, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a
classe de trabalho da política de roteamento se aplica. O
parâmetro -odrname é necessário somente se você modificar um
ODR.
- -nodename: Especificar o nome do nó no qual o ODR reside. O
parâmetro -nodename é necessário somente se você modificar um ODR.
- -clustername : Especificar o nome do
cluster ao qual a regra se aplica. O parâmetro -clustername
é necessário somente se você modificar um cluster do ODR.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask listRoutingRules {-odrname odr -nodename node1 -protocol SIP}
- Utilizando a cadeia Jython:
AdminTask.listRoutingRules('-odrname odr -nodename node1 -protocol SIP')
Uso de exemplo do modo interativo
- Utilizando Jacl:
$AdminTask listRoutingRules {-interactive}
- Utilizando a cadeia Jython:
AdminTask.listRoutingRules ('[-interactive]')
removeRoutingRule
O comando
removeRoutingRule remove uma regra de política de roteamento.
Parâmetros Requeridos
- -protocol: Especificar o nome do protocolo para
associar a uma regra. (Cadeia, obrigatória)
- -priority: Valor de número inteiro
positivo representando a prioridade de uma regra. Zero é a prioridade mais alta. (Cadeia,
obrigatória)
- -expression: Especificar a expressão da regra. A expressão deve ser delimitada por aspas duplas. Para obter informações adicionais sobre como especificar os parâmetros para a expressão da regra, consulte os tópicos de operandos SIP e HTTP.
(Cadeia, obrigatória)
Parâmetros Opcionais
- -odrname: Especificar o nome do ODR ao qual a
classe de trabalho da política de roteamento se aplica. O
parâmetro -odrname é necessário somente se você modificar um
ODR.
- -nodename: Especificar o nome do nó no qual o ODR reside. O
parâmetro -nodename é necessário somente se você modificar um ODR.
- -clustername : Especificar o nome do
cluster ao qual a regra se aplica. O parâmetro -clustername
é necessário somente se você modificar um cluster do ODR.
Exemplo de uso do modo em lote
- Utilizando Jacl:
$AdminTask removeRoutingRule {-odrname odr -nodename node1 -protocol SIP -expression "request.method = 'getOperation'"}
- Utilizando a cadeia Jython:
AdminTask.removeRoutingRule('[-odrname odr -nodename node1 -protocol HTTP -expression "request.method = \'INVITE\'"]')
Uso de exemplo do modo interativo
- Utilizando Jacl:
$AdminTask removeRoutingRule {-interactive}
- Utilizando a cadeia Jython:
AdminTask.removeRoutingRule ('[-interactive]')