Come faccio ad assicurarmi che l'I/O del mio client non venga interrotto a causa delle patch di sicurezza?

5 minuti di lettura
0

Voglio conoscere alcune best practice per mantenere un'elevata disponibilità nei cluster MSK durante l'applicazione delle patch di sicurezza.

Breve descrizione

Il servizio 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. Durante questo processo, i broker vengono riavviati uno per uno e il broker successivo non viene riavviato finché le partizioni del broker attualmente riavviato non recuperano completamente il ritardo (sincronizzato). È normale riscontrare errori di disconnessione temporanei sui client durante questo processo di aggiornamento.

Per evitare che per i client si verifichino tempi di inattività durante l'applicazione delle patch di sicurezza, utilizza le seguenti best practice per rendere i cluster altamente disponibili.

Risoluzione

Configura un cluster a tre AZ

In caso di guasto di una zona di disponibilità, un cluster a tre AZ protegge da eventuali tempi di inattività.

Amazon MSK imposta la proprietà del broker broker.rack per ottenere un'assegnazione di replica compatibile con il rack per la tolleranza agli errori a livello di zona di disponibilità. Ciò significa che quando si utilizza un cluster a tre AZ con un fattore di replicazione (RF) pari a tre, ciascuna delle tre repliche di partizione si trova in una zona di disponibilità separata.

Nota: avere un cluster a due AZ con un RF-3 non consente a ciascuna delle tre repliche di partizione di trovarsi in una zona di disponibilità separata. Amazon MSK non consente di creare un cluster in una singola zona di disponibilità.

Assicurati che il fattore di replica sia il numero delle zone di disponibilità

Quando si riavvia un broker durante l'applicazione delle patch di sicurezza, il leader diventa non disponibile. Di conseguenza, una delle repliche successive viene eletta come nuovo leader in modo che il cluster possa continuare a fornire assistenza ai clienti.

Un RF-1 può portare a partizioni non disponibili durante un aggiornamento continuo perché il cluster non ha alcuna replica da promuovere come nuovo leader. Un RF-2, con una replica in sincronia minima (minISR) di uno, potrebbe causare la perdita di dati, anche quando il riconoscimento del produttore (acks) è impostato su "tutti". Affinché una scrittura abbia successo, un minISR di uno richiede che solo il leader confermi la scrittura. Se il broker della replica leader si interrompe immediatamente dopo il riconoscimento, ma prima che la replica successiva recuperi il ritardo, si verifica una perdita di dati. Per ulteriori informazioni su min.insync.replicas, consulta la documentazione di Apache Kafka.

Imposta minISR minimo su un massimo di RF-1

L'impostazione di minISR sul valore di RF può causare errori del produttore quando un broker è fuori servizio a causa di un aggiornamento continuo. Se le repliche non inviano una conferma da scrivere al produttore, il produttore solleva un'eccezione. Ad esempio, se AZ è uguale a tre e RF è uguale a tre, il produttore attende che tutte e tre le repliche della partizione (inclusa la leader) confermino i messaggi. Quando uno dei broker è fuori servizio, solo due delle tre partizioni restituiscono le conferme, con conseguenti eccezioni per i produttori.

Questo scenario presuppone che il produttore acks sia impostato su "tutti". Quando imposti il produttore ack su "tutti", il record non viene perso fintanto che almeno una replica sincronizzata rimane attiva. Per maggiori dettagli sui pacchetti dei produttori, consulta la documentazione di Apache Kafka.

Includi almeno un broker per ogni AZ 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 cliente, il broker invia metadati con informazioni sui broker a cui il cliente deve accedere.

Quando un broker diventa non disponibile, la connessione fallisce. 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 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 su come configurare una stringa di connessione con più broker, vedi Ottenere i broker bootstrap per un cluster Amazon MSK.

Consenti nuovi tentativi

Quando si riavvia un broker, le partizioni leader su quel broker diventano non disponibili. Di conseguenza, Apache Kafka promuove le partizioni di replica su un altro broker come nuovo leader. Il client ora richiede un aggiornamento dei metadati per individuare le nuove partizioni leader. Durante questa modifica, è normale che per il tuo client si verifichino errori transitori.

Per impostazione predefinita, i client dispongono di nuovi tentativi integrati per gestire questi tipi di errori transitori. Verifica che il client sia configurato per i nuovi tentativi. Per ulteriori informazioni sulla configurazione dei nuovi tentativi, consulta la documentazione di Apache Kafka.

AWS UFFICIALE
AWS UFFICIALEAggiornata un anno fa