Gestisci i criteri di routing e i controlli di integrità del DNS

I criteri di routing del DNS indirizzano il traffico in base al tipo di query (ad esempio Round Robin ponderato o geolocalizzazione). Puoi configurare questi criteri creando di set di record di risorse contenenti valori specifici dei criteri di routing. Questi valori determinare le modalità di routing del traffico. Ad esempio, in un criterio round robin ponderato, a ogni set di record di risorse è assegnato un peso che influisce sul traffico distribuzione dei contenuti.

Questa pagina fornisce informazioni su come creare, modificare ed eliminare i criteri di routing del DNS e l'abilitazione del controllo di integrità tramite Cloud DNS. Prima di utilizzare questa pagina, acquisisci familiarità con le Panoramica dei criteri DNS.

Per utilizzare i criteri di routing DNS, crea un set di record di risorse e scegli uno dei i seguenti criteri di routing DNS da applicare al set di record di risorse:

  • Criterio di routing WRR (round robin) ponderato: utilizza WRR per specificare valori diversi ponderazioni per record di risorse impostate per il nome DNS. Criteri di routing del DNS per garantire che il traffico sia distribuito in base alle ponderazioni configurate. La combinazione di un criterio di routing WRR e di un criterio di routing di geolocalizzazione non è supportati.

  • Criterio di routing di geolocalizzazione (GEO): utilizza l'impostazione GEO per specificare la geolocalizzazione di origine e fornire risposte corrispondenti a queste aree geografiche. La geolocalizzazione il criterio di routing applica la corrispondenza più vicina alla località di origine quando la sorgente del traffico non corrisponde esattamente a nessun elemento delle norme.

    L'impostazione GEO mappa l'origine per i DNS pubblici e privati nei seguenti modi:

    • Per DNS pubblico: l'indirizzo IP di origine o Meccanismo di estensione per DNS (EDNS) viene utilizzata la subnet client della query.
    • Per il DNS privato, non viene utilizzata la subnet client EDNS. Invece, la posizione della query è la posizione del sistema che invia i pacchetti la query:
      • Per query da un'istanza di una macchina virtuale (VM) con una rete in una rete VPC, la posizione della query corrisponde alla regione che contiene la VM.
      • Per le query ricevute da una voce dei criteri del server in entrata punto di accesso, la località della query è la regione del tunnel Cloud VPN, Collegamento VLAN di Cloud Interconnect o appliance router che ha ricevuto i pacchetti per la query. La regione del punto di ingresso L'indirizzo IP non è pertinente. Per ulteriori informazioni, consulta la sezione Rete regione per i prodotti in entrata query attive i criteri del server DNS .

  • Criterio di routing in geofencing: utilizza il geofencing per limitare il traffico a un geolocalizzazione specifica anche se tutti gli endpoint in quella geolocalizzazione sono non è integro. Per informazioni dettagliate sul geofencing, vedi Criteri di routing in geofencing

  • Criterio di routing del failover: usa il failover per configurare il backup attivo configurazioni. Per maggiori dettagli, vedi Criteri di routing del failover.

I criteri di routing del DNS supportano anche più indirizzi IP per ogni posizione geografica. Se viene specificato per una determinata posizione geografica, Gli indirizzi IP vengono restituiti secondo un criterio WRR di ponderazione uguale. Combinazione non è supportato un criterio di routing basato su dati geografici con un criterio WRR con ponderazione personalizzata.

Controlli di integrità

Cloud DNS supporta i controlli di integrità per i bilanciatori del carico di rete passthrough interni bilanciatori del carico delle applicazioni interni con l'accesso globale abilitato e bilanciatori del carico delle applicazioni interni tra regioni.

Dopo aver configurato un bilanciatore del carico di rete passthrough interno, configura il routing appropriato all'interno di Cloud DNS utilizzando la console Google Cloud, gcloud CLI, o l'API, che specifica il bilanciatore del carico di rete passthrough interno. Questo passaggio comporta l'impostazione di più bucket WRR o GEO e ciascun bucket può contiene più bilanciatori del carico di rete passthrough interni.

Per i bilanciatori del carico di rete passthrough interni, Cloud DNS controlla le informazioni di integrità sulle singole istanze di backend del bilanciatore del carico per determinare se il bilanciatore del carico è in stato integro o non integro. Cloud DNS applica un valore predefinito pari al 20% e se almeno il 20% delle istanze di backend è integro, l'endpoint del bilanciatore è considerato integro. I criteri di routing del DNS contrassegnano in stato integro o non integro in base a questa soglia, instradando il traffico di conseguenza.

