Service Level Agreement (SLA) für die Verfügbarkeit von Event Streams

Standard-Plan

Der Event Streams -Standardplan bietet eine hoch verfügbare Architektur durch die Bereitstellung einer Region mit mehreren Zonen. An einem Standort mit mehreren Zonen wird der Event Streams-Service auf drei Verfügbarkeitszonen verteilt, wodurch der Cluster vor dem Ausfall einer einzelnen Zone oder einer beliebigen Komponente innerhalb dieser Zone geschützt ist.

Der Event Streams-Dienst wird mit einer Verfügbarkeit von 99.99 % im Standard-Plan bereitgestellt. Weitere Informationen zum SLA für Hochverfügbarkeitsservices in IBM Cloud®finden Sie unter Service Level Agreements für IBM Cloud(Public Cloud).

Enterprise-Plan

Der Event Streams Enterprise Plan bietet eine Hochverfügbarkeitsarchitektur durch die Bereitstellung einer Region mit mehreren Zonen. An einem Standort mit mehreren Zonen wird der Event Streams -Service auf drei Verfügbarkeitszonen verteilt, was bedeutet, dass der Cluster gegen den Ausfall einer einzelnen Zone oder einer beliebigen Komponente innerhalb dieser Zone widerstandsfähig ist.

Bei einem Einsatz in einer Region mit mehreren Zonen wird der Event Streams-Dienst mit einer Verfügbarkeit von 99.99 % im Enterprise-Plan bereitgestellt. Weitere Informationen zum SLA für Hochverfügbarkeitsservices in IBM Cloudfinden Sie unter Service-Level-Agreements für IBM Cloud(Public Cloud).

Wenn der Event Streams-Dienst in einer nicht hochverfügbaren Konfiguration ausgeführt wird, z. B. an Standorten mit nur einer Zone, beträgt die Verfügbarkeit 99.9 %. Weitere Informationen zum SLA für nicht hoch verfügbare Services in IBM Cloudfinden Sie unter Service-Level-Agreements für IBM Cloud(Public Cloud).

Wie erfolgt die Messung?

Serviceinstanzen werden kontinuierlich hinsichtlich ihrer Leistung, ihrer Fehlerraten und ihrer Reaktion auf synthetische Operationen überwacht. Ausfälle werden aufgezeichnet. Weitere Informationen finden Sie unter Servicestatus für Event Streams.

Die Verfügbarkeit bezieht sich auf die Fähigkeit von Anwendungen, Nachrichten aus Kafka-Topics zu erstellen und zu verarbeiten.

Was muss zum Erreichen dieser Verfügbarkeit beachtet werden?

Damit ein hoher Grad an Verfügbarkeit aus der Perspektive der Anwendung erreicht werden kann, müssen Konnektivität, Durchsatz sowie Konsistenz und Permanenz von Nachrichten berücksichtigt werden. Es liegt im Verantwortungsbereich der Benutzer, Anwendungen so zu entwerfen, dass sie diese drei Aspekte für ihr Unternehmen optimieren.

Konnektivität

Aufgrund der dynamischen Eigenschaften der Cloud müssen Anwendungen auf Verbindungsunterbrechungen vorbereitet sein. Eine Verbindungsunterbrechung wird nicht als Serviceausfall bewertet.

Retries

Kafka -Clients stellen Logik für die Verbindungswiederholung bereit, aber Sie müssen die Verbindungswiederholung für Produzenten explizit aktivieren. Weitere Informationen finden Sie in der retries-Eigenschaft. Verbindungen werden innerhalb von 60 Sekunden wiederhergestellt.

Duplikate

Das Aktivieren von Wiederholungen kann zu doppelten Nachrichten führen. Abhängig vom Zeitpunkt der Verbindungsunterbrechung kann der Producer möglicherweise nicht feststellen, ob eine Nachricht erfolgreich vom Server verarbeitet wurde, und muss daher die Nachricht nach dem Wiederherstellen der Verbindung erneut senden. Anwendungen so entwerfen, dass doppelte Nachrichten erwartet werden.

