Documentation Oracle Cloud Infrastructure

Guide d'API Traffic Management Steering Policies

Utiliser l'API REST Oracle Cloud Infrastructure DNS pour créer et configurer des stratégies Traffic Management.

Utilisez le guide suivant pour découvrir comment les stratégies sont construites à l'aide de l'API REST DNS.

Authentification et autorisation

Chaque service d'Oracle Cloud Infrastructure s'intègre à IAM pour les fonctions d'authentification et d'autorisation, pour toutes les interfaces (console, kit SDK ou CLI, et API REST).

Un administrateur d'une organisation doit configurer des groupes , des compartiments et des stratégies qui détermine quels utilisateurs peuvent accéder à quels services, quelles ressources, ainsi qu'à quel type d'accès. Par exemple, les stratégies indiquent qui peut créer les utilisateurs, créer et gérer le réseau cloud, créer les instances, créer les buckets, télécharger les objets, etc. Pour plus d'informations, reportez-vous à Gestion des domaines d'identité. Afin d'obtenir des détails spécifiques sur l'élaboration de stratégies pour chacun des différents services, reportez-vous à Référence de stratégie.

Si vous êtes un utilisateur standard (pas un administrateur) et que vous avez besoin des ressources Oracle Cloud Infrastructure de l'entreprise, demandez à un administrateur de configurer pour vous un ID utilisateur. L'administrateur peut confirmer les compartiments que vous pouvez utiliser.

Composants de stratégie de pilotage de la gestion du trafic

La liste suivante décrit les composants utilisés pour créer une stratégie de pilotage de la gestion du trafic.

Stratégies de pilotage
Structure globale qui définit le comportement de gestion du trafic pour les zones. Les stratégies de pilotage contiennent des règles permettant de diriger de façon intelligente les réponses DNS.
Attachements
Permet de lier une stratégie de pilotage à des zones. L'attachement d'une stratégie de pilotage à une zone occlut tous les enregistrements de son domaine qui sont d'un type d'enregistrement couvert, en construisant des réponses DNS à partir de la stratégie et non à partir des enregistrements de domaine. Un domaine peut disposer d'un attachement au maximum, couvrant tout type d'enregistrement particulier.
Règles
Instructions utilisées par les stratégies de pilotage pour filtrer les réponses en fonction des propriétés d'une demande DNS, telles que la géolocalisation des demandes ou l'état des adresses.
Réponses
Les réponses contiennent les données et métadonnées d'enregistrement DNS à traiter dans une stratégie de pilotage.
Modèles
Les modèles sont des séquences de règles prédéfinies qui créent un type de stratégie et son comportement prévu. Exemple : le modèle FAILOVER sert des réponses en vérifiant d'abord la requête DNS par rapport à une règle FILTER , puis les règles suivantes successivement : HEALTH, PRIORITY et LIMIT. Le domaine dispose ainsi d'une fonctionnalité de basculement dynamique. Les stratégies qui utilisent dans le champ template une stratégie autre que CUSTOM doivent suivre la séquence de règles indiquée pour ce type de stratégie, sinon, une erreur avec le code de statut 400 est renvoyée lors de la création de la stratégie.
Cas
Une règle peut éventuellement contenir une séquence de cas qui définit des configurations alternatives pour traiter une requête DNS particulière. Lorsqu'une règle ne contient pas de séquence de cas, elle est toujours évaluée avec la même configuration. Lorsqu'une règle contient une séquence de cas vide, elle est toujours ignorée lors du traitement. Lorsqu'elle contient une séquence de cas qui n'est pas vide, son fonctionnement est déterminé par le premier cas qui correspond dans la séquence. Un cas de règle sans caseCondition correspond toujours. Un cas de règle avec une expression caseCondition correspond uniquement si l'expression renvoie la valeur True pour la requête spécifique.

Création de stratégies de pilotage à l'aide de modèles

La section suivante décrit la configuration de règle pour chaque type de modèle de stratégie de pilotage, suivie d'un exemple de demande POST (CreateSteeringPolicy) qui présente comment configurer chaque modèle.

Basculement

Les stratégies de basculement utilisateur permettent de définir la priorité des réponses utilisées dans une stratégie (par exemple, Principal et Secondaire). Les moniteurs Oracle Cloud Infrastructure Health Checks et les sondes à la demande sont utilisés pour évaluer l'état des réponses dans la stratégie. Si la réponse principale n'est pas en bon état, le trafic DNS est automatiquement piloté vers la réponse secondaire. Chacune des règles suivantes doit être définie dans l'ordre indiqué dans le champ rules du corps de la demande lorsque vous utilisez un modèle FAILOVER :

Ordre Règle Restrictions Commentaires
1 FILTER
  • Aucun cas n'est autorisé.

  • Les données de réponse doivent être définies dans defaultAnswerData à l'aide du fichier JSON suivant :

    
{
  "answerCondition": "answer.isDisabled != true",
  "shouldKeep": true
}
 