Per i bilanciatori del carico delle applicazioni interni e i bilanciatori del carico delle applicazioni interni tra regioni, Cloud DNS controlla l'integrità complessiva del bilanciatore del carico delle applicazioni interno e consente anche al bilanciatore del carico delle applicazioni interno e controllare l'integrità delle istanze di backend.

Quando l'endpoint è contrassegnato come non integro, possono verificarsi le seguenti condizioni:

  • Se sono presenti più indirizzi VIP programmati in base a un criterio, solo vengono restituiti indirizzi VIP integri.

  • Se tutti gli indirizzi VIP programmati in un bucket di criteri non sono integri, la riga del criterio non è andata a buon fine. Si applica il seguente comportamento:

    • Per un criterio WRR: Cloud DNS distribuisce il traffico al peso integro successivo di sincronizzare la directory di una VM con un bucket.
    • Per un criterio GEO che non ha la recinzione abilitata, il traffico passa alla successiva area geografica più vicina.
    • Per un criterio per recinti virtuali con fencing abilitato, gli indirizzi VIP nel bucket geografico più vicino vengono restituiti così come sono.
    • Per un criterio di failover, Cloud DNS trasferisce il traffico al bucket di failover.
    • Se tutti i bucket di criteri non sono integri, Cloud DNS si comporta come se tutti gli endpoint sono integri.

Prima di iniziare

Questa procedura presuppone che tu abbia completato quanto segue:

  1. Creazione di una zona gestita e completamento dei prerequisiti per la creazione di una zona.
  2. Configura uno dei seguenti bilanciatori del carico interni:
  3. Sono state create regole di forwarding per il bilanciatore del carico interno.
  4. Configura il controllo di integrità per il bilanciatore del carico interno.

Crea criteri di routing DNS

Per creare un set di record di risorse e applicarvi un criterio di routing: passaggi.

Console

Avvia la configurazione

  1. Nella console Google Cloud, vai alla pagina Zone Cloud DNS.

    Vai alle zone Cloud DNS

  2. Fai clic sul nome della zona gestita a cui vuoi aggiungere il record.

  3. Nella pagina Dettagli zona, fai clic su Aggiungi con criterio di routing.

Dati di base

  1. Nella sezione Crea set di record con criterio di routing Nel campo Nome DNS, inserisci il sottodominio della zona DNS, per ad esempio mail. Il punto finale viene aggiunto automaticamente alla fine.

  2. Seleziona il Tipo di record di risorse, ad esempio A.

  3. Nel campo TTL, inserisci un valore numerico per il valore , che è la quantità di tempo per cui può essere memorizzata nella cache. Questo deve essere un numero intero positivo.

  4. Nel menu Unità TTL, seleziona l'unità di tempo, ad esempio 30 minutes.

  5. Fai clic su Avanti.

Tipo di criterio di routing

  1. Nell'elenco Criterio di routing, seleziona Round Robin ponderato, Geolocalizzazione o Failover.
  2. Fai clic su Avanti.

