SLA (service level agreement) per la disponibilità Event Streams

Piano Standard

Il piano standard Event Streams fornisce un'architettura altamente disponibile per la distribuzione della regione multizona. In una sede multi-zona, il servizio di continuità operativa ( Event Streams ) è distribuito su tre zone di disponibilità, il che significa che il cluster è resiliente al guasto di una singola zona o di qualsiasi componente all'interno di quella zona.

Il servizio di assistenza Event Streams è fornito con disponibilità dell' 99.99 % sul piano Standard. Per ulteriori informazioni sullo SLA per i servizi ad alta disponibilità in IBM Cloud®, vedi SLA(Service Level Agreement)per IBM Cloud(Cloud pubblico).

piano Enterprise

Il piano Enterprise Event Streams fornisce un'architettura altamente disponibile per la distribuzione della regione multizona. In una sede multi-zona, il servizio di continuità operativa ( Event Streams ) è distribuito su tre zone di disponibilità, il che significa che il cluster è resiliente al guasto di una singola zona o di qualsiasi componente all'interno di quella zona.

In una distribuzione della regione multizona, viene fornito il servizio Event Streams con la disponibilità del 99.99% sul piano Enterprise. Per ulteriori informazioni sullo SLA per i servizi ad alta disponibilità in IBM Cloud, vedi SLA(Service Level Agreement)per IBM Cloud(Public Cloud).

Quando il servizio Event Streams è eseguito in una configurazione non altamente disponibile, come le ubicazioni a zona singola, la disponibilità è del 99.9%. Per ulteriori informazioni sullo SLA per servizi non altamente disponibili in IBM Cloud, vedi SLA(Service Level Agreement)per IBM Cloud(Cloud pubblico).

Come la misuriamo?

Le istanze del servizio sono monitorate continuamente per prestazioni, frequenze di errore e loro risposte alle operazioni di sintesi. Vengono registrate le interruzioni del servizio. Per ulteriori informazioni, vedi Stato del Servizio per Event Streams.

La disponibilità si riferisce alla capacità delle applicazioni di produrre ed utilizzare i messaggi dagli argomenti Kafka.

Cosa devi prendere in considerazione per ottenere questa disponibilità?

Per ottenere alti livelli di disponibilità dalla prospettiva dell'applicazione, dovresti considerare connettività, velocità effettiva e congruenza e durabilità dei messaggi. Gli utenti sono responsabili della progettazione delle loro applicazioni per ottimizzare questi tre elementi per il proprio business.

Connettività

A causa della natura dinamica del cloud, le applicazioni devono attendersi delle interruzioni della connessione. Un'interruzione della connessione non è considerata un malfunzionamento del servizio.

Tentativi

I client Kafka forniscono la logica di riconnessione, ma devi abilitare esplicitamente le riconnessioni per i produttori. Per ulteriori informazioni, consultare la proprietà retries. Le connessioni vengono rieffettuate entro 60 secondi.

Duplicati

Abilitando i nuovi tentativi potrebbero crearsi dei messaggi duplicati. A seconda di quando una connessione è stata persa, il produttore potrebbe non essere in grado di determinare se un messaggio è stato elaborato correttamente dal server e pertanto deve inviare nuovamente il messaggio quando si riconnette. Progettare le applicazioni per prevedere messaggi duplicati.

Se non è possibile tollerare duplicati, è possibile utilizzare la funzione di produttore di duplicati ( idempotent, da Kafka 1.1 ) per evitare duplicati durante i tentativi. Per ulteriori informazioni, consultare la proprietà enable.idempotence.

Velocità effettiva

La velocità effettiva viene espressa come il numero di byte al secondo che può essere inviato e ricevuto in un cluster.

Guida specifica per il piano Standard

Per informazioni sulla guida alla produttività, vedere Limiti e quote - Standard.

Guida specifica per il piano Enterprise

Per informazioni di orientamento sulla velocità effettiva, vedi Limiti e quote - Enterprise.

Misurazione

Strumentazione delle applicazioni per essere consapevoli di come stanno funzionando. Ad esempio, il numero di messaggi inviati e ricevuti, le dimensioni del messaggio e i codici di ritorno. Comprendere l'utilizzo di un'applicazione ti aiuta a configurare le sue risorse appropriatamente, come il tempo di conservazione per i messaggi sugli argomenti.

Saturazione

Quando il limite del traffico che può essere prodotto nel cluster viene raggiunto, i produttori iniziano ad essere limitati, la latenza aumenta ed infine si verificano dei malfunzionamenti come degli errori di timeout. A seconda della configurazione, anche la congruenza e la durabilità del messaggio potrebbero essere influenzate. Per ulteriori informazioni, vedi Congruenza e durabilità dei messaggi.

Congruenza e durabilità dei messaggi

Kafka raggiunge la sua disponibilità e durata replicando i messaggi che riceve su altri nodi nel cluster, che possono essere utilizzati in caso di errore. Event Streams utilizza tre replica (default.replication.factor = 3), il che significa che ogni messaggio ricevuto da un nodo viene replicato su due altri nodi in zone di disponibilità differenti. In questo modo, la perdita di un nodo o di una zona di disponibilità può essere tollerata senza la perdita di dati o funzioni.

