Risoluzione dei problemi

Questa pagina spiega vari scenari di errore e fornisce indicazioni per la risoluzione degli errori.

Scenari di replica

Questa sezione spiega i problemi di replica che potrebbero verificarsi con il cluster.

Come monitori i ritardi di replica?

Memorystore for Redis Cluster ha la metrica /cluster/replication/maximum_offset_diff. Questa metrica monitora la differenza massima di offset di replica (in byte) per un nodo in un cluster primario.

Mantenendo bassa la differenza di offset di replica, le repliche possono eseguire operazioni di sincronizzazione incrementale più frequentemente e a un costo inferiore rispetto alle operazioni di sincronizzazione completa.

Ti consigliamo di impostare una soglia per la metrica maximum_offset_diff. Se la soglia viene superata, Memorystore for Redis Cluster può inviarti una notifica tramite un avviso.

In base al tipo di nodo per il tuo cluster, ti consigliamo di impostare la soglia nel seguente modo:

  • Se il tipo di nodo è redis-shared-core-nano, redis-standard-small, redis-highmem-medium, redis-highcpu-medium o redis-standard-large, imposta la soglia su un valore inferiore a 64 MB.

  • Se il tipo di nodo è redis-highmem-xlarge o redis-highmem-2xlarge, imposta la soglia su un valore inferiore a 1 GB.

Scenari di errore di connettività

Questa sezione spiega i problemi di connettività che potrebbe riscontrare il tuo cluster.

Errore di connessione causato dalle regole firewall

Se non consenti le porte corrette sul firewall, il cluster potrebbe riscontrare errori di connessione perché il firewall potrebbe bloccare le porte utilizzate da Memorystore for Redis Cluster.

Per tutti gli endpoint Private Service Connect del cluster, devi consentire la porta TCP 6379, nonché le porte TCP da 11000 a 13047. Per saperne di più su questi endpoint, consulta Indirizzi di rete riservati.

Errore di connessione causato dai criteri dell'organizzazione

Potresti avere una policy dell'organizzazione che blocca le connessioni Private Service Connect al tuo cluster.

Se la policy dell'organizzazione utilizza la policy .restrictPrivateServiceConnectProducer, consenti la cartella 961333125034, che è una cartella specifica per Memorystore for Redis Cluster. Ad esempio:

name: organizations/Consumer-org-1/policies/compute.restrictPrivateServiceConnectProducer
spec:
    rules:
      - values:
          allowedValues:
          - under:folders/961333125034

Se il criterio dell'organizzazione utilizza il criterio .disablePrivateServiceConnectCreationForConsumers, consenti SERVICE_PRODUCERS. Ad esempio:

name: organizations/Consumer-org-1/policies/compute.disablePrivateServiceConnectCreationForConsumers
spec:
    rules:
      - values:
          allowedValues:
          - SERVICE_PRODUCERS

Errore di connessione causato da connessioni che non rispondono

Ti consigliamo vivamente di configurare l'applicazione client in modo che rilevi le connessioni non rispondenti a Memorystore for Redis Cluster. Quando viene rilevata una connessione che non risponde, il client deve ripristinarla. Per creare un'applicazione resiliente, ti consigliamo le seguenti configurazioni client:

  • Configura i parametri TCP keep-alive: imposta i parametri TCP keepalive time, TCP keepalive interval e TCP keepalive probes in modo che i client rilevino e interrompano le connessioni che non rispondono in modo proattivo, anche quando le connessioni sono inattive. Ad esempio, se imposti il parametro TCP keepalive time su 30 secondi, TCP keepalive interval su 10 secondi e TCP keepalive probes su 3, i client reimpostano le connessioni inattive che non rispondono entro un minuto.
  • Configura i timeout utente TCP: imposta questo timeout nei client per reimpostare le connessioni con richieste in sospeso e interrompere la risposta. Ad esempio, se imposti il timeout su 15 secondi, i client reimpostano le connessioni che non rispondono e che hanno richieste in sospeso dopo 15 secondi.

Scenari di utilizzo della CPU

Questa sezione spiega i problemi di utilizzo della CPU che il cluster potrebbe riscontrare.

Il buffer di output del cluster esaurisce lo spazio