Dati dei criteri di routing

  1. Se hai selezionato Round robin ponderato, nella Dati di routing per il criterio round robin ponderato:

    1. Nel campo Ponderazione, inserisci la ponderazione corrispondente a questa metrica. dei dati del record di risorse (RR). Questo peso deve essere un numero non negativo compreso tra 0,0 e 1000,0. Rapporto di traffico indirizzato rispetto al target viene calcolato in base al rapporto tra rispetto al totale di tutti i pesi.

    2. Nella sezione Aggiungi target sottoposto a controllo di integrità, segui questi passaggi:

      1. Nell'elenco Progetto, seleziona il progetto in cui verrà eseguito l'inoltro una regola esistente.
      2. Nell'elenco Tipo, seleziona Bilanciatore del carico di rete passthrough interno, Application Load Balancer interno oppure Bilanciatore del carico delle applicazioni interno tra regioni.

      3. Nell'elenco Regola di forwarding, selezionane una.

        La regola di forwarding specifica un indirizzo IP interno, una porta e un servizio di backend regionale o un proxy HTTP(S). Per per far funzionare i controlli di integrità, devi e abilitare l'accesso globale per il bilanciatore del carico interno.

    3. Per consentire gli indirizzi IPv4 senza controllo di integrità, Seleziona Consenti indirizzi IPv4 senza controllo di integrità.

    4. Nel campo Indirizzo IPv4, inserisci un indirizzo IPv4.

  2. Se hai selezionato Geolocalizzazione, segui questi passaggi:

    1. Per Geofencing, seleziona Disattivato o Attivato. Abilitazione in corso... il geofencing limita il traffico a una specifica geolocalizzazione anche se tutti gli endpoint in quella geolocalizzazione sono in stato non integro.
    2. Nel menu Regione di origine, seleziona un cluster Google Cloud valido regione di origine, ad esempio asia-east1.

    3. Nella sezione Aggiungi target sottoposto a controllo di integrità, segui questi passaggi:

      1. Nell'elenco Progetto, seleziona il progetto in cui verrà eseguito l'inoltro una regola esistente.
      2. Nell'elenco Tipo, seleziona Bilanciatore del carico di rete passthrough interno, Application Load Balancer interno oppure Bilanciatore del carico delle applicazioni interno tra regioni.

      3. Nell'elenco Regola di forwarding, selezionane una.

        La regola di forwarding specifica un indirizzo IP interno, una porta e un servizio di backend regionale o un proxy HTTP(S). Affinché Cloud DNS funzioni con i controlli di integrità, devi e abilitare l'accesso globale per il bilanciatore del carico interno.

    4. Per consentire gli indirizzi IPv4 senza controllo di integrità, Seleziona Consenti indirizzi IPv4 senza controllo di integrità.

    5. Nel campo Indirizzo IPv4, inserisci un indirizzo IPv4.

  3. Se hai selezionato Failover:

    1. Nel campo Traffico lento (%), inserisci la percentuale di al traffico inviato alle destinazioni di failover, a prescindere dallo stato controllo di integrità dei target primari.

    2. Nella sezione Target principali, procedi nel seguente modo:

      1. Nell'elenco Progetto, seleziona il progetto in cui verrà eseguito l'inoltro una regola esistente.
      2. Nell'elenco Tipo, seleziona Bilanciatore del carico di rete passthrough interno, Application Load Balancer interno oppure Bilanciatore del carico delle applicazioni interno tra regioni.

      3. Nell'elenco Regola di forwarding, selezionane una.

        La regola di forwarding specifica un indirizzo IP interno, una porta e un servizio di backend regionale o un proxy HTTP(S). Per Cloud DNS per funzionare con i controlli di integrità, devi abilitare accesso globale per il bilanciatore del carico interno.

    3. Nella sezione Criterio di geolocalizzazione per il backup, segui questi passaggi:

      1. Per Geofencing, seleziona Disattivato o Attivato. Abilitazione in corso... il geofencing limita il traffico a una specifica geolocalizzazione anche se tutti gli endpoint in quella geolocalizzazione sono in stato non integro.
      2. Nel menu Regione di origine, seleziona un cluster Google Cloud valido regione di origine, ad esempio asia-east1.

      3. Nella sezione Aggiungi target sottoposto a controllo di integrità, segui questi passaggi:

        1. Nell'elenco Progetto, seleziona il progetto in cui verrà eseguito l'inoltro una regola esistente.
        2. Nell'elenco Tipo, seleziona Bilanciatore del carico di rete passthrough interno, Application Load Balancer interno oppure Bilanciatore del carico delle applicazioni interno tra regioni.
        3. Nell'elenco Regola di forwarding, selezionane una.

        Se tutti gli indirizzi IP principali non sono integri, il traffico viene e vengono gestiti automaticamente in base al criterio di geolocalizzazione di backup.

    4. Per consentire gli indirizzi IPv4 senza controllo di integrità, Seleziona Consenti indirizzi IPv4 senza controllo di integrità.

    5. Nel campo Indirizzo IPv4, inserisci un indirizzo IPv4.

  4. Fai clic su Avanti.

Rivedi e crea

  1. Fai clic su Esamina.
  2. Rivedi il set di record Cloud DNS con la configurazione dei criteri di routing.
  3. (Facoltativo) Fai clic su Riga di commento equivalente per visualizzare la Comando gcloud CLI per creare questo set di record con routing .
  4. Fai clic su Crea.

gcloud

