Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Die wichtigsten Funktionen und Konzepte von Amazon MSK
Von Amazon MSK bereitgestellte Cluster bieten eine Vielzahl von Funktionen und Fähigkeiten, mit denen Sie die Leistung Ihres Clusters optimieren und Ihre Streaming-Anforderungen erfüllen können. In den folgenden Themen werden diese Funktionen detailliert beschrieben.
+ Die [AWS-Managementkonsole](https://console.aws.amazon.com/msk)
+ Die [API-Referenz für Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference)
+ Die [Befehlsreferenz für die Amazon-MSK-CLI](https://docs.aws.amazon.com/cli/latest/reference/kafka/index.html)
**Topics**
+ [Amazon-MSK-Brokertypen](broker-instance-types.md)
+ [Amazon-MSK-Brokergrößen](broker-instance-sizes.md)
+ [Speicherverwaltung für Standard-Broker](msk-storage-management.md)
+ [Bereitgestellte Amazon MSK-Konfiguration](msk-configuration.md)
+ [Intelligentes Rebalancing für Cluster](intelligent-rebalancing.md)
+ [Patchen auf von MSK bereitgestellten Clustern](patching-impact.md)
+ [Broker offline und Client-Failover](troubleshooting-offlinebroker-clientfailover.md)
+ [Sicherheit in Amazon MSK](security.md)
+ [Amazon MSK-Protokollierung](msk-logging.md)
+ [Verwaltung von Metadaten](metadata-management.md)
+ [Thema Operationen](msk-topic-operations-information.md)
+ [Amazon-MSK-Ressourcen](resources.md)
+ [Apache-Kafka-Versionen](kafka-versions.md)
+ [Problembehandlung bei Ihrem Amazon MSK-Cluster](troubleshooting.md)
# Amazon-MSK-Brokertypen
MSK Provisioned bietet zwei Brokertypen an: Standard und Express. Standardbroker bieten Ihnen die größte Flexibilität bei der Konfiguration Ihrer Cluster, während Express-Broker mehr Elastizität, Durchsatz und Stabilität bieten und ease-of-use leistungsfähige Streaming-Anwendungen ausführen können.
In den folgenden Themen finden Sie weitere Informationen zu den einzelnen Angeboten. In der folgenden Tabelle wird auch der Vergleich der wichtigsten Funktionen zwischen Standard- und Express-Brokern hervorgehoben.
| Feature | Standardbroker | Express-Broker |
| --- | --- | --- |
| [Speicherverwaltung](msk-storage-management.md) | Vom Kunden verwaltet (zu den Funktionen gehören EBS-Speicher, Tiered Storage, Durchsatz für bereitgestellten Speicher, automatische Skalierung, Speicherkapazitätswarnungen) | Vollständig über MSK verwaltet |
| [Unterstützte Instanzen](broker-instance-sizes.md) | T3, M5, M7g | M7g |
| [Überlegungen zur Dimensionierung und Skalierung](bestpractices-intro.md) | Durchsatz, Verbindungen, Partitionen, Speicher | Durchsatz, Verbindungen, Partitionen |
| [Broker-Skalierung](msk-update-broker-count.md) | Vertikale und horizontale Skalierung | Vertikale und horizontale Skalierung |
| [Kafka-Versionen](kafka-versions.md) | Siehe [Apache-Kafka-Versionen](kafka-versions.md) | Beginnt mit Version 3.6 |
| [Apache-Kafka-Konfiguration](msk-configuration.md) | Noch konfigurierbarer | Meist wurde MSK für eine höhere Belastbarkeit gesorgt |
| [Sicherheit](security.md) | Verschlüsselung, Private/Public Zugriff, Authentifizierung und Autorisierung — IAM, SASL/SCRAM, mTLS, Klartext, Kafka ACLs | Verschlüsselung, Private/Public Zugriff, Authentifizierung und Autorisierung — IAM, SASL/SCRAM, mTLS, Klartext, Kafka ACLs |
| [Überwachung](monitoring.md) | CloudWatch, Überwachung öffnen | CloudWatch, Überwachung öffnen |
**Anmerkung**
Sie können einen von MSK bereitgestellten Cluster nicht von einem Standard-Brokertyp in einen Express-Brokertyp ändern, indem Sie den Brokertyp mithilfe der MSK-API ändern. Sie müssen einen neuen Cluster mit dem gewünschten Brokertyp (Standard oder Express) erstellen.
**Topics**
+ [Amazon MSK Standard-Makler](msk-broker-types-standard.md)
+ [Amazon MSK Express-Broker](msk-broker-types-express.md)
# Amazon MSK Standard-Makler
Standardbroker für MSK Provisioned bieten die größte Flexibilität bei der Konfiguration der Leistung Ihres Clusters. Sie können aus einer Vielzahl von Clusterkonfigurationen wählen, um die für Ihre Anwendungen erforderlichen Verfügbarkeits-, Haltbarkeits-, Durchsatz- und Latenzeigenschaften zu erreichen. Sie können auch Speicherkapazität bereitstellen und diese nach Bedarf erhöhen. Amazon MSK kümmert sich um die Hardwarewartung von Standard-Brokern und angeschlossenen Speicherressourcen und behebt automatisch eventuell auftretende Hardwareprobleme. [In diesem Dokument finden Sie weitere Informationen zu verschiedenen Themen im Zusammenhang mit Standard-Brokern, einschließlich Themen zur [Speicherverwaltung](msk-storage-management.md), [Konfiguration](msk-configuration-standard.md) und Wartung.](patching-impact.md#patching-standard-brokers)
# Amazon MSK Express-Broker
Express-Broker für MSK Provisioned sorgen dafür, dass Apache Kafka einfacher zu verwalten, kostengünstiger und skalierbarer ist und bei der erwarteten niedrigen Latenz elastischer ist. Broker bieten pay-as-you-go Speicher, der automatisch skaliert wird und für den weder Größe noch Bereitstellung noch proaktive Überwachung erforderlich sind. Abhängig von der ausgewählten Instance-Größe kann jeder Broker-Knoten im Vergleich zu standardmäßigen Apache Kafka-Brokern bis zu dreimal mehr Durchsatz pro Broker bieten, bis zu 20-mal schneller skalieren und 90% schneller wiederherstellen. Express-Broker sind mit den Best-Practice-Standardeinstellungen von Amazon MSK vorkonfiguriert und setzen Kundendurchsatzquoten durch, um Ressourcenkonflikte zwischen Kunden und den Hintergrundoperationen von Kafka zu minimieren.
Im Folgenden sind einige wichtige Faktoren und Funktionen aufgeführt, die Sie bei der Verwendung von Express-Brokern berücksichtigen sollten.
+ **Kein Speichermanagement**: Express-Broker machen die [Bereitstellung oder Verwaltung von Speicherressourcen](msk-storage-management.md) überflüssig. Sie erhalten elastischen, praktisch unbegrenzten und vollständig verwalteten Speicher. pay-as-you-go Bei Anwendungsfällen mit hohem Durchsatz müssen Sie sich keine Gedanken über die Interaktionen zwischen Recheninstanzen und Speichervolumes und die damit verbundenen Durchsatzengpässe machen. Diese Funktionen vereinfachen die Clusterverwaltung und reduzieren den betrieblichen Mehraufwand bei der Speicherverwaltung.
+ **Schnellere Skalierung**: Mit Express-Brokern können Sie Ihren Cluster skalieren und Partitionen bis zu 20-mal schneller verschieben als mit Standard-Brokern. Diese Funktion ist entscheidend, wenn Sie Ihren Cluster skalieren müssen, um bevorstehende Lastspitzen zu bewältigen, oder wenn Sie Ihren Cluster skalieren müssen, um die Kosten zu senken. Weitere Informationen zur Skalierung [Ihres Clusters finden Sie in den Abschnitten zur Erweiterung Ihres Clusters](msk-update-broker-count.md), [zum Entfernen von Brokern](msk-remove-broker.md), [zum [Neuzuweisen von Partitionen](msk-update-broker-type.md) und zum Einrichten LinkedIn des Tempomats für das Rebalancing](cruise-control.md).
+ **Höherer Durchsatz**: Express-Broker bieten bis zu dreimal mehr Durchsatz pro Broker als Standard-Broker. Beispielsweise können Sie MBps mit jedem Express-Broker der Größe m7g.16xlarge problemlos Daten bis zu 500 schreiben, verglichen mit 153,8 MBps beim entsprechenden Standard-Broker (beide Zahlen setzen eine ausreichende Bandbreitenzuweisung für Hintergrundvorgänge wie Replikation und Neuverteilung voraus).
+ **Für hohe Ausfallsicherheit konfiguriert**: Express-Broker bieten automatisch verschiedene bewährte Methoden zur Verbesserung der Ausfallsicherheit Ihres Clusters. Dazu gehören Sicherheitsvorkehrungen für kritische Apache Kafka-Konfigurationen, Durchsatzquoten und Kapazitätsreservierungen für Hintergrundoperationen und ungeplante Reparaturen. Diese Funktionen machen es sicherer und einfacher, große Apache Kafka-Anwendungen auszuführen. Weitere Informationen finden Sie in den Abschnitten über [Express-Broker-Konfigurationen](msk-configuration-express.md) und[Kontingent für Amazon MSK Express-Broker](limits.md#msk-express-quota).
+ **Keine Wartungsfenster**: Es gibt keine Wartungsfenster für Express-Broker. Amazon MSK aktualisiert Ihre Cluster-Hardware automatisch und fortlaufend. Weitere Informationen finden Sie unter [Patching für Express-Broker](https://docs.aws.amazon.com/msk/latest/developerguide/patching-impact.html#patching-express-brokers).
## Zusätzliche Informationen zu Express-Brokern
+ Express-Broker arbeiten mit Apache Kafka APIs, unterstützen die KStreams API jedoch noch nicht vollständig.
+ Express-Broker sind nur in einer AZs 3-Konfiguration verfügbar.
+ Express-Broker sind nur für ausgewählte Instance-Größen verfügbar. Die aktualisierte Liste finden Sie unter [Amazon MSK-Preise](https://aws.amazon.com/msk/pricing/).
+ Express-Broker werden in den folgenden Apache Kafka-Versionen unterstützt: 3.6, 3.8 und 3.9.
+ Express-Broker können ab Apache Kafka Version 3.9 KRaft im Modus erstellt werden.
**Sehen Sie sich diese Blogs an**
Weitere Informationen zu MSK Express-Brokern und ein Beispiel aus der Praxis für den Einsatz von Express-Brokern finden Sie in den folgenden Blogs:
[Wir stellen Express-Broker für Amazon MSK vor, um einen hohen Durchsatz und eine schnellere Skalierung für Ihre Kafka-Cluster zu bieten](https://aws.amazon.com/blogs/aws/introducing-express-brokers-for-amazon-msk-to-deliver-high-throughput-and-faster-scaling-for-your-kafka-clusters/)
[Express Brokers für Amazon MSK: Turboschnelle Kafka-Skalierung mit bis zu 20-mal schnellerer Leistung](https://aws.amazon.com/blogs/big-data/express-brokers-for-amazon-msk-turbo-charged-kafka-scaling-with-up-to-20-times-faster-performance/)
In diesem Blog wird gezeigt, wie Express-Broker:
Sorgen Sie für einen schnelleren Durchsatz, eine schnelle Skalierung und eine kürzere Wiederherstellungszeit nach Ausfällen
Eliminieren Sie die Komplexität des Speichermanagements
# Amazon-MSK-Brokergrößen
Wenn Sie einen von Amazon MSK bereitgestellten Cluster erstellen, geben Sie die Größe der Broker an, die er haben soll. Je nach [Brokertyp](broker-instance-types.md) unterstützt Amazon MSK die folgenden Brokergrößen.
**Standardgrößen für Makler**
+ kafka.t3.small
+ kafka.m5.large, kafka.m5.xlarge, kafka.m5.2xlarge, kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge, kafka.m5.24xlarge
+ kafka.m7g.large, kafka.m7g.xlarge, kafka.m7g.2xlarge, kafka.m7g.4xlarge, kafka.m7g.8xlarge, kafka.m7g.12xlarge, kafka.m7g.12xlarge, kafka.m7g.16xlarge
**Größen für Express-Broker**
+ express.m7g.large, express.m7g.xlarge, express.m7g.2xlarge, express.m7g.4xlarge, express.m7g.8xlarge, express.m7g.12xlarge, express.m7g.12xlarge, express.m7g.16xlarge
**Anmerkung**
Einige Broker-Größen sind in bestimmten Regionen möglicherweise nicht verfügbar. AWS Die aktuelle Liste der verfügbaren Instances nach Regionen finden Sie in den aktualisierten [Broker-Instance-Preistabellen auf der Amazon MSK-Preisseite](https://aws.amazon.com/msk/pricing/).
## Weitere Hinweise zu Broker-Größen
+ M7g-Broker verwenden AWS Graviton-Prozessoren (kundenspezifische ARM-basierte Prozessoren, die von Amazon Web Services entwickelt wurden). M7g-Broker bieten im Vergleich zu vergleichbaren M5-Instances ein besseres Preis-Leistungs-Verhältnis. M7g-Broker verbrauchen weniger Strom als vergleichbare M5-Instances.
+ Amazon MSK unterstützt M7G-Broker auf von MSK bereitgestellten Clustern, auf denen Kafka-Versionen 2.8.2 und 3.3.2 und höher ausgeführt werden.
+ M7g- und M5-Broker bieten eine höhere Ausgangsdurchsatzleistung als T3-Broker und werden für Produktionsworkloads empfohlen. M7g- und M5-Broker können auch mehr Partitionen pro Broker haben als T3-Broker. Verwenden Sie M7g- oder M5-Broker, wenn Sie größere produktionstaugliche Workloads ausführen oder eine größere Anzahl von Partitionen benötigen. Weitere Informationen zu den Instance-Größen M7g und M5 finden Sie unter [Amazon EC2 General](https://aws.amazon.com/ec2/instance-types/) Purpose Instances.
+ T3-Broker haben die Möglichkeit, CPU-Guthaben zu verwenden, um die Leistung vorübergehend zu steigern. Verwenden Sie T3-Broker für eine kostengünstige Entwicklung, wenn Sie kleine bis mittlere Streaming-Workloads testen oder Streaming-Workloads mit niedrigem Durchsatz haben, bei denen temporäre Spitzen auftreten. Wir empfehlen Ihnen, einen proof-of-concept Test durchzuführen, um festzustellen, ob T3-Broker für die Produktion oder kritische Workloads ausreichend sind. Weitere Informationen zu den Größen von T3-Brokern finden Sie unter [Amazon EC2 T3-Instances](https://aws.amazon.com/ec2/instance-types/t3/).
Weitere Informationen zur Auswahl der Broker-Größen finden Sie unter. [Bewährte Methoden für Standard- und Express-Broker](bestpractices-intro.md)
# Speicherverwaltung für Standard-Broker
Amazon MSK bietet Features, die Sie bei der Speicherverwaltung auf Ihren MSK-Clustern unterstützen.
**Anmerkung**
Mit [Express Brokers](msk-broker-types-express.md) müssen Sie keine Speicherressourcen bereitstellen oder verwalten, die für Ihre Daten verwendet werden. Dies vereinfacht die Clusterverwaltung und beseitigt eine der häufigsten Ursachen für Betriebsprobleme bei Apache Kafka-Clustern. Sie geben auch weniger aus, da Sie keine ungenutzte Speicherkapazität bereitstellen müssen und nur für das zahlen, was Sie tatsächlich nutzen.
**Standardmaklertyp**
Bei [Standard-Brokern](msk-broker-types-standard.md) können Sie aus einer Vielzahl von Speicheroptionen und -funktionen wählen. Amazon MSK bietet Features, die Sie bei der Speicherverwaltung auf Ihren MSK-Clustern unterstützen.
Informationen zur Verwaltung des Durchsatzes finden Sie unter[Bereitstellung von Speicherdurchsatz für Standard-Broker in einem Amazon MSK-Cluster](msk-provision-throughput.md).
**Topics**
+ [Mehrstufiger Speicher für Standard-Broker](msk-tiered-storage.md)
+ [Skalieren Sie den Brokerspeicher von Amazon MSK Standard](msk-update-storage.md)
+ [Speicherdurchsatz für Standard-Broker in einem Amazon MSK-Cluster verwalten](msk-provision-throughput-management.md)
# Mehrstufiger Speicher für Standard-Broker
Gestaffelte Speicherung ist eine kostengünstige Speicherstufe für Amazon MSK, die auf praktisch unbegrenzten Speicherplatz skaliert werden kann, sodass Streaming-Datenanwendungen kostengünstig erstellt werden können.
Sie können einen Amazon-MSK-Cluster erstellen, der mit gestaffeltem Speicher konfiguriert ist, der ein ausgewogenes Verhältnis zwischen Leistung und Kosten bietet. Amazon MSK speichert Streaming-Daten auf einer leistungsoptimierten primären Speicherebene, bis die Aufbewahrungsgrenzen für Apache-Kafka-Themen erreicht sind. Anschließend verschiebt Amazon MSK Daten automatisch in die neue kostengünstige Speicherstufe.
Wenn Ihre Anwendung beginnt, Daten aus dem gestaffelten Speicher zu lesen, können Sie mit einer Erhöhung der Leselatenz für die ersten paar Bytes rechnen. Wenn Sie beginnen, die verbleibenden Daten sequentiell aus der kostengünstigen Stufe zu lesen, können Sie mit Latenzen rechnen, die denen der primären Speicherstufe ähneln. Sie müssen keinen Speicher für die kostengünstige gestaffelte Speicherung bereitstellen oder die Infrastruktur verwalten. Sie können beliebig viele Daten speichern und nur für das bezahlen, was Sie tatsächlich nutzen. Diese Funktion ist kompatibel mit dem in [KIP-405 APIs eingeführten Feature: Kafka Tiered Storage](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage).
Informationen zur Dimensionierung, Überwachung und Optimierung Ihres MSK Tiered Storage-Clusters finden Sie unter [Bewährte Methoden für die Ausführung von Produktionsworkloads mit Amazon MSK](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/) Tiered Storage.
Im Folgenden sind einige Funktionen der gestaffelten Speicherung aufgeführt:
+ Sie können auf praktisch unbegrenzten Speicherplatz skalieren. Sie müssen nicht raten, wie Sie Ihre Apache-Kafka-Infrastruktur skalieren können.
+ Sie können Daten in Ihren Apache-Kafka-Themen länger aufbewahren oder Ihren Themenspeicher vergrößern, ohne die Anzahl der Broker erhöhen zu müssen.
+ Es bietet einen längeren Sicherheitspuffer, um unerwartete Verzögerungen bei der Verarbeitung zu bewältigen.
+ Sie können alte Daten in der exakten Produktionsreihenfolge mit Ihrem vorhandenen Stream-Verarbeitungscode und Kafka erneut verarbeiten. APIs
+ Partitionen können schneller wieder ausgeglichen werden, da Daten auf sekundärem Speicher nicht zwischen Broker-Festplatten repliziert werden müssen.
+ Daten werden zwischen Brokern und dem gestaffelten Speicher innerhalb der VPC bewegt und nicht über das Internet übertragen.
+ Ein Client-Computer kann zum Herstellen einer Verbindung zu neuen Clustern mit aktivierter gestaffelter Speicherung den gleichen Prozess wie zum Herstellen einer Verbindung zu einem Cluster ohne aktivierte gestaffelte Speicherung verwenden. Siehe [Erstellen eines Client-Computers](https://docs.aws.amazon.com/msk/latest/developerguide/create-client-machine.html).
## Mehrstufige Speicheranforderungen für Amazon MSK-Cluster
+ Sie müssen den Apache-Kafka-Client Version 3.0.0 oder höher verwenden, um ein neues Thema mit aktivierter gestaffelter Speicherung zu erstellen. Um ein vorhandenes Thema auf gestaffelte Speicherung umzustellen, können Sie einen Client-Computer neu konfigurieren, der eine Kafka-Client-Version unter 3.0.0 verwendet (die unterstützte Apache-Kafka-Version ist mindestens 2.8.2.tiered), um die gestaffelte Speicherung zu aktivieren. Siehe [Schritt 4: Erstellen Sie ein Thema im Amazon MSK-Cluster](create-topic.md).
+ Der Amazon MSK-Cluster mit aktiviertem Tiered Storage muss Version 3.6.0 oder höher oder 2.8.2. Tiered verwenden.
## Mehrstufige Speicherbeschränkungen und Einschränkungen für Amazon MSK-Cluster
Für die gestaffelte Speicherung gelten die folgenden Einschränkungen und Limits:
+ Stellen Sie sicher, dass Clients `read_committed` beim Lesen von remote\$1tier in Amazon MSK nicht so konfiguriert sind, es sei denn, die Anwendung verwendet die Transaktionsfunktion aktiv.
+ Tiered Storage ist in AWS GovCloud Regionen (USA) nicht verfügbar.
+ Die gestaffelte Speicherung gilt nur für Cluster im Bereitstellungsmodus.
+ Mehrstufiger Speicher unterstützt die Brokergröße t3.small nicht.
+ Die Mindestaufbewahrungsdauer bei kostengünstiger Speicherung beträgt 3 Tage. Es gibt keine Mindestaufbewahrungsdauer für den Primärspeicher.
+ Die gestaffelte Speicherung unterstützt nicht mehrere Protokollverzeichnisse auf einem Broker (JBOD-bezogene Funktionen).
+ Mehrstufiger Speicher unterstützt keine komprimierten Themen. Stellen Sie sicher, dass bei allen Themen, für die Tiered Storage aktiviert ist, die cleanup.policy nur auf „DELETE“ konfiguriert ist.
+ Das Ändern der log.cleanup.policy-Richtlinie für ein Thema nach dessen Erstellung wird vom Tiered Storage-Cluster nicht unterstützt.
+ Tiered Storage kann für einzelne Themen deaktiviert werden, jedoch nicht für den gesamten Cluster. Nach der Deaktivierung kann die gestaffelte Speicherung für ein Thema nicht wieder aktiviert werden.
+ Wenn Sie Amazon MSK Version 2.8.2.tiered verwenden, können Sie nur zu einer anderen von Tiered Storage unterstützten Apache Kafka-Version migrieren. Wenn Sie eine von Tiered Storage unterstützte Version nicht weiter verwenden möchten, erstellen Sie einen neuen MSK-Cluster und migrieren Sie Ihre Daten dorthin.
+ Das kafka-log-dirs Tool kann die Größe von Tiered Storage-Daten nicht melden. Das Tool meldet nur die Größe der Protokollsegmente im Primärspeicher.
Informationen zu Standardeinstellungen und Einschränkungen, die Sie bei der Konfiguration von Tiered Storage auf Themenebene beachten müssen, finden Sie unter. [Richtlinien für die Konfiguration von Amazon MSK Tiered Storage auf Themenebene](msk-guidelines-tiered-storage-topic-level-config.md)
# So werden Protokollsegmente für ein Amazon MSK-Thema in den mehrstufigen Speicher kopiert
Wenn Sie gestaffelte Speicherung für ein neues oder vorhandenes Thema aktivieren, kopiert Apache Kafka geschlossene Protokollsegmente vom Primärspeicher in den gestaffelten Speicher.
+ Apache Kafka kopiert nur geschlossene Protokollsegmente. Es kopiert alle Nachrichten innerhalb des Protokollsegments in einen gestaffelten Speicher.
+ Aktive Segmente kommen nicht für gestaffelte Speicherung in Frage. Die Größe des Protokollsegments (segment.bytes) oder die Segment-Rollzeit (segment.ms) steuern die Geschwindigkeit, mit der Segmente geschlossen werden, und die Geschwindigkeit, mit der Apache Kafka sie anschließend in den gestaffelten Speicher kopiert.
Die Aufbewahrungseinstellungen für ein Thema mit aktivierter gestaffelter Speicherung unterscheiden sich von den Einstellungen für ein Thema ohne aktivierte gestaffelte Speicherung. Die folgenden Regeln steuern die Aufbewahrung von Nachrichten in Themen, für die gestaffelte Speicherung aktiviert ist:
+ Sie definieren die Aufbewahrung in Apache Kafka mit zwei Einstellungen: log.retention.ms (Zeit) und log.retention.bytes (Größe). Diese Einstellungen bestimmen die Gesamtdauer und Größe der Daten, die Apache Kafka im Cluster aufbewahrt. Unabhängig davon, ob Sie den gestaffelten Speichermodus aktivieren oder nicht, legen Sie diese Konfigurationen auf Cluster-Ebene fest. Sie können die Einstellungen auf Themenebene mit Themenkonfigurationen überschreiben.
+ Wenn Sie die gestaffelte Speicherung aktivieren, können Sie zusätzlich angeben, wie lange die primäre Hochleistungs-Speicherebene Daten speichert. Wenn für ein Thema beispielsweise die Einstellung für die gesamte Aufbewahrung (log.retention.ms) von 7 Tagen und die lokale Aufbewahrung (local.retention.ms) für 12 Stunden festgelegt ist, speichert der primäre Speicher des Clusters Daten nur für die ersten 12 Stunden. Bei der kostengünstigen Speicherstufe werden die Daten für die gesamten 7 Tage aufbewahrt.
+ Die üblichen Aufbewahrungseinstellungen gelten für das gesamte Protokoll. Dazu gehören auch die gestaffelten und die primären Komponenten.
+ Die Einstellungen local.retention.ms oder local.retention.bytes steuern die Aufbewahrung von Nachrichten im Primärspeicher. Apache Kafka kopiert geschlossene Protokollsegmente in den mehrstufigen Speicher, sobald sie geschlossen werden (basierend auf segment.bytes oder segment.ms), unabhängig von den lokalen Aufbewahrungseinstellungen. Nachdem Segmente in den mehrstufigen Speicher kopiert wurden, verbleiben sie im Primärspeicher, bis die Schwellenwerte local.retention.ms oder local.retention.bytes erreicht sind. Zu diesem Zeitpunkt werden die Daten aus dem Primärspeicher gelöscht, sind aber weiterhin im mehrstufigen Speicher verfügbar. Auf diese Weise können Sie aktuelle Daten auf einem Hochleistungs-Primärspeicher speichern, um schnell darauf zugreifen zu können, während ältere Daten über den kostengünstigen mehrstufigen Speicher bereitgestellt werden.
+ Wenn Apache Kafka eine Nachricht in einem Protokollsegment in einen gestaffelten Speicher kopiert, entfernt es die Nachricht auf der Grundlage der Einstellungen retention.ms oder retention.bytes aus dem Cluster.
## Beispiel für ein mehrstufiges Speicherszenario von Amazon MSK
Dieses Szenario veranschaulicht, wie sich ein vorhandenes Thema, das Nachrichten im Primärspeicher enthält, verhält, wenn gestaffelte Speicherung aktiviert ist. Sie aktivieren die gestaffelte Speicherung zu diesem Thema, indem Sie remote.storage.enable auf `true` setzen. In diesem Beispiel ist retention.ms auf 5 Tage und local.retention.ms auf 2 Tage festgelegt. Im Folgenden ist die Reihenfolge der Ereignisse dargestellt, wenn ein Segment abläuft.
**Zeitpunkt T0 - Bevor Sie die gestaffelte Speicherung aktivieren.**
Bevor Sie die gestaffelte Speicherung für dieses Thema aktivieren, gibt es zwei Protokollsegmente. Eines der Segmente ist für eine bestehende Themenpartition 0 aktiv.
![\[Zeitpunkt T0 - Bevor Sie die gestaffelte Speicherung aktivieren.\]](http://docs.aws.amazon.com/de_de/msk/latest/developerguide/images/tiered-storage-segments-1.png)
**Zeitpunkt T1 (< 2 Tage) - gestaffelte Speicherung aktiviert. Segment 0 wurde in den gestaffelten Speicher kopiert.**
Nachdem Sie Tiered Storage für dieses Thema aktiviert haben, kopiert Apache Kafka das geschlossene Protokollsegment 0 in den mehrstufigen Speicher, sobald es geschlossen wird. Das Segment wird auf der Grundlage der Einstellungen von segment.bytes oder segment.ms geschlossen, nicht auf der Grundlage der Aufbewahrungseinstellungen. Apache Kafka behält auch eine Kopie im Primärspeicher. Das aktive Segment 1 kann noch nicht in den mehrstufigen Speicher kopiert werden, da es immer noch aktiv ist und nicht geschlossen wurde. In dieser Zeitleiste wendet Amazon MSK noch keine der Aufbewahrungseinstellungen für Nachrichten in Segment 0 und Segment 1 an. (local.retention). bytes/ms, retention.ms/bytes)
![\[Zeitpunkt T1 (< 2 Tage) - gestaffelte Speicherung aktiviert. Segment 0 wurde in den gestaffelten Speicher kopiert.\]](http://docs.aws.amazon.com/de_de/msk/latest/developerguide/images/tiered-storage-segments-2.png)
**Zeitpunkt T2 – Die lokale Aufbewahrung ist wirksam.**
Nach 2 Tagen ist der lokale Aufbewahrungsschwellenwert für Segment 0 erreicht. Dies wird durch die Einstellung von local.retention.ms auf 2 Tage festgelegt. Segment 0 wurde jetzt aus dem Primärspeicher gelöscht, ist aber weiterhin im mehrstufigen Speicher verfügbar. Beachten Sie, dass Segment 0 bereits zum Zeitpunkt T1, als es geschlossen wurde, in den mehrstufigen Speicher kopiert wurde, und nicht zum Zeitpunkt T2, als die lokale Aufbewahrung abgelaufen war. Das aktive Segment 1 kann noch nicht gelöscht oder in den mehrstufigen Speicher kopiert werden, da es immer noch aktiv ist.
![\[Zeitpunkt T2 - Die lokale Aufbewahrung ist wirksam.\]](http://docs.aws.amazon.com/de_de/msk/latest/developerguide/images/tiered-storage-segments-3.png)
**Zeitpunkt T3 - Die gesamte Aufbewahrung ist wirksam.**
Nach 5 Tagen werden die Aufbewahrungseinstellungen wirksam, und Kafka löscht das Protokollsegment 0 und die zugehörigen Nachrichten aus dem gestaffelten Speicher. Segment 1 ist noch nicht ablauffähig und kann auch nicht in den gestaffelten Speicher kopiert werden, da es noch aktiv ist. Segment 1 ist noch nicht geschlossen und kommt daher nicht für Segment-Rolling in Frage.
![\[Zeitpunkt T3 - Die gesamte Aufbewahrung ist wirksam.\]](http://docs.aws.amazon.com/de_de/msk/latest/developerguide/images/tiered-storage-segments-4.png)
# Erstellen Sie einen Amazon MSK-Cluster mit mehrstufigem Speicher mit dem AWS-Managementkonsole
Dieser Prozess beschreibt, wie Sie mithilfe des einen mehrstufigen Speicher-Amazon MSK-Cluster erstellen. AWS-Managementkonsole
1. Öffnen Sie die Amazon-MSK-Konsole unter [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Wählen Sie **Cluster erstellen**.
1. Wählen Sie **Benutzerdefiniert erstellen** für die gestaffelte Speicherung.
1. Geben Sie einen Namen für den Cluster ein.
1. Wählen Sie unter **Cluster-Typ** die Option **Bereitgestellt** aus.
1. Wählen Sie eine Amazon-Kafka-Version aus, welche die gestaffelte Speicherung für Amazon MSK zur Erstellung des Clusters unterstützt.
1. **Geben Sie eine andere Broker-Größe als kafka.t3.small an.**
1. Geben Sie die Anzahl der Broker an, die Amazon MSK in jeder Availability Zone erstellen soll. Mindestens ist ein Broker pro Availability Zone erforderlich und maximal sind 30 Broker pro Cluster möglich.
1. Geben Sie die Anzahl der Zonen an, auf die Broker verteilt sind.
1. Geben Sie die Anzahl der Apache-Kafka-Broker an, die pro Zone bereitgestellt werden.
1. Wählen Sie **Speicheroptionen**. Dazu gehören **Tiered Storage und EBS Storage** zur Aktivierung des gestaffelten Speichermodus.
1. Führen Sie die restlichen Schritte im Cluster-Erstellungsassistenten aus. Wenn der Vorgang abgeschlossen ist, werden **Tiered Storage und EBS Storage** in der Ansicht **Überprüfen und Erstellen** als Cluster-Speichermodus angezeigt.
1. Wählen Sie **Cluster erstellen** aus.
# Erstellen Sie einen Amazon MSK-Cluster mit mehrstufigem Speicher mit dem AWS CLI
Um die gestaffelte Speicherung auf einem Cluster zu aktivieren, erstellen Sie den Cluster mit der richtigen Apache-Kafka-Version und dem richtigen Attribut für gestaffelte Speicherung. Folgen Sie dem folgenden Codebeispiel. Führen Sie außerdem die im nächsten Abschnitt beschriebenen Schritte aus, um [Erstellen Sie ein Kafka-Thema mit aktiviertem Tiered Storage mit AWS CLI](#msk-create-topic-tiered-storage-cli).
Eine vollständige Liste der unterstützten Attribute für die Cluster-Erstellung finden Sie unter [create-cluster](https://docs.aws.amazon.com//cli/latest/reference/kafka/create-cluster.html).
```
aws kafka create-cluster \
—cluster-name "MessagingCluster" \
—broker-node-group-info file://brokernodegroupinfo.json \
—number-of-broker-nodes 3 \
--kafka-version "3.6.0" \
--storage-mode "TIERED"
```
## Erstellen Sie ein Kafka-Thema mit aktiviertem Tiered Storage mit AWS CLI
Um den Prozess abzuschließen, den Sie bei der Erstellung eines Clusters mit aktivierter gestaffelter Speicherung gestartet haben, erstellen Sie auch ein Thema mit aktivierter gestaffelter Speicherung mit den Attributen aus dem späteren Codebeispiel. Die spezifischen Attribute für die gestaffelte Speicherung lauten wie folgt:
+ `local.retention.ms` (z. B. 10 Minuten) für zeitbasierte Aufbewahrungseinstellungen oder `local.retention.bytes` für Größenbeschränkungen für Protokollsegmente.
+ `remote.storage.enable` auf `true` gesetzt, um die gestaffelte Speicherung zu aktivieren.
Die folgende Konfiguration verwendet local.retention.ms, aber Sie können dieses Attribut durch local.retention.bytes ersetzen. Dieses Attribut steuert die Zeit, die vergehen kann, oder die Anzahl der Byte, die Apache Kafka kopieren kann, bevor Apache Kafka die Daten vom Primärspeicher in den gestaffelten Speicher kopiert. Weitere Informationen zu den unterstützten Konfigurationsattributen finden Sie unter [Konfiguration auf Themenebene](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration).
**Anmerkung**
Sie müssen den Apache-Kafka-Client Version 3.0.0 und höher verwenden. Diese Versionen unterstützen die Einstellung `remote.storage.enable` nur in diesen Client-Versionen von `kafka-topics.sh`. Informationen zur Aktivierung der gestaffelten Speicherung für ein vorhandenes Thema, das eine frühere Version von Apache Kafka verwendet, finden Sie im Abschnitt [Tiered Storage für ein vorhandenes Amazon MSK-Thema aktivieren](msk-enable-disable-topic-tiered-storage-cli.md#msk-enable-topic-tiered-storage-cli).
```
bin/kafka-topics.sh --create --bootstrap-server $bs --replication-factor 2 --partitions 6 --topic MSKTutorialTopic --config remote.storage.enable=true --config local.retention.ms=100000 --config retention.ms=604800000 --config segment.bytes=134217728
```
# Tiered Storage für ein vorhandenes Amazon MSK-Thema aktivieren und deaktivieren
In diesen Abschnitten wird beschrieben, wie Sie die gestaffelte Speicherung für ein Thema aktivieren und deaktivieren, das Sie bereits erstellt haben. Informationen zum Erstellen eines neuen Clusters und Themas mit aktiviertem gestaffelten Speicher finden Sie unter [Erstellen eines Clusters mit gestaffeltem Speicher mithilfe der AWS-Managementkonsole](https://docs.aws.amazon.com//msk/latest/developerguide/msk-create-cluster-tiered-storage-console).
## Tiered Storage für ein vorhandenes Amazon MSK-Thema aktivieren
Verwenden Sie die `alter`-Befehlssyntax im folgenden Beispiel, um die gestaffelte Speicherung für ein vorhandenes Thema zu aktivieren. Wenn Sie die gestaffelte Speicherung für ein bereits vorhandenes Thema aktivieren, sind Sie nicht auf eine bestimmte Apache-Kafka-Client-Version beschränkt.
```
bin/kafka-configs.sh --bootstrap-server $bsrv --alter --entity-type topics --entity-name msk-ts-topic --add-config 'remote.storage.enable=true, local.retention.ms=604800000, retention.ms=15550000000'
```
## Tiered Storage für ein vorhandenes Amazon MSK-Thema deaktivieren
Um die gestaffelte Speicherung für ein vorhandenes Thema zu deaktivieren, verwenden Sie die `alter`-Befehlssyntax in derselben Reihenfolge wie bei der Aktivierung der gestaffelten Speicherung.
```
bin/kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name MSKTutorialTopic --add-config 'remote.log.msk.disable.policy=Delete, remote.storage.enable=false'
```
**Anmerkung**
Wenn Sie die gestaffelte Speicherung deaktivieren, löschen Sie die Themendaten in der gestaffelten Speicherung vollständig. Apache Kafka behält primäre Speicherdaten bei, wendet aber weiterhin die primären Aufbewahrungsregeln anhand von `local.retention.ms` an. Wenn Sie die gestaffelte Speicherung für ein Thema deaktiviert haben, können Sie sie nicht erneut aktivieren. Wenn Sie die gestaffelte Speicherung für ein bereits vorhandenes Thema deaktivieren, sind Sie nicht auf eine bestimmte Apache-Kafka-Client-Version beschränkt.
# Tiered Storage auf einem vorhandenen Amazon MSK-Cluster mithilfe der CLI aktivieren AWS
**Anmerkung**
Sie können die gestaffelte Speicherung nur aktivieren, wenn die log.cleanup.policy Ihres Clusters auf `delete` eingestellt ist, da komprimierte Themen bei der gestaffelten Speicherung nicht unterstützt werden. Später können Sie die log.cleanup.policy eines einzelnen Themas auf `compact` konfigurieren, wenn die gestaffelte Speicherung für dieses bestimmte Thema nicht aktiviert ist. Weitere Informationen zu den unterstützten Konfigurationsattributen finden Sie unter [Konfiguration auf Themenebene](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration).
1. **Die Kafka-Version aktualisieren** – Cluster-Versionen sind keine einfachen Ganzzahlen. Verwenden Sie den Befehl `DescribeCluster` operation oder den `describe-cluster` AWS CLI-Befehl, um die aktuelle Version des Clusters zu ermitteln. `KTVPDKIKX0DER` ist ein Beispiel für eine Version.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version 3.6.0
```
1. Den Cluster-Speichermodus bearbeiten. Das folgende Codebeispiel zeigt die Bearbeitung des Cluster-Speichermodus auf `TIERED` mithilfe der [https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html)-API.
```
aws kafka update-storage --current-version Current-Cluster-Version --cluster-arn Cluster-arn --storage-mode TIERED
```
# Tiered Storage auf einem vorhandenen Amazon MSK-Cluster mithilfe der Konsole aktualisieren
Dieser Prozess beschreibt, wie Sie einen Amazon MSK-Cluster mit Tiered Storage mithilfe des aktualisieren. AWS-Managementkonsole
Stellen Sie sicher, dass die aktuelle Apache-Kafka-Version Ihres MSK-Clusters 2.8.2.tiered ist. Weitere Informationen finden Sie unter [Aktualisieren der Apache-Kafka-Version](https://docs.aws.amazon.com/msk/latest/developerguide/version-upgrades.html), wenn Sie Ihren MSK-Cluster auf die Version 2.8.2.tiered aktualisieren müssen.
**Anmerkung**
Sie können die gestaffelte Speicherung nur aktivieren, wenn die log.cleanup.policy Ihres Clusters auf `delete` eingestellt ist, da komprimierte Themen bei der gestaffelten Speicherung nicht unterstützt werden. Später können Sie die log.cleanup.policy eines einzelnen Themas auf `compact` konfigurieren, wenn die gestaffelte Speicherung für dieses bestimmte Thema nicht aktiviert ist. Weitere Informationen zu den unterstützten Konfigurationsattributen finden Sie unter [Konfiguration auf Themenebene](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration).
1. Öffnen Sie die Amazon-MSK-Konsole unter [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Rufen Sie die Cluster-Übersichtsseite auf und wählen Sie **Eigenschaften**.
1. Rufen Sie den Bereich **Speicher** auf und wählen Sie **Cluster-Speichermodus bearbeiten**.
1. Wählen Sie **Gestaffelter Speicher und EBS-Speicher** und **Änderungen speichern**.
# Skalieren Sie den Brokerspeicher von Amazon MSK Standard
Sie können die Menge an EBS-Speicher pro Broker erhöhen. Sie können den Speicher nicht verringern.
Während dieses Skalierungsvorgangs bleiben Speichervolumen verfügbar.
**Wichtig**
Wenn der Speicher für einen MSK-Cluster skaliert wird, wird der zusätzliche Speicher sofort verfügbar gemacht. Der Cluster benötigt jedoch nach jedem Speicher-Skalierungsereignis eine Abkühlphase. Amazon MSK verwendet diese Abkühlphase, um den Cluster zu optimieren, bevor er erneut skaliert werden kann. Dieser Zeitraum kann je nach Speichergröße und Auslastung des Clusters sowie vom Datenverkehr zwischen mindestens 6 Stunden und mehr als 24 Stunden liegen. Dies gilt sowohl für auto Skalierungsereignisse als auch für manuelle Skalierung mithilfe des [UpdateBrokerStorage](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage)Vorgangs. Informationen zur richtigen Größe Ihres Speichers finden Sie unter [Bewährte Methoden für Standardbroker](bestpractices.md).
Sie können gestaffelten Speicher verwenden, um Ihren Broker auf unbegrenzte Speichermengen hochzuskalieren. Siehe [Mehrstufiger Speicher für Standard-Broker](msk-tiered-storage.md).
**Topics**
+ [Automatische Skalierung für Amazon MSK-Cluster](msk-autoexpand.md)
+ [Manuelle Skalierung für Standard-Broker](manually-expand-storage.md)
# Automatische Skalierung für Amazon MSK-Cluster
Um den Speicher Ihres Clusters als Reaktion auf eine erhöhte Auslastung automatisch zu erweitern, können Sie eine Richtlinie zur automatischen Skalierung von Anwendungen für Amazon MSK konfigurieren. In einer Auto-Scaling-Richtlinie legen Sie die Ziel-Festplattenauslastung und die maximale Skalierungskapazität fest.
Bevor Sie die automatische Skalierung für Amazon MSK verwenden, sollten Sie Folgendes berücksichtigen:
+
**Wichtig**
Eine Speicher-Skalierungsaktion kann nur einmal alle sechs Stunden ausgeführt werden.
Wir empfehlen, dass Sie mit einem Speichervolumen beginnen, das Ihren Speicheranforderungen entspricht. Hinweise zur Dimensionierung Ihrer MSK-Cluster finden Sie unter [Passen Sie die Größe Ihres Clusters an: Anzahl der Standard-Broker pro Cluster](bestpractices.md#brokers-per-cluster).
+ Amazon MSK reduziert den Cluster-Speicher nicht als Reaktion auf eine geringere Nutzung. Amazon MSK unterstützt die Verringerung der Größe von Speichervolumes nicht. Wenn Sie die Größe Ihres Cluster-Speichers reduzieren müssen, müssen Sie Ihren vorhandenen Cluster auf einen Cluster mit kleinerem Speicher migrieren. Weitere Informationen zur Migration eines Clusters finden Sie unter [Migrieren Sie zum MSK-Cluster](migration.md).
+ Amazon MSK unterstützt keine automatische Skalierung in den Regionen Asien-Pazifik (Osaka), Afrika (Kapstadt) und Asien-Pazifik (Malaysia).
+ Wenn Sie Ihrem Cluster eine Auto-Scaling-Richtlinie zuordnen, erstellt Amazon EC2 Auto Scaling automatisch einen CloudWatch Amazon-Alarm für die Zielverfolgung. Wenn Sie einen Cluster mit einer Auto-Scaling-Richtlinie löschen, bleibt dieser CloudWatch Alarm bestehen. Um den CloudWatch Alarm zu löschen, sollten Sie eine Auto-Scaling-Richtlinie aus einem Cluster entfernen, bevor Sie den Cluster löschen. Informationen zur Ziel-Nachverfolgung finden Sie unter [Skalierungsrichtlinien für die Ziel-Nachverfolgung für Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) im *Benutzerhandbuch für Amazon EC2 Auto Scaling*.
**Topics**
+ [Richtliniendetails zur automatischen Skalierung für Amazon MSK](msk-autoexpand-details.md)
+ [Automatische Skalierung für Ihren Amazon MSK-Cluster einrichten](msk-autoexpand-setup.md)
# Richtliniendetails zur automatischen Skalierung für Amazon MSK
Eine Auto-Scaling-Richtlinie definiert die folgenden Parameter für Ihren Cluster:
+ **Speichernutzungsziel**: Der Schwellenwert für die Speichernutzung, den Amazon MSK zum Auslösen eines Auto-Scaling-Vorgangs verwendet. Sie können das Nutzungsziel auf zwischen 10 % und 80 % der aktuellen Speicherkapazität festlegen. Wir empfehlen, das Speichernutzungsziel auf zwischen 50 % und 60 % festzulegen.
+ **Maximale Speicherkapazität**: Die maximale Skalierungsgrenze, die Amazon MSK für Ihren Broker-Speicher festlegen kann. Sie können die maximale Speicherkapazität auf bis zu 16 TiB pro Broker festlegen. Weitere Informationen finden Sie unter [Amazon-MSK-Kontingent](limits.md).
Wenn Amazon MSK feststellt, dass Ihre `Maximum Disk Utilization`-Metrik gleich oder größer als die `Storage Utilization Target`-Einstellung ist, erhöht es Ihre Speicherkapazität um eine Menge, die der größeren von zwei Zahlen entspricht: 10 GiB oder 10 % des aktuellen Speichers. Wenn Sie beispielsweise 1000 GiB haben, ist diese Menge 100 GiB. Der Service überprüft die Speichernutzung jede Minute. Durch weitere Skalierungsvorgänge wird der Speicherplatz weiter um eine Menge erhöht, die der größeren von zwei Zahlen entspricht: 10 GiB oder 10 % des aktuellen Speichers.
Verwenden Sie den [ ListClusterOperations](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-operations.html#ListClusterOperations)Vorgang, um festzustellen, ob auto-scaling Skalierungsvorgänge stattgefunden haben.
# Automatische Skalierung für Ihren Amazon MSK-Cluster einrichten
Sie können die Amazon MSK-Konsole, die Amazon MSK-API oder die automatische Skalierung für CloudFormation den Speicher verwenden. CloudFormation Support ist verfügbar über. [Application Auto Scaling](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html)
**Anmerkung**
Es ist nicht möglich, eine automatische Skalierung festzulegen, wenn Sie einen Cluster erstellen. Sie müssen zuerst den Cluster erstellen und dann eine Auto-Scaling-Richtlinie für diesen erstellen und aktivieren. Sie können die Richtlinie jedoch erstellen, während der Amazon-MSK-Service Ihren Cluster erstellt.
**Topics**
+ [Automatische Skalierung mit Amazon MSK einrichten AWS-Managementkonsole](msk-autoexpand-setup-console.md)
+ [Automatische Skalierung mit der CLI einrichten](msk-autoexpand-setup-cli.md)
+ [Automatische Skalierung für Amazon MSK mithilfe der API einrichten](msk-autoexpand-setup-api.md)
# Automatische Skalierung mit Amazon MSK einrichten AWS-Managementkonsole
Dieser Prozess beschreibt, wie Sie die Amazon MSK-Konsole verwenden, um die automatische Skalierung für Speicher zu implementieren.
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie Ihren Cluster in der Liste der Cluster aus. Dadurch gelangen Sie zu einer Seite, auf der Details zum Cluster aufgeführt sind.
1. Wählen Sie im Abschnitt **Auto Scaling für Speicher** die Option **Konfigurieren**.
1. Erstellen und benennen Sie eine Auto-Scaling-Richtlinie. Geben Sie das Speichernutzungsziel, die maximale Speicherkapazität und die Zielmetrik an.
1. Wählen Sie `Save changes`.
Wenn Sie die neue Richtlinie speichern und aktivieren, wird die Richtlinie für den Cluster aktiv. Amazon MSK erweitert dann den Speicher des Clusters, wenn das Speichernutzungsziel erreicht ist.
# Automatische Skalierung mit der CLI einrichten
In diesem Prozess wird beschrieben, wie Sie die Amazon MSK-CLI verwenden, um die automatische Skalierung für Speicher zu implementieren.
1. Verwenden Sie den [ RegisterScalableTarget](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)Befehl, um ein Speichernutzungsziel zu registrieren.
1. Verwenden Sie den [ PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)Befehl, um eine automatische Erweiterungsrichtlinie zu erstellen.
# Automatische Skalierung für Amazon MSK mithilfe der API einrichten
In diesem Prozess wird beschrieben, wie die Amazon MSK-API verwendet wird, um die automatische Skalierung für Speicher zu implementieren.
1. Verwenden Sie die [ RegisterScalableTarget](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_RegisterScalableTarget.html)API, um ein Speichernutzungsziel zu registrieren.
1. Verwenden Sie die [ PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)API, um eine automatische Erweiterungsrichtlinie zu erstellen.
# Manuelle Skalierung für Standard-Broker
Warten Sie mit der Speichererhöhung, bis sich der Cluster im Status `ACTIVE` befindet. Bei der Speicherskalierung gibt es zwischen Ereignissen eine Abkühlzeit von mindestens sechs Stunden. Der Vorgang stellt zwar sofort zusätzlichen Speicher zur Verfügung, der Service führt jedoch Optimierungen an Ihrem Cluster durch, die bis zu 24 Stunden oder länger dauern können. Die Dauer dieser Optimierungen ist proportional zur Speichergröße.
## Skalierung des Broker-Speichers mit dem AWS-Managementkonsole
1. Öffnen Sie die Amazon-MSK-Konsole unter [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Wählen Sie den MSK-Cluster aus, für den Sie Broker-Speicher aktualisieren möchten.
1. Wählen Sie im Abschnitt **Speicher** die Option **Bearbeiten** aus.
1. Geben Sie das gewünschte Speicher-Volume an. Sie können die Speichermenge nur erhöhen, nicht verringern.
1. Wählen Sie **Änderungen speichern ** aus.
## Skalierung des Broker-Speichers mit dem AWS CLI
Führen Sie den folgenden Befehl aus und *ClusterArn* ersetzen Sie ihn durch den Amazon-Ressourcennamen (ARN), den Sie bei der Erstellung Ihres Clusters erhalten haben. Wenn Ihnen der ARN für Ihren Cluster nicht vorliegt, finden Sie ihn, indem Sie alle Cluster auflisten. Weitere Informationen finden Sie unter [Amazon MSK-Cluster auflisten](msk-list-clusters.md).
*Current-Cluster-Version*Ersetzen Sie durch die aktuelle Version des Clusters.
**Wichtig**
Cluster-Versionen sind keine einfachen Ganzzahlen. Verwenden Sie den Befehl [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operation oder [describe-cluster, um die aktuelle Version des Clusters](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI zu finden. `KTVPDKIKX0DER` ist ein Beispiel für eine Version.
Der *Target-Volume-in-GiB* Parameter stellt die Speichermenge dar, über die jeder Broker verfügen soll. Es ist nur möglich, den Speicher für alle Broker zu aktualisieren. Sie können keine einzelnen Broker angeben, für die der Speicher aktualisiert werden soll. Der Wert, für den Sie angeben, *Target-Volume-in-GiB* muss eine ganze Zahl sein, die größer als 100 GiB ist. Der Speicher pro Broker darf nach dem Aktualisierungsvorgang den Wert 16384 GiB nicht überschreiten.
```
aws kafka update-broker-storage --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-broker-ebs-volume-info '{"KafkaBrokerNodeId": "All", "VolumeSizeGB": Target-Volume-in-GiB}'
```
## Hochskalieren von Broker-Speicher mithilfe der API
Informationen zum Aktualisieren eines Broker-Speichers mithilfe der API finden Sie unter [UpdateBrokerStorage](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage).
# Speicherdurchsatz für Standard-Broker in einem Amazon MSK-Cluster verwalten
Informationen zur Bereitstellung von Durchsatz mithilfe der Amazon MSK-Konsole, CLI und API finden Sie unter[Bereitstellung von Speicherdurchsatz für Standard-Broker in einem Amazon MSK-Cluster](msk-provision-throughput.md).
**Topics**
+ [Durchsatzengpässe und Einstellungen für maximalen Durchsatz bei Amazon MSK Broker](#throughput-bottlenecks)
+ [Messen Sie den Speicherdurchsatz eines Amazon MSK-Clusters](#throughput-metrics)
+ [Werte für das Konfigurationsupdate für bereitgestellten Speicher in einem Amazon MSK-Cluster](#provisioned-throughput-config)
+ [Bereitstellung von Speicherdurchsatz für Standard-Broker in einem Amazon MSK-Cluster](msk-provision-throughput.md)
## Durchsatzengpässe und Einstellungen für maximalen Durchsatz bei Amazon MSK Broker
Es gibt mehrere Ursachen für Engpässe beim Broker-Durchsatz: den Volumendurchsatz, den Netzwerkdurchsatz von Amazon EC2 zu Amazon EBS und den Amazon-EC2-Ausgangsdurchsatz. Sie können den bereitgestellten Speicherdurchsatz aktivieren, um den Volumendurchsatz anzupassen. Einschränkungen des Broker-Durchsatzes können jedoch durch den Netzwerkdurchsatz von Amazon EC2 zu Amazon EBS und den Amazon-EC2-Ausgangsdurchsatz verursacht werden.
Der Amazon-EC2-Ausgangsdurchsatz wird von der Anzahl der Verbrauchergruppen und der Verbraucher pro Verbrauchergruppe beeinflusst. Außerdem sind sowohl der Netzwerkdurchsatz von Amazon EC2 zu Amazon EBS als auch der Amazon EC2 EC2-Ausgangsdurchsatz bei größeren Brokern höher.
Für Volumengrößen von 10 GiB oder mehr können Sie einen Speicherdurchsatz von 250 MiB pro Sekunde oder mehr bereitstellen. 250 MiB pro Sekunde ist die Standardeinstellung. Um den Speicherdurchsatz bereitzustellen, müssen Sie die Broker-Größe kafka.m5.4xlarge oder größer (oder kafka.m7g.2xlarge oder größer) wählen, und Sie können den maximalen Durchsatz angeben, wie in der folgenden Tabelle dargestellt.
****
| Größe des Brokers | Maximaler Speicherdurchsatz (MiB/s) |
| --- | --- |
| kafka.m5.4xlarge | 593 |
| kafka.m5.8xlarge | 850 |
| kafka.m5.12xlarge | 1000 |
| kafka.m 5.16x groß | 1000 |
| kafka.m5.24xlarge | 1000 |
| kafka.m 7 g, 2 x groß | 312,5 |
| kafka.m7g.4x groß | 625 |
| kafka.m7g.8xgroß | 1000 |
| kafka.m7g.12x groß | 1000 |
| kafka.m7g.16x groß | 1000 |
## Messen Sie den Speicherdurchsatz eines Amazon MSK-Clusters
Sie können die Metriken `VolumeReadBytes` und `VolumeWriteBytes` verwenden, um den durchschnittlichen Speicherdurchsatz eines Clusters zu messen. Die Summe dieser beiden Metriken ergibt den durchschnittlichen Speicherdurchsatz in Bytes. Um den durchschnittlichen Speicherdurchsatz für einen Cluster zu ermitteln, setzen Sie diese beiden Metriken auf SUM und den Zeitraum auf 1 Minute, und verwenden Sie dann die folgende Formel.
```
Average storage throughput in MiB/s = (Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / (60 * 1024 * 1024)
```
Weitere Informationen über die Metriken `VolumeReadBytes` und `VolumeWriteBytes` finden Sie unter [Überwachung auf `PER_BROKER`-Ebene](metrics-details.md#broker-metrics).
## Werte für das Konfigurationsupdate für bereitgestellten Speicher in einem Amazon MSK-Cluster
Sie können Ihre Amazon-MSK-Konfiguration entweder vor oder nach der Aktivierung des bereitgestellten Durchsatzes aktualisieren. Der gewünschte Durchsatz wird Ihnen jedoch erst angezeigt, wenn Sie beide Aktionen ausführen: den Konfigurationsparameter `num.replica.fetchers` aktualisieren und den bereitgestellten Durchsatz aktivieren.
In der Standardkonfiguration von Amazon MSK hat `num.replica.fetchers` den Wert 2. Sie können Ihr `num.replica.fetchers` aktualisieren, indem Sie die vorgeschlagenen Werte aus der folgenden Tabelle verwenden. Diese Werte dienen zur Orientierung. Wir empfehlen Ihnen, diese Werte an Ihren Anwendungsfall anzupassen.
****
| Größe des Brokers | num.replica.fetchers |
| --- | --- |
| kafka.m5.4xlarge | 4 |
| kafka.m5.8xlarge | 8 |
| kafka.m5.12xlarge | 14 |
| kafka.m 5.16x groß | 16 |
| kafka.m5.24xlarge | 16 |
Ihre aktualisierte Konfiguration wird möglicherweise erst nach 24 Stunden wirksam und kann länger dauern, wenn ein Quell-Volume nicht voll ausgelastet ist. Die Leistung eines temporären Volumes entspricht jedoch mindestens der Leistung der Quell-Speicher-Volumes während des Migrationszeitraums. Die Migration eines voll ausgelasteten 1-TiB-Volumes zu einer aktualisierten Konfiguration dauert in der Regel etwa sechs Stunden.
# Bereitstellung von Speicherdurchsatz für Standard-Broker in einem Amazon MSK-Cluster
Amazon-MSK-Broker speichern Daten auf Speichervolumes. Speicherplatz I/O wird verbraucht, wenn Produzenten in den Cluster schreiben, wenn Daten zwischen Brokern repliziert werden und wenn Verbraucher Daten lesen, die sich nicht im Arbeitsspeicher befinden. Der Volumenspeicherdurchsatz ist die Geschwindigkeit, mit der Daten in ein Speichervolume geschrieben und von diesem gelesen werden können. Beim bereitgestellten Speicherdurchsatz handelt es sich um die Möglichkeit, diese Rate für die Broker in Ihrem Cluster festzulegen.
Sie können die bereitgestellte Durchsatzrate in MiB pro Sekunde für Cluster angeben, deren Broker größer `kafka.m5.4xlarge` oder größer sind und wenn das Speichervolumen 10 GiB oder mehr beträgt. Es ist möglich, den bereitgestellten Durchsatz bei der Cluster-Erstellung anzugeben. Sie können den bereitgestellten Durchsatz auch für einen Cluster aktivieren oder deaktivieren, der sich im Status `ACTIVE` befindet.
Informationen zur Verwaltung des Durchsatzes finden Sie unter. [Speicherdurchsatz für Standard-Broker in einem Amazon MSK-Cluster verwalten](msk-provision-throughput-management.md)
**Topics**
+ [Stellen Sie den Amazon MSK-Cluster-Speicherdurchsatz bereit mithilfe der AWS-Managementkonsole](#provisioned-throughput-console)
+ [Stellen Sie den Amazon MSK-Cluster-Speicherdurchsatz bereit mithilfe der AWS CLI](#provisioned-throughput-cli)
+ [Bereitstellung von Speicherdurchsatz bei der Erstellung eines Amazon MSK-Clusters mithilfe der API](#provisioned-throughput-api)
## Stellen Sie den Amazon MSK-Cluster-Speicherdurchsatz bereit mithilfe der AWS-Managementkonsole
Dieser Prozess zeigt ein Beispiel dafür, wie Sie den verwenden können, AWS-Managementkonsole um einen Amazon MSK-Cluster mit aktiviertem bereitgestellten Durchsatz zu erstellen.
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie **Cluster erstellen**.
1. Wählen Sie **Benutzerdefiniert erstellen**.
1. Geben Sie einen Namen für den Cluster ein.
1. Wählen Sie im Abschnitt **Speicher** die Option **Aktivieren**.
1. Wählen Sie einen Wert für den Speicherdurchsatz pro Broker.
1. Wählen Sie eine VPC, Zonen und Subnetze und eine Sicherheitsgruppe.
1. Wählen Sie **Weiter** aus.
1. Wählen Sie unten im Schritt **Sicherheit** die Option **Weiter**.
1. Wählen Sie unten im Schritt **Überwachung und Tags** die Option **Weiter**.
1. Überprüfen Sie die Cluster-Einstellungen und wählen Sie dann **Cluster erstellen**.
## Stellen Sie den Amazon MSK-Cluster-Speicherdurchsatz bereit mithilfe der AWS CLI
Dieser Prozess zeigt ein Beispiel dafür, wie Sie den verwenden können AWS CLI , um einen Cluster mit aktiviertem bereitgestellten Durchsatz zu erstellen.
1. Kopieren Sie den folgenden JSON-Code in eine Datei. Ersetzen Sie die Platzhalter für die Subnetz IDs - und Sicherheitsgruppen-ID durch Werte aus Ihrem Konto. Benennen Sie die Datei `cluster-creation.json` und speichern Sie sie.
```
{
"Provisioned": {
"BrokerNodeGroupInfo":{
"InstanceType":"kafka.m5.4xlarge",
"ClientSubnets":[
"Subnet-1-ID",
"Subnet-2-ID"
],
"SecurityGroups":[
"Security-Group-ID"
],
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 10,
"ProvisionedThroughput": {
"Enabled": true,
"VolumeThroughput": 250
}
}
}
},
"EncryptionInfo": {
"EncryptionInTransit": {
"InCluster": false,
"ClientBroker": "PLAINTEXT"
}
},
"KafkaVersion":"2.8.1",
"NumberOfBrokerNodes": 2
},
"ClusterName": "provisioned-throughput-example"
}
```
1. Führen Sie den folgenden AWS CLI Befehl in dem Verzeichnis aus, in dem Sie die JSON-Datei im vorherigen Schritt gespeichert haben.
```
aws kafka create-cluster-v2 --cli-input-json file://cluster-creation.json
```
## Bereitstellung von Speicherdurchsatz bei der Erstellung eines Amazon MSK-Clusters mithilfe der API
[Verwenden Sie V2, um den Durchsatz des bereitgestellten Speichers bei der Erstellung eines Clusters zu konfigurieren. CreateCluster](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)
# Bereitgestellte Amazon MSK-Konfiguration
Amazon MSK bietet Standardkonfigurationen für Broker, Themen und Metadatenknoten. Ebenso können Sie benutzerdefinierte Konfigurationen erstellen und sie verwenden, um neue MSK-Cluster zu erstellen oder vorhandene Cluster zu aktualisieren. Eine MSK-Konfiguration besteht aus einer Reihe von Eigenschaften und den entsprechenden Werten. Je nach Brokertyp, den Sie in Ihrem Cluster verwenden, gibt es unterschiedliche Standardkonfigurationen und verschiedene Konfigurationen, die Sie ändern können. In den folgenden Abschnitten finden Sie weitere Informationen zur Konfiguration Ihrer Standard- und Express-Broker.
**Topics**
+ [Standard-Broker-Konfigurationen](msk-configuration-standard.md)
+ [Express-Broker-Konfigurationen](msk-configuration-express.md)
+ [Operationen zur Broker-Konfiguration](msk-configuration-operations.md)
# Standard-Broker-Konfigurationen
In diesem Abschnitt werden die Konfigurationseigenschaften für Standard-Broker beschrieben.
**Topics**
+ [Benutzerdefinierte Amazon MSK-Konfigurationen](msk-configuration-properties.md)
+ [Standardkonfiguration von Amazon MSK](msk-default-configuration.md)
+ [Richtlinien für die Konfiguration von Amazon MSK Tiered Storage auf Themenebene](msk-guidelines-tiered-storage-topic-level-config.md)
# Benutzerdefinierte Amazon MSK-Konfigurationen
Sie können Amazon MSK verwenden, um eine benutzerdefinierte MSK-Konfiguration zu erstellen, in der Sie die folgenden Apache Kafka-Konfigurationseigenschaften festlegen. Eigenschaften, die Sie nicht explizit festlegen, erhalten die in [Standardkonfiguration von Amazon MSK](msk-default-configuration.md) festgelegten Werte. Weitere Informationen zu Konfigurationseigenschaften finden Sie unter [Apache Kafka Configuration](https://kafka.apache.org/documentation/#configuration).
| Name | Description |
| --- | --- |
| allow.everyone.if.no.acl.found | Wenn Sie diese Eigenschaft auf setzen möchten, stellen Sie zunächst sicherfalse, dass Sie Apache Kafka ACLs für Ihren Cluster definieren. Wenn Sie diese Eigenschaft auf setzen false und Sie nicht zuerst Apache Kafka definieren ACLs, verlieren Sie den Zugriff auf den Cluster. In diesem Fall können Sie die Konfiguration erneut aktualisieren und diese Eigenschaft auf true setzen, um wieder Zugriff auf den Cluster zu erhalten. |
| auto.create.topics.enable | Aktiviert die automatische Erstellung von Themen auf dem Server. |
| compression.type | Der endgültige Komprimierungstyp für ein bestimmtes Thema. Sie können diese Eigenschaft auf die Standard-Komprimierungscodecs (gzip, snappy, lz4 und zstd) festlegen. Akzeptiert zusätzlich uncompressed. Dieser Wert entspricht keiner Komprimierung. Wenn Sie den Wert auf producer setzen, bedeutet dies, dass der ursprüngliche Komprimierungs-Codec beibehalten wird, den der Produzent festlegt. |
| connections.max.idle.ms | Timeout bei inaktiven Verbindungen in Millisekunden. Die Threads des Server-Socket-Prozessors schließen die Verbindungen, die länger als den von Ihnen für diese Eigenschaft festgelegten Wert inaktiv sind. |
| default.replication.factor | Der Standardreplikationsfaktor für automatisch erstellte Themen. |
| delete.topic.enable | Aktiviert den Vorgang zum Löschen von Themen. Wenn Sie diese Einstellung deaktivieren, können Sie ein Thema nicht über das Admin-Tool löschen. |
| group.initial.rebalance.delay.ms | Die Zeit, die der Gruppenkoordinator darauf wartet, dass mehr Verbraucher einer neuen Gruppe beitreten, bevor der erste Neuausgleich durchgeführt wird. Eine längere Verzögerung bedeutet potenziell wenigere Neuausgleiche, erhöht aber die Zeit bis zum Beginn der Verarbeitung. |
| group.max.session.timeout.ms | Maximales Sitzungs-Timeout für registrierte Konsumenten. Längere Timeouts verschaffen Verbrauchern mehr Zeit für die Verarbeitung von Nachrichten zwischen Heartbeats, sie führen aber auch zu einer längeren Fehlererkennungszeit. |
| group.min.session.timeout.ms | Minimale Sitzungs-Timeout für registrierte Konsumenten. Kürzere Timeouts führen zu einer schnelleren Fehlererkennung und häufigeren Verbraucher-Heartbeats, was Broker-Ressourcen überfordern kann. Dies kann die Broker-Ressourcen überfordern. |
| leader.imbalance.per.broker.percentage | Das Verhältnis des zulässigen Führungsungleichgewichts pro Broker. Der Controller löst einen Führungsausgleich aus, wenn er diesen Wert pro Broker übersteigt. Dieser Wert wird in Prozent angegeben. |
| log.cleaner.delete.retention.ms | Zeitraum, in dem Apache Kafka gelöschte Datensätze beibehalten soll. Der Mindestwert ist 0. |
| log.cleaner.min.cleanable.ratio | Diese Konfigurationseigenschaft kann Werte zwischen 0 und 1 haben. Dieser Wert bestimmt, wie oft der Protokollkomprimierer versucht, das Protokoll zu bereinigen (wenn die Protokollkomprimierung aktiviert ist). Standardmäßig vermeidet Apache Kafka die Bereinigung eines Protokolls, wenn mehr als 50 % des Protokolls komprimiert wurden. Dieses Verhältnis begrenzt den maximalen Speicherplatz, den das Protokoll mit Duplikaten verschwendet (bei 50 % bedeutet dies, dass höchstens 50 % des Protokolls Duplikate sein könnten). Bei einem größeren Verhältnis sind Bereinigungen häufiger und effizienter, aber es wird auch mehr Speicherplatz im Protokoll benötigt. |
| log.cleanup.policy | Die Standard-Bereinigungsrichtlinie für Segmente außerhalb des Aufbewahrungsfensters. Eine durch Kommata getrennte Liste gültiger Richtlinien. Gültige Richtlinien sind delete und compact. Für Cluster mit aktivierter gestaffelter Speicherung gilt nur die Richtlinie delete. |
| log.flush.interval.messages | Anzahl der Nachrichten, die auf einer Protokollpartition gesammelt werden, bevor Nachrichten auf den Datenträger geschrieben werden. |
| log.flush.interval.ms | Maximale Zeit in Millisekunden, in der eine Nachricht in einem beliebigen Thema im Speicher aufbewahrt wird, bevor sie auf die Festplatte geschrieben wird. Wenn Sie diesen Wert nicht festlegen, wird der Wert in log.flush.scheduler.interval.ms verwendet. Der Mindestwert ist 0. |
| log.message.timestamp.difference.max.ms | Diese Konfiguration ist in Kafka 3.6.0 veraltet. Zwei Konfigurationen, log.message.timestamp.before.max.ms undlog.message.timestamp.after.max.ms, wurden hinzugefügt. Der maximale Zeitunterschied zwischen dem Zeitstempel beim Empfang einer Nachricht durch den Broker und dem in der Nachricht angegebenen Zeitstempel. Bei log.message.timestamp.type= wird eine Nachricht zurückgewiesenCreateTime, wenn der Unterschied im Zeitstempel diesen Schwellenwert überschreitet. Diese Konfiguration wird LogAppendTime ignoriert, wenn log.message.timestamp.type=. |
| log.message.timestamp.type | Gibt an, wenn der Zeitstempel in der Nachricht die Erstellungszeit der Nachricht oder die Anfügezeit des Protokolls widerspiegelt. Die zulässigen Werte sind CreateTime und LogAppendTime. |
| log.retention.bytes | Maximale Größe des Protokolls vor dem Löschen. |
| log.retention.hours | Anzahl der Stunden, die eine Protokolldatei vor dem Löschen aufbewahrt werden muss, tertiär zur Eigenschaft log.retention.ms. |
| log.retention.minutes | Anzahl der Minuten, in denen eine Protokolldatei vor dem Löschen aufbewahrt wird, sekundär zur Eigenschaft log.retention.ms. Wenn Sie diesen Wert nicht festlegen, wird der Wert in log.retention.hours verwendet. |
| log.retention.ms | Anzahl der Millisekunden, die eine Protokolldatei vor dem Löschen aufbewahrt wird (in Millisekunden). Wenn der Wert nicht festgelegt ist, wird der Wert in log.retention.minutes verwendet. |
| log.roll.ms | Maximale Zeit, bis ein neues Protokollsegment bereitgestellt wird (in Millisekunden). Wenn Sie diesen Wert nicht festlegen, wird der Wert in log.roll.hours verwendet. Der Mindestwert für diese Eigenschaft ist 1. |
| log.segment.bytes | Maximale Größe einer einzelnen Protokolldatei. |
| max.incremental.fetch.session.cache.slots | Maximale Anzahl inkrementeller Abrufsitzungen, die beibehalten werden. |
| message.max.bytes | Die größte von Kafka unterstützte Protokoll-Batch-Größe. Wenn Sie diesen Wert erhöhen und Verbraucher älter als 0.10.2 vorhanden sind, müssen Sie auch die Abrufgröße der Verbraucher erhöhen, damit sie diese großen Datensatz-Batch abrufen können. In der neuesten Nachrichtenformat-Version werden Datensätze aus gründen der Effizienz immer in Batches gruppiert. In früheren Nachrichtenformat-Versionen werden nicht komprimierte Datensätze nicht in Batches gruppiert und diese Beschränkung gilt in diesem Fall nur für einen einzelnen Datensatz. Sie können dies pro Thema mit der Konfiguration auf Themenebene max.message.bytes festlegen. |
| min.insync.replicas | Wenn ein Produzent acks auf `"all"` (oder `"-1"`) setzt, gibt min.insync.replicas die Mindestanzahl von Replikaten an, die einen Schreibvorgang bestätigen müssen, damit der Schreibvorgang als erfolgreich angesehen wird. Wenn dieses Minimum nicht erreicht werden kann, löst der Hersteller eine Ausnahme aus (entweder oder). NotEnoughReplicas NotEnoughReplicasAfterAppend Sie können die Werte in min.insync.replicas und acks zusammen verwenden, um langfristigere Beständigkeitsgarantien durchzusetzen. Zum Beispiel könnten Sie ein Thema mit dem Replikationsfaktor 3 erstellen, min.insync.replicas auf 2 einstellen und mit acks von `"all"` produzieren. Dadurch wird sichergestellt, dass der Produzent eine Ausnahme auslöst, wenn die Mehrheit der Replikate keinen Schreibvorgang erhält. |
| num.io.threads | Die Anzahl der Threads, die der Server für die Verarbeitung von Anforderungen verwendet, einschließlich Datenträger-E/A. |
| num.network.threads | Die Anzahl der Threads, die der Server zum Empfangen von Anfragen aus dem Netzwerk und zum Senden von Antworten verwendet. |
| num.partitions | Standardanzahl der Protokollpartitionen pro Thema. |
| num.recovery.threads.per.data.dir | Die Anzahl der Threads pro Datenverzeichnis, die für die Protokollwiederherstellung beim Startup und zum Bereinigen beim Herunterfahren verwendet werden sollen. |
| num.replica.fetchers | Die Anzahl der Abfrage-Threads, die zum Replizieren von Nachrichten von einem Quell-Broker verwendet werden. Wenn Sie diesen Wert erhöhen, können Sie den Grad der I/O Parallelität im Follower-Broker erhöhen. |
| offsets.retention.minutes | Nachdem eine Konsumentengruppe alle Konsumenten verliert (d. h. sie ist dann leer), werden die Offsets für diesen Aufbewahrungszeitraum aufbewahrt, bevor sie verworfen werden. Bei eigenständigen Verbrauchern (d. h. diejenige, die manueller Zuweisung verwenden) sind Offsets nach dem Zeitpunkt des letzten Commits zusätzlich dieser Aufbewahrungsfrist abgelaufen. |
| offsets.topic.replication.factor | Der Replikationsfaktor für das Offsets-Thema. Setzen Sie diesen Wert höher, um die Verfügbarkeit sicherzustellen. Die interne Themenerstellung schlägt fehl, bis die Cluster-Größe diese Anforderung des Replikationsfaktors erfüllt. |
| replica.fetch.max.bytes | Anzahl der Bytes von Nachrichten, die für jede Partition abgerufen werden sollen. Es handelt sich nicht um ein absolutes Maximum. Wenn der erste Datensatz-Batch in der ersten nicht leeren Partition des Abrufs größer ist als dieser Wert, wird der Datensatz-Batch zurückgegeben, damit Fortschritte gemacht werden können. Die Eigenschaften message.max.bytes (Broker-Konfiguration) oder max.message.bytes (Themenkonfiguration) geben die maximale vom Broker akzeptierte Datensatz-Batch-Größe an. |
| replica.fetch.response.max.bytes | Die maximale Anzahl von Bytes, die für die gesamte Abrufantwort erwartet wird. Datensätze werden in Batches abgerufen und wenn der erste Datensatz-Batch in der ersten nicht leeren Partition des Abrufs größer ist als dieser Wert, wird der Datensatz-Batch weiterhin zurückgegeben, damit Fortschritte gemacht werden können. Es handelt sich nicht um ein absolutes Maximum. Die Eigenschaften message.max.bytes (Broker-Konfiguration) oder max.message.bytes (Themenkonfiguration) geben die maximale vom Broker akzeptierte Datensatzstapelgröße an. |
| replica.lag.time.max.ms | Wenn ein Follower für mindestens diese Anzahl von Millisekunden keine Abrufanforderungen gesendet hat oder nicht bis zum Protokollendversatz des Leaders konsumiert hat, entfernt der Leader den Follower aus dem ISR.MinValue: 10000MaxValue = 30000 |
| replica.selector.class | Der vollqualifizierte Klassenname, der implementiert wird. ReplicaSelector Der Broker verwendet diesen Wert, um das bevorzugte Lesereplikat zu finden. Wenn Sie Apache Kafka Version 2.4.1 oder höher verwenden und es Verbrauchern erlauben möchten, vom nächstgelegenen Replikat abzurufen, setzen Sie diese Eigenschaft auf org.apache.kafka.common.replica.RackAwareReplicaSelector. Weitere Informationen finden Sie unter [Apache Kafka Version 2.4.1 (verwenden Sie stattdessen 2.4.1.1)](supported-kafka-versions.md#2.4.1). |
| replica.socket.receive.buffer.bytes | Der Socket-Empfangspuffer für Netzwerkanforderungen. |
| socket.receive.buffer.bytes | Der SO\$1RCVBUF-Puffer der Socket-Server-Sockets. Der Mindestwert, den Sie für diese Eigenschaft festlegen können, ist -1. Wenn der Wert -1 ist, verwendet Amazon MSK den Betriebssystemstandard. |
| socket.request.max.bytes | Die maximale Anzahl von Bytes in einer Socket-Anfrage. |
| socket.send.buffer.bytes | Der SO\$1SNDBUF-Puffer der Socket-Server-Sockets. Der Mindestwert, den Sie für diese Eigenschaft festlegen können, ist -1. Wenn der Wert -1 ist, verwendet Amazon MSK den Betriebssystemstandard. |
| transaction.max.timeout.ms | Maximales Timeout für Transaktionen. Wenn die angeforderte Transaktionszeit eines Clients diesen Wert überschreitet, gibt der Broker einen Fehler in InitProducerIdRequest zurück. So wird ein zu großer Timeout auf Client-Seite verhindert, der Verbraucher am Lesen aus Themen, die in der Transaktion vorhanden sind, hindern könnte. |
| transaction.state.log.min.isr | Überschriebene min.insync.replicas-Konfiguration für das Transaktionsthema. |
| transaction.state.log.replication.factor | Der Replikationsfaktor für das Transaktionsthema. Setzen Sie diese Eigenschaft auf einen höheren Wert, um die Verfügbarkeit zu erhöhen. Die interne Themenerstellung schlägt fehl, bis die Cluster-Größe diese Anforderung des Replikationsfaktors erfüllt. |
| transactional.id.expiration.ms | Die Zeit in Millisekunden, in der der Transaktionskoordinator auf Aktualisierungen des Transaktionsstatus für die aktuelle Transaktion wartet, bevor der Koordinator seine Transaktions-ID ablaufen lässt. Diese Einstellung beeinflusst auch den Ablauf der Producer-ID, da sie dazu führt, dass die Producer-ID IDs abläuft, wenn diese Zeit nach dem letzten Schreibvorgang mit der angegebenen Producer-ID verstrichen ist. Producer läuft aufgrund der Aufbewahrungseinstellungen für das Thema IDs möglicherweise früher ab, wenn der letzte Schreibvorgang aus der Producer-ID gelöscht wird. Der Mindestwert für diese Eigenschaft ist 1 Millisekunde. |
| unclean.leader.election.enable | Gibt an, ob Replikate, die nicht im ISR-Satz enthalten sind, als letztes Mittel als Führer dienen sollen, auch wenn dies zu Datenverlust führen kann. |
| zookeeper.connection.timeout.ms | ZooKeeper Modus-Cluster. Maximale Zeit, bis zu der der Client wartet, um eine Verbindung herzustellen. ZooKeeper Wenn Sie diesen Wert nicht festlegen, wird der Wert in zookeeper.session.timeout.ms verwendet. MinValue = 6000 MaxValue (einschließlich) = 18000 Wir empfehlen, diesen Wert auf T3.small auf 10.000 festzulegen, um Cluster-Ausfallzeiten zu vermeiden. |
| zookeeper.session.timeout.ms | ZooKeeper Modus-Cluster. Das Zeitlimit für die ZooKeeper Apache-Sitzung in Millisekunden. MinValue = 6000 MaxValue (einschließlich) = 18000 |
Weitere Informationen dazu, wie Sie eine benutzerdefinierte MSK-Konfiguration erstellen, alle Konfigurationen auflisten oder diese beschreiben können, finden Sie unter [Operationen zur Broker-Konfiguration](msk-configuration-operations.md). Informationen zum Erstellen eines MSK-Clusters mit einer benutzerdefinierten MSK-Konfiguration oder zum Aktualisieren eines Clusters mit einer neuen benutzerdefinierten Konfiguration finden Sie unter [Die wichtigsten Funktionen und Konzepte von Amazon MSK](operations.md).
Wenn Sie den vorhandenen MSK-Cluster mit einer benutzerdefinierten MSK-Konfiguration aktualisieren, führt Amazon MSK bei Bedarf unter Verwendung bewährter Methoden fortlaufende Neustarts durch, um Ausfallzeiten für Kunden zu minimieren. Nachdem Amazon MSK jeden Broker neu gestartet hat, warten Amazon MSK, bis der Broker Daten verarbeitet hat, die während des Konfigurations-Updates möglicherweise verpasst wurden, bevor zum nächsten Broker übergegangen wird.
## Dynamische Amazon MSK-Konfiguration
Zusätzlich zu den Konfigurationseigenschaften, die Amazon MSK bereitstellt, können Sie Konfigurationseigenschaften, für die kein Broker-Neustart erforderlich ist, auf Cluster- und Broker-Ebene dynamisch festlegen. Sie können einige Konfigurationseigenschaften dynamisch festlegen. Dies sind die Eigenschaften, die in der Tabelle unter [Broker-Konfigurationen](https://kafka.apache.org/documentation/#brokerconfigs) in der Apache-Kafka-Dokumentation nicht als schreibgeschützt markiert sind. Informationen zur dynamischen Konfiguration und zu Beispielbefehlen finden Sie unter [Aktualisieren der Broker-Konfigurationen](https://kafka.apache.org/documentation/#dynamicbrokerconfigs) in der Apache-Kafka-Dokumentation.
**Anmerkung**
Sie können die Eigenschaft `advertised.listeners` festlegen, die Eigenschaft `listeners` hingegen nicht.
## Amazon MSK-Konfiguration auf Themenebene
Sie können Apache Kafka-Befehle verwenden, um Konfigurationseigenschaften auf Themenebene für neue und vorhandene Themen festzulegen oder zu ändern. Weitere Informationen zu Konfigurationseigenschaften auf Themenebene und Beispiele zum Festlegen dieser Eigenschaften finden Sie unter [Konfigurationen auf Themenebene](https://kafka.apache.org/documentation/#topicconfigs) in der Apache-Kafka-Dokumentation.
# Standardkonfiguration von Amazon MSK
Wenn Sie einen MSK-Cluster erstellen, ohne eine benutzerdefinierte MSK-Konfiguration anzugeben, erstellt und verwendet Amazon MSK eine Standardkonfiguration mit den in der folgenden Tabelle angegebenen Werten. Bei Eigenschaften, die nicht in dieser Tabelle enthalten sind, verwendet Amazon MSK die Standardwerte, die Ihrer Version von Apache Kafka zugeordnet sind. Eine Liste dieser Standardwerte finden Sie unter [Apache Kafka Configuration](https://kafka.apache.org/documentation/#configuration).
| Name | Description | Standardwert für Cluster mit nicht-gestaffeltem Speicher | Standardwert für Cluster mit aktivierter gestaffelter Speicherung |
| --- | --- | --- | --- |
| allow.everyone.if.no.acl.found | Wenn keine Ressourcenmuster mit einer bestimmten Ressource übereinstimmen, ist der Ressource nichts zugeordnet ACLs. Wenn diese Eigenschaft auf true gesetzt ist, kann jeder auf die Ressource zugreifen, nicht nur die Superuser. | true | true |
| auto.create.topics.enable | Aktiviert die automatische Erstellung eines Themas auf dem Server. | false | false |
| auto.leader.rebalance.enable | Aktiviert den automatischen Führungsausgleich. Ein Hintergrund-Thread prüft den Führungsausgleich und löst, wenn erforderlich, diesen in regelmäßigen Abständen aus. | true | true |
| default.replication.factor | Standardreplikationsfaktoren für automatisch erstellte Themen. | 3 für Cluster in 3 Availability Zones und 2 für Cluster in 2 Availability Zones. | 3 für Cluster in 3 Availability Zones und 2 für Cluster in 2 Availability Zones. |
| local.retention.bytes | Die maximale Größe der lokalen Protokollsegmente für eine Partition, bevor die alten Segmente gelöscht werden. Wenn Sie diesen Wert nicht festlegen, wird der Wert in log.retention.bytes verwendet. Der effektive Wert sollte immer kleiner oder gleich dem Wert log.retention.bytes sein. Ein Standardwert von -2 bedeutet, dass kein Grenzwert für die lokale Aufbewahrung vorhanden ist. Dies entspricht der retention.ms/bytes-Einstellung von -1. Die Eigenschaften local.retention.ms und local.retention.bytes ähneln log.retention, da sie verwendet werden, um zu bestimmen, wie lange die Protokollsegmente im lokalen Speicher verbleiben sollen. Bestehende log.retention.\$1-Konfigurationen sind Aufbewahrungskonfigurationen für die Themenpartition. Dies umfasst sowohl lokalen als auch Remote-Speicher. Gültige Werte: Ganzzahlen in [-2; \$1Inf] | -2 für unbegrenzt | -2 für unbegrenzt |
| local.retention.ms | Die Anzahl der Millisekunden, die das lokale Protokollsegment vor dem Löschen beibehalten werden soll. Wenn Sie diesen Wert nicht festlegen, verwendet Amazon MSK den Wert in log.retention.ms. Der effektive Wert sollte immer kleiner oder gleich dem Wert log.retention.bytes sein. Ein Standardwert von -2 bedeutet, dass kein Grenzwert für die lokale Aufbewahrung vorhanden ist. Dies entspricht der retention.ms/bytes-Einstellung von -1.Die Werte local.retention.ms und local.retention.bytes ähneln log.retention. MSK verwendet diese Konfiguration, um zu bestimmen, wie lange die Protokollsegmente im lokalen Speicher verbleiben sollen. Bestehende log.retention.\$1-Konfigurationen sind Aufbewahrungskonfigurationen für die Themenpartition. Dies umfasst sowohl lokalen als auch Remote-Speicher. Gültige Werte sind Ganzzahlen größer als 0. | -2 für unbegrenzt | -2 für unbegrenzt |
| log.message.timestamp.difference.max.ms | Diese Konfiguration ist in Kafka 3.6.0 veraltet. Zwei Konfigurationen, log.message.timestamp.before.max.ms undlog.message.timestamp.after.max.ms, wurden hinzugefügt. Die maximal zulässige Diskrepanz zwischen dem Zeitstempel beim Empfang einer Nachricht durch den Broker und dem in der Nachricht angegebenen Zeitstempel. Bei log.message.timestamp.type= wird eine Nachricht zurückgewiesenCreateTime, wenn der Unterschied im Zeitstempel diesen Schwellenwert überschreitet. Diese Konfiguration wird LogAppendTime ignoriert, wenn log.message.timestamp.type=. Der maximal zulässige Zeitstempelunterschied sollte nicht größer als log.retention.ms sein, um unnötig häufiges Protokoll-Rolling zu vermeiden. | 9223372036854775807 | 86400000 für Kafka 2.8.2. Tiered und Kafka 3.7.x Tiered. |
| log.segment.bytes | Die maximale Größe einer einzelnen Protokolldatei. | 1073741824 | 134217728 |
| min.insync.replicas | Wenn ein Produzent den Wert von acks (Bestätigung, die der Produzent vom Kafka-Brocker erhält) auf `"all"` (oder `"-1"`) setzt, gibt der Wert in min.insync.replicas die Mindestanzahl von Replikaten an, die einen Schreibvorgang bestätigen müssen, damit der Schreibvorgang als erfolgreich angesehen wird. Wenn dieser Wert dieses Minimum nicht erreicht, löst der Producer eine Ausnahme aus (entweder oder). NotEnoughReplicas NotEnoughReplicasAfterAppend Wenn Sie die Werte in min.insync.replicas und acks zusammen verwenden, können Sie langfristigere Beständigkeitsgarantien durchsetzen. Zum Beispiel könnten Sie ein Thema mit dem Replikationsfaktor 3 erstellen, min.insync.replicas auf 2 einstellen und mit acks von `"all"` produzieren. Dadurch wird sichergestellt, dass der Produzent eine Ausnahme auslöst, wenn die Mehrheit der Replikate keinen Schreibvorgang erhält. | 2 für Cluster in 3 Availability Zones und 1 für Cluster in 2 Availability Zones. | 2 für Cluster in 3 Availability Zones und 1 für Cluster in 2 Availability Zones. |
| num.io.threads | Anzahl der Threads, die der Server für die Erzeugung von Anfragen verwendet, eventuell einschließlich Datenträger-I/O. | 8 | max (8, vCPUs) wobei v CPUs von der Instanzgröße des Brokers abhängt |
| num.network.threads | Anzahl der Threads, die der Server verwendet, um Anfragen vom Netzwerk zu empfangen und Antworten an das Netzwerk zu senden. | 5 | max (5, vCPUs /2) wobei v CPUs von der Instanzgröße des Brokers abhängt |
| num.partitions | Standardanzahl der Protokollpartitionen pro Thema. | 1 | 1 |
| num.replica.fetchers | Anzahl der Fetcher-Threads, die verwendet werden, um Nachrichten von einem Quell-Broker zu replizieren. Wenn Sie diesen Wert erhöhen, können Sie den Grad der I/O Parallelität im Follower-Broker erhöhen. | 2 | max (2, vCPUs /4), wobei v CPUs von der Instanzgröße des Brokers abhängt |
| remote.log.msk.disable.policy | Wird zusammen mit remote.storage.enable verwendet, um die gestaffelte Speicherung zu deaktivieren. Setzen Sie diese Richtlinie auf Löschen, um anzugeben, dass Daten im gestaffelten Speicher gelöscht werden, wenn Sie remote.storage.enable auf Falsch setzen. | – | Keine |
| remote.log.reader.threads | Größe des Threadpools für den Remote-Protokollleser, der bei der Planung von Aufgaben zum Abrufen von Daten aus dem Remote-Speicher verwendet wird. | – | max (10, v CPUs \$1 0.67) wobei v CPUs von der Instanzgröße des Brokers abhängt |
| remote.storage.enable | Aktiviert gestaffelte (Remote-)Speicherung für ein Thema, wenn dieser Wert auf Wahr gesetzt ist. Deaktiviert die gestaffelte Speicherung auf Themenebene, wenn der Wert auf Falsch gesetzt ist und remote.log.msk.disable.policy auf Löschen gesetzt ist. Wenn Sie die gestaffelte Speicherung deaktivieren, löschen Sie Daten aus dem Remote-Speicher. Wenn Sie die gestaffelte Speicherung für ein Thema deaktiviert haben, können Sie sie nicht erneut aktivieren. | false | false |
| replica.lag.time.max.ms | Wenn ein Follower für mindestens diese Anzahl von Millisekunden keine Abrufanforderungen gesendet hat oder nicht bis zum Protokollendversatz des Leaders konsumiert hat, entfernt der Leader den Follower aus dem ISR. | 30000 | 30000 |
| retention.ms | Plichtfeld. Die Mindestzeit beträgt 3 Tage. Es gibt keine Standardeinstellung, da die Einstellung ein Pflichtfeld ist. Amazon MSK verwendet den Wert retention.ms zusammen mit local.retention.ms, um zu bestimmen, wann Daten vom lokalen zum gestaffelten Speicher verschoben werden. Der Wert local.retention.ms gibt an, wann Daten vom lokalen in den gestaffelten Speicher verschoben werden sollen. Der Wert retention.ms gibt an, wann Daten aus dem Tiered Storage (d. h. aus dem Cluster) entfernt werden sollen. Gültige Werte: Ganzzahlen in [-1; \$1Inf] | Mindestens 259 200 000 Millisekunden (3 Tage). -1 für unendliche Aufbewahrung. | Mindestens 259 200 000 Millisekunden (3 Tage). -1 für unendliche Aufbewahrung. |
| socket.receive.buffer.bytes | Der SO\$1RCVBUF-Puffer der Socket-Server-Sockets. Wenn der Wert -1 ist, wird der Standardwert des Betriebssystems verwendet. | 102400 | 102400 |
| socket.request.max.bytes | Maximale Anzahl von Bytes in einer Socket-Anforderung. | 104857600 | 104857600 |
| socket.send.buffer.bytes | Der SO\$1SNDBUF-Puffer der Socket-Server-Sockets. Wenn der Wert -1 ist, wird der Standardwert des Betriebssystems verwendet. | 102400 | 102400 |
| unclean.leader.election.enable | Gibt an, ob Replikate, die nicht in der ISR-Gruppe enthalten sind, als letztes Mittel als Führer dienen sollen, auch wenn dies zu Datenverlust führen kann. | true | false |
| zookeeper.session.timeout.ms | Das Zeitlimit für die Apache-Sitzung in Millisekunden ZooKeeper . | 18000 | 18000 |
| zookeeper.set.acl | Der eingestellte Client, der sicher verwendet werden soll. ACLs | false | false |
Hinweise zum Angeben von benutzerdefinierten Konfigurationswerten finden Sie unter[Benutzerdefinierte Amazon MSK-Konfigurationen](msk-configuration-properties.md).
# Richtlinien für die Konfiguration von Amazon MSK Tiered Storage auf Themenebene
Im Folgenden finden Sie Standardeinstellungen und Einschränkungen bei der Konfiguration der gestaffelten Speicherung auf Themenebene.
+ Amazon MSK unterstützt keine kleineren Protokollsegmentgrößen für Themen, für die gestaffelte Speicherung aktiviert ist. Wenn Sie ein Segment erstellen möchten, gibt es eine Mindestgröße für das Protokoll-Segment von 48 MiB oder eine Mindest-Segment-Rollzeit von 10 Minuten. Diese Werte sind den Eigenschaften segment.bytes und segment.ms zugeordnet.
+ Der Wert von local.retention. ms/bytes can't equal or exceed the retention.ms/bytes. Dies ist die Aufbewahrungseinstellung der gestaffelten Speicherung.
+ Der Standardwert für für local.retention. ms/bytes is -2. This means that the retention.ms value is used for local.retention.ms/bytes. In diesem Fall verbleiben die Daten sowohl im lokalen als auch im gestaffelten Speicher (jeweils eine Kopie), und sie laufen zusammen ab. Bei dieser Option wird eine Kopie der lokalen Daten dauerhaft im Remote-Speicher gespeichert. In diesem Fall stammen die aus dem Verbraucherdatenverkehr gelesenen Daten aus dem lokalen Speicher.
+ Der Standardwert für retention.ms ist 7 Tage. Es gibt keine Standard-Größenbeschränkung für retention.bytes.
+ Der Mindestwert für retention.ms/bytes ist -1. Dies bedeutet unendliche Aufbewahrung.
+ Der Mindestwert für local.retention. ms/bytes is -2. This means infinite retention for local storage. It matches with the retention.ms/bytesEinstellung auf -1.
+ Die Konfiguration retention.ms auf Themenebene ist für Themen mit aktiviertem Tiered Storage obligatorisch. Der Mindestwert für retention.ms ist 3 Tage.
Weitere Hinweise zu Einschränkungen bei der mehrstufigen Speicherung finden Sie unter. [Mehrstufige Speicherbeschränkungen und Einschränkungen für Amazon MSK-Cluster](msk-tiered-storage.md#msk-tiered-storage-constraints)
# Express-Broker-Konfigurationen
Apache Kafka verfügt über Hunderte von Broker-Konfigurationen, mit denen Sie die Leistung Ihres von MSK bereitgestellten Clusters optimieren können. Das Einstellen fehlerhafter oder suboptimaler Werte kann sich auf die Zuverlässigkeit und Leistung des Clusters auswirken. Express-Broker verbessern die Verfügbarkeit und Haltbarkeit Ihrer von MSK bereitgestellten Cluster, indem sie optimale Werte für kritische Konfigurationen festlegen und diese vor häufigen Fehlkonfigurationen schützen. Es gibt drei Kategorien von Konfigurationen, die auf Lese- und Schreibzugriff basieren: Konfigurationen mit [Lese-/Schreibzugriff (bearbeitbar)](msk-configuration-express-read-write.md), Nur-Lese-Konfigurationen und Konfigurationen ohne [Lese-/Schreibzugriff](msk-configuration-express-read-only.md). Einige Konfigurationen verwenden immer noch den Standardwert von Apache Kafka für die Apache Kafka-Version, die auf dem Cluster ausgeführt wird. Wir kennzeichnen diese als Apache Kafka Default.
**Topics**
+ [Benutzerdefinierte MSK Express-Broker-Konfigurationen (Lese-/Schreibzugriff)](msk-configuration-express-read-write.md)
+ [Express vermittelt Konfigurationen, die nur lesbar sind](msk-configuration-express-read-only.md)
# Benutzerdefinierte MSK Express-Broker-Konfigurationen (Lese-/Schreibzugriff)
Sie können read/write Broker-Konfigurationen entweder mithilfe der [Konfigurationsaktualisierungsfunktion von Amazon MSK oder mithilfe der API von Apache Kafka aktualisieren](msk-update-cluster-config.md). AlterConfig Die Apache Kafka-Broker-Konfigurationen sind entweder statisch oder dynamisch. Statische Konfigurationen erfordern einen Broker-Neustart, damit die Konfiguration angewendet werden kann, während dynamische Konfigurationen keinen Broker-Neustart erfordern. Weitere Informationen zu Konfigurationseigenschaften und Aktualisierungsmodi finden Sie unter [Broker-Konfigurationen aktualisieren](https://kafka.apache.org/documentation/#dynamicbrokerconfigs).
**Topics**
+ [Statische Konfigurationen auf MSK Express-Brokern](#msk-configuration-express-static-configuration)
+ [Dynamische Konfigurationen auf Express Brokers](#msk-configuration-express-dynamic-configuration)
+ [Konfigurationen auf Themenebene auf Express Brokers](#msk-configuration-express-topic-configuration)
## Statische Konfigurationen auf MSK Express-Brokern
Sie können Amazon MSK verwenden, um eine benutzerdefinierte MSK-Konfigurationsdatei zu erstellen, um die folgenden statischen Eigenschaften festzulegen. Amazon MSK legt alle anderen Eigenschaften fest und verwaltet sie, die Sie nicht festlegen. Sie können statische Konfigurationsdateien über die MSK-Konsole oder mithilfe des Befehls [configurations](msk-configuration-operations-create.md) erstellen und aktualisieren.
| Property (Eigenschaft) | Description (Beschreibung) | Standardwert |
| --- | --- | --- |
| allow.everyone.if.no.acl.found | Wenn Sie diese Eigenschaft auf false setzen möchten, stellen Sie zunächst sicher, dass Sie Apache Kafka ACLs für Ihren Cluster definieren. Wenn Sie diese Eigenschaft auf false setzen und Apache Kafka nicht zuerst definieren ACLs, verlieren Sie den Zugriff auf den Cluster. In diesem Fall können Sie die Konfiguration erneut aktualisieren und diese Eigenschaft auf true setzen, um wieder Zugriff auf den Cluster zu erhalten. | true |
| auto.create.topics.enable | Aktiviert die automatische Erstellung eines Themas auf dem Server. | false |
| compression.type | Geben Sie den endgültigen Komprimierungstyp für ein bestimmtes Thema an. Diese Konfiguration akzeptiert die Standard-Komprimierungscodecs: gzip, snappy, lz4, zstd. Diese Konfiguration akzeptiert zusätzlich`uncompressed`, was gleichbedeutend mit keiner Komprimierung ist. Das bedeutet`producer`, dass der ursprüngliche vom Hersteller festgelegte Komprimierungscodec beibehalten wird. | Apache Kafka (Standard) |
| connections.max.idle.ms | Timeout bei inaktiven Verbindungen in Millisekunden. Die Threads des Server-Socket-Prozessors schließen die Verbindungen, die länger als den von Ihnen für diese Eigenschaft festgelegten Wert inaktiv sind. | Apache Kafka Standard |
| delete.topic.enable | Aktiviert den Vorgang zum Löschen von Themen. Wenn Sie diese Einstellung deaktivieren, können Sie ein Thema nicht über das Admin-Tool löschen. | Apache Kafka Standard |
| group.initial.rebalance.delay.ms | Die Zeit, die der Gruppenkoordinator darauf wartet, dass mehr Verbraucher einer neuen Gruppe beitreten, bevor der erste Neuausgleich durchgeführt wird. Eine längere Verzögerung bedeutet potenziell wenigere Neuausgleiche, erhöht aber die Zeit bis zum Beginn der Verarbeitung. | Apache Kafka Standard |
| group.max.session.timeout.ms | Maximales Sitzungs-Timeout für registrierte Konsumenten. Längere Timeouts verschaffen Verbrauchern mehr Zeit für die Verarbeitung von Nachrichten zwischen Heartbeats, sie führen aber auch zu einer längeren Fehlererkennungszeit. | Apache Kafka Standard |
| leader.imbalance.per.broker.percentage | Das Verhältnis des zulässigen Führungsungleichgewichts pro Broker. Der Controller löst einen Führungsausgleich aus, wenn er diesen Wert pro Broker übersteigt. Dieser Wert wird in Prozent angegeben. | Apache Kafka Standard |
| log.cleanup.policy | Die Standard-Bereinigungsrichtlinie für Segmente außerhalb des Aufbewahrungsfensters. Eine durch Kommata getrennte Liste gültiger Richtlinien. Gültige Richtlinien sind delete und compact. Für Cluster mit aktiviertem Tiered Storage gilt nur eine gültige Richtlinie. delete | Apache Kafka Standard |
| log.message.timestamp.after.max.ms | Die zulässige Zeitstempeldifferenz zwischen dem Nachrichtenzeitstempel und dem Zeitstempel des Brokers. Der Nachrichtenzeitstempel kann später als oder gleich dem Zeitstempel des Brokers sein, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied zwischen den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`. | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) |
| log.message.timestamp.before.max.ms | Die zulässige Zeitstempeldifferenz zwischen dem Zeitstempel des Brokers und dem Nachrichtenzeitstempel. Der Nachrichtenzeitstempel kann vor dem Zeitstempel des Brokers liegen oder diesem entsprechen, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied in den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`. | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) |
| log.message.timestamp.type | Gibt an, wenn der Zeitstempel in der Nachricht die Erstellungszeit der Nachricht oder die Anfügezeit des Protokolls widerspiegelt. Die zulässigen Werte sind CreateTime und LogAppendTime. | Apache Kafka Standard |
| log.retention.bytes | Maximale Größe des Protokolls vor dem Löschen. | Apache Kafka Standard |
| log.retention.ms | Anzahl der Millisekunden, für die eine Protokolldatei aufbewahrt werden muss, bevor sie gelöscht wird. | Apache Kafka Standard |
| max.connections.per.ip | Die maximale Anzahl von Verbindungen, die von jeder IP-Adresse aus zulässig sind. Dies kann auf eingestellt werden, 0 wenn mithilfe der max.connections.per.ip.overrides Eigenschaft Überschreibungen konfiguriert wurden. Neue Verbindungen von der IP-Adresse werden gelöscht, wenn das Limit erreicht wird. | Apache Kafka Standard |
| max.incremental.fetch.session.cache.slots | Maximale Anzahl inkrementeller Abrufsitzungen, die beibehalten werden. | Apache Kafka Standard |
| message.max.bytes | Die größte von Kafka unterstützte Protokoll-Batch-Größe. Wenn Sie diesen Wert erhöhen und Verbraucher älter als 0.10.2 vorhanden sind, müssen Sie auch die Abrufgröße der Verbraucher erhöhen, damit sie diese großen Datensatz-Batch abrufen können. In der neuesten Nachrichtenformat-Version werden Datensätze aus gründen der Effizienz immer in Batches gruppiert. In früheren Nachrichtenformat-Versionen werden nicht komprimierte Datensätze nicht in Batches gruppiert und diese Beschränkung gilt in diesem Fall nur für einen einzelnen Datensatz. Sie können diesen Wert pro Thema mit der `max.message.bytes` Konfiguration auf Themenebene festlegen. | Apache Kafka Standard |
| num.partitions | Standardanzahl von Partitionen pro Thema. | 1 |
| offsets.retention.minutes | Nachdem eine Konsumentengruppe alle Konsumenten verliert (d. h. sie ist dann leer), werden die Offsets für diesen Aufbewahrungszeitraum aufbewahrt, bevor sie verworfen werden. Für eigenständige Benutzer (d. h. Benutzer, die die manuelle Zuweisung verwenden) laufen Offsets nach dem Zeitpunkt der letzten Übertragung zuzüglich dieser Aufbewahrungsfrist ab. | Apache Kafka (Standard) |
| replica.fetch.max.bytes | Anzahl der Bytes von Nachrichten, die für jede Partition abgerufen werden sollen. Es handelt sich nicht um ein absolutes Maximum. Wenn der erste Datensatz-Batch in der ersten nicht leeren Partition des Abrufs größer ist als dieser Wert, wird der Datensatz-Batch zurückgegeben, damit Fortschritte gemacht werden können. Die Eigenschaften message.max.bytes (Broker-Konfiguration) oder max.message.bytes (Themenkonfiguration) geben die maximale vom Broker akzeptierte Datensatz-Batch-Größe an. | Apache Kafka Standard |
| replica.selector.class | Der vollqualifizierte Klassenname, der implementiert wird. ReplicaSelector Der Broker verwendet diesen Wert, um das bevorzugte Lesereplikat zu finden. Wenn Sie es Verbrauchern ermöglichen möchten, Daten vom nächstgelegenen Replikat abzurufen, setzen Sie diese Eigenschaft auf. `org.apache.kafka.common.replica.RackAwareReplicaSelector` | Apache Kafka Standard |
| socket.receive.buffer.bytes | Der SO\$1RCVBUF-Puffer der Socket-Server-Sockets. Wenn der Wert -1 ist, wird der Standardwert des Betriebssystems verwendet. | 102400 |
| socket.request.max.bytes | Maximale Anzahl von Bytes in einer Socket-Anforderung. | 104857600 |
| socket.send.buffer.bytes | Der SO\$1SNDBUF-Puffer der Socket-Server-Sockets. Wenn der Wert -1 ist, wird der Standardwert des Betriebssystems verwendet. | 102400 |
| transaction.max.timeout.ms | Maximales Timeout für Transaktionen. Wenn die angeforderte Transaktionszeit eines Kunden diesen Wert überschreitet, gibt der Broker einen Fehler in InitProducerIdRequest zurück. So wird ein zu großer Timeout auf Client-Seite verhindert, der Verbraucher am Lesen aus Themen, die in der Transaktion vorhanden sind, hindern könnte. | Apache Kafka (Standard) |
| transactional.id.expiration.ms | Die Zeit in Millisekunden, in der der Transaktionskoordinator auf Aktualisierungen des Transaktionsstatus für die aktuelle Transaktion wartet, bevor der Koordinator seine Transaktions-ID ablaufen lässt. Diese Einstellung beeinflusst auch den Ablauf der Producer-ID, da sie dazu führt IDs , dass der Producer abläuft, wenn diese Zeit nach dem letzten Schreibvorgang mit der angegebenen Producer-ID verstrichen ist. Producer läuft aufgrund der Aufbewahrungseinstellungen für das Thema IDs möglicherweise früher ab, wenn der letzte Schreibvorgang aus der Producer-ID gelöscht wird. Der Mindestwert für diese Eigenschaft ist 1 Millisekunde. | Apache Kafka (Standard) |
## Dynamische Konfigurationen auf Express Brokers
Sie können die Apache AlterConfig Kafka-API oder das Tool Kafka-configs.sh verwenden, um die folgenden dynamischen Konfigurationen zu bearbeiten. Amazon MSK legt alle anderen Eigenschaften fest und verwaltet sie, die Sie nicht festlegen. Sie können dynamisch Konfigurationseigenschaften auf Cluster- und Broker-Ebene festlegen, für die kein Neustart des Brokers erforderlich ist.
| Property (Eigenschaft) | Description (Beschreibung) | Standardwert |
| --- | --- | --- |
| advertised.listeners | Listener, die veröffentlicht werden sollen, damit Clients sie verwenden können, sofern sie sich von der Eigenschaft config unterscheiden. `listeners` In IaaS-Umgebungen muss sich dies möglicherweise von der Schnittstelle unterscheiden, an die der Broker bindet. Wenn dies nicht festgelegt ist, wird der Wert für Listener verwendet. Im Gegensatz zu Listenern ist es nicht zulässig, die 0.0.0.0-Metaadresse bekannt zu geben. Im Gegensatz dazu kann diese Eigenschaft doppelte Ports enthalten`listeners`, sodass ein Listener so konfiguriert werden kann, dass er die Adresse eines anderen Listeners bekannt gibt. Dies kann in einigen Fällen nützlich sein, in denen externe Load Balancer verwendet werden. Diese Eigenschaft wird auf Broker-Ebene festgelegt. | Null |
| compression.type | Der endgültige Komprimierungstyp für ein bestimmtes Thema. Sie können diese Eigenschaft auf die Standard-Komprimierungscodecs (`gzip`, `snappy`, `lz4` und `zstd`) festlegen. Akzeptiert zusätzlich `uncompressed`. Dieser Wert entspricht keiner Komprimierung. Wenn Sie den Wert auf `producer` setzen, bedeutet dies, dass der ursprüngliche Komprimierungs-Codec beibehalten wird, den der Produzent festlegt. | Apache Kafka (Standard) |
| log.cleaner.delete.retention.ms | Der Zeitraum, in dem gelöschte Tombstone-Markierungen für im Protokoll komprimierte Themen aufbewahrt werden sollen. Diese Einstellung gibt auch eine Grenze für die Zeit, in der ein Benutzer einen Lesevorgang abschließen muss, wenn er bei Offset 0 beginnt, um sicherzustellen, dass er einen gültigen Snapshot der letzten Phase erhält. Andernfalls könnten gelöschte Tombstones gesammelt werden, bevor der Scan abgeschlossen ist. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, also 1 Tag), Apache Kafka-Standardeinstellung |
| log.cleaner.min.compaction.lag.ms | Die Mindestdauer, für die eine Nachricht unkomprimiert im Protokoll verbleibt. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. | 0, Apache Kafka-Standard |
| log.cleaner.max.compaction.lag.ms | Die maximale Zeit, für die eine Nachricht im Protokoll nicht komprimiert werden kann. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. Diese Konfiguration wäre auf den Bereich [7 Tage, Long.Max] begrenzt. | 9223372036854775807, Apache Kafka Standard |
| log.cleanup.policy | Die Standard-Bereinigungsrichtlinie für Segmente außerhalb des Aufbewahrungsfensters. Eine durch Kommata getrennte Liste gültiger Richtlinien. Gültige Richtlinien sind `delete` und `compact`. Für Cluster mit aktiviertem Tiered Storage gilt nur eine gültige Richtlinie. `delete` | Apache Kafka Standard |
| log.message.timestamp.after.max.ms | Die zulässige Zeitstempeldifferenz zwischen dem Nachrichtenzeitstempel und dem Zeitstempel des Brokers. Der Nachrichtenzeitstempel kann später als oder gleich dem Zeitstempel des Brokers sein, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied zwischen den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`. | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) |
| log.message.timestamp.before.max.ms | Die zulässige Zeitstempeldifferenz zwischen dem Zeitstempel des Brokers und dem Nachrichtenzeitstempel. Der Nachrichtenzeitstempel kann vor dem Zeitstempel des Brokers liegen oder diesem entsprechen, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied in den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`. | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) |
| log.message.timestamp.type | Gibt an, wenn der Zeitstempel in der Nachricht die Erstellungszeit der Nachricht oder die Anfügezeit des Protokolls widerspiegelt. Die zulässigen Werte sind `CreateTime` und `LogAppendTime`. | Apache Kafka Standard |
| log.retention.bytes | Maximale Größe des Protokolls vor dem Löschen. | Apache Kafka Standard |
| log.retention.ms | Anzahl der Millisekunden, für die eine Protokolldatei aufbewahrt werden muss, bevor sie gelöscht wird. | Apache Kafka Standard |
| max.connection.creation.rate | Die maximale Verbindungsaufbaurate, die im Broker zu einem beliebigen Zeitpunkt zulässig ist. | Apache Kafka Standard |
| maximale Anzahl an Verbindungen | Die maximale Anzahl von Verbindungen, die im Broker zu einem beliebigen Zeitpunkt zulässig sind. Dieses Limit wird zusätzlich zu allen IP-Limits angewendet, die mit `max.connections.per.ip` konfiguriert wurden. | Apache Kafka Standard |
| max.connections.per.ip | Die maximale Anzahl von Verbindungen, die von jeder IP-Adresse aus zulässig sind. Dies kann auf eingestellt werden, `0` wenn mit der Eigenschaft max.connections.per.ip.overrides Überschreibungen konfiguriert wurden. Neue Verbindungen von der IP-Adresse werden unterbrochen, wenn das Limit erreicht wird. | Apache Kafka Standard |
| max.connections.per.ip.overrides | Eine durch Kommas getrennte Liste von IP-Adressen oder Hostnamen setzt die standardmäßige maximale Anzahl von Verbindungen außer Kraft. Ein Beispielwert ist `hostName:100,127.0.0.1:200` | Apache Kafka Standard |
| message.max.bytes | Die größte von Kafka unterstützte Protokoll-Batch-Größe. Wenn Sie diesen Wert erhöhen und Verbraucher älter als 0.10.2 vorhanden sind, müssen Sie auch die Abrufgröße der Verbraucher erhöhen, damit sie diese großen Datensatz-Batch abrufen können. In der neuesten Nachrichtenformat-Version werden Datensätze aus gründen der Effizienz immer in Batches gruppiert. In früheren Nachrichtenformat-Versionen werden nicht komprimierte Datensätze nicht in Batches gruppiert und diese Beschränkung gilt in diesem Fall nur für einen einzelnen Datensatz. Sie können diesen Wert pro Thema mit der `max.message.bytes` Konfiguration auf Themenebene festlegen. | Apache Kafka Standard |
| producer.id.expiration.ms | Die Zeit in ms, die ein Topic-Partitionsleiter abwartet, bevor der Producer abläuft. IDs Der Producer IDs läuft nicht ab, solange eine mit ihm verknüpfte Transaktion noch läuft. Beachten Sie, dass Producer IDs möglicherweise früher abläuft, wenn der letzte Schreibvorgang aus der Producer-ID aufgrund der Aufbewahrungseinstellungen des Themas gelöscht wird. Wenn Sie diesen Wert auf den gleichen Wert oder einen höheren Wert setzen, `delivery.timeout.ms` können Sie das Ablaufen bei Wiederholungsversuchen verhindern und die Duplizierung von Nachrichten verhindern. Die Standardeinstellung sollte jedoch für die meisten Anwendungsfälle angemessen sein. | Apache Kafka (Standard) |
## Konfigurationen auf Themenebene auf Express Brokers
Sie können Apache Kafka-Befehle verwenden, um Konfigurationseigenschaften auf Themenebene für neue und vorhandene Themen festzulegen oder zu ändern. Wenn Sie keine Konfiguration auf Themenebene angeben können, verwendet Amazon MSK den Broker-Standard. Wie bei Konfigurationen auf Brokerebene schützt Amazon MSK einige der Konfigurationseigenschaften auf Themenebene vor Änderungen. Beispiele hierfür sind der Replikationsfaktor und. `min.insync.replicas` `unclean.leader.election.enable` Wenn Sie versuchen, ein Thema mit einem anderen Replikationsfaktorwert als zu erstellen`3`, erstellt Amazon MSK das Thema standardmäßig mit einem Replikationsfaktor `3` von. Weitere Informationen zu Konfigurationseigenschaften auf Themenebene und Beispiele zum Festlegen dieser Eigenschaften finden Sie unter [Konfigurationen auf Themenebene](https://kafka.apache.org/documentation/#topicconfigs) in der Apache-Kafka-Dokumentation.
| Property (Eigenschaft) | Description (Beschreibung) |
| --- | --- |
| cleanup.policy | Diese Konfiguration legt die Aufbewahrungsrichtlinie fest, die für Protokollsegmente verwendet werden soll. Die Richtlinie „Löschen“ (die Standardeinstellung) verwirft alte Segmente, wenn ihre Aufbewahrungszeit oder Größenbeschränkung erreicht ist. Die Richtlinie „Compact“ ermöglicht die Protokollkomprimierung, bei der der aktuelle Wert für jeden Schlüssel beibehalten wird. Es ist auch möglich, beide Richtlinien in einer durch Kommas getrennten Liste anzugeben (z. B. „Löschen, Komprimieren“). In diesem Fall werden alte Segmente gemäß der Konfiguration für Aufbewahrungszeit und Größe verworfen, während die beibehaltenen Segmente komprimiert werden. Die Komprimierung auf Express-Brokern wird ausgelöst, wenn die Daten in einer Partition 256 MB erreicht haben. |
| compression.type | Geben Sie den endgültigen Komprimierungstyp für ein bestimmtes Thema an. Diese Konfiguration akzeptiert die Standard-Komprimierungscodecs (`gzip`,, `snappy``lz4`,`zstd`). Sie akzeptiert außerdem`uncompressed`, was einer Nichtkomprimierung entspricht, und `producer` das bedeutet, dass der vom Hersteller festgelegte ursprüngliche Komprimierungscodec beibehalten wird. |
| .retention.ms löschen | Der Zeitraum, in dem gelöschte Tombstone-Markierungen für im Protokoll komprimierte Themen aufbewahrt werden sollen. Diese Einstellung gibt auch eine Grenze für die Zeit, in der ein Benutzer einen Lesevorgang abschließen muss, wenn er bei Offset 0 beginnt, um sicherzustellen, dass er einen gültigen Snapshot der letzten Phase erhält. Andernfalls könnten gelöschte Tombstones gesammelt werden, bevor der Scan abgeschlossen ist. Der Standardwert für diese Einstellung ist 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, also 1 Tag), Apache Kafka Default |
| max.message.bytes | Die größte von Kafka zulässige Batchgröße für Datensätze (nach der Komprimierung, sofern die Komprimierung aktiviert ist). Wenn dieser Wert erhöht wird und es Verbraucher gibt, die älter sind als`0.10.2`, muss auch die Abrufgröße der Verbraucher erhöht werden, damit sie so große Datensatzstapel abrufen können. In der neuesten Nachrichtenformatversion werden Datensätze aus gründen der Effizienz immer in Stapeln gruppiert. In früheren Nachrichtenformatversionen werden nicht komprimierte Datensätze nicht in Stapeln gruppiert und diese Beschränkung gilt in diesem Fall nur für einen einzelnen Datensatz. Dies kann pro Thema mit der Themenebene festgelegt werden. `max.message.bytes config` |
| message.timestamp.after.max.ms | Diese Konfiguration legt die zulässige Zeitstempeldifferenz zwischen dem Nachrichtenzeitstempel und dem Zeitstempel des Brokers fest. Der Nachrichtenzeitstempel kann später als oder gleich dem Zeitstempel des Brokers sein, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied zwischen den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`message.timestamp.type=LogAppendTime`. |
| message.timestamp.before.max.ms | Diese Konfiguration legt die zulässige Zeitstempeldifferenz zwischen dem Zeitstempel des Brokers und dem Nachrichtenzeitstempel fest. Der Nachrichtenzeitstempel kann vor dem Zeitstempel des Brokers liegen oder diesem entsprechen, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied in den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`message.timestamp.type=LogAppendTime`. |
| message.timestamp.type | Definieren Sie, ob der Zeitstempel in der Nachricht die Erstellungszeit der Nachricht oder die Zeit für das Anhängen des Protokolls ist. Der Wert sollte entweder oder sein `CreateTime` `LogAppendTime` |
| min.compaction.lag.ms | Die Mindestdauer, für die eine Nachricht unkomprimiert im Protokoll verbleibt. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. Der Standardwert für diese Einstellung ist 0, Apache Kafka Default |
| max.compaction.lag.ms | Die maximale Zeit, für die eine Nachricht im Protokoll nicht komprimiert werden kann. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. Diese Konfiguration wäre auf den Bereich [7 Tage, Long.Max] begrenzt. Der Standardwert für diese Einstellung ist 9223372036854775807, Apache Kafka Default. |
| retention.bytes | Diese Konfiguration steuert die maximale Größe, auf die eine Partition (die aus Protokollsegmenten besteht) anwachsen kann, bevor wir alte Protokollsegmente verwerfen, um Speicherplatz freizugeben, wenn wir die Aufbewahrungsrichtlinie „Löschen“ verwenden. Standardmäßig gibt es keine Größenbeschränkung, nur eine Zeitbegrenzung. Da dieses Limit auf Partitionsebene durchgesetzt wird, multiplizieren Sie es mit der Anzahl der Partitionen, um die Beibehaltung des Themas in Byte zu berechnen. Darüber hinaus `retention.bytes configuration` funktioniert es unabhängig von `segment.ms` den `segment.bytes` Konfigurationen. Darüber hinaus löst es das Rollen eines neuen Segments aus, wenn das auf Null konfiguriert `retention.bytes` ist. |
| retention.ms | Diese Konfiguration legt fest, wie lange wir ein Protokoll maximal aufbewahren, bevor wir alte Protokollsegmente verwerfen, um Speicherplatz freizugeben, wenn wir die Aufbewahrungsrichtlinie „Löschen“ verwenden. Dies stellt eine SLA dar, die festlegt, wie schnell Verbraucher ihre Daten lesen müssen. Wenn auf gesetzt`-1`, wird kein Zeitlimit angewendet. Darüber hinaus funktioniert die `retention.ms` Konfiguration unabhängig von `segment.ms` den `segment.bytes` Konfigurationen. Darüber hinaus löst sie das Rollen eines neuen Segments aus, wenn die `retention.ms` Bedingung erfüllt ist. |
# Express vermittelt Konfigurationen, die nur lesbar sind
Amazon MSK legt die Werte für diese Konfigurationen fest und schützt sie vor Änderungen, die sich auf die Verfügbarkeit Ihres Clusters auswirken könnten. Diese Werte können sich je nach der Apache Kafka-Version, die auf dem Cluster ausgeführt wird, ändern. Denken Sie also daran, die Werte Ihres spezifischen Clusters zu überprüfen.
In der folgenden Tabelle sind die schreibgeschützten Konfigurationen für Express-Broker aufgeführt.
| Property (Eigenschaft) | Description (Beschreibung) | Der Wert von Express Broker |
| --- | --- | --- |
| broker.id | Die Broker-ID für diesen Server. | 1,2,3... |
| Broker.Rack | Rack des Brokers. Dies wird aus Gründen der Fehlertoleranz bei der Zuweisung von Replikationen mit Rack-Unterstützung verwendet. Beispiele: `RACK1`, `us-east-1d` | AZ-ID oder Subnetz-ID |
| default.replication.factor | Standardreplikationsfaktoren für alle Themen. | 3 |
| fetch.max.bytes | Die maximale Anzahl von Byte, die wir für eine Abrufanforderung zurückgeben. | Apache Kafka Standard |
| group.max.size | Die maximale Anzahl von Verbrauchern, die eine einzelne Verbrauchergruppe aufnehmen kann. | Apache Kafka Standard |
| inter.broker.listener.name | Name des Listeners, der für die Kommunikation zwischen Brokern verwendet wird. | REPLICATION\$1SECURE oder REPLICATION |
| inter.broker.protocol.version | Gibt an, welche Version des Inter-Broker-Protokolls verwendet wird. | Apache Kafka (Standard) |
| Listener | Listener-Liste — Kommagetrennte Liste der Listener-Namen, auf die URIs wir hören werden. Sie können die Eigenschaft festlegenadvertised.listeners property, aber nicht die Eigenschaft. listeners | Von MSK generiert |
| log.message.format.version | Geben Sie die Version des Nachrichtenformats an, die der Broker verwenden wird, um Nachrichten an die Protokolle anzuhängen. | Apache Kafka (Standard) |
| min.insync.replicas | Wenn ein Producer acks auf `all` (oder`-1`) setzt, `min.insync.replicas` gibt der Wert in die Mindestanzahl von Replikaten an, die einen Schreibvorgang bestätigen müssen, damit der Schreibvorgang als erfolgreich angesehen wird. Wenn dieses Minimum nicht erreicht werden kann, löst der Producer eine Ausnahme aus (entweder `NotEnoughReplicas` oder`NotEnoughReplicasAfterAppend`). Sie können die Value-Acks Ihres Herstellers verwenden, um höhere Haltbarkeitsgarantien durchzusetzen. Indem Sie Acks auf „Alle“ setzen. Dadurch wird sichergestellt, dass der Produzent eine Ausnahme auslöst, wenn die Mehrheit der Replikate keinen Schreibvorgang erhält. | 2 |
| num.io.threads | Anzahl der Threads, die der Server verwendet, um Anfragen zu erzeugen, die Festplatten-I/O beinhalten können. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 16), (m7g.4xlarge, 32), (m7g.8xlarge, 64), (m7g.12xlarge, 96), (m7g.16xlarge, 128) | Basierend auf dem Instanztyp. =Math.max (8, 2 \$1 v) CPUs |
| num.network.threads | Anzahl der Threads, die der Server verwendet, um Anfragen vom Netzwerk zu empfangen und Antworten an das Netzwerk zu senden. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 8), (m7g.4xlarge, 16), (m7g.8xlarge, 32), (m7g.12xlarge, 48), (m7g.16xlarge, 64) | Basiert auf dem Instanztyp. =Math.max (8, v) CPUs |
| replica.fetch.response.max.bytes | Die maximale Anzahl von Bytes, die für die gesamte Abrufantwort erwartet wird. Datensätze werden in Batches abgerufen und wenn der erste Datensatz-Batch in der ersten nicht leeren Partition des Abrufs größer ist als dieser Wert, wird der Datensatz-Batch weiterhin zurückgegeben, damit Fortschritte gemacht werden können. Es handelt sich nicht um ein absolutes Maximum. Die Eigenschaften message.max.bytes (broker config) oder max.message.bytes (topic config) geben die maximale Batchgröße von Datensätzen an, die der Broker akzeptiert. | Apache Kafka (Standard) |
| request.timeout.ms | Die Konfiguration steuert, wie lange der Client maximal auf die Antwort auf eine Anfrage wartet. Wenn die Antwort nicht vor Ablauf des Timeouts eingeht, sendet der Client die Anfrage gegebenenfalls erneut oder schlägt die Anfrage fehl, wenn die Wiederholungsversuche erschöpft sind. | Apache Kafka (Standard) |
| transaction.state.log.min.isr | Die min.insync.replicas Konfiguration für das Transaktionsthema wurde außer Kraft gesetzt. | 2 |
| transaction.state.log.replication.factor | Der Replikationsfaktor für das Transaktionsthema. | Apache Kafka (Standard) |
| unclean.leader.election.enable | Ermöglicht Replikaten, die nicht in der ISR-Gruppe enthalten sind, als letztes Mittel als führendes Mittel zu dienen, auch wenn dies zu Datenverlust führen kann. | FALSE |
# Operationen zur Broker-Konfiguration
Apache Kafka-Broker-Konfigurationen sind entweder statisch oder dynamisch. Statische Konfigurationen erfordern einen Neustart des Brokers, damit die Konfiguration angewendet werden kann. Dynamische Konfigurationen erfordern keinen Broker-Neustart, damit die Konfiguration aktualisiert wird. Weitere Informationen zu Konfigurationseigenschaften und Aktualisierungsmodi finden Sie unter Apache Kafka-Konfiguration.
In diesem Thema wird beschrieben, wie benutzerdefinierte MSK-Konfigurationen erstellt und Vorgänge an diesen ausgeführt werden. Informationen zur Verwendung von MSK-Konfigurationen zum Erstellen oder Aktualisieren von Clustern finden Sie unter [Die wichtigsten Funktionen und Konzepte von Amazon MSK](operations.md).
**Topics**
+ [Erstellen einer Konfiguration](msk-configuration-operations-create.md)
+ [Konfiguration aktualisieren](msk-configuration-operations-update.md)
+ [Konfiguration löschen](msk-configuration-operations-delete.md)
+ [Rufen Sie die Konfigurationsmetadaten ab](msk-configuration-operations-describe.md)
+ [Erfahren Sie mehr über die Revision der Konfiguration](msk-configuration-operations-describe-revision.md)
+ [Listet die Konfigurationen in Ihrem Konto für die aktuelle Region auf](msk-configuration-operations-list.md)
+ [Amazon MSK-Konfigurationsstatus](msk-configuration-states.md)
# Erstellen einer Konfiguration
In diesem Prozess wird beschrieben, wie Sie eine benutzerdefinierte Amazon MSK-Konfiguration erstellen und Operationen damit durchführen.
1. Erstellen Sie eine Datei, in der Sie die festzulegenden Konfigurationseigenschaften und die Werte angeben, die Sie ihnen zuweisen möchten. Im Folgenden finden Sie den Inhalt einer Beispielkonfigurationsdatei.
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
1. Führen Sie den folgenden AWS CLI Befehl aus und *config-file-path* ersetzen Sie ihn durch den Pfad zu der Datei, in der Sie Ihre Konfiguration im vorherigen Schritt gespeichert haben.
**Anmerkung**
Der Name, den Sie für Ihre Konfiguration auswählen, muss mit dem folgenden regulären Ausdruck übereinstimmen: „^[0-9A-Za-z][0-9A-Za-z-]\$10,\$1\$1“.
```
aws kafka create-configuration --name "ExampleConfigurationName" --description "Example configuration description." --kafka-versions "1.1.1" --server-properties fileb://config-file-path
```
Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-21T19:37:40.626Z",
"LatestRevision": {
"CreationTime": "2019-05-21T19:37:40.626Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
```
1. Der vorherige Befehl gibt einen Amazon-Ressourcennamen (ARN) für die neue Konfiguration zurück. Speichern Sie diesen ARN, da Sie bei anderen Befehlen auf diese Konfiguration verweisen müssen. Wenn Sie den Konfigurations-ARN verlieren, finden Sie ihn in der Konfigurationsliste in Ihrem Konto wieder.
# Konfiguration aktualisieren
Dieser Prozess beschreibt, wie eine benutzerdefinierte Amazon MSK-Konfiguration aktualisiert wird.
1. Erstellen Sie eine Datei, in der Sie die zu aktualisierenden Konfigurationseigenschaften angeben, und die Werte, die Sie ihnen zuweisen möchten. Im Folgenden finden Sie den Inhalt einer Beispielkonfigurationsdatei.
```
auto.create.topics.enable = true
min.insync.replicas = 2
```
1. Führen Sie den folgenden AWS CLI Befehl aus und *config-file-path* ersetzen Sie ihn durch den Pfad zu der Datei, in der Sie Ihre Konfiguration im vorherigen Schritt gespeichert haben.
*configuration-arn*Ersetzen Sie es durch den ARN, den Sie bei der Erstellung der Konfiguration erhalten haben. Wenn Sie den ARN beim Erstellen der Konfiguration nicht gespeichert haben, können Sie den `list-configurations`-Befehl verwenden, um alle Konfigurationen in Ihrem Konto aufzulisten. Die Konfiguration, die Sie in der Liste haben möchten, wird in der Antwort angezeigt. Der ARN der Konfiguration wird ebenfalls in dieser Liste angezeigt.
```
aws kafka update-configuration --arn configuration-arn --description "Example configuration revision description." --server-properties fileb://config-file-path
```
1. Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"LatestRevision": {
"CreationTime": "2020-08-27T19:37:40.626Z",
"Description": "Example configuration revision description.",
"Revision": 2
}
}
```
# Konfiguration löschen
Das folgende Verfahren zeigt, wie Sie eine Konfiguration löschen, die nicht einem Cluster angefügt ist. Sie können eine Konfiguration nicht löschen, die einem Cluster angefügt ist.
1. Um dieses Beispiel auszuführen, *configuration-arn* ersetzen Sie es durch den ARN, den Sie bei der Erstellung der Konfiguration erhalten haben. Wenn Sie den ARN beim Erstellen der Konfiguration nicht gespeichert haben, können Sie den `list-configurations`-Befehl verwenden, um alle Konfigurationen in Ihrem Konto aufzulisten. Die Konfiguration, die Sie in der Liste haben möchten, wird in der Antwort angezeigt. Der ARN der Konfiguration wird ebenfalls in dieser Liste angezeigt.
```
aws kafka delete-configuration --arn configuration-arn
```
1. Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"arn": " arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"state": "DELETING"
}
```
# Rufen Sie die Konfigurationsmetadaten ab
Das folgende Verfahren zeigt, wie eine Amazon MSK-Konfiguration beschrieben wird, um Metadaten über die Konfiguration abzurufen.
1. Der folgende Befehl gibt Metadaten zur Konfiguration zurück. Um eine detaillierte Beschreibung der Konfiguration zu erhalten, führen Sie `describe-configuration-revision` aus .
Um dieses Beispiel auszuführen, *configuration-arn* ersetzen Sie es durch den ARN, den Sie bei der Erstellung der Konfiguration erhalten haben. Wenn Sie den ARN beim Erstellen der Konfiguration nicht gespeichert haben, können Sie den `list-configurations`-Befehl verwenden, um alle Konfigurationen in Ihrem Konto aufzulisten. Die Konfiguration, die Sie in der Liste haben möchten, wird in der Antwort angezeigt. Der ARN der Konfiguration wird ebenfalls in dieser Liste angezeigt.
```
aws kafka describe-configuration --arn configuration-arn
```
1. Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
}
```
# Erfahren Sie mehr über die Revision der Konfiguration
Bei diesem Vorgang erhalten Sie eine detaillierte Beschreibung der Amazon MSK-Konfigurationsrevision.
Wenn Sie den `describe-configuration`-Befehl verwenden, um eine MSK-Konfiguration zu beschreiben, erhalten Sie die Metadaten der Konfiguration. Um eine Beschreibung der Konfiguration zu erhalten, verwenden Sie den Befehl `describe-configuration-revision`.
+ Führen Sie den folgenden Befehl aus und *configuration-arn* ersetzen Sie ihn durch den ARN, den Sie bei der Erstellung der Konfiguration erhalten haben. Wenn Sie den ARN beim Erstellen der Konfiguration nicht gespeichert haben, können Sie den `list-configurations`-Befehl verwenden, um alle Konfigurationen in Ihrem Konto aufzulisten. Die Konfiguration, die Sie in der Liste suchen, wird in der Antwort angezeigt. Der ARN der Konfiguration wird ebenfalls in dieser Liste angezeigt.
```
aws kafka describe-configuration-revision --arn configuration-arn --revision 1
```
Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1,
"ServerProperties": "YXV0by5jcmVhdGUudG9waWNzLmVuYWJsZSA9IHRydWUKCgp6b29rZWVwZXIuY29ubmVjdGlvbi50aW1lb3V0Lm1zID0gMTAwMAoKCmxvZy5yb2xsLm1zID0gNjA0ODAwMDAw"
}
```
Der Wert von `ServerProperties` wird mit base64 codiert. Wenn Sie einen base64-Decoder (z. B. https://www.base64decode.org/) verwenden, um den Wert manuell zu dekodieren, erhalten Sie den Inhalt der ursprünglichen Konfigurationsdatei, mit der Sie die benutzerdefinierte Konfiguration erstellt haben. In diesem Fall erhalten Sie Folgendes:
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
# Listet die Konfigurationen in Ihrem Konto für die aktuelle Region auf
Dieser Prozess beschreibt, wie Sie alle Amazon MSK-Konfigurationen in Ihrem Konto für die aktuelle AWS Region auflisten.
+ Führen Sie den folgenden Befehl aus.
```
aws kafka list-configurations
```
Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"Configurations": [
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
},
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
]
}
```
# Amazon MSK-Konfigurationsstatus
Eine Amazon-MSK-Konfiguration kann sich in einem der folgenden Status befinden. Um einen Vorgang an einer Konfiguration durchzuführen, muss sich die Konfiguration im Status `ACTIVE` oder `DELETE_FAILED` befinden:
+ `ACTIVE`
+ `DELETING`
+ `DELETE_FAILED`
# Intelligentes Rebalancing für Cluster
Amazon MSK bietet intelligentes Rebalancing für alle neuen MSK Provisioned Cluster mit Express-Brokern. Diese Funktion verwaltet automatisch die Partitionsverteilung und die Clusterskalierung, sodass keine Tools von Drittanbietern erforderlich sind. Intelligentes Rebalancing gleicht Partitionen automatisch neu aus, wenn Sie Cluster nach oben oder unten skalieren. Außerdem überwacht es kontinuierlich den Zustand Ihres Clusters im Hinblick auf ein Ungleichgewicht oder eine Überlastung der Ressourcen und verteilt die Arbeitslast neu.
Intelligentes Rebalancing ermöglicht schnelle Skalierungsvorgänge, die innerhalb von 30 Minuten abgeschlossen werden und die Cluster-Verfügbarkeit während der Skalierung nicht beeinträchtigt. Es ist standardmäßig für alle neuen bereitgestellten MSK Express-basierten Cluster aktiviert und funktioniert mit der empfohlenen maximalen Partitionsbeschränkung von 20.000 Partitionen pro Broker. Darüber hinaus ist diese Funktion ohne zusätzliche Kosten verfügbar und erfordert keine Konfiguration.
Ab dem 20. November 2025 ist Intelligent Rebalancing in allen AWS Regionen verfügbar, in denen Amazon MSK Express-Broker unterstützt werden.
**Topics**
+ [So funktioniert intelligentes Rebalancing](#how-intelligent-rebalancing-works)
+ [Überwachung intelligenter Rebalancing-Metriken](#intelligent-rebalancing-metrics)
+ [Überlegungen zur Verwendung von intelligentem Rebalancing](#intelligent-rebalancing-considerations)
+ [Skalieren von Amazon MSK-Clustern mit einem einzigen Vorgang nach oben und unten](intelligent-rebalancing-scaling-clusters.md)
+ [Steady-State-Rebalancing für Amazon MSK-Cluster](intelligent-rebalancing-self-balancing-paritions.md)
## So funktioniert intelligentes Rebalancing
Intelligentes Rebalancing ist standardmäßig für alle neuen MSK Provisioned Cluster mit Express-Brokern aktiviert. Es beinhaltet Unterstützung für die folgenden Situationen:
+ **Hoch- und Herunterskalierung**: Ermöglicht das Hinzufügen oder Entfernen von Brokern zu Ihren MSK Express-basierten Clustern mit einem einzigen Klick. Sobald Sie angegeben haben, welche Broker hinzugefügt oder entfernt werden sollen, verteilt das intelligente Rebalancing die Partitionen automatisch auf der Grundlage interner Best Practices im neuen Cluster-Setup neu. AWS
+ **Steady-State-Rebalancing**: Im Steady-State-Modus überwacht diese Funktion kontinuierlich den Zustand Ihres Clusters und gleicht Partitionen automatisch neu aus, wenn:
+ Die Ressourcennutzung ist von Broker zu Broker unterschiedlich.
+ Makler werden entweder zu viel bereitgestellt oder nicht ausreichend genutzt.
+ Neue Makler werden hinzugefügt oder bestehende Broker werden entfernt.
**Anmerkung**
Wenn das intelligente Rebalancing aktiviert ist, können Sie keine Tools von Drittanbietern wie Cruise Control für das Rebalancing von Partitionen verwenden. Sie müssen zuerst die intelligente Neuverteilung unterbrechen, um die von diesen Drittanbieter-Tools bereitgestellte API zur Neuzuweisung von Partitionen verwenden zu können.
Sie können diese Funktion in der Amazon MSK-Konsole verwenden. Sie können diese Funktion auch mit Amazon MSK APIs oder AWS SDK und AWS CloudFormation verwenden. AWS CLI Weitere Informationen erhalten Sie unter [Skalierung von Amazon MSK-Clustern](intelligent-rebalancing-scaling-clusters.md) und [Stabile Neugewichtung](intelligent-rebalancing-self-balancing-paritions.md).
## Überwachung intelligenter Rebalancing-Metriken
Sie können den Status laufender und historischer intelligenter Rebalancing-Operationen anhand der folgenden CloudWatch Amazon-Metriken überwachen:
+ `RebalanceInProgress`: Diese Metrik wird jede Minute mit dem Wert 1 veröffentlicht, wenn der Rebalancing noch nicht abgeschlossen ist, und andernfalls 0.
+ `UnderProvisioned`: Zeigt an, dass ein Cluster derzeit zu wenig bereitgestellt wird und kein Partitionsneuausgleich durchgeführt werden kann. Sie müssen entweder weitere Broker hinzufügen oder den Instance-Typ Ihres Clusters skalieren.
Informationen zur Überwachung eines von MSK bereitgestellten Clusters finden Sie unter und. [](monitoring.md) [](cloudwatch-metrics.md)
## Überlegungen zur Verwendung von intelligentem Rebalancing
+ Support für intelligentes Rebalancing ist nur für neue von MSK bereitgestellte Cluster mit Express-Brokern verfügbar.
+ Für die automatische Neuzuweisung von Partitionen ist die maximale Unterstützung für bis zu 20.000 Partitionen pro Broker verfügbar.
+ Sie können keine Tools zur Neuzuweisung von Partitionen APIs oder Tools für die Neuverteilung von Drittanbietern verwenden, wenn die intelligente Neuverteilung aktiviert ist. Um solche Tools APIs oder Tools von Drittanbietern zu verwenden, müssen Sie zunächst die intelligente Neuverteilung für Ihren MSK Express-basierten Cluster unterbrechen.
# Skalieren von Amazon MSK-Clustern mit einem einzigen Vorgang nach oben und unten
Mit intelligentem Rebalancing können Sie Ihre Cluster nach oben oder unten skalieren, indem Sie die Anzahl der Broker in Ihren Clustern in einer einzigen Aktion bearbeiten. Sie können dies in der Amazon MSK-Konsole oder mithilfe von Amazon MSK APIs oder AWS SDK und tun. AWS CLI AWS CloudFormation Wenn Sie die Anzahl der Makler ändern, geht Amazon MSK wie folgt vor:
+ Verteilt Partitionen automatisch an neue Broker.
+ Verschiebt Partitionen von Brokern, die entfernt werden.
Wenn Sie Ihre Cluster nach oben oder unten skalieren, bleibt die Cluster-Verfügbarkeit für Clients zur Erzeugung und Nutzung von Daten unberührt.
**Topics**
------
#### [ Scaling clusters using AWS-Managementkonsole ]
1. Die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause öffnen? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie auf der Seite Cluster einen neu erstellten Express-basierten **Cluster** aus. Informationen zum Erstellen eines bereitgestellten Express-basierten Clusters finden Sie unter. [Schritt 1: Erstellen Sie einen von MSK bereitgestellten Cluster](create-cluster.md)
1. Wählen Sie in der Dropdownliste **Aktionen** die Option **Anzahl der Broker bearbeiten** aus.
1. Führen Sie auf der Seite **Anzahl der Broker pro Zone bearbeiten** eine der folgenden Aktionen aus:
+ Um Ihrem Cluster weitere Broker hinzuzufügen, wählen Sie **Broker zu jeder Availability Zone hinzufügen** und geben Sie dann die Anzahl der Broker ein, die Sie hinzufügen möchten.
+ Um Broker aus Ihrem Cluster zu **entfernen, wählen Sie Einen Broker aus jeder Availability Zone** entfernen.
1. Wählen Sie **Änderungen speichern ** aus.
------
#### [ Scaling clusters using AWS CLI ]
Sie können Ihre Cluster nach oben oder unten skalieren, indem Sie deren Broker-Anzahl bearbeiten. Um dies in der zu tun AWS CLI, verwenden Sie den [update-broker-count](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-broker-count.html)Befehl, wie im folgenden Beispiel gezeigt. Geben Sie in diesem Befehl die Anzahl der Broker, die Sie in Ihrem Cluster haben möchten, im `target-broker-count` Parameter an.
```
aws msk update-broker-count --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --target-broker-count 6
```
------
#### [ Scaling clusters using AWS SDK ]
Sie können Ihre Cluster nach oben oder unten skalieren, indem Sie die Anzahl der Broker programmgesteuert bearbeiten. Verwenden Sie dazu mithilfe des AWS SDK die [UpdateBrokerCount](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-count.html#UpdateBrokerCount)API, wie im folgenden Beispiel gezeigt. Geben Sie für den `TargetNumberOfBrokerNodes` Parameter die Anzahl der Broker an, die Sie in Ihrem Cluster haben möchten.
```
update_broker_count_response = client.update_broker_count(
ClusterArn='arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1',
CurrentVersion='ABCDEF1GHIJK0L',
TargetNumberOfBrokerNodes=6
)
```
------
# Steady-State-Rebalancing für Amazon MSK-Cluster
Steady-State-Rebalancing ist Teil der intelligenten Rebalancing-Funktion, die standardmäßig für alle neuen MSK Provisioned Cluster mit Express-Brokern aktiviert ist. Wenn Sie Ihre Cluster nach oben oder unten skalieren, übernimmt Amazon MSK automatisch die Partitionsverwaltung, indem es Partitionen an neue Broker verteilt und Partitionen von Brokern verschiebt, die entfernt werden müssen. Um eine optimale Verteilung der Arbeitslast auf die Makler zu gewährleisten, verwendet Intelligent Rebalancing die Best Practices von Amazon MSK, um Schwellenwerte für die automatische Initiierung des Rebalancing für Ihre Broker festzulegen.
Sie können den Steady-State-Rebalancing bei Bedarf anhalten und wieder aufnehmen. Beim Steady-State-Rebalancing wird Ihr Cluster kontinuierlich überwacht und es werden folgende Aktionen ausgeführt:
+ Verfolgt die Nutzung von Broker-Ressourcen (CPU, Netzwerk, Speicher).
+ Passt die Partitionsplatzierung automatisch an, ohne die Datenverfügbarkeit zu beeinträchtigen.
+ Schließt Neuausgleichsvorgänge bei Express-Brokern bis zu 180-mal schneller ab als bei Standard-Brokern.
+ Hält die Cluster-Leistung aufrecht.
**Topics**
------
#### [ Pause and resume steady state rebalancing in AWS-Managementkonsole ]
1. Die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause öffnen? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. **Wählen Sie auf der Cluster-Seite einen Express-basierten Cluster aus.** Informationen zum Erstellen eines bereitgestellten Express-basierten Clusters finden Sie unter. [Schritt 1: Erstellen Sie einen von MSK bereitgestellten Cluster](create-cluster.md)
1. **Vergewissern Sie sich auf der Cluster-Detailseite, dass der Status **Intelligent Rebalancing Aktiv lautet**.** Wenn Intelligent Rebalancing nicht verfügbar ist oder der Status „Angehalten“ lautet, erstellen Sie einen **neuen** Express-basierten Cluster.
1. **Wählen Sie in der Dropdownliste **Aktionen** die Option Intelligentes Rebalancing bearbeiten aus.**
1. Gehen Sie auf der Seite **Intelligentes Rebalancing bearbeiten** wie folgt vor:
1. Wählen Sie „Angehalten“**.**
1. Wählen Sie **Änderungen speichern ** aus.
------
#### [ Pause and resume steady state rebalancing using AWS CLI ]
Um den Rebalancing-Status eines Clusters auf die **ACTIVE** Verwendung von einzustellen AWS CLI, verwenden Sie den Befehl [update-rebalancing](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-rebalancing.html), wie im folgenden Beispiel gezeigt. Geben Sie in diesem Befehl den Status mit dem Parameter an. `rebalancing`
```
aws msk update-rebalancing --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --rebalancing "{\"Rebalancing\":{\"Status\":\"ACTIVE\"}}"
```
------
#### [ Pause and resume steady state rebalancing using AWS SDK ]
Sie können den Rebalancing-Status eines Clusters auch mithilfe der [UpdateRebalancingRequest](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-rebalancing.html#UpdateRebalancing)API festlegen, um die Anzahl der Broker programmgesteuert zu ändern. Die folgenden Beispiele zeigen, wie der Rebalancing-Status auf und gesetzt wird. **ACTIVE** **PAUSED**
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("ACTIVE"));
```
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("PAUSED"));
```
------
# Patchen auf von MSK bereitgestellten Clustern
In regelmäßigen Abständen aktualisiert Amazon MSK die Software auf den Brokern in Ihrem Cluster. Die Wartung umfasst geplante Updates oder ungeplante Reparaturen. Die geplante Wartung umfasst Betriebssystemupdates, Sicherheitsupdates und andere Softwareupdates, die zur Aufrechterhaltung der Integrität, Sicherheit und Leistung Ihres Clusters erforderlich sind. Wir führen ungeplante Wartungsarbeiten durch, um plötzliche Beeinträchtigungen der Infrastruktur zu beheben. Wir führen Wartungsarbeiten bei Standard- und Express-Brokern durch, aber die Erfahrungen sind unterschiedlich.
## Patchen für Standard-Broker
[Aktualisierungen Ihrer Standard-Broker haben keine Auswirkungen auf die Schreib- und Lesevorgänge Ihrer Anwendungen, wenn Sie sich an bewährte Methoden halten.](bestpractices.md)
Amazon MSK verwendet fortlaufende Updates für Software, um die hohe Verfügbarkeit Ihrer Cluster aufrechtzuerhalten. Während dieses Vorgangs werden die Broker nacheinander neu gestartet, und Kafka überträgt die Leitung automatisch auf einen anderen Online-Broker. Wenn Sie Clustervorgänge im AWS-Managementkonsole oder über `DescribeClusterOperation` und anzeigen `ListClusterOperations` APIs, werden diese Wartungsvorgänge mit dem Operationstyp angezeigt. `SECURITY_PATCHING` Kafka-Clients verfügen über integrierte Mechanismen, mit denen der Wechsel in der Führung der Partitionen automatisch erkannt und weiterhin Daten in einen MSK-Cluster geschrieben und gelesen werden können. Folgen Sie [Bewährte Methoden für Apache Kafka-Kunden](bestpractices-kafka-client.md) diesen Regeln, um jederzeit einen reibungslosen Betrieb Ihres Clusters zu gewährleisten, auch beim Patchen.
Wenn ein Broker offline geht, ist es normal, dass bei Ihren Clients vorübergehende Verbindungsfehler auftreten. Außerdem werden Sie für einen kurzen Zeitraum (bis zu 2 Minuten, in der Regel weniger) einige Spitzen in der p99-Lese- und Schreiblatenz beobachten (typischerweise hohe Millisekunden, bis zu \$12 Sekunden). Diese Spitzenwerte sind zu erwarten und werden dadurch verursacht, dass der Kunde erneut eine Verbindung zu einem neuen führenden Broker herstellt. Sie wirken sich nicht auf Ihre Produktion oder Ihren Verbrauch aus und werden nach der erneuten Verbindung wieder behoben. Weitere Informationen finden Sie unter [Broker-Offline](https://docs.aws.amazon.com/msk/latest/developerguide/troubleshooting-offlinebroker-clientfailover.html) und Client-Failover.
Sie werden auch einen Anstieg der Metrik feststellen`UnderReplicatedPartitions`, was zu erwarten ist, da die Partitionen auf dem heruntergefahrenen Broker keine Daten mehr replizieren. Dies hat keine Auswirkungen auf die Schreib- und Lesevorgänge der Anwendungen, da Replikate für diese Partitionen, die auf anderen Brokern gehostet werden, die Anfragen jetzt bearbeiten.
Wenn der Broker nach dem Softwareupdate wieder online ist, muss er die Nachrichten „catch“, die während des Offline-Betriebs generiert wurden. Während der Nachholphase können Sie auch einen Anstieg der Auslastung des Volumendurchsatzes und der CPU beobachten. Diese sollten keine Auswirkungen auf Schreib- und Lesevorgänge in den Cluster haben, wenn Sie über genügend CPU-, Arbeitsspeicher-, Netzwerk- und Volume-Ressourcen auf Ihren Brokern verfügen.
## Patchen für Express-Broker
Es gibt keine Wartungsfenster für Express-Broker. Amazon MSK aktualisiert Ihren Cluster automatisch fortlaufend und zeitverteilt, sodass Sie im Laufe des Monats mit gelegentlichen und einmaligen Broker-Neustarts rechnen können. Dadurch wird sichergestellt, dass Sie keine Pläne oder Vorkehrungen für einmalige, clusterweite Wartungsfenster treffen müssen. Wie immer bleibt der Datenverkehr während eines Broker-Neustarts ununterbrochen, da die Leitung zu anderen Brokern wechselt, die weiterhin Anfragen bearbeiten werden. Wenn Sie Clustervorgänge im AWS-Managementkonsole oder über `DescribeClusterOperation` und anzeigen `ListClusterOperations` APIs, werden diese Wartungsvorgänge mit dem Operationstyp `BROKER_UPDATE` angezeigt.
Express-Broker sind mit bewährten Einstellungen und Leitplanken konfiguriert, sodass Ihr Cluster widerstandsfähig gegenüber Laständerungen ist, die während der Wartung auftreten können. Amazon MSK legt Durchsatzquoten für Ihre Express-Broker fest, um die Auswirkungen einer Überlastung Ihres Clusters zu minimieren, die zu Problemen bei Broker-Neustarts führen kann. Durch diese Verbesserungen entfällt die Notwendigkeit von Vorabbenachrichtigungen, Planungs- und Wartungsfenstern, wenn Sie Express Brokers verwenden.
Express-Broker replizieren Ihre Daten immer auf drei Arten, sodass Ihre Kunden bei Neustarts automatisch ein Failover durchführen. Sie müssen sich keine Sorgen machen, dass Themen aufgrund des auf 1 oder 2 eingestellten Replikationsfaktors nicht mehr verfügbar sind. Außerdem ist die catch nach einem neu gestarteten Express-Broker schneller als bei Standard-Brokern. Die schnellere Patch-Geschwindigkeit bei Express-Brokern bedeutet, dass die Planung aller Aktivitäten auf der Kontrollebene, die Sie möglicherweise für Ihren Cluster geplant haben, nur minimal unterbrochen wird.
Wie bei allen Apache Kafka-Anwendungen gibt es immer noch einen gemeinsamen Client-Server-Vertrag für Clients, die eine Verbindung zu Express-Brokern herstellen. Es ist nach wie vor wichtig, dass Sie Ihre Clients so konfigurieren, dass sie das Management Failover zwischen Brokern bewältigen können. Folgen Sie den Anweisungen [Bewährte Methoden für Apache Kafka-Kunden](bestpractices-kafka-client.md) für einen reibungslosen Betrieb Ihres Clusters zu jeder Zeit, auch beim Patchen. Nach einem Neustart des Brokers ist es normal, dass [auf Ihren Clients vorübergehende Verbindungsfehler auftreten](troubleshooting-offlinebroker-clientfailover.md). Dies hat keine Auswirkungen auf Ihre Produktion und Ihren Konsum, da die Follower-Broker die Partitionsführung übernehmen. Ihre Apache Kafka-Clients werden automatisch ein Failover durchführen und beginnen, Anfragen an die neuen Leader-Broker zu senden.
# Broker offline und Client-Failover
Kafka ermöglicht einen Offline-Broker. Ein einziger Offline-Broker in einem gesunden und ausgewogenen Cluster, der sich an bewährte Methoden hält, hat keine Auswirkungen und führt auch nicht zu Produktionsausfällen oder Ausfällen bei der Produktion oder Nutzung. Das liegt daran, dass ein anderer Broker die Partitionsleitung übernimmt und dass die Kafka-Clientbibliothek automatisch ein Failover durchführt und Anfragen an die neuen Leader-Broker sendet.
**Client-Server-Vertrag**
Dies führt zu einem gemeinsamen Vertrag zwischen der Client-Bibliothek und dem serverseitigen Verhalten. Der Server muss erfolgreich einen oder mehrere neue Leader zuweisen, und der Client muss den Broker wechseln, um Anfragen rechtzeitig an die neuen Leader zu senden.
Kafka verwendet Ausnahmen, um diesen Ablauf zu kontrollieren:
**Ein Beispiel für ein Verfahren**
1. Broker A wechselt in einen Offline-Status.
1. Der Kafka-Client erhält eine Ausnahme (normalerweise wird das Netzwerk getrennt oder not\$1leader\$1for\$1partition).
1. Diese Ausnahmen veranlassen den Kafka-Client, seine Metadaten zu aktualisieren, sodass er über die neuesten Führungskräfte informiert ist.
1. Der Kafka-Client setzt das Senden von Anfragen an die neuen Partitionsleiter auf anderen Brokern fort.
Dieser Vorgang dauert mit dem angebotenen Java-Client und den Standardkonfigurationen in der Regel weniger als 2 Sekunden. Die Fehler auf der Clientseite sind ausführlich und wiederholen sich, geben jedoch keinen Anlass zur Sorge, was durch die Stufe „WARN“ gekennzeichnet ist.
**Beispiel: Ausnahme 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`
**Beispiel: Ausnahme 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"`
Kafka-Clients beheben diese Fehler automatisch in der Regel innerhalb von 1 Sekunde und höchstens 3 Sekunden. Dies zeigt sich in den clientseitigen Metriken als produce/consume Latenz bei p99 (typischerweise hohe Millisekunden in den 100ern). Länger als dieser Wert deutet in der Regel auf ein Problem mit der Client-Konfiguration oder der serverseitigen Controller-Auslastung hin. Weitere Informationen finden Sie im Abschnitt zur Fehlerbehebung.
Ein erfolgreicher Failover kann überprüft werden, indem die Zunahme der `BytesInPerSec` `LeaderCount` Messwerte bei anderen Brokern überprüft wird. Dies beweist, dass sich der Traffic und die Führung erwartungsgemäß entwickelt haben. Sie werden auch einen Anstieg der `UnderReplicatedPartitions` Metrik beobachten, der zu erwarten ist, wenn Replikate mit dem Shutdown-Broker offline sind.
**Fehlerbehebung**
Der oben genannte Ablauf kann unterbrochen werden, wenn der Client-Server-Vertrag gebrochen wird. Zu den häufigsten Gründen für das Problem gehören:
+ Fehlkonfiguration oder falsche Verwendung von Kafka-Clientbibliotheken.
+ Unerwartetes Standardverhalten und Fehler bei Clientbibliotheken von Drittanbietern.
+ Überladener Controller führt zu einer langsameren Zuweisung von Partitionsführern.
+ Es wird ein neuer Controller gewählt, was zu einer langsameren Zuweisung des Partitionsführers führt.
Um ein korrektes Verhalten beim Umgang mit Führungskräften zu gewährleisten, empfehlen wir:
+ Serverseitige [Best Practices](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html) müssen befolgt werden, um sicherzustellen, dass der Controller-Broker angemessen skaliert wird, um eine langsame Zuweisung von Führungskräften zu vermeiden.
+ Für Clientbibliotheken müssen Wiederholungsversuche aktiviert sein, um sicherzustellen, dass der Client den Failover verarbeitet.
+ Für Clientbibliotheken muss retry.backoff.ms konfiguriert sein (Standard 100), um Stürme zu vermeiden. connection/request
+ Clientbibliotheken müssen request.timeout.ms und delivery.timeout.ms auf Werte setzen, die dem SLA der Anwendungen entsprechen. Höhere Werte führen bei bestimmten Fehlertypen zu einem langsameren Failover.
+ Clientbibliotheken müssen sicherstellen, dass bootstrap.servers mindestens 3 zufällige Broker enthält, um eine Beeinträchtigung der Verfügbarkeit bei der ersten Erkennung zu vermeiden.
+ Einige Clientbibliotheken sind niedriger als andere und erwarten, dass der Anwendungsentwickler die Wiederholungslogik und die Ausnahmebehandlung selbst implementiert. Informationen zur Verwendung finden Sie in der spezifischen Dokumentation zur Clientbibliothek und stellen Sie sicher, dass die richtige reconnect/retry Logik befolgt wird.
+ Wir empfehlen, die clientseitige Latenz für Produkte, die Anzahl erfolgreicher Anfragen und die Anzahl der Fehler bei Fehlern, die nicht wiederholt werden können, zu überwachen.
+ Wir haben beobachtet, dass ältere Golang- und Ruby-Bibliotheken von Drittanbietern während der gesamten Offline-Zeit des Brokers sehr umfangreich bleiben, obwohl Produces- und Consume-Anfragen davon nicht betroffen sind. Wir empfehlen Ihnen, neben den Erfolgs- und Fehlerkennzahlen auch immer Ihre Kennzahlen auf Unternehmensebene zu überwachen, um festzustellen, ob Ihre Logs tatsächlich Auswirkungen haben und nicht.
+ Kunden sollten sich nicht über vorübergehende Ausnahmen für network/not\$1leader informieren, da diese normal sind, keine Auswirkungen haben und im Rahmen des Kafka-Protokolls erwartet werden.
+ Kunden sollten keinen Alarm auslösen, UnderReplicatedPartitions da sie bei einem einzigen Offline-Broker normal sind, keine Auswirkungen haben und zu erwarten sind.
# Sicherheit in Amazon MSK
Cloud-Sicherheit hat AWS höchste Priorität. Als AWS Kunde profitieren Sie von einer Rechenzentrums- und Netzwerkarchitektur, die darauf ausgelegt sind, die Anforderungen der sicherheitssensibelsten Unternehmen zu erfüllen.
Sicherheit ist eine gemeinsame Verantwortung von Ihnen AWS und Ihnen. Das [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/) beschreibt dies als Sicherheit *der* Cloud und Sicherheit *in* der Cloud:
+ **Sicherheit der Cloud** — AWS ist verantwortlich für den Schutz der Infrastruktur, die AWS Dienste in der AWS Cloud ausführt. AWS bietet Ihnen auch Dienste, die Sie sicher nutzen können. Externe Prüfer testen und verifizieren regelmäßig die Wirksamkeit unserer Sicherheitsmaßnahmen im Rahmen der [AWS](https://aws.amazon.com/compliance/programs/) . Informationen zu den Compliance-Programmen, die für Amazon Managed Streaming für Apache Kafka gelten, finden Sie unter [Im Rahmen des Compliance-Programms zugelassene Amazon-Web-Services](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicherheit in der Cloud** — Ihre Verantwortung richtet sich nach dem AWS Dienst, den Sie nutzen. Sie sind auch für andere Faktoren verantwortlich, einschließlich der Vertraulichkeit Ihrer Daten, für die Anforderungen Ihres Unternehmens und für die geltenden Gesetze und Vorschriften.
Diese Dokumentation zeigt Ihnen, wie Sie das Modell der geteilten Verantwortung bei der Verwendung von Amazon MSK einsetzen können. Die folgenden Themen zeigen Ihnen, wie Sie Amazon MKS konfigurieren, um Ihre Sicherheits- und Compliance-Ziele zu erreichen. Sie lernen auch, wie Sie andere Amazon Web Services verwenden, die Sie bei der Überwachung und Sicherung Ihrer Amazon-MSK-Ressourcen unterstützen.
**Topics**
+ [Datenschutz in Amazon Managed Streaming für Apache Kafka](data-protection.md)
+ [Authentifizierung und Autorisierung für Amazon MSK APIs](security-iam.md)
+ [Authentifizierung und Autorisierung für Apache Kafka APIs](kafka_apis_iam.md)
+ [Ändern der Sicherheitsgruppe eines Amazon-MSK-Clusters](change-security-group.md)
+ [Steuern Sie den Zugriff auf ZooKeeper Apache-Knoten in Ihrem Amazon MSK-Cluster](zookeeper-security.md)
+ [Compliance-Validierung für Amazon Managed Streaming für Apache Kafka](MSK-compliance.md)
+ [Ausfallsicherheit in Amazon Managed Streaming für Apache Kafka](disaster-recovery-resiliency.md)
+ [Infrastruktursicherheit in Amazon Managed Streaming für Apache Kafka](infrastructure-security.md)
# Datenschutz in Amazon Managed Streaming für Apache Kafka
Das [Modell der AWS gemeinsamen Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/) gilt für den Datenschutz in Amazon Managed Streaming for Apache Kafka. Wie in diesem Modell beschrieben, AWS ist verantwortlich für den Schutz der globalen Infrastruktur, auf der AWS Cloud alle Systeme laufen. Sie sind dafür verantwortlich, die Kontrolle über Ihre in dieser Infrastruktur gehosteten Inhalte zu behalten. Sie sind auch für die Sicherheitskonfiguration und die Verwaltungsaufgaben für die von Ihnen verwendeten AWS-Services verantwortlich. Weitere Informationen zum Datenschutz finden Sie unter [Häufig gestellte Fragen zum Datenschutz](https://aws.amazon.com/compliance/data-privacy-faq/). Informationen zum Datenschutz in Europa finden Sie im Blog-Beitrag [AWS -Modell der geteilten Verantwortung und in der DSGVO](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) im *AWS -Sicherheitsblog*.
Aus Datenschutzgründen empfehlen wir, dass Sie AWS-Konto Anmeldeinformationen schützen und einzelne Benutzer mit AWS IAM Identity Center oder AWS Identity and Access Management (IAM) einrichten. So erhält jeder Benutzer nur die Berechtigungen, die zum Durchführen seiner Aufgaben erforderlich sind. Außerdem empfehlen wir, die Daten mit folgenden Methoden schützen:
+ Verwenden Sie für jedes Konto die Multi-Faktor-Authentifizierung (MFA).
+ Wird verwendet SSL/TLS , um mit AWS Ressourcen zu kommunizieren. Wir benötigen TLS 1.2 und empfehlen TLS 1.3.
+ Richten Sie die API und die Protokollierung von Benutzeraktivitäten mit ein AWS CloudTrail. Informationen zur Verwendung von CloudTrail Pfaden zur Erfassung von AWS Aktivitäten finden Sie unter [Arbeiten mit CloudTrail Pfaden](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) im *AWS CloudTrail Benutzerhandbuch*.
+ Verwenden Sie AWS Verschlüsselungslösungen zusammen mit allen darin enthaltenen Standardsicherheitskontrollen AWS-Services.
+ Verwenden Sie erweiterte verwaltete Sicherheitsservices wie Amazon Macie, die dabei helfen, in Amazon S3 gespeicherte persönliche Daten zu erkennen und zu schützen.
+ Wenn Sie für den Zugriff AWS über eine Befehlszeilenschnittstelle oder eine API FIPS 140-3-validierte kryptografische Module benötigen, verwenden Sie einen FIPS-Endpunkt. Weitere Informationen über verfügbare FIPS-Endpunkte finden Sie unter [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Wir empfehlen dringend, in Freitextfeldern, z. B. im Feld **Name**, keine vertraulichen oder sensiblen Informationen wie die E-Mail-Adressen Ihrer Kunden einzugeben. Dies gilt auch, wenn Sie mit Amazon MSK oder anderen AWS-Services über die Konsole AWS CLI, API oder AWS SDKs arbeiten. Alle Daten, die Sie in Tags oder Freitextfelder eingeben, die für Namen verwendet werden, können für Abrechnungs- oder Diagnoseprotokolle verwendet werden. Wenn Sie eine URL für einen externen Server bereitstellen, empfehlen wir dringend, keine Anmeldeinformationen zur Validierung Ihrer Anforderung an den betreffenden Server in die URL einzuschließen.
**Topics**
+ [Amazon-MSK-Verschlüsselung](msk-encryption.md)
+ [Erste Schritte mit der Amazon MSK-Verschlüsselung](msk-working-with-encryption.md)
+ [Verwenden Sie Amazon MSK APIs mit Interface VPC-Endpunkten](privatelink-vpc-endpoints.md)
# Amazon-MSK-Verschlüsselung
Amazon MSK bietet Datenverschlüsselungsoptionen, mit denen Sie strenge Anforderungen an die Datenverwaltung erfüllen können. Die Zertifikate, die Amazon MSK für die Verschlüsselung verwendet, müssen alle 13 Monate erneuert werden. Amazon MSK erneuert diese Zertifikate automatisch für alle Cluster. Express-Broker-Cluster bleiben in dem `ACTIVE` Zustand, in dem Amazon MSK den Vorgang zur Aktualisierung des Zertifikats startet. Für Standard-Broker-Cluster legt Amazon MSK den Status des Clusters auf den `MAINTENANCE` Zeitpunkt fest, zu dem der Vorgang zur Zertifikatsaktualisierung gestartet wird. MSK setzt den Wert auf den `ACTIVE` Zeitpunkt zurück, zu dem die Aktualisierung abgeschlossen ist. Während der Zertifikatsaktualisierung eines Clusters können Sie weiterhin Daten erzeugen und verwenden, aber Sie können keine Aktualisierungsvorgänge für den Cluster ausführen.
## Amazon MSK-Verschlüsselung im Ruhezustand
Amazon MSK wird in [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/) (KMS) integriert, um transparente serverseitige Verschlüsselung zu ermöglichen. Amazon MQ verschlüsselt stets Ihre Daten im Ruhezustand. Wenn Sie einen MSK-Cluster erstellen, können Sie den AWS KMS key angeben, den Amazon MSK zur Verschlüsselung Ihrer Daten im Ruhezustand verwenden soll. Wenn Sie keinen KMS-Schlüssel angeben, erstellt Amazon MSK einen [Von AWS verwalteter Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) für Sie und verwendet ihn in Ihrem Namen. Weitere Informationen über KMS-Schlüssel finden Sie unter [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) im *Entwicklerhandbuch zu AWS Key Management Service *.
## Amazon MSK-Verschlüsselung bei der Übertragung
Amazon MSK verwendet TLS 1.2. Daten werden standardmäßig während der Übertragung zwischen den Brokern Ihres MSK-Clusters verschlüsselt. Sie können diese Standardeinstellung beim Erstellen des Clusters außer Kraft setzen.
Für die Kommunikation zwischen Clients und Brokern müssen Sie eine der folgenden drei Einstellungen angeben:
+ Nur Daten mit TLS-Verschlüsselung zulassen. Dies ist die Standardeinstellung.
+ Sowohl Klartextdaten als auch Daten mit TLS-Verschlüsselung zulassen
+ Nur Klartextdaten zulassen
Amazon MSK-Broker verwenden öffentliche AWS Certificate Manager Zertifikate. Daher vertraut jeder Vertrauensspeicher, der Amazon Trust Services vertraut, auch den Zertifikaten von Amazon-MSK-Brokern.
Während wir dringend empfehlen, die Verschlüsselung während der Übertragung zu aktivieren, kann dies zusätzliche CPU-Kosten und einige Millisekunden Latenz verursachen. Die meisten Anwendungsfälle reagieren jedoch nicht empfindlich auf diese Unterschiede, und das Ausmaß der Auswirkungen hängt von der Konfiguration Ihres Clusters, Ihrer Clients und Ihres Nutzungsprofils ab.
# Erste Schritte mit der Amazon MSK-Verschlüsselung
Beim Erstellen eines MSK-Clusters können Sie Verschlüsselungseinstellungen im JSON-Format angeben. Im Folgenden wird ein -Beispiel gezeigt.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdabcd-1234-abcd-1234-abcd123e8e8e"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Für `DataVolumeKMSKeyId` können Sie einen [vom Kunden verwalteten Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) oder den Von AWS verwalteter Schlüssel für MSK in Ihrem Konto angeben (`alias/aws/kafka`). Wenn Sie nichts angeben`EncryptionAtRest`, verschlüsselt Amazon MSK Ihre ruhenden Daten trotzdem unter dem. Von AWS verwalteter Schlüssel Um festzustellen, welchen Schlüssel Ihr Cluster verwendet, senden Sie eine `GET`-Anforderung oder rufen Sie den `DescribeCluster`-API-Vorgang auf.
Für `EncryptionInTransit` ist der Standardwert von `InCluster` auf Wahr festgelegt, aber Sie können ihn auf Falsch setzen, wenn Sie Ihre Daten bei der Übergabe zwischen Brokern nicht von Amazon MSK verschlüsseln lassen möchten.
Um den Verschlüsselungsmodus für die Übertragung von Daten zwischen Clients und Brokern anzugeben, legen Sie `ClientBroker` auf einen der drei Werte folgenden fest: `TLS`, `TLS_PLAINTEXT`, oder `PLAINTEXT`.
**Topics**
+ [Geben Sie die Verschlüsselungseinstellungen an, wenn Sie einen Amazon MSK-Cluster erstellen](msk-working-with-encryption-cluster-create.md)
+ [Testen Sie die Amazon MSK TLS-Verschlüsselung](msk-working-with-encryption-test-tls.md)
# Geben Sie die Verschlüsselungseinstellungen an, wenn Sie einen Amazon MSK-Cluster erstellen
In diesem Prozess wird beschrieben, wie Verschlüsselungseinstellungen bei der Erstellung eines Amazon MSK-Clusters angegeben werden.
**Geben Sie bei der Erstellung eines Clusters die Verschlüsselungseinstellungen an**
1. Speichern Sie den Inhalt des vorherigen Beispiels in einer Datei und geben Sie der Datei einen beliebigen Namen. Nennen Sie sie beispielsweise „`encryption-settings.json`“.
1. Führen Sie den `create-cluster`-Befehl aus, und weisen Sie mithilfe der `encryption-info`-Option auf die Datei, in der Sie Ihr Konfigurations-JSON gespeichert haben. Im Folgenden wird ein -Beispiel gezeigt. *\$1YOUR MSK VERSION\$1*Ersetzen Sie es durch eine Version, die der Apache Kafka-Client-Version entspricht. Weitere Informationen zum Auffinden der MSK-Cluster-Version finden Sie unter [Ermitteln Sie Ihre MSK-Cluster-Version](create-topic.md#find-msk-cluster-version). Beachten Sie, dass die Verwendung einer Apache-Kafka-Client-Version, die nicht mit Ihrer MSK-Cluster-Version identisch ist, zu Beschädigung, Verlust und Ausfallzeiten von Apache-Kafka-Daten führen kann.
```
aws kafka create-cluster --cluster-name "ExampleClusterName" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --kafka-version "{YOUR MSK VERSION}" --number-of-broker-nodes 3
```
Im Folgenden finden Sie ein Beispiel für eine erfolgreiche Antwort nach der Ausführung dieses Befehls.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:123456789012:cluster/SecondTLSTest/abcdabcd-1234-abcd-1234-abcd123e8e8e",
"ClusterName": "ExampleClusterName",
"State": "CREATING"
}
```
# Testen Sie die Amazon MSK TLS-Verschlüsselung
In diesem Prozess wird beschrieben, wie die TLS-Verschlüsselung auf Amazon MSK getestet wird.
**So testen Sie die TLS-Verschlüsselung**
1. Erstellen Sie einen Client-Computer entsprechend der Anweisungen in [Schritt 3: Einen Client-Computer erstellen](create-client-machine.md).
1. Installieren Sie Apache Kafka auf dem Client-Computer.
1. In diesem Beispiel verwenden wir den JVM-Vertrauensspeicher, um mit dem MSK-Cluster zu kommunizieren. Erstellen Sie dazu zunächst einen Ordner mit dem Namen `/tmp` auf dem Client-Computer. Wechseln Sie dann zum Ordner „`bin`“ der Apache Kafka-Installation und führen Sie den folgenden Befehl aus. (Ihr JVM-Pfad kann sich unterscheiden.)
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Wenn Sie sich noch im `bin`-Ordner der Apache Kafka-Installation auf dem Client-Computer befinden, erstellen Sie eine Textdatei `client.properties` mit dem folgenden Inhalt.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka.client.truststore.jks
```
1. Führen Sie den folgenden Befehl auf einem Computer aus, auf dem der AWS CLI installiert ist, und *clusterARN* ersetzen Sie ihn durch den ARN Ihres Clusters.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Ein erfolgreiches Ergebnis sieht wie folgt aus. Speichern Sie dieses Ergebnis, da Sie es für den nächsten Schritt benötigen.
```
{
"BootstrapBrokerStringTls": "a-1.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-3.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-2.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123"
}
```
1. Führen Sie den folgenden Befehl aus und *BootstrapBrokerStringTls* ersetzen Sie ihn durch einen der Broker-Endpunkte, die Sie im vorherigen Schritt erhalten haben.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringTls --producer.config client.properties --topic TLSTestTopic
```
1. Öffnen Sie ein neues Befehlsfenster und stellen Sie eine Verbindung zu demselben Client-Computer her. Führen Sie dann den folgenden Befehl aus, um einen Konsolenverbraucher zu erstellen.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringTls --consumer.config client.properties --topic TLSTestTopic
```
1. Geben Sie im Produzent-Fenster eine Textnachricht gefolgt von einem Zeilenumbruch ein, und suchen Sie im Verbraucher-Fenster nach derselben Nachricht. Amazon MSK hat diese Nachricht während der Übertragung verschlüsselt.
Weitere Informationen zum Konfigurieren von Apache Kafka-Clients für die Arbeit mit verschlüsselten Daten finden Sie unter [Konfigurieren von Kafka-Clients](https://kafka.apache.org/documentation/#security_configclients).
# Verwenden Sie Amazon MSK APIs mit Interface VPC-Endpunkten
Sie können einen Interface VPC Endpoint, powered by, verwenden AWS PrivateLink, um zu verhindern, dass der Datenverkehr zwischen Ihrer Amazon VPC und Amazon MSK das APIs Amazon-Netzwerk verlässt. Interface VPC Endpoints benötigen kein Internet-Gateway, kein NAT-Gerät, keine VPN-Verbindung oder AWS Direct Connect-Verbindung. [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)ist eine AWS Technologie, die private Kommunikation zwischen AWS Services über eine elastic network interface mit Private IPs in Ihrer Amazon VPC ermöglicht. Weitere Informationen finden Sie unter [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) und [Interface VPC Endpoints ()AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).
Ihre Anwendungen können über Amazon MSK Provisioned und MSK Connect eine Verbindung herstellen. APIs AWS PrivateLink Erstellen Sie zunächst einen Interface-VPC-Endpunkt für Ihre Amazon MSK-API, um den Datenverkehr von und zu Ihren Amazon VPC-Ressourcen über den Interface VPC-Endpunkt zu starten. VPC-Endpunkte mit FIPS-fähiger Schnittstelle sind für US-Regionen verfügbar. [Weitere Informationen finden Sie unter Erstellen eines Schnittstellenendpunkts.](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint)
Mithilfe dieser Funktion können Ihre Apache Kafka-Clients die Verbindungszeichenfolgen dynamisch abrufen, um eine Connect mit MSK Provisioned- oder MSK Connect-Ressourcen herzustellen, ohne das Internet zu durchqueren, um die Verbindungszeichenfolgen abzurufen.
Wählen Sie beim Erstellen eines Interface VPC-Endpoints einen der folgenden Dienstnamen-Endpunkte aus:
**Für MSK Provisioned:**
+ Die folgenden Dienstnamen-Endpunkte werden für neue Verbindungen nicht mehr unterstützt:
+ com.amazonaws.region.kafka
+ com.amazonaws.region.kafka-fips (FIPS-fähig)
+ Der Dual-Stack-Endpunktservice, der sowohl den Datenverkehr als auch den Datenverkehr unterstützt, ist: IPv4 IPv6
+ aws.api.region.kafka-api
+ aws.api.region. kafka-api-fips (FIPS-fähig)
[Um die Dual-Stack-Endpunkte einzurichten, müssen Sie die Richtlinien für Dual-Stack- und FIPS-Endgeräte befolgen.](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html)
Wobei Region der Name Ihrer Region ist. Wählen Sie diesen Dienstnamen, um mit MSK APIs Provisioned-Compatible zu arbeiten. *Weitere Informationen finden Sie unter [Operationen](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) in der Datei 1.0/apireference/. https://docs.aws.amazon.com/msk/*
**Für MSK Connect:**
+ com.amazonaws.region.kafkaconnect
Wobei Region der Name Ihrer Region ist. Wählen Sie diesen Dienstnamen, um mit MSK APIs Connect-Compatible zu arbeiten. Weitere Informationen finden Sie unter [Aktionen](https://docs.aws.amazon.com/MSKC/latest/mskc/API_Operations.html) in der *Amazon MSK Connect API-Referenz.*
Weitere Informationen, einschließlich step-by-step Anweisungen zum Erstellen eines Schnittstellen-VPC-Endpunkts, finden Sie im *AWS PrivateLink Handbuch* unter [Erstellen eines Schnittstellenendpunkts](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).
## Steuern Sie den Zugriff auf VPC-Endpunkte für Amazon MSK Provisioned oder MSK Connect APIs
Mit VPC-Endpunktrichtlinien können Sie den Zugriff steuern, indem Sie entweder eine Richtlinie an einen VPC-Endpunkt anhängen oder indem Sie zusätzliche Felder in einer Richtlinie verwenden, die einem IAM-Benutzer, einer Gruppe oder einer Rolle zugeordnet ist, um den Zugriff auf den angegebenen VPC-Endpunkt zu beschränken. Verwenden Sie die entsprechende Beispielrichtlinie, um Zugriffsberechtigungen für den MSK Provisioned- oder den MSK Connect-Dienst zu definieren.
Wenn Sie einem Endpunkt beim Erstellen keine Richtlinie zuordnen, ordnet Amazon VPC ihm eine Standardrichtlinie mit Vollzugriff auf den Service zu. IAM-identitätsbasierte Richtlinien oder servicespezifische Richtlinien werden von einer Endpunktrichtlinie nicht überschrieben oder ersetzt. Endpunktrichtlinien steuern unabhängig vom Endpunkt den Zugriff auf den angegebenen Service.
*Weitere Informationen finden Sie im Handbuch unter [Steuern des Zugriffs auf Dienste mit VPC-Endpunkten](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html).AWS PrivateLink *
------
#### [ MSK Provisioned — VPC policy example ]
**Schreibgeschützter Zugriff**
Diese Beispielrichtlinie kann an einen VPC-Endpunkt angehängt werden. Weitere Informationen finden Sie unter Steuern des Zugriffs auf Amazon VPC-Ressourcen. Es beschränkt die Aktionen darauf, nur Operationen über den VPC-Endpunkt aufzulisten und zu beschreiben, an den sie angehängt sind.
```
{
"Statement": [
{
"Sid": "MSKReadOnly",
"Principal": "*",
"Action": [
"kafka:List*",
"kafka:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
**MSK Provisioned — Beispiel für eine VPC-Endpunktrichtlinie**
Beschränken Sie den Zugriff auf einen bestimmten MSK-Cluster
Diese Beispielrichtlinie kann an einen VPC-Endpunkt angehängt werden. Es schränkt den Zugriff auf einen bestimmten Kafka-Cluster über den VPC-Endpunkt ein, an den er angehängt ist.
```
{
"Statement": [
{
"Sid": "AccessToSpecificCluster",
"Principal": "*",
"Action": "kafka:*",
"Effect": "Allow",
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster"
}
]
}
```
------
#### [ MSK Connect — VPC endpoint policy example ]
**Konnektoren auflisten und einen neuen Connector erstellen**
Das Folgende ist ein Beispiel für eine Endpunktrichtlinie für MSK Connect. Diese Richtlinie ermöglicht es der angegebenen Rolle, Connectors aufzulisten und einen neuen Connector zu erstellen.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MSKConnectPermissions",
"Effect": "Allow",
"Action": [
"kafkaconnect:ListConnectors",
"kafkaconnect:CreateConnector"
],
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/MyMSKConnectExecutionRole"
]
}
}
]
}
```
**MSK Connect — Beispiel für eine VPC-Endpunktrichtlinie**
Erlaubt nur Anfragen von einer bestimmten IP-Adresse in der angegebenen VPC
Das folgende Beispiel zeigt eine Richtlinie, die nur erlaubt, dass Anfragen, die von einer bestimmten IP-Adresse in der angegebenen VPC kommen, erfolgreich sind. Anfragen von anderen IP-Adressen schlagen fehl.
```
{
"Statement": [
{
"Action": "kafkaconnect:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:VpcSourceIp": "192.0.2.123"
},
"StringEquals": {
"aws:SourceVpc": "vpc-555555555555"
}
}
}
]
}
```
------
# Authentifizierung und Autorisierung für Amazon MSK APIs
AWS Identity and Access Management (IAM) hilft einem Administrator AWS-Service , den Zugriff auf Ressourcen sicher zu kontrollieren. AWS IAM-Administratoren steuern, wer *authentifiziert* (angemeldet) und *autorisiert* (im Besitz von Berechtigungen) ist, Amazon-MSK-Ressourcen zu nutzen. IAM ist ein Programm AWS-Service , das Sie ohne zusätzliche Kosten nutzen können.
**Topics**
+ [Funktionsweise von Amazon MKS mit IAM](security_iam_service-with-iam.md)
+ [Beispiele für identitätsbasierte Amazon-MSK-Richtlinien](security_iam_id-based-policy-examples.md)
+ [Servicebezogene Rollen für Amazon MSK](using-service-linked-roles.md)
+ [AWS verwaltete Richtlinien für Amazon MSK](security-iam-awsmanpol.md)
+ [Problembehandlung bei Amazon MSK-Identität und -Zugriff](security_iam_troubleshoot.md)
# Funktionsweise von Amazon MKS mit IAM
Bevor Sie mit IAM den Zugriff auf Amazon MSK verwalten können, sollten Sie sich darüber informieren, welche IAM-Funktionen Sie mit Amazon MSK verwenden können. Einen allgemeinen Überblick darüber, wie Amazon MSK und andere AWS Services mit IAM zusammenarbeiten, finden Sie unter [AWS Services That Work with IAM im *IAM-Benutzerhandbuch*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).
**Topics**
+ [Identitätsbasierte Amazon-MSK-Richtlinien](security_iam_service-with-iam-id-based-policies.md)
+ [Ressourcenbasierte Amazon-MSK-Richtlinien](security_iam_service-with-iam-resource-based-policies.md)
+ [Autorisierung basierend auf Amazon-MSK-Tags](security_iam_service-with-iam-tags.md)
+ [Amazon-MSK-IAM-Rollen](security_iam_service-with-iam-roles.md)
# Identitätsbasierte Amazon-MSK-Richtlinien
Mit identitätsbasierten IAM-Richtlinien können Sie angeben, welche Aktionen und Ressourcen zugelassen oder abgelehnt werden. Darüber hinaus können Sie die Bedingungen festlegen, unter denen Aktionen zugelassen oder abgelehnt werden. Amazon MSK unterstützt bestimmte Aktionen, Ressourcen und Bedingungsschlüssel. Informationen zu sämtlichen Elementen, die Sie in einer JSON-Richtlinie verwenden, finden Sie in der [IAM-Referenz für JSON-Richtlinienelemente](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) im *IAM-Benutzerhandbuch*.
## Aktionen für identitätsbasierte Amazon MSK-Richtlinien
Administratoren können AWS JSON-Richtlinien verwenden, um festzulegen, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das Element `Action` einer JSON-Richtlinie beschreibt die Aktionen, mit denen Sie den Zugriff in einer Richtlinie zulassen oder verweigern können. Nehmen Sie Aktionen in eine Richtlinie auf, um Berechtigungen zur Ausführung des zugehörigen Vorgangs zu erteilen.
Richtlinienaktionen in Amazon MSK verwenden das folgende Präfix vor der Aktion: `kafka:`. Wenn Sie beispielsweise einem Benutzer die Berechtigung erteilen möchten, einen MSK-Cluster mit dem Amazon-MSK-API-Vorgang `DescribeCluster` zu beschreiben, nehmen Sie die Aktion `kafka:DescribeCluster` in die Richtlinie auf. Richtlinienanweisungen müssen entweder ein – `Action`oder ein `NotAction`-Element enthalten. Amazon MSK definiert einen eigenen Satz von Aktionen, die Aufgaben beschreiben, die Sie mit diesem Service durchführen können.
Bitte beachten Sie, dass bei Richtlinienaktionen für das MSK-Thema das `kafka-cluster` Präfix vor der Aktion APIs verwendet wird. Weitere Informationen finden Sie unter. [Semantik der Aktionen und Ressourcen der IAM-Autorisierungsrichtlinie](kafka-actions.md)
Um mehrere Aktionen in einer einzigen Anweisung anzugeben, trennen Sie sie wie folgt durch Kommata:
```
"Action": ["kafka:action1", "kafka:action2"]
```
Sie können auch Platzhalter verwenden, um mehrere Aktionen anzugeben. Beispielsweise können Sie alle Aktionen festlegen, die mit dem Wort `Describe` beginnen, einschließlich der folgenden Aktion:
```
"Action": "kafka:Describe*"
```
Eine Liste der Amazon-MSK-Aktionen finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für Amazon Managed Streaming für Apache Kafka](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonmanagedstreamingforapachekafka.html) im *IAM-Benutzerhandbuch*.
## Ressourcen für identitätsbasierte Amazon MSK-Richtlinien
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das JSON-Richtlinienelement `Resource` gibt die Objekte an, auf welche die Aktion angewendet wird. Als Best Practice geben Sie eine Ressource mit dem zugehörigen [Amazon-Ressourcennamen (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) an. Verwenden Sie für Aktionen, die keine Berechtigungen auf Ressourcenebene unterstützen, einen Platzhalter (\$1), um anzugeben, dass die Anweisung für alle Ressourcen gilt.
```
"Resource": "*"
```
Die Amazon-MSK-Instance-Ressource hat den folgenden ARN:
```
arn:${Partition}:kafka:${Region}:${Account}:cluster/${ClusterName}/${UUID}
```
Weitere Informationen zum Format von ARNs finden Sie unter [Amazon Resource Names (ARNs) und AWS Service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Wenn Sie beispielsweise die `CustomerMessages`-Instance in Ihrer Anweisung angeben möchten, verwenden Sie den folgenden ARN:
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/CustomerMessages/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2"
```
Um alle Instances anzugeben, die zu einem bestimmten Konto gehören, verwenden Sie den Platzhalter (\$1):
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*"
```
Einige Amazon-MKS-Aktionen, z. B. das Erstellen von Ressourcen, können für bestimmte Ressourcen nicht ausgeführt werden. In diesen Fällen müssen Sie den Platzhalter (\$1) verwenden.
```
"Resource": "*"
```
Um mehrere Ressourcen in einer einzigen Anweisung anzugeben, trennen Sie sie durch Kommas. ARNs
```
"Resource": ["resource1", "resource2"]
```
Eine Liste der Amazon MSK-Ressourcentypen und ihrer ARNs Eigenschaften finden Sie unter [Von Amazon Managed Streaming for Apache Kafka definierte Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-resources-for-iam-policies) im *IAM-Benutzerhandbuch*. Informationen zu den Aktionen, mit denen Sie den ARN einzelner Ressourcen angeben können, finden Sie unter [Von Amazon Managed Streaming für Apache Kafka definierte Aktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Bedingungsschlüssel für identitätsbasierte Amazon MSK-Richtlinien
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer Zugriff auf was hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das Element `Condition` gibt an, wann Anweisungen auf der Grundlage definierter Kriterien ausgeführt werden. Sie können bedingte Ausdrücke erstellen, die [Bedingungsoperatoren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html) verwenden, z. B. ist gleich oder kleiner als, damit die Bedingung in der Richtlinie mit Werten in der Anforderung übereinstimmt. Eine Übersicht aller AWS globalen Bedingungsschlüssel finden Sie unter [Kontextschlüssel für AWS globale Bedingungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) im *IAM-Benutzerhandbuch*.
Amazon MSK definiert seinen eigenen Satz von Bedingungsschlüsseln und unterstützt auch die Verwendung einiger globaler Bedingungsschlüssel. Eine Übersicht aller AWS globalen Bedingungsschlüssel finden Sie unter [AWS Globale Bedingungskontextschlüssel](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) im *IAM-Benutzerhandbuch*.
Eine Liste der Amazon-MSK-Bedingungsschlüssel finden Sie unter [Bedingungsschlüssel für Amazon Managed Streaming für Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-policy-keys) im *IAM-Benutzerhandbuch*. Informationen dazu, mit welchen Aktionen und Ressourcen Sie einen Bedingungsschlüssel verwenden können, finden Sie unter [Von Amazon Managed Streaming für Apache Kafka definierte Aktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Beispiele für identitätsbasierte Amazon MSK-Richtlinien
Beispiele für identitätsbasierte Amazon-MSK-Richtlinien finden Sie unter [Beispiele für identitätsbasierte Amazon-MSK-Richtlinien](security_iam_id-based-policy-examples.md).
# Ressourcenbasierte Amazon-MSK-Richtlinien
Amazon MSK unterstützt eine Cluster-Richtlinie (auch als ressourcenbasierte Richtlinie bezeichnet) zur Verwendung mit Amazon-MSK-Clustern. Sie können eine Cluster-Richtlinie verwenden, um zu definieren, welche IAM-Prinzipale über kontoübergreifende Berechtigungen zum Einrichten einer privaten Konnektivität mit Ihrem Amazon-MSK-Cluster verfügen. Bei Verwendung mit der IAM-Client-Authentifizierung können Sie die Cluster-Richtlinie auch verwenden, um die Kafka-Datenebenen-Berechtigungen für die verbindenden Clients detailliert zu definieren.
Die maximale Größe, die für eine Cluster-Richtlinie unterstützt wird, beträgt 20 KB.
Ein Beispiel für die Konfiguration einer Cluster-Richtlinie finden Sie unter [Schritt 2: Eine Cluster-Richtlinie an den MSK-Cluster anhängen](mvpc-cluster-owner-action-policy.md).
# Autorisierung basierend auf Amazon-MSK-Tags
Sie können Amazon-MSK-Clustern Tags anhängen. Um den Zugriff auf der Grundlage von Tags zu steuern, geben Sie im Bedingungselement einer[ Richtlinie Tag-Informationen ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)an, indem Sie die Schlüssel `kafka:ResourceTag/key-name`, `aws:RequestTag/key-name`, oder Bedingung `aws:TagKeys` verwenden. Informationen zum Taggen von Amazon MSK-Ressourcen finden Sie unter. [Kennzeichnen Sie einen Amazon MSK-Cluster](msk-tagging.md)
Sie können den Cluster-Zugriff nur mit Hilfe von Tags steuern. Um Themen und Nutzergruppen zu taggen, müssen Sie in Ihren Richtlinien eine separate Erklärung ohne Stichwörter hinzufügen.
Ein Beispiel für eine identitätsbasierte Richtlinie zur Beschränkung des Zugriffs auf einen Cluster anhand der Tags in diesem Cluster finden Sie unter. [Zugreifen auf Amazon-MSK-Cluster anhand von Tags](security_iam_id-based-policy-examples-view-widget-tags.md)
Sie können Bedingungen in Ihrer identitätsbasierten Richtlinie verwenden, um den Zugriff auf Amazon-MSK-Ressourcen anhand von Tags zu steuern. Das folgende Beispiel zeigt eine Richtlinie, die es einem Benutzer ermöglicht, den Cluster zu beschreiben, seine Bootstrap-Broker abzurufen, seine Brokerknoten aufzulisten, ihn zu aktualisieren und zu löschen. Diese Richtlinie gewährt jedoch nur dann Berechtigungen, wenn das Cluster-Tag den Wert des betreffenden Benutzers `Owner` `username` hat. Die zweite Aussage in der folgenden Richtlinie ermöglicht den Zugriff auf die Themen im Cluster. Die erste Aussage in dieser Richtlinie autorisiert keinen Zugriff auf Themen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/*"
]
}
]
}
```
------
# Amazon-MSK-IAM-Rollen
Eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) ist eine Entität in Ihrem Amazon–Web-Services-Konto mit spezifischen Berechtigungen.
## Verwenden temporärer Anmeldeinformationen mit Amazon MSK
Sie können temporäre Anmeldeinformationen verwenden, um sich über einen Verbund anzumelden, eine IAM-Rolle anzunehmen oder eine kontenübergreifende Rolle anzunehmen. Sie erhalten temporäre Sicherheitsanmeldedaten, indem Sie AWS STS API-Operationen wie [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)oder [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)aufrufen.
Amazon MSK unterstützt die Verwendung temporärer Anmeldeinformationen.
## Service-verknüpfte Rollen
[Serviceverknüpfte Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) erlauben Amazon Web Services den Zugriff auf Ressourcen in anderen Services, um eine Aktion in Ihrem Auftrag auszuführen. Serviceverknüpfte Rollen werden in Ihrem IAM-Konto angezeigt und gehören zum Service. Ein -Administrator kann die Berechtigungen für serviceverknüpfte Rollen anzeigen, aber nicht bearbeiten.
Amazon MSK unterstützt serviceverknüpfte Rollen. Weitere Informationen zum Erstellen oder Verwalten von serviceverknüpften Amazon-MSK-Rollen finden Sie unter [Servicebezogene Rollen für Amazon MSK](using-service-linked-roles.md).
# Beispiele für identitätsbasierte Amazon-MSK-Richtlinien
Standardmäßig haben IAM-Benutzer und -Rollen keine Berechtigung zum Ausführen von Amazon-MSK-API-Aktionen. Ein Administrator muss IAM-Richtlinien erstellen, die Benutzern und Rollen die Berechtigung zum Ausführen bestimmter API-Operationen für die angegebenen Ressourcen gewähren, die diese benötigen. Der Administrator muss diese Richtlinien anschließend den IAM-Benutzern oder -Gruppen anfügen, die diese Berechtigungen benötigen.
Informationen dazu, wie Sie unter Verwendung dieser beispielhaften JSON-Richtliniendokumente eine identitätsbasierte IAM-Richtlinie erstellen, finden Sie unter [Erstellen von Richtlinien auf der JSON-Registerkarte](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) im *IAM-Benutzerhandbuch*.
**Topics**
+ [Best Practices für Richtlinien](security_iam_service-with-iam-policy-best-practices.md)
+ [Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Zugriff auf einen Amazon-MSK-Cluster](security_iam_id-based-policy-examples-access-one-cluster.md)
+ [Zugreifen auf Amazon-MSK-Cluster anhand von Tags](security_iam_id-based-policy-examples-view-widget-tags.md)
# Best Practices für Richtlinien
Identitätsbasierte Richtlinien können festlegen, ob jemand Amazon-MSK-Ressourcen in Ihrem Konto erstellen, darauf zugreifen oder löschen kann. Dies kann zusätzliche Kosten für Ihr verursachen AWS-Konto. Beachten Sie beim Erstellen oder Bearbeiten identitätsbasierter Richtlinien die folgenden Richtlinien und Empfehlungen:
+ **Erste Schritte mit AWS verwalteten Richtlinien und Umstellung auf Berechtigungen mit den geringsten Rechten** — Verwenden Sie die *AWS verwalteten Richtlinien*, die Berechtigungen für viele gängige Anwendungsfälle gewähren, um damit zu beginnen, Ihren Benutzern und Workloads Berechtigungen zu gewähren. Sie sind in Ihrem verfügbar. AWS-Konto Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie vom AWS Kunden verwaltete Richtlinien definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind. Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) oder [Von AWS verwaltete Richtlinien für Auftragsfunktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) im *IAM-Benutzerhandbuch*.
+ **Anwendung von Berechtigungen mit den geringsten Rechten** – Wenn Sie mit IAM-Richtlinien Berechtigungen festlegen, gewähren Sie nur die Berechtigungen, die für die Durchführung einer Aufgabe erforderlich sind. Sie tun dies, indem Sie die Aktionen definieren, die für bestimmte Ressourcen unter bestimmten Bedingungen durchgeführt werden können, auch bekannt als *die geringsten Berechtigungen*. Weitere Informationen zur Verwendung von IAM zum Anwenden von Berechtigungen finden Sie unter [ Richtlinien und Berechtigungen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden von Bedingungen in IAM-Richtlinien zur weiteren Einschränkung des Zugriffs** – Sie können Ihren Richtlinien eine Bedingung hinzufügen, um den Zugriff auf Aktionen und Ressourcen zu beschränken. Sie können beispielsweise eine Richtlinienbedingung schreiben, um festzulegen, dass alle Anforderungen mithilfe von SSL gesendet werden müssen. Sie können auch Bedingungen verwenden, um Zugriff auf Serviceaktionen zu gewähren, wenn diese für einen bestimmten Zweck verwendet werden AWS-Service, z. CloudFormation B. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingung](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden von IAM Access Analyzer zur Validierung Ihrer IAM-Richtlinien, um sichere und funktionale Berechtigungen zu gewährleisten** – IAM Access Analyzer validiert neue und vorhandene Richtlinien, damit die Richtlinien der IAM-Richtliniensprache (JSON) und den bewährten IAM-Methoden entsprechen. IAM Access Analyzer stellt mehr als 100 Richtlinienprüfungen und umsetzbare Empfehlungen zur Verfügung, damit Sie sichere und funktionale Richtlinien erstellen können. Weitere Informationen finden Sie unter [Richtlinienvalidierung mit IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) im *IAM-Benutzerhandbuch*.
+ **Multi-Faktor-Authentifizierung (MFA) erforderlich** — Wenn Sie ein Szenario haben, das IAM-Benutzer oder einen Root-Benutzer in Ihrem System erfordert AWS-Konto, aktivieren Sie MFA für zusätzliche Sicherheit. Um MFA beim Aufrufen von API-Vorgängen anzufordern, fügen Sie Ihren Richtlinien MFA-Bedingungen hinzu. Weitere Informationen finden Sie unter [Sicherer API-Zugriff mit MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) im *IAM-Benutzerhandbuch*.
Weitere Informationen zu bewährten Methoden in IAM finden Sie unter [Best Practices für die Sicherheit in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) im *IAM-Benutzerhandbuch*.
# Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer
In diesem Beispiel wird gezeigt, wie Sie eine Richtlinie erstellen, die IAM-Benutzern die Berechtigung zum Anzeigen der eingebundenen Richtlinien und verwalteten Richtlinien gewährt, die ihrer Benutzeridentität angefügt sind. Diese Richtlinie umfasst Berechtigungen zum Ausführen dieser Aktion auf der Konsole oder programmgesteuert mithilfe der API oder. AWS CLI AWS
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Zugriff auf einen Amazon-MSK-Cluster
In diesem Beispiel möchten Sie einem IAM-Benutzer in Ihrem Amazon-Web-Services-Konto den Zugriff auf einen Ihrer Cluster gewähren, `purchaseQueriesCluster`. Diese Richtlinie ermöglicht es dem Benutzer, den Cluster zu beschreiben, seine Bootstrap-Broker abrufen, seine Broker-Knoten auflisten und ihn zu aktualisieren.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"UpdateCluster",
"Effect":"Allow",
"Action":[
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*"
],
"Resource":"arn:aws:kafka:us-east-1:012345678012:cluster/purchaseQueriesCluster/abcdefab-1234-abcd-5678-cdef0123ab01-2"
}
]
}
```
------
# Zugreifen auf Amazon-MSK-Cluster anhand von Tags
Sie können Bedingungen in Ihrer identitätsbasierten Richtlinie verwenden, um den Zugriff auf Amazon-MSK-Ressourcen anhand von Tags zu steuern. In diesem Beispiel wird dargestellt, wie Sie eine Richtlinie erstellen können, mit der Benutzer den Cluster beschreiben, seine Bootstrap-Broker abrufen, seine Broker-Knoten auflisten, ihn aktualisieren und löschen können. Die Berechtigung wird jedoch nur gewährt, wenn der Wert des Cluster-Tags „`Owner`“ dem Benutzernamen entspricht.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:012345678012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
```
------
Sie können diese Richtlinie den IAM-Benutzern in Ihrem Konto anfügen. Wenn ein Benutzer mit dem Namen `richard-roe` versucht, einen MSK-Cluster zu aktualisieren, muss der Cluster mit dem Tag `Owner=richard-roe` oder `owner=richard-roe` markiert sein. Andernfalls wird der Zugriff abgelehnt. Der Tag-Schlüssel `Owner` der Bedingung stimmt sowohl mit `Owner` als auch mit `owner` überein, da die Namen von Bedingungsschlüsseln nicht zwischen Groß- und Kleinschreibung unterscheiden. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingung](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) im *IAM-Benutzerhandbuch*.
# Servicebezogene Rollen für Amazon MSK
Amazon MSK verwendet AWS Identity and Access Management (IAM) [serviceverknüpfte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Rollen. Eine serviceverknüpfte Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Amazon MSK verknüpft ist. Servicebezogene Rollen sind von Amazon MSK vordefiniert und beinhalten alle Berechtigungen, die der Service benötigt, um andere AWS Services in Ihrem Namen aufzurufen.
Eine serviceverknüpfte Rolle macht die Einrichtung von Amazon MSK einfacher, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Amazon MSK definiert die Berechtigungen seiner serviceverknüpften Rollen. Sofern nicht anders definiert, kann nur Amazon MSK seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Informationen zu anderen Services, die serviceverknüpfte Rollen unterstützen, finden Sie unter [Amazon Web Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer serviceverknüpften Rolle für diesen Service anzuzeigen.
**Topics**
+ [Berechtigungen von serviceverknüpften Rollen](slr-permissions.md)
+ [Erstellen einer serviceverknüpften Rolle](create-slr.md)
+ [Bearbeiten einer serviceverknüpften Rolle](edit-slr.md)
+ [Unterstützte Regionen für serviceverknüpfte -Rollen](slr-regions.md)
# Serviceverknüpfte Rollenberechtigungen für Amazon MSK
Amazon MSK verwendet die serviceverknüpfte Rolle namens **AWSServiceRoleForKafka**. Amazon MSK verwendet diese Rolle für den Zugriff auf Ihre Ressourcen und für die Ausführung von Vorgängen wie:
+ `*NetworkInterface` – Netzwerkschnittstellen im Kundenkonto erstellen und verwalten, die Cluster-Broker für Clients in der Kunden-VPC zugänglich machen.
+ `*VpcEndpoints`— VPC-Endpunkte im Kundenkonto verwalten, die Cluster-Broker für Kunden in der Kunden-VPC zugänglich machen, die sie verwenden. AWS PrivateLink Amazon MSK verwendet Berechtigungen für `DescribeVpcEndpoints`, `ModifyVpcEndpoint` und `DeleteVpcEndpoints`.
+ `secretsmanager`— Kundenanmeldedaten verwalten mit. AWS Secrets Manager
+ `GetCertificateAuthorityCertificate` – Das Zertifikat für Ihre private Zertifizierungsstelle abrufen.
+ `*Ipv6Addresses`— Netzwerkschnittstellen im Kundenkonto IPv6 Adressen zuweisen und deren Zuweisung aufheben, um die IPv6 Konnektivität für MSK-Cluster zu aktivieren.
+ `ModifyNetworkInterfaceAttribute`— Ändern Sie die Netzwerkschnittstellenattribute im Kundenkonto, um die IPv6 Einstellungen für die MSK-Cluster-Konnektivität zu konfigurieren.
Diese verwaltete Richtlinie ist mit der folgenden serviceverknüpften Rolle verbunden: `KafkaServiceRolePolicy`. Aktualisierungen dieser Richtlinie finden Sie unter [KafkaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KafkaServiceRolePolicy.html).
Die serviceverknüpfte Rolle AWSServiceRoleForKafka vertraut darauf, dass die folgenden Services die Rolle annehmen:
+ `kafka.amazonaws.com`
Die Rollenberechtigungsrichtlinie erlaubt es Amazon MSK, die folgenden Aktionen für Ressourcen durchzuführen.
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Weitere Informationen finden Sie unter [serviceverknüpfte Rollenberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
# Eine serviceverknüpfte Rolle für Amazon MSK erstellen
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie einen Amazon MSK-Cluster in der AWS-Managementkonsole, der oder der AWS API erstellen AWS CLI, erstellt Amazon MSK die serviceverknüpfte Rolle für Sie.
Wenn Sie diese serviceverknüpfte Rolle löschen und sie dann erneut erstellen müssen, können Sie dasselbe Verfahren anwenden, um die Rolle in Ihrem Konto neu anzulegen. Wenn Sie einen Amazon-MSK-Cluster erstellen, erstellt Amazon MSK wieder die servicevereknüpfte Rolle für Sie.
# Eine serviceverknüpfte Rolle für Amazon MSK bearbeiten
Amazon MSK verhindert die Bearbeitung der serviceverknüpften Rolle AWSServiceRoleForKafka. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach dem Erstellen einer serviceverknüpften Rolle nicht mehr geändert werden. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
# Unterstützte Regionen für Amazon MSK serviceverknüpfte Rollen
Amazon MSK unterstützt die Verwendung von serviceverknüpften Rollen in allen Regionen, in denen der Service verfügbar ist. Weitere Informationen finden Sie unter [AWS -Regionen und Endpunkte](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# AWS verwaltete Richtlinien für Amazon MSK
Eine AWS verwaltete Richtlinie ist eine eigenständige Richtlinie, die von erstellt und verwaltet AWS wird. AWS Verwaltete Richtlinien sind so konzipiert, dass sie Berechtigungen für viele gängige Anwendungsfälle bereitstellen, sodass Sie damit beginnen können, Benutzern, Gruppen und Rollen Berechtigungen zuzuweisen.
Beachten Sie, dass AWS verwaltete Richtlinien für Ihre speziellen Anwendungsfälle möglicherweise keine Berechtigungen mit den geringsten Rechten gewähren, da sie allen AWS Kunden zur Verfügung stehen. Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie [vom Kunden verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind.
Sie können die in AWS verwalteten Richtlinien definierten Berechtigungen nicht ändern. Wenn die in einer AWS verwalteten Richtlinie definierten Berechtigungen AWS aktualisiert werden, wirkt sich das Update auf alle Prinzidentitäten (Benutzer, Gruppen und Rollen) aus, denen die Richtlinie zugeordnet ist. AWS aktualisiert eine AWS verwaltete Richtlinie höchstwahrscheinlich, wenn eine neue Richtlinie eingeführt AWS-Service wird oder neue API-Operationen für bestehende Dienste verfügbar werden.
Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) im *IAM-Benutzerhandbuch*.
# AWS verwaltete Richtlinie: Amazon MSKFull Access
Diese Richtlinie gewährt Administratorberechtigungen, die einem Prinzipal vollen Zugriff auf alle Amazon-MSK-Aktionen erlauben. Die Berechtigungen in dieser Richtlinie sind wie folgt gruppiert:
+ Die Amazon-MSK-Berechtigungen erlauben alle Amazon-MSK-Aktionen.
+ **`Amazon EC2`Berechtigungen** — In dieser Richtlinie sind sie erforderlich, um die übergebenen Ressourcen in einer API-Anfrage zu validieren. Dadurch soll sichergestellt werden, dass Amazon MSK die Ressourcen erfolgreich mit einem Cluster nutzen kann. Die übrigen Amazon EC2 EC2-Berechtigungen in dieser Richtlinie ermöglichen es Amazon MSK, AWS Ressourcen zu erstellen, die erforderlich sind, damit Sie eine Verbindung zu Ihren Clustern herstellen können.
+ **`AWS KMS`Berechtigungen** — werden bei API-Aufrufen verwendet, um die übergebenen Ressourcen in einer Anfrage zu validieren. Sie sind erforderlich, damit Amazon MSK den übergebenen Schlüssel mit dem Amazon-MSK-Cluster verwenden kann.
+ **`CloudWatch Logs, Amazon S3, and Amazon Data Firehose`Berechtigungen** — sind erforderlich, damit Amazon MSK sicherstellen kann, dass die Protokollzustellungsziele erreichbar sind und dass sie für die Verwendung von Broker-Protokollen gültig sind.
+ **`IAM`Berechtigungen** — sind erforderlich, damit Amazon MSK eine serviceverknüpfte Rolle in Ihrem Konto erstellen und eine Rolle zur Ausführung von Dienstleistungen an Amazon MSK übergeben kann.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"kafka:*",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcAttribute",
"kms:DescribeKey",
"kms:CreateGrant",
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups",
"S3:GetBucketPolicy",
"firehose:TagDeliveryStream"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc/*",
"arn:*:ec2:*:*:subnet/*",
"arn:*:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/AWSMSKManaged": "true"
},
"StringLike": {
"aws:RequestTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteVpcEndpoints"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AWSMSKManaged": "true"
},
"StringLike": {
"ec2:ResourceTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/delivery.logs.amazonaws.com/AWSServiceRoleForLogDelivery*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "delivery.logs.amazonaws.com"
}
}
}
]
}
```
------
# AWS verwaltete Richtlinie: Amazon MSKRead OnlyAccess
Diese Richtlinie gewährt schreibgeschützte Berechtigungen, die es Benutzern erlauben, Informationen in Amazon MSK anzuzeigen. Prinzipale, denen diese Richtlinie angefügt ist, können keine Aktualisierungen vornehmen oder bestehende Ressourcen löschen. Sie können auch keine neuen Amazon-MSK-Ressourcen erstellen. Prinzipale mit diesen Berechtigungen können beispielsweise die Liste der Cluster und Konfigurationen, die mit ihrem Konto verknüpft sind, einsehen, aber nicht die Konfiguration oder Einstellungen von Clustern ändern. Die Berechtigungen in dieser Richtlinie sind wie folgt gruppiert:
+ **`Amazon MSK`Berechtigungen** — ermöglichen es Ihnen, Amazon MSK-Ressourcen aufzulisten, zu beschreiben und Informationen über sie abzurufen.
+ **`Amazon EC2`Berechtigungen** — werden verwendet, um die Amazon VPC, Subnetze und Sicherheitsgruppen zu beschreiben, ENIs die einem Cluster zugeordnet sind.
+ **`AWS KMS`Permission** — wird verwendet, um den Schlüssel zu beschreiben, der dem Cluster zugeordnet ist.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"kafka:Describe*",
"kafka:List*",
"kafka:Get*",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
# AWS verwaltete Richtlinie: KafkaServiceRolePolicy
Sie können keine Verbindungen KafkaServiceRolePolicy zu Ihren IAM-Entitäten herstellen. Diese Richtlinie ist mit einer servicegebundenen Rolle verknüpft, die es Amazon MSK ermöglicht, Aktionen wie die Verwaltung von VPC-Endpunkten (Konnektoren) auf MSK-Clustern, die Verwaltung von Netzwerkschnittstellen und die Verwaltung von Cluster-Anmeldeinformationen mit AWS Secrets Manager durchzuführen. Weitere Informationen finden Sie unter [Servicebezogene Rollen für Amazon MSK](using-service-linked-roles.md).
In der folgenden Tabelle werden die Aktualisierungen der KafkaServiceRolePolicy verwalteten Richtlinie seit Beginn der Nachverfolgung von Änderungen durch Amazon MSK beschrieben.
| Änderungen | Beschreibung | Date |
| --- | --- | --- |
| [IPv6 Konnektivitätsunterstützung hinzugefügt zu KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) — Aktualisierung einer bestehenden Richtlinie | Amazon MSK hat Berechtigungen hinzugefügt, KafkaServiceRolePolicy um IPv6 Konnektivität für MSK-Cluster zu aktivieren. Diese Berechtigungen ermöglichen Amazon MSK, Netzwerkschnittstellen IPv6 Adressen zuzuweisen und deren Zuweisung aufzuheben und Netzwerkschnittstellenattribute im Kundenkonto zu ändern. | 17. November 2025 |
| [KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) – Aktualisierung auf eine bestehende Richtlinie | Amazon MSK hat Berechtigungen zur Unterstützung privater Multi-VPC-Konnektivität hinzugefügt. | 08. März 2023 |
| Amazon MSK hat mit der Nachverfolgung von Änderungen begonnen | Amazon MSK hat damit begonnen, Änderungen an KafkaServiceRolePolicy verwalteten Richtlinien nachzuverfolgen. | 08. März 2023 |
# AWS verwaltete Richtlinie: AWSMSKReplicator ExecutionRole
Die `AWSMSKReplicatorExecutionRole` Richtlinie gewährt dem Amazon MSK-Replikator die Erlaubnis, Daten zwischen MSK-Clustern zu replizieren. Die Berechtigungen in dieser Richtlinie sind wie folgt gruppiert:
+ **`cluster`**— Erteilt dem Amazon MSK Replicator die Berechtigung, mithilfe der IAM-Authentifizierung eine Verbindung zum Cluster herzustellen. Erteilt außerdem Berechtigungen zur Beschreibung und Änderung des Clusters.
+ **`topic`**— Erteilt dem Amazon MSK Replicator Berechtigungen zum Beschreiben, Erstellen und Ändern eines Themas sowie zum Ändern der dynamischen Konfiguration des Themas.
+ **`consumer group`**— Erteilt dem Amazon MSK Replicator Berechtigungen zum Beschreiben und Ändern von Nutzergruppen, zum Lesen und Schreiben von Daten aus einem MSK-Cluster und zum Löschen interner Themen, die vom Replikator erstellt wurden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ClusterPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeCluster",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:*:*:cluster/*"
]
},
{
"Sid": "TopicPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:AlterCluster"
],
"Resource": [
"arn:aws:kafka:*:*:topic/*/*"
]
},
{
"Sid": "GroupPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:*:*:group/*/*"
]
}
]
}
```
------
# Amazon MSK aktualisiert AWS verwaltete Richtlinien
Sehen Sie sich Details zu Aktualisierungen der AWS verwalteten Richtlinien für Amazon MSK an, seit dieser Service begonnen hat, diese Änderungen zu verfolgen.
| Änderungen | Beschreibung | Date |
| --- | --- | --- |
| [WriteDataIdempotently Berechtigung hinzugefügt zu AWSMSKReplicator ExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) — Aktualisierung einer bestehenden Richtlinie | Amazon MSK hat der AWSMSKReplicator ExecutionRole Richtlinie die WriteDataIdempotently Erlaubnis zur Unterstützung der Datenreplikation zwischen MSK-Clustern hinzugefügt. | 12. März 2024 |
| [AWSMSKReplicatorExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) – Neue Richtlinie | Amazon MSK hat eine AWSMSKReplicator ExecutionRole Richtlinie zur Unterstützung von Amazon MSK Replicator hinzugefügt. | 4. Dezember 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Aktualisierung einer bestehenden Richtlinie | Amazon MSK hat Berechtigungen zur Unterstützung von Amazon MSK Replicator hinzugefügt. | 28. September 2023 |
| [KafkaServiceRolePolicy](security-iam-awsmanpol-KafkaServiceRolePolicy.md) – Aktualisierung auf eine bestehende Richtlinie | Amazon MSK hat Berechtigungen zur Unterstützung privater Multi-VPC-Konnektivität hinzugefügt. | 08. März 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Aktualisierung einer bestehenden Richtlinie | Amazon MSK hat neue Amazon-EC2-Berechtigungen hinzugefügt, um die Verbindung zu einem Cluster zu ermöglichen. | 30. November 2021 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Aktualisierung einer bestehenden Richtlinie | Amazon MSK hat eine neue Berechtigung hinzugefügt, mit der Amazon-EC2-Routing-Tabellen beschrieben werden können. | 19. November 2021 |
| Amazon MSK hat mit der Nachverfolgung von Änderungen begonnen | Amazon MSK hat damit begonnen, Änderungen an seinen AWS verwalteten Richtlinien nachzuverfolgen. | 19. November 2021 |
# Problembehandlung bei Amazon MSK-Identität und -Zugriff
Diagnostizieren und beheben Sie mithilfe der folgenden Informationen gängige Probleme, die bei der Verwendung von Amazon MSK und IAM auftreten können.
**Topics**
+ [Ich bin nicht autorisiert, eine Aktion in Amazon MSK auszuführen](#security_iam_troubleshoot-no-permissions)
## Ich bin nicht autorisiert, eine Aktion in Amazon MSK auszuführen
Wenn Ihnen AWS-Managementkonsole mitgeteilt wird, dass Sie nicht berechtigt sind, eine Aktion durchzuführen, müssen Sie sich an Ihren Administrator wenden, um Unterstützung zu erhalten. Ihr Administrator hat Ihnen Ihre Anmeldeinformationen zur Verfügung gestellt.
Der folgende Beispielfehler tritt auf, wenn der `mateojackson`-IAM-Benutzer versucht, die Konsole zum Löschen eines Clusters zu verwenden, jedoch nicht über `kafka:DeleteCluster`-Berechtigungen verfügt.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: kafka:DeleteCluster on resource: purchaseQueriesCluster
```
In diesem Fall bittet Mateo seinen Administrator um die Aktualisierung seiner Richtlinien, um unter Verwendung der Aktion `purchaseQueriesCluster` auf die Ressource `kafka:DeleteCluster` zugreifen zu können.
# Authentifizierung und Autorisierung für Apache Kafka APIs
Sie können IAM verwenden, um Clients zu authentifizieren und Apache-Kafka-Aktionen zu erlauben oder zu verweigern. Alternativ können Sie TLS oder SASL/SCRAM zur Authentifizierung von Clients und Apache Kafka verwenden, ACLs um Aktionen zuzulassen oder abzulehnen.
Informationen darüber, wie Sie steuern können, wer [Amazon-MSK-Vorgänge](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) auf Ihrem Cluster ausführen kann, finden Sie unter [Authentifizierung und Autorisierung für Amazon MSK APIs](security-iam.md).
**Topics**
+ [IAM-Zugriffssteuerung](iam-access-control.md)
+ [Gegenseitige TLS-Client-Authentifizierung für Amazon MSK](msk-authentication.md)
+ [Authentifizierung der Anmeldedaten mit AWS Secrets Manager](msk-password.md)
+ [Apache Kafka ACLs](msk-acls.md)
# IAM-Zugriffssteuerung
IAM-Zugriffssteuerung für Amazon MSK ermöglicht es Ihnen, sowohl die Authentifizierung als auch die Autorisierung für Ihren MSK-Cluster zu verwalten. Dies macht die Verwendung eines Mechanismus für die Authentifizierung und einen anderen für die Autorisierung überflüssig. Wenn ein Client beispielsweise versucht, in Ihren Cluster zu schreiben, prüft Amazon MSK mithilfe von IAM, ob es sich bei diesem Client um eine authentifizierte Identität handelt und ob er berechtigt ist, für Ihren Cluster zu produzieren.
Die IAM-Zugriffskontrolle funktioniert für Java- und Nicht-Java-Clients, einschließlich Kafka-Clients, die in Python JavaScript, Go und.NET geschrieben sind. Die IAM-Zugriffskontrolle für Nicht-Java-Clients ist für MSK-Cluster mit Kafka-Version 2.7.1 oder höher verfügbar.
Um die IAM-Zugriffssteuerung zu ermöglichen, nimmt Amazon MSK geringfügige Änderungen am Apache-Kafka-Quellcode vor. Diese Änderungen werden keinen spürbaren Unterschied in Ihrem Apache-Kafka-Erlebnis bewirken. Amazon MSK protokolliert Zugriffsereignisse, sodass Sie sie prüfen können.
Sie können Apache Kafka ACL APIs für einen MSK-Cluster aufrufen, der IAM-Zugriffskontrolle verwendet. Apache Kafka ACLs hat jedoch keine Auswirkung auf die Autorisierung für IAM-Identitäten. Sie müssen IAM-Richtlinien verwenden, um den Zugriff auf IAM-Identitäten zu kontrollieren.
**Wichtige Überlegungen**
Wenn Sie die IAM-Zugriffskontrolle mit Ihrem MSK-Cluster verwenden, sollten Sie die folgenden wichtigen Überlegungen berücksichtigen:
Die IAM-Zugriffskontrolle gilt nicht für Apache-Knoten. ZooKeeper Weitere Informationen zum Steuern des Zugriffs auf diese Knoten finden Sie unter [Steuern Sie den Zugriff auf ZooKeeper Apache-Knoten in Ihrem Amazon MSK-Cluster](zookeeper-security.md).
Die Apache-Kafka-Einstellung `allow.everyone.if.no.acl.found` hat keine Auswirkung, wenn Ihr Cluster die IAM-Zugriffssteuerung verwendet.
Sie können Apache Kafka ACL APIs für einen MSK-Cluster aufrufen, der IAM-Zugriffskontrolle verwendet. Apache Kafka ACLs hat jedoch keine Auswirkung auf die Autorisierung für IAM-Identitäten. Sie müssen IAM-Richtlinien verwenden, um den Zugriff auf IAM-Identitäten zu kontrollieren.
# So funktioniert die IAM-Zugriffssteuerung für Amazon MSK
Um die IAM-Zugriffskontrolle für Amazon MSK zu verwenden, führen Sie die folgenden Schritte aus, die in diesen Themen ausführlich beschrieben werden:
+ [Erstellen Sie einen Amazon MSK-Cluster, der IAM-Zugriffskontrolle verwendet](create-iam-access-control-cluster-in-console.md)
+ [Konfiguration von Clients für die IAM-Zugriffssteuerung](configure-clients-for-iam-access-control.md)
+ [Erstellen Sie Autorisierungsrichtlinien für die IAM-Rolle](create-iam-access-control-policies.md)
+ [Bootstrap-Broker für IAM-Zugriffssteuerung abrufen](get-bootstrap-brokers-for-iam.md)
# Erstellen Sie einen Amazon MSK-Cluster, der IAM-Zugriffskontrolle verwendet
In diesem Abschnitt wird erklärt, wie Sie die AWS-Managementkonsole, die API oder die verwenden können, AWS CLI um einen Amazon MSK-Cluster zu erstellen, der IAM-Zugriffskontrolle verwendet. Informationen zum Aktivieren der IAM-Zugriffssteuerung für einen vorhandenen Cluster finden Sie unter [Sicherheitseinstellungen eines Amazon MSK-Clusters aktualisieren](msk-update-security.md).
**Verwenden Sie den AWS-Managementkonsole , um einen Cluster zu erstellen, der die IAM-Zugriffskontrolle verwendet**
1. Öffnen Sie die Amazon-MSK-Konsole unter [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Wählen Sie **Cluster erstellen**.
1. Wählen Sie **Cluster mit benutzerdefinierten Einstellungen erstellen**.
1. Wählen Sie im Abschnitt **Authentifizierung** die Option **IAM-Zugriffssteuerung** aus.
1. Führen Sie den Rest des Workflows zum Erstellen eines Clusters aus.
**Verwenden Sie die API oder die AWS CLI , um einen Cluster zu erstellen, der die IAM-Zugriffskontrolle verwendet**
+ Um einen Cluster mit aktivierter IAM-Zugriffskontrolle zu erstellen, verwenden Sie die [CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)API oder den CLI-Befehl [create-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/create-cluster.html) und übergeben Sie den folgenden JSON-Code für den `ClientAuthentication` Parameter:. `"ClientAuthentication": { "Sasl": { "Iam": { "Enabled": true } }`
# Konfiguration von Clients für die IAM-Zugriffssteuerung
Damit Clients mit einem MSK-Cluster kommunizieren können, der die IAM-Zugriffskontrolle verwendet, können Sie einen der folgenden Mechanismen verwenden:
+ Konfiguration eines Nicht-Java-Clients mithilfe eines Mechanismus SASL\$1OAUTHBEARER
+ Konfiguration des Java-Clients mithilfe eines SASL\$1OAUTHBEARER Mechanismus oder AWS\$1MSK\$1IAM Mechanismus
## Verwenden Sie den SASL\$1OAUTHBEARER Mechanismus, um IAM zu konfigurieren
1. Bearbeiten Sie Ihre client.properties-Konfigurationsdatei mit dem folgenden Python-Kafka-Client-Beispiel. Konfigurationsänderungen sind in anderen Sprachen ähnlich.
```
from kafka import KafkaProducer
from kafka.errors import KafkaError
from kafka.sasl.oauth import AbstractTokenProvider
import socket
import time
from aws_msk_iam_sasl_signer import MSKAuthTokenProvider
class MSKTokenProvider():
def token(self):
token, _ = MSKAuthTokenProvider.generate_auth_token('')
return token
tp = MSKTokenProvider()
producer = KafkaProducer(
bootstrap_servers='',
security_protocol='SASL_SSL',
sasl_mechanism='OAUTHBEARER',
sasl_oauth_token_provider=tp,
client_id=socket.gethostname(),
)
topic = ""
while True:
try:
inp=input(">")
producer.send(topic, inp.encode())
producer.flush()
print("Produced!")
except Exception:
print("Failed to send message:", e)
producer.close()
```
1. Laden Sie die Hilfsbibliothek für die von Ihnen gewählte Konfigurationssprache herunter und folgen Sie den Anweisungen im Abschnitt *Erste Schritte* auf der Homepage dieser Sprachbibliothek.
+ JavaScript: [https://github.com/aws/aws-msk-iam-sasl-signer-js](https://github.com/aws/aws-msk-iam-sasl-signer-js#getting-started) \$1getting -started
+ Python: [https://github.com/aws/aws-msk-iam-sasl-signer-python](https://github.com/aws/aws-msk-iam-sasl-signer-python#get-started) \$1get -gestartet
+ [Gehe zu: -signer-go \$1getting -gestartet https://github.com/aws/ aws-msk-iam-sasl](https://github.com/aws/aws-msk-iam-sasl-signer-go#getting-started)
+ [.NET: -signer-net \$1getting -gestartet https://github.com/aws/ aws-msk-iam-sasl](https://github.com/aws/aws-msk-iam-sasl-signer-net#getting-started)
+ JAVA: SASL\$1OAUTHBEARER Unterstützung für Java ist über die JAR-Datei verfügbar [https://github.com/aws/aws-msk-iam-auth/releases](https://github.com/aws/aws-msk-iam-auth/releases)
## Verwenden Sie den benutzerdefinierten AWS\$1MSK\$1IAM MSK-Mechanismus, um IAM zu konfigurieren
1. Fügen Sie der Datei `client.properties` Folgendes hinzu. **Ersetzen Sie ihn durch den vollqualifizierten Pfad zur Trust Store-Datei auf dem Client.
**Anmerkung**
Wenn Sie ein bestimmtes Zertifikat nicht verwenden möchten, können Sie `ssl.truststore.location=` aus Ihrer `client.properties`-Datei entfernen. Wenn Sie keinen Wert für `ssl.truststore.location` angeben, verwendet der Java-Prozess das Standardzertifikat.
```
ssl.truststore.location=
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
```
Um ein benanntes Profil zu verwenden, das Sie für AWS Anmeldeinformationen erstellt haben, nehmen Sie es `awsProfileName="your profile name";` in Ihre Client-Konfigurationsdatei auf. Informationen zu benannten Profilen finden Sie in der AWS CLI Dokumentation unter [Benannte Profile](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html).
1. Laden Sie die neueste stabile [aws-msk-iam-auth](https://github.com/aws/aws-msk-iam-auth/releases)JAR-Datei herunter und platzieren Sie sie im Klassenpfad. Wenn Sie Maven verwenden, fügen Sie die folgende Abhängigkeit hinzu und passen Sie die Versionsnummer nach Bedarf an:
```
software.amazon.msk
aws-msk-iam-auth
1.0.0
```
Das Amazon-MSK-Client-Plugin ist unter der Apache-2.0-Lizenz als Open-Source verfügbar.
# Erstellen Sie Autorisierungsrichtlinien für die IAM-Rolle
Fügen Sie eine Autorisierungsrichtlinie an die IAM-Rolle an, die dem Client entspricht. In einer Autorisierungsrichtlinie geben Sie an, welche Aktionen für die Rolle erlaubt oder verweigert werden sollen. Wenn sich Ihr Client auf einer Amazon-EC2-Instance befindet, ordnen Sie die Autorisierungsrichtlinie der IAM-Rolle für diese Amazon-EC2-Instance zu. Alternativ können Sie Ihren Client so konfigurieren, dass er ein benanntes Profil verwendet, und dann die Autorisierungsrichtlinie der Rolle für dieses benannte Profil zuordnen. [Konfiguration von Clients für die IAM-Zugriffssteuerung](configure-clients-for-iam-access-control.md) beschreibt, wie ein Client für die Verwendung eines benannten Profils konfiguriert wird.
Informationen zum Erstellen einer IAM-Richtlinie finden Sie unter [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).
Im Folgenden finden Sie ein Beispiel für eine Autorisierungsrichtlinie für einen Cluster mit dem Namen MyTestCluster. Informationen zur Semantik der `Action`- und `Resource`-Elemente finden Sie unter [Semantik der Aktionen und Ressourcen der IAM-Autorisierungsrichtlinie](kafka-actions.md).
**Wichtig**
Änderungen, die Sie an einer IAM-Richtlinie vornehmen, werden in der IAM APIs und in der sofort widergespiegelt. AWS CLI Es kann jedoch einige Zeit dauern, bis die Änderung der Richtlinie wirksam wird. In den meisten Fällen werden Richtlinien-Änderungen in weniger als einer Minute wirksam. Netzwerkbedingungen können die Verzögerung manchmal erhöhen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster"
],
"Resource": [
"arn:aws:kafka:us-east-1:111122223333:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*"
]
}
]
}
```
------
Informationen zum Erstellen einer Richtlinie mit Aktionselementen, die gängigen Anwendungsfällen von Apache Kafka entsprechen, wie z. B. das Erzeugen und Verbrauchen von Daten, finden Sie unter [Häufige Anwendungsfälle für Client-Autorisierungsrichtlinien](iam-access-control-use-cases.md).
[Für Kafka-Versionen 2.8.0 und höher ist die **WriteDataIdempotently**Berechtigung veraltet (KIP-679).](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default) `enable.idempotence = true` ist standardmäßig festgelegt. Daher bietet IAM für die Kafka-Versionen 2.8.0 und höher nicht die gleiche Funktionalität wie Kafka. ACLs Es ist nicht möglich, zu einem Thema `WriteDataIdempotently` zu gelangen, indem man nur `WriteData` Zugriff auf dieses Thema gewährt. Dies hat keinen Einfluss auf den Fall, dass `WriteData` es für **ALLE** Themen bereitgestellt wird. In diesem Fall ist `WriteDataIdempotently` erlaubt. Dies ist auf Unterschiede in der Implementierung der IAM-Logik und der Implementierung von Kafka ACLs zurückzuführen. Darüber hinaus erfordert das Schreiben zu einem Thema unabhängig davon auch Zugriff auf. `transactional-ids`
Um dieses Problem zu umgehen, empfehlen wir, eine Richtlinie zu verwenden, die der folgenden Richtlinie ähnelt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic",
"arn:aws:kafka:us-east-1:123456789012:transactional-id/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*"
]
}
]
}
```
------
In diesem Fall erlaubt `WriteData` Schreibvorgänge in `TestTopic`, während `WriteDataIdempotently` idempotente Schreibvorgänge in den Cluster erlaubt. Diese Richtlinie ermöglicht auch den Zugriff auf die `transactional-id` Ressourcen, die benötigt werden.
Da `WriteDataIdempotently` es sich um eine Berechtigung auf Clusterebene handelt, können Sie sie nicht auf Themenebene verwenden. Wenn sie auf Themenebene beschränkt `WriteDataIdempotently` ist, funktioniert diese Richtlinie nicht.
# Bootstrap-Broker für IAM-Zugriffssteuerung abrufen
Siehe [Holen Sie sich die Bootstrap-Broker für einen Amazon MSK-Cluster](msk-get-bootstrap-brokers.md).
# Semantik der Aktionen und Ressourcen der IAM-Autorisierungsrichtlinie
**Anmerkung**
Für Cluster, auf denen Apache Kafka Version 3.8 oder höher ausgeführt wird, unterstützt die IAM-Zugriffskontrolle die WriteTxnMarkers API zum Beenden von Transaktionen. Für Cluster, auf denen Kafka-Versionen vor 3.8 ausgeführt werden, unterstützt die IAM-Zugriffskontrolle keine internen Clusteraktionen, einschließlich. WriteTxnMarkers Verwenden Sie für diese früheren Versionen zum Beenden von Transaktionen die SCRAM- oder mTLS-Authentifizierung mit entsprechender ACLs anstelle der IAM-Authentifizierung.
In diesem Abschnitt wird die Semantik der Aktions- und Ressourcenelemente erläutert, die Sie in einer IAM-Autorisierungsrichtlinie verwenden können. Eine Beispielrichtlinie finden Sie unter [Erstellen Sie Autorisierungsrichtlinien für die IAM-Rolle](create-iam-access-control-policies.md).
## Aktionen der Autorisierungsrichtlinie
In der folgenden Tabelle sind die Aktionen aufgeführt, die Sie in eine Autorisierungsrichtlinie aufnehmen können, wenn Sie IAM-Zugriffssteuerung für Amazon MSK verwenden. Wenn Sie in Ihre Autorisierungsrichtlinie eine Aktion aus der Spalte *Aktion* der Tabelle aufnehmen, müssen Sie auch die entsprechenden Aktionen aus der Spalte *Erforderliche Aktionen* angeben.
| Action | Description | Erforderliche Aktionen | Erforderliche -Ressourcen | Gilt für Serverless-Cluster |
| --- | --- | --- | --- | --- |
| kafka-cluster:Connect | Gewährt die Berechtigung, sich mit dem Cluster zu verbinden und zu authentifizieren. | Keine | Cluster | Ja |
| kafka-cluster:DescribeCluster | Gewährt die Berechtigung zum Beschreiben verschiedener Aspekte des Clusters, was der DESCRIBE CLUSTER ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` | Cluster | Ja |
| kafka-cluster:AlterCluster | Gewährt die Berechtigung zum Ändern verschiedener Aspekte des Clusters, was der ALTER CLUSTER ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` `kafka-cluster:DescribeCluster` | Cluster | Nein |
| kafka-cluster:DescribeClusterDynamicConfiguration | Gewährt die Berechtigung zum Beschreiben der dynamischen Konfiguration eines Clusters, was der DESCRIBE\$1CONFIGS CLUSTER ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` | Cluster | Nein |
| kafka-cluster:AlterClusterDynamicConfiguration | Gewährt die Berechtigung zum Ändern der dynamischen Konfiguration eines Clusters, was der ALTER\$1CONFIGS CLUSTER ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` | Cluster | Nein |
| kafka-cluster:WriteDataIdempotently | Gewährt die Berechtigung zum idempotenten Schreiben von Daten auf einen Cluster, was der IDEMPOTENT\$1WRITE CLUSTER ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` `kafka-cluster:WriteData` | Cluster | Ja |
| kafka-cluster:CreateTopic | Erteilt die Berechtigung zum Erstellen von Themen in einem Cluster, was der CREATE CLUSTER/TOPIC ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` | Thema | Ja |
| kafka-cluster:DescribeTopic | Gewährt die Berechtigung zum Beschreiben von Themen auf einem Cluster, was der DESCRIBE TOPIC ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` | Thema | Ja |
| kafka-cluster:AlterTopic | Gewährt die Berechtigung zum Ändern von Themen auf einem Cluster, was der ALTER TOPIC ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | Thema | Ja |
| kafka-cluster:DeleteTopic | Gewährt die Berechtigung zum Löschen von Themen auf einem Cluster, was der DELETE TOPIC ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | Thema | Ja |
| kafka-cluster:DescribeTopicDynamicConfiguration | Gewährt die Berechtigung zum Beschreiben der dynamischen Konfiguration von Themen auf einem Cluster, was der DESCRIBE\$1CONFIGS TOPIC ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` | Thema | Ja |
| kafka-cluster:AlterTopicDynamicConfiguration | Gewährt die Berechtigung zum Ändern der dynamischen Konfiguration von Themen auf einem Cluster, was der ALTER\$1CONFIGS TOPIC ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` | Thema | Ja |
| kafka-cluster:ReadData | Gewährt die Berechtigung zum Lesen von Daten aus Themen auf einem Cluster, was der READ TOPIC ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterGroup` | Thema | Ja |
| kafka-cluster:WriteData | Gewährt die Berechtigung zum Schreiben von Daten zu Themen auf einem Cluster, was der WRITE-TOPIC-ACL von Apache Kafka entspricht | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | Thema | Ja |
| kafka-cluster:DescribeGroup | Gewährt die Berechtigung zum Beschreiben von Gruppen auf einem Cluster, was der DESCRIBE GROUP ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` | Gruppe | Ja |
| kafka-cluster:AlterGroup | Gewährt die Berechtigung, Gruppen in einem Cluster beizutreten, was der READ GROUP ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | Gruppe | Ja |
| kafka-cluster:DeleteGroup | Gewährt die Berechtigung zum Löschen von Gruppen auf einem Cluster, was der DELETE GROUP ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | Gruppe | Ja |
| kafka-cluster:DescribeTransactionalId | Erteilt die Berechtigung zur Beschreibung von Transaktionen IDs auf einem Cluster, was der DESCRIBE TRANSACTIONAL\$1ID-ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` | transactional-id | Ja |
| kafka-cluster:AlterTransactionalId | Erteilt die Berechtigung, Transaktionen auf einem Cluster zu ändern, was der WRITE IDs TRANSACTIONAL\$1ID-ACL von Apache Kafka entspricht. | `kafka-cluster:Connect` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:WriteData` | transactional-id | Ja |
Sie können das Sternchen (\$1) als Platzhalter in einer Aktion hinter dem Doppelpunkt beliebig oft verwenden. Im Folgenden sind einige Beispiele aufgeführt.
+ `kafka-cluster:*Topic` steht für `kafka-cluster:CreateTopic`, `kafka-cluster:DescribeTopic`, `kafka-cluster:AlterTopic` und `kafka-cluster:DeleteTopic`. Es beinhaltet nicht `kafka-cluster:DescribeTopicDynamicConfiguration` oder `kafka-cluster:AlterTopicDynamicConfiguration`.
+ `kafka-cluster:*` steht für alle Berechtigungen.
## Ressourcen für Autorisierungsrichtlinien
In der folgenden Tabelle sind die vier Arten von Ressourcen aufgeführt, die Sie in eine Autorisierungsrichtlinie aufnehmen können, wenn Sie IAM-Zugriffssteuerung für Amazon MSK verwenden. Sie können den Cluster-Amazon-Ressourcennamen (ARN) von AWS-Managementkonsole oder mithilfe der [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)API oder des Befehls [describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI abrufen. Anschließend können Sie den Cluster-ARN verwenden, um Themen-, Gruppen- und Transaktions-IDs zu erstellen. ARNs Um eine Ressource in einer Autorisierungsrichtlinie anzugeben, verwenden Sie den ARN dieser Ressource.
| Ressource | ARN-Format |
| --- | --- |
| Cluster | arn:aws:kafka: ::cluster//regionaccount-idcluster-namecluster-uuid |
| Thema | arn:aws:kafka: region ::topic///account-idcluster-namecluster-uuidtopic-name |
| Group (Gruppieren) | arn:aws:kafka: region ::group///account-idcluster-namecluster-uuidgroup-name |
| Transkaktions-ID | arn:aws:kafka: region ::transactional-id//account-idcluster-namecluster-uuidtransactional-id |
Sie können das Sternchen (\$1) als Platzhalter beliebig oft an beliebiger Stelle in dem Teil des ARN verwenden, der nach `:cluster/`, `:topic/`, `:group/` und `:transactional-id/` folgt. Im Folgenden finden Sie einige Beispiele dafür, wie Sie das Sternchen (\$1) als Platzhalter verwenden können, um auf mehrere Ressourcen zu verweisen:
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/*`: alle Themen in einem beliebigen Cluster mit Namen, unabhängig von der UUID des Clusters. MyTestCluster
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*_test`: alle Themen, deren Name mit „\$1test“ endet, in dem Cluster, dessen Name MyTestCluster und dessen UUID abcd1234-0123-abcd-5678-1234abcd-1 ist.
+ `arn:aws:kafka:us-east-1:0123456789012:transactional-id/MyTestCluster/*/5555abcd-1111-abcd-1234-abcd1234-1`: alle Transaktionen, deren Transaktions-ID 5555abcd-1111-abcd-1234-abcd1234-1 lautet, in allen Inkarnationen eines Clusters, der in Ihrem Konto benannt ist. MyTestCluster Das heißt, wenn Sie einen Cluster mit dem Namen erstellen MyTestCluster, ihn dann löschen und dann einen weiteren Cluster mit demselben Namen erstellen, können Sie diesen Ressourcen-ARN verwenden, um dieselbe Transaktions-ID auf beiden Clustern darzustellen. Auf den gelöschten Cluster kann jedoch nicht zugegriffen werden.
# Häufige Anwendungsfälle für Client-Autorisierungsrichtlinien
Die erste Spalte der folgenden Tabelle zeigt einige gängige Anwendungsfälle. Um einen Client zur Ausführung eines bestimmten Anwendungsfalls zu autorisieren, nehmen Sie die für diesen Anwendungsfall erforderlichen Aktionen in die Autorisierungsrichtlinie des Clients auf und stellen Sie `Effect` auf `Allow` ein.
Informationen zu allen Aktionen, die Teil der IAM-Zugriffssteuerung für Amazon MSK sind, finden Sie unter [Semantik der Aktionen und Ressourcen der IAM-Autorisierungsrichtlinie](kafka-actions.md).
**Anmerkung**
Aktionen werden standardmäßig verweigert. Sie müssen jede Aktion, zu deren Ausführung Sie den Client autorisieren möchten, ausdrücklich erlauben.
****
| Anwendungsfall | Erforderliche Aktionen |
| --- | --- |
| Admin. | `kafka-cluster:*` |
| Erstellen Sie ein Thema | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` |
| Daten produzieren | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` |
| Daten verbrauchen | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeGroup` `kafka-cluster:AlterGroup` `kafka-cluster:ReadData` |
| Daten idempotent produzieren | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:WriteDataIdempotently` |
| Daten transaktionell produzieren | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:AlterTransactionalId` |
| Die Konfiguration eines Clusters beschreiben | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` |
| Die Konfiguration eines Clusters aktualisieren | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` `kafka-cluster:AlterClusterDynamicConfiguration` |
| Die Konfiguration eines Themas beschreiben | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` |
| Die Konfiguration eines Themas aktualisieren | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` `kafka-cluster:AlterTopicDynamicConfiguration` |
| Ein Thema ändern | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` |
# Gegenseitige TLS-Client-Authentifizierung für Amazon MSK
Sie können die Client-Authentifizierung mit TLS für Verbindungen von Ihren Anwendungen zu Ihren Amazon MSK-Brokern aktivieren. Damit Sie die Client-Authentifizierung verwenden können, benötigen Sie eine AWS Private CA. AWS Private CA Sie können sich entweder in demselben AWS-Konto Cluster oder in einem anderen Konto befinden. Informationen zu AWS Private CA s finden Sie unter [Erstellen und Verwalten von AWS Private CA](https://docs.aws.amazon.com/acm-pca/latest/userguide/create-CA.html).
Amazon MSK unterstützt keine Zertifikatssperrlisten (CRLs). Verwenden Sie Apache Kafka ACLs und Sicherheitsgruppen, um den Zugriff auf Ihre Cluster-Themen zu kontrollieren oder kompromittierte Zertifikate zu blockieren. AWS Hinweise zur Verwendung von Apache Kafka ACLs finden Sie unter. [Apache Kafka ACLs](msk-acls.md)
**Topics**
+ [Erstellen Sie einen Amazon MSK-Cluster, der die Client-Authentifizierung unterstützt](msk-authentication-cluster.md)
+ [Richten Sie einen Client für die Verwendung der Authentifizierung ein](msk-authentication-client.md)
+ [Erstellen und konsumieren Sie Nachrichten mithilfe von Authentifizierung](msk-authentication-messages.md)
# Erstellen Sie einen Amazon MSK-Cluster, der die Client-Authentifizierung unterstützt
Dieses Verfahren zeigt Ihnen, wie Sie die Client-Authentifizierung mithilfe von aktivieren. AWS Private CA
**Anmerkung**
Wir empfehlen dringend, unabhängig AWS Private CA für jeden MSK-Cluster zu verwenden, wenn Sie Mutual TLS zur Zugriffskontrolle verwenden. Dadurch wird sichergestellt, dass TLS-Zertifikate, die von signiert wurden, PCAs nur bei einem einzigen MSK-Cluster authentifiziert werden.
1. Erstellen Sie eine Datei mit dem Namen `clientauthinfo.json` und dem folgenden Inhalt. *Private-CA-ARN*Ersetzen Sie es durch den ARN Ihres PCA.
```
{
"Tls": {
"CertificateAuthorityArnList": ["Private-CA-ARN"]
}
}
```
1. Erstellen Sie eine Datei mit dem Namen `brokernodegroupinfo.json`, wie unter [Erstellen Sie einen bereitgestellten Amazon MSK-Cluster mit dem AWS CLI](create-cluster-cli.md) beschrieben.
1. Für die Client-Authentifizierung müssen Sie auch die Verschlüsselung während der Übertragung zwischen Clients und Brokern aktivieren. Erstellen Sie eine Datei mit dem Namen `encryptioninfo.json` und dem folgenden Inhalt. *KMS-Key-ARN*Ersetzen Sie es durch den ARN Ihres KMS-Schlüssels. Für `ClientBroker` können Sie `TLS` oder `TLS_PLAINTEXT` festlegen.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "KMS-Key-ARN"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Weitere Informationen zur Verschlüsselung finden Sie unter [Amazon-MSK-Verschlüsselung](msk-encryption.md).
1. Führen Sie auf einem Computer, auf dem Sie das AWS CLI installiert haben, den folgenden Befehl aus, um einen Cluster mit aktivierter Authentifizierung und Verschlüsselung bei der Übertragung zu erstellen. Speichern Sie den in der Antwort angegebenen Cluster-ARN.
```
aws kafka create-cluster --cluster-name "AuthenticationTest" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --client-authentication file://clientauthinfo.json --kafka-version "{YOUR KAFKA VERSION}" --number-of-broker-nodes 3
```
# Richten Sie einen Client für die Verwendung der Authentifizierung ein
Dieser Prozess beschreibt, wie Sie eine Amazon EC2 EC2-Instance einrichten, die als Client für die Authentifizierung verwendet wird.
Dieser Prozess beschreibt, wie Nachrichten mithilfe der Authentifizierung erzeugt und verarbeitet werden, indem ein Client-Computer erstellt, ein Thema erstellt und die erforderlichen Sicherheitseinstellungen konfiguriert werden.
1. Erstellen Sie eine Amazon-EC2-Instance, die als Client-Computer verwendet werden soll. Erstellen Sie diese Instance der Einfachheit halber in derselben VPC, die Sie für den Cluster verwendet haben. Unter [Schritt 3: Einen Client-Computer erstellen](create-client-machine.md) finden Sie ein Beispiel dafür, wie Sie solch einen Client-Computer erstellen können.
1. Erstellen eines Themas. Ein Beispiel finden Sie in den Anweisungen unter [Schritt 4: Erstellen Sie ein Thema im Amazon MSK-Cluster](create-topic.md).
1. Führen Sie auf einem Computer, auf dem Sie das AWS CLI installiert haben, den folgenden Befehl aus, um die Bootstrap-Broker des Clusters abzurufen. *Cluster-ARN*Ersetzen Sie es durch den ARN Ihres Clusters.
```
aws kafka get-bootstrap-brokers --cluster-arn Cluster-ARN
```
Speichern Sie die Zeichenfolge, die `BootstrapBrokerStringTls` in der Antwort zugeordnet ist.
1. Führen Sie auf Ihrem Client-Computer den folgenden Befehl aus, um mithilfe des JVM-Vertrauensspeichers Ihren Client-Vertrauensspeicher zu erstellen. Wenn Ihr JVM-Pfad anders ist, passen Sie den Befehl entsprechend an.
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts kafka.client.truststore.jks
```
1. Führen Sie auf Ihrem Client-Computer den folgenden Befehl aus, um einen privaten Schlüssel für Ihren Client zu erstellen. Ersetzen Sie *Distinguished-Name**Example-Alias*,*Your-Store-Pass*, und *Your-Key-Pass* durch Zeichenketten Ihrer Wahl.
```
keytool -genkey -keystore kafka.client.keystore.jks -validity 300 -storepass Your-Store-Pass -keypass Your-Key-Pass -dname "CN=Distinguished-Name" -alias Example-Alias -storetype pkcs12 -keyalg rsa
```
1. Führen Sie auf Ihrem Client-Computer den folgenden Befehl aus, um eine Zertifikatsanforderung mit dem privaten Schlüssel zu erstellen, den Sie im vorherigen Schritt erstellt haben.
```
keytool -keystore kafka.client.keystore.jks -certreq -file client-cert-sign-request -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Öffnen Sie die Datei `client-cert-sign-request`, und stellen Sie sicher, dass sie mit `-----BEGIN CERTIFICATE REQUEST-----` beginnt und mit `-----END CERTIFICATE REQUEST-----` endet. Wenn sie mit `-----BEGIN NEW CERTIFICATE REQUEST-----` beginnt , löschen Sie das Wort `NEW` (und das einzelne Leerzeichen, das darauf folgt) vom Anfang und vom Ende der Datei.
1. Führen Sie auf einem Computer, auf dem Sie das AWS CLI installiert haben, den folgenden Befehl aus, um Ihre Zertifikatsanforderung zu signieren. *Private-CA-ARN*Ersetzen Sie es durch den ARN Ihres PCA. Sie können den Gültigkeitswert ändern, wenn Sie möchten. Hier verwenden wir 300 als Beispiel.
```
aws acm-pca issue-certificate --certificate-authority-arn Private-CA-ARN --csr fileb://client-cert-sign-request --signing-algorithm "SHA256WITHRSA" --validity Value=300,Type="DAYS"
```
Speichern Sie den in der Antwort angegebenen Zertifikat-ARN.
**Anmerkung**
Um Ihr Client-Zertifikat abzurufen, verwenden Sie den Befehl `acm-pca get-certificate` und geben Sie Ihren Zertifikat-ARN an. Weitere Informationen finden Sie unter [get-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm-pca/get-certificate.html) in der *AWS CLI -Befehlsreferenz*.
1. Führen Sie den folgenden Befehl aus, um das Zertifikat abzurufen, das für Sie AWS Private CA signiert wurde. *Certificate-ARN*Ersetzen Sie durch den ARN, den Sie aus der Antwort auf den vorherigen Befehl erhalten haben.
```
aws acm-pca get-certificate --certificate-authority-arn Private-CA-ARN --certificate-arn Certificate-ARN
```
1. Kopieren Sie aus dem JSON-Ergebnis der Ausführung des vorherigen Befehls die Zeichenfolgen, die `Certificate` und `CertificateChain` zugeordnet sind. Fügen Sie diese beiden Zeichenketten in eine neue Datei mit dem Namen ein signed-certificate-from-acm. Fügen Sie die Zeichenfolge, die `Certificate` zugeordnet ist, zuerst ein, gefolgt von der Zeichenfolge, die `CertificateChain` zugeordnet ist. Ersetzen Sie die Zeichen `\n` durch neue Zeilen. Im Folgenden finden Sie die Struktur der Datei, nachdem Sie das Zertifikat und die Zertifikatkette eingefügt haben.
```
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
1. Führen Sie den folgenden Befehl auf dem Client-Computer aus, um dieses Zertifikat zu Ihrem Schlüsselspeicher hinzuzufügen, damit Sie es bei der Kommunikation mit den MSK-Brokern bereitstellen können.
```
keytool -keystore kafka.client.keystore.jks -import -file signed-certificate-from-acm -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Erstellen Sie eine Datei mit dem Namen `client.properties` und dem folgenden Inhalt. Passen Sie die Speicherorte des Vertrauensspeichers und des Schlüsselspeichers an die Pfade an, in denen Sie `kafka.client.truststore.jks` gespeichert haben. Ersetzen Sie die *\$1YOUR KAFKA VERSION\$1* Platzhalter durch Ihre Kafka-Client-Version.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.truststore.jks
ssl.keystore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.keystore.jks
ssl.keystore.password=Your-Store-Pass
ssl.key.password=Your-Key-Pass
```
# Erstellen und konsumieren Sie Nachrichten mithilfe von Authentifizierung
In diesem Prozess wird beschrieben, wie Nachrichten mithilfe von Authentifizierung erstellt und verarbeitet werden.
1. Führen Sie den folgenden Befehl aus, um ein Thema zu erstellen. Die Datei namens `client.properties` ist die Datei, die Sie im vorherigen Verfahren erstellt haben.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBroker-String --replication-factor 3 --partitions 1 --topic ExampleTopic --command-config client.properties
```
1. Führen Sie den folgenden Befehl aus, um einen Konsolenproduzenten zu starten. Die Datei namens `client.properties` ist die Datei, die Sie im vorherigen Verfahren erstellt haben.
```
/bin/kafka-console-producer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --producer.config client.properties
```
1. Führen Sie auf Ihrem Client-Computer in einem neuen Befehlsfenster den folgenden Befehl aus, um einen Konsolenverbraucher zu starten.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --consumer.config client.properties
```
1. Geben Sie Nachrichten in das Produzentenfenster ein und beobachten Sie, wie sie im Verbraucherfenster angezeigt werden.
# Authentifizierung der Anmeldedaten mit AWS Secrets Manager
Sie können den Zugriff auf Ihre Amazon MSK-Cluster mithilfe von Anmeldeinformationen steuern, die mit AWS Secrets Manager gespeichert und gesichert werden. Das Speichern von Benutzeranmeldeinformationen in Secrets Manager reduziert den Aufwand für die Cluster-Authentifizierung, wie z. B. die Prüfung, Aktualisierung und Rotation von Anmeldeinformationen. Mit Secrets Manager können Sie auch Benutzeranmeldeinformationen clusterübergreifend freigeben.
Nachdem Sie einem MSK-Cluster ein Geheimnis zugeordnet haben, synchronisiert MSK die Anmeldedaten regelmäßig.
**Topics**
+ [So funktioniert die Authentifizierung mit den Anmeldedaten](msk-password-howitworks.md)
+ [SASL/SCRAM Authentifizierung für einen Amazon MSK-Cluster einrichten](msk-password-tutorial.md)
+ [Working with users](msk-password-users.md)
+ [Einschränkungen bei der Verwendung von SCRAM-Geheimnissen](msk-password-limitations.md)
# So funktioniert die Authentifizierung mit den Anmeldedaten
Die Authentifizierung der Anmeldedaten für Amazon MSK verwendet die Authentifizierung SASL/SCRAM (Simple Authentication and Security Layer/Salted Challenge Response Mechanism). Um die Authentifizierung über Anmeldeinformationen für einen Cluster einzurichten, erstellen Sie eine Secret-Ressource in [AWS Secrets Manager](https://docs.aws.amazon.com//secretsmanager/?id=docs_gateway) und ordnen diesem Secret Anmeldeinformationen zu.
SASL/SCRAM ist in [RFC 5802](https://tools.ietf.org/html/rfc5802) definiert. SCRAM verwendet gesicherte Hashing-Algorithmen und überträgt keine Klartext-Anmeldeinformationen zwischen dem Client und dem Server.
**Anmerkung**
Wenn Sie die SASL/SCRAM Authentifizierung für Ihren Cluster einrichten, aktiviert Amazon MSK die TLS-Verschlüsselung für den gesamten Datenverkehr zwischen Clients und Brokern.
# SASL/SCRAM Authentifizierung für einen Amazon MSK-Cluster einrichten
Um ein Geheimnis in AWS Secrets Manager einzurichten, folgen Sie dem Tutorial [Creating and Retrieving a Secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) im [AWS Secrets Manager Manager-Benutzerhandbuch](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
Beachten Sie die folgenden Anforderungen, wenn Sie ein Secret für einen Amazon-MSK-Cluster erstellen:
+ Wählen Sie für Secret-Typ die Option **Anderer Secret-Typ (z. B. API-Schlüssel)**.
+ Ihr Secret-Nname muss mit dem Präfix **AmazonMSK\$1** beginnen.
+ Sie müssen entweder einen vorhandenen benutzerdefinierten AWS KMS Schlüssel verwenden oder einen neuen benutzerdefinierten AWS KMS Schlüssel für Ihr Geheimnis erstellen. Secrets Manager verwendet standardmäßig den AWS KMS Standardschlüssel für ein Geheimnis.
**Wichtig**
Ein mit dem AWS KMS Standardschlüssel erstelltes Geheimnis kann nicht mit einem Amazon MSK-Cluster verwendet werden.
+ Ihre Anmeldeinformationen müssen das folgende Format haben, um Schlüssel-Wert-Paare mit der **Klartext**-Option eingeben zu können.
```
{
"username": "alice",
"password": "alice-secret"
}
```
+ Notieren Sie sich den ARN (Amazon-Ressourcenname) für Ihr Secret.
+
**Wichtig**
Sie können einem Cluster, der die unter [Passen Sie die Größe Ihres Clusters an: Anzahl der Partitionen pro Standard-Broker](bestpractices.md#partitions-per-broker) beschriebenen Grenzwerte überschreitet, kein Secrets-Manager-Secret zuordnen.
+ Wenn Sie den AWS CLI zum Erstellen des Geheimnisses verwenden, geben Sie eine Schlüssel-ID oder einen ARN für den `kms-key-id` Parameter an. Geben Sie keinen Alias an.
+ Um das Geheimnis Ihrem Cluster zuzuordnen, verwenden Sie entweder die Amazon MSK-Konsole oder den [ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)Vorgang.
**Wichtig**
Wenn Sie einem Cluster ein Secret zuordnen, fügt Amazon MSK dem Secret eine Ressourcenrichtlinie hinzu, die es Ihrem Cluster ermöglicht, auf die von Ihnen definierten geheimen Werte zuzugreifen und diese zu lesen. Sie sollten diese Ressourcenrichtlinie nicht ändern. Andernfalls kann Ihr Cluster daran gehindert werden, auf Ihr Secret zuzugreifen. Wenn Sie Änderungen an der Secrets-Ressourcenrichtlinie und/oder dem für die geheime Verschlüsselung verwendeten KMS-Schlüssel vornehmen, stellen Sie sicher, dass Sie die Secrets erneut Ihrem MSK-Cluster zuordnen. Dadurch wird sichergestellt, dass Ihr Cluster weiterhin auf Ihr Geheimnis zugreifen kann.
Die folgende Beispiel-JSON-Eingabe für den Vorgang `BatchAssociateScramSecret` ordnet ein Secret einem Cluster zu:
```
{
"clusterArn" : "arn:aws:kafka:us-west-2:0123456789019:cluster/SalesCluster/abcd1234-abcd-cafe-abab-9876543210ab-4",
"secretArnList": [
"arn:aws:secretsmanager:us-west-2:0123456789019:secret:AmazonMSK_MyClusterSecret"
]
}
```
# Herstellen einer Verbindung zu Ihrem Cluster mit Anmeldeinformationen
Nachdem Sie ein Secret erstellt und es Ihrem Cluster zugeordnet haben, können Sie Ihren Client mit dem Cluster verbinden. Das folgende Verfahren zeigt, wie Sie einen Client mit einem Cluster verbinden, der SASL/SCRAM Authentifizierung verwendet. Außerdem wird anhand eines Beispielthemas gezeigt, wie das Produzieren und das Konsumieren anhand eines Beispielthemas erfolgt.
**Topics**
+ [Einen Client mithilfe der SASL/SCRAM Authentifizierung mit dem Cluster verbinden](#w2aab9c13c29c17c13c11b9b7)
+ [Fehlerbehebung bei Verbindungsproblemen](#msk-password-tutorial-connect-troubleshooting)
## Einen Client mithilfe der SASL/SCRAM Authentifizierung mit dem Cluster verbinden
1. Führen Sie den folgenden Befehl auf einem Computer aus, der AWS CLI installiert wurde. *clusterARN*Ersetzen Sie es durch den ARN Ihres Clusters.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Speichern Sie aus dem JSON-Ergebnis dieses Befehls den Wert, der der genannten Zeichenfolge zugeordnet ist`BootstrapBrokerStringSaslScram`. Sie werden diesen Wert in späteren Schritten verwenden.
1. Erstellen Sie auf Ihrem Client-Computer eine JAAS-Konfigurationsdatei, die die in Ihrem Secret gespeicherten Benutzeranmeldeinformationen enthält. Erstellen Sie beispielsweise für den Benutzer **alice** eine Datei namens `users_jaas.conf` mit dem folgenden Inhalt.
```
KafkaClient {
org.apache.kafka.common.security.scram.ScramLoginModule required
username="alice"
password="alice-secret";
};
```
1. Verwenden Sie den folgenden Befehl, um Ihre JAAS-Konfigurationsdatei als `KAFKA_OPTS`-Umgebungsparameter zu exportieren.
```
export KAFKA_OPTS=-Djava.security.auth.login.config=/users_jaas.conf
```
1. Erstellen Sie in einem `/tmp`-Verzeichnis eine Datei namens `kafka.client.truststore.jks`.
1. (Optional) Verwenden Sie den folgenden Befehl, um die JDK-Schlüsselspeicherdatei aus Ihrem `cacerts` JVM-Ordner in die `kafka.client.truststore.jks` Datei zu kopieren, die Sie im vorherigen Schritt erstellt haben. *JDKFolder*Ersetzen Sie ihn durch den Namen des JDK-Ordners auf Ihrer Instanz. Beispielsweise könnte Ihr JDK-Ordner `java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64` benannt sein.
```
cp /usr/lib/jvm/JDKFolder/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Erstellen Sie im `bin`-Verzeichnis Ihrer Apache-Kafka-Installation eine Client-Eigenschaftendatei namens `client_sasl.properties` mit dem folgenden Inhalt. Diese Datei definiert den SASL-Mechanismus und das SASL-Protokoll.
```
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
```
1. Führen Sie den folgenden Befehl aus, um ein Beispielthema zu erstellen. *BootstrapBrokerStringSaslScram*Ersetzen Sie es durch die Bootstrap-Broker-Zeichenfolge, die Sie in Schritt 1 dieses Themas abgerufen haben.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBrokerStringSaslScram --command-config /client_sasl.properties --replication-factor 3 --partitions 1 --topic ExampleTopicName
```
1. Führen Sie den folgenden Befehl auf Ihrem Client-Computer aus, um in dem von Ihnen erstellten Beispielthema zu produzieren. *BootstrapBrokerStringSaslScram*Ersetzen Sie sie durch die Bootstrap-Broker-Zeichenfolge, die Sie in Schritt 1 dieses Themas abgerufen haben.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringSaslScram --topic ExampleTopicName --producer.config client_sasl.properties
```
1. Führen Sie den folgenden Befehl auf Ihrem Client-Computer aus, um aus dem von Ihnen erstellten Thema zu verbrauchen. *BootstrapBrokerStringSaslScram*Ersetzen Sie sie durch die Bootstrap-Broker-Zeichenfolge, die Sie in Schritt 1 dieses Themas abgerufen haben.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --from-beginning --consumer.config client_sasl.properties
```
## Fehlerbehebung bei Verbindungsproblemen
Beim Ausführen von Kafka-Client-Befehlen können Java-Heap-Speicherfehler auftreten, insbesondere bei der Arbeit mit großen Themen oder Datensätzen. Diese Fehler treten auf, weil Kafka-Tools als Java-Anwendungen mit Standardspeichereinstellungen ausgeführt werden, die für Ihre Arbeitslast möglicherweise nicht ausreichen.
Um `Out of Memory Java Heap` Fehler zu beheben, können Sie die Größe des Java-Heaps erhöhen, indem Sie die `KAFKA_OPTS` Umgebungsvariable so ändern, dass sie Speichereinstellungen enthält.
Im folgenden Beispiel wird die maximale Heap-Größe auf 1 GB () festgelegt. `-Xmx1G` Sie können diesen Wert an Ihren verfügbaren Systemspeicher und Ihre Anforderungen anpassen.
```
export KAFKA_OPTS="-Djava.security.auth.login.config=/users_jaas.conf -Xmx1G"
```
Bei umfangreichen Themen sollten Sie die Verwendung von zeit- oder offsetbasierten Parametern in Betracht ziehen, anstatt die Speicherbelegung `--from-beginning` zu begrenzen:
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --max-messages 1000 --consumer.config client_sasl.properties
```
# Working with users
**Benutzer erstellen:** Sie erstellen Benutzer in Ihrem Secret als Schlüssel-Wert-Paare. Wenn Sie die **Klartext**-Option in der Secrets-Manager-Konsole verwenden, sollten Sie die Anmeldeinformationen im folgenden Format angeben.
```
{
"username": "alice",
"password": "alice-secret"
}
```
**Benutzerzugriff widerrufen:** Um die Anmeldeinformationen eines Benutzers für den Zugriff auf einen Cluster zu widerrufen, empfehlen wir, zuerst eine ACL für den Cluster zu entfernen oder zu erzwingen und dann die Zuordnung des Secrets aufzuheben. Dies ist auf Folgendes zurückzuführen:
+ Durch das Entfernen eines Benutzers werden bestehende Verbindungen nicht geschlossen.
+ Es dauert bis zu 10 Minuten, bis Änderungen an Ihrem Secret verbreitet sind.
Weitere Informationen zur Verwendung einer ACL mit Amazon MSK finden Sie unter [Apache Kafka ACLs](msk-acls.md).
Für Cluster, die ZooKeeper den Modus verwenden, empfehlen wir, den Zugriff auf Ihre ZooKeeper Knoten einzuschränken, um zu verhindern, dass Benutzer Änderungen vornehmen. ACLs Weitere Informationen finden Sie unter [Steuern Sie den Zugriff auf ZooKeeper Apache-Knoten in Ihrem Amazon MSK-Cluster](zookeeper-security.md).
# Einschränkungen bei der Verwendung von SCRAM-Geheimnissen
Beachten Sie die folgenden Einschränkungen bei der Verwendung von SCRAM-Secrets:
+ Amazon MSK unterstützt nur SCRAM-SHA-512-Authentifizierung.
+ Ein Amazon-MSK-Cluster kann bis zu 1 000 Benutzer haben.
+ Sie müssen eine AWS KMS key mit Ihrem Secret verwenden. Sie können kein Secret verwenden, das den standardmäßigen Secrets-Manager-Verschlüsselungsschlüssel mit Amazon MSK verwendet. Weitere Informationen zum Erstellen eines KMS-Schlüssels finden Sie unter [Erstellen von symmetrichen KMS-Verschlüsselungsschlüsseln](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk).
+ Sie können keinen asymmetrischen KMS-Schlüssel mit Secrets Manager verwenden.
+ Mithilfe dieser [ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)Operation können Sie einem Cluster bis zu 10 Geheimnisse gleichzeitig zuordnen.
+ Der Name von Secrets, die einem Amazon-MSK-Cluster zugeordnet sind, muss das Präfix **AmazonMSK\$1** haben.
+ Mit einem Amazon MSK-Cluster verknüpfte Geheimnisse müssen sich im selben Amazon Web Services Services-Konto und derselben AWS Region wie der Cluster befinden.
# Apache Kafka ACLs
Apache Kafka hat einen austauschbaren Authorizer und wird mit einer Authorizer-Implementierung geliefert. out-of-box Amazon MSK aktiviert diesen Autorisierer in der Datei `server.properties` auf den Brokern.
Apache Kafka ACLs haben das Format „Principal P ist [erlaubt/verweigert] Operation O von Host H auf einer beliebigen Ressource R, die RP entspricht“. ResourcePattern Wenn RP nicht mit einer bestimmten Ressource R übereinstimmt, hat R keine zugehörige Ressource ACLs, und daher darf niemand außer Superusern auf R zugreifen. Um dieses Verhalten von Apache Kafka zu ändern, setzen Sie die Eigenschaft `allow.everyone.if.no.acl.found` auf true. Amazon MSK setzt es standardmäßig auf true. Das bedeutet, dass bei Amazon MSK-Clustern alle Principals ACLs auf diese Ressource zugreifen können, wenn Sie nicht explizit eine Ressource festlegen. Wenn Sie eine Ressource ACLs aktivieren, können nur autorisierte Prinzipale darauf zugreifen. Wenn Sie den Zugriff auf ein Thema einschränken und einen Client mithilfe der gegenseitigen TLS-Authentifizierung autorisieren möchten, fügen Sie dies ACLs mithilfe der Apache Kafka-Autorisierungs-CLI hinzu. Weitere Informationen zum Hinzufügen, Entfernen und Auflisten ACLs finden Sie unter [Kafka Authorization](https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorization+Command+Line+Interface) Command Line Interface.
Da Amazon MSK Makler als Superuser konfiguriert, können sie auf alle Themen zugreifen. Dies hilft den Brokern, Nachrichten von der primären Partition zu replizieren, unabhängig davon, ob die `allow.everyone.if.no.acl.found` Eigenschaft für die Clusterkonfiguration definiert ist oder nicht.
**Hinzufügen oder Entfernen von Lese- und Schreibzugriff für ein Thema**
1. Fügen Sie Ihre Broker zur ACL-Tabelle hinzu, damit sie aus allen vorhandenen Themen lesen können. ACLs Um Ihren Brokern Lesezugriff auf ein Thema zu gewähren, führen Sie den folgenden Befehl auf einem Client-Computer aus, der mit dem MSK-Cluster kommunizieren kann.
*Distinguished-Name*Ersetzen Sie es durch den DNS eines der Bootstrap-Broker Ihres Clusters und ersetzen Sie dann die Zeichenfolge vor dem ersten Punkt in diesem eindeutigen Namen durch ein Sternchen ()`*`. Wenn beispielsweise einer der Bootstrap-Broker Ihres Clusters über den DNS verfügt`b-6.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`, ersetzen Sie ihn *Distinguished-Name* im folgenden Befehl durch. `*.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com` Informationen zum Abrufen der Bootstrap-Broker finden Sie unter [Holen Sie sich die Bootstrap-Broker für einen Amazon MSK-Cluster](msk-get-bootstrap-brokers.md).
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
1. Um einer Client-Anwendung Lesezugriff auf ein Thema zu gewähren, führen Sie den folgenden Befehl auf Ihrem Client-Computer aus. Wenn Sie die gegenseitige TLS-Authentifizierung verwenden, verwenden *Distinguished-Name* Sie dasselbe, das Sie bei der Erstellung des privaten Schlüssels verwendet haben.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
Zum Entfernen des Lesezugriffs können Sie denselben Befehl ausführen und `--add` durch `--remove` ersetzen.
1. Zum Gewähren von Schreibzugriff auf ein Thema führen Sie den folgenden Befehl auf Ihrem Client-Computer aus. Wenn Sie die gegenseitige TLS-Authentifizierung verwenden, verwenden *Distinguished-Name* Sie dieselbe, die Sie bei der Erstellung des privaten Schlüssels verwendet haben.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Write --topic Topic-Name
```
Zum Entfernen des Schreibzugriffs können Sie denselben Befehl ausführen und `--add` durch `--remove` ersetzen.
# Ändern der Sicherheitsgruppe eines Amazon-MSK-Clusters
Auf dieser Seite wird erklärt, wie Sie die Sicherheitsgruppe eines vorhandenen MSK-Clusters ändern. Möglicherweise müssen Sie die Sicherheitsgruppe eines Clusters ändern, um einer bestimmten Gruppe von Benutzern Zugriff zu gewähren oder den Zugriff auf den Cluster einzuschränken. Weitere Informationen zu Sicherheitsgruppen finden Sie unter [Sicherheitsgruppen für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) im Amazon-VPC-Benutzerhandbuch.
1. Verwenden Sie die [ListNodes](https://docs.amazonaws.cn/en_us/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes)API oder den Befehl [list-nodes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/list-nodes.html) in AWS CLI , um eine Liste der Broker in Ihrem Cluster abzurufen. Zu den Ergebnissen dieses Vorgangs gehören die IDs Elastic Network-Schnittstellen (ENIs), die den Brokern zugeordnet sind.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Wählen Sie im Dropdown-Menü in der oberen rechten Ecke des Bildschirms die Region aus, in der der Cluster bereitgestellt wird.
1. Wählen Sie im linken Bereich unter **Netzwerk und Sicherheit** die Option **Netzwerkschnittstellen**.
1. Wählen Sie die erste ENI aus, die Sie im ersten Schritt erhalten haben. Wählen Sie oben auf dem Bildschirm das Menü **Aktionen** und anschließend **Sicherheitsgruppen ändern**. Weisen Sie dieser ENI die neue Sicherheitsgruppe zu. Wiederholen Sie diesen Schritt für jedes Element ENIs , das Sie im ersten Schritt erhalten haben.
**Anmerkung**
Änderungen, die Sie mit der Amazon-EC2-Konsole an der Sicherheitsgruppe eines Clusters vornehmen, werden nicht in der MSK-Konsole unter **Netzwerkeinstellungen** wiedergegeben.
1. Konfigurieren Sie die Regeln der neuen Sicherheitsgruppe, um sicherzustellen, dass Ihre Clients Zugriff auf die Broker haben. Weitere Informationen zum Einrichten von Regeln für Sicherheitsgruppen finden Sie unter [Hinzufügen, Entfernen und Aktualisieren von Regeln](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) im Amazon-VPC-Benutzerhandbuch.
**Wichtig**
Wenn Sie die Sicherheitsgruppe ändern, die den Brokern eines Clusters zugeordnet ist, und diesem Cluster dann neue Broker hinzufügen, ordnet Amazon MSK die neuen Broker der ursprünglichen Sicherheitsgruppe zu, die dem Cluster zugeordnet war, als der Cluster erstellt wurde. Damit ein Cluster jedoch ordnungsgemäß funktioniert, müssen alle seine Broker derselben Sicherheitsgruppe zugeordnet sein. Wenn Sie also nach dem Ändern der Sicherheitsgruppe neue Broker hinzufügen, müssen Sie das vorherige Verfahren erneut ausführen und ENIs die neuen Broker aktualisieren.
# Steuern Sie den Zugriff auf ZooKeeper Apache-Knoten in Ihrem Amazon MSK-Cluster
Aus Sicherheitsgründen können Sie den Zugriff auf die ZooKeeper Apache-Knoten einschränken, die Teil Ihres Amazon MSK-Clusters sind. Zum Beschränken des Zugriffs auf die Knoten können Sie ihnen eine separate Sicherheitsgruppe zuweisen. Anschließend können Sie entscheiden, wer Zugriff auf diese Sicherheitsgruppe erhält.
**Wichtig**
Dieser Abschnitt gilt nicht für Cluster, die im KRaft Modus ausgeführt werden. Siehe [KRaft Modus](metadata-management.md#kraft-intro).
**Topics**
+ [Um Ihre ZooKeeper Apache-Knoten einer separaten Sicherheitsgruppe zuzuordnen](zookeeper-security-group.md)
+ [Verwendung der TLS-Sicherheit mit Apache ZooKeeper](zookeeper-security-tls.md)
# Um Ihre ZooKeeper Apache-Knoten einer separaten Sicherheitsgruppe zuzuordnen
Um den Zugriff auf ZooKeeper Apache-Knoten zu beschränken, können Sie ihnen eine separate Sicherheitsgruppe zuweisen. Sie können auswählen, wer Zugriff auf diese neue Sicherheitsgruppe hat, indem Sie Sicherheitsgruppenregeln festlegen.
1. Rufen Sie die ZooKeeper Apache-Verbindungszeichenfolge für Ihren Cluster ab. Um zu erfahren wie dies geht, vgl. [ZooKeeper Modus](metadata-management.md#msk-get-connection-string). Die Verbindungszeichenfolge enthält die DNS-Namen Ihrer ZooKeeper Apache-Knoten.
1. Verwenden Sie ein Tool wie `host` oder `ping`, um die DNS-Namen, die Sie im vorherigen Schritt erhalten haben, in IP-Adressen zu konvertieren. Speichern Sie diese IP-Adressen, da Sie sie später in diesem Verfahren benötigen.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Klicken Sie im linken Bereich unter **NETWORK & SECURITY (NETZWERK UND SICHERHEIT)** auf **Network Interfaces (Netzwerkschnittstellen)**.
1. Geben Sie im Suchfeld über der Tabelle der Netzwerkschnittstellen den Namen des Clusters ein, und geben Sie dann „return“ ein. Dadurch wird die Anzahl der Netzwerkschnittstellen, die in der Tabelle angezeigt werden, auf die Schnittstellen beschränkt, die dem Cluster zugeordnet sind.
1. Aktivieren Sie das Kontrollkästchen am Anfang der Zeile, die der ersten Netzwerkschnittstelle in der Liste entspricht.
1. Suchen Sie im Detailbereich unten auf der Seite nach der **primären privaten IPv4 IP**. Wenn diese IP-Adresse mit einer der IP-Adressen übereinstimmt, die Sie im ersten Schritt dieses Verfahrens erhalten haben, bedeutet dies, dass diese Netzwerkschnittstelle einem ZooKeeper Apache-Knoten zugewiesen ist, der Teil Ihres Clusters ist. Andernfalls deaktivieren Sie das Kontrollkästchen neben dieser Netzwerkschnittstelle, und wählen Sie die nächste Netzwerkschnittstelle in der Liste aus. Die Reihenfolge, in der Sie die Netzwerkschnittstellen auswählen, spielt keine Rolle. In den nächsten Schritten führen Sie nacheinander dieselben Operationen an allen Netzwerkschnittstellen durch, die ZooKeeper Apache-Knoten zugewiesen sind.
1. Wenn Sie eine Netzwerkschnittstelle auswählen, die einem ZooKeeper Apache-Knoten entspricht, wählen Sie oben auf der Seite das Menü **Aktionen** und dann **Sicherheitsgruppen ändern**. Weisen Sie dieser Netzwerkschnittstelle eine neue Sicherheitsgruppe zu. Weitere Informationen zum Erstellen von Sicherheitsgruppen finden Sie unter [Erstellen einer Sicherheitsgruppe](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#CreatingSecurityGroups) in der Amazon-VPC-Dokumentation.
1. Wiederholen Sie den vorherigen Schritt, um allen Netzwerkschnittstellen, die den ZooKeeper Apache-Knoten Ihres Clusters zugeordnet sind, dieselbe neue Sicherheitsgruppe zuzuweisen.
1. Nun können Sie auswählen, wer Zugriff auf diese neue Sicherheitsgruppe hat. Weitere Informationen zum Einrichten von Regeln für Sicherheitsgruppen finden Sie unter [Hinzufügen, Entfernen und Aktualisieren von Regeln](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) in der Amazon-VPC-Dokumentation.
# Verwendung der TLS-Sicherheit mit Apache ZooKeeper
Sie können die TLS-Sicherheit für die Verschlüsselung bei der Übertragung zwischen Ihren Clients und Ihren ZooKeeper Apache-Knoten verwenden. Gehen Sie wie folgt vor, um die TLS-Sicherheit mit Ihren ZooKeeper Apache-Knoten zu implementieren:
+ Cluster müssen Apache Kafka Version 2.5.1 oder höher verwenden, um TLS-Sicherheit mit Apache verwenden zu können. ZooKeeper
+ Aktivieren Sie die TLS-Sicherheit, wenn Sie Ihren Cluster erstellen oder konfigurieren. Cluster, die mit Apache Kafka Version 2.5.1 oder höher und aktiviertem TLS erstellt wurden, verwenden automatisch TLS-Sicherheit mit Apache-Endpunkten. ZooKeeper Weitere Informationen zur Einrichtung von TLS-Sicherheit finden Sie unter [Erste Schritte mit der Amazon MSK-Verschlüsselung](msk-working-with-encryption.md).
+ Rufen Sie die TLS-Apache ZooKeeper Endpoints mithilfe des Vorgangs ab. [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
+ Erstellen Sie eine ZooKeeper Apache-Konfigurationsdatei zur Verwendung mit den [https://kafka.apache.org/documentation/#security_authz_cli](https://kafka.apache.org/documentation/#security_authz_cli)Tools `kafka-configs.sh` und oder mit der ZooKeeper Shell. Bei jedem Tool verwenden Sie den `--zk-tls-config-file` Parameter, um Ihre ZooKeeper Apache-Konfiguration anzugeben.
Das folgende Beispiel zeigt eine typische ZooKeeper Apache-Konfigurationsdatei:
```
zookeeper.ssl.client.enable=true
zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
zookeeper.ssl.keystore.location=kafka.jks
zookeeper.ssl.keystore.password=test1234
zookeeper.ssl.truststore.location=truststore.jks
zookeeper.ssl.truststore.password=test1234
```
+ Für andere Befehle (z. B.`kafka-topics`) müssen Sie die `KAFKA_OPTS` Umgebungsvariable verwenden, um ZooKeeper Apache-Parameter zu konfigurieren. Das folgende Beispiel zeigt, wie die `KAFKA_OPTS` Umgebungsvariable so konfiguriert wird, dass ZooKeeper Apache-Parameter an andere Befehle übergeben werden:
```
export KAFKA_OPTS="
-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
-Dzookeeper.client.secure=true
-Dzookeeper.ssl.trustStore.location=/home/ec2-user/kafka.client.truststore.jks
-Dzookeeper.ssl.trustStore.password=changeit"
```
Nachdem Sie die `KAFKA_OPTS`-Umgebungsvariable konfiguriert haben, können Sie CLI-Befehle normal verwenden. Im folgenden Beispiel wird mithilfe der ZooKeeper Apache-Konfiguration aus der `KAFKA_OPTS` Umgebungsvariablen ein Apache Kafka-Thema erstellt:
```
/bin/kafka-topics.sh --create --zookeeper ZooKeeperTLSConnectString --replication-factor 3 --partitions 1 --topic AWSKafkaTutorialTopic
```
**Anmerkung**
Die Namen der Parameter, die Sie in Ihrer ZooKeeper Apache-Konfigurationsdatei verwenden, und der Parameter, die Sie in Ihrer `KAFKA_OPTS` Umgebungsvariablen verwenden, sind nicht konsistent. Achten Sie darauf, welche Namen Sie mit welchen Parametern in Ihrer Konfigurationsdatei und `KAFKA_OPTS`-Umgebungsvariablen verwenden.
Weitere Informationen zum Zugriff auf Ihre ZooKeeper Apache-Knoten mit TLS finden Sie unter [KIP-515: Aktivieren Sie den ZK-Client, um die neue TLS-unterstützte Authentifizierung zu verwenden](https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+ZK+client+to+use+the+new+TLS+supported+authentication).
# Compliance-Validierung für Amazon Managed Streaming für Apache Kafka
Externe Prüfer bewerten im Rahmen verschiedener AWS -Compliance-Programme die Sicherheit und Compliance von Amazon Managed Streaming für Apache Kafka. Dazu gehören PCI und HIPAA BAA.
Eine Liste der AWS Services im Rahmen bestimmter Compliance-Programme finden Sie unter [Amazon Services in Umfang nach Compliance-Programm](https://aws.amazon.com/compliance/services-in-scope/) . Allgemeine Informationen finden Sie unter [AWS Compliance-Programme AWS](https://aws.amazon.com/compliance/programs/) .
Sie können Prüfberichte von Drittanbietern unter herunterladen AWS Artifact. Weitere Informationen finden Sie unter [Berichte herunterladen unter ](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Ihre Compliance-Verantwortung bei der Nutzung von Amazon MSK hängt von der Sensibilität Ihrer Daten, den Compliance-Zielen Ihres Unternehmens und den geltenden Gesetzen und Vorschriften ab. AWS bietet die folgenden Ressourcen zur Unterstützung bei der Einhaltung von Vorschriften:
+ [Schnellstartanleitungen für Sicherheit und Compliance](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – In diesen Bereitstellungsleitfäden werden architektonische Überlegungen erörtert und Schritte für die Bereitstellung von sicherheits- und konformitätsorientierten Basisumgebungen auf AWS angegeben.
+ Whitepaper „[Architecting for HIPAA Security and Compliance“ — In diesem Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) wird beschrieben, wie Unternehmen HIPAA-konforme Anwendungen erstellen können AWS .
+ [AWS Compliance-Ressourcen ](https://aws.amazon.com/compliance/resources/) — Diese Sammlung von Arbeitsmappen und Leitfäden kann auf Ihre Branche und Ihren Standort zutreffen.
+ [Bewertung von Ressourcen anhand von Regeln](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) im *AWS Config Entwicklerhandbuch* — Der AWS Config Service bewertet, wie gut Ihre Ressourcenkonfigurationen den internen Praktiken, Branchenrichtlinien und Vorschriften entsprechen.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Dieser AWS Service bietet einen umfassenden Überblick über Ihren Sicherheitsstatus, sodass Sie überprüfen können AWS , ob Sie die Sicherheitsstandards und Best Practices der Branche einhalten.
# Ausfallsicherheit in Amazon Managed Streaming für Apache Kafka
Die AWS globale Infrastruktur basiert auf AWS Regionen und Availability Zones. AWS Regionen bieten mehrere physisch getrennte und isolierte Availability Zones, die über Netzwerke mit niedriger Latenz, hohem Durchsatz und hoher Redundanz miteinander verbunden sind. Mithilfe von Availability Zones können Sie Anwendungen und Datenbanken erstellen und ausführen, die automatisch Failover zwischen Zonen ausführen, ohne dass es zu Unterbrechungen kommt. Availability Zones sind besser verfügbar, fehlertoleranter und skalierbarer als herkömmliche Infrastrukturen mit einem oder mehreren Rechenzentren.
Weitere Informationen zu AWS Regionen und Availability Zones finden Sie unter [AWS Globale](https://aws.amazon.com/about-aws/global-infrastructure/) Infrastruktur.
# Infrastruktursicherheit in Amazon Managed Streaming für Apache Kafka
Als verwalteter Service ist Amazon Managed Streaming for Apache Kafka durch die AWS globalen Netzwerksicherheitsverfahren geschützt, die im Whitepaper [Amazon Web Services: Sicherheitsprozesse im Überblick](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) beschrieben werden.
Sie verwenden AWS veröffentlichte API-Aufrufe, um über das Netzwerk auf Amazon MSK zuzugreifen. Kunden müssen Transport Layer Security (TLS) 1.0 oder neuer unterstützen. Wir empfehlen TLS 1.2 oder höher. Clients müssen außerdem Verschlüsselungssammlungen mit PFS (Perfect Forward Secrecy) wie DHE (Ephemeral Diffie-Hellman) oder ECDHE (Elliptic Curve Ephemeral Diffie-Hellman) unterstützen. Die meisten modernen Systemen wie Java 7 und höher unterstützen diese Modi.
Außerdem müssen Anforderungen mit einer Zugriffsschlüssel-ID und einem geheimen Zugriffsschlüssel signiert sein, der einem IAM-Prinzipal zugeordnet ist. Alternativ können Sie mit [AWS -Security-Token-Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) temporäre Sicherheitsanmeldeinformationen erstellen, um die Anforderungen zu signieren.
# Amazon MSK-Protokollierung
Sie können Apache Kafka-Broker-Protokolle an einen oder mehrere der folgenden Zieltypen senden: Amazon CloudWatch Logs, Amazon S3, Amazon Data Firehose. Sie können Amazon MSK API-Aufrufe auch mit AWS CloudTrail protokollieren.
**Anmerkung**
Broker-Protokolle sind sowohl für MSK Standard- als auch für Express-Broker verfügbar.
## Broker-Protokolle
Broker-Protokolle ermöglichen es Ihnen, Probleme mit Ihren Apache-Kafka-Anwendungen zu beheben und die Kommunikation der Anwendungen mit Ihrem MSK-Cluster zu analysieren. Sie können Ihren neuen oder vorhandenen MSK-Cluster so konfigurieren, dass Brokerprotokolle auf INFO-Ebene an eine oder mehrere der folgenden Arten von Zielressourcen gesendet werden: eine CloudWatch Protokollgruppe, ein S3-Bucket, ein Firehose-Lieferstream. Über Firehose können Sie dann die Protokolldaten aus Ihrem Lieferstream an den OpenSearch Service übermitteln.
Sie müssen eine Zielressource erstellen, bevor Sie Ihren Cluster so konfigurieren, dass er Broker-Protokolle dahin übermittelt. Amazon MSK erstellt diese Zielressourcen nicht für Sie, wenn sie nicht bereits vorhanden sind. Informationen zu diesen drei Arten von Zielressourcen und deren Erstellung finden Sie in der folgenden Dokumentation:
+ [ CloudWatch Amazon-Protokolle](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)
+ [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
### Erforderliche Berechtigungen
Um ein Ziel für Amazon-MSK-Broker-Protokolle zu konfigurieren, muss die IAM-Identität, die Sie für Amazon-MSK-Aktionen verwenden, über die in der Richtlinie [AWS verwaltete Richtlinie: Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) beschriebenen Berechtigungen verfügen.
Um Broker-Protokolle an einen S3-Bucket zu streamen, benötigen Sie auch die Berechtigung `s3:PutBucketPolicy`. Informationen zu S3-Bucket-Richtlinien finden Sie unter [Wie füge ich eine S3-Bucket-Richtlinie hinzu?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html) im Amazon-S3-Benutzerhandbuch. Informationen zu IAM-Richtlinien im Allgemeinen finden Sie unter [Zugriffsverwaltung](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) im IAM-Benutzerhandbuch.
### Erforderliche KMS-Schlüsselrichtlinie zur Verwendung mit SSE-KMS-Buckets
Wenn Sie die serverseitige Verschlüsselung für Ihren S3-Bucket mithilfe von AWS KMS verwalteten Schlüsseln (SSE-KMS) mit einem vom Kunden verwalteten Schlüssel aktiviert haben, fügen Sie der Schlüsselrichtlinie für Ihren KMS-Schlüssel Folgendes hinzu, damit Amazon MSK Brokerdateien in den Bucket schreiben kann.
```
{
"Sid": "Allow Amazon MSK to use the key.",
"Effect": "Allow",
"Principal": {
"Service": [
"delivery.logs.amazonaws.com"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}
```
### Konfigurieren Sie Broker-Logs mit dem AWS-Managementkonsole
Wenn Sie einen neuen Cluster erstellen, suchen Sie im Abschnitt **Überwachung** nach der Überschrift **Bereitstellung von Broker-Protokollen**. Sie können die Ziele angeben, an die Amazon MSK die Broker-Protokolle bereitstellen soll.
Wählen Sie für einen vorhandenen Cluster den Cluster aus der Cluster-Liste aus und wählen Sie dann die Registerkarte **Eigenschaften**. Scrollen Sie nach unten zum Abschnitt **Protokoll-Bereitstellung** und wählen Sie dann die Schaltfläche **Bearbeiten**. Sie können die Ziele angeben, an die Amazon MSK die Broker-Protokolle bereitstellen soll.
### Konfigurieren Sie Broker-Logs mit dem AWS CLI
Wenn Sie die Befehle `create-cluster` oder `update-monitoring` verwenden, können Sie optional den Parameter `logging-info` angeben und eine JSON-Struktur wie im folgenden Beispiel an ihn übergeben. In diesem JSON sind alle drei Zieltypen optional.
**Anmerkung**
Sie müssen das `LogDeliveryEnabled` Tag in Firehose-Streams `true` auf setzen, um die Protokollzustellung einzurichten. Die serviceverknüpfte Rolle, die CloudWatch Protokolle AWS erstellt, verwendet dieses Tag, um Berechtigungen für alle Firehose-Lieferstreams zu erteilen. Wenn Sie dieses Tag entfernen, kann die mit dem Dienst verknüpfte Rolle keine Protokolle an den Firehose-Stream senden. Ein Beispiel für eine IAM-Richtlinie, in der die Berechtigungen aufgeführt sind, die die serviceverknüpfte Rolle umfasst, finden Sie im * CloudWatch Amazon-Benutzerhandbuch* unter [IAM-Rollen, die für Ressourcenberechtigungen verwendet werden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html).
```
{
"BrokerLogs": {
"S3": {
"Bucket": "amzn-s3-demo-bucket",
"Prefix": "ExamplePrefix",
"Enabled": true
},
"Firehose": {
"DeliveryStream": "ExampleDeliveryStreamName",
"Enabled": true
},
"CloudWatchLogs": {
"Enabled": true,
"LogGroup": "ExampleLogGroupName"
}
}
}
```
### Konfigurieren Sie Broker-Logs mithilfe der API
Sie können die optionale `loggingInfo` Struktur in der JSON-Datei angeben, die Sie an die [CreateCluster[UpdateMonitoring](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-monitoring.html#UpdateMonitoring)](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)OR-Operationen übergeben.
**Anmerkung**
Wenn die Broker-Protokollierung aktiviert ist, protokolliert Amazon MSK standardmäßig Protokolle auf `INFO`-Ebene an die angegebenen Ziele. Bei Standard-Brokern können Benutzer von Apache Kafka 2.4.X und höher die Broker-Protokollebene jedoch dynamisch auf eine der [log4j-Protokollebenen](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html) festlegen. Informationen zur dynamischen Festlegung der Broker-Protokollierungsebene finden Sie unter [KIP-412: Erweitern der Admin-API zur Unterstützung dynamischer Anwendungs-Protokollierungsebenen](https://cwiki.apache.org/confluence/display/KAFKA/KIP-412%3A+Extend+Admin+API+to+support+dynamic+application+log+levels). Wenn Sie die Protokollebene dynamisch auf `DEBUG` oder setzen`TRACE`, empfehlen wir, Amazon S3 oder Firehose als Protokollziel zu verwenden. Wenn Sie CloudWatch Logs als Protokollziel verwenden und die `TRACE` Protokollierung dynamisch aktivieren `DEBUG` oder abgleichen, kann Amazon MSK kontinuierlich eine Stichprobe von Protokollen bereitstellen. Dies kann die Leistung des Brokers erheblich beeinträchtigen und sollte nur verwendet werden, wenn die `INFO`-Protokollierungsebene nicht ausführlich genug ist, um die Grundursache eines Problems zu ermitteln.
# API-Aufrufe protokollieren mit AWS CloudTrail
**Anmerkung**
AWS CloudTrail Protokolle sind für Amazon MSK nur verfügbar, wenn Sie sie verwenden[IAM-Zugriffssteuerung](iam-access-control.md).
Amazon MSK ist in einen Service integriert AWS CloudTrail, der eine Aufzeichnung der Aktionen bereitstellt, die von einem Benutzer, einer Rolle oder einem AWS Service in Amazon MSK ausgeführt wurden. CloudTrail erfasst API-Aufrufe als Ereignisse. Zu den erfassten Aufrufen gehören Aufrufe von der Amazon-MSK-Konsole und Code-Aufrufe an die Amazon-MSK-API-Vorgänge. Es werden auch Apache-Kafka-Aktionen wie das Erstellen und Ändern von Themen und Gruppen erfasst.
Wenn Sie einen Trail erstellen, können Sie die kontinuierliche Übermittlung von CloudTrail Ereignissen an einen Amazon S3 S3-Bucket aktivieren, einschließlich Ereignissen für Amazon MSK. Wenn Sie keinen Trail konfigurieren, können Sie die neuesten Ereignisse trotzdem in der CloudTrail Konsole im **Ereignisverlauf** anzeigen. Anhand der von gesammelten Informationen können Sie die Anfrage CloudTrail, die an Amazon MSK oder die Apache Kafka-Aktion gestellt wurde, die IP-Adresse, von der aus die Anfrage gestellt wurde, wer die Anfrage gestellt hat, wann sie gestellt wurde, und weitere Details ermitteln.
Weitere Informationen darüber CloudTrail, einschließlich der Konfiguration und Aktivierung, finden Sie im [AWS CloudTrail Benutzerhandbuch](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## Amazon MSK-Informationen in CloudTrail
CloudTrail ist in Ihrem Amazon Web Services Services-Konto aktiviert, wenn Sie das Konto erstellen. Wenn unterstützte Ereignisaktivitäten in einem MSK-Cluster auftreten, wird diese Aktivität zusammen mit anderen AWS Serviceereignissen im CloudTrail **Ereignisverlauf in einem Ereignis** aufgezeichnet. Sie können die neusten Ereignisse in Ihrem Amazon Web Services-Konto anzeigen, suchen und herunterladen. Weitere Informationen finden Sie unter [Anzeigen von Ereignissen mit dem CloudTrail -API-Ereignisverlauf](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Zur kontinuierlichen Aufzeichnung von Ereignissen in Ihrem Amazon-Web-Services-Konto, einschließlich Ereignissen für Amazon MSK, erstellen Sie einen Trail. Ein *Trail* ermöglicht CloudTrail die Übermittlung von Protokolldateien an einen Amazon S3 S3-Bucket. Wenn Sie einen Trail in der Konsole anlegen, gilt dieser für alle -Regionen. Der Trail protokolliert Ereignisse aus allen Regionen in der AWS -Partition und stellt die Protokolldateien in dem von Ihnen angegebenen Amazon-S3-Bucket bereit. Darüber hinaus können Sie andere Amazon-Dienste so konfigurieren, dass sie die in den CloudTrail Protokollen gesammelten Ereignisdaten weiter analysieren und darauf reagieren. Weitere Informationen finden Sie hier:
+ [Übersicht zum Erstellen eines Trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Unterstützte Dienste und Integrationen](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Konfiguration von Amazon SNS SNS-Benachrichtigungen für CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Empfangen von CloudTrail Protokolldateien aus mehreren Regionen](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) und [Empfangen von CloudTrail Protokolldateien von mehreren Konten](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Amazon MSK protokolliert alle [Amazon MSK-Operationen](https://docs.aws.amazon.com/MSK/2.0/APIReference/operations.html) als Ereignisse in CloudTrail Protokolldateien. Darüber hinaus protokolliert es die folgenden Apache-Kafka-Aktionen.
+ Kafka-Cluster: DescribeClusterDynamicConfiguration
+ Kafka-Cluster: AlterClusterDynamicConfiguration
+ Kafka-Cluster: CreateTopic
+ Kafka-Cluster: DescribeTopicDynamicConfiguration
+ Kafka-Cluster: AlterTopic
+ Kafka-Cluster: AlterTopicDynamicConfiguration
+ Kafka-Cluster: DeleteTopic
Jeder Ereignis- oder Protokolleintrag enthält Informationen zu dem Benutzer, der die Anforderung generiert hat. Die Identitätsinformationen unterstützen Sie bei der Ermittlung der folgenden Punkte:
+ Ob die Anfrage mit Root-Benutzer- oder AWS Identity and Access Management (IAM-) Benutzeranmeldedaten gestellt wurde.
+ Gibt an, ob die Anforderung mit temporären Sicherheitsanmeldeinformationen für eine Rolle oder einen Verbundbenutzer gesendet wurde.
+ Ob die Anfrage von einem anderen AWS Dienst gestellt wurde.
Weitere Informationen finden Sie unter [CloudTrail userIdentity-Element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Beispiel: Einträge in der Amazon-MSK-Protokolldatei
Ein Trail ist eine Konfiguration, die die Übertragung von Ereignissen als Protokolldateien an einen von Ihnen angegebenen Amazon S3 S3-Bucket ermöglicht. CloudTrail Protokolldateien enthalten einen oder mehrere Protokolleinträge. Ein Ereignis stellt eine einzelne Anforderung aus einer beliebigen Quelle dar und enthält Informationen über die angeforderte Aktion, Datum und Uhrzeit der Aktion, Anforderungsparameter usw. CloudTrail Protokolldateien sind kein geordneter Stack-Trace der öffentlichen API-Aufrufe und Apache Kafka-Aktionen, sodass sie nicht in einer bestimmten Reihenfolge angezeigt werden.
Das folgende Beispiel zeigt CloudTrail Protokolleinträge, die die Aktionen `DescribeCluster` und `DeleteCluster` Amazon MSK demonstrieren.
```
{
"Records": [
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:24Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DescribeCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": null,
"requestID": "bd83f636-fdb5-abcd-0123-157e2fbf2bde",
"eventID": "60052aba-0123-4511-bcde-3e18dbd42aa4",
"readOnly": true,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
},
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:40Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DeleteCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": {
"clusterArn": "arn:aws:kafka:us-east-1:012345678901:cluster/examplecluster/01234567-abcd-0123-abcd-abcd0123efa-2",
"state": "DELETING"
},
"requestID": "c6bfb3f7-abcd-0123-afa5-293519897703",
"eventID": "8a7f1fcf-0123-abcd-9bdb-1ebf0663a75c",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
}
]
}
```
Das folgende Beispiel zeigt einen CloudTrail Protokolleintrag, der die `kafka-cluster:CreateTopic` Aktion demonstriert.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEFGH1IJKLMN2P34Q5",
"arn": "arn:aws:iam::111122223333:user/Admin",
"accountId": "111122223333",
"accessKeyId": "CDEFAB1C2UUUUU3AB4TT",
"userName": "Admin"
},
"eventTime": "2021-03-01T12:51:19Z",
"eventSource": "kafka-cluster.amazonaws.com",
"eventName": "CreateTopic",
"awsRegion": "us-east-1",
"sourceIPAddress": "198.51.100.0/24",
"userAgent": "aws-msk-iam-auth/unknown-version/aws-internal/3 aws-sdk-java/1.11.970 Linux/4.14.214-160.339.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/25.272-b10 java/1.8.0_272 scala/2.12.8 vendor/Red_Hat,_Inc.",
"requestParameters": {
"kafkaAPI": "CreateTopics",
"resourceARN": "arn:aws:kafka:us-east-1:111122223333:topic/IamAuthCluster/3ebafd8e-dae9-440d-85db-4ef52679674d-1/Topic9"
},
"responseElements": null,
"requestID": "e7c5e49f-6aac-4c9a-a1d1-c2c46599f5e4",
"eventID": "be1f93fd-4f14-4634-ab02-b5a79cb833d2",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "111122223333"
}
```
# Verwaltung von Metadaten
Amazon MSK unterstützt Apache ZooKeeper - oder KRaft Metadatenverwaltungsmodi.
Ab Apache Kafka Version 3.7.x auf Amazon MSK können Sie Cluster erstellen, die Modus statt KRaft Modus verwenden. ZooKeeper KRaftbasierte Cluster verlassen sich auf Controller innerhalb von Kafka, um Metadaten zu verwalten.
**Topics**
+ [ZooKeeper Modus](#msk-get-connection-string)
+ [KRaft Modus](#kraft-intro)
## ZooKeeper Modus
[Apache ZooKeeper](https://zookeeper.apache.org/) ist „ein zentraler Dienst zur Verwaltung von Konfigurationsinformationen, Benennung, Bereitstellung verteilter Synchronisation und Bereitstellung von Gruppendiensten. All diese Arten von Diensten werden in der einen oder anderen Form von verteilten Anwendungen verwendet“, einschließlich Apache Kafka.
Wenn Ihr Cluster den ZooKeeper Modus verwendet, können Sie die folgenden Schritte ausführen, um die ZooKeeper Apache-Verbindungszeichenfolge abzurufen. Wir empfehlen jedoch, dass Sie den verwenden, `BootstrapServerString` um eine Verbindung zu Ihrem Cluster herzustellen und Administratorvorgänge durchzuführen, da das `--zookeeper` Flag in Kafka 2.5 veraltet ist und aus Kafka 3.0 entfernt wurde.
### Abrufen der Apache-Verbindungszeichenfolge mithilfe der ZooKeeper AWS-Managementkonsole
1. Öffnen Sie die Amazon-MSK-Konsole unter [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Die Tabelle führt alle Cluster für die aktuelle Region unter diesem Konto auf. Wählen Sie den Namen eines Clusters aus, um dessen Beschreibung anzuzeigen.
1. Wählen Sie auf der Seite mit der **Cluster-Zusammenfassung** die Option **Client-Informationen anzeigen**. Dies zeigt Ihnen die Bootstrap-Broker sowie die ZooKeeper Apache-Verbindungszeichenfolge.
### Abrufen der ZooKeeper Apache-Verbindungszeichenfolge mithilfe der AWS CLI
1. Wenn Sie den Amazon Resourcennamen (ARN) Ihres Clusters nicht kennen, finden Sie ihn, indem Sie alle Cluster in Ihrem Konto auflisten. Weitere Informationen finden Sie unter [Amazon MSK-Cluster auflisten](msk-list-clusters.md).
1. Um die ZooKeeper Apache-Verbindungszeichenfolge zusammen mit anderen Informationen zu Ihrem Cluster abzurufen, führen Sie den folgenden Befehl aus und *ClusterArn* ersetzen Sie ihn durch den ARN Ihres Clusters.
```
aws kafka describe-cluster --cluster-arn ClusterArn
```
Die Ausgabe dieses `describe-cluster`-Befehls sieht wie das folgende JSON-Beispiel aus.
```
{
"ClusterInfo": {
"BrokerNodeGroupInfo": {
"BrokerAZDistribution": "DEFAULT",
"ClientSubnets": [
"subnet-0123456789abcdef0",
"subnet-2468013579abcdef1",
"subnet-1357902468abcdef2"
],
"InstanceType": "kafka.m5.large",
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 1000
}
}
},
"ClusterArn": "arn:aws:kafka:us-east-1:111122223333:cluster/testcluster/12345678-abcd-4567-2345-abcdef123456-2",
"ClusterName": "testcluster",
"CreationTime": "2018-12-02T17:38:36.75Z",
"CurrentBrokerSoftwareInfo": {
"KafkaVersion": "2.2.1"
},
"CurrentVersion": "K13V1IB3VIYZZH",
"EncryptionInfo": {
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:555555555555:key/12345678-abcd-2345-ef01-abcdef123456"
}
},
"EnhancedMonitoring": "DEFAULT",
"NumberOfBrokerNodes": 3,
"State": "ACTIVE",
"ZookeeperConnectString": "10.0.1.101:2018,10.0.2.101:2018,10.0.3.101:2018"
}
}
```
Das vorherige JSON-Beispiel zeigt den `ZookeeperConnectString`-Schlüssel in der Ausgabe des `describe-cluster`-Befehls an. Kopieren Sie den Wert, der diesem Schlüssel entspricht, und speichern Sie ihn, für den Fall, dass Sie ein Thema in Ihrem Cluster erstellen müssen.
**Wichtig**
Ihr Amazon MSK-Cluster muss sich in dem `ACTIVE` Status befinden, in dem Sie die ZooKeeper Apache-Verbindungszeichenfolge abrufen können. Wenn ein Cluster noch den Status „`CREATING`“ aufweist, enthält die Ausgabe des `describe-cluster`-Befehls „`ZookeeperConnectString`“ nicht. Warten Sie in diesem Fall einige Minuten und führen Sie den `describe-cluster` erneut aus, nachdem der Cluster den Status „`ACTIVE`“ erreicht hat.
### Die ZooKeeper Apache-Verbindungszeichenfolge mithilfe der API abrufen
Informationen zum Abrufen der ZooKeeper Apache-Verbindungszeichenfolge mithilfe der API finden Sie unter [DescribeCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster).
## KRaft Modus
Amazon MSK hat die Unterstützung für KRaft (Apache Kafka Raft) in Kafka Version 3.7.x eingeführt. Die Apache Kafka-Community wurde entwickelt, KRaft um Apache ZooKeeper für die Metadatenverwaltung in [Apache](#msk-get-connection-string) Kafka-Clustern zu ersetzen. Im KRaft Modus werden Cluster-Metadaten innerhalb einer Gruppe von Kafka-Controllern, die Teil des Kafka-Clusters sind, und nicht knotenübergreifend weitergegeben. ZooKeeper KRaftController sind ohne zusätzliche Kosten für Sie enthalten und erfordern keine zusätzliche Einrichtung oder Verwaltung durch Sie. Weitere Informationen zu finden Sie unter [KIP-500](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum). KRaft
Hier sind einige Punkte, die Sie zum KRaft Modus auf MSK beachten sollten:
+ KRaft Der Modus ist nur für neue Cluster verfügbar. Sie können den Metadatenmodus nicht wechseln, sobald der Cluster erstellt wurde.
+ Auf der MSK-Konsole können Sie einen Kraft-basierten Cluster erstellen, indem Sie Kafka Version 3.7.x auswählen und das KRaft Kontrollkästchen im Fenster zur Clustererstellung aktivieren.
+ Um einen Cluster im KRaft Modus mithilfe der MSK-API [https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)oder der [https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)MSK-Operationen zu erstellen, sollten Sie als Version verwenden. `3.7.x.kraft` Verwenden Sie `3.7.x` als Version, um einen Cluster im ZooKeeper Modus zu erstellen.
+ Die Anzahl der Partitionen pro Broker ist auf KRaft und ZooKeeper auf Clustern identisch. Sie KRaft können jedoch mehr Partitionen pro Cluster hosten, indem Sie [mehr Broker in einem Cluster](https://docs.aws.amazon.com/msk/latest/developerguide/limits.html) bereitstellen.
+ Es sind keine API-Änderungen erforderlich, um den KRaft Modus auf Amazon MSK zu verwenden. Wenn Ihre Clients die `--zookeeper` Verbindungszeichenfolge jedoch heute noch verwenden, sollten Sie Ihre Clients so aktualisieren, dass sie die `--bootstrap-server` Verbindungszeichenfolge verwenden, um eine Verbindung zu Ihrem Cluster herzustellen. Das `--zookeeper` Flag ist in Apache Kafka Version 2.5 veraltet und wird ab Kafka Version 3.0 entfernt. Wir empfehlen Ihnen daher, aktuelle Apache Kafka-Client-Versionen und die `--bootstrap-server` Verbindungszeichenfolge für alle Verbindungen zu Ihrem Cluster zu verwenden.
+ ZooKeeper Der Modus ist weiterhin für alle veröffentlichten Versionen verfügbar, in denen Zookeeper auch von Apache Kafka unterstützt wird. Einzelheiten [Unterstützte Apache Kafka-Versionen](supported-kafka-versions.md) zum Ende der Unterstützung für Apache Kafka-Versionen und future Updates finden Sie unter.
+ Sie sollten überprüfen, ob alle von Ihnen verwendeten Tools Kafka Admin APIs ohne ZooKeeper Verbindungen verwenden können. Aktuelle Schritte [LinkedInUse's Cruise Control für Apache Kafka mit Amazon MSK](cruise-control.md) zur Verbindung Ihres Clusters mit Cruise Control finden Sie unter. Cruise Control enthält auch Anweisungen für den [Betrieb von Cruise Control ohne ZooKeeper](https://github.com/linkedin/cruise-control/wiki/Run-without-ZooKeeper).
+ Sie müssen für administrative Aktionen nicht direkt auf die KRaft Controller Ihres Clusters zugreifen. Wenn Sie jedoch Open Monitoring zur Erfassung von Metriken verwenden, benötigen Sie auch die DNS-Endpunkte Ihrer Controller, um einige Metriken zu Ihrem Cluster zu sammeln, die sich nicht auf Controller beziehen. Sie können diese DNS-Endpunkte über die MSK-Konsole oder mithilfe der API-Operation abrufen. [ListNodes](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes) Aktualisierte Schritte [Überwachen Sie einen von MSK bereitgestellten Cluster mit Prometheus](open-monitoring.md) zur Einrichtung von Open-Monitoring für KRaft basierte Cluster finden Sie unter.
+ Es gibt keine zusätzlichen [CloudWatch Metriken](https://docs.aws.amazon.com/msk/latest/developerguide/metrics-details.html), die Sie für KRaft Moduscluster ZooKeeper im Vergleich zu Modusclustern überwachen müssen. MSK verwaltet die in Ihren Clustern verwendeten KRaft Controller.
+ Sie können die Verwaltung ACLs mithilfe von Clustern im KRaft Modus fortsetzen, indem Sie die `--bootstrap-server` Verbindungszeichenfolge verwenden. Sie sollten die `--zookeeper` Verbindungszeichenfolge nicht zur Verwaltung verwenden ACLs. Siehe [Apache Kafka ACLs](msk-acls.md).
+ Im KRaft Modus werden die Metadaten Ihres Clusters auf KRaft Controllern innerhalb von Kafka und nicht auf externen ZooKeeper Knoten gespeichert. Daher müssen Sie den Zugriff auf Controller-Knoten nicht separat steuern, [wie dies bei ZooKeeper Knoten](https://docs.aws.amazon.com/msk/latest/developerguide/zookeeper-security.html) der Fall ist.
# Thema Operationen
Sie können Amazon MSK verwenden APIs , um Themen in Ihrem MSK Provisioned Cluster zu verwalten, ohne Kafka-Admin-Clients einrichten und verwalten zu müssen. Mit diesen APIs können Sie Themeneigenschaften wie Replikationsfaktor und Partitionsanzahl sowie Konfigurationseinstellungen wie Aufbewahrungs- und Bereinigungsrichtlinien definieren oder lesen. Sie können Kafka-Themen mithilfe Ihrer vertrauten Benutzeroberflächen wie AWS CLI, AWS SDKs und programmgesteuert verwalten. AWS CloudFormation Diese APIs sind auch in die Amazon MSK-Konsole integriert, sodass alle Themenoperationen an einem Ort zusammengefasst sind. Sie können jetzt Themen mit nur wenigen Klicks erstellen oder aktualisieren, indem Sie die Standardeinstellungen verwenden und gleichzeitig einen umfassenden Einblick in Themenkonfigurationen, Informationen auf Partitionsebene und Kennzahlen erhalten.
**Wichtig**
Diese API-Antworten auf Themen beziehen sich auf Daten, die etwa jede Minute aktualisiert werden. Warten Sie etwa eine Minute, bevor Sie eine Abfrage durchführen, um den aktuellsten Status des Themas zu ermitteln, nachdem Sie Änderungen vorgenommen haben.
## Voraussetzungen für die Verwendung des Themas APIs
+ Ihr Cluster muss ein von MSK bereitgestellter Cluster sein. Diese APIs sind für MSK-Cluster ohne Server nicht verfügbar.
+ Auf Ihrem Cluster muss Apache Kafka Version 3.6.0 oder höher ausgeführt werden. Weitere Informationen zu unterstützten Versionen finden Sie unter. [Unterstützte Apache Kafka-Versionen](supported-kafka-versions.md)
+ Ihr Cluster muss sich im `ACTIVE` Status befinden. Weitere Informationen zu Cluster-Status finden Sie unter [Verstehen Sie die Status des MSK Provisioned Clusters](msk-cluster-states.md).
+ Sie müssen über die entsprechenden IAM-Berechtigungen verfügen. Weitere Informationen finden Sie unter [IAM-Berechtigungen für Themenoperationen APIs](#topic-operations-permissions).
## IAM-Berechtigungen für Themenoperationen APIs
Um diese aufrufen zu können APIs, benötigen Sie die entsprechenden IAM-Berechtigungen. In der folgenden Tabelle sind die erforderlichen Berechtigungen für jede API aufgeführt.
**Erforderliche Berechtigungen für Themenoperationen APIs**
| API | Erforderliche Berechtigungen | Ressource |
| --- | --- | --- |
| ListTopics | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | Cluster ARN, Thema ARN |
| DescribeTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | Cluster ARN, Thema ARN |
| DescribeTopicPartitions | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | Cluster ARN, Thema ARN |
| CreateTopic | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` | Cluster ARN, Thema ARN |
| DeleteTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DeleteTopic` | Cluster ARN, Thema ARN |
| UpdateTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` `kafka-cluster:AlterTopicDynamicConfiguration` | Cluster ARN, Thema ARN |
**Anmerkung**
Geben Sie für `kafka-cluster:Connect` den Cluster-ARN in Ihrer IAM-Richtlinie an. Geben Sie für alle anderen Aktionen das Thema ARN in Ihrer IAM-Richtlinie an.
**Anmerkung**
Für `ListTopics` können Sie einen Platzhalter (\$1) verwenden, um alle Themen in einem Cluster zuzuordnen. Beispiel: `arn:aws:kafka:us-east-1:123456789012:topic/my-cluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/*`.
Weitere Informationen zur IAM-Zugriffskontrolle für Amazon MSK finden Sie unter. [IAM-Zugriffssteuerung](iam-access-control.md)
**Topics**
+ [Voraussetzungen für die Verwendung des Themas APIs](#topic-operations-requirements)
+ [IAM-Berechtigungen für Themenoperationen APIs](#topic-operations-permissions)
+ [Themen in einem Amazon MSK-Cluster auflisten](msk-list-topics.md)
+ [Holen Sie sich detaillierte Informationen zu einem Thema](msk-describe-topic.md)
+ [Partitionsinformationen für ein Thema anzeigen](msk-describe-topic-partitions.md)
+ [Themen in einem Amazon MSK-Cluster erstellen](msk-create-topic.md)
+ [Ein Thema in einem Amazon MSK-Cluster aktualisieren](msk-update-topic.md)
+ [Löschen Sie ein Thema in einem Amazon MSK-Cluster](msk-delete-topic.md)
# Themen in einem Amazon MSK-Cluster auflisten
Sie können alle Themen in Ihrem von MSK bereitgestellten Cluster auflisten, um grundlegende Metadaten wie Partitionsanzahl und Replikationsfaktoren anzuzeigen. Dies ist nützlich, um die Themen Ihres Clusters zu überwachen, Inventarprüfungen durchzuführen oder Themen für weitere Untersuchungen zu identifizieren.
**Anmerkung**
Die `ListTopics` API stellt grundlegende Themen-Metadaten bereit. Verwenden Sie die `DescribeTopic` API, um detaillierte Informationen zu einem bestimmten Thema zu erhalten, einschließlich seines aktuellen Status und seiner Konfiguration. Weitere Informationen finden Sie unter [Holen Sie sich detaillierte Informationen zu einem Thema](msk-describe-topic.md).
**Anmerkung**
Diese API-Antwort spiegelt Daten wider, die ungefähr jede Minute aktualisiert werden. Warten Sie etwa eine Minute, bevor Sie eine Abfrage durchführen, um den aktuellsten Status des Themas zu ermitteln, nachdem Sie Änderungen vorgenommen haben.
**Topics**
+ [Listen Sie Themen mit dem AWS-Managementkonsole](list-topics-console.md)
+ [Listen Sie Themen mit dem auf AWS CLI](list-topics-cli.md)
+ [Listet Themen mithilfe der API auf](list-topics-api.md)
# Listen Sie Themen mit dem AWS-Managementkonsole
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie in der Clusterliste den Namen des Clusters aus, für den Sie Themen auflisten möchten.
1. Wählen Sie auf der Seite mit den Cluster-Details die Registerkarte **Themen** aus.
1. In der Tabelle werden alle Themen im Cluster angezeigt, einschließlich des Themennamens, der Anzahl der Partitionen, des Replikationsfaktors und der out-of-sync Replikatanzahl.
# Listen Sie Themen mit dem auf AWS CLI
Führen Sie den folgenden Befehl aus und *ClusterArn* ersetzen Sie ihn durch den Amazon Resource Name (ARN) Ihres Clusters. Wenn Ihnen der ARN für Ihren Cluster nicht vorliegt, finden Sie ihn, indem Sie alle Cluster auflisten. Weitere Informationen finden Sie unter [Amazon MSK-Cluster auflisten](msk-list-clusters.md).
```
aws kafka list-topics --cluster-arn ClusterArn
```
Die Ausgabe dieses -Befehls sieht wie das folgende JSON-Beispiel aus.
```
{
"topics": [
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"outOfSyncReplicaCount": 0
},
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/AnotherTopic",
"topicName": "AnotherTopic",
"partitionCount": 6,
"replicationFactor": 3,
"outOfSyncReplicaCount": 1
}
]
}
```
## Ergebnisse paginieren
Wenn Ihr Cluster viele Themen enthält, können Sie die Paginierung verwenden, um Ergebnisse in kleineren Batches abzurufen. Verwenden Sie den `--max-results` Parameter, um die maximale Anzahl von Themen anzugeben, die zurückgegeben werden sollen, und verwenden Sie den `--next-token` Parameter, um die nächste Ergebnisseite abzurufen.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10
```
Wenn mehr Ergebnisse verfügbar sind, enthält die Antwort einen `nextToken` Wert. Verwenden Sie dieses Token, um die nächste Ergebnisseite abzurufen.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10 --next-token NextToken
```
## Themen nach Namen filtern
Sie können die Themenliste filtern, indem Sie mit dem `--topic-name-filter` Parameter ein Präfix angeben. Dadurch werden nur Themen zurückgegeben, deren Namen mit dem angegebenen Präfix beginnen.
```
aws kafka list-topics --cluster-arn ClusterArn --topic-name-filter "prod-"
```
Dieser Befehl gibt nur Themen zurück`prod-`, deren Namen mit `prod-orders` oder beginnen`prod-inventory`.
# Listet Themen mithilfe der API auf
Eine Liste der Themen, die die API verwenden, finden Sie unter [ListTopics](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#ListTopics).
# Holen Sie sich detaillierte Informationen zu einem Thema
Sie können detaillierte Informationen zu einem bestimmten Thema in Ihrem von MSK bereitgestellten Cluster abrufen, einschließlich des aktuellen Status, der Partitionsanzahl, des Replikationsfaktors und der Konfiguration. Dies ist nützlich für die Problembehandlung, die Überprüfung von Themeneinstellungen oder die Überwachung des Themenstatus während des Betriebs.
**Anmerkung**
Diese API-Antwort spiegelt Daten wider, die ungefähr jede Minute aktualisiert werden. Warten Sie etwa eine Minute, bevor Sie eine Abfrage durchführen, um den aktuellsten Status des Themas zu ermitteln, nachdem Sie Änderungen vorgenommen haben.
**Topics**
+ [Beschreiben Sie ein Thema mit dem AWS-Managementkonsole](describe-topic-console.md)
+ [Beschreiben Sie ein Thema mit dem AWS CLI](describe-topic-cli.md)
+ [Beschreiben Sie ein Thema mithilfe der API](describe-topic-api.md)
# Beschreiben Sie ein Thema mit dem AWS-Managementkonsole
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie in der Clusterliste den Namen des Clusters aus, der das Thema enthält, das Sie beschreiben möchten.
1. Wählen Sie auf der Seite mit den Cluster-Details die Registerkarte **Themen** aus.
1. Wählen Sie in der Themenliste den Namen des Themas aus, das Sie sich ansehen möchten.
1. Auf der Seite mit den Themendetails werden Informationen zum Thema angezeigt, einschließlich Status, Partitionsanzahl, Replikationsfaktor und Konfigurationseinstellungen.
# Beschreiben Sie ein Thema mit dem AWS CLI
Führen Sie den folgenden Befehl aus und *ClusterArn* ersetzen Sie ihn durch den Amazon-Ressourcennamen (ARN) Ihres Clusters und *TopicName* durch den Namen des Themas, das Sie beschreiben möchten.
```
aws kafka describe-topic --cluster-arn ClusterArn --topic-name TopicName
```
Die Ausgabe dieses -Befehls sieht wie das folgende JSON-Beispiel aus.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"configs": "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw",
"status": "ACTIVE"
}
```
## Den Status des Themas verstehen
Das `status` Feld gibt den aktuellen Status des Themas an. In der folgenden Tabelle werden die möglichen Statuswerte beschrieben.
**Statuswerte des Themas**
| Status | Description |
| --- | --- |
| WIRD ERSTELLT | Das Thema wird gerade erstellt. |
| ACTIVE | Das Thema ist aktiv und einsatzbereit. |
| WIRD AKTUALISIERT | Die Themenkonfiguration wird aktualisiert. |
| WIRD GELÖSCHT | Das Thema wird gelöscht. |
## Grundlegendes zu Themenkonfigurationen
Das `configs` Feld enthält die Kafka-Konfigurationseigenschaften des Themas, kodiert im Base64-Format. Um die Konfiguration in einem lesbaren Format anzuzeigen, müssen Sie die Base64-Zeichenfolge dekodieren.
Das folgende Beispiel zeigt, wie die Konfiguration mit dem `base64` Befehl unter Linux oder macOS dekodiert wird.
```
echo "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw" | base64 --decode
```
Die dekodierte Ausgabe zeigt die Konfigurationseigenschaften des Themas im Schlüsselwertformat.
```
compression.type=producer
retention.ms=604800000
```
Weitere Hinweise zu Konfigurationseigenschaften auf Themenebene finden Sie unter. [Amazon MSK-Konfiguration auf Themenebene](msk-configuration-properties.md#msk-topic-confinguration)
# Beschreiben Sie ein Thema mithilfe der API
Eine Beschreibung eines Themas mithilfe der API finden Sie unter [DescribeTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DescribeTopic).
# Partitionsinformationen für ein Thema anzeigen
Sie können detaillierte Informationen zu den Partitionen eines bestimmten Themas in Ihrem von MSK bereitgestellten Cluster abrufen. Zu diesen Informationen gehören die Partitionsnummer, der Leader-Broker, die Replikatbroker und die In-Sync-Replikate (ISR). Dies ist nützlich, um die Partitionsverteilung zu überwachen, zu wenig replizierte Partitionen zu identifizieren oder Replikationsprobleme zu beheben.
**Anmerkung**
Diese API-Antwort spiegelt Daten wider, die ungefähr jede Minute aktualisiert werden. Warten Sie etwa eine Minute, bevor Sie eine Abfrage durchführen, um den aktuellsten Status des Themas zu ermitteln, nachdem Sie Änderungen vorgenommen haben.
**Topics**
+ [Zeigen Sie Partitionsinformationen mit dem AWS-Managementkonsole](describe-topic-partitions-console.md)
+ [Zeigen Sie Partitionsinformationen an, indem Sie AWS CLI](describe-topic-partitions-cli.md)
+ [Partitionsinformationen mithilfe der API anzeigen](describe-topic-partitions-api.md)
# Zeigen Sie Partitionsinformationen mit dem AWS-Managementkonsole
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie in der Clusterliste den Namen des Clusters aus, der das Thema enthält.
1. Wählen Sie auf der Seite mit den Cluster-Details die Registerkarte **Themen** aus.
1. Wählen Sie in der Themenliste den Namen des Themas aus, für das Sie Partitionsinformationen anzeigen möchten.
1. Auf der Seite mit den Themendetails werden die Partitionsinformationen mit Partitionsnummer, Leader-Broker, Replikaten und synchronisierten Replikaten für jede Partition angezeigt.
# Zeigen Sie Partitionsinformationen an, indem Sie AWS CLI
Führen Sie den folgenden Befehl aus und *ClusterArn* ersetzen Sie ihn durch den Amazon-Ressourcennamen (ARN) Ihres Clusters und *TopicName* durch den Namen des Themas.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName
```
Die Ausgabe dieses -Befehls sieht wie das folgende JSON-Beispiel aus.
```
{
"partitions": [
{
"partition": 0,
"leader": 1,
"replicas": [1, 2, 3],
"isr": [1, 2, 3]
},
{
"partition": 1,
"leader": 2,
"replicas": [2, 3, 1],
"isr": [2, 3, 1]
},
{
"partition": 2,
"leader": 3,
"replicas": [3, 1, 2],
"isr": [3, 1]
}
]
}
```
## Grundlegendes zu Partitionsinformationen
Die Antwort enthält die folgenden Informationen für jede Partition:
+ **Partition** — Die Partitionsnummer. Partitionen werden ab 0 nummeriert.
+ **leader** — Die Broker-ID des Leaders für diese Partition. Der Leader bearbeitet alle Lese- und Schreibanforderungen für die Partition.
+ **Repliken** — Die Liste der Broker IDs , die über Replikate dieser Partition verfügen. Dazu gehören sowohl synchrone als auch Replikate. out-of-sync
+ **isr** — Die Liste der Broker, bei denen es sich um synchrone IDs Replikate handelt. Diese Replikate haben sich vollständig an den Leader gehalten und können bei Bedarf die Führung übernehmen.
Im obigen Beispiel hat Partition 2 ein out-of-sync Replikat. Die `replicas` Liste enthält Broker 2, die `isr` Liste jedoch nicht. Dies deutet darauf hin, dass Broker 2 nicht vollständig mit dem Leader für diese Partition Schritt gehalten hat.
## Ergebnisse paginieren
Wenn Ihr Thema viele Partitionen hat, können Sie die Paginierung verwenden, um Ergebnisse in kleineren Batches abzurufen. Verwenden Sie den `--max-results` Parameter, um die maximale Anzahl von Partitionen anzugeben, die zurückgegeben werden sollen, und verwenden Sie den `--next-token` Parameter, um die nächste Ergebnisseite abzurufen.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10
```
Wenn mehr Ergebnisse verfügbar sind, enthält die Antwort einen `nextToken` Wert. Verwenden Sie dieses Token, um die nächste Ergebnisseite abzurufen.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10 --next-token NextToken
```
## Häufige Anwendungsfälle
Das Anzeigen von Partitionsinformationen ist in verschiedenen Szenarien nützlich:
+ **Zu wenig replizierte Partitionen identifizieren** — Vergleichen Sie die `isr` Listen `replicas` und, um Partitionen zu identifizieren, bei denen einige Replikate nicht synchron sind. Dies kann auf Leistungsprobleme oder Brokerprobleme hinweisen.
+ **Überwachung der Partitionsverteilung** — Stellen Sie sicher, dass die Partitionsleiter gleichmäßig auf die Broker verteilt sind, um eine ausgewogene Auslastung zu gewährleisten.
+ **Behebung von Replikationsproblemen** — Identifizieren Sie anhand der ISR-Liste, welche Broker Probleme haben, mit der Replikation Schritt zu halten.
+ **Planung der Neuverteilung von Partitionen** — Verwenden Sie diese Informationen, um sich mit dem aktuellen Partitionslayout vertraut zu machen, bevor Sie die Neuverteilung durchführen.
# Partitionsinformationen mithilfe der API anzeigen
Informationen zum Anzeigen von Partitionsinformationen mithilfe der API finden Sie unter [DescribeTopicPartitions](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname-partitions.html#DescribeTopicPartitions).
# Themen in einem Amazon MSK-Cluster erstellen
Sie können Themen in Ihrem MSK Provisioned-Cluster direkt mithilfe dieser API erstellen, ohne ein benutzerdefiniertes Kafka einrichten zu müssen. AdminClient Beim Erstellen eines Themas geben Sie den Themennamen, die Partitionsanzahl, den Replikationsfaktor und optional die Themenkonfigurationen an.
**Topics**
+ [Erstellen Sie Themen mit dem AWS-Managementkonsole](create-topic-console.md)
+ [Erstellen Sie ein Thema mit dem AWS CLI](create-topic-cli.md)
+ [Erstellen Sie mithilfe der API ein Thema](create-topic-api.md)
# Erstellen Sie Themen mit dem AWS-Managementkonsole
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie in der Clusterliste den Namen des Clusters aus, in dem Sie die Themen erstellen möchten.
1. Wählen Sie auf der Seite mit den Cluster-Details die Registerkarte **Themen** aus.
1. Wählen Sie **Thema erstellen** aus.
1. Geben Sie den Themennamen, die Partitionsanzahl und den Replikationsfaktor ein. Fügen Sie optional Konfigurationen hinzu. Sie können mehrere Themen gleichzeitig erstellen.
1. Wählen Sie **Thema erstellen** aus.
# Erstellen Sie ein Thema mit dem AWS CLI
Führen Sie den folgenden Befehl aus und *ClusterArn* ersetzen Sie ihn durch den Amazon Resource Name (ARN) Ihres Clusters. Wenn Ihnen der ARN für Ihren Cluster nicht vorliegt, finden Sie ihn, indem Sie alle Cluster auflisten. Weitere Informationen finden Sie unter [Amazon MSK-Cluster auflisten](msk-list-clusters.md).
```
aws kafka create-topic --cluster-arn ClusterArn --topic-name MyTopic --partition-count 3 --replication-factor 3
```
Die Ausgabe dieses -Befehls sieht wie das folgende JSON-Beispiel aus.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "CREATING"
}
```
# Erstellen Sie mithilfe der API ein Thema
Informationen zum Erstellen eines Themas mithilfe der API finden Sie unter [CreateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#CreateTopic).
# Ein Thema in einem Amazon MSK-Cluster aktualisieren
Aktualisieren Sie die Partitionsanzahl oder die Konfigurationen auf Themenebene für ein vorhandenes Thema. Durch diesen Vorgang wird das Thema geändert, ohne dass eine Neuerstellung erforderlich ist.
**Anmerkung**
Sie können entweder die Partitionsanzahl oder die Themenkonfigurationen in einem einzigen API-Aufruf aktualisieren, aber nicht beide gleichzeitig. Um beide zu aktualisieren, führen Sie separate API-Aufrufe durch.
**Topics**
+ [Aktualisieren Sie ein Thema mithilfe der AWS-Managementkonsole](update-topic-console.md)
+ [Aktualisieren Sie ein Thema mit dem AWS CLI](update-topic-cli.md)
+ [Aktualisieren Sie ein Thema mithilfe der API](update-topic-api.md)
# Aktualisieren Sie ein Thema mithilfe der AWS-Managementkonsole
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie in der Clusterliste den Namen des Clusters aus, der das Thema enthält, das Sie aktualisieren möchten.
1. Wählen Sie auf der Seite mit den Cluster-Details die Registerkarte **Themen** aus.
1. Wählen Sie das Thema aus, das Sie aktualisieren möchten, und wählen Sie dann unter **Aktionen** entweder **Partitionseinstellungen** **bearbeiten oder Konfigurationen bearbeiten** aus.
1. Aktualisieren Sie die Partitionsanzahl oder die Konfigurationen nach Bedarf.
1. Wählen Sie **Speichern**.
# Aktualisieren Sie ein Thema mit dem AWS CLI
Führen Sie den folgenden Befehl aus und *ClusterArn* ersetzen Sie ihn durch den Amazon-Ressourcennamen (ARN) Ihres Clusters und *TopicName* durch den Namen des Themas, das Sie aktualisieren möchten.
```
aws kafka update-topic --cluster-arn ClusterArn --topic-name TopicName --partition-count 6
```
Die Ausgabe dieses -Befehls sieht wie das folgende JSON-Beispiel aus.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "UPDATING"
}
```
# Aktualisieren Sie ein Thema mithilfe der API
Informationen zum Aktualisieren eines Themas mithilfe der API finden Sie unter [UpdateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#UpdateTopic).
# Löschen Sie ein Thema in einem Amazon MSK-Cluster
Durch das Löschen eines Themas werden alle zugehörigen Daten, Metadaten und Partitionsinformationen dauerhaft entfernt. Diese Operation kann nicht rückgängig gemacht werden.
**Topics**
+ [Löschen Sie ein Thema mit dem AWS-Managementkonsole](delete-topic-console.md)
+ [Löschen Sie ein Thema mit dem AWS CLI](delete-topic-cli.md)
+ [Löschen Sie ein Thema mithilfe der API](delete-topic-api.md)
# Löschen Sie ein Thema mit dem AWS-Managementkonsole
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon MSK-Konsole zu [https://console.aws.amazon.com/msk/Hause? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Wählen Sie in der Clusterliste den Namen des Clusters aus, der das Thema enthält, das Sie löschen möchten.
1. Wählen Sie auf der Seite mit den Cluster-Details die Registerkarte **Themen** aus.
1. Wählen Sie die Themen aus, die Sie löschen möchten, und wählen Sie dann Aus **Aktionen** **löschen**.
1. Bestätigen Sie den Löschvorgang und wählen Sie dann **Löschen**.
# Löschen Sie ein Thema mit dem AWS CLI
Führen Sie den folgenden Befehl aus und *ClusterArn* ersetzen Sie ihn durch den Amazon-Ressourcennamen (ARN) Ihres Clusters und *TopicName* durch den Namen des Themas, das Sie löschen möchten.
```
aws kafka delete-topic --cluster-arn ClusterArn --topic-name TopicName
```
Die Ausgabe dieses -Befehls sieht wie das folgende JSON-Beispiel aus.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "DELETING"
}
```
# Löschen Sie ein Thema mithilfe der API
Informationen zum Löschen eines Themas mithilfe der API finden Sie unter [DeleteTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DeleteTopic).
# Amazon-MSK-Ressourcen
Der Begriff *Ressourcen* hat in Amazon MSK je nach Kontext zwei Bedeutungen. Im Kontext APIs einer Ressource handelt es sich um eine Struktur, für die Sie eine Operation aufrufen können. Eine Liste dieser Ressourcen und der Vorgänge, die Sie für sie aufrufen können, finden Sie unter [Ressourcen](https://docs.aws.amazon.com/msk/1.0/apireference/resources.html) in der API-Referenz zu Amazon MSK. Im Kontext von [IAM-Zugriffssteuerung](iam-access-control.md) ist eine Ressource eine Entität, für die Sie den Zugriff gewähren oder verweigern können, wie im Abschnitt [Ressourcen für Autorisierungsrichtlinien](kafka-actions.md#msk-iam-resources) definiert.
# Apache-Kafka-Versionen
Wenn Sie einen Amazon-MSK-Cluster erstellen, geben Sie an, welche Apache-Kafka-Version Sie darauf ausführen möchten. Sie können auch die Apache Kafka-Version eines vorhandenen Clusters aktualisieren. Die Themen in diesem Kapitel helfen Ihnen, die Zeitpläne für die Unterstützung der Kafka-Version sowie Vorschläge für bewährte Verfahren zu verstehen.
**Topics**
+ [Unterstützte Apache Kafka-Versionen](supported-kafka-versions.md)
+ [Unterstützung für Amazon MSK-Versionen](version-support.md)
# Unterstützte Apache Kafka-Versionen
Amazon Managed Streaming für Apache Kafka (Amazon MSK) unterstützt die folgenden Versionen von Apache Kafka und Amazon MSK. Die Apache Kafka-Community bietet etwa 12 Monate Support für eine Version nach dem Veröffentlichungsdatum. Weitere Informationen finden Sie unter [Apache Kafka EOL (End of Life](https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatIsOurEOLPolicy?)) -Richtlinie.
In der folgenden Tabelle sind die Apache Kafka-Versionen aufgeführt, die Amazon MSK unterstützt.
| Apache-Kafka-Version | Veröffentlichungsdatum von MSK | Datum des Endes des Supports |
| --- | --- | --- |
| [1.1.1](https://archive.apache.org/dist/kafka/1.1.1/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.1.0](https://archive.apache.org/dist/kafka/2.1.0/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.2.1](https://archive.apache.org/dist/kafka/2.2.1/RELEASE_NOTES.html) | 31.07.2019 | 2024-06-08 |
| [2.3.1](https://archive.apache.org/dist/kafka/2.3.1/RELEASE_NOTES.html) | 19.12.2019 | 2024-06-08 |
| [2.4.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 02.04.2020 | 2024-06-08 |
| [2.4.1.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 09.09.2020 | 2024-06-08 |
| [2,5.1](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) | 30.09.2020 | 2024-06-08 |
| [2,6.0](https://archive.apache.org/dist/kafka/2.6.0/RELEASE_NOTES.html) | 21.10.2020 | 2024-09-11 |
| [2.6.1](https://archive.apache.org/dist/kafka/2.6.1/RELEASE_NOTES.html) | 19.01.2021 | 11. September 2024 |
| [2.6.2](https://archive.apache.org/dist/kafka/2.6.2/RELEASE_NOTES.html) | 29.04.2021 | 11. September 2024 |
| [2.6.3](https://archive.apache.org/dist/kafka/2.6.3/RELEASE_NOTES.html) | 21.12.2021 | 2024-09-11 |
| [2,7,0](https://archive.apache.org/dist/kafka/2.7.0/RELEASE_NOTES.html) | 29.12.2020 | 2024-09-11 |
| [2.7.1](https://archive.apache.org/dist/kafka/2.7.1/RELEASE_NOTES.html) | 25.05.2021 | 11. September 2024 |
| [2.7.2](https://archive.apache.org/dist/kafka/2.7.2/RELEASE_NOTES.html) | 21.12.2021 | 2024-09-11 |
| [2,8,0](https://archive.apache.org/dist/kafka/2.8.0/RELEASE_NOTES.html) | 19.05.2021 | 11. September 2024 |
| [2,8.1](https://archive.apache.org/dist/kafka/2.8.1/RELEASE_NOTES.html) | 28.10.2022 | 11. September 2024 |
| [2.8.2 gestaffelt](https://archive.apache.org/dist/kafka/2.8.2/RELEASE_NOTES.html) | 28.10.2022 | 14.01.2025 |
| [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html) | 22.06.2022 | 11. September 2024 |
| [3.2.0](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) | 22.06.2022 | 11. September 2024 |
| [3.3.1](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) | 26.10.2022 | 11. September 2024 |
| [3.3.2](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) | 2023-03-02 | 2024-09-11 |
| [3,4,0](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) | 2023-05-04 | 2025-08-04 |
| [3.5.1](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) | 2023-09-26 | 2025-10-23 |
| [3,6,0](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) | 16.11.2023-23 | 2026-06-01 |
| [3.7.x](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html) | 29.05.2024 | -- |
| [3.8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html) | 20.02.2025 | -- |
| [3.9.x (empfohlen](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html)) | 2025-04-21 | -- |
| [4.0.x](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html) | 16.05.2025 | -- |
| [4.1.x](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) | 2025-10-15 | -- |
Weitere Informationen zur Support-Richtlinie für Amazon MSK-Versionen finden Sie unter[Support-Richtlinie für Amazon MSK-Versionen](version-support.md#version-support-policy).
## Amazon MSK Version 4.1.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) unterstützt jetzt Apache Kafka Version 4.1, die Warteschlangen als Vorschaufunktion, ein neues Streams Rebalance Protocol im Early-Access und Eligible Leader Replicas (ELR) einführt. Neben diesen Funktionen enthält Apache Kafka Version 4.1 verschiedene Fehlerkorrekturen und Verbesserungen.
Ein wichtiges Highlight von Kafka 4.1 ist die Einführung von Warteschlangen als Vorschaufunktion. Sie können mehrere Benutzer verwenden, um Nachrichten aus denselben Themenpartitionen zu verarbeiten, wodurch die Parallelität und der Durchsatz für Workloads, die eine Nachrichtenzustellung erfordern, verbessert werden. point-to-point Das neue Streams Rebalance Protocol baut auf dem Consumer Rebalance-Protokoll von Kafka 4.0 auf und erweitert die Funktionen zur Broker-Koordination auf Kafka Streams, um Aufgabenzuweisungen und Rebalancing zu optimieren. Darüber hinaus ist ELR jetzt standardmäßig aktiviert, um die Verfügbarkeit zu erhöhen.
Weitere Informationen und eine vollständige Liste der Verbesserungen und Bugfixes finden Sie in den [Apache Kafka-Versionshinweisen für Version 4.1](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html).
Um mit der Verwendung von Apache Kafka 4.1 auf Amazon MSK zu beginnen, wählen Sie Version 4.1.x, wenn Sie einen neuen Cluster über, oder erstellen. AWS-Managementkonsole AWS CLI AWS SDKs Sie können auch bestehende, von MSK bereitgestellte Cluster mit einem fortlaufenden In-Place-Update aktualisieren. Amazon MSK orchestriert Broker-Neustarts, um die Verfügbarkeit aufrechtzuerhalten und Ihre Daten während des Upgrades zu schützen. Unterstützung für Kafka Version 4.1 ist überall verfügbar AWS-Regionen , wo Amazon MSK angeboten wird.
## Amazon MSK Version 4.0.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) unterstützt jetzt Apache Kafka Version 4.0. Diese Version bringt die neuesten Fortschritte im Bereich Clustermanagement und Leistung in MSK Provisioned. Mit Kafka 4.0 wird ein neues Protokoll zur Neugewichtung von Privatkunden eingeführt, das jetzt allgemein verfügbar ist und für einen reibungsloseren und schnelleren Gruppenausgleich sorgt. Darüber hinaus verlangt Kafka 4.0 von Brokern und Tools die Verwendung von Java 17, was eine verbesserte Sicherheit und Leistung bietet, verschiedene Fehlerkorrekturen und Verbesserungen beinhaltet und die Metadatenverwaltung über Apache überflüssig macht. ZooKeeper
Weitere Informationen und eine vollständige Liste der Verbesserungen und Bugfixes finden Sie in den [Apache Kafka-Versionshinweisen](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html) für Version 4.0.
## Amazon MSK Version 3.9.x (empfohlen)
Amazon Managed Streaming for Apache Kafka (Amazon MSK) unterstützt jetzt Apache Kafka Version 3.9. Diese Version erweitert die Funktionalität der mehrstufigen Speicherung, indem Sie Tiered Data beibehalten können, wenn Sie Tiered Storage auf Themenebene deaktivieren. Ihre Anwendungen für Privatanwender können historische Daten aus dem Remote-Log-Start-Offset (Rx) lesen und gleichzeitig kontinuierliche Log-Offsets im lokalen Speicher und im Remotespeicher beibehalten.
Version 3.9 ist die letzte Version, die sowohl KRaft Metadatenverwaltungssysteme als ZooKeeper auch unterstützt. Amazon MSK bietet ab dem Veröffentlichungsdatum mindestens zwei Jahre lang erweiterten Support für Version 3.9.
Weitere Informationen und eine vollständige Liste der Verbesserungen und Bugfixes finden Sie in den [Apache Kafka-Versionshinweisen für Version](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html) 3.9.x.
## Amazon MSK Version 3.8.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) unterstützt jetzt Apache Kafka Version 3.8. Sie können jetzt neue Cluster mit Version 3.8 entweder mit KRAFT oder dem ZooKeeper Modus für die Metadatenverwaltung erstellen oder Ihre vorhandenen ZooKeeper basierten Cluster auf Version 3.8 aktualisieren. Apache Kafka Version 3.8 enthält mehrere Bugfixes und neue Funktionen, die die Leistung verbessern. Zu den wichtigsten neuen Funktionen gehört die Unterstützung für die Konfiguration der Komprimierungsstufe. Auf diese Weise können Sie Ihre Leistung bei der Verwendung von Komprimierungstypen wie lz4, zstd und gzip weiter optimieren, indem Sie die Standardkomprimierungsstufe ändern können.
Weitere Informationen und eine vollständige Liste der Verbesserungen und Bugfixes finden Sie in den [Apache Kafka-Versionshinweisen](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html) für Version 3.8.x.
## Apache Kafka Version 3.7.x (mit produktionsbereitem Tiered Storage)
Apache Kafka Version 3.7.x auf MSK beinhaltet Unterstützung für Apache Kafka Version 3.7.0. Sie können Cluster erstellen oder bestehende Cluster aktualisieren, um die neue Version 3.7.x zu verwenden. Mit dieser Änderung der Versionsbezeichnung müssen Sie keine neueren Patchfix-Versionen wie 3.7.1 mehr verwenden, wenn sie von der Apache Kafka-Community veröffentlicht werden. Amazon MSK aktualisiert 3.7.x automatisch, um future Patch-Versionen zu unterstützen, sobald diese verfügbar sind. Auf diese Weise können Sie von den Sicherheits- und Bugfixes profitieren, die über Patchfix-Versionen verfügbar sind, ohne ein Versions-Upgrade auszulösen. Diese von Apache Kafka veröffentlichten Patchfix-Versionen beeinträchtigen nicht die Versionskompatibilität, und Sie können von den neuen Patchfix-Versionen profitieren, ohne sich Gedanken über Lese- oder Schreibfehler Ihrer Client-Anwendungen machen zu müssen. Bitte stellen Sie sicher, dass Ihre Tools zur Infrastrukturautomatisierung, wie z. B. CloudFormation, aktualisiert sind, um dieser Änderung der Versionsbezeichnung Rechnung zu tragen.
Amazon MSK unterstützt jetzt den KRaft Modus (Apache Kafka Raft) in Apache Kafka Version 3.7.x. Bei Amazon MSK sind KRaft Controller wie bei ZooKeeper Nodes ohne zusätzliche Kosten für Sie enthalten und erfordern keine zusätzliche Einrichtung oder Verwaltung durch Sie. In Apache Kafka Version 3.7.x können Sie jetzt Cluster entweder ZooKeeper im KRaft Modus oder im Modus erstellen. Im Kraft-Modus können Sie bis zu 60 Broker hinzufügen, um mehr Partitionen pro Cluster zu hosten, ohne eine Erhöhung des Limits zu beantragen, verglichen mit dem Kontingent von 30 Brokern bei Zookeeper-basierten Clustern. Weitere Informationen über KRaft MSK finden Sie unter. [KRaft Modus](metadata-management.md#kraft-intro)
Apache Kafka Version 3.7.x enthält auch mehrere Bugfixes und neue Funktionen, die die Leistung verbessern. Zu den wichtigsten Verbesserungen gehören Leader-Discovery-Optimierungen für Clients und Optionen zur Optimierung des Log-Segment-Flushs. [Eine vollständige Liste der Verbesserungen und Bugfixes finden Sie in den Apache Kafka-Versionshinweisen für 3.7.0.](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html)
## Apache Kafka Version 3.6.0 (mit produktionsbereiter gestaffelter Speicherung)
Weitere Informationen zu Apache Kafka Version 3.6.0 (mit produktionsbereiter gestaffelter speicherung) finden Sie in den [Versionshinweisen](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) auf der Download-Seite von Apache Kafka.
Amazon MSK wird in dieser Version aus Stabilitätsgründen weiterhin Zookeeper für die Quorumverwaltung verwenden und verwalten.
## Amazon MSK versie 3.5.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) unterstützt jetzt Apache Kafka Version 3.5.1 für neue und bestehende Cluster. Apache Kafka 3.5.1 enthält mehrere Bugfixes und neue Funktionen, die die Leistung verbessern. Zu den wichtigsten Funktionen gehört die Einführung einer neuen Rack-fähigen Partitionszuweisung für Privatanwender. Amazon MSK wird in dieser Version weiterhin Zookeeper für die Quorumverwaltung verwenden und verwalten. Eine vollständige Liste der Verbesserungen und Bugfixes finden Sie in den Apache Kafka-Versionshinweisen für 3.5.1.
Weitere Informationen zu Apache Kafka Version 3.5.1 finden Sie in den [Versionshinweisen](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) auf der Download-Seite von Apache Kafka.
## Amazon MSK versie 3.4.0
Amazon Managed Streaming for Apache Kafka (Amazon MSK) unterstützt jetzt Apache Kafka Version 3.4.0 für neue und bestehende Cluster. Apache Kafka 3.4.0 enthält mehrere Bugfixes und neue Funktionen, die die Leistung verbessern. Zu den wichtigsten Funktionen gehört ein Fix zur Verbesserung der Stabilität beim Abrufen aus dem nächstgelegenen Replikat. Amazon MSK wird in dieser Version weiterhin Zookeeper für die Quorumverwaltung verwenden und verwalten. Eine vollständige Liste der Verbesserungen und Bugfixes finden Sie in den Apache Kafka-Versionshinweisen für 3.4.0.
Weitere Informationen zu Apache Kafka Version 3.4.0 finden Sie in den [Versionshinweisen](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) auf der Download-Seite von Apache Kafka.
## Amazon MSK versie 3.3.2
Amazon Managed Streaming for Apache Kafka (Amazon MSK) unterstützt jetzt Apache Kafka Version 3.3.2 für neue und bestehende Cluster. Apache Kafka 3.3.2 enthält mehrere Bugfixes und neue Funktionen, die die Leistung verbessern. Zu den wichtigsten Funktionen gehört ein Fix zur Verbesserung der Stabilität beim Abrufen aus dem nächstgelegenen Replikat. Amazon MSK wird in dieser Version weiterhin Zookeeper für die Quorumverwaltung verwenden und verwalten. Eine vollständige Liste der Verbesserungen und Bugfixes finden Sie in den Apache Kafka-Versionshinweisen für 3.3.2.
Weitere Informationen zu Apache Kafka Version 3.3.2 finden Sie in den [Versionshinweisen](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) auf der Download-Seite von Apache Kafka.
## Amazon MSK versie 3.3.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) unterstützt jetzt Apache Kafka Version 3.3.1 für neue und bestehende Cluster. Apache Kafka 3.3.1 enthält mehrere Bugfixes und neue Funktionen, die die Leistung verbessern. Zu den wichtigsten Funktionen gehören Verbesserungen an Metriken und Partitionierung. Amazon MSK wird in dieser Version aus Stabilitätsgründen weiterhin Zookeeper für die Quorumverwaltung verwenden und verwalten. Eine vollständige Liste der Verbesserungen und Bugfixes finden Sie in den Apache Kafka-Versionshinweisen für 3.3.1.
Weitere Informationen zu Apache Kafka Version 3.3.1 finden Sie in den [Versionshinweisen](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) auf der Download-Seite von Apache Kafka.
## Amazon MSK versie 3.1.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) unterstützt jetzt Apache Kafka Version 3.1.1 und 3.2.0 für neue und bestehende Cluster. Apache Kafka 3.1.1 und Apache Kafka 3.2.0 enthalten mehrere Bugfixes und neue Funktionen, die die Leistung verbessern. Zu den wichtigsten Funktionen gehören Verbesserungen der Metriken und die Verwendung von Themen. IDs MSK wird Zookeeper in dieser Version aus Stabilitätsgründen weiterhin für die Quorumverwaltung verwenden und verwalten. Eine vollständige Liste der Verbesserungen und Bugfixes finden Sie in den Apache Kafka-Versionshinweisen für 3.1.1 und 3.2.0.
Informationen zu Apache Kafka Version 3.1.1 und 3.2.0 finden Sie in den [Versionshinweisen 3.2.0 und [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html)](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) auf der Apache Kafka-Downloadseite.
## Mehrstufiger Speicher von Amazon MSK, Version 2.8.2.tiered
Bei dieser Version handelt es sich um eine reine Amazon-MSK-Version von Apache Kafka Version 2.8.2 und sie ist mit Open-Source-Apache-Kafka-Clients kompatibel.
[Die Version 2.8.2. Tiered enthält Tiered-Storage-Funktionen, die mit den in KIP-405 für Apache Kafka eingeführten Funktionen kompatibel sind. APIs ](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) Weitere Informationen zu den Feature für gestaffelten Speicher für Amazon MSK finden Sie unter [Mehrstufiger Speicher für Standard-Broker](msk-tiered-storage.md).
## Apache Kafka Version 2.5.1
Apache Kafka Version 2.5.1 enthält mehrere Bugfixes und neue Funktionen, darunter Verschlüsselung bei der Übertragung für Apache und Administrationsclients. ZooKeeper Amazon MSK stellt ZooKeeper TLS-Endpunkte bereit, die Sie während des [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)Vorgangs abfragen können.
Die Ausgabe des [ DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)Vorgangs umfasst den `ZookeeperConnectStringTls` Knoten, der die TLS-Zookeeper-Endpunkte auflistet.
Das folgende Beispiel zeigt den `ZookeeperConnectStringTls`-Knoten der Antwort für den `DescribeCluster`-Vorgang:
```
"ZookeeperConnectStringTls": "z-3.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-2.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-1.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182"
```
Informationen zum Verwenden von TLS-Verschlüsselung mit Zookeeper finden Sie unter [Verwendung der TLS-Sicherheit mit Apache ZooKeeper](zookeeper-security-tls.md).
Weitere Informationen zu Apache Kafka Version 2.5.1 finden Sie in den [Versionshinweisen](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) auf der Download-Seite von Apache Kafka.
## Amazon-MSK-Bugfix Version 2.4.1.1
Bei dieser Version handelt es sich um eine reine Amazon-MSK-Bugfix-Version von Apache Kafka Version 2.4.1. Diese Bugfix-Version enthält eine Lösung für [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752), ein seltenes Problem, das dazu führt, dass Verbrauchergruppen ständig das Gleichgewicht wiederherstellen und den Status `PreparingRebalance` beibehalten. Dieses Problem betrifft Cluster, auf denen die Versionen 2.3.1 und 2.4.1 von Apache Kafka ausgeführt werden. Diese Version enthält einen von der Community erstellten Fix, der in Apache Kafka Version 2.5.0 verfügbar ist.
**Anmerkung**
Amazon-MSK-Cluster, auf denen Version 2.4.1.1 ausgeführt wird, sind mit jedem Apache-Kafka-Client kompatibel, der mit Apache Kafka Version 2.4.1 kompatibel ist.
Wir empfehlen, die MSK-Bugfix-Version 2.4.1.1 für neue Amazon-MSK-Cluster zu verwenden, wenn Sie Apache Kafka 2.4.1 bevorzugen. Sie können bestehende Cluster, auf denen Apache Kafka Version 2.4.1 ausgeführt wird, auf diese Version aktualisieren, um diesen Fix zu integrieren. Hinweise zum Aktualisieren eines vorhandenen Clusters finden Sie unter [Aktualisieren Sie die Apache Kafka-Version](version-upgrades.md).
Informationen zur Umgehung dieses Problems, ohne den Cluster auf Version 2.4.1.1 zu aktualisieren, finden Sie im Abschnitt [Verbrauchergruppe steckt im Status `PreparingRebalance` fest](troubleshooting.md#consumer-group-rebalance) des [Problembehandlung bei Ihrem Amazon MSK-Cluster](troubleshooting.md)-Handbuchs.
## Apache Kafka Version 2.4.1 (verwenden Sie stattdessen 2.4.1.1)
**Anmerkung**
Mit Apache Kafka Version 2.4.1 können Sie keinen MSK-Cluster mehr erstellen. Stattdessen können Sie [Amazon-MSK-Bugfix Version 2.4.1.1](#2.4.1.1) mit Clients verwenden, die mit Apache Kafka Version 2.4.1 kompatibel sind. Und wenn Sie bereits einen MSK-Cluster mit Apache Kafka Version 2.4.1 haben, empfehlen wir Ihnen, ihn so zu aktualisieren, dass er stattdessen Apache Kafka Version 2.4.1.1 verwendet.
KIP-392 ist einer der wichtigsten Verbesserungen für Kafka, die in der Version 2.4.1 von Apache Kafka enthalten sind. Sie ermöglicht Konsumenten das Abrufen vom nächstgelegenen Replikat. Um dieses Feature zu verwenden, legen Sie `client.rack` in den Konsumenteneigenschaften auf die ID der Availability Zone des Konsumenten fest. Ein Beispiel für eine AZ-ID ist `use1-az1`. Amazon MSK legt `broker.rack` die IDs Availability Zones der Broker fest. Sie müssen auch die Konfigurationseigenschaft `replica.selector.class` auf `org.apache.kafka.common.replica.RackAwareReplicaSelector` festlegen. Dabei handelt es sich um eine Implementierung für Rackinformationen von Apache Kafka.
Wenn Sie diese Version von Apache Kafka verwenden, werden die Metriken in der Überwachungsebene `PER_TOPIC_PER_BROKER` erst angezeigt, nachdem ihre Werte zum ersten Mal ungleich Null sind. Weitere Informationen hierzu finden Sie unter [Überwachung auf `PER_TOPIC_PER_BROKER`-Ebene](metrics-details.md#broker-topic-metrics).
Informationen darüber, wie Sie die Availability Zone finden IDs, finden Sie unter [AZ IDs for Your Resource](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) im AWS Resource Access Manager Benutzerhandbuch.
Informationen zum Festlegen von Konfigurationseigenschaften finden Sie unter [Bereitgestellte Amazon MSK-Konfiguration](msk-configuration.md).
Weitere Informationen zu KIP-392 finden Sie auf den Confluence-Seiten unter [Allow Consumers to Fetch from Closest Replica](https://cwiki.apache.org/confluence/display/KAFKA/KIP-392:+Allow+consumers+to+fetch+from+closest+replica).
Weitere Informationen zu Apache Kafka Version 2.4.1 finden Sie in den [Versionshinweisen](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) auf der Download-Seite von Apache Kafka.
# Unterstützung für Amazon MSK-Versionen
In diesem Thema werden die [Support-Richtlinie für Amazon MSK-Versionen](#version-support-policy) und das Verfahren für [Aktualisieren Sie die Apache Kafka-Version](version-upgrades.md) beschrieben. Wenn Sie Ihre Kafka-Version aktualisieren, befolgen Sie die unter beschriebenen bewährten Methoden. [Bewährte Methoden für Versionsupgrades](version-upgrades-best-practices.md)
**Topics**
+ [Support-Richtlinie für Amazon MSK-Versionen](#version-support-policy)
+ [Aktualisieren Sie die Apache Kafka-Version](version-upgrades.md)
+ [Bewährte Methoden für Versionsupgrades](version-upgrades-best-practices.md)
## Support-Richtlinie für Amazon MSK-Versionen
In diesem Abschnitt werden die Support-Richtlinien für von Amazon MSK unterstützte Kafka-Versionen beschrieben.
+ Alle Kafka-Versionen werden bis zum Ende des Supports unterstützt. Einzelheiten zu den Terminen, an denen der Support endet, finden Sie unter[Unterstützte Apache Kafka-Versionen](supported-kafka-versions.md). Führen Sie vor Ablauf des Supportzeitraums ein Upgrade Ihres MSK-Clusters auf die empfohlene Kafka-Version oder eine höhere Version durch. Einzelheiten zum Upgrade Ihrer Apache Kafka-Version finden Sie unter. [Aktualisieren Sie die Apache Kafka-Version](version-upgrades.md) Ein Cluster, der nach Ablauf des Supports eine Kafka-Version verwendet, wird automatisch auf die empfohlene Kafka-Version aktualisiert. Automatische Upgrades können jederzeit nach Ablauf des Supports erfolgen. Sie erhalten vor dem Upgrade keine Benachrichtigung.
+ MSK wird die Unterstützung für neu erstellte Cluster, die Kafka-Versionen verwenden, auslaufen lassen, wobei das Ende des Supports veröffentlicht wurde.
# Aktualisieren Sie die Apache Kafka-Version
Sie können einen vorhandenen MSK-Cluster auf eine neuere Version von Apache Kafka aktualisieren. Stellen Sie vor dem Upgrade der Kafka-Version Ihres Clusters sicher, dass die Version Ihrer clientseitigen Software die Funktionen der neuen Kafka-Version unterstützt.
Informationen darüber, wie Sie einen Cluster während eines Upgrades hochverfügbar machen können, finden Sie unter. [Erstellen hochverfügbarer Cluster](bestpractices.md#ensure-high-availability)
**Aktualisieren Sie die Apache Kafka-Version mit dem AWS-Managementkonsole**
1. Öffnen Sie die Amazon-MSK-Konsole unter [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Wählen Sie in der Navigationsleiste die Region aus, in der Sie den MSK-Cluster erstellt haben.
1. Wählen Sie den MSK-Cluster aus, den Sie aktualisieren möchten.
1. Wählen Sie auf der Registerkarte **Eigenschaften** im Abschnitt **Apache Kafka-Version** die Option **Upgrade** aus.
1. Gehen Sie im Abschnitt **Apache Kafka-Version** wie folgt vor:
1. *Wählen Sie in der Dropdownliste Apache Kafka-Version* auswählen die Zielversion aus, auf die Sie ein Upgrade durchführen möchten. Wählen Sie zum Beispiel aus **3.9.x**.
1. (Optional) Wählen Sie **Versionskompatibilität anzeigen**, um die Kompatibilität zwischen der aktuellen Version Ihres Clusters und den verfügbaren Upgrade-Versionen zu überprüfen. Wählen Sie dann **Auswählen** aus, um fortzufahren.
**Anmerkung**
Amazon MSK unterstützt direkte Upgrades auf die meisten Apache Kafka-Versionen. Wenn Sie jedoch von einer ZooKeeper basierten Kafka-Version auf eine KRaft basierte Version aktualisieren, müssen Sie einen neuen Cluster erstellen. Kopieren Sie dann Ihre Daten in den neuen Cluster und wechseln Sie mit den Clients zum neuen Cluster.
1. (Optional) Aktivieren Sie das Kontrollkästchen **Clusterkonfiguration aktualisieren**, um mit der neuen Version kompatible Konfigurationsupdates anzuwenden. Dadurch werden die Funktionen und Verbesserungen der neuen Version aktiviert.
Sie können diesen Schritt überspringen, wenn Sie Ihre vorhandenen benutzerdefinierten Konfigurationen beibehalten müssen.
**Anmerkung**
Bei serverseitigen Upgrades werden Client-Anwendungen nicht automatisch aktualisiert.
Um die Clusterstabilität aufrechtzuerhalten, werden Versions-Downgrades nicht unterstützt.
1. Wählen Sie **Upgrade**, um den Vorgang zu starten.
**Aktualisieren Sie die Apache Kafka-Version mit dem AWS CLI**
1. Führen Sie den folgenden Befehl aus und *ClusterArn* ersetzen Sie ihn durch den Amazon-Ressourcennamen (ARN), den Sie bei der Erstellung Ihres Clusters erhalten haben. Wenn Ihnen der ARN für Ihren Cluster nicht vorliegt, finden Sie ihn, indem Sie alle Cluster auflisten. Weitere Informationen finden Sie unter [Amazon MSK-Cluster auflisten](msk-list-clusters.md).
```
aws kafka get-compatible-kafka-versions --cluster-arn ClusterArn
```
Die Ausgabe dieses Befehls enthält eine Liste der Apache Kafka-Versionen, auf die Sie den Cluster aktualisieren können. Es sollte wie das folgende Beispiel aussehen.
```
{
"CompatibleKafkaVersions": [
{
"SourceVersion": "2.2.1",
"TargetVersions": [
"2.3.1",
"2.4.1",
"2.4.1.1",
"2.5.1"
]
}
]
}
```
1. Führen Sie den folgenden Befehl aus und *ClusterArn* ersetzen Sie ihn durch den Amazon-Ressourcennamen (ARN), den Sie bei der Erstellung Ihres Clusters erhalten haben. Wenn Ihnen der ARN für Ihren Cluster nicht vorliegt, finden Sie ihn, indem Sie alle Cluster auflisten. Weitere Informationen finden Sie unter [Amazon MSK-Cluster auflisten](msk-list-clusters.md).
*Current-Cluster-Version*Ersetzen Sie durch die aktuelle Version des Clusters. Denn *TargetVersion* Sie können eine der Zielversionen aus der Ausgabe des vorherigen Befehls angeben.
**Wichtig**
Cluster-Versionen sind keine einfachen Ganzzahlen. Verwenden Sie den Befehl [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operation oder [describe-cluster, um die aktuelle Version des Clusters](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html) AWS CLI zu finden. `KTVPDKIKX0DER` ist ein Beispiel für eine Version.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version TargetVersion
```
Die Ausgabe des Befehls sieht wie das folgende JSON aus.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. Um das Ergebnis des `update-cluster-kafka-version` Vorgangs zu erhalten, führen Sie den folgenden Befehl aus und *ClusterOperationArn* ersetzen Sie ihn durch den ARN, den Sie in der Ausgabe des `update-cluster-kafka-version` Befehls erhalten haben.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
Die Ausgabe dieses `describe-cluster-operation`-Befehls sieht wie das folgende JSON-Beispiel aus.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "62cd41d2-1206-4ebf-85a8-dbb2ba0fe259",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2021-03-11T20:34:59.648000+00:00",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_IN_PROGRESS",
"OperationSteps": [
{
"StepInfo": {
"StepStatus": "IN_PROGRESS"
},
"StepName": "INITIALIZE_UPDATE"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "UPDATE_APACHE_KAFKA_BINARIES"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "FINALIZE_UPDATE"
}
],
"OperationType": "UPDATE_CLUSTER_KAFKA_VERSION",
"SourceClusterInfo": {
"KafkaVersion": "2.4.1"
},
"TargetClusterInfo": {
"KafkaVersion": "2.6.1"
}
}
}
```
Wenn `OperationState` den Wert „`UPDATE_IN_PROGRESS`“ aufweist, warten Sie eine Weile, bevor Sie den `describe-cluster-operation`-Befehl erneut ausführen. Wenn der Vorgang abgeschlossen ist, erhält `OperationState` den Wert `UPDATE_COMPLETE`. Da die Zeit, die Amazon MSK benötigt, um den Vorgang abzuschließen, unterschiedlich ist, müssen Sie dies möglicherweise wiederholt überprüfen, bis der Vorgang abgeschlossen ist.
**Aktualisieren Sie die Apache Kafka-Version mithilfe der API**
1. Rufen Sie den [GetCompatibleKafkaVersions](https://docs.aws.amazon.com//msk/1.0/apireference/compatible-kafka-versions.html#GetCompatibleKafkaVersions)Vorgang auf, um eine Liste der Apache Kafka-Versionen abzurufen, auf die Sie den Cluster aktualisieren können.
1. Rufen Sie den [UpdateClusterKafkaVersion](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-version.html#UpdateClusterKafkaVersion)Vorgang auf, um den Cluster auf eine der kompatiblen Apache Kafka-Versionen zu aktualisieren.
# Bewährte Methoden für Versionsupgrades
Um die Kontinuität der Clients während des fortlaufenden Updates sicherzustellen, das im Rahmen des Kafka-Versionsupgrade-Prozesses durchgeführt wird, sollten Sie die Konfiguration Ihrer Clients und die Themen zu Apache Kafka wie folgt überprüfen:
+ Stellen Sie den Themenreplikationsfaktor (RF) auf einen Mindestwert von `2` für Zwei-AZ-Cluster und einen Mindestwert von `3` für Drei-AZ-Cluster ein. Ein RF-Wert von `2` kann dazu führen, dass Partitionen während des Patchens offline sind.
+ Stellen Sie die Mindestanzahl an synchronisierten Replikaten (minISR) auf einen Höchstwert ein, der um 1 unter Ihrem Replikationsfaktor (RF) liegt, d. h. `miniISR = (RF) - 1` Dadurch wird sichergestellt, dass der Partitionsreplikatsatz tolerieren kann, dass ein Replikat offline ist oder zu wenig repliziert wird.
+ Konfigurieren Sie Clients so, dass sie mehrere Broker-Verbindungszeichenfolgen verwenden. Wenn die Verbindungszeichenfolge eines Clients mehrere Broker enthält, ist ein Failover möglich, falls ein bestimmter Broker, der den Client unterstützt, I/O mit dem Patchen beginnt. Informationen zum [Abrufen einer Verbindungszeichenfolge mit mehreren Brokern finden Sie unter Bootstrap-Broker für einen Amazon MSK-Cluster](https://docs.aws.amazon.com//msk/latest/developerguide/msk-get-bootstrap-brokers.html) abrufen.
+ Wir empfehlen, die Verbindungsclients auf die empfohlene Version oder höher zu aktualisieren, um von den Funktionen der neuen Version zu profitieren. Client-Upgrades unterliegen nicht dem Ende der Lebensdauer (EOL) der Kafka-Version Ihres MSK-Clusters und müssen auch nicht bis zum EOL-Datum abgeschlossen sein. Apache Kafka bietet eine [bidirektionale Client-Kompatibilitätsrichtlinie](https://kafka.apache.org/protocol#protocol_compatibility), die es älteren Clients ermöglicht, mit neueren Clustern zu arbeiten und umgekehrt.
+ Kafka-Clients, die die Versionen 3.x.x verwenden, verfügen wahrscheinlich über die folgenden Standardwerte: und. `acks=all` `enable.idempotence=true` `acks=all`unterscheidet sich von der vorherigen Standardeinstellung von `acks=1` und bietet zusätzliche Haltbarkeit, indem sichergestellt wird, dass alle synchronisierten Replikate die Produktionsanforderung bestätigen. In ähnlicher Weise `enable.idempotence` war die Standardeinstellung für zuvor. `false` Die Änderung `enable.idempotence=true` zur Standardeinstellung verringert die Wahrscheinlichkeit doppelter Nachrichten. Diese Änderungen gelten als bewährte Einstellungen und können zu einer geringen zusätzlichen Latenz führen, die innerhalb der normalen Leistungsparameter liegt.
+ Verwenden Sie die empfohlene Kafka-Version, wenn Sie neue MSK-Cluster erstellen. Wenn Sie die empfohlene Kafka-Version verwenden, können Sie von den neuesten Kafka- und MSK-Funktionen profitieren.
# Problembehandlung bei Ihrem Amazon MSK-Cluster
Die folgenden Informationen können zum Beheben von Problemen mit Ihrem Amazon-MSK-Cluster nützlich sein. Sie können Ihr Problem auch im [AWS re:Post](https://repost.aws/) posten. Informationen zur Fehlerbehebung bei Amazon MSK Replicator finden Sie unter. [Problembehandlung bei MSK Replicator](msk-replicator-troubleshooting.md)
**Topics**
+ [Der Austausch eines Volumes führt aufgrund einer Überlastung der Replikation zu einer Überlastung der Festplatte](#replication-overload-disk-saturation)
+ [Verbrauchergruppe steckt im Status `PreparingRebalance` fest](#consumer-group-rebalance)
+ [Fehler beim Senden von Broker-Protokollen an Amazon CloudWatch Logs](#cw-broker-logs-error)
+ [Keine Standard-Sicherheitsgruppe](#troubleshooting-shared-vpc)
+ [Der Cluster steckt anscheinend im Status „CREATING“ fest.](#troubleshooting-cluster-stuck)
+ [Der Cluster-Status wird von „CREATING“ in „FAILED“ geändert.](#troubleshooting-cluster-failed)
+ [Der Cluster-Status ist „ACTIVE“, Produzenten können jedoch keine Daten senden oder Konsumenten können keine Daten empfangen.](#troubleshooting-nodata)
+ [AWS CLI erkennt Amazon MSK nicht](#troubleshooting-nocli)
+ [Partitionen werden auf „offline“ festgelegt oder Replikate sind nicht synchronisiert.](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [Wenig Speicherplatz](#troubleshooting-lowdiskspace)
+ [Wenig Arbeitsspeicher](#troubleshooting-lowmemory)
+ [Der Produzent erhält NotLeaderForPartitionException](#troubleshooting-NotLeaderForPartitionException)
+ [Die unterreplizierten Partitionen (URP) sind größer als Null](#troubleshooting-urp)
+ [Der Cluster hat die Themen \$1\$1amazon\$1msk\$1canary und \$1\$1amazon\$1msk\$1canary\$1state](#amazon_msk_canary)
+ [Die Partitionsreplikation schlägt fehl](#partition_replication_fails)
+ [Es kann nicht auf einen Cluster zugegriffen werden, für den der öffentliche Zugriff aktiviert ist](#public-access-issues)
+ [Über Bootstrap kann nicht auf den Cluster zugegriffen werden IPv6](#dualstack-issues)
+ [Von innen kann nicht auf den Cluster zugegriffen werden AWS: Netzwerkprobleme](#networking-trouble)
+ [Fehlgeschlagene Authentifizierung: Zu viele Verbindungen](#troubleshoot-too-many-connects)
+ [Authentifizierung fehlgeschlagen: Sitzung zu kurz](#troubleshoot-session-too-short)
+ [MSK Serverless: Die Cluster-Erstellung schlägt fehl](#troubleshoot-serverless-create-cluster-failure)
+ [Die MSK-Konfiguration kann nicht aktualisiert KafkaVersionsList werden](#troubleshoot-kafkaversionslist-cfn-update-failure)
## Der Austausch eines Volumes führt aufgrund einer Überlastung der Replikation zu einer Überlastung der Festplatte
Bei einem ungeplanten Ausfall der Volume-Hardware kann Amazon MSK das Volume durch eine neue Instance ersetzen. Kafka füllt das neue Volume erneut auf, indem es Partitionen von anderen Brokern im Cluster repliziert. Sobald Partitionen repliziert und aufgeholt wurden, kommen sie für eine Leadership- und ISR-Mitgliedschaft (In-Sync Replica) in Frage.
**Problem**
Bei einem Broker, der sich nach dem Austausch eines Volumes erholt, können einige Partitionen unterschiedlicher Größe vor anderen wieder online gehen. Dies kann problematisch sein, da diese Partitionen Datenverkehr von demselben Broker bereitstellen können, der immer noch andere Partitionen abholt (repliziert). Dieser Replikationsverkehr kann manchmal die zugrundeliegenden Volumendurchsatzgrenzen, die im Standardfall 250 MiB pro Sekunde betragen, sättigen. Wenn diese Sättigung eintritt, sind alle Partitionen betroffen, die bereits abgeholt wurden. Dies führt zu einer Latenz im gesamten Cluster bei allen Brokern, die ISR mit den aufgenommenen Partitionen teilen (nicht nur bei Leader-Partitionen aufgrund von Remote-Acks). `acks=all` Dieses Problem tritt häufiger bei größeren Clustern auf, die eine größere Anzahl von Partitionen mit unterschiedlicher Größe haben.
**Empfehlung**
+ Um den Status der Replikation I/O zu verbessern, stellen Sie sicher, dass die [Thread-Einstellungen nach bewährten](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads) Methoden vorhanden sind.
+ Um die Wahrscheinlichkeit einer zugrundeliegenden Volumensättigung zu verringern, sollten Sie bereitgestellten Speicher mit einem höheren Durchsatz aktivieren. Für Replikationsfälle mit hohem Durchsatz MiB/s wird ein Mindestdurchsatz von 500 empfohlen. Der tatsächlich benötigte Wert hängt jedoch vom Durchsatz und vom Anwendungsfall ab. [Bereitstellung von Speicherdurchsatz für Standard-Broker in einem Amazon MSK-Cluster](msk-provision-throughput.md).
+ Um den Replikationsdruck `num.replica.fetchers` zu minimieren, senken Sie den Wert auf den Standardwert von`2`.
## Verbrauchergruppe steckt im Status `PreparingRebalance` fest
Wenn sich eine oder mehrere Ihrer Verbrauchergruppen in einem Zustand der ständigen Neuausrichtung befinden, kann dies am Apache-Kafka-Problem [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752) liegen, das die Apache-Kafka-Versionen 2.3.1 und 2.4.1 betrifft.
Um dieses Problem zu beheben, empfehlen wir Ihnen, Ihren Cluster auf die Version [Amazon-MSK-Bugfix Version 2.4.1.1](supported-kafka-versions.md#2.4.1.1) zu aktualisieren, die eine Lösung für dieses Problem enthält. Informationen zur Aktualisierung eines vorhandenen Clusters auf die Amazon-MSK-Bugfix-Version 2.4.1.1 finden Sie unter [Aktualisieren Sie die Apache Kafka-Version](version-upgrades.md).
Um dieses Problem zu lösen, ohne den Cluster auf die Bug-Fix-Version 2.4.1.1 des Amazon MSK zu aktualisieren, müssen Sie entweder die Kafka-Clients für die Verwendung von [Static-Membership-Protokoll](#consumer-group-rebalance-static) einrichten oder den koordinierenden Broker-Knoten der festgefahrenen Verbrauchergruppe auf [Identifizieren und neu starten](#consumer-group-rebalance-reboot) einstellen.
### Implementierung des Static-Membership-Protokolls
Gehen Sie folgendermaßen vor, um das Static-Membership-Protokoll in Ihren Clients zu implementieren:
1. Setzen Sie die `group.instance.id`-Eigenschaft Ihrer [Kafka-Verbraucher](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html)-Konfiguration auf eine statische Zeichenfolge, die den Verbraucher in der Gruppe identifiziert.
1. Stellen Sie sicher, dass andere Instances der Konfiguration aktualisiert werden, sodass sie die statische Zeichenfolge verwenden.
1. Stellen Sie die Änderungen für Ihre Kafka-Verbraucher bereit.
Die Verwendung des Static Membership Protocol ist effektiver, wenn das Sitzungs-Timeout in der Client-Konfiguration auf eine Dauer festgelegt ist, die es dem Verbraucher ermöglicht, sich zu erholen, ohne vorzeitig eine Neuverteilung der Verbrauchergruppen auszulösen. Wenn Ihre Verbraucheranwendung beispielsweise eine Nichtverfügbarkeit von 5 Minuten toleriert, wäre ein angemessener Wert für das Sitzungs-Timeout 4 Minuten anstelle des Standardwerts von 10 Sekunden.
**Anmerkung**
Die Verwendung des Static-Membership-Protokolls verringert nur die Wahrscheinlichkeit, dass dieses Problem auftritt. Dieses Problem kann auch dann auftreten, wenn Sie das Static-Membership-Protokoll verwenden.
### Den koordinierenden Broker-Knoten neu starten
Gehen Sie wie folgt vor, um den koordinierenden Broker-Knoten neu zu starten:
1. Identifizieren Sie den Gruppenkoordinator mithilfe des Befehls `kafka-consumer-groups.sh`.
1. Starten Sie den Gruppenkoordinator der festgefahrenen Nutzergruppe mithilfe der [ RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker)API-Aktion neu.
## Fehler beim Senden von Broker-Protokollen an Amazon CloudWatch Logs
Wenn Sie versuchen, Ihren Cluster so einzurichten, dass er Broker-Logs an Amazon CloudWatch Logs sendet, kann es zu einer von zwei Ausnahmen kommen.
Wenn Sie die Ausnahme `InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded` erhalten, wiederholen Sie den Vorgang, verwenden jedoch Protokollgruppen, die mit `/aws/vendedlogs/` beginnen. Weitere Informationen finden Sie unter [Aktivieren der Protokollierung aus bestimmten Amazon Web Services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html).
Wenn Sie eine `InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded` Ausnahme erhalten, wählen Sie eine bestehende Amazon CloudWatch Logs-Richtlinie in Ihrem Konto aus und hängen Sie die folgende JSON-Datei an.
```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```
Wenn Sie versuchen, den obigen JSON-Code an eine bestehende Richtlinie anzuhängen, aber eine Fehlermeldung erhalten, die besagt, dass Sie die maximale Länge für die von Ihnen gewählte Richtlinie erreicht haben, versuchen Sie, den JSON an eine andere Ihrer Amazon CloudWatch Logs-Richtlinien anzuhängen. Nachdem Sie das JSON an eine bestehende Richtlinie angehängt haben, versuchen Sie erneut, die Broker-Log-Übermittlung an Amazon Logs einzurichten. CloudWatch
## Keine Standard-Sicherheitsgruppe
Wenn Sie versuchen, einen Cluster zu erstellen und einen Fehler über das Fehlen einer Standardsicherheitsgruppe erhalten, verwenden Sie möglicherweise eine VPC, die für Sie freigegeben wurde. Bitten Sie Ihren Administrator, Ihnen die Berechtigung zur Beschreibung der Sicherheitsgruppen auf dieser VPC zu erteilen, und versuchen Sie es erneut. Ein Beispiel für eine Richtlinie, die diese Aktion zulässt, finden Sie unter [Amazon EC2: Ermöglicht es, die mit einer bestimmten VPC verknüpften EC2-Sicherheitsgruppen programmgesteuert und in der Konsole zu verwalten ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html).
## Der Cluster steckt anscheinend im Status „CREATING“ fest.
Gelegentlich dauert die Cluster-Erstellung bis zu 30 Minuten. Warten Sie 30 Minuten und überprüfen Sie den Status des Clusters erneut.
## Der Cluster-Status wird von „CREATING“ in „FAILED“ geändert.
Versuchen Sie erneut, den Cluster zu erstellen.
## Der Cluster-Status ist „ACTIVE“, Produzenten können jedoch keine Daten senden oder Konsumenten können keine Daten empfangen.
+ Wenn die Cluster-Erstellung erfolgreich ist (der Cluster-Status lautet „`ACTIVE`“), Sie jedoch keine Daten senden oder empfangen können, stellen Sie sicher, dass Ihre Produzenten- und Konsumentenanwendungen auf den Cluster zugreifen können. Weitere Informationen finden Sie in der Anleitung in [Schritt 3: Einen Client-Computer erstellen](create-client-machine.md).
+ Wenn Ihre Produzenten und Konsumenten auf den Cluster zugreifen können, aber immer noch Probleme beim Erstellen und Nutzen von Daten auftreten, könnte dies durch [KAFKA-7697](https://issues.apache.org/jira/browse/KAFKA-7697) verursacht werden. Dies wirkt sich auf Apache Kafka Version 2.1.0 aus und kann zu einem Deadlock in einem oder mehreren Brokern führen. Ziehen Sie eine Migration zu Apache Kafka 2.2.1 in Betracht. Diese Version ist von diesem Fehler nicht betroffen. Weitere Informationen zur Migration finden Sie unter [Migrieren Sie Kafka-Workloads zu einem Amazon MSK-Cluster](migration.md).
## AWS CLI erkennt Amazon MSK nicht
Wenn Sie das AWS CLI installiert haben, es aber die Amazon MSK-Befehle nicht erkennt, führen Sie ein Upgrade AWS CLI auf die neueste Version durch. Detaillierte Anweisungen zum Upgrade von finden Sie AWS CLI unter [Installation von](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html). AWS Command Line Interface Informationen zur Verwendung der Befehle AWS CLI zum Ausführen von Amazon MSK-Befehlen finden Sie unter[Die wichtigsten Funktionen und Konzepte von Amazon MSK](operations.md).
## Partitionen werden auf „offline“ festgelegt oder Replikate sind nicht synchronisiert.
Dies können Anzeichen von wenig Speicherplatz sein. Siehe [Wenig Speicherplatz](#troubleshooting-lowdiskspace).
## Wenig Speicherplatz
Lesen Sie die folgenden bewährten Methoden für die Verwaltung des Speicherplatzes: [Überwachen der Festplattenkapazität](bestpractices.md#bestpractices-monitor-disk-space) und [Anpassen der Datenaufbewahrungsparameter](bestpractices.md#bestpractices-retention-period).
## Wenig Arbeitsspeicher
Wenn Sie sehen, dass die `MemoryUsed`-Metrik hoch oder `MemoryFree` niedrig ist, deutet das nicht auf ein Problem hin. Apache Kafka wurde entwickelt, um so viel Speicher wie möglich zu verwenden, und es verwaltet ihn optimal.
## Der Produzent erhält NotLeaderForPartitionException
Dies ist oft ein vorübergehender Fehler. Legen Sie den `retries`-Konfigurationsparameter des Produzenten auf einen Wert fest, der höher als sein aktueller Wert ist.
## Die unterreplizierten Partitionen (URP) sind größer als Null
Die Überwachung der `UnderReplicatedPartitions`-Metrik ist wichtig. In einem fehlerfreien MSK-Cluster weist diese Metrik den Wert „0“ auf. Der Wert kann aus Folgenden Gründen größer als Null sein.
+ Falls es zu Spitzenwerten bei `UnderReplicatedPartitions` kommt, wird der Cluster möglicherweise nicht in der richtigen Größe für die Verarbeitung von eingehendem und ausgehendem Datenverkehr bereitgestellt. Siehe [Bewährte Methoden für Standardbroker](bestpractices.md).
+ Wenn der `UnderReplicatedPartitions` Wert durchweg größer als 0 ist, auch in Zeiten mit geringem Besucheraufkommen, liegt das Problem möglicherweise daran, dass Sie Einschränkungen festgelegt haben ACLs , sodass Maklern kein Zugriff auf das Thema gewährt wird. Zum Replizieren von Partitionen müssen Broker für die Themen „READ“ und „DESCRIBE“ autorisiert sein. „DESCRIBE“ wird standardmäßig mit der „READ“-Autorisierung erteilt. Informationen zur Einstellung ACLs finden Sie unter [Autorisierung und ACLs](https://kafka.apache.org/documentation/#security_authz) in der Apache Kafka-Dokumentation.
## Der Cluster hat die Themen \$1\$1amazon\$1msk\$1canary und \$1\$1amazon\$1msk\$1canary\$1state
Möglicherweise sehen Sie, dass Ihr MSK-Cluster ein Thema mit dem Namen `__amazon_msk_canary` und ein anderes mit dem Namen `__amazon_msk_canary_state` hat. Dies sind interne Themen, die Amazon MSK erstellt und für Metriken zum Cluster-Zustand und zur Diagnose verwendet. Diese Themen haben eine vernachlässigbare Größe und können nicht gelöscht werden.
## Die Partitionsreplikation schlägt fehl
Stellen Sie sicher, dass Sie CLUSTER\$1ACTIONS nicht ACLs aktiviert haben.
## Es kann nicht auf einen Cluster zugegriffen werden, für den der öffentliche Zugriff aktiviert ist
Wenn für Ihren Cluster der öffentliche Zugriff aktiviert ist, Sie aber immer noch nicht über das Internet darauf zugreifen können, gehen Sie wie folgt vor:
1. Stellen Sie sicher, dass die Regeln der Sicherheitsgruppe für eingehenden Datenverkehr Ihre IP-Adresse und den Port des Clusters erlauben. Eine Liste der Cluster-Portnummern finden Sie unter [Port-Informationen](port-info.md). Stellen Sie außerdem sicher, dass die Regeln für ausgehenden Datenverkehr der Sicherheitsgruppe ausgehende Kommunikation zulassen. Weitere Informationen zu Sicherheitsgruppen und Regeln für eingehenden und ausgehenden Datenverkehr finden Sie unter [Sicherheitsgruppen für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) im Amazon-VPC-Benutzerhandbuch.
1. Stellen Sie sicher, dass Ihre IP-Adresse und der Port des Clusters in den Regeln für eingehenden Datenverkehr der VPC-Netzwerk-ACL des Clusters zulässig sind. Im Gegensatz zu Sicherheitsgruppen sind Netzwerke zustandslos ACLs . Dies bedeutet, dass Sie die Regeln für den ein- und ausgehenden Datenverkehr konfigurieren müssen. Erlauben Sie in den Regeln für ausgehenden Datenverkehr den gesamten Datenverkehr (Portbereich: 0–65535) zu Ihrer IP-Adresse zu. Weitere Informationen finden Sie unter [Hinzufügen und Löschen von Regeln](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules) im Amazon-VPC-Benutzerhandbuch.
1. Stellen Sie sicher, dass Sie die Bootstrap-Brokers-Zeichenfolge mit öffentlichem Zugriff für den Zugriff auf den Cluster verwenden. Ein MSK-Cluster, für den der öffentliche Zugriff aktiviert ist, hat zwei verschiedene Bootstrap-Broker-Zeichenfolgen, eine für den öffentlichen Zugriff und eine für den Zugriff innerhalb AWS. Weitere Informationen finden Sie unter [Holen Sie sich die Bootstrap-Broker mit dem AWS-Managementkonsole](get-bootstrap-console.md).
## Über Bootstrap kann nicht auf den Cluster zugegriffen werden IPv6
Wenn Sie Probleme haben, mithilfe der bereitgestellten IPv6 Bootstrap-Zeichenfolgen eine Verbindung zu einem Cluster herzustellen, gehen Sie wie folgt vor:
1. Stellen Sie sicher, dass Ihrem Client sowohl IPv4- als auch IPv6-Adressen zugewiesen sind. Ihre Client-Anwendung muss in einem Subnetz ausgeführt werden, in dem sowohl die IPv4- als auch die IPv6-Adressierung aktiviert und ordnungsgemäß konfiguriert sind. Prüfen Sie, ob Ihre VPC sowohl über einen IPv4-CIDR-Block als auch über einen zugehörigen IPv6-CIDR-Block verfügt, stellen Sie sicher, dass in Ihrem Subnetz sowohl IPv4- als auch IPv6-Adressen aktiviert sind, und stellen Sie sicher, dass Ihrer EC2-Instance oder Client-Umgebung beide Adressen zugewiesen sind. IPv4 IPv6 Weitere Informationen finden Sie unter [IP-Adressierung für Ihre VPCs und Subnetze](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) im Amazon VPC-Benutzerhandbuch.
1. Stellen Sie sicher, dass die entsprechenden IPv6 Ports in den Regeln für eingehenden und ausgehenden Datenverkehr der Sicherheitsgruppe enthalten sind. Fügen Sie Regeln für eingehenden Datenverkehr von Ihren IPv6 Adressen auf den Cluster-Ports hinzu, und konfigurieren Sie Regeln für ausgehenden Datenverkehr, um Datenverkehr zuzulassen. IPv6 Spezifische Portnummern finden Sie in der MSK-Dokumentation unter [Portinformationen](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html). Denken Sie daran, IPv4 sowohl als auch die IPv6 Regeln zu aktualisieren, wenn Sie im Dual-Stack-Modus arbeiten. Weitere Informationen zu Sicherheitsgruppen und Regeln für eingehenden und ausgehenden Datenverkehr finden Sie unter [Sicherheitsgruppen für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) im Amazon-VPC-Benutzerhandbuch.
1. Stellen Sie sicher, dass die Konfiguration der JVM-Eigenschaften für IPv6 die Unterstützung korrekt ist. Stellen Sie in Ihrer Client-Anwendung `java.net.preferIPv6Addresses` auf `true` und `java.net.preferIPv4Stack` auf `false` ein. Diese Einstellungen können entweder als Systemeigenschaften oder als JVM-Argumente konfiguriert werden. Starten Sie Ihre Anwendung neu, nachdem Sie diese Änderungen vorgenommen haben, damit sie wirksam werden.
## Von innen kann nicht auf den Cluster zugegriffen werden AWS: Netzwerkprobleme
Wenn Sie über eine Apache-Kafka-Anwendung verfügen, die nicht erfolgreich mit einem MSK-Cluster kommunizieren kann, führen Sie zunächst den folgenden Konnektivitätstest durch.
1. Verwenden Sie eine der in [Holen Sie sich die Bootstrap-Broker für einen Amazon MSK-Cluster](msk-get-bootstrap-brokers.md) beschriebenen Methoden, um die Adressen der Bootstrap-Broker zu erhalten.
1. Ersetzen Sie im folgenden Befehl *bootstrap-broker* durch eine der Brokeradressen, die Sie im vorherigen Schritt erhalten haben. *port-number*Ersetzen Sie es durch 9094, wenn der Cluster für die Verwendung der TLS-Authentifizierung eingerichtet ist. Wenn der Cluster keine TLS-Authentifizierung verwendet, *port-number* ersetzen Sie ihn durch 9092. Führen Sie den Befehl vom Clientcomputer aus.
```
telnet bootstrap-broker port-number
```
Wobei die Portnummer wie folgt lautet:
+ 9094, wenn der Cluster für die Verwendung der TLS-Authentifizierung eingerichtet ist.
+ 9092 Wenn der Cluster keine TLS-Authentifizierung verwendet.
+ Eine andere Portnummer ist erforderlich, wenn der öffentliche Zugriff aktiviert ist.
Führen Sie den Befehl vom Clientcomputer aus.
1. Wiederholen Sie den vorherigen Befehl für alle Bootstrap-Broker.
Wenn der Client-Computer auf die Broker zugreifen kann, bedeutet dies, dass keine Verbindungsprobleme vorliegen. Führen Sie in diesem Fall den folgenden Befehl aus, um zu überprüfen, ob Ihr Apache Kafka Client korrekt eingerichtet ist. Verwenden Sie *bootstrap-brokers* dazu eine der unter beschriebenen Methoden[Holen Sie sich die Bootstrap-Broker für einen Amazon MSK-Cluster](msk-get-bootstrap-brokers.md). *topic*Ersetzen Sie es durch den Namen Ihres Themas.
```
/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```
Wenn der vorherige Befehl erfolgreich ist, bedeutet dies, dass Ihr Client korrekt eingerichtet ist. Wenn Sie immer noch nicht in der Lage sind, aus einer Anwendung zu produzieren und zu konsumieren, debuggen Sie das Problem auf Anwendungsebene.
Wenn der Client-Computer nicht auf die Broker zugreifen kann, finden Sie in den folgenden Unterabschnitten Anleitungen, die auf Ihrem Client-Computer-Setup basieren.
### Amazon-EC2-Client und MSK-Cluster in derselben VPC
Wenn sich der Client-Computer in derselben VPC wie der MSK-Cluster befindet, stellen Sie sicher, dass die Sicherheitsgruppe des Clusters über eine Regel für eingehenden Datenverkehr verfügt, die Datenverkehr von der Sicherheitsgruppe des Client-Computers akzeptiert. Informationen zum Einrichten dieser Regeln finden Sie unter [Sicherheitsgruppenregeln](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules). Ein Beispiel für den Zugriff auf einen Cluster von einer Amazon-EC2-Instance aus, die sich in derselben VPC wie der Cluster befindet, finden Sie unter [Erste Schritte mit Amazon MSK](getting-started.md).
### Amazon EC2 EC2-Client und MSK-Cluster in verschiedenen VPCs
Wenn sich der Client-Computer und der Cluster in zwei verschiedenen Umgebungen befinden VPCs, stellen Sie Folgendes sicher:
+ Die beiden VPCs werden miteinander verbunden.
+ Der Status der Peering-Verbindung ist aktiv.
+ Die Routentabellen der beiden VPCs sind korrekt eingerichtet.
Weitere Informationen zum VPC-Peering finden Sie unter [Arbeiten mit VPC-Peering-Verbindungen](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html).
### On-Premises-Client
Stellen Sie bei einem lokalen Client, der so eingerichtet ist, dass er eine Verbindung zum MSK-Cluster herstellt Site-to-Site VPN, Folgendes sicher:
+ Der VPN-Verbindungsstatus lautet `UP`. Informationen zum Überprüfen des VPN-Verbindungsstatus finden Sie unter [Wie überprüfe ich den aktuellen Status meines VPN-Tunnels?](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/).
+ Die Routingtabelle der VPC des Clusters enthält die Route für einen On-Premises-CIDR, dessen Ziel das Format `Virtual private gateway(vgw-xxxxxxxx)` aufweist.
+ Die Sicherheitsgruppe des MSK-Clusters erlaubt Datenverkehr auf Port 2181, Port 9092 (wenn Ihr Cluster Nur-Text-Datenverkehr akzeptiert) und Port 9094 (wenn Ihr Cluster TLS-verschlüsselten Datenverkehr akzeptiert).
Weitere Anleitungen Site-to-Site VPN zur Fehlerbehebung finden Sie unter [Fehlerbehebung bei Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html).
### Direct Connect
Wenn der Client verwendet Direct Connect, finden Sie weitere Informationen unter [Problembehandlung Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html).
Wenn die vorherige Anleitung zur Fehlerbehebung das Problem nicht beheben kann, stellen Sie sicher, dass keine Firewall den Netzwerkverkehr blockiert. Verwenden Sie zum weiteren Debuggen Tools wie `tcpdump` und `Wireshark` zum Analysieren des Datenverkehrs und stellen Sie sicher, dass er den MSK-Cluster erreicht.
## Fehlgeschlagene Authentifizierung: Zu viele Verbindungen
Der Fehler `Failed authentication ... Too many connects` weist darauf hin, dass ein Broker sich selbst schützt, weil ein oder mehrere IAM-Clients mit einer aggressiv-schnellen Rate versuchen, eine Verbindung zu ihm herzustellen. Um Brokern zu helfen, eine höhere Rate neuer IAM-Verbindungen zu akzeptieren, können Sie den Konfigurationsparameter [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms) erhöhen.
Weitere Informationen zu den Ratenlimits für neue Verbindungen pro Broker finden Sie auf der [Amazon-MSK-Kontingent](limits.md)-Seite.
## Authentifizierung fehlgeschlagen: Sitzung zu kurz
Der `Failed authentication ... Session too short` Fehler tritt auf, wenn Ihr Client versucht, mithilfe von IAM-Anmeldeinformationen, die bald ablaufen, eine Verbindung zu einem Cluster herzustellen. Stellen Sie sicher, dass Sie überprüfen, wie Ihre IAM-Anmeldeinformationen aktualisiert werden. Höchstwahrscheinlich werden die Anmeldeinformationen zu kurz vor Ablauf der Sitzung ersetzt, was zu Problemen auf der Serverseite und Authentifizierungsfehlern führt.
## MSK Serverless: Die Cluster-Erstellung schlägt fehl
Wenn Sie versuchen, einen MSK-Serverless-Cluster zu erstellen, und der Workflow fehlschlägt, sind Sie möglicherweise nicht berechtigt, einen VPC-Endpunkt zu erstellen. Stellen Sie sicher, dass Ihr Administrator Ihnen die Berechtigung erteilt hat, einen VPC-Endpunkt zu erstellen, indem Sie die `ec2:CreateVpcEndpoint`-Aktion zulassen.
Eine vollständige Liste der Berechtigungen, die für die Ausführung aller Amazon-MSK-Aktionen erforderlich sind, finden Sie unter [AWS verwaltete Richtlinie: Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md).
## Die MSK-Konfiguration kann nicht aktualisiert KafkaVersionsList werden
Wenn Sie die [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist)Eigenschaft in der [AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html)Ressource aktualisieren, schlägt die Aktualisierung mit dem folgenden Fehler fehl.
```
Resource of type 'AWS::MSK::Configuration' with identifier '' already exists.
```
Wenn Sie die `KafkaVersionsList` Eigenschaft aktualisieren, AWS CloudFormation erstellt eine neue Konfiguration mit der aktualisierten Eigenschaft neu, bevor die alte Konfiguration gelöscht wird. Das CloudFormation Stack-Update schlägt fehl, weil die neue Konfiguration denselben Namen wie die bestehende Konfiguration verwendet. Ein solches Update erfordert einen [Ressourcenaustausch](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement). Für eine erfolgreiche Aktualisierung `KafkaVersionsList` müssen Sie im selben Vorgang auch die [Name-Eigenschaft](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) aktualisieren.
Wenn Ihre Konfiguration mit Clustern verknüpft ist, die mit AWS-Managementkonsole oder erstellt wurden AWS CLI, fügen Sie Ihrer Konfigurationsressource außerdem Folgendes hinzu, um [fehlgeschlagene Versuche beim Löschen von Ressourcen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted) zu verhindern.
```
UpdateReplacePolicy: Retain
```
Gehen Sie nach erfolgreicher Aktualisierung zur Amazon MSK-Konsole und löschen Sie die alte Konfiguration. Informationen zu MSK-Konfigurationen finden Sie unter [Bereitgestellte Amazon MSK-Konfiguration](msk-configuration.md).