Se il buffer di output del cluster esaurisce lo spazio, procedi nel seguente modo:

  • Imposta un valore più piccolo per il parametro maxmemory.
  • Utilizza le norme maxmemory allkeys-lru.

Quando la memoria del cluster è piena e arriva una nuova scrittura, Memorystore for Redis Cluster elimina le chiavi per fare spazio alla scrittura, in base ai criteri maxmemory del cluster. Le norme allkeys-lru eliminano le chiavi utilizzate meno di recente dall'intero set di chiavi.

Ti consigliamo di monitorare maxmemory e la memoria utilizzata del cluster. In questo modo puoi sapere se il tuo cluster raggiunge la capacità del cluster di cui è stato eseguito il provisioning. Inoltre, riducendo il valore del parametro maxmemory, avrai più spazio per l'overhead.

Perché potrebbero mancare metriche esterne per il tuo cluster?

Se il cluster registra un utilizzo elevato della CPU o le risorse del cluster si esauriscono (ad esempio, a causa di un numero eccessivo di connessioni), il cluster potrebbe non funzionare correttamente e le metriche esterne potrebbero non essere disponibili.

Isolare l'origine della latenza del cluster

Per determinare se la latenza che riscontri ha origine dal tuo cluster, dalla tua applicazione client o dal tuo ambiente di rete, utilizza lo strumento redis-cli per eseguire un test di latenza continuo.

Per isolare l'origine della latenza del cluster:

  1. Connettiti a una VM Compute Engine che si trova nella stessa regione e nella stessa rete VPC del cluster.

  2. Se non è già installato, installa lo strumento redis-cli sulla tua VM.

    • Per le VM basate su Debian o Ubuntu, esegui il seguente comando:

      sudo apt-get install redis-tools

    • Per le VM basate su RHEL o CentOS, esegui questo comando:

      sudo yum install redis

  3. Per misurare la latenza del cluster in millisecondi, esegui questo comando:

    redis-cli --latency -h DISCOVERY_ENDPOINT_ADDRESS -p PORT

    Se il cluster utilizza la crittografia dei dati in transito, aggiungi il flag --tls e specifica le autorità di certificazione (CA) a cui connetterti.

    Effettua le seguenti sostituzioni:

    • DISCOVERY_ENDPOINT_ADDRESS: l'indirizzo IP dell'endpoint di rilevamento del cluster.
    • PORT: il numero di porta riservato all'endpoint di rilevamento del cluster. In genere, questo numero di porta è 6379.

  4. Lascia che il comando venga eseguito per alcuni minuti. Lo strumento esegue il ping continuo del server e calcola i valori di latenza minimo, massimo e medio.

  5. Per interrompere il comando e visualizzare i risultati, premi Ctrl+C.

Se il comando restituisce una latenza media costantemente bassa (in genere 1 millisecondo o meno), il cluster è integro e risponde rapidamente.

Se il comando mostra una latenza costantemente bassa, ma l'applicazione client continua a riscontrare ritardi, i seguenti problemi potrebbero causare la latenza:

  • Rete: il traffico instradato in diverse regioni o zone tra il client e il cluster potrebbe introdurre ritardi di rete significativi.
  • Client: un utilizzo elevato della CPU o della memoria sul client, pool di connessioni esauriti o colli di bottiglia della logica dell'applicazione potrebbero aumentare il tempo di round trip totale riscontrato dal client.

Scenari di persistenza

Questa sezione spiega i problemi di persistenza che potrebbero verificarsi con il cluster.

Il traffico di scrittura supera la capacità di Memorystore for Redis Cluster di compattare e recuperare spazio tramite la riscrittura AOF

Se si verifica questa situazione, il file Append-Only File (AOF) cresce più velocemente di quanto possa gestire il processo di riscrittura. Ciò comporta l'esaurimento dello spazio su disco, causa errori di scrittura e blocca le operazioni che richiedono la creazione di repliche e la sincronizzazione completa.

Memorystore for Redis Cluster ha implementato misure di protezione per regolare il throughput di scrittura. In questo modo, la riscrittura di AOF può tenere il passo con i carichi di lavoro di scrittura elevata sostenuti.