Un ResourceRecordSet può contenere routingPolicy o rrdatas, ma non entrambi. Il passaggio tra rrdatas e routingPolicy è supportato durante l'aggiornamento ResourceRecordSets. Ad esempio, se vuoi aggiornare ResourceRecordSet che contiene rrdatas, puoi eliminare rrdatas e aggiungere routingPolicy allo stesso ResourceRecordSet.

Per creare un ResourceRecordSet e applicarvi un criterio di routing: passaggi.

Esegui l' gcloud dns record-sets create un comando kubectl.

Per le norme relative all'area geografica

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

Per i criteri WRR (round robin pesato)

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=WRR \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

Per i criteri relativi a recinti virtuali

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-geo-fencing
    --enable-health-checking

Per i criteri di failover

gcloud dns record-sets create RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=FAILOVER \
    --enable-geo-fencing \
    --routing-policy-primary-data=ROUTING_POLICY_PRIMARY_DATA \
    --routing-policy-backup-data-type=ROUTING_POLICY_BACKUP_DATA_TYPE \
    --routing-policy-backup-data=ROUTING_POLICY_BACKUP_DATA \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO \
    --enable-health-checking

Sostituisci quanto segue:

  • RRSET_NAME: il nome DNS che corrisponde alla richiesta in entrata query con il nome DNS di questa zona come suffisso, ad esempio service.example.com
  • TTL: il TTL in secondi in cui il resolver memorizza questo elemento nella cache ResourceRecordSet, ad esempio 30

  • RRSET_TYPE: tipo di record di risorse di questo ResourceRecordSet, ad esempio A

    Per un elenco dei tipi di record supportati, vedi Seleziona i tipi di record di risorse.

  • MANAGED_ZONE: la zona gestita ResourceRecordSet ha un'affiliazione con, come service-zone. Il nome di questo ResourceRecordSet deve avere il nome DNS del zona gestita come suffisso

  • ROUTING_POLICY_TYPE: il tipo di criterio di routing

    Inserisci WRR per il round robin ponderato, GEO per la geolocalizzazione oppure FAILOVER per i criteri di failover. Non puoi modificare questo campo dopo che un criterio ha un tipo scelto; puoi eliminare solo il criterio e aggiungerne uno nuovo di tipo diverso.

  • ROUTING_POLICY_DATA: i dati del criterio di routing

    • Per --routing-policy-type=WRR, inserisci un elenco delimitato da punti e virgola in il formato ${weight_percent}:${rrdatas}, ad esempio .8=203.0.113.1;.2=198.51.100.1. Specifica la ponderazione come decimale non negativo. Viene calcolato il rapporto tra il traffico indirizzato al target dal rapporto tra il peso del singolo e il totale di tutte le i pesi. I nomi delle regole di forwarding sono valori accettabili e comportano controllo di integrità.
    • Per --routing-policy-type=GEO, inserisci un elenco delimitato da punti e virgola in il formato ${region}=${IP_address}, ad esempio asia-east1=198.51.100.1;us-central1=203.0.113.1. Puoi specificare più indirizzi IP per una singola regione aggiungendo indirizzi IP separate da una virgola. I nomi delle regole di forwarding sono valori accettabili e comportano controllo di integrità.

    • Per --routing-policy-type=FAILOVER, inserisci il nome dell'inoltro creata nel formato ${region}=${Forwarding rule name}.

    Devi specificare sia il tipo di criterio di routing che il criterio di routing e i dati di Google Cloud. Se ne specifichi uno, non puoi lasciare vuoto l'altro.

  • --enable-geo-fencing: per GEO criteri di routing, questo determina sull'eventuale failover del traffico tra regioni se tutti gli endpoint in un non sono integri. Se impostato, Cloud DNS indirizza sempre le query alla regione più vicina, anche se tutti gli endpoint in quella regione sono in stato non integro. Usa --no-enable-geo-fencing per disattivare il geofencing. Se il criterio non viene configurato, Cloud DNS indirizza le query all'istanza successiva più vicina regione quando tutti gli endpoint in una regione non sono integro. Il valore predefinito è false.

  • ROUTING_POLICY_PRIMARY_DATA: il target principale da utilizzare per FAILOVER criteri di routing. Questo target deve essere un riferimento a una o più regole di forwarding, ad esempio forwarding-rule-1. A condizione che una di queste regole di forwarding è integro, gli indirizzi IP di vengono utilizzate regole di forwarding integro per rispondere alle query relative a questo nome.

  • ROUTING_POLICY_BACKUP_DATA: il target di backup da utilizzare per FAILOVER criteri di routing. Questi target vengono utilizzati quando le regole di forwarding specificate in --routing-policy-primary-data sono non è integro. Cloud DNS supporta solo i target di backup basati su dati geografici. La di questo campo corrisponde a quello di --routing-policy-data quando --routing-policy-type = 'GEO', ad esempio asia-east1=forwarding-rule-2.

  • ROUTING_POLICY_BACKUP_DATA_TYPE: per FAILOVER routing e il tipo di criterio di routing utilizzato dai dati di backup. Deve GEO.

  • BACKUP_DATA_TRICKLE_RATIO: il rapporto tra traffico verso vengono inviati alle destinazioni di backup, anche quando le istanze primarie sono in stato integro. Il rapporto deve essere compreso tra 0 e 1, ad esempio 0.1. Il valore predefinito è 0.

  • --enable-health-checking: il flag per abilitare il controllo di integrità. Quando utilizzare questo flag, devi fornire il nome della regola di forwarding anziché Indirizzo IP nel campo --routing-policy-data.