Modalità produttore- acks e

Sebbene tutti i messaggi vengano replicati, le applicazioni possono controllare la robustezza con cui i messaggi da loro prodotti vengono trasferiti al servizio utilizzando la proprietà della modalità di produzione ( acks ). Questa proprietà fornisce una scelta tra velocità e rischio di perdita dei messaggi. Con Kafka 3.0, l'impostazione client predefinita è acks=all (prima di questa versione era acks=1). L'impostazione acks=all indica che il produttore restituisce l'esito positivo, non appena il broker a cui è connesso e almeno un altro broker nel cluster, ha riconosciuto di aver ricevuto il messaggio. Il vantaggio di utilizzare acks=all è che offre il più alto livello di durata e quindi la protezione contro la perdita di dati del messaggio.

Repliche sincronizzate

Nella configurazione utilizzata da Event Streams, Kafka sceglie un broker come leader per ciascuna replica di partizione e due altri broker come follower. I dati del messaggio dai client vengono inviati al leader per la partizione e vengono replicati ai follower. Se i seguaci stanno tenendo il passo con il leader, sono considerati repliche "in-sync". Il leader, per definizione, è sempre considerato in sincronia.

Se il leader per una partizione diventa non disponibile, forse a causa della manutenzione applicata al broker, Kafka elegge automaticamente una delle altre repliche in - sync per diventare il nuovo leader. Questo processo si verifica rapidamente e viene gestito automaticamente dai client di Kafka.

Elezioni leader impuro

Event Streams disabilita le elezioni leader non pulite. Questa impostazione non può essere modificata.

Il termine elezione leader non pulita descrive il modo in cui Kafka risponde in una situazione in cui tutta la replica in - sync per una partizione diventa non disponibile. Quando sono abilitate le elezioni leader non pulite, Kafka esegue il ripristino rendendo la prima replica disponibile come leader per la partizione, indipendentemente dal fatto che sia in sincronia. Ciò può causare la perdita dei dati del messaggio se la replica selezionata come leader non ha replicato tutti i dati del messaggio dal leader precedente. Quando le elezioni leader non pulite sono disabilitate (come nel caso di Event Streams), Kafka attende che una replica in - sync diventi disponibile e la sceglie come nuovo leader per la partizione. Ciò evita la potenziale perdita di dati del messaggio che può verificarsi quando sono abilitate le elezioni leader non pulite. Il compromesso è che il ripristino può richiedere più tempo perché Kafka potrebbe dover attendere che uno specifico broker venga riportato in linea prima che una partizione sia disponibile per i client per produrre e utilizzare i dati del messaggio.

Distribuzioni a ubicazioni a singola zona

Per la disponibilità più elevata ti consigliamo i nostri ambienti pubblici ad elevata disponibilità, creati nelle nostre ubicazioni multizona. In un'ubicazione multizona, i nostri cluster Kafka sono distribuiti in 3 zone di disponibilità, il che significa che il cluster è resiliente nel caso di un malfunzionamento di una singola zona o di tutti i componenti all'interno di una zona. Alcuni clienti richiedono la località geografica e quindi desiderano eseguire il provisioning di un cluster Event Streams in un'ubicazione geograficamente locale ma a zona singola. Event Streams supporta questo modello di distribuzione, tuttavia tieni presente i seguenti compromessi di disponibilità:

  • In un'ubicazione a singola zona, esistono delle categorie di singoli errori che potrebbero portare il cluster offline per un periodo di tempo. Ad esempio, il malfunzionamento di un intero data center o l'aggiornamento o il malfunzionamento di un componente condiviso ad esempio l'hypervisor sottostante, la SAN o la rete. Questi errori si riflettono nella SLA ridotta delle ubicazioni a singola zona.

  • Uno dei vantaggi della distribuzione dell' Kafka e in più zone è la riduzione al minimo della possibilità di un guasto che potrebbe mettere fuori uso un intero gruppo. Al contrario, c'è una piccola possibilità che un singolo guasto possa far cadere l'intero cluster all'interno di una zona. In casi estremi c'è anche la possibilità di perdere dei dati. Ad esempio, anche se i produttori utilizzano acks=all, se tutti i nodi dell' Kafka e si bloccassero contemporaneamente, potrebbero esserci alcuni messaggi di cui i broker hanno accusato ricevuta, ma il file system sottostante non ha completato il flusso su disco. Potenzialmente, quei messaggi non cancellati potrebbero andare persi.

Per ulteriori informazioni, vedi Riconoscimenti dei messaggi. In molti casi di utilizzo questo non è necessariamente un problema. Tuttavia, se la perdita di messaggi non è accettabile in nessun caso, considera altre strategie come l'utilizzo di un cluster di disponibilità multizona, la replica tra le regioni o il checkpoint del messaggio dal lato del produttore.

Per ulteriori informazioni, vedi cluster a zona singola e cluster multizona.