2 HEALTH
  • Aucun cas n'est autorisé.
Inclus uniquement si healthCheckMonitorId est défini pour la stratégie.
3 PRIORITÉ
  • Aucun cas n'est autorisé.
  • Les données de réponse doivent être définies dans la propriété defaultAnswerData de la règle.

  • Chaque réponse doit avoir une propriété pool.

  • defaultAnswerData restrictions :
    • Les réponses ne peuvent pas être référencées par leur propriété de nom dans les expressions answerCondition ; elles doivent être référencées par leur propriété de pool.
    • Chaque pool de réponses doit être référencé une seule fois.
    • PRIORITY
    • PRIORITY
  
4 LIMITE
  • Aucun cas n'est autorisé.
 

Exemple de stratégie POST /steeringPolicies utilisant le modèle 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

Les stratégies d'équilibreur de charge répartissent le trafic entre de nombreuses adresses. Vous pouvez affecter des pondérations égales aux adresses pour répartir le trafic uniformément entre les adresses ou vous pouvez affecter des pondérations personnalisées pour l'équilibrage de charge des ratios. Les moniteurs Oracle Cloud Infrastructure Health Checks et les sondes à la demande sont utilisés pour évaluer l'état de l'adresse. Le trafic DNS est automatiquement réparti vers les autres adresses, en cas de défaillance d'une adresse. Chacune des règles suivantes doit être définie dans l'ordre indiqué dans le champ rules du corps de la demande lorsque vous utilisez un modèle LOAD_BALANCE :

Ordre Règle Restrictions Commentaires
1 FILTER
  • Aucun cas n'est autorisé.

  • Les données de réponse doivent être définies dans defaultAnswerData à l'aide du fichier JSON suivant :

    
{
  "answerCondition": "answer.isDisabled != true",
  "shouldKeep": true
}
 
2 HEALTH
  • Aucun cas n'est autorisé.
Inclus uniquement si healthCheckMonitorId est défini pour la stratégie.
3 PONDÉRÉ
  • Aucun cas n'est autorisé.
  • Les données de réponse doivent être définies dans la propriété defaultAnswerData de la règle.
  • Les réponses ne peuvent pas être référencées par leur propriété de pool dans les expressions answerCondition ; elles doivent être référencées par leur propriété de nom.
 
4 LIMITE
  • Aucun cas n'est autorisé.
 

Exemple de stratégie POST /steeringPolicies à l'aide du modèle 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

Les stratégies de pilotage basées sur la géolocalisation répartissent le trafic DNS vers différentes adresses en fonction de l'emplacement de l'utilisateur final. Les clients peuvent définir des régions géographiques composées de continent, de pays ou d'Etats/de provinces (Amérique du Nord), et définir une adresse ou un ensemble d'adresses distinct pour chaque région. Chacune des règles suivantes doit être définie dans l'ordre indiqué dans le champ rules du corps de la demande lorsque vous utilisez un modèle ROUTE_BY_GEO :

Ordre Règle Restrictions Commentaires
1 FILTER
  • Aucun cas n'est autorisé.

  • Les données de réponse doivent être définies dans defaultAnswerData à l'aide du fichier JSON suivant :

    
{
  "answerCondition": "answer.isDisabled != true",
  "shouldKeep": true
}
 
2 HEALTH
  • Aucun cas n'est autorisé.
Inclus uniquement si healthCheckMonitorId est défini pour la stratégie.
3 PRIORITÉ
  • La propriété defaultAnswerData ne peut pas être utilisée sur cette règle.
  • Au moins un cas doit être défini. S'il existe de nombreux cas, le cas final peut fournir un cas "catch-all".
  • La propriété caseCondition dans les cas ne peut utiliser query.client.geoKey que dans l'expression conditionnelle.
  • Les réponses ne peuvent pas être référencées par leur propriété de nom dans les expressions answerCondition ; elles doivent être référencées par leur propriété de pool.
  • Chaque réponse doit avoir une propriété de piscine.

  • Pour chaque cas answerData :

    • Chaque pool de réponses doit être référencé une seule fois.
    • Chaque pool de réponses doit avoir une propriété de valeur unique (dans le cas présent).
    • Chaque référence de pool de réponses doit correspondre à la propriété de pool sur une ou plusieurs réponses définies dans la liste de réponses de la stratégie.
 
4 LIMITE
  • Aucun cas n'est autorisé.
 

Exemple de corps de demande POST /steeringPolicies utilisant le modèle 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

Les stratégies de pilotage basées sur le numéro ASN vous permettent de piloter le trafic DNS en fonction des numéros de système autonome (ASN). Les requêtes DNS provenant d'un numéro ASN ou d'un ensemble de numéros ASN spécifique peuvent être pilotées vers une adresse indiquée. Chacune des règles suivantes doit être définie dans l'ordre indiqué dans le champ rules du corps de la demande lorsque vous utilisez un modèle ROUTE_BY_ASN :

