Guia da API do Serviço Traffic Management Steering Policies

Use a API REST do Oracle Cloud Infrastructure DNS para criar e configurar políticas de Gerenciamento de Tráfego.

Use o guia a seguir para saber como as políticas são criadas usando a API REST de DNS.

Autenticação e Autorização

Cada serviço do Oracle Cloud Infrastructure se integra ao serviço IAM para autenticação e autorização, para todas as interfaces (a Console, SDK ou CLI e API REST).

Um administrador de uma organização precisa configurar grupos, compartimentos e políticas que controlam quais usuários podem acessar quais serviços, quais recursos e o tipo de acesso. Por exemplo, as políticas controlam quem pode criar novos usuários, criar e gerenciar a rede na nuvem, criar instâncias, criar buckets, fazer download dos objetos, entre outros. Para obter mais informações, consulte Gerenciando Domínios de Identidade. Para ver detalhes específicos sobre a gravação de políticas para cada um dos diversos serviços, consulte Referência de Políticas.

Se você for um usuário comum (não um administrador) que precisa usar os recursos do Oracle Cloud Infrastructure que a empresa possui, entre em contato com um administrador para configurar um ID de usuário para você. O administrador pode confirmar o(s) compartimento(s) que você pode usar.

Componentes da Política de Orientação de Gerenciamento de Tráfego

A lista a seguir descreve os componentes usados para criar uma Política de Orientação do Gerenciamento de Tráfego.

STEERING POLICIES: Um framework geral para definir o comportamento do gerenciamento de tráfego para zonas. As políticas de orientação contêm regras que ajudam a fornecer respostas de DNS com inteligência.
ATTACHMENTS: Permite vincular uma política de orientação a zonas. Um anexo de uma política de orientação a uma zona oclui todos os registros em seu domínio que são de um tipo de registro coberto, criando respostas de DNS com base em sua política de orientação em vez de com base nos registros desse domínio. Um domínio pode ter no máximo um anexo abrangendo qualquer tipo de registro específico.
RULES: As diretrizes que as políticas de orientação usam para filtrar respostas com base nas propriedades de uma solicitação de DNS, como a geolocalização das solicitações ou a integridade dos pontos finais.
ANSWERS: As respostas contêm os dados de registro de DNS e os metadados a serem processados em uma política de orientação.
MODELOS: Modelos são sequências de regras predefinidas que criam um tipo de política e seu comportamento pretendido. Exemplo: O modelo FAILOVER atende as respostas verificando a consulta de DNS em uma regra FILTER primeiro, depois, as seguintes regras em sequência: HEALTH, PRIORITY e LIMIT. Isso oferece o recurso de failover dinâmico de domínio. As políticas que definem o campo template com qualquer outra política que não seja CUSTOM devem seguir a sequência de regras descrita para esse tipo de política; caso contrário, um erro de código de status 400 será retornado na criação da política.
CASOS: Opcionalmente, uma regra pode incluir uma sequência de casos que define configurações alternativas de como ela se comporta durante o processamento de qualquer consulta de DNS específica. Quando uma regra não tem sequência de casos, é sempre avaliada com a mesma configuração durante o processamento. Quando uma regra tem uma sequência vazia de casos, ela é sempre ignorada durante o processamento. Quando uma regra tem uma sequência não vazia de casos, seu comportamento durante o processamento é configurado pelo primeiro caso de correspondência na sequência. Um caso de regra sem caseCondition sempre coincide. Um caso de regra com um caseCondition só corresponde quando essa expressão é avaliada como verdadeira para a consulta específica.

Criar Políticas de Orientação Usando Modelos

A seção a seguir explica a configuração da regra para cada tipo de modelo de política de orientação seguido de um exemplo de solicitação POST ( CreateSteeringPolicy) exibindo como configurar cada modelo.

FAILOVER

Políticas de failover do usuário para priorizar a ordem em que as respostas são fornecidas em uma política (por exemplo, Principal e Secundário). Os monitores e as investigações sob demanda do Oracle Cloud Infrastructure Health Checks são utilizados para avaliar a integridade das respostas na política. Se a Resposta Principal for encontrada como não íntegra, o tráfego de DNS será automaticamente direcionado para a Resposta Secundária. Cada uma das regras a seguir deve ser definida na ordem especificada no campo rules do corpo da solicitação ao usar um modelo FAILOVER:


Ordem	Regra	Restrições	Comentários
`1`	`FILTER`	Não são permitidos casos. Os dados da resposta devem ser definidos em `defaultAnswerData` usando o seguinte JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Não são permitidos casos.	Só será incluída se `healthCheckMonitorId` for definido para a política.
`3`	`PRIORITY`	Não são permitidos casos. Os dados de resposta devem ser definidos na propriedade `defaultAnswerData` da regra. Cada resposta deve ter uma propriedade de pool. `defaultAnswerData` restrições: As respostas não podem ser referenciadas por sua propriedade de nome nas expressões `answerCondition`; elas devem ser referenciadas por sua propriedade de pool. Cada pool de respostas deve ser referenciado uma vez e apenas uma vez. PRIORITY PRIORITY
`4`	`LIMITE`	Não são permitidos casos.

Exemplo de uma política POST /steeringPolicies usando o modelo FAILOVER:

{
  "compartmentId": "ocid1...",
  "displayName": "failover between endpoints",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "FAILOVER",
  "answers": [
    {
      "name": "server-primary",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "primary"
    },
    {
      "name": "server-secondary",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "secondary"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "PRIORITY",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.pool == 'primary'",
          "value": 1
        },
        {
          "answerCondition": "answer.pool == 'secondary'",
          "value": 99
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

LOAD_BALANCE

As políticas do Balanceador de Carga distribuem o tráfego entre muitos pontos finais. Você pode atribuir pesos iguais aos pontos finais para distribuir o tráfego uniformemente entre os pontos finais ou pode atribuir pesos personalizados para balanceamento de carga de proporção. Os monitores e investigações sob demanda do Oracle Cloud Infrastructure Health Checks são aproveitados para avaliar a integridade do ponto final. O tráfego de DNS é distribuído automaticamente para os outros pontos finais, se um ponto final não for íntegro. Cada uma das regras a seguir deve ser definida na ordem especificada no campo rules do corpo da solicitação ao usar um modelo LOAD_BALANCE:


Ordem	Regra	Restrições	Comentários
`1`	`FILTER`	Não são permitidos casos. Os dados da resposta devem ser definidos em `defaultAnswerData` usando o seguinte JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Não são permitidos casos.	Só será incluída se `healthCheckMonitorId` for definido para a política.
`3`	`PONDERADO`	Não são permitidos casos. Os dados de resposta devem ser definidos na propriedade defaultAnswerData da regra. As respostas não podem ser referenciadas por sua propriedade de pool em expressões answerCondition; elas devem ser referenciadas por sua propriedade de nome.
`4`	`LIMITE`	Não são permitidos casos.

Exemplo de uma política POST /steeringPolicies usando o modelo LOAD_BALANCE:

{
  "compartmentId": "ocid1...",
  "displayName": "Weighted load balance for a set of answers with health checks",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "LOAD_BALANCE",
  "answers": [
    {
      "name": "server1",
      "rtype": "A",
      "rdata": "192.168.0.2"
    },
    {
      "name": "server2",
      "rtype": "A",
      "rdata": "192.168.0.3"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "WEIGHTED",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.name == 'server1'",
          "value": 99
        },
        {
          "answerCondition": "answer.name == 'server2'",
          "value": 1
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_GEO

As políticas de orientação baseadas em geolocalização distribuem o tráfego de DNS para diversos pontos finais com base na localização do usuário final. Os clientes podem definir regiões geográficas compostas de continentes, países ou estados/províncias de origem (América do Norte) e definir um ponto final separado ou um conjunto de pontos finais para cada região. Cada uma das regras a seguir deve ser definida na ordem especificada no campo rules do corpo da solicitação ao usar um modelo ROUTE_BY_GEO:


Ordem	Regra	Restrições	Comentários
`1`	`FILTER`	Não são permitidos casos. Os dados da resposta devem ser definidos em `defaultAnswerData` usando o seguinte JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Não são permitidos casos.	Só será incluída se `healthCheckMonitorId` for definido para a política.
`3`	`PRIORITY`	A propriedade `defaultAnswerData` não pode ser usada nesta regra. Pelo menos um caso deve ser definido. Se houver muitos casos, o último poderá fornecer um caso "catch-all". A propriedade `caseCondition` nos casos só pode usar `query.client.geoKey` na expressão condicional. As respostas não podem ser referenciadas pela propriedade name em expressões `answerCondition`; elas devem ser referenciadas por sua propriedade pool. Cada resposta deve ter uma propriedade de pool. Para `answerData` de cada caso: Cada pool de respostas deve ser referenciado uma vez e apenas uma vez. Cada pool de respostas deve ter uma propriedade de valor exclusiva (dentro do caso). Cada referência do pool de respostas deve corresponder à propriedade do pool em uma ou mais respostas definidas na lista de respostas da política.
`4`	`LIMIT`	Não são permitidos casos.

Exemplo de um corpo de solicitação POST /steeringPolicies usando o modelo ROUTE_BY_GEO:

{
  "compartmentId": "ocid1...",
  "displayName": "Geolocations mapped to answer pools",
  "ttl": 30,
  "healthCheckMonitorId": "ocid1...",
  "template": "ROUTE_BY_GEO",
  "answers": [
    {
      "name": "US Server 1",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "US"
    },
    {
      "name": "US Server 2",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "US"
    },
    {
      "name": "EU Server 1",
      "rtype": "A",
      "rdata": "192.168.0.4",
      "pool": "EU"
    },
    {
      "name": "EU Server 2",
      "rtype": "A",
      "rdata": "192.168.0.5",
      "pool": "EU"
    },
    {
      "name": "rest of world 1",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Global"
    },
    {
      "name": "rest of world 2",
      "rtype": "A",
      "rdata": "203.0.113.3",
      "pool": "Global"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "HEALTH"
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.geoKey in (geoKey '6255149')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.geokey in (geokey '6255148')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Global'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'US'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'EU'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_ASN

As políticas de orientação baseadas no ASN permitem direcionar o tráfego de DNS com base nos ASNs (Autonomous System Numbers). As consultas de DNS originárias de um ASN específico ou de um conjunto de ASNs podem ser direcionadas para um ponto final especificado. Cada uma das regras a seguir deve ser definida na ordem especificada no campo rules do corpo da solicitação ao usar um modelo ROUTE_BY_ASN:


Ordem	Regra	Restrições	Comentários
`1`	`FILTER`	Não são permitidos casos. Os dados da resposta devem ser definidos em `defaultAnswerData` usando o seguinte JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Não são permitidos casos.	Só será incluída se `healthCheckMonitorId` for definido para a política.
`3`	`PRIORITY`	A propriedade defaultAnswerData não pode ser usada nesta regra. Pelo menos um caso deve ser definido. Se houver muitos casos, o último poderá fornecer um caso "catch-all". A propriedade caseCondition em casos só pode usar query.client.asn na expressão condicional. As respostas não podem ser referenciadas por sua propriedade de nome nas expressões answerCondition; elas devem ser referenciadas por sua propriedade de pool. LIMIT Para o answerData de cada caso: Cada pool de respostas deve ser referenciado uma vez e apenas uma vez. Cada pool de respostas deve ter uma propriedade de valor exclusiva (dentro do caso). Cada referência do pool de respostas deve corresponder à propriedade do pool em uma ou mais respostas definidas na lista de respostas da política.
`4`	`LIMIT`	Não são permitidos casos.

Exemplo de um corpo de solicitação POST /steeringPolicies usando o modelo ROUTE_BY_ASN:

{
  "compartmentId": "ocid1...",
  "displayName": "ASNs mapped to pools",
  "ttl": 30,
  "template": "ROUTE_BY_ASN",
  "answers": [
    {
      "name": "ABC Server",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "ABC"
    },
    {
      "name": "DEF Server",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "DEF"
    },
    {
      "name": "Other",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Other"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.asn == 3",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.asn == 16591",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

ROUTE_BY_IP

As políticas de orientação baseadas no Prefixo IP permitem que os clientes direcionem o tráfego de DNS com base no Prefixo IP da consulta de origem. Cada uma das regras a seguir deve ser definida na ordem especificada no campo rules do corpo da solicitação ao usar um modelo ROUTE_BY_IP:


Ordem	Regra	Restrições	Comentários
`1`	`FILTER`	Não são permitidos casos. Os dados da resposta devem ser definidos em `defaultAnswerData` usando o seguinte JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Não são permitidos casos.	Só será incluída se `healthCheckMonitorId` for definido para a política.
`3`	`PRIORITY`	A propriedade `defaultAnswerData` não pode ser usada nesta regra. Pelo menos um caso deve ser definido. Se houver muitos casos, o último poderá fornecer um caso "catch-all". A propriedade `caseCondition` nos casos só pode usar query.client.address na expressão condicional. As respostas não podem ser referenciadas por sua propriedade de nome nas expressões `answerCondition`; elas devem ser referenciadas por sua propriedade de pool. Cada resposta deve ter uma propriedade de pool. Para `answerData` de cada caso: Cada pool de respostas deve ser referenciado uma vez e apenas uma vez. Cada pool de respostas deve ter uma propriedade de valor exclusiva (dentro do caso). Cada referência do pool de respostas deve corresponder à propriedade do pool em uma ou mais respostas definidas na lista de respostas da política.
`4`	`LIMIT`	Não são permitidos casos.

Exemplo de um corpo de solicitação POST /steeringPolicies usando o modelo ROUTE_BY_IP:

{
  "compartmentId": "ocid1...",
  "displayName": "IP subnets mapped to answer pools",
  "ttl": 30,
  "template": "ROUTE_BY_IP",
  "answers": [
    {
      "name": "ABC Server",
      "rtype": "A",
      "rdata": "192.168.0.2",
      "pool": "ABC"
    },
    {
      "name": "DEF Server",
      "rtype": "A",
      "rdata": "192.168.0.3",
      "pool": "DEF"
    },
    {
      "name": "Other",
      "rtype": "A",
      "rdata": "203.0.113.2",
      "pool": "Other"
    }
  ],
  "rules": [
    {
      "ruleType": "FILTER",
      "defaultAnswerData": [
        {
          "answerCondition": "answer.isDisabled != true",
          "shouldKeep": true
        }
      ]
    },
    {
      "ruleType": "PRIORITY",
      "cases": [
        {
          "caseCondition": "query.client.address in (subnet '10.0.3.0/24')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "caseCondition": "query.client.address in (subnet '192.0.2.2/24')",
          "answerData": [
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 3
            }
          ]
        },
        {
          "answerData": [
            {
              "answerCondition": "answer.pool == 'Other'",
              "value": 1
            },
            {
              "answerCondition": "answer.pool == 'ABC'",
              "value": 2
            },
            {
              "answerCondition": "answer.pool == 'DEF'",
              "value": 3
            }
          ]
        }
      ]
    },
    {
      "ruleType": "LIMIT",
      "defaultCount": 1
    }
  ]
}

CUSTOM

Use políticas personalizadas para criar políticas complexas que combinam os recursos de failover, balanceamento de carga, geolocalização, orientação do ASN e de prefixo IP. Modelos personalizados para não exigir uma sequência regimentada de regras. Recomendamos que você entre em contato com o suporte do Oracle Cloud Infrastructure antes de criar uma política personalizada.

Tipos de Regras

FILTER: Usa dados boolianos associados a respostas, mantendo respostas apenas se o valor shouldKeep da regra for true.
HEALTH: Usa monitores e investigações sob demanda do OCI Health Checks para avaliar a integridade dos pontos finais e adicionar e remover respostas da política, conforme necessário. Um monitor de verificação de integridade deve ser referenciado em uma regra de integridade para afetar a política. Para obter mais informações sobre Verificações de Integridade, consulte Verificações de Integridade.
WEIGHTED: Usa um número entre 0 e 255 usado para avaliar a frequência com que uma resposta é fornecida em relação a outras respostas. As respostas com valores mais altos têm mais probabilidade de serem retornadas.
PRIORITY: Usa um número inteiro associado a cada resposta para classificar respostas do valor mais baixo para o mais alto. Exemplo: Uma resposta com valor de prioridade 1 seria retornada antes de uma resposta com valor de prioridade 10 na lista de respostas. As respostas que não tiverem valor de prioridade designado para elas serão movidas para o final da lista de respostas.
LIMIT: Usa uma propriedade de contagem para filtrar todas as respostas, exceto as primeiras da lista.

Documentação do Oracle Cloud Infrastructure