Guida all'API per i criteri di indirizzamento per la gestione del traffico

Utilizza l'API REST Oracle Cloud Infrastructure DNS per creare e configurare i criteri di gestione del traffico.

Utilizza la guida riportata di seguito per scoprire come vengono creati i criteri utilizzando l'API REST DNS.

Autenticazione e autorizzazione

Ogni servizio in Oracle Cloud Infrastructure si integra con IAM per l'autenticazione e l'autorizzazione, per tutte le interfacce (console, SDK o CLI e API REST).

Un amministratore di un'organizzazione deve impostare i gruppi , i compartimenti e i criteri che controllano gli utenti che possono accedere ai servizi, alle risorse e al tipo di accesso. Ad esempio, i criteri controllano chi può creare nuovi utenti, creare e gestire la rete cloud, creare istanze, creare bucket, scaricare oggetti e così via. Per ulteriori informazioni, vedere Gestione dei domini di Identity. Per dettagli specifici sulla scrittura dei criteri relativi a ognuno dei vari servizi, consulta il riferimento per i criteri.

Se sei un utente normale (non un amministratore) che deve utilizzare le risorse Oracle Cloud Infrastructure di proprietà dell'azienda, contatta un amministratore per impostare un ID utente. L'amministratore può confermare quale compartimento o compartimenti è possibile utilizzare.

Componenti dei criteri di indirizzamento per la gestione del traffico

L'elenco riportato di seguito descrive i componenti utilizzati per creare un criterio di indirizzamento per la gestione del traffico.

CRITERI DI INDIRIZZAMENTO: Framework generale per definire il funzionamento della gestione del traffico per le zone. I criteri di indirizzamento contengono regole che aiutano a fornire risposte DNS in modo intelligente.
ALLEGATI: Consente di collegare un criterio di indirizzamento alle zone. Un collegamento di un criterio di indirizzamento a una zona comporta l'occlusione di tutti i record nel relativo dominio di un tipo di record coperto, la creazione di risposte DNS dal relativo criterio di indirizzamento anziché dai record di tali domini. Un dominio può avere al massimo un allegato che copre qualsiasi tipo di record specifico.
REGOLE: Le linee guida utilizzate dai criteri di indirizzamento per filtrare le risposte in base alle proprietà di una richiesta DNS, ad esempio la geolocalizzazione delle richieste o lo stato degli endpoint.
SOLUZIONI: Le risposte contengono i dati e i metadati dei record DNS da elaborare in un criterio di indirizzamento.
MODELLI: I modelli sono sequenze di regole predefinite che creano un tipo di criterio e il funzionamento previsto. Esempio: il modello FAILOVER fornisce risposte controllando prima la query DNS su una regola FILTER , quindi le regole seguenti in successione: HEALTH, PRIORITY e LIMIT. Fornisce la capacità di failover dinamico del dominio. I criteri che definiscono il campo template con qualsiasi criterio diverso da CUSTOM devono seguire la sequenza di regole delineata per quel tipo di criterio, altrimenti viene restituito un errore di codice di stato 400 alla creazione del criterio.
CASI: Una regola può facoltativamente includere una sequenza di casi che definiscono configurazioni alternative per il funzionamento durante l'elaborazione di una determinata query DNS. Quando una regola non ha una sequenza di casi, viene sempre valutata con la stessa configurazione durante l'elaborazione. Quando una regola ha una sequenza di casi vuota, viene sempre ignorata durante l'elaborazione. Quando una regola ha una sequenza di casi non vuota, il suo funzionamento durante l'elaborazione viene configurato dal primo caso corrispondente nella sequenza. Una regola senza caseCondition corrisponde sempre. Un caso di regola con un valore caseCondition corrisponde solo quando l'espressione restituisce true per la query specifica.

Crea criteri di indirizzamento mediante modelli

Nella sezione seguente viene illustrata la configurazione delle regole per ogni tipo di modello di criteri di indirizzamento seguito da una richiesta POST di esempio (CreateSteeringPolicy) che mostra come configurare ciascun modello.

FAILOVER

Criteri di failover utente per assegnare la priorità all'ordine in cui le risposte vengono fornite in un criterio, ad esempio Primario e Secondario. Oracle Cloud Infrastructure Health Checks monitora e sonde on-demand vengono utilizzate per valutare lo stato delle risposte nella policy. Se la risposta primaria risulta non sana, il traffico DNS viene indirizzato automaticamente alla risposta secondaria. Quando si utilizza un modello FAILOVER, è necessario definire ciascuna delle seguenti regole nell'ordine specificato nel campo rules del corpo della richiesta:


