Come posso assicurarmi che le patch di sicurezza non interrompano l'I/O del mio client?

Breve descrizione

Streaming gestito da Amazon per Apache Kafka (Amazon MSK) utilizza aggiornamenti continui per mantenere un'elevata disponibilità e supportare l'I/O del cluster durante l'applicazione delle patch. Amazon MSK riavvia i broker uno per uno e attende che le partizioni sull'ultimo broker riavviato recuperino completamente il ritardo prima di riavviare il broker successivo. Potresti riscontrare errori di disconnessione temporanei sui client durante questo processo di aggiornamento.

Per evitare tempi di inattività durante una patch di sicurezza, crea cluster ad alta disponibilità.

Risoluzione

Configura un cluster con tre zone di disponibilità

Per evitare tempi di inattività in caso di problemi di una zona di disponibilità, configura un cluster con tre zone di disponibilità.

Nota: per impostazione predefinita, i broker Express distribuiscono i dati in tre zone di disponibilità.

Per ottenere un'assegnazione della replica rack-aware per la tolleranza ai guasti, Amazon MSK imposta la proprietà broker.rack del broker a livello di zona di disponibilità. Quando utilizzi un cluster con tre zone di disponibilità e fattore di replica (RF) pari a 3, ciascuna delle tre repliche delle partizioni si trova in una zona di disponibilità distinta.

Nota: un cluster con due zone di disponibilità e un RF di 3 non può collocare ciascuna delle tre repliche di partizione in una zona di disponibilità distinta. Amazon MSK non consente di creare un cluster in una singola zona di disponibilità.

Imposta il fattore di replica uguale al numero di zone di disponibilità

Quando riavvii un broker durante una patch di sicurezza, il leader non è più disponibile. Di conseguenza, il cluster elegge una delle repliche successive come nuovo leader in modo da poter continuare a servire i client.

Un RF pari a 1 potrebbe portare a partizioni non disponibili durante un aggiornamento continuo perché il cluster non ha alcuna replica da promuovere come nuovo leader. Un RF pari a 2 con una replica in sincronia minima (minISR) di 1 potrebbe causare la perdita di dati, anche quando le conferme del producer (acks) è impostato su all. Affinché una scrittura abbia successo, un minISR pari a 1 richiede che solo il leader confermi la scrittura. Se il broker della replica leader diventa inattivo subito dopo la conferma, ma prima che subentri la replica successiva, si verifica una perdita di dati. Per ulteriori informazioni su minISR, consulta min.insync.replicas sul sito web Apache Kafka.

Nota: se utilizzi broker Express, per impostazione predefinita la replica è impostata su 3.

Imposta minISR su RF - 1 o meno

Se imposti il minlSR sul valore del fattore di replica, potresti ricevere errori del producer quando un broker è fuori servizio. Se le repliche non inviano una conferma che consenta al producer di eseguire la scrittura, il producer genera un'eccezione. Ad esempio, se il valore per le zone di disponibilità è 3 e il valore RF è 3, il producer attende che tutte e tre le repliche delle partizioni, incluso il leader, confermino i messaggi. Quando uno dei broker è fuori servizio, solo due delle tre partizioni restituiscono le conferme e ciò comporta un'eccezione del producer.

Nota: se utilizzi broker Express, per impostazione predefinita il minISR è impostato su 2.

Quando imposti le conferme del producer (acks) su all, il record non viene perso fintanto che almeno una replica sincronizzata rimane attiva. Per ulteriori informazioni sulle conferme del producer (acks), consulta acks sul sito web Apache Kafka.

Nota: minISR ha impostazioni a livello di topic e impostazioni a livello di broker. Le impostazioni a livello di topic hanno sempre la precedenza su quelle a livello di broker.

Includi almeno un broker per ogni zona di disponibilità nella stringa di connessione del client

Il client utilizza l'endpoint di un singolo broker per avviare una connessione al cluster. Durante la connessione iniziale con il client, il broker invia metadati con informazioni sui broker a cui il client deve accedere.

Quando un broker diventa non disponibile, la connessione ha esito negativo. Ad esempio, hai un solo broker nella stringa di connessione di un client. Durante l'applicazione delle patch, il client non riesce a stabilire una connessione iniziale con il cluster quando si riavvia il broker.

Oppure hai più broker in una stringa di connessione del client. In questo caso, la stringa di connessione del client consente il failover quando il broker utilizzato per stabilire la connessione va offline. Per ulteriori informazioni sulla configurazione di una stringa di connessione con più broker, consulta Ottieni i broker bootstrap per un cluster Amazon MSK.

Consenti la ripetizione

Quando riavvii un broker, le partizioni leader sul broker diventano non disponibili. Di conseguenza, Apache Kafka promuove le partizioni di replica su un altro broker come nuovo leader. Il client richiede dunque un aggiornamento dei metadati per individuare le nuove partizioni leader. Durante questa modifica, il client potrebbe subire errori transitori.

Per impostazione predefinita, i client hanno una funzionalità di ripetizione incorporata per gestire questi tipi di errori transitori. Verifica di aver configurato il client per la ripetizione. Per ulteriori informazioni sulla configurazione della ripetizione, consulta retries (ripetizione) sul sito web Apache Kafka.

Informazioni correlate

Applicazione di patch sui cluster MSK Provisioned