Risoluzione dei problemi

In questa pagina vengono illustrati vari scenari di errore e vengono fornite indicazioni per la risoluzione degli errori.

Scenari di replica

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

Come si monitorano 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 del cluster, ti consigliiamo di impostare la soglia come segue:

  • 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 illustra i problemi di connettività che potrebbero verificarsi con il cluster.

Errore di connessione causato dalle regole firewall

Le regole firewall potrebbero causare errori di connessione bloccando le porte utilizzate da Memorystore for Redis Cluster. Per entrambi gli endpoint Private Service Connect del cluster, consenti 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 un criterio dell'organizzazione che blocca le connessioni Private Service Connect al cluster.

Se il criterio dell'organizzazione utilizza il criterio .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 che non rispondono a Memorystore for Redis Cluster. Quando viene rilevata una connessione che non risponde, il client deve reimpostarla. Per creare un'applicazione resiliente, ti consigliamo le seguenti configurazioni client:

  • Configura i parametri keep-alive TCP: imposta i parametri TCP keepalive time, TCP keepalive interval e TCP keepalive probes in modo che i client rilevino e abbandonino in modo proattivo le connessioni che non rispondono, 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 con richieste in sospeso dopo 15 secondi.

Scenari di utilizzo della CPU

Questa sezione illustra i problemi di utilizzo della CPU che potrebbero verificarsi con il cluster.

Il buffer di output del cluster esaurisce lo spazio

Se il buffer di output del cluster esaurisce lo spazio:

  • Imposta un valore inferiore per il maxmemory parametro.
  • Utilizza il criterio allkeys-lru maxmemory.

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 al criterio maxmemory del cluster. Il criterio allkeys-lru elimina le chiavi utilizzate meno di recente (LRU) dall'intero keyset.

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

Perché potrebbero mancare le metriche esterne per il 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 mancare.

Isola l'origine della latenza del cluster

Per determinare se la latenza che riscontri proviene dal cluster o dall'applicazione client e dall'ambiente di rete, puoi utilizzare lo strumento redis-cli per eseguire un test di latenza continuo.

Per isolare l'origine della latenza del cluster:

  1. Connettiti a una VM di 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 VM.

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

      sudo apt-get install redis-tools

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

      sudo yum install redis

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

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

    Se il cluster utilizza la crittografia in transito, devi aggiungere il flag --tls e specificare le autorità di certificazione (CA) per la connessione.

    Esegui 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 continuamente il ping del server e calcola i valori di latenza minimo, massimo e medio.

  5. Per interrompere l'esecuzione del 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 le prestazioni tipiche del server, ma l'applicazione client continua a riscontrare ritardi, i seguenti problemi potrebbero causare la latenza:

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

Scenari di persistenza

Questa sezione illustra 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

In questa situazione, il file AOF (Append-Only File) cresce più velocemente di quanto il processo di riscrittura possa gestire. Ciò comporta l'esaurimento del 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 dei guardrail per regolare la velocità effettiva di scrittura. In questo modo, la riscrittura AOF può tenere il passo con i carichi di lavoro di scrittura elevati e sostenuti.