.

API

Utilizza la resourceRecordSets.create .

Per le norme relative all'area geografica

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
            "name": "RRSET_NAME",
            "type": "RRSET_TYPE",
            "ttl": TTL,
            "routingPolicy": {
          "geo": {
              "items": [
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCER_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCING_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              }
           ]

        }
     }
}

Per i criteri WRR (round robin pesato)

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
  "name": "RRSET_NAME",
        "type": "RRSET_TYPE",
        "ttl": TTL,
  "routingPolicy": {
    "wrr": {
      "items": [
        {
          "weight": WEIGHT,
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port" : "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT"
                "region": "REGION"
              }
            ]
          }
        },
        {
          "weight": WEIGHT,
          "healthCheckedTargets": {
            "internalLoadBalancers": [
              {
                "loadBalancerType": "LOAD_BALANCER_TYPE"
                "ipAddress": "IP_ADDRESS"
                "port" : "PORT_NUMBER"
                "ipProtocol": "IP_PROTOCOL"
                "networkUrl": "NETWORK_URL"
                "project": "PROJECT"
                "region": "REGION"
              }
            ]
          }
        },
      ]
    }
  }
}

Per le norme relative a FAILOVER for GEO

Nell'opzione di failover, Cloud DNS supporta solo i criteri GEO.

POST https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
  "name": "RRSET_NAME",
        "type": "RRSET_TYPE",
        "ttl": TTL,
  "routingPolicy": {
    "primaryBackup": {
      "trickleTraffic": TRICKLE_TRAFFIC,
      "primaryTargets": {
        "internalLoadBalancers": [
          {
            "ipAddress": "IP_ADDRESS"
            "ipProtocol": "IP_PROTOCOL"
            "loadBalancerType": "LOAD_BALANCER_TYPE"
            "networkUrl": "NETWORK_URL"
            "port": "PORT_NUMBER"
            "project": "PROJECT"
            "region": "REGION"
           }
         ]
       },
       "backupGeoTargets": {
         "enableFencing": ENABLE_FENCING,
         "items": [
           {
             "location": "LOCATION",
             "rrdatas": [
               "RRDATA"
             ]
           },
           {
             "location": "LOCATION",
             "rrdatas": [
               "RRDATA"
             ]
           }
         ]
       }
     },
   }
}

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto
  • MANAGED_ZONE: la zona gestita ResourceRecordSet ha un'affiliazione con, come service-zone; il nome di questo ResourceRecordSet deve avere il nome DNS del zona gestita come suffisso
  • RRSET_NAME: il nome DNS che corrisponde alla richiesta in entrata query con il nome DNS di questa zona come suffisso, ad esempio service.example.com
  • RRSET_TYPE: tipo di record di risorse di questo ResourceRecordSet, ad esempio A
  • TTL: il TTL in secondi in cui il resolver memorizza questo elemento nella cache ResourceRecordSet, ad esempio 30
  • TRICKLE_TRAFFIC: il rapporto tra traffico verso l'invio alle destinazioni di backup anche quando le istanze primarie sono integri; il rapporto deve essere compreso tra 0 e 1, ad esempio 0.1
  • ENABLE_FENCING: per GEO criteri di routing, questo determina se il failover del traffico deve avvenire tra regioni in una regione non sono integri. Se configurato, Cloud DNS esegue sempre indirizza le query alla regione più vicina, anche se tutti gli endpoint in quella non sono integri. Se il criterio non viene configurato, Cloud DNS indirizza le query alla alla regione più vicina quando tutti gli endpoint in una regione non sono integro. Il valore predefinito è false.
  • LOCATION: per i criteri GEO, la geolocalizzazione per necessario per creare il criterio, ad esempio asia-east1
  • WEIGHT: per i criteri WRR, un elenco delimitato da punti e virgola nel formato ${weight_percent}=${rrdatas}, ad esempio .8=10.128.1.1;.2=10.130.1.1; specifica la ponderazione come qualsiasi decimale
  • RR_DATA: un valore arbitrario associato alla risorsa set di record, ad esempio 198.51.100.5; puoi anche inserire più valori, rrdata1 rrdata2 rrdata3, ad esempio 198.51.100.1 203.0.113.1...
  • LOAD_BALANCER_TYPE: il tipo di bilanciatore del carico, ad esempio regionalL4ilb
  • IP_ADDRESS: l'indirizzo IP utilizzato dalla regola di forwarding serve
  • PORT_NUMBER: il numero di porta
  • IP_PROTOCOL: definisce il protocollo utilizzato per l'integrità verifica; le opzioni valide sono tcp e udp
  • NETWORK_URL: l'URL di rete a cui l'inoltro si applica una regola
  • REGION: la regione in cui hai creato l'inoltro regola