Wenn Duplikate nicht toleriert werden können, können Sie das idempotent -Producer-Feature (ab Kafka 1.1) verwenden, um Duplikate während Wiederholungen zu verhindern. Weitere Informationen finden Sie in der enable.idempotence-Eigenschaft.

Durchsatz

Der Durchsatz wird als Anzahl der Byte pro Sekunde ausgedrückt, die in einem Cluster sowohl gesendet als auch empfangen werden können.

Spezifische Anleitungen für den Standardplan

Informationen zum Durchsatz finden Sie in Grenzwerte und Quoten-Standard.

Spezifische Anleitungen für den Enterprise-Plan

Informationen zum Durchsatz finden Sie in Grenzwerte und Kontingente - Enterprise.

Messwert

Instrumentieren Sie Anwendungen, um deren Leistung zu kennen. Hierzu gehören beispielsweise die Anzahl der gesendeten und empfangenen Nachrichten, die Nachrichtengrößen und die Rückgabecodes. Mithilfe einer Analyse der Anwendungsnutzung können Sie die zugehörigen Ressourcen entsprechend konfigurieren, wie z. B. den Aufbewahrungszeitraum für Nachrichten zu Topics.

Sättigung

Sobald der Grenzwert für den Datenverkehr, der in dem Cluster erzeugt werden kann, erreicht wird, werden die Erzeuger gedrosselt, die Latenzzeit erhöht sich und schließlich treten Fehler wie Zeitlimitfehler auf. Abhängig von der Konfiguration kann sich dies auch auf die Konsistenz und Permanenz von Nachrichten auswirken. Weitere Informationen finden Sie in Konsistenz und Permanenz von Nachrichten.

Konsistenz und Permanenz von Nachrichten

Kafka erreicht seine Verfügbarkeit und Dauerhaftigkeit, indem die empfangenen Nachrichten auf anderen Knoten im Cluster repliziert werden, die dann bei einem Ausfall verwendet werden können. Event Streams verwendet drei Replikate (default.replication.factor = 3), d. h., jede von einem Knoten empfangene Nachricht wird auf zwei anderen Knoten in verschiedenen Verfügbarkeitszonen repliziert. Auf diese Weise kann der Verlust eines Knotens oder einer Verfügbarkeitszone ohne Daten- oder Funktionalitätsverlust toleriert werden.

Produzentenmodus`acks`

Obwohl alle Nachrichten repliziert werden, können Anwendungen mithilfe der acks-Moduseigenschaft des Erzeugers steuern, wie robust die von ihnen erzeugten Nachrichten an den Dienst übertragen werden. Diese Eigenschaft bietet die Auswahlmöglichkeit zwischen Geschwindigkeit und dem Risiko eines Nachrichtenverlusts. Bei Kafka 3.0ist die Standardclienteinstellung acks=all (vor dieser Version war es acks=1). Die Einstellung acks=all bedeutet, dass der Erzeuger den Erfolg zurückgibt, sobald sowohl der Broker, mit dem er verbunden ist, als auch mindestens ein weiterer Broker im Cluster den Empfang der Nachricht bestätigt haben. Der Vorteil der Verwendung von acks=all besteht darin, dass sie die höchste Permanenz bietet und somit vor dem Verlust von Nachrichtendaten schützt.

Synchrone Replikate

In der Konfiguration, die Event Streams verwendet, wählt Kafka einen Broker als Leader für jedes Partitionsreplikat und zwei weitere Broker als Follower aus. Nachrichtendaten von Clients werden an den Leader für die Partition gesendet und an die Follower repliziert. Wenn die Follower mit dem Leader Schritt halten, gelten sie als "synchrone" Replikate. Der Leader wird per Definition immer als synchron betrachtet.

Wenn der Leader für eine Partition nicht mehr verfügbar ist, weil möglicherweise eine Wartung auf den Broker angewendet wird, wählt Kafka automatisch eines der anderen synchronen Replikate als neuen Leader aus. Dieser Prozess erfolgt schnell und wird von Kafka-Clients automatisch verarbeitet.

Unsaubere Wahlen des Führers

Event Streams inaktiviert unbereinigte Führungswahlen. Diese Einstellung kann nicht geändert werden.

Der Begriff unclean leader election beschreibt, wie Kafka in einer Situation reagiert, in der alle synchronen Replikate für eine Partition nicht mehr verfügbar sind. Wenn unbereinigte Leader-Wahlen aktiviert sind, wird Kafka wiederhergestellt, indem das erste Replikat als Leader für die Partition verfügbar gemacht wird, unabhängig davon, ob es synchron ist. Dies kann dazu führen, dass Nachrichtendaten verloren gehen, wenn das als Leader ausgewählte Replikat nicht alle Nachrichtendaten vom vorherigen Leader repliziert hat. Wenn unbereinigte Leader-Wahlen inaktiviert sind (wie dies bei Event Streamsder Fall ist), wartet Kafka auf die Verfügbarkeit eines synchronen Replikats und wählt es als neuen Leader für die Partition aus. Dadurch wird das Risiko eines Nachrichtendatenverlusts vermieden, der auftreten kann, wenn unbereinigte Führungswahlen aktiviert sind. Der Kompromiss besteht darin, dass die Wiederherstellung länger dauern kann, weil Kafka möglicherweise warten muss, bis ein bestimmter Broker wieder online ist, bevor eine Partition für Clients verfügbar ist, um Nachrichtendaten zu erzeugen und zu konsumieren.

Bereitstellungen an Standorten mit einer einzelnen Zone

Für den höchsten Grad an Verfügbarkeit werden die öffentlichen Hochverfügbarkeitsumgebungen empfohlen, die an Standorten mit mehreren Zonen eingerichtet sind. An einem Standort mit mehreren Zonen sind die Kafka-Cluster über 3 Verfügbarkeitszonen verteilt, d. h., der Cluster ist ausfallsicher, sollte eine einzelne Zone oder eine Komponente innerhalb dieser Zone ausfallen. Einige Kunden benötigen eine geografische Lokalität und möchten daher einen Event Streams-Cluster an einem geografisch lokalen, aber einzelnen Zonenstandort bereitstellen. Event Streams unterstützt dieses Bereitstellungsmodell, allerdings sollten Sie die folgenden Verfügbarkeitseinschränkungen beachten:

An einem Standort mit einer einzelnen Zone können einzelne, bestimmten Kategorien zuzuordnende Ausfälle auftreten, die dazu führen können, dass der Cluster über einen bestimmten Zeitraum hinweg offline ist. Beispiel: Ausfall eines gesamten Rechenzentrums oder Aktualisierung bzw. Ausfall einer gemeinsam genutzten Komponente wie beispielsweise des zugrunde liegenden Hypervisors, SANs oder Netzes. Solche Ausfälle spiegeln sich in einer entsprechenden Reduzierung im SLA für Standorte mit einer einzelnen Zone wider.
Ein Vorteil der Verteilung von Kafka auf viele Zonen besteht darin, die Wahrscheinlichkeit eines Ausfalls zu minimieren, der einen ganzen Cluster zum Absturz bringen könnte. Im Gegensatz dazu besteht eine geringe Wahrscheinlichkeit, dass ein einzelner Fehler den gesamten Cluster innerhalb einer Zone zum Absturz bringen könnte. In extremen Fällen besteht die Möglichkeit eines Datenverlustes. Selbst wenn beispielsweise acks=allvon den Erzeugern verwendet wird und alle Kafka -Knoten gleichzeitig inaktiv wurden, kann es einige Nachrichten geben, für die die Broker den Empfang bestätigt haben, aber das zugrunde liegende Dateisystem hat die Flushoperation auf Platte nicht abgeschlossen. Möglicherweise gehen diese nicht gesendeten Nachrichten verloren.

Weitere Informationen finden Sie in Bestätigungen für Nachrichten. In manchen Anwendungsfällen stellt dies nicht unbedingt ein Problem dar. Wenn der Verlust von Nachrichten jedoch in keinem Fall akzeptabel ist, ziehen Sie andere Strategien in Betracht, wie beispielsweise die Verwendung eines Clusters mit mehreren Verfügbarkeitszonen, einer regionsübergreifenden Replikation oder eines producerseitigen Prüfpunktverfahrens für Nachrichten.

Weitere Informationen finden Sie in Cluster mit einer einzelnen Zone und Cluster mit mehreren Zonen.