Ordina	Regola	Limitazioni	commenti
`1`	`FILTER`	Nessun caso consentito. I dati della risposta devono essere definiti in `defaultAnswerData` utilizzando il seguente JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Nessun caso consentito.	Incluso solo se per il criterio è definito `healthCheckMonitorId`.
`3`	`PRIORITY`	Nessun caso consentito. I dati della risposta devono essere definiti nella proprietà `defaultAnswerData` per la regola. Ogni risposta deve avere una proprietà pool. `defaultAnswerData` limitazioni: Le risposte non possono essere utilizzate come riferimento dalla proprietà del nome nelle espressioni `answerCondition`, ma devono essere utilizzate come riferimento dalla proprietà del pool. È necessario fare riferimento a ogni pool di risposte una sola volta. Ogni pool di risposte deve avere una proprietà valore univoca. Ogni riferimento al pool di risposte deve corrispondere alla proprietà del pool in una o più risposte definite nell'elenco di risposte per il criterio.
`4`	`LIMIT`	Nessun caso consentito.

Esempio di criterio POST /steeringPolicies che utilizza il modello 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

I criteri del load balancer distribuiscono il traffico tra molti endpoint. Puoi assegnare pesi uguali agli endpoint per distribuire il traffico in modo uniforme tra gli endpoint oppure puoi assegnare pesi personalizzati per il bilanciamento del carico proporzionale. Oracle Cloud Infrastructure Health Checks monitora e sonde on-demand vengono utilizzate per valutare lo stato dell'endpoint. Il traffico DNS viene distribuito automaticamente agli altri endpoint, se un endpoint risulta in cattivo stato. Quando si utilizza un modello LOAD_BALANCE, è necessario definire ciascuna delle seguenti regole nell'ordine specificato nel campo rules del corpo della richiesta:


Ordina	Regola	Limitazioni	Commenti
`1`	`FILTER`	Nessun caso consentito. I dati della risposta devono essere definiti in `defaultAnswerData` utilizzando il seguente JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Nessun caso consentito.	Incluso solo se per il criterio è definito `healthCheckMonitorId`.
`3`	`WEIGHTED`	Nessun caso consentito. I dati della risposta devono essere definiti nella proprietà defaultAnswerData per la regola. La proprietà del pool non può fare riferimento alle risposte nelle espressioni answerCondition. È necessario fare riferimento alle risposte mediante la proprietà del nome.
`4`	`LIMIT`	Nessun caso consentito.

Esempio di criterio POST /steeringPolicies che utilizza il modello 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

I criteri di indirizzamento basati sulla geolocalizzazione distribuiscono il traffico DNS a endpoint diversi in base alla posizione dell'utente finale. I clienti possono definire aree geografiche composte da continente di origine, paesi o stati/province (Nord America) e definire un endpoint separato o un set di endpoint per ogni area. Quando si utilizza un modello ROUTE_BY_GEO, è necessario definire ciascuna delle seguenti regole nell'ordine specificato nel campo rules del corpo della richiesta:


Ordina	Regola	Limitazioni	Commenti
`1`	`FILTER`	Nessun caso consentito. I dati della risposta devono essere definiti in `defaultAnswerData` utilizzando il seguente JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Nessun caso consentito.	Incluso solo se per il criterio è definito `healthCheckMonitorId`.
`3`	`PRIORITY`	Impossibile utilizzare la proprietà `defaultAnswerData` in questa regola. Definire almeno un caso. Se ci sono molti casi, il caso finale può fornire un caso "catch-all". La proprietà `caseCondition` nei casi può utilizzare solo `query.client.geoKey` nell'espressione condizionale. Le risposte non possono essere utilizzate come riferimento dalla proprietà del nome nelle espressioni `answerCondition`, ma devono essere utilizzate come riferimento dalla proprietà del pool. Ogni risposta deve avere una proprietà pool. Per ogni caso `answerData`: È necessario fare riferimento a ogni pool di risposte una sola volta. Ogni pool di risposte deve avere una proprietà valore univoca (nel caso). Ogni riferimento al pool di risposte deve corrispondere alla proprietà del pool in una o più risposte definite nell'elenco di risposte per il criterio.
`4`	`LIMIT`	Nessun caso consentito.

Esempio di corpo della richiesta POST /steeringPolicies che utilizza il modello 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

I criteri di indirizzamento basati su ASN consentono di indirizzare il traffico DNS in base ai numeri ASN (Autonomous System Numbers). Le query DNS provenienti da un ASN specifico o da un set di ASN possono essere indirizzate a un endpoint specificato. Quando si utilizza un modello ROUTE_BY_ASN, è necessario definire ciascuna delle seguenti regole nell'ordine specificato nel campo rules del corpo della richiesta:


Ordina	Regola	Limitazioni	commenti
`1`	`FILTER`	Nessun caso consentito. I dati della risposta devono essere definiti in `defaultAnswerData` utilizzando il seguente JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Nessun caso consentito.	Incluso solo se per il criterio è definito `healthCheckMonitorId`.
`3`	`PRIORITY`	Impossibile utilizzare la proprietà defaultAnswerData in questa regola. Definire almeno un caso. Se ci sono molti casi, il caso finale può fornire un caso "catch-all". La proprietà caseCondition nei casi può utilizzare solo query.client.asn nell'espressione condizionale. Le risposte non possono essere utilizzate come riferimento dalla proprietà del nome nelle espressioni answerCondition, ma devono essere utilizzate come riferimento dalla proprietà del pool. Ogni risposta deve avere una proprietà pool. Per ogni caso answerData: È necessario fare riferimento a ogni pool di risposte una sola volta. Ogni pool di risposte deve avere una proprietà valore univoca (nel caso). Ogni riferimento al pool di risposte deve corrispondere alla proprietà del pool in una o più risposte definite nell'elenco di risposte per il criterio.
`4`	`LIMIT`	Nessun caso consentito.

Esempio di corpo della richiesta POST /steeringPolicies che utilizza il modello 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

I criteri di indirizzamento basati su prefisso IP consentono ai clienti di indirizzare il traffico DNS in base al prefisso IP della query di origine. Quando si utilizza un modello ROUTE_BY_IP, è necessario definire ciascuna delle seguenti regole nell'ordine specificato nel campo rules del corpo della richiesta:


Ordina	Regola	Limitazioni	commenti
`1`	`FILTER`	Nessun caso consentito. I dati della risposta devono essere definiti in `defaultAnswerData` utilizzando il seguente JSON: `{ "answerCondition": "answer.isDisabled != true", "shouldKeep": true }`
`2`	`HEALTH`	Nessun caso consentito.	Incluso solo se per il criterio è definito `healthCheckMonitorId`.
`3`	`PRIORITY`	Impossibile utilizzare la proprietà `defaultAnswerData` in questa regola. Definire almeno un caso. Se ci sono molti casi, il caso finale può fornire un caso "catch-all". La proprietà `caseCondition` nei casi può utilizzare solo query.client.address nell'espressione condizionale. Le risposte non possono essere utilizzate come riferimento dalla proprietà del nome nelle espressioni `answerCondition`, ma devono essere utilizzate come riferimento dalla proprietà del pool. Ogni risposta deve avere una proprietà pool. Per ogni caso `answerData`: È necessario fare riferimento a ogni pool di risposte una sola volta. Ogni pool di risposte deve avere una proprietà valore univoca (nel caso). Ogni riferimento al pool di risposte deve corrispondere alla proprietà del pool in una o più risposte definite nell'elenco di risposte per il criterio.
`4`	`LIMIT`	Nessun caso consentito.

Esempio di corpo della richiesta POST /steeringPolicies che utilizza il modello 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
    }
  ]
}

PERSONALIZZA

Utilizza criteri personalizzati per creare criteri complessi che combinano le funzionalità di failover, bilanciamento del carico, geolocalizzazione, indirizzamento ASN e prefisso IP. Modelli personalizzati per non richiedere una sequenza regimentata di regole e si consiglia di contattare il supporto Oracle Cloud Infrastructure prima di creare un criterio personalizzato.

Tipi di regole

FILTRA: Utilizza dati booleani associati alle risposte, mantenendo le risposte solo se il valore shouldKeep della regola è true.
STATO: Utilizza i monitoraggi e le sonde on-demand di OCI Health Checks per valutare lo stato degli endpoint e aggiungere e rimuovere le risposte dal criterio in base alle esigenze. Per influire sul criterio, è necessario fare riferimento a un monitoraggio del controllo dello stato in una regola dello stato. Per ulteriori informazioni sui controlli dello stato, vedere Controlli dello stato.
PONDERATO: Utilizza un numero compreso tra 0 e 255 per valutare la frequenza con cui viene fornita una risposta rispetto ad altre risposte. Le risposte con valori più alti hanno maggiori probabilità di essere restituite.
PRIORITÀ: Utilizza un numero intero associato a ogni risposta per ordinare le risposte dal valore più basso al valore più alto. Esempio: una risposta con valore di priorità 1 viene restituita prima di una risposta con valore di priorità 10 nell'elenco delle risposte. Le risposte a cui non è stato assegnato un valore di priorità vengono spostate alla fine dell'elenco di risposte.
LIMITAZIONE: Utilizza una proprietà di conteggio per filtrare tutte le risposte tranne le prime nell'elenco.

Documentazione di Oracle Cloud Infrastructure