Aggiorna i criteri di routing del DNS

Per aggiornare il criterio di routing di un set di record di risorse, segui questi passaggi.

Console

  1. Nella console Google Cloud, vai alle zone Cloud DNS .

    Vai alle zone Cloud DNS

  2. Fai clic sulla zona per cui vuoi aggiornare il set di record di risorse di routing.

  3. Nella pagina Dettagli zona, accanto al set di record di risorse che aggiornare, fare clic su Modifica.

  4. Dopo aver apportato gli aggiornamenti necessari, fai clic su Salva.

gcloud

Esegui l' gcloud dns record-sets update :

Per le norme relative all'area geografica

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

Per i criteri WRR (round robin pesato)

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=WRR \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-health-checking

Per i criteri relativi a recinti virtuali

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=GEO \
    --routing-policy-data=ROUTING_POLICY_DATA \
    --enable-geo-fencing
    --enable-health-checking

Per i criteri di failover

gcloud dns record-sets update RRSET_NAME \
    --ttl=TTL \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \
    --routing-policy-type=FAILOVER \
    --enable-geo-fencing \
    --routing-policy-primary-data=ROUTING_POLICY_PRIMARY_DATA \
    --routing-policy-backup-data=ROUTING_POLICY_BACKUP_DATA \
    --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO \
    --enable-health-checking