Ordre Règle Restrictions Commentaires
1 FILTER
  • Aucun cas n'est autorisé.

  • Les données de réponse doivent être définies dans defaultAnswerData à l'aide du fichier JSON suivant :

    
{
  "answerCondition": "answer.isDisabled != true",
  "shouldKeep": true
}
 
2 HEALTH
  • Aucun cas n'est autorisé.
Inclus uniquement si healthCheckMonitorId est défini pour la stratégie.
3 PRIORITÉ
  • La propriété defaultAnswerData ne peut pas être utilisée sur cette règle.
  • Au moins un cas doit être défini. S'il existe de nombreux cas, le cas final peut fournir un cas "catch-all".
  • La propriété caseCondition sur les cas ne peut utiliser query.client.asn que dans l'expression conditionnelle.
  • Les réponses ne peuvent pas être référencées par leur propriété de nom dans les expressions answerCondition ; elles doivent être référencées par leur propriété de pool.
  • LIMIT

  • Pour chaque cas answerData :

    • Chaque pool de réponses doit être référencé une seule fois.
    • Chaque pool de réponses doit avoir une propriété de valeur unique (dans le cas).
    • Chaque référence de pool de réponses doit correspondre à la propriété de pool sur une ou plusieurs réponses définies dans la liste de réponses de la stratégie.
  
4 LIMITE
  • Aucun cas n'est autorisé.
 

Exemple de corps de demande POST /steeringPolicies utilisant le modèle 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

Les stratégies de pilotage basées sur le préfixe IP permettent aux clients de piloter le trafic DNS en fonction du préfixe IP de la requête d'origine. Chacune des règles suivantes doit être définie dans l'ordre indiqué dans le champ rules du corps de la demande lorsque vous utilisez un modèle ROUTE_BY_IP :

Ordre Règle Restrictions Commentaires
1 FILTER
  • Aucun cas n'est autorisé.

  • Les données de réponse doivent être définies dans defaultAnswerData à l'aide du fichier JSON suivant :

    
{
  "answerCondition": "answer.isDisabled != true",
  "shouldKeep": true
}
 
2 HEALTH
  • Aucun cas n'est autorisé.
Inclus uniquement si healthCheckMonitorId est défini pour la stratégie.
3 PRIORITÉ
  • La propriété defaultAnswerData ne peut pas être utilisée sur cette règle.
  • Au moins un cas doit être défini. S'il existe de nombreux cas, le cas final peut fournir un cas "catch-all".
  • La propriété caseCondition dans les cas ne peut utiliser query.client.address que dans l'expression conditionnelle.
  • Les réponses ne peuvent pas être référencées par leur propriété de nom dans les expressions answerCondition ; elles doivent être référencées par leur propriété de pool.
  • Chaque réponse doit avoir une propriété de piscine.

  • Pour chaque cas answerData :

    • Chaque pool de réponses doit être référencé une seule fois.
    • Chaque pool de réponses doit avoir une propriété de valeur unique (dans le cas présent).
    • Chaque référence de pool de réponses doit correspondre à la propriété de pool sur une ou plusieurs réponses définies dans la liste de réponses de la stratégie.
 
4 LIMITE
  • Aucun cas n'est autorisé.
 

Exemple de corps de demande POST /steeringPolicies utilisant le modèle 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

Utilisez des stratégies personnalisées pour créer des stratégies complexes combinant les fonctionnalités de pilotage, de basculement, d'équilibrage de charge, de géolocalisation, de numéro ASN et de préfixe IP. Les modèles personnalisés ne nécessitent pas une séquence organisée de règles. Nous vous recommandons de contacter le support technique Oracle Cloud Infrastructure avant de créer une stratégie personnalisée.

Types de règle

FILTER
Utilise des données booléennes associées aux réponses, en ne conservant les réponses que si la valeur shouldKeep de la règle est true.
HEALTH
Utilise les moniteurs et les sondes à la demande d'OCI Health Checks pour évaluer l'état des adresses, et ajouter et enlever des réponses à la stratégie selon les besoins. Un moniteur de vérification d'état doit être référencé dans une règle d'état pour affecter la stratégie. Pour plus d'informations sur les vérifications d'état, reportez-vous à Vérifications d'état.
WEIGHTED
Utilise un nombre compris entre 0 et 255 afin d'évaluer la fréquence à laquelle une réponse est utilisée par rapport aux autres. Les réponses avec des valeurs plus élevées sont plus susceptibles d'être renvoyées.
PRIORITY
Utilise un entier associé à chaque réponse pour trier les réponses de la valeur la plus faible à la plus élevée. Exemple : une réponse dont la valeur de priorité est 1 est renvoyée avant une réponse dont la valeur de priorité est 10 dans la liste des réponses. Les réponses sans valeur de priorité sont déplacées à la fin de la liste des réponses.
LIMIT
Utilise une propriété de comptage pour ne conserver que les premières réponses de la liste.