Broker offline e failover del client - Amazon Managed Streaming per Apache Kafka

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Broker offline e failover del client

Kafka consente l'utilizzo di un broker offline; un unico broker offline in un cluster sano ed equilibrato che segue le migliori pratiche non avrà alcun impatto né causerà l'interruzione della produzione o del consumo. Questo perché un altro broker assumerà la guida delle partizioni e perché la libreria dei client di Kafka eseguirà automaticamente il failover e inizierà a inviare richieste ai nuovi broker leader.

Contratto client-server

Ciò si traduce in un contratto condiviso tra la libreria client e il comportamento lato server; il server deve assegnare correttamente uno o più nuovi leader e il client deve cambiare broker per inviare le richieste ai nuovi leader in modo tempestivo.

Kafka utilizza le eccezioni per controllare questo flusso:

Un esempio di procedura

  1. Il broker A entra in uno stato offline.

  2. Il client Kafka riceve un'eccezione (in genere la disconnessione della rete o not_leader_for_partition).

  3. Queste eccezioni fanno sì che il client Kafka aggiorni i propri metadati in modo da conoscere i leader più recenti.

  4. Il client Kafka riprende a inviare richieste ai nuovi responsabili delle partizioni su altri broker.

Questo processo richiede in genere meno di 2 secondi con il client Java fornito e le configurazioni predefinite. Gli errori lato client sono dettagliati e ripetitivi, ma non sono motivo di preoccupazione, come indicato dal livello «». WARN

Esempio: eccezione 1

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2

Esempio: eccezione 2

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"

I client Kafka risolveranno automaticamente questi errori in genere entro 1 secondo e al massimo 3 secondi. Ciò si presenta come una latenza di produzione/consumo a p99 nelle metriche lato client (in genere alti millisecondi negli anni 100). Un periodo superiore a questo valore indica in genere un problema con la configurazione del client o il carico del controller sul lato server. Consulta la sezione sulla risoluzione dei problemi.

Un failover riuscito può essere verificato controllando l'BytesInPerSecaumento delle LeaderCount metriche su altri broker, il che dimostra che il traffico e la leadership si sono mossi come previsto. Noterai anche un aumento della UnderReplicatedPartitions metrica, previsto quando le repliche sono offline con il broker di shutdown.

Risoluzione dei problemi

Il flusso di cui sopra può essere interrotto interrompendo il contratto client-server. I motivi più comuni del problema includono:

  • Configurazione errata o utilizzo errato delle librerie dei client Kafka.

  • Comportamenti e bug predefiniti imprevisti con librerie di client di terze parti.

  • Controller sovraccarico con conseguente rallentamento dell'assegnazione del leader di partizione.

  • Viene eletto un nuovo controller con conseguente rallentamento dell'assegnazione del leader di partizione.

Per garantire un comportamento corretto in caso di fallimento della leadership, consigliamo di:

  • È necessario seguire le migliori pratiche lato server per garantire che il controller broker sia dimensionato in modo appropriato per evitare rallentamenti nell'assegnazione dei dirigenti.

  • Le librerie client devono avere i nuovi tentativi abilitati per garantire che il client gestisca il failover.

  • Le librerie client devono avere retry.backoff.ms configurato (impostazione predefinita 100) per evitare tempeste di connessione/richieste.

  • Le librerie client devono impostare request.timeout.ms e delivery.timeout.ms su valori in linea con quelli delle applicazioni. SLA Valori più alti comporteranno un failover più lento per determinati tipi di errore.

  • Le librerie client devono garantire che bootstrap.servers contenga almeno 3 broker casuali per evitare un impatto sulla disponibilità sulla scoperta iniziale.

  • Alcune librerie client sono di livello inferiore rispetto ad altre e si aspettano che lo sviluppatore dell'applicazione implementi autonomamente la logica dei tentativi e la gestione delle eccezioni. Fate riferimento alla documentazione specifica di client lib, ad esempio sull'utilizzo, e assicuratevi che venga seguita la corretta logica di riconnessione/riprova.

  • Consigliamo di monitorare la latenza lato client per verificare la produzione, il conteggio delle richieste riuscite e il conteggio degli errori per errori non ripetibili.

  • Abbiamo osservato che le vecchie librerie golang e ruby di terze parti rimangono dettagliate durante l'intero periodo di tempo offline del broker, nonostante le richieste di produzione e consumo non ne risentano. Ti consigliamo di monitorare sempre le metriche a livello aziendale, oltre a quelle relative alle richieste di successo e agli errori, per determinare se i log registrano un impatto reale rispetto al rumore.

  • I clienti non devono allarmarsi per le eccezioni transitorie per network/not_leader, in quanto sono normali, ininfluenti e previste dal protocollo kafka.

  • I clienti non dovrebbero attivare gli allarmi in UnderReplicatedPartitions quanto sono normali, ininfluenti e previsti da un singolo broker offline.