Sostituisci quanto segue:

  • RRSET_NAME: il nome DNS che corrisponde alla richiesta in entrata query con il nome DNS di questa zona come suffisso, ad esempio service.example.com
  • TTL: il TTL in secondi in cui il resolver memorizza questo elemento nella cache ResourceRecordSet, ad esempio 30

  • RRSET_TYPE: tipo di record di risorse di questo ResourceRecordSet, ad esempio A

    Per un elenco dei tipi di record supportati, vedi Seleziona i tipi di record di risorse.

  • MANAGED_ZONE: la zona gestita ResourceRecordSet ha un'affiliazione con, come service-zone. Il nome di questo ResourceRecordSet deve avere il nome DNS del zona gestita come suffisso

  • ROUTING_POLICY_TYPE: il tipo di criterio di routing

    Inserisci WRR per il round robin ponderato, GEO per la geolocalizzazione oppure FAILOVER per i criteri di failover. Non puoi modificare questo campo dopo che un criterio ha un tipo scelto; puoi eliminare solo il criterio e aggiungerne uno nuovo di tipo diverso.

  • ROUTING_POLICY_DATA: i dati del criterio di routing

    • Per --routing-policy-type=WRR, inserisci un elenco delimitato da punti e virgola in il formato ${weight_percent}:${rrdatas}, ad esempio .8=203.0.113.1;.2=198.51.100.1. Specifica la ponderazione come decimale non negativo. Viene calcolato il rapporto tra il traffico indirizzato al target dal rapporto tra il peso del singolo e il totale di tutte le i pesi. I nomi delle regole di forwarding sono valori accettabili e comportano controllo di integrità.
    • Per --routing-policy-type=GEO, inserisci un elenco delimitato da punti e virgola in il formato ${region}=${IP_address}, ad esempio asia-east1=198.51.100.1;us-central1=203.0.113.1. Puoi specificare più indirizzi IP per una singola regione aggiungendo indirizzi IP separate da una virgola. I nomi delle regole di forwarding sono valori accettabili e comportano controllo di integrità.

    • Per --routing-policy-type=FAILOVER, inserisci il nome dell'inoltro creata nel formato ${region}=${Forwarding rule name}.

    Devi specificare sia il tipo di criterio di routing che il criterio di routing e i dati di Google Cloud. Se ne specifichi uno, non puoi lasciare vuoto l'altro.

  • --enable-geo-fencing: per GEO criteri di routing, questo determina sull'eventuale failover del traffico tra regioni se tutti gli endpoint in un non sono integri. Se impostato, Cloud DNS indirizza sempre le query alla regione più vicina, anche se tutti gli endpoint in quella regione sono in stato non integro. Usa --no-enable-geo-fencing per disattivare il geofencing. Se il criterio non viene configurato, Cloud DNS indirizza le query all'istanza successiva più vicina regione quando tutti gli endpoint in una regione non sono integro. Il valore predefinito è false.

  • ROUTING_POLICY_PRIMARY_DATA: il target principale da utilizzare per FAILOVER criteri di routing. Questo target deve essere un riferimento a una o più regole di forwarding, ad esempio forwarding-rule-1. A condizione che una di queste regole di forwarding è integro, gli indirizzi IP di vengono utilizzate regole di forwarding integro per rispondere alle query relative a questo nome.

  • ROUTING_POLICY_BACKUP_DATA: il target di backup da utilizzare per FAILOVER criteri di routing. Questi target vengono utilizzati quando le regole di forwarding specificate in --routing-policy-primary-data sono non è integro. Cloud DNS supporta solo i target di backup basati su dati geografici. La di questo campo corrisponde a quello di --routing-policy-data quando --routing-policy-type = 'GEO', ad esempio asia-east1=forwarding-rule-2.

  • BACKUP_DATA_TRICKLE_RATIO: il rapporto tra traffico verso inviati ai target di backup anche quando le istanze primarie sono integri. Il rapporto deve essere compreso tra 0 e 1, ad esempio 0.1. Il valore predefinito è 0.

  • --enable-health-checking: abilita il controllo di integrità dell'inoltro Regole che vengono fornite come rrdata a --routing-policy-data.

.

API

Utilizza la resourceRecordSets.patch . Specifica un solo valore tra rrset.rrdatas o rrset.routingPolicy. Se specificando routingPolicy, devi specificare il nuovo campo routingPolicy nella sua interezza.

Per i criteri GEO, utilizza il metodo seguente:

PATCH https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
            "name": "RRSET_NAME",
            "type": "RRSET_TYPE",
            "ttl": TTL,
            "routingPolicy": {
          "geo": {
              "items": [
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCER_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              {
                  "location": "LOCATION",
                  "healthCheckedTargets": {
                     "internalLoadBalancers": [
                      {
                       "loadBalancerType": "LOAD_BALANCING_TYPE"
                       "ipAddress": "IP_ADDRESS"
                       "port" : "PORT_NUMBER"
                       "ipProtocol": "IP_PROTOCOL"
                       "networkUrl": "NETWORK_URL"
                       "project": "PROJECT"
                       "region": "REGION"
                      }
                     ]
                  }
              },
              }
           ]

        }
     }
}

Per i criteri WRR, utilizza il metodo seguente:

PATCH https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets
{
        "name": "RRSET_NAME.",
        "type": "RRSET_TYPE",
        "ttl": TTL,
        "routingPolicy": {
          "wrrPolicy": {
              "item": [
                    {
                        "weight": WEIGHT,
                        "rrdatas": ["RR_DATA"]
                    },
                    {
                        "weight": WEIGHT,
                        "rrdatas": ["RR_DATA"]
                     }
               ],
            }
      }
}

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto
  • MANAGED_ZONE: la zona gestita ResourceRecordSet ha un'affiliazione con, come service-zone; il nome di questo ResourceRecordSet deve avere il nome DNS del zona gestita come suffisso
  • RRSET_NAME: il nome DNS che corrisponde alla richiesta in entrata query con il nome DNS di questa zona come suffisso, ad esempio service.example.com
  • RRSET_TYPE: tipo di record di risorse di questo ResourceRecordSet, ad esempio A
  • TTL: il TTL in secondi in cui il resolver memorizza questo elemento nella cache ResourceRecordSet, ad esempio 30
  • TRICKLE_TRAFFIC: il rapporto tra traffico verso l'invio alle destinazioni di backup anche quando le istanze primarie sono integri; il rapporto deve essere compreso tra 0 e 1, ad esempio 0.1
  • ENABLE_FENCING: per GEO criteri di routing, questo determina se il failover del traffico deve avvenire tra regioni in una regione non sono integri. Se configurato, Cloud DNS esegue sempre indirizza le query alla regione più vicina, anche se tutti gli endpoint in quella non sono integri. Se il criterio non viene configurato, Cloud DNS indirizza le query alla alla regione più vicina quando tutti gli endpoint in una regione non sono integro. Il valore predefinito è false.
  • LOCATION: per i criteri GEO, la geolocalizzazione per di cui devi aggiornare il criterio, ad esempio asia-east1
  • WEIGHT: per i criteri WRR, un elenco delimitato da punti e virgola nel formato ${weight_percent}=${rrdatas}, ad esempio .8=10.128.1.1;.2=10.130.1.1; specifica la ponderazione come qualsiasi decimale
  • RR_DATA: un valore arbitrario associato alla risorsa set di record, ad esempio 198.51.100.5; puoi anche inserire più valori, rrdata1 rrdata2 rrdata3, ad esempio 198.51.100.1 203.0.113.1...
  • LOAD_BALANCER_TYPE: il tipo di bilanciatore del carico, ad esempio regionalL4ilb
  • IP_ADDRESS: l'indirizzo IP utilizzato dalla regola di forwarding serve
  • PORT_NUMBER: il numero di porta
  • IP_PROTOCOL: definisce il protocollo utilizzato per l'integrità verifica; le opzioni valide sono tcp e udp
  • NETWORK_URL: l'URL di rete a cui l'inoltro si applica una regola
  • REGION: la regione in cui hai creato l'inoltro regola

Elimina criteri di routing DNS

Per eliminare un criterio di routing, devi eliminare il set di record di risorse contiene il criterio di routing. Per farlo, segui questi passaggi.

Console

  1. Nella console Google Cloud, vai alla pagina Zone Cloud DNS.

    Vai alle zone Cloud DNS

  2. Fai clic sulla zona per cui vuoi eliminare il set di record di risorse.

  3. Nella pagina Dettagli zona, accanto al nome DNS di il set di record di risorse che vuoi eliminare, seleziona la casella di controllo.

  4. Fai clic su Elimina set di record.

gcloud

Esegui l' gcloud dns record-sets delete :

gcloud dns record-sets delete RRSET_NAME \
    --type=RRSET_TYPE \
    --zone=MANAGED_ZONE \

Sostituisci quanto segue:

  • RRSET_NAME: il nome DNS che corrisponde alla richiesta in entrata query con il nome DNS di questa zona come suffisso, ad esempio service.example.com

  • RRSET_TYPE: tipo di record di risorse di questo ResourceRecordSet, ad esempio A

    Per un elenco dei tipi di record supportati, vedi Selezione dei tipi di record di risorse.

  • MANAGED_ZONE: la zona gestita ResourceRecordSet ha un'affiliazione con, come service-zone; il nome di questo ResourceRecordSet deve avere il nome DNS del zona gestita come suffisso

API

Utilizza la resourceRecordSets.delete :

DELETE https://www.googleapis.com/dns/v1/projects/PROJECT_ID/managedZones/MANAGED_ZONE/rrsets/RRSET_NAME/RRSET_TYPE

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto
  • MANAGED_ZONE: la zona gestita ResourceRecordSet ha un'affiliazione con, come my-zone-name; il nome di questo ResourceRecordSet deve avere il nome DNS del zona gestita come suffisso
  • RRSET_NAME: il nome DNS che corrisponde alla richiesta in entrata query con il nome DNS di questa zona come suffisso, ad esempio test.example.com
  • RRSET_TYPE: tipo di record di risorse di questo ResourceRecordSet, ad esempio A

Passaggi successivi