Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Caratteristiche e concetti chiave di Amazon MSK
I cluster Amazon MSK Provisioned offrono un'ampia gamma di caratteristiche e funzionalità per aiutarti a ottimizzare le prestazioni del cluster e soddisfare le tue esigenze di streaming. Gli argomenti seguenti descrivono queste funzionalità in dettaglio.
+ La [Console di gestione AWS](https://console.aws.amazon.com/msk)
+ La [documentazione di riferimento all'API di Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference)
+ La [documentazione di riferimento ai comandi della CLI di Amazon MSK](https://docs.aws.amazon.com/cli/latest/reference/kafka/index.html)
**Topics**
+ [Tipi di broker Amazon MSK](broker-instance-types.md)
+ [Dimensioni dei broker Amazon MSK](broker-instance-sizes.md)
+ [Gestione dello storage per broker Standard](msk-storage-management.md)
+ [Configurazione Amazon MSK Provisioned](msk-configuration.md)
+ [Ribilanciamento intelligente per i cluster](intelligent-rebalancing.md)
+ [Applicazione di patch sui cluster MSK Provisioned](patching-impact.md)
+ [Broker offline e failover del client](troubleshooting-offlinebroker-clientfailover.md)
+ [Sicurezza in Amazon MSK](security.md)
+ [Registrazione Amazon MSK](msk-logging.md)
+ [Gestione dei metadati](metadata-management.md)
+ [Argomento Operazioni](msk-topic-operations-information.md)
+ [Risorse Amazon MSK](resources.md)
+ [Versioni di Apache Kafka](kafka-versions.md)
+ [Risolvi i problemi del tuo cluster Amazon MSK](troubleshooting.md)
# Tipi di broker Amazon MSK
MSK Provisioned offre due tipi di broker: Standard ed Express. I broker standard offrono la massima flessibilità per configurare i cluster, mentre i broker Express offrono maggiore elasticità, velocità effettiva e resilienza e ease-of-use per l'esecuzione di applicazioni di streaming ad alte prestazioni.
Per ulteriori dettagli su ciascuna offerta, consulta i seguenti argomenti. La tabella seguente evidenzia anche il confronto delle funzionalità chiave tra i broker Standard ed Express.
| Funzionalità | Broker standard | Broker espresso |
| --- | --- | --- |
| [Gestione dello storage](msk-storage-management.md) | Gestita dal cliente (le funzionalità includono storage EBS, storage su più livelli, throughput di storage fornito, scalabilità automatica, avvisi sulla capacità di storage) | Completamente gestito da MSK |
| [Istanze supportate](broker-instance-sizes.md) | T3, M5, M7g | M7g |
| [Considerazioni sul dimensionamento e sulla scalabilità](bestpractices-intro.md) | Velocità effettiva, connessioni, partizioni, archiviazione | Velocità effettiva, connessioni, partizioni |
| [Scalabilità dei broker](msk-update-broker-count.md) | Scalabilità verticale e orizzontale | Ridimensionamento verticale e orizzontale |
| [Versioni Kafka](kafka-versions.md) | Per informazioni, consultare [Versioni di Apache Kafka](kafka-versions.md). | Inizia dalla versione 3.6 |
| [Configurazione di Apache Kafka](msk-configuration.md) | Più configurabile | Principalmente MSK è gestito per una maggiore resilienza |
| [Sicurezza](security.md) | Crittografia, Private/Public accesso, autenticazione e autorizzazione: IAM, SASL/SCRAM, mTLS, testo in chiaro, Kafka ACLs | Crittografia, Private/Public accesso, autenticazione e autorizzazione: IAM, SASL/SCRAM, mTLS, testo in chiaro, Kafka ACLs |
| [Monitoraggio](monitoring.md) | CloudWatch, Monitoraggio aperto | CloudWatch, Monitoraggio aperto |
**Nota**
Non è possibile modificare un cluster MSK Provisioned da un tipo di broker Standard a un tipo di broker Express cambiando il tipo di broker utilizzando l'API MSK. È necessario creare un nuovo cluster con il tipo di broker desiderato (Standard o Express).
**Topics**
+ [Broker Amazon MSK Standard](msk-broker-types-standard.md)
+ [Broker Amazon MSK Express](msk-broker-types-express.md)
# Broker Amazon MSK Standard
I broker standard per MSK Provisioned offrono la massima flessibilità per configurare le prestazioni del cluster. È possibile scegliere tra un'ampia gamma di configurazioni di cluster per ottenere le caratteristiche di disponibilità, durabilità, velocità effettiva e latenza richieste per le applicazioni. È inoltre possibile fornire la capacità di storage e aumentarla in base alle esigenze. Amazon MSK gestisce la manutenzione hardware dei broker Standard e delle risorse di storage collegate, riparando automaticamente i problemi hardware che possono insorgere. [[Puoi trovare maggiori dettagli in questo documento su vari argomenti relativi ai broker Standard, inclusi argomenti sulla [gestione dello storage](msk-storage-management.md), le configurazioni e la manutenzione.](patching-impact.md#patching-standard-brokers)](msk-configuration-standard.md)
# Broker Amazon MSK Express
I broker Express per MSK Provisioned rendono Apache Kafka più semplice da gestire, più conveniente da eseguire su larga scala e più elastico grazie alla bassa latenza prevista. I broker includono uno pay-as-you-go storage scalabile automaticamente e che non richiede dimensionamento, provisioning o monitoraggio proattivo. A seconda della dimensione dell'istanza selezionata, ogni nodo del broker può fornire un throughput fino a 3 volte superiore per broker, scalare fino a 20 volte più velocemente e ripristinare il 90% più velocemente rispetto ai broker Apache Kafka standard. I broker Express sono preconfigurati con le best practice predefinite di Amazon MSK e applicano le quote di throughput dei clienti per ridurre al minimo la contesa di risorse tra i clienti e le operazioni in background di Kafka.
Ecco alcuni fattori e funzionalità chiave da considerare quando si utilizzano i broker Express.
+ **Nessuna gestione dello storage**: i broker Express eliminano la necessità di [fornire o gestire qualsiasi risorsa di storage](msk-storage-management.md). Ottieni uno storage elastico pay-as-you-go, praticamente illimitato e completamente gestito. Per i casi d'uso con throughput elevato, non è necessario ragionare sulle interazioni tra istanze di elaborazione e volumi di storage e sui relativi colli di bottiglia in termini di throughput. Queste funzionalità semplificano la gestione dei cluster ed eliminano il sovraccarico operativo della gestione dello storage.
+ **Scalabilità più rapida**: i broker Express consentono di scalare il cluster e spostare le partizioni fino a 20 volte più velocemente rispetto ai broker Standard. Questa funzionalità è fondamentale quando è necessario scalare il cluster per gestire i picchi di carico imminenti o scalare il cluster per ridurre i costi. Per maggiori dettagli sulla scalabilità del [cluster, consulta le sezioni sull'espansione](msk-update-broker-count.md) del cluster, la [rimozione dei broker](msk-remove-broker.md), la [riassegnazione delle partizioni](msk-update-broker-type.md) e [ LinkedInla configurazione del Cruise Control per il ribilanciamento](cruise-control.md).
+ **Throughput più elevato**: i broker Express offrono un throughput fino a 3 volte superiore per broker rispetto ai broker Standard. Ad esempio, è possibile scrivere in sicurezza fino a 500 dati MBps con ogni broker Express di dimensioni pari a m7g.16xlarge rispetto ai 153,8 MBps del broker Standard equivalente (entrambi i numeri presuppongono un'allocazione della larghezza di banda sufficiente per le operazioni in background, come la replica e il ribilanciamento).
+ **Configurato per un'elevata resilienza: i broker Express offrono automaticamente diverse best practice per migliorare la resilienza** del cluster. Queste includono protezioni sulle configurazioni critiche di Apache Kafka, quote di throughput e prenotazioni di capacità per operazioni in background e riparazioni non pianificate. Queste funzionalità rendono più sicura e semplice l'esecuzione di applicazioni Apache Kafka su larga scala. Consulta le sezioni relative [Configurazioni del broker Express](msk-configuration-express.md) e [Quota del broker Amazon MSK Express](limits.md#msk-express-quota) per maggiori dettagli.
+ **Nessuna finestra di manutenzione**: non ci sono finestre di manutenzione per i broker Express. Amazon MSK aggiorna automaticamente l'hardware del cluster su base continuativa. Per maggiori dettagli, consulta [Patching for Express brokers](https://docs.aws.amazon.com/msk/latest/developerguide/patching-impact.html#patching-express-brokers).
## Informazioni aggiuntive sui broker Express
+ I broker Express funzionano con Apache Kafka APIs, ma non supportano ancora completamente le API. KStreams
+ I broker Express sono disponibili solo in una configurazione a 3. AZs
+ I broker Express sono disponibili solo su istanze di dimensioni selezionate. Consulta i [prezzi di Amazon MSK](https://aws.amazon.com/msk/pricing/) per l'elenco aggiornato.
+ I broker Express sono supportati nelle seguenti versioni di Apache Kafka: 3.6, 3.8 e 3.9.
+ I broker Express possono essere creati con KRaft modalità a partire dalla versione 3.9 di Apache Kafka.
**Vedi questi blog**
Per ulteriori informazioni sui broker MSK Express e per vedere un esempio reale di utilizzo dei broker Express, leggi i seguenti blog:
[Ti presentiamo Express Brokers for Amazon MSK per offrire un throughput elevato e una scalabilità più rapida per i tuoi cluster Kafka](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 per Amazon MSK: scalabilità Kafka potenziata con prestazioni fino a 20 volte più veloci](https://aws.amazon.com/blogs/big-data/express-brokers-for-amazon-msk-turbo-charged-kafka-scaling-with-up-to-20-times-faster-performance/)
Questo blog dimostra come i broker Express:
Offrono un throughput più rapido, una scalabilità rapida e tempi di ripristino migliorati in caso di guasti
Elimina le complessità di gestione dello storage
# Dimensioni dei broker Amazon MSK
Quando crei un cluster Amazon MSK Provisioned, specifichi la dimensione dei broker che desideri che abbia. A seconda del [tipo di broker](broker-instance-types.md), Amazon MSK supporta le seguenti dimensioni di broker.
**Dimensioni standard dei broker**
+ 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.16xlarge, kafka.m7g.16xlarge
**Dimensioni dei broker Express**
+ express.m7g.large, express.m7g.xlarge, express.m7g.2xlarge, express.m7g.4xlarge, express.m7g.8xlarge, express.m7g.12xlarge, express.m7g.16xlarge, express.m7g.16xlarge
**Nota**
Alcune dimensioni di broker potrebbero non essere disponibili in alcune regioni. AWS Consulta le tabelle dei prezzi aggiornate delle istanze Broker nella [pagina dei prezzi di Amazon MSK](https://aws.amazon.com/msk/pricing/) per l'elenco più recente delle istanze disponibili per regione.
## Altre note sulle dimensioni dei broker
+ I broker M7g utilizzano processori AWS Graviton (processori personalizzati basati su ARM creati da Amazon Web Services). I broker M7g offrono un rapporto prezzo/prestazioni migliorato rispetto alle istanze M5 comparabili. I broker M7g consumano meno energia rispetto alle istanze M5 comparabili.
+ Amazon MSK supporta i broker M7g su cluster MSK Provisioned con versioni 2.8.2 e 3.3.2 e successive di Kafka.
+ I broker M7g e M5 offrono prestazioni di throughput di base più elevate rispetto ai broker T3 e sono consigliati per carichi di lavoro di produzione. I broker M7g e M5 possono anche avere più partizioni per broker rispetto ai broker T3. Usa i broker M7g o M5 se esegui carichi di lavoro di livello di produzione più grandi o richiedi un numero maggiore di partizioni. Per ulteriori informazioni sulle dimensioni delle istanze M7g e M5, consulta [Amazon EC2 General](https://aws.amazon.com/ec2/instance-types/) Purpose Instances.
+ I broker T3 possono utilizzare i crediti della CPU per incrementare temporaneamente le prestazioni. Utilizza i broker T3 per lo sviluppo a basso costo, se stai provando carichi di lavoro di streaming di piccole e medie dimensioni o se disponi di carichi di lavoro di streaming a throughput basso con picchi temporanei di throughput. Ti consigliamo di eseguire un proof-of-concept test per determinare se i broker T3 sono sufficienti per la produzione o per un carico di lavoro critico. Per ulteriori informazioni sulle dimensioni dei broker T3, consulta [Amazon EC2 T3 Instances](https://aws.amazon.com/ec2/instance-types/t3/).
Per ulteriori informazioni su come scegliere le dimensioni dei broker, consulta. [Le migliori pratiche per i broker Standard ed Express](bestpractices-intro.md)
# Gestione dello storage per broker Standard
Amazon MSK offre funzionalità per aiutarti con la gestione dell'archiviazione sui tuoi cluster MSK.
**Nota**
Con [i broker Express](msk-broker-types-express.md), non è necessario fornire o gestire le risorse di archiviazione utilizzate per i dati. Ciò semplifica la gestione dei cluster ed elimina una delle cause più comuni dei problemi operativi con i cluster Apache Kafka. Inoltre, spendi meno in quanto non devi fornire capacità di storage inattiva e paghi solo per ciò che utilizzi.
**Tipo di broker standard**
Con [i broker Standard](msk-broker-types-standard.md) puoi scegliere tra una varietà di opzioni e funzionalità di archiviazione. Amazon MSK offre funzionalità per aiutarti con la gestione dell'archiviazione sui tuoi cluster MSK.
Per informazioni sulla gestione del throughput, consulta. [Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput.md)
**Topics**
+ [Storage su più livelli per broker Standard](msk-tiered-storage.md)
+ [Espandi lo storage dei broker Amazon MSK Standard](msk-update-storage.md)
+ [Gestisci il throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput-management.md)
# Storage su più livelli per broker Standard
L'archiviazione a più livelli è un livello di archiviazione a basso costo per Amazon MSK che si dimensiona fino a una capacità praticamente illimitata, rendendo conveniente la creazione di applicazioni di streaming di dati.
È possibile creare un cluster Amazon MSK configurato con un'archiviazione a più livelli che bilancia prestazioni e costi. Amazon MSK archivia i dati in streaming in un livello di archiviazione primario ottimizzato per le prestazioni fino a raggiungere i limiti di conservazione degli argomenti di Apache Kafka. Quindi, Amazon MSK sposta automaticamente i dati nel nuovo livello di archiviazione a basso costo.
Quando l'applicazione inizia a leggere i dati dall'archiviazione a più livelli, è possibile che i primi byte siano soggetti a un aumento della latenza di lettura. Quando inizi a leggere i dati rimanenti in sequenza dal livello a basso costo, le latenze dovrebbero essere simili a quelle del livello di archiviazione primario. Non è necessario effettuare il provisioning di alcun tipo di archiviazione per l'archiviazione più livelli a basso costo o per gestire l'infrastruttura. È possibile archiviare qualsiasi quantità di dati e pagare solo per le risorse utilizzate. Questa funzionalità è compatibile con la funzionalità APIs introdotta in [KIP-405: Kafka Tiered Storage](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage).
Per informazioni sul dimensionamento, il monitoraggio e l'ottimizzazione del cluster di storage su più livelli MSK, consulta [Best practice per l'esecuzione di carichi di lavoro di produzione utilizzando lo storage su più livelli Amazon](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/) MSK.
Di seguito sono elencate alcune caratteristiche dell'archiviazione a più livelli:
+ È possibile dimensionare fino a una capacità di archiviazione praticamente illimitata. Non è necessario fare supposizioni su come dimensionare la propria infrastruttura Apache Kafka.
+ È possibile mantenere i dati più a lungo negli argomenti di Apache Kafka o aumentare lo spazio di archiviazione degli argomenti senza la necessità di aumentare il numero di broker.
+ Fornisce un buffer di sicurezza di maggiore durata per gestire ritardi imprevisti nell'elaborazione.
+ Puoi rielaborare i vecchi dati nel loro esatto ordine di produzione con il codice di elaborazione dello stream esistente e Kafka. APIs
+ Le partizioni si ribilanciano più velocemente perché i dati nell'archiviazione secondaria non richiedono la replica tra i dischi del broker.
+ I dati tra i broker e l'archiviazione a più livelli si spostano all'interno del VPC e non viaggiano su Internet.
+ Per connettersi a nuovi cluster con l'archiviazione a più livelli abilitata, un computer client può utilizzare lo stesso processo che utilizza per connettersi a un cluster senza l'archiviazione a più livelli abilitata. Consulta la sezione [Creazione di un computer client](https://docs.aws.amazon.com/msk/latest/developerguide/create-client-machine.html).
## Requisiti di storage su più livelli per i cluster Amazon MSK
+ È necessario utilizzare la versione 3.0.0 o successiva del client Apache Kafka per creare un nuovo argomento con l'archiviazione a più livelli abilitata. Per trasferire un argomento esistente all'archiviazione a più livelli, puoi riconfigurare un computer client che utilizza una versione del client Kafka precedente alla 3.0.0 (la versione minima supportata di Apache Kafka è 2.8.2.tiered) per abilitare l'archiviazione a più livelli. Per informazioni, consulta [Fase 4: creare un argomento nel cluster Amazon MSK](create-topic.md).
+ Il cluster Amazon MSK con storage su più livelli abilitato deve utilizzare la versione 3.6.0 o successiva o 2.8.2.tiered.
## Vincoli e limitazioni dello storage su più livelli per i cluster Amazon MSK
L'archiviazione a più livelli presenta i seguenti vincoli e limitazioni:
+ Assicurati che i client non siano configurati per `read_committed` la lettura da remote\$1tier in Amazon MSK, a meno che l'applicazione non utilizzi attivamente la funzionalità delle transazioni.
+ Lo storage su più livelli non è disponibile nelle regioni AWS GovCloud (Stati Uniti).
+ L'archiviazione a più livelli si applica solo ai cluster in modalità assegnata.
+ Lo storage su più livelli non supporta la dimensione del broker t3.small.
+ Il periodo di conservazione minimo nell'archiviazione a basso costo è di 3 giorni. Non è previsto un periodo minimo di conservazione per l'archiviazione primaria.
+ L'archiviazione a più livelli non supporta le directory di log multipli su un broker (funzionalità relative a JBOD).
+ Lo storage su più livelli non supporta argomenti compatti. Assicurati che cleanup.policy sia configurato solo su «DELETE» per tutti gli argomenti per cui è attivato lo storage su più livelli.
+ Il cluster di archiviazione a più livelli non supporta la modifica della politica log.cleanup.policy per un argomento dopo la sua creazione.
+ Lo storage su più livelli può essere disabilitato per singoli argomenti ma non per l'intero cluster. Una volta disattivata, l'archiviazione a più livelli non può essere riattivata per un argomento.
+ Se utilizzi la versione 2.8.2.tiered di Amazon MSK, puoi migrare solo a un'altra versione di Apache Kafka supportata dallo storage su più livelli. Se non desideri continuare a utilizzare una versione supportata dallo storage su più livelli, crea un nuovo cluster MSK e migra i tuoi dati su di esso.
+ Lo kafka-log-dirs strumento non è in grado di riportare le dimensioni dei dati di storage su più livelli. Lo strumento riporta solo la dimensione dei segmenti di log nell'archiviazione primaria.
Per informazioni sulle impostazioni e sui vincoli predefiniti, è necessario prestare attenzione quando si configura lo storage su più livelli a livello di argomento, vedere. [Linee guida per la configurazione a livello di argomento dello storage su più livelli di Amazon MSK](msk-guidelines-tiered-storage-topic-level-config.md)
# Come vengono copiati i segmenti di log nello storage su più livelli per un argomento di Amazon MSK
Quando abiliti l'archiviazione a più livelli per un argomento nuovo o esistente, Apache Kafka copia i segmenti di log chiusi dall'archiviazione primaria all'archiviazione a più livelli.
+ Apache Kafka copia solo i segmenti di log chiusi. Copia tutti i messaggi all'interno del segmento di log in un'archiviazione a più livelli.
+ I segmenti attivi non sono idonei per l'archiviazione a più livelli. La dimensione del segmento di log (segment.bytes) o il tempo di distribuzione del segmento (segment.ms) controllano la velocità di chiusura dei segmenti e la velocità con cui, successivamente, Apache Kafka li copia nell'archiviazione a più livelli.
Le impostazioni di conservazione per un argomento con l'archiviazione a più livelli abilitata sono diverse dalle impostazioni per un argomento senza l'archiviazione a più livelli abilitata. Le seguenti regole disciplinano la conservazione dei messaggi negli argomenti con l'archiviazione a più livelli abilitata:
+ È possibile definire la conservazione in Apache Kafka con due impostazioni: log.retention.ms (durata) e log.retention.bytes (dimensioni). Queste impostazioni determinano la durata e le dimensioni totali dei dati che Apache Kafka conserva nel cluster. Indipendentemente dal fatto che si abiliti o meno la modalità di archiviazione a più livelli, queste configurazioni vengono impostate a livello di cluster. È possibile sovrascrivere le impostazioni a livello di argomento con le configurazioni degli argomenti.
+ Quando si abilita l'archiviazione a più livelli, è possibile specificare anche per quanto tempo il livello di archiviazione primaria ad alte prestazioni archivia i dati. Ad esempio, se un argomento ha un'impostazione di conservazione complessiva (log.retention.ms) di 7 giorni e una conservazione locale (local.retention.ms) di 12 ore, l'archiviazione primaria del cluster conserva i dati solo per le prime 12 ore. Il livello di archiviazione a basso costo conserva i dati per tutti i 7 giorni.
+ Al log completo si applicano le normali impostazioni di conservazione. Ciò include le parti primarie e a più livelli.
+ Le impostazioni local.retention.ms o local.retention.bytes controllano la conservazione dei messaggi nell'archiviazione primaria. Apache Kafka copia i segmenti di log chiusi nello storage su più livelli non appena vengono chiusi (in base a segment.bytes o segment.ms), indipendentemente dalle impostazioni di conservazione locali. Dopo che i segmenti sono stati copiati nello storage su più livelli, rimangono nello storage principale fino al raggiungimento delle soglie local.retention.ms o local.retention.bytes. A quel punto, i dati vengono eliminati dallo storage principale ma rimangono disponibili nello storage su più livelli. Ciò consente di conservare i dati recenti su uno storage primario ad alte prestazioni per un accesso rapido, mentre i dati più vecchi vengono serviti dallo storage su più livelli a basso costo.
+ Quando Apache Kafka copia un messaggio in un segmento di log a più livelli, lo rimuove dal cluster in base alle impostazioni retention.ms o retention.bytes.
## Esempio di scenario di storage su più livelli di Amazon MSK
Questo scenario illustra il comportamento di un argomento esistente che contiene messaggi nell'archiviazione primaria quando è abilitata l'archiviazione a più livelli. L'archiviazione a più livelli su questo argomento viene abilitata quando si imposta remote.storage.enable su `true`. In questo esempio, retention.ms è impostato su 5 giorni e local.retention.ms è impostato su 2 giorni. Di seguito è riportata la sequenza di eventi alla scadenza di un segmento.
**Ora T0: prima di abilitare l'archiviazione a più livelli.**
Prima di abilitare l'archiviazione a più livelli per questo argomento, esistono due segmenti di log. Uno dei segmenti è attivo per una partizione di argomenti esistente 0.
![\[Ora T0: prima di abilitare l'archiviazione a più livelli.\]](http://docs.aws.amazon.com/it_it/msk/latest/developerguide/images/tiered-storage-segments-1.png)
**Ora T1 (< 2 giorni): archiviazione a più livelli abilitata. Segmento 0 copiato nell'archiviazione a più livelli.**
Dopo aver abilitato lo storage su più livelli per questo argomento, Apache Kafka copia il segmento di log chiuso 0 nello storage su più livelli non appena viene chiuso. Il segmento si chiude in base alle impostazioni segment.bytes o segment.ms, non in base alle impostazioni di conservazione. Apache Kafka conserva una copia anche nella memoria principale. Il segmento 1 attivo non è ancora idoneo alla copia su uno storage su più livelli perché è ancora attivo e non è stato chiuso. In questa sequenza temporale, Amazon MSK non applica ancora nessuna delle impostazioni di conservazione per nessuno dei messaggi nel segmento 0 e nel segmento 1. (conservazione locale). bytes/ms, retention.ms/bytes)
![\[Ora T1 (< 2 giorni): archiviazione a più livelli abilitata. Segmento 0 copiato nell'archiviazione a più livelli.\]](http://docs.aws.amazon.com/it_it/msk/latest/developerguide/images/tiered-storage-segments-2.png)
**Ora T2: conservazione locale in vigore.**
Dopo 2 giorni, viene raggiunta la soglia di conservazione locale per il segmento 0. Ciò è determinato dall'impostazione di local.retention.ms su 2 giorni. Il segmento 0 viene ora eliminato dallo storage principale, ma rimane disponibile nello storage su più livelli. Si noti che il segmento 0 era già stato copiato nello storage su più livelli al momento T1 alla chiusura, non al momento T2 alla scadenza della conservazione locale. Il segmento attivo 1 non è ancora idoneo per l'eliminazione né per la copia su uno storage su più livelli perché è ancora attivo.
![\[Ora T2: conservazione locale in vigore.\]](http://docs.aws.amazon.com/it_it/msk/latest/developerguide/images/tiered-storage-segments-3.png)
**Ora T3: conservazione complessiva in vigore.**
Dopo 5 giorni, le impostazioni di conservazione hanno effetto e Kafka cancella il segmento di log 0 e i messaggi associati dall'archiviazione a più livelli. Il segmento 1 non è ancora idoneo alla scadenza né può essere copiato nell'archiviazione a più livelli perché è attivo. Il segmento 1 non è ancora chiuso, quindi non è idoneo per la distribuzione dei segmenti.
![\[Ora T3: conservazione complessiva in vigore.\]](http://docs.aws.amazon.com/it_it/msk/latest/developerguide/images/tiered-storage-segments-4.png)
# Crea un cluster Amazon MSK con storage su più livelli con Console di gestione AWS
Questo processo descrive come creare un cluster Amazon MSK di storage su più livelli utilizzando. Console di gestione AWS
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Scegli **Crea cluster**.
1. Scegli **Creazione personalizzata** per l'archiviazione a più livelli.
1. Specificare un nome per il cluster.
1. In **Tipo di cluster**, seleziona **Assegnato**.
1. Scegli la versione di Amazon Kafka che supporti l'archiviazione a più livelli e che desideri che Amazon MSK utilizzi per creare il cluster.
1. **Specificate una dimensione del broker diversa da kafka.t3.small.**
1. Specifica il numero di broker che devono essere creati da Amazon MSK in ogni zona di disponibilità. Il valore minimo è un broker per zona di disponibilità e il valore massimo è 30 broker per cluster.
1. Specifica il numero di zone in cui sono distribuiti i broker.
1. Specifica il numero di broker Apache Kafka implementati per zona.
1. Seleziona **Opzioni di archiviazione**. Ciò include l'**archiviazione a più livelli e l'archiviazione EBS** per abilitare la modalità di archiviazione a più livelli.
1. Segui i restanti passaggi nella procedura guidata di creazione dei cluster. Al termine, **Archiviazione a più livelli e archiviazione EBS** viene visualizzata come modalità di archiviazione del cluster nella vista **Rivedi e crea**.
1. Selezionare **Creazione di un cluster**.
# Crea un cluster Amazon MSK con storage su più livelli con AWS CLI
Per abilitare l'archiviazione a più livelli su un cluster, crea il cluster con la versione e l'attributo di Apache Kafka corretti per l'archiviazione a più livelli. Segui l'esempio di codice sottostante. Inoltre, completa la procedura descritta nella sezione successiva per [Crea un argomento su Kafka con lo storage su più livelli abilitato con AWS CLI](#msk-create-topic-tiered-storage-cli).
Per un elenco completo degli attributi supportati per la creazione di cluster, consulta la sezione [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"
```
## Crea un argomento su Kafka con lo storage su più livelli abilitato con AWS CLI
Per completare il processo avviato quando hai creato un cluster con l'archiviazione a più livelli abilitata, crea anche un argomento con l'archiviazione a più livelli abilitata con gli attributi dell'esempio di codice successivo. Gli attributi specifici per l'archiviazione a più livelli sono i seguenti:
+ `local.retention.ms` (ad esempio, 10 minuti) per le impostazioni di conservazione basate sul tempo o `local.retention.bytes` per i limiti delle dimensioni dei segmenti di log.
+ `remote.storage.enable` impostato su `true` per abilitare l'archiviazione a più livelli.
La configurazione seguente utilizza local.retention.ms, ma è possibile sostituire questo attributo con local.retention.bytes. Questo attributo controlla la quantità di tempo che può trascorrere o il numero di byte che Apache Kafka può copiare prima che il servizio copi i dati dall'archiviazione primaria a quella a più livelli. Per maggiori dettagli sugli attributi di configurazione supportati, consulta la sezione [Configurazione a livello di argomento](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration).
**Nota**
È necessario utilizzare la versione 3.0.0 o successiva del client Apache Kafka. Queste versioni supportano un'impostazione chiamata `remote.storage.enable` solo in tali versioni client di `kafka-topics.sh`. Per abilitare l'archiviazione a più livelli su un argomento esistente che utilizza una versione precedente di Apache Kafka, consulta la sezione [Abilitazione dello storage su più livelli su un argomento esistente di Amazon MSK](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
```
# Abilitare e disabilitare lo storage su più livelli su un argomento esistente di Amazon MSK
Queste sezioni spiegano come abilitare e disabilitare l'archiviazione a più livelli su un argomento che hai già creato. Per creare un nuovo cluster e un argomento con l'archiviazione a più livelli abilitata, consulta la sezione [Creazione di un cluster con archiviazione a più livelli tramite la Console di gestione AWS](https://docs.aws.amazon.com//msk/latest/developerguide/msk-create-cluster-tiered-storage-console).
## Abilitazione dello storage su più livelli su un argomento esistente di Amazon MSK
Per abilitare l'archiviazione a più livelli su un argomento esistente, utilizza la sintassi del comando `alter` nell'esempio seguente. Quando abiliti l'archiviazione a più livelli su un argomento esistente, non è necessario utilizzare una determinata versione del client Apache Kafka.
```
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'
```
## Disabilitare lo storage su più livelli su un argomento esistente di Amazon MSK
Per disabilitare l'archiviazione a più livelli su un argomento esistente, utilizza la sintassi del comando `alter` nello stesso ordine con cui hai abilitato l'archiviazione a più livelli.
```
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'
```
**Nota**
Quando si disabilita l'archiviazione a più livelli, si eliminano completamente i dati relativi all'argomento nell'archiviazione a più livelli. Apache Kafka conserva i dati dell'archiviazione primaria, ma applica comunque le regole di conservazione dell'archiviazione primaria in base a `local.retention.ms`. Una volta disabilitata l'archiviazione a più livelli su un argomento, non sarà possibile riabilitarla. Se desideri disabilitare l'archiviazione a più livelli su un argomento esistente, non è necessario utilizzare una determinata versione del client Apache Kafka.
# Abilita lo storage su più livelli su un cluster Amazon MSK esistente tramite CLI AWS
**Nota**
È possibile abilitare l'archiviazione a più livelli solo se la policy del cluster log.cleanup.policy è impostata su `delete`, poiché gli argomenti compatti non sono supportati nell'archiviazione a più livelli. Successivamente, puoi configurare la policy log.cleanup.policy di un singolo argomento su `compact` in modo che l'archiviazione a più livelli non sia abilitata su quel particolare argomento. Per maggiori dettagli sugli attributi di configurazione supportati, consulta la sezione [Configurazione a livello di argomento](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration).
1. **Aggiorna la versione di Kafka**: le versioni dei cluster non sono semplici numeri interi. Per trovare la versione corrente del cluster, utilizzare l'`DescribeCluster`operazione o il comando `describe-cluster` AWS CLI. Una versione di esempio è `KTVPDKIKX0DER`.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version 3.6.0
```
1. Modifica la modalità di archiviazione del cluster. Nel seguente esempio di codice viene illustrato come modificare la modalità di archiviazione del cluster in `TIERED` tramite l'API [https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html).
```
aws kafka update-storage --current-version Current-Cluster-Version --cluster-arn Cluster-arn --storage-mode TIERED
```
# Aggiorna lo storage su più livelli su un cluster Amazon MSK esistente utilizzando la console
Questo processo descrive come aggiornare un cluster Amazon MSK di storage su più livelli utilizzando il. Console di gestione AWS
Assicurati che la versione corrente di Apache Kafka del tuo cluster MSK sia la versione 2.8.2.tiered. Fai riferimento all'[aggiornamento della versione di Apache Kafka](https://docs.aws.amazon.com/msk/latest/developerguide/version-upgrades.html) se è necessario aggiornare il cluster MSK alla versione 2.8.2.tiered.
**Nota**
È possibile abilitare l'archiviazione a più livelli solo se la policy del cluster log.cleanup.policy è impostata su `delete`, poiché gli argomenti compatti non sono supportati nell'archiviazione a più livelli. Successivamente, puoi configurare la policy log.cleanup.policy di un singolo argomento su `compact` in modo che l'archiviazione a più livelli non sia abilitata su quel particolare argomento. Per maggiori dettagli sugli attributi di configurazione supportati, consulta la sezione [Configurazione a livello di argomento](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration).
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Vai alla pagina di riepilogo del cluster e scegli **Proprietà**.
1. Vai alla sezione **Archiviazione** e scegli **Modifica modalità di archiviazione del cluster**.
1. Scegli **Archiviazione a più livelli e archiviazione EBS** e **Salva modifiche**.
# Espandi lo storage dei broker Amazon MSK Standard
È possibile aumentare la quantità di storage EBS per broker. Non è possibile ridurre lo storage.
I volumi di storage rimangono disponibili durante questa operazione di dimensionamento.
**Importante**
Quando l'archiviazione viene dimensionata per un cluster MSK, l'archiviazione aggiuntiva viene resa disponibile immediatamente. Tuttavia, il cluster richiede un periodo di raffreddamento dopo ogni evento di dimensionamento dell'archiviazione. Amazon MSK utilizza questo periodo di raffreddamento per ottimizzare il cluster prima di un successivo nuovo dimensionamento. Questo periodo può variare da un minimo di 6 ore a più di 24 ore, a seconda delle dimensioni e dell'utilizzo dell'archiviazione del cluster e del traffico. Ciò è applicabile sia agli eventi di ridimensionamento automatico che al ridimensionamento manuale utilizzando l'[UpdateBrokerStorage](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage)operazione. Per informazioni sul corretto dimensionamento dell'archiviazione, consulta la sezione [Le migliori pratiche per i broker standard](bestpractices.md).
Puoi utilizzare l'archiviazione a più livelli per aumentare fino a quantità illimitate lo spazio di archiviazione per il broker. Per informazioni, consultare [Storage su più livelli per broker Standard](msk-tiered-storage.md).
**Topics**
+ [Scalabilità automatica per i cluster Amazon MSK](msk-autoexpand.md)
+ [Ridimensionamento manuale per broker Standard](manually-expand-storage.md)
# Scalabilità automatica per i cluster Amazon MSK
Per espandere automaticamente l'archiviazione del cluster in risposta a un maggiore utilizzo, puoi configurare una policy di dimensionamento automatico dell'applicazione per Amazon MSK. In una policy di dimensionamento automatico, si imposta l'utilizzo del disco di destinazione e la capacità di dimensionamento massima.
Prima di utilizzare il dimensionamento automatico per Amazon MSK, è consigliabile tenere in considerazione quanto segue:
+
**Importante**
Un'operazione di dimensionamento dell'archiviazione può avvenire solo una volta ogni sei ore.
Ti consigliamo di iniziare con un volume di archiviazione della dimensione giusta per le tue esigenze di archiviazione. Per indicazioni sul corretto dimensionamento del cluster, consulta la pagina [Dimensiona correttamente il tuo cluster: numero di broker Standard per cluster](bestpractices.md#brokers-per-cluster).
+ Amazon MSK non riduce lo spazio di archiviazione del cluster in risposta a un utilizzo ridotto. Amazon MSK non supporta la riduzione delle dimensioni dei volumi di archiviazione. Se è necessario ridurre le dimensioni dell'archiviazione del cluster, è necessario migrare il cluster esistente in un cluster con un'archiviazione più piccola. Per ulteriori informazioni sulla migrazione di un cluster, consulta la pagina [Esegui la migrazione al cluster MSK](migration.md).
+ Amazon MSK non supporta la scalabilità automatica nelle regioni Asia Pacifico (Osaka), Africa (Città del Capo) e Asia Pacifico (Malesia).
+ Quando associ una politica di auto-scaling al tuo cluster, Amazon EC2 Auto Scaling crea automaticamente un allarme Amazon per il tracciamento degli obiettivi. CloudWatch Se si elimina un cluster con una politica di auto-scaling, CloudWatch questo allarme persiste. Per eliminare l' CloudWatch allarme, è necessario rimuovere una politica di auto-scaling da un cluster prima di eliminare il cluster. Per ulteriori informazioni sul monitoraggio degli obiettivi, consulta la pagina [Target tracking scaling policies for Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) nella *Guida per l'utente di Dimensionamento automatico Amazon EC2*.
**Topics**
+ [Dettagli della politica di ridimensionamento automatico per Amazon MSK](msk-autoexpand-details.md)
+ [Configura il ridimensionamento automatico per il tuo cluster Amazon MSK](msk-autoexpand-setup.md)
# Dettagli della politica di ridimensionamento automatico per Amazon MSK
Una policy di dimensionamento automatico definisce i seguenti parametri predefiniti per il cluster:
+ **Obiettivo di utilizzo dell'archiviazione**: la soglia di utilizzo dell'archiviazione utilizzata da Amazon MSK per attivare un'operazione di dimensionamento automatico. È possibile impostare l'obiettivo di utilizzo tra il 10% e l'80% della capacità di archiviazione corrente. Consigliamo di impostare l'obiettivo di utilizzo dell'archiviazione tra il 50% e il 60%.
+ **Capacità massima di archiviazione**: il limite di scalabilità massimo che Amazon MSK può impostare per l'archiviazione del broker. È possibile impostare la capacità di archiviazione massima fino a 16 TiB per broker. Per ulteriori informazioni, consulta [Quota di Amazon MSK](limits.md).
Quando Amazon MSK rileva che il parametro `Maximum Disk Utilization` è uguale o superiore all'impostazione `Storage Utilization Target`, aumenta la capacità di archiviazione di una quantità pari al più grande tra due numeri: 10 GiB o il 10% dell'archiviazione corrente. Ad esempio, se hai 1.000 GiB, tale quantità è 100 GiB. Il servizio verifica l'utilizzo dell'archiviazione ogni minuto. Ulteriori operazioni di dimensionamento continuano ad aumentare l'archiviazione di una quantità pari al più grande tra due numeri: 10 GiB o il 10% dell'archiviazione corrente.
Per determinare se sono state eseguite operazioni di auto-scaling, utilizzare l'operazione. [ ListClusterOperations](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-operations.html#ListClusterOperations)
# Configura il ridimensionamento automatico per il tuo cluster Amazon MSK
Puoi utilizzare la console Amazon MSK, l'API Amazon MSK o implementare il ridimensionamento automatico CloudFormation per lo storage. CloudFormation il supporto è disponibile tramite. [Application Auto Scaling](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html)
**Nota**
Non è possibile implementare il dimensionamento automatico al momento della creazione di un cluster. È necessario innanzitutto creare il cluster, quindi creare e abilitare una policy di dimensionamento automatico per il cluster. Tuttavia, puoi creare la policy mentre il servizio Amazon MSK crea il tuo cluster.
**Topics**
+ [Configura il ridimensionamento automatico utilizzando Amazon MSK Console di gestione AWS](msk-autoexpand-setup-console.md)
+ [Configura il ridimensionamento automatico utilizzando la CLI](msk-autoexpand-setup-cli.md)
+ [Configura la scalabilità automatica per Amazon MSK utilizzando l'API](msk-autoexpand-setup-api.md)
# Configura il ridimensionamento automatico utilizzando Amazon MSK Console di gestione AWS
Questo processo descrive come utilizzare la console Amazon MSK per implementare la scalabilità automatica per lo storage.
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco di cluster, scegli il tuo cluster. Questa operazione ti reindirizzerà a una pagina che elenca i dettagli sul cluster.
1. Nella sezione **Dimensionamento automatico per l'archiviazione**, scegli **Configura**.
1. Crea e assegna un nome a una policy di dimensionamento automatico. Specifica l'obiettivo di utilizzo dell'archiviazione, la capacità massima di archiviazione e il parametro obiettivo.
1. Scegli `Save changes`.
Quando salvi e abiliti la nuova policy, la policy diventa attiva per il cluster. Quando viene raggiunto l'obiettivo di utilizzo dell'archiviazione, Amazon MSK espande l'archiviazione del cluster.
# Configura il ridimensionamento automatico utilizzando la CLI
Questo processo descrive come utilizzare la CLI di Amazon MSK per implementare la scalabilità automatica per lo storage.
1. Usa il [ RegisterScalableTarget](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)comando per registrare un obiettivo di utilizzo dello storage.
1. Usa il [ PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)comando per creare una politica di espansione automatica.
# Configura la scalabilità automatica per Amazon MSK utilizzando l'API
Questo processo descrive come utilizzare l'API Amazon MSK per implementare la scalabilità automatica per lo storage.
1. Utilizza l'[ RegisterScalableTarget](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_RegisterScalableTarget.html)API per registrare un obiettivo di utilizzo dello storage.
1. Utilizza l'[ PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)API per creare una politica di espansione automatica.
# Ridimensionamento manuale per broker Standard
Per incrementare lo storage, attendere che lo stato del cluster diventi `ACTIVE`. Il dimensionamento dell'archiviazione prevede un periodo di raffreddamento di almeno sei ore tra un evento e l'altro. Anche se l'operazione rende immediatamente disponibile spazio di archiviazione aggiuntivo, il servizio esegue ottimizzazioni sul cluster che possono richiedere fino a 24 ore o più. La durata di queste ottimizzazioni è proporzionale alla dimensione dell'archiviazione.
## Scalabilità dello spazio di archiviazione dei broker utilizzando il Console di gestione AWS
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Scegli il cluster MSK per cui desideri aggiornare lo spazio di archiviazione del broker.
1. Nella sezione **Archiviazione**, scegli **Modifica**.
1. Specifica il volume di storage desiderato. La quantità di storage può essere solo aumentata, non diminuita.
1. Scegli **Save changes** (Salva modifiche).
## Scalabilità dello storage dei broker utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
Sostituiscilo *Current-Cluster-Version* con la versione corrente del cluster.
**Importante**
Le versioni del cluster non sono interi semplici. Per trovare la versione corrente del cluster, usa l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operazione o il comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Una versione di esempio è `KTVPDKIKX0DER`.
Il *Target-Volume-in-GiB* parametro rappresenta la quantità di spazio di archiviazione che desideri assegnare a ciascun broker. È consentito aggiornare lo storage solo per tutti i broker. Non è possibile specificare singoli broker per i quali aggiornare lo storage. Il valore specificato *Target-Volume-in-GiB* deve essere un numero intero maggiore di 100 GiB. Lo storage per broker dopo l'operazione di aggiornamento non può superare 16384 GiB.
```
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}'
```
## Aumento delle dimensioni dello spazio di archiviazione del broker tramite l'API
Per aggiornare lo storage di un broker utilizzando l'API, consulta [UpdateBrokerStorage](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage).
# Gestisci il throughput di storage per i broker Standard in un cluster Amazon MSK
Per informazioni su come fornire la velocità effettiva utilizzando la console, la CLI e l'API di Amazon MSK, consulta. [Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput.md)
**Topics**
+ [Problemi di throughput del broker Amazon MSK e impostazioni di throughput massimo](#throughput-bottlenecks)
+ [Misura il throughput di storage di un cluster Amazon MSK](#throughput-metrics)
+ [Valori di aggiornamento della configurazione per lo storage assegnato in un cluster Amazon MSK](#provisioned-throughput-config)
+ [Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput.md)
## Problemi di throughput del broker Amazon MSK e impostazioni di throughput massimo
I colli di bottiglia nella velocità di trasmissione effettiva dei broker sono dovuti a molteplici cause: velocità di trasmissione effettiva del volume, velocità di trasmissione effettiva della rete da Amazon EC2 ad Amazon EBS e velocità di trasmissione effettiva in uscita di Amazon EC2. È possibile abilitare la velocità di trasmissione effettiva assegnata per regolare la velocità di trasmissione effettiva del volume. Tuttavia, le limitazioni della velocità di trasmissione effettiva del broker possono essere causate dalla velocità di trasmissione effettiva della rete da Amazon EC2 ad Amazon EBS e dalla velocità di trasmissione effettiva in uscita di Amazon EC2.
La velocità di trasmissione effettiva in uscita di Amazon EC2 è influenzata dal numero di gruppi di consumatori e dal numero di consumatori per ciascun gruppo. Inoltre, sia il throughput di rete da Amazon EC2 ad Amazon EBS che il throughput di uscita di Amazon EC2 sono più elevati per broker di grandi dimensioni.
Per volumi di dimensioni pari o superiori a 10 GiB, è possibile assegnare una velocità di trasmissione effettiva dell'archiviazione pari o superiore a 250 MiB al secondo. L'impostazione predefinita è 250 MiB al secondo. Per effettuare il provisioning del throughput di storage, devi scegliere la dimensione del broker kafka.m5.4xlarge o superiore (oppure kafka.m7g.2xlarge o superiore) e puoi specificare il throughput massimo come mostrato nella tabella seguente.
****
| dimensione del broker | Velocità di trasmissione effettiva massima (MiB/secondo) |
| --- | --- |
| kafka.m5.4xlarge | 593 |
| kafka.m5.8xlarge | 850 |
| kafka.m5.12xlarge | 1000 |
| kafka.m5.16xlarge | 1000 |
| kafka.m5.24xlarge | 1000 |
| kafka.m7 g. 2 x grande | 312,5 |
| kafka.m7g.4xlarge | 625 |
| kafka.m7g.8xlarge | 1000 |
| kafka.m7g. 12 x grande | 1000 |
| kafka.m7g. 16 x grande | 1000 |
## Misura il throughput di storage di un cluster Amazon MSK
È possibile utilizzare i parametri `VolumeReadBytes` e `VolumeWriteBytes` per misurare la velocità di trasmissione effettiva media di archiviazione di un cluster. La somma di questi due parametri fornisce la velocità di trasmissione effettiva media dell'archiviazione espressa in byte. Per ottenere la velocità di trasmissione effettiva media dell'archiviazione per un cluster, imposta questi due parametri su SUM e il periodo su 1 minuto, quindi utilizza la formula seguente.
```
Average storage throughput in MiB/s = (Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / (60 * 1024 * 1024)
```
Per ulteriori informazioni sui parametri `VolumeReadBytes` e `VolumeWriteBytes`, consulta la sezione [Monitoraggio del livello `PER_BROKER`](metrics-details.md#broker-metrics).
## Valori di aggiornamento della configurazione per lo storage assegnato in un cluster Amazon MSK
Puoi aggiornare la configurazione di Amazon MSK prima o dopo aver attivato la velocità di trasmissione effettiva assegnata. Tuttavia, non vedrai la velocità di trasmissione effettiva desiderata finché non eseguirai entrambe le operazioni: aggiornare il parametro di configurazione `num.replica.fetchers` e attivare la velocità di trasmissione effettiva assegnata.
Nella configurazione predefinita di Amazon MSK, `num.replica.fetchers` ha un valore di 2. Per aggiornare il `num.replica.fetchers`, puoi utilizzare i valori suggeriti dalla tabella seguente. Questi valori sono forniti a scopo indicativo. Si consiglia di modificare questi valori in base al proprio caso d'uso.
****
| dimensione del broker | num.replica.fetchers |
| --- | --- |
| kafka.m5.4xlarge | 4 |
| kafka.m5.8xlarge | 8 |
| kafka.m5.12xlarge | 14 |
| kafka.m5.16xlarge | 16 |
| kafka.m5.24xlarge | 16 |
La configurazione aggiornata potrebbe non avere effetto per un massimo di 24 ore e potrebbe richiedere più tempo quando un volume sorgente non è completamente utilizzato. Tuttavia, le prestazioni dei volumi di transizione sono almeno uguali a quelle dei volumi di archiviazione di origine durante il periodo di migrazione. Un volume da 1 TiB completamente utilizzato richiede in genere circa sei ore per migrare a una configurazione aggiornata.
# Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK
I broker Amazon MSK mantengono i dati sui volumi di archiviazione. Lo storage I/O viene utilizzato quando i produttori scrivono nel cluster, quando i dati vengono replicati tra broker e quando i consumatori leggono dati che non sono in memoria. La velocità di trasmissione effettiva dell'archiviazione del volume è la velocità con cui i dati possono essere scritti e letti da un volume di archiviazione. La velocità di trasmissione effettiva dell'archiviazione assegnata è la capacità di specificare tale velocità per i broker del cluster.
È possibile specificare la velocità di throughput assegnata in MiB al secondo per i cluster i cui broker sono di dimensioni `kafka.m5.4xlarge` o superiori e se il volume di storage è pari o superiore a 10 GiB. È possibile specificare la velocità di trasmissione effettiva assegnata durante la creazione del cluster. Inoltre, è possibile abilitare o disabilitare la velocità di trasmissione effettiva assegnata per un cluster che si trova nello stato `ACTIVE`.
Per informazioni sulla gestione della velocità effettiva, vedere. [Gestisci il throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput-management.md)
**Topics**
+ [Effettua il provisioning del throughput di storage del cluster Amazon MSK utilizzando Console di gestione AWS](#provisioned-throughput-console)
+ [Effettua il provisioning del throughput di storage del cluster Amazon MSK utilizzando AWS CLI](#provisioned-throughput-cli)
+ [Esegui il provisioning del throughput di storage durante la creazione di un cluster Amazon MSK utilizzando l'API](#provisioned-throughput-api)
## Effettua il provisioning del throughput di storage del cluster Amazon MSK utilizzando Console di gestione AWS
Questo processo mostra un esempio di come è possibile utilizzare il Console di gestione AWS per creare un cluster Amazon MSK con throughput assegnato abilitato.
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Scegli **Crea cluster**.
1. Scegli **Creazione personalizzata**.
1. Specificare un nome per il cluster.
1. Nella sezione **Archiviazione**, scegli **Abilita**.
1. Scegli un valore per la velocità di trasmissione effettiva dell'archiviazione per broker.
1. Scegli un VPC, zone e sottoreti, nonché un gruppo di sicurezza.
1. Scegli **Next (Successivo)**.
1. Nella parte inferiore del passaggio **Sicurezza**, scegli **Avanti**.
1. Nella parte inferiore del passaggio **Monitoraggio e tag**, scegli **Avanti**.
1. Verifica le impostazioni del cluster, quindi scegli **Crea cluster**.
## Effettua il provisioning del throughput di storage del cluster Amazon MSK utilizzando AWS CLI
Questo processo mostra un esempio di come è possibile utilizzare il AWS CLI per creare un cluster con il throughput assegnato abilitato.
1. Copia il codice JSON seguente e incollalo in un file. Sostituisci i segnaposto dell'ID della sottorete IDs e del gruppo di sicurezza con i valori del tuo account. Assegna al file il nome `cluster-creation.json` e salvalo.
```
{
"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. Esegui il AWS CLI comando seguente dalla directory in cui hai salvato il file JSON nel passaggio precedente.
```
aws kafka create-cluster-v2 --cli-input-json file://cluster-creation.json
```
## Esegui il provisioning del throughput di storage durante la creazione di un cluster Amazon MSK utilizzando l'API
[Per configurare il throughput di storage assegnato durante la creazione di un cluster, usa V2. CreateCluster](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)
# Configurazione Amazon MSK Provisioned
Amazon MSK fornisce configurazioni predefinite per broker, argomenti e nodi di metadati. Puoi inoltre creare configurazioni personalizzate e utilizzarle per creare nuovi cluster MSK o per aggiornare cluster esistenti. Una configurazione MSK è costituita da un insieme di proprietà e dai relativi valori corrispondenti. A seconda del tipo di broker utilizzato nel cluster, esistono diversi set di impostazioni predefinite di configurazione e un diverso set di configurazioni che è possibile modificare. Consulta le sezioni seguenti per maggiori dettagli su come configurare i broker Standard ed Express.
**Topics**
+ [Configurazioni standard del broker](msk-configuration-standard.md)
+ [Configurazioni del broker Express](msk-configuration-express.md)
+ [Operazioni di configurazione del broker](msk-configuration-operations.md)
# Configurazioni standard del broker
Questa sezione descrive le proprietà di configurazione per i broker Standard.
**Topics**
+ [Configurazioni Amazon MSK personalizzate](msk-configuration-properties.md)
+ [Configurazione Amazon MSK predefinita](msk-default-configuration.md)
+ [Linee guida per la configurazione a livello di argomento dello storage su più livelli di Amazon MSK](msk-guidelines-tiered-storage-topic-level-config.md)
# Configurazioni Amazon MSK personalizzate
Puoi usare Amazon MSK per creare una configurazione MSK personalizzata in cui impostare le seguenti proprietà di configurazione di Apache Kafka. Le proprietà che non vengono impostate in modo esplicito ricevono i valori che hanno in [Configurazione Amazon MSK predefinita](msk-default-configuration.md). Per ulteriori informazioni sulle proprietà di configurazione, consulta la pagina relativa alla [configurazione di Apache Kafka](https://kafka.apache.org/documentation/#configuration).
| Nome | Description |
| --- | --- |
| allow.everyone.if.no.acl.found | Se desideri impostare questa proprietà sufalse, assicurati innanzitutto di definire Apache Kafka per il tuo cluster. ACLs Se imposti questa proprietà su false e non definisci prima Apache Kafka ACLs, perdi l'accesso al cluster. In tal caso, puoi aggiornare nuovamente la configurazione e impostare questa proprietà su true per ottenere nuovamente l'accesso al cluster. |
| auto.create.topics.enable | Abilita la creazione automatica di argomenti sul server. |
| compression.type | Il tipo di compressione finale per un determinato argomento. Puoi impostare questa proprietà sui codec di compressione standard (gzip, snappy, lz4 e zstd). Inoltre, accetta uncompressed. Questo valore equivale a nessuna compressione. Se imposti il valore su producer, significa mantenere il codec di compressione originale impostato dal produttore. |
| connections.max.idle.ms | Timeout delle connessioni inattive in millisecondi. I thread del processore dei socket del server chiudono le connessioni inattive per un periodo superiore al valore impostato per questa proprietà. |
| default.replication.factor | Il fattore di replica predefinito per argomenti creati automaticamente. |
| delete.topic.enable | Abilita l'operazione di eliminazione argomento. Se questa configurazione è disattivata, non è possibile eliminare un argomento tramite lo strumento di amministrazione. |
| group.initial.rebalance.delay.ms | Il tempo durante il quale il coordinatore del gruppo attende che altri consumatori si uniscano a un nuovo gruppo prima di eseguire il primo ribilanciamento. Un ritardo più lungo significa potenzialmente meno ribilanciamenti, ma aumenta il tempo prima dell'inizio dell'elaborazione. |
| group.max.session.timeout.ms | Timeout sessione massimo per i consumatori registrati. Timeout più lunghi offrono ai consumatori più tempo per elaborare i messaggi tra heartbeat, ma implicano un aumento del tempo richiesto per rilevare gli errori. |
| group.min.session.timeout.ms | Timeout sessione minimo per consumatori registrati. Timeout più brevi comportano un rilevamento più rapido degli errori, ma implicano un heartbeat dei consumatori più frequente. Ciò può sovraccaricare le risorse del broker. |
| leader.imbalance.per.broker.percentage | Il rapporto di squilibrio leader consentito per broker. Il controller attiva un bilanciamento dei leader se supera questo valore per broker. Questo valore è specificato in percentuale. |
| log.cleaner.delete.retention.ms | Quantità di tempo per cui Apache Kafka deve conservare i record eliminati. Il valore minimo è 0. |
| log.cleaner.min.cleanable.ratio | Questa proprietà di configurazione può avere valori compresi tra 0 e 1. Questo valore determina la frequenza con cui il compattatore di log tenta di pulire il log (se la compattazione dei log è abilitata). Per impostazione predefinita, Apache Kafka evita di pulire un log se più del 50% del log è stato compattato. Questo rapporto limita lo spazio massimo che il log spreca con i duplicati (al 50%, ciò significa che al massimo il 50% del log potrebbe essere duplicato). Un rapporto più elevato significa un numero inferiore, pulizie più efficienti, ma anche più spreco di spazio nel log. |
| log.cleanup.policy | La policy di pulizia predefinita per i segmenti oltre la finestra di conservazione. Un elenco separato da virgole di policy valide. Policy valide sono delete e compact. Per i cluster abilitati all'archiviazione a più livelli, è valida solo la policy delete. |
| log.flush.interval.messages | Numero di messaggi che si accumulano in una partizione di log prima che i messaggi vengano scaricati su disco. |
| log.flush.interval.ms | Tempo massimo, in millisecondi, di mantenimento in memoria di un messaggio in un argomento prima che venga scaricato su disco. Se questo valore non viene impostato, viene utilizzato il valore in log.flush.scheduler.interval.ms. Il valore minimo è 0. |
| log.message.timestamp.difference.max.ms | Questa configurazione è obsoleta in Kafka 3.6.0. Sono state aggiunte due configurazioni, e. log.message.timestamp.before.max.ms log.message.timestamp.after.max.ms La differenza massima consentita tra il timestamp del momento in cui un broker riceve un messaggio e il timestamp specificato nel messaggio. Se log.message.timestamp.type=CreateTime, un messaggio viene rifiutato se la differenza di timestamp supera questa soglia. Questa LogAppendTime configurazione viene ignorata se log.message.timestamp.type=. |
| log.message.timestamp.type | Specifica se il timestamp nel messaggio è l'ora di creazione del messaggio o l'ora di aggiunta del log. I valori consentiti sono CreateTime e LogAppendTime. |
| log.retention.bytes | Dimensione massima del log prima dell'eliminazione. |
| log.retention.hours | Numero di ore per cui mantenere un file di log prima di eliminarlo, terziario alla proprietà log.retention.ms. |
| log.retention.minutes | Numero di minuti per cui mantenere un file di log prima di eliminarlo, secondario alla proprietà log.retention.ms. Se questo valore non viene impostato, viene utilizzato il valore in log.retention.hours. |
| log.retention.ms | Numero di millisecondi per cui mantenere un file di log prima di eliminarlo. Se non è impostato, viene utilizzato il valore in log.retention.minutes. |
| log.roll.ms | Tempo massimo prima che un nuovo segmento di log venga distribuito (in millisecondi). Se questo valore non viene impostato, viene utilizzato il valore in log.roll.hours. Il valore minimo possibile per questa proprietà è 1. |
| log.segment.bytes | Dimensione massima di un singolo file di log. |
| max.incremental.fetch.session.cache.slots | Numero massimo di sessioni di recupero incrementali che vengono mantenute. |
| message.max.bytes | Dimensione massima del batch di record consentita da Kafka. Se aumenti questo valore e sono presenti consumatori più vecchi di 0.10.2, anche le dimensioni di recupero dei consumatori devono essere incrementate in modo che possano recuperare batch di record di queste dimensioni. Nella versione più recente del formato del messaggio, i messaggi vengono sempre raggruppati in batch per maggiore efficienza. Nelle versioni precedenti del formato del messaggio, i record non compressi non sono raggruppati in batch; in tal caso, questo limite si applica solo a un singolo record. Questo valore può essere impostato a livello di argomento con la configurazione max.message.bytes. |
| min.insync.replicas | Quando un produttore imposta le ACK su `"all"` (o `"-1"`), il valore in min.insync.replicas specifica il numero minimo di repliche che devono riconoscere una scrittura affinché questa sia considerata correttamente completata. Se questo minimo non può essere raggiunto, il produttore solleva un'eccezione (o). NotEnoughReplicas NotEnoughReplicasAfterAppend È possibile utilizzare i valori in min.insync.replicas e ACK per applicare maggiori garanzie di durabilità. Ad esempio, è possibile creare un argomento con un fattore di replica di 3, impostare min.insync.replicas su 2 e produrre con ACK di `"all"`. Ciò garantisce che il produttore generi un'eccezione se la maggior parte delle repliche non riceve una scrittura. |
| num.io.thread | Il numero di thread utilizzati dal server per elaborare le richieste, che possono includere I/O del disco. |
| num.network.threads | Il numero di thread utilizzati dal server per ricevere richieste dalla rete e inviarle le risposte. |
| num.partitions | Numero predefinito di partizioni di log per argomento. |
| num.recovery.threads.per.data.dir | Il numero di thread per directory di dati da utilizzare per il ripristino dei log all'avvio e per lo scaricamento all'arresto. |
| num.replica.fetchers | Il numero di thread fetcher utilizzati per rispondere ai messaggi da un broker di origine. Se aumenti questo valore, puoi aumentare il grado di I/O parallelismo nel broker di follower. |
| offsets.retention.minutes | Dopo che un gruppo di consumatori perde tutti i suoi consumatori (ovvero, diventa vuoto) i suoi offset vengono mantenuti per questo periodo di conservazione prima di essere scartati. Per i consumatori autonomi (ossia che utilizzano l'assegnazione manuale), gli offset scadono dopo l'ora dell'ultimo commit più questo periodo di conservazione. |
| offsets.topic.replication.factor | Il fattore di replica per l'argomento di offset. La selezione di un valore più alto garantisce la disponibilità. La creazione di argomenti interni non riesce fino a quando la dimensione del cluster non soddisfa questo requisito del fattore di replica. |
| replica.fetch.max.bytes | Numero di byte di messaggi da recuperare per ogni partizione. Questo valore non è un massimo assoluto. Se il primo batch di record nella prima partizione non vuota del recupero è più grande di questo valore, viene restituito il batch di record per garantire l'avanzamento. La proprietà message.max.bytes (configurazione broker) o max.message.bytes (configurazione argomento) specifica la dimensione massima del batch di record accettata dal broker. |
| replica.fetch.response.max.bytes | Il numero massimo di byte previsto per l'intera risposta di recupero. I record vengono recuperati in batch. Se il primo batch di record nella prima partizione non vuota del recupero è più grande di questo valore, il batch di record verrà comunque restituito per garantire l'avanzamento. Questo non è un massimo assoluto. Le proprietà message.max.bytes (configurazione broker) o max.message.bytes (configurazione argomento) specificano la dimensione massima del batch di record accettata dal broker. |
| replica.lag.time.max.ms | Se un follower non ha inviato richieste di fetch o non ha consumato fino all'offset di fine log del leader per almeno questo numero di millisecondi, il leader rimuove il follower dall'ISR.MinValue: 10000MaxValue = 30000 |
| replica.selector.class | Il nome completo della classe che implementa. ReplicaSelector Il broker utilizza questo valore per trovare la replica di lettura preferita. Se utilizzi Apache Kafka versione 2.4.1 o superiore e desideri consentire ai consumatori di recuperare dati dalla replica più vicina, imposta questa proprietà su org.apache.kafka.common.replica.RackAwareReplicaSelector. Per ulteriori informazioni, consulta [Apache Kafka versione 2.4.1 (usa invece 2.4.1.1)](supported-kafka-versions.md#2.4.1). |
| replica.socket.receive.buffer.bytes | Il buffer di ricezione socket per le richieste di rete. |
| socket.receive.buffer.bytes | Buffer SO\$1RCVBUF dei socket del server dei socket. Il valore minimo che è possibile impostare per questa proprietà è -1. Se il valore è -1, Amazon MSK utilizza il sistema operativo predefinito. |
| socket.request.max.bytes | Il numero massimo di byte in una richiesta socket. |
| socket.send.buffer.bytes | Buffer SO\$1SNDBUF dei socket del server dei socket. Il valore minimo che è possibile impostare per questa proprietà è -1. Se il valore è -1, Amazon MSK utilizza il sistema operativo predefinito. |
| transaction.max.timeout.ms | Timeout massimo per transazioni. Se il tempo di transazione richiesto da un cliente supera questo valore, il broker restituisce un errore in. InitProducerIdRequest Ciò evita un timeout troppo elevato per un client, che può rallentare i consumatori che leggono dagli argomenti inclusi nella transazione. |
| transaction.state.log.min.isr | Configurazione min.insync.replicas ignorata per l'argomento di transazione. |
| transaction.state.log.replication.factor | Il fattore di replica per l'argomento di transazione. La selezione di un valore più alto per questa proprietà aumenta la disponibilità. La creazione di argomenti interni non riesce fino a quando la dimensione del cluster non soddisfa questo requisito del fattore di replica. |
| transactional.id.expiration.ms | Il tempo in millisecondi durante il quale il coordinatore della transazione attende di ricevere eventuali aggiornamenti sullo stato delle transazioni per la transazione corrente prima che il coordinatore faccia scadere il proprio ID transazionale. Questa impostazione influenza anche la scadenza dell'ID del produttore perché fa IDs scadere il produttore quando questo tempo trascorre dopo l'ultima scrittura con l'ID produttore specificato. Producer IDs potrebbe scadere prima se l'ultima scrittura dall'ID produttore viene eliminata a causa delle impostazioni di conservazione dell'argomento. Il valore minimo per questa proprietà è 1 millisecondo. |
| unclean.leader.election.enable | Indica se le repliche non incluse nel set ISR devono fungere da leader come ultima risorsa, anche se ciò potrebbe comportare la perdita di dati. |
| zookeeper.connection.timeout.ms | ZooKeeper cluster di modalità. Tempo massimo di attesa del client per stabilire una connessione. ZooKeeper Se questo valore non viene impostato, viene utilizzato il valore fornito in zookeeper.session.timeout.ms. MinValue = 6000 MaxValue (incluso) = 18000 Ti consigliamo di impostare questo valore su 10.000 su T3.small per evitare tempi di inattività del cluster. |
| zookeeper.session.timeout.ms | ZooKeeper cluster di modalità. Il timeout della ZooKeeper sessione Apache in millisecondi. MinValue = 6000 MaxValue (incluso) = 18000 |
Per informazioni su come creare una configurazione MSK personalizzata, elencare tutte le configurazioni o descriverle, consulta [Operazioni di configurazione del broker](msk-configuration-operations.md). Per creare un cluster MSK utilizzando una configurazione MSK personalizzata o per aggiornare un cluster con una nuova configurazione personalizzata, consulta la pagina [Caratteristiche e concetti chiave di Amazon MSK](operations.md).
Quando si aggiorna il cluster MSK esistente con una configurazione MSK personalizzata, Amazon MSK esegue riavvii in sequenza quando necessario e utilizza le best practice per ridurre al minimo i tempi di inattività del cliente. Ad esempio, dopo aver riavviato ogni broker, Amazon MSK prova a lasciare che il broker recuperi i dati che potrebbe aver perso durante l'aggiornamento della configurazione prima di passare al broker successivo.
## Configurazione dinamica di Amazon MSK
Oltre alle proprietà di configurazione fornite da Amazon MSK, puoi impostare dinamicamente le proprietà di configurazione a livello di cluster e broker che non richiedono un riavvio del broker. È possibile impostare dinamicamente alcune proprietà di configurazione. Si tratta delle proprietà che non sono contrassegnate come di sola lettura nella tabella in [Broker Configs](https://kafka.apache.org/documentation/#brokerconfigs) nella documentazione di Apache Kafka. Per informazioni sulla configurazione dinamica e sui comandi di esempio, consulta la pagina [Updating Broker Configs](https://kafka.apache.org/documentation/#dynamicbrokerconfigs) nella documentazione di Apache Kafka.
**Nota**
Puoi impostare la proprietà `advertised.listeners`, ma non la proprietà `listeners`.
## Configurazione Amazon MSK a livello di argomento
Puoi utilizzare i comandi Apache Kafka per impostare o modificare le proprietà di configurazione a livello dell'argomento per argomenti nuovi ed esistenti. Per ulteriori informazioni sulle proprietà di configurazione a livello di argomento ed esempi di come impostarle, consulta la pagina [Topic-Level Configs](https://kafka.apache.org/documentation/#topicconfigs) nella documentazione ufficiale di Apache Kafka.
# Configurazione Amazon MSK predefinita
Quando crei un cluster MSK senza specificare una configurazione MSK personalizzata, Amazon MSK crea e utilizza una configurazione predefinita con i valori visualizzati nella tabella seguente. Per le proprietà non presenti in questa tabella, Amazon MSK utilizza i valori predefiniti associati alla versione di Apache Kafka. Per un elenco di questi valori predefiniti, consulta la pagina relativa alla [configurazione di Apache Kafka](https://kafka.apache.org/documentation/#configuration).
| Nome | Description | Valore predefinito per il cluster con l'archiviazione non a più livelli | Valore predefinito per il cluster abilitato all'archiviazione a più livelli |
| --- | --- | --- | --- |
| allow.everyone.if.no.acl.found | Se nessun modello di risorsa corrisponde a una risorsa specifica, la risorsa non è associata ACLs. In questo caso, se questa proprietà è impostata su true, tutti possono accedere alla risorsa, non solo i superutenti. | true | true |
| auto.create.topics.enable | Abilita la creazione automatica di un argomento sul server. | false | false |
| auto.leader.rebalance.enable | Consente il bilanciamento leader automatico. Un thread in background controlla e attiva il bilanciamento del leader a intervalli regolari, se necessario. | true | true |
| default.replication.factor | Fattori di replica predefiniti per argomenti creati automaticamente. | 3 per i cluster in 3 zone di disponibilità e 2 per i cluster in 2 zone di disponibilità. | 3 per i cluster in 3 zone di disponibilità e 2 per i cluster in 2 zone di disponibilità. |
| local.retention.bytes | La dimensione massima dei segmenti di log locali per una partizione prima dell'eliminazione dei vecchi segmenti. Se questo valore non viene impostato, viene utilizzato il valore in log.retention.bytes. Il valore effettivo deve essere sempre minore o uguale al valore di log.retention.bytes. Il valore predefinito -2 indica che non è previsto un limite alla conservazione locale. Ciò corrisponde all'impostazione retention.ms/bytes di -1. Le proprietà local.retention.ms e local.retention.bytes sono simili a log.retention, in quanto vengono utilizzate per determinare per quanto tempo i segmenti di log devono rimanere nell'archiviazione locale. Le configurazioni log.retention.\$1 esistenti sono configurazioni di conservazione per la partizione degli argomenti. Ciò include l'archiviazione locale e remota. Valori validi: numeri interi in [-2; \$1Inf] | -2 per illimitato | -2 per illimitato |
| local.retention.ms | Numero di millisecondi di conservazione del segmento di log locale prima dell'eliminazione. Se questo valore non viene impostato, Amazon MSK utilizza il valore in log.retention.ms. Il valore effettivo deve essere sempre minore o uguale al valore di log.retention.bytes. Il valore predefinito -2 indica che non è previsto un limite alla conservazione locale. Ciò corrisponde all'impostazione retention.ms/bytes di -1.I valori local.retention.ms e local.retention.bytes sono simili a log.retention. MSK utilizza questa configurazione per determinare per quanto tempo i segmenti di log devono rimanere nell'archiviazione locale. Le configurazioni log.retention.\$1 esistenti sono configurazioni di conservazione per la partizione degli argomenti. Ciò include l'archiviazione locale e remota. I valori validi sono numeri interi maggiori di 0. | -2 per illimitato | -2 per illimitato |
| log.message.timestamp.difference.max.ms | Questa configurazione è obsoleta in Kafka 3.6.0. Sono state aggiunte due configurazioni, e. log.message.timestamp.before.max.ms log.message.timestamp.after.max.ms La differenza massima consentita tra il timestamp quando un broker riceve un messaggio e il timestamp specificato nel messaggio. Se log.message.timestamp.type=CreateTime, un messaggio verrà rifiutato se la differenza di timestamp supera questa soglia. Questa configurazione viene ignorata se log.message.timestamp.type=. LogAppendTime La differenza di timestamp massima consentita non deve essere maggiore di log.retention.ms per evitare una distribuzione dei log inutilmente frequente. | 9223372036854775807 | 86400000 per Kafka 2.8.2.tiered e Kafka 3.7.x a più livelli. |
| log.segment.bytes | Dimensione massima di un singolo file di log. | 1073741824 | 134217728 |
| min.insync.replicas | Quando un produttore imposta il valore delle ACK (il riconoscimento che il produttore riceve dal broker Kafka) su `"all"` (o `"-1"`), il valore in min.insync.replicas specifica il numero minimo di repliche che devono riconoscere una scrittura affinché questa sia considerata correttamente completata. Se questo valore non soddisfa questo minimo, il produttore solleva un'eccezione (o). NotEnoughReplicas NotEnoughReplicasAfterAppend Se usati insieme, i valori min.insync.replicas e ACK consentono di imporre maggiori garanzie di durata. Ad esempio, è possibile creare un argomento con un fattore di replica di 3, impostare min.insync.replicas su 2 e produrre con ACK di `"all"`. Ciò garantisce che il produttore generi un'eccezione se la maggior parte delle repliche non riceve una scrittura. | 2 per i cluster in 3 zone di disponibilità e 1 per i cluster in 2 zone di disponibilità. | 2 per i cluster in 3 zone di disponibilità e 1 per i cluster in 2 zone di disponibilità. |
| num.io.thread | Numero di thread utilizzati dal server per produrre le richieste, che possono includere l'I/O del disco. | 8 | max (8, vCPUs) dove v CPUs dipende dalla dimensione dell'istanza del broker |
| num.network.threads | Numero di thread utilizzati dal server per ricevere richieste dalla rete e inviare risposte alla rete. | 5 | max (5, vCPUs /2) dove v CPUs dipende dalla dimensione dell'istanza del broker |
| num.partitions | Numero predefinito di partizioni di log per argomento. | 1 | 1 |
| num.replica.fetchers | Numero di thread fetcher utilizzati per replicare i messaggi da un broker di origine. Se si aumenta questo valore, è possibile aumentare il grado di parallelismo nel broker di I/O follower. | 2 | max (2, vCPUs /4) dove v dipende dalla dimensione dell'istanza del broker CPUs |
| remote.log.msk.disable.policy | Utilizzato con remote.storage.enable per disabilitare l'archiviazione a più livelli. Imposta questa policy su Elimina per indicare che i dati nell'archiviazione a più livelli vengono eliminati quando si imposta remote.storage.enable su false. | N/D | Nessuno |
| remote.log.reader.threads | La dimensione del pool di thread del lettore di log remoto, utilizzato nella pianificazione delle attività per recuperare dati dall'archiviazione remota. | N/D | max (10, v CPUs \$1 0.67) dove v CPUs dipende dalla dimensione dell'istanza del broker |
| remote.storage.enable | Abilita l'archiviazione a più livelli (remota) per un argomento, se impostato su true. Disabilita l'archiviazione a più livelli a livello di argomento se impostato su false e remote.log.msk.disable.policy è impostato su Delete. Quando si disabilita l'archiviazione a più livelli, si eliminano i dati dall'archiviazione remota. Una volta disabilitata l'archiviazione a più livelli su un argomento, non sarà possibile riabilitarla. | false | false |
| replica.lag.time.max.ms | Se un follower non ha inviato richieste di fetch o non ha consumato fino all'offset di fine log del leader per almeno questo numero di millisecondi, il leader rimuove il follower dall'ISR. | 30000 | 30000 |
| retention.ms | Campo obbligatorio. Il tempo minimo è 3 giorni. Non esiste un'impostazione predefinita perché l'impostazione è obbligatoria. Amazon MSK utilizza il valore retention.ms con local.retention.ms per determinare quando i dati vengono spostati dall'archiviazione locale a quella a più livelli. Il valore local.retention.ms specifica quando spostare i dati dall'archiviazione locale a quella a più livelli. Il valore retention.ms specifica quando rimuovere i dati dallo storage su più livelli (ovvero, rimossi dal cluster). Valori validi: numeri interi in [-1; \$1Inf] | Minimo 259.200.000 millisecondi (3 giorni). -1 per una conservazione infinita. | Minimo 259.200.000 millisecondi (3 giorni). -1 per una conservazione infinita. |
| socket.receive.buffer.bytes | Buffer SO\$1RCVBUF dei socket del server dei socket. Se il valore è -1, viene utilizzato il sistema operativo predefinito. | 102400 | 102400 |
| socket.request.max.bytes | Numero massimo di byte in una richiesta socket. | 104857600 | 104857600 |
| socket.send.buffer.bytes | Buffer SO\$1SNDBUF dei socket del server dei socket. Se il valore è -1, viene utilizzato il sistema operativo predefinito. | 102400 | 102400 |
| unclean.leader.election.enable | Indica se desideri che le repliche non incluse nel set ISR fungano da leader come ultima risorsa, anche se ciò potrebbe comportare la perdita di dati. | true | false |
| zookeeper.session.timeout.ms | Il timeout della sessione Apache in millisecondi. ZooKeeper | 18000 | 18000 |
| zookeeper.set.acl | Il client impostato da usare secure. ACLs | false | false |
Per informazioni su come specificare valori di configurazione personalizzati, vedere[Configurazioni Amazon MSK personalizzate](msk-configuration-properties.md).
# Linee guida per la configurazione a livello di argomento dello storage su più livelli di Amazon MSK
Di seguito sono riportate le impostazioni e le limitazioni predefinite per la configurazione dell'archiviazione a più livelli a livello di argomento.
+ Amazon MSK non supporta segmenti di log di dimensioni inferiori per argomenti con l'archiviazione a più livelli attivata. Se si desidera creare un segmento, è prevista una dimensione minima del segmento di log di 48 MiB o un tempo minimo di distribuzione del segmento di 10 minuti. Questi valori sono mappati alle proprietà segment.bytes e segment.ms.
+ Il valore di local.retention. ms/bytes can't equal or exceed the retention.ms/bytes. Questa è l'impostazione di conservazione dell'archiviazione a più livelli.
+ Il valore predefinito per local.retention. ms/bytes is -2. This means that the retention.ms value is used for local.retention.ms/bytes. In questo caso, i dati rimangono sia nell'archiviazione locale sia nell'archiviazione a più livelli (una copia per ciascuna) e scadono insieme. Con questa opzione, una copia dei dati locali viene memorizzata nell'archiviazione remota. In questo caso, i dati letti dal traffico di utilizzo provengono dall'archiviazione locale.
+ Il valore predefinito per retention.ms è 7 giorni. Non esiste un limite di dimensione predefinito per retention.bytes.
+ Il valore minimo per retention.ms/bytes è -1. Ciò significa una conservazione infinita.
+ Il valore minimo per local.retention. ms/bytes is -2. This means infinite retention for local storage. It matches with the retention.ms/bytesimpostazione come -1.
+ La configurazione a livello di argomento retention.ms è obbligatoria per gli argomenti con lo storage su più livelli attivato. Il valore minimo per retention.ms è 3 giorni.
Per ulteriori informazioni sui vincoli di storage su più livelli, vedere. [Vincoli e limitazioni dello storage su più livelli per i cluster Amazon MSK](msk-tiered-storage.md#msk-tiered-storage-constraints)
# Configurazioni del broker Express
Apache Kafka dispone di centinaia di configurazioni di broker che puoi utilizzare per ottimizzare le prestazioni del tuo cluster MSK Provisioned. L'impostazione di valori errati o non ottimali può influire sull'affidabilità e sulle prestazioni del cluster. I broker Express migliorano la disponibilità e la durata dei cluster MSK Provisioned impostando valori ottimali per le configurazioni critiche e proteggendole dai comuni errori di configurazione. [Esistono tre categorie di configurazioni basate sull'accesso in lettura e scrittura: configurazioni di lettura/scrittura [(modificabili), di sola lettura e non di lettura/scrittura](msk-configuration-express-read-write.md).](msk-configuration-express-read-only.md) Alcune configurazioni utilizzano ancora il valore predefinito di Apache Kafka per la versione di Apache Kafka in esecuzione sul cluster. Le contrassegniamo come Apache Kafka Default.
**Topics**
+ [Configurazioni personalizzate del broker MSK Express (accesso in lettura/scrittura)](msk-configuration-express-read-write.md)
+ [Configurazioni di sola lettura di Express Brokers](msk-configuration-express-read-only.md)
# Configurazioni personalizzate del broker MSK Express (accesso in lettura/scrittura)
Puoi aggiornare le configurazioni dei read/write broker utilizzando la [funzionalità di aggiornamento della configurazione](msk-update-cluster-config.md) di Amazon MSK o l'API di Apache Kafka. AlterConfig Le configurazioni del broker Apache Kafka sono statiche o dinamiche. Le configurazioni statiche richiedono il riavvio del broker per poter applicare la configurazione, mentre le configurazioni dinamiche non richiedono il riavvio del broker. Per ulteriori informazioni sulle proprietà di configurazione e sulle modalità di aggiornamento, vedere [Aggiornamento delle configurazioni del broker](https://kafka.apache.org/documentation/#dynamicbrokerconfigs).
**Topics**
+ [Configurazioni statiche sui broker MSK Express](#msk-configuration-express-static-configuration)
+ [Configurazioni dinamiche su Express Brokers](#msk-configuration-express-dynamic-configuration)
+ [Configurazioni a livello di argomento su Express Brokers](#msk-configuration-express-topic-configuration)
## Configurazioni statiche sui broker MSK Express
Puoi usare Amazon MSK per creare un file di configurazione MSK personalizzato per impostare le seguenti proprietà statiche. Amazon MSK imposta e gestisce tutte le altre proprietà che non hai impostato. È possibile creare e aggiornare file di configurazione statici dalla console MSK o utilizzando il comando [configurations](msk-configuration-operations-create.md).
| Proprietà | Description | Valore predefinito |
| --- | --- | --- |
| allow.everyone.if.no.acl.found | Se vuoi impostare questa proprietà su false, assicurati innanzitutto di definire Apache Kafka ACLs per il tuo cluster. Se impostate questa proprietà su false e non definite prima Apache Kafka ACLs, perderete l'accesso al cluster. In tal caso, puoi aggiornare nuovamente la configurazione e impostare questa proprietà su true per riottenere l'accesso al cluster. | true |
| auto.create.topics.enable | Abilita la creazione automatica di un argomento sul server. | false |
| compression.type | Specificate il tipo di compressione finale per un determinato argomento. Questa configurazione accetta i codec di compressione standard: gzip, snappy, lz4, zstd. Questa configurazione accetta inoltre`uncompressed`, il che equivale a non comprimere nulla`producer`, e ciò significa mantenere il codec di compressione originale impostato dal produttore. | Apache Kafka (impostazione predefinita) |
| connections.max.idle.ms | Timeout delle connessioni inattive in millisecondi. I thread del processore dei socket del server chiudono le connessioni inattive per un periodo superiore al valore impostato per questa proprietà. | Apache Kafka predefinito |
| delete.topic.enable | Abilita l'operazione di eliminazione argomento. Se questa configurazione è disattivata, non è possibile eliminare un argomento tramite lo strumento di amministrazione. | Apache Kafka predefinito |
| group.initial.rebalance.delay.ms | Il tempo durante il quale il coordinatore del gruppo attende che altri consumatori si uniscano a un nuovo gruppo prima di eseguire il primo ribilanciamento. Un ritardo più lungo significa potenzialmente meno ribilanciamenti, ma aumenta il tempo prima dell'inizio dell'elaborazione. | Apache Kafka predefinito |
| group.max.session.timeout.ms | Timeout sessione massimo per i consumatori registrati. Timeout più lunghi offrono ai consumatori più tempo per elaborare i messaggi tra heartbeat, ma implicano un aumento del tempo richiesto per rilevare gli errori. | Apache Kafka predefinito |
| leader.imbalance.per.broker.percentage | Il rapporto di squilibrio leader consentito per broker. Il controller attiva un bilanciamento dei leader se supera questo valore per broker. Questo valore è specificato in percentuale. | Apache Kafka predefinito |
| log.cleanup.policy | La policy di pulizia predefinita per i segmenti oltre la finestra di conservazione. Un elenco separato da virgole di policy valide. Policy valide sono delete e compact. Per i cluster abilitati allo storage su più livelli, è valida solo la policy. delete | Apache Kafka (impostazione predefinita) |
| log.message.timestamp.after.max.ms | La differenza di timestamp consentita tra il timestamp del messaggio e il timestamp del broker. Il timestamp del messaggio può essere successivo o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`log.message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `log.message.timestamp.type=LogAppendTime` | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno) |
| log.message.timestamp.before.max.ms | La differenza di timestamp consentita tra il timestamp del broker e il timestamp del messaggio. Il timestamp del messaggio può essere precedente o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`log.message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `log.message.timestamp.type=LogAppendTime` | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno) |
| log.message.timestamp.type | Specifica se il timestamp nel messaggio è l'ora di creazione del messaggio o l'ora di aggiunta del log. I valori consentiti sono CreateTime e LogAppendTime. | Apache Kafka predefinito |
| log.retention.bytes | Dimensione massima del log prima dell'eliminazione. | Apache Kafka predefinito |
| log.retention.ms | Numero di millisecondi per conservare un file di registro prima di eliminarlo. | Apache Kafka (impostazione predefinita) |
| numero massimo di connessioni per ip | Il numero massimo di connessioni consentite da ogni indirizzo IP. Questo valore può essere impostato su 0 se sono presenti sostituzioni configurate utilizzando la max.connections.per.ip.overrides proprietà. Le nuove connessioni dall'indirizzo IP vengono interrotte se viene raggiunto il limite. | Apache Kafka (impostazione predefinita) |
| max.incremental.fetch.session.cache.slots | Numero massimo di sessioni di recupero incrementali che vengono mantenute. | Apache Kafka predefinito |
| message.max.bytes | Dimensione massima del batch di record consentita da Kafka. Se aumenti questo valore e sono presenti consumatori più vecchi di 0.10.2, anche le dimensioni di recupero dei consumatori devono essere incrementate in modo che possano recuperare batch di record di queste dimensioni. Nella versione più recente del formato del messaggio, i messaggi vengono sempre raggruppati in batch per maggiore efficienza. Nelle versioni precedenti del formato del messaggio, i record non compressi non sono raggruppati in batch; in tal caso, questo limite si applica solo a un singolo record. Puoi impostare questo valore per argomento con la configurazione a livello di argomento. `max.message.bytes` | Apache Kafka predefinito |
| num.partitions | Numero predefinito di partizioni per argomento. | 1 |
| offsets.retention.minutes | Dopo che un gruppo di consumatori perde tutti i suoi consumatori (ovvero, diventa vuoto) i suoi offset vengono mantenuti per questo periodo di conservazione prima di essere scartati. Per i consumatori autonomi (ovvero quelli che utilizzano l'assegnazione manuale), gli offset scadono dopo l'ultimo commit più questo periodo di conservazione. | Apache Kafka predefinito |
| replica.fetch.max.bytes | Numero di byte di messaggi da recuperare per ogni partizione. Questo valore non è un massimo assoluto. Se il primo batch di record nella prima partizione non vuota del recupero è più grande di questo valore, viene restituito il batch di record per garantire l'avanzamento. La proprietà message.max.bytes (configurazione broker) o max.message.bytes (configurazione argomento) specifica la dimensione massima del batch di record accettata dal broker. | Apache Kafka predefinito |
| replica.selector.class | Il nome completo della classe che implementa. ReplicaSelector Il broker utilizza questo valore per trovare la replica di lettura preferita. Se desideri consentire ai consumatori di eseguire il recupero dalla replica più vicina, imposta questa proprietà su. `org.apache.kafka.common.replica.RackAwareReplicaSelector` | Apache Kafka (impostazione predefinita) |
| socket.receive.buffer.bytes | Buffer SO\$1RCVBUF dei socket del server dei socket. Se il valore è -1, viene utilizzato il sistema operativo predefinito. | 102400 |
| socket.request.max.bytes | Numero massimo di byte in una richiesta socket. | 104857600 |
| socket.send.buffer.bytes | Buffer SO\$1SNDBUF dei socket del server dei socket. Se il valore è -1, viene utilizzato il sistema operativo predefinito. | 102400 |
| transaction.max.timeout.ms | Timeout massimo per transazioni. Se il tempo di transazione richiesto da un cliente supera questo valore, il broker restituisce un errore in. InitProducerIdRequest Ciò evita un timeout troppo elevato per un client, che può rallentare i consumatori che leggono dagli argomenti inclusi nella transazione. | Apache Kafka (impostazione predefinita) |
| transactional.id.expiration.ms | Il tempo in millisecondi durante il quale il coordinatore della transazione attende di ricevere eventuali aggiornamenti sullo stato delle transazioni per la transazione corrente prima che il coordinatore faccia scadere il proprio ID transazionale. Questa impostazione influenza anche la scadenza dell'ID del produttore perché fa scadere IDs il produttore quando questo tempo è trascorso dall'ultima scrittura con l'ID produttore specificato. Producer IDs potrebbe scadere prima se l'ultima scrittura dall'ID produttore viene eliminata a causa delle impostazioni di conservazione dell'argomento. Il valore minimo per questa proprietà è 1 millisecondo. | Apache Kafka (impostazione predefinita) |
## Configurazioni dinamiche su Express Brokers
Puoi utilizzare l' AlterConfig API Apache Kafka o lo strumento Kafka-configs.sh per modificare le seguenti configurazioni dinamiche. Amazon MSK imposta e gestisce tutte le altre proprietà che non hai impostato. Puoi impostare dinamicamente proprietà di configurazione a livello di cluster e di broker che non richiedono il riavvio del broker.
| Proprietà | Description | Valore predefinito |
| --- | --- | --- |
| advertised.listeners | Listener da pubblicare per l'utilizzo da parte dei client, se diversi dalla proprietà config. `listeners` Negli ambienti IaaS, potrebbe essere necessario che questa sia diversa dall'interfaccia a cui si collega il broker. Se questo non è impostato, verrà utilizzato il valore per gli ascoltatori. A differenza degli ascoltatori, non è valido pubblicizzare il meta-indirizzo 0.0.0.0. Inoltre`listeners`, a differenza di questa proprietà, possono esserci porte duplicate, in modo che un listener possa essere configurato per annunciare l'indirizzo di un altro listener. Ciò può essere utile in alcuni casi in cui vengono utilizzati sistemi di bilanciamento del carico esterni. Questa proprietà è impostata a livello di broker. | null |
| compression.type | Il tipo di compressione finale per un determinato argomento. Puoi impostare questa proprietà sui codec di compressione standard (`gzip`, `snappy`, `lz4` e `zstd`). Inoltre, accetta `uncompressed`. Questo valore equivale a nessuna compressione. Se imposti il valore su `producer`, significa mantenere il codec di compressione originale impostato dal produttore. | Apache Kafka predefinito |
| log.cleaner.delete.retention.ms | Il periodo di tempo necessario per conservare i marker di eliminazione di tombstone per gli argomenti con log compattati. Questa impostazione stabilisce anche un limite al tempo in cui un consumatore deve completare una lettura se inizia dall'offset 0 per assicurarsi di ottenere un'istantanea valida della fase finale. Altrimenti, le lapidi eliminate potrebbero essere raccolte prima che completino la scansione. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno), Apache Kafka Default |
| log.cleaner.min.compaction.lag.ms | Il periodo minimo di tempo in cui un messaggio rimarrà non compattato nel registro. Questa impostazione è applicabile solo ai log che vengono compattati. | 0, Apache Kafka predefinito |
| log.cleaner.max.compaction.lag.ms | Il periodo massimo di tempo in cui un messaggio rimarrà non idoneo per la compattazione nel registro. Questa impostazione è applicabile solo ai log che vengono compattati. Questa configurazione sarebbe limitata all'intervallo di [7 giorni, Long.Max]. | 9223372036854775807, impostazione predefinita di Apache Kafka |
| log.cleanup.policy | La policy di pulizia predefinita per i segmenti oltre la finestra di conservazione. Un elenco separato da virgole di policy valide. Policy valide sono `delete` e `compact`. Per i cluster abilitati allo storage su più livelli, è valida solo la policy. `delete` | Apache Kafka (impostazione predefinita) |
| log.message.timestamp.after.max.ms | La differenza di timestamp consentita tra il timestamp del messaggio e il timestamp del broker. Il timestamp del messaggio può essere successivo o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`log.message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `log.message.timestamp.type=LogAppendTime` | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno) |
| log.message.timestamp.before.max.ms | La differenza di timestamp consentita tra il timestamp del broker e il timestamp del messaggio. Il timestamp del messaggio può essere precedente o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`log.message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `log.message.timestamp.type=LogAppendTime` | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno) |
| log.message.timestamp.type | Specifica se il timestamp nel messaggio è l'ora di creazione del messaggio o l'ora di aggiunta del log. I valori consentiti sono `CreateTime` e `LogAppendTime`. | Apache Kafka predefinito |
| log.retention.bytes | Dimensione massima del log prima dell'eliminazione. | Apache Kafka predefinito |
| log.retention.ms | Numero di millisecondi per conservare un file di registro prima di eliminarlo. | Apache Kafka (impostazione predefinita) |
| max.connection.creation.rate | La velocità massima di creazione della connessione consentita nel broker in qualsiasi momento. | Apache Kafka (impostazione predefinita) |
| numero massimo di connessioni | Il numero massimo di connessioni consentite nel broker in qualsiasi momento. Questo limite viene applicato in aggiunta a qualsiasi limite per IP configurato utilizzando. `max.connections.per.ip` | Apache Kafka (impostazione predefinita) |
| numero massimo di connessioni per ip | Il numero massimo di connessioni consentite da ogni indirizzo IP. Questo valore può essere impostato su `0` se sono presenti sostituzioni configurate utilizzando la proprietà max.connections.per.ip.overrides. Le nuove connessioni dall'indirizzo IP vengono interrotte se viene raggiunto il limite. | Apache Kafka (impostazione predefinita) |
| max.connections.per.ip.overrides | Un elenco separato da virgole di per-ip o nome host sostituisce il numero massimo predefinito di connessioni. Un valore di esempio è `hostName:100,127.0.0.1:200` | Apache Kafka predefinito |
| message.max.bytes | Dimensione massima del batch di record consentita da Kafka. Se aumenti questo valore e sono presenti consumatori più vecchi di 0.10.2, anche le dimensioni di recupero dei consumatori devono essere incrementate in modo che possano recuperare batch di record di queste dimensioni. Nella versione più recente del formato del messaggio, i messaggi vengono sempre raggruppati in batch per maggiore efficienza. Nelle versioni precedenti del formato del messaggio, i record non compressi non sono raggruppati in batch; in tal caso, questo limite si applica solo a un singolo record. Puoi impostare questo valore per argomento con la configurazione a livello di argomento. `max.message.bytes` | Apache Kafka predefinito |
| producer.id.expiration.ms | Il tempo in ms che il leader della partizione di un argomento aspetterà prima che il produttore scada. IDs Il produttore non IDs scadrà finché una transazione ad esso associata è ancora in corso. Tieni presente che producer IDs potrebbe scadere prima se l'ultima scrittura dall'ID del produttore viene eliminata a causa delle impostazioni di conservazione dell'argomento. L'impostazione di questo valore uguale o superiore a `delivery.timeout.ms` può aiutare a prevenire la scadenza durante i nuovi tentativi e a proteggere dalla duplicazione dei messaggi, ma l'impostazione predefinita dovrebbe essere ragionevole per la maggior parte dei casi d'uso. | Apache Kafka predefinito |
## Configurazioni a livello di argomento su Express Brokers
Puoi utilizzare i comandi Apache Kafka per impostare o modificare le proprietà di configurazione a livello dell'argomento per argomenti nuovi ed esistenti. Se non puoi fornire alcuna configurazione a livello di argomento, Amazon MSK utilizza il broker predefinito. Come per le configurazioni a livello di broker, Amazon MSK protegge alcune proprietà di configurazione a livello di argomento da eventuali modifiche. Gli esempi includono il fattore di replica e. `min.insync.replicas` `unclean.leader.election.enable` Se tenti di creare un argomento con un valore del fattore di replica diverso da`3`, Amazon MSK creerà l'argomento con un fattore di replica di `3` default. Per ulteriori informazioni sulle proprietà di configurazione a livello di argomento ed esempi di come impostarle, consulta la pagina [Topic-Level Configs](https://kafka.apache.org/documentation/#topicconfigs) nella documentazione ufficiale di Apache Kafka.
| Proprietà | Description |
| --- | --- |
| cleanup.policy | Questa configurazione indica la politica di conservazione da utilizzare sui segmenti di log. La politica di «eliminazione» (che è l'impostazione predefinita) eliminerà i vecchi segmenti una volta raggiunto il tempo di conservazione o il limite di dimensione. La politica «compatta» consentirà la compattazione dei log, che conserva il valore più recente per ogni chiave. È anche possibile specificare entrambe le politiche in un elenco separato da virgole (ad esempio, «delete, compact»). In questo caso, i vecchi segmenti verranno eliminati in base alla configurazione del tempo di conservazione e delle dimensioni, mentre i segmenti mantenuti verranno compattati. La compattazione sui broker Express viene attivata dopo che i dati in una partizione raggiungono i 256 MB. |
| compression.type | Specificate il tipo di compressione finale per un determinato argomento. Questa configurazione accetta i codec di compressione standard (`gzip`,, `snappy``lz4`,`zstd`). Accetta inoltre ciò `uncompressed` che equivale a nessuna compressione; il `producer` che significa mantenere il codec di compressione originale impostato dal produttore. |
| delete.retention.ms | Il periodo di tempo necessario per conservare i marker di eliminazione di tombstone per gli argomenti con log compattati. Questa impostazione stabilisce anche un limite al tempo in cui un consumatore deve completare una lettura se inizia dall'offset 0 per assicurarsi di ottenere un'istantanea valida della fase finale. Altrimenti, le lapidi eliminate potrebbero essere raccolte prima che completino la scansione. Il valore predefinito per questa impostazione è 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ovvero 1 giorno), Apache Kafka Default |
| max.message.bytes | La dimensione massima del batch di record consentita da Kafka (dopo la compressione, se la compressione è abilitata). Se questa cifra aumenta e ci sono consumatori più vecchi di età`0.10.2`, è necessario aumentare anche la dimensione di recupero dei consumatori in modo che possano recuperare batch di dischi di dimensioni così grandi. Nella versione più recente del tipo di formato, i record vengono sempre raggruppati in batch ai fini dell'efficienza. Nelle versioni precedenti del tipo di formato, i record non compressi non sono raggruppati in batch e questo limite si applica solo a un singolo record in quel caso. Questo può essere impostato per argomento con il livello dell'argomento. `max.message.bytes config` |
| messaggio.timestamp.after.max.ms | Questa configurazione imposta la differenza di timestamp consentita tra il timestamp del messaggio e il timestamp del broker. Il timestamp del messaggio può essere successivo o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `message.timestamp.type=LogAppendTime` |
| message.timestamp.before.max.ms | Questa configurazione imposta la differenza di timestamp consentita tra il timestamp del broker e il timestamp del messaggio. Il timestamp del messaggio può essere precedente o uguale al timestamp del broker, con la differenza massima consentita determinata dal valore impostato in questa configurazione. Se`message.timestamp.type=CreateTime`, il messaggio verrà rifiutato se la differenza nei timestamp supera la soglia specificata. Questa configurazione viene ignorata se. `message.timestamp.type=LogAppendTime` |
| message.timestamp.type | Definisce se il timestamp nel messaggio è l'ora di creazione del messaggio o l'ora di aggiunta del registro. Il valore deve essere o `CreateTime` `LogAppendTime` |
| min.compaction.lag.ms | Il periodo minimo di tempo in cui un messaggio rimarrà non compattato nel registro. Questa impostazione è applicabile solo ai log che vengono compattati. Il valore predefinito per questa impostazione è 0, Apache Kafka Default |
| max.compaction.lag.ms | Il periodo massimo di tempo in cui un messaggio rimarrà non idoneo per la compattazione nel registro. Questa impostazione è applicabile solo ai log che vengono compattati. Questa configurazione sarebbe limitata all'intervallo di [7 giorni, Long.Max]. Il valore predefinito per questa impostazione è 9223372036854775807, Apache Kafka Default. |
| retention.bytes | Questa configurazione controlla la dimensione massima che una partizione (composta da segmenti di log) può raggiungere prima di eliminare i vecchi segmenti di registro per liberare spazio se utilizziamo la politica di conservazione «elimina». Per impostazione predefinita, non esiste un limite di dimensione, ma solo un limite di tempo. Poiché questo limite viene applicato a livello di partizione, moltiplicalo per il numero di partizioni per calcolare la conservazione dell'argomento in byte. Inoltre, funziona indipendentemente dalle configurazioni e dalle `retention.bytes configuration` configurazioni. `segment.ms` `segment.bytes` Inoltre, attiva il lancio di un nuovo segmento se `retention.bytes` è configurato a zero. |
| retention.ms | Questa configurazione controlla il tempo massimo di conservazione di un registro prima di eliminare i vecchi segmenti di registro per liberare spazio se utilizziamo la politica di conservazione «elimina». Ciò rappresenta uno SLA sulla tempistica con cui i consumatori devono leggere i propri dati. Se impostato su`-1`, non viene applicato alcun limite di tempo. Inoltre, la `retention.ms` configurazione funziona indipendentemente dalle `segment.bytes` configurazioni `segment.ms` e. Inoltre, attiva il lancio di un nuovo segmento se la `retention.ms` condizione è soddisfatta. |
# Configurazioni di sola lettura di Express Brokers
Amazon MSK imposta i valori per queste configurazioni e le protegge da modifiche che potrebbero influire sulla disponibilità del cluster. Questi valori possono cambiare a seconda della versione di Apache Kafka in esecuzione sul cluster, quindi ricordati di controllare i valori del tuo cluster specifico.
La tabella seguente elenca le configurazioni di sola lettura per i broker Express.
| Proprietà | Description | Valore di Express Broker |
| --- | --- | --- |
| broker.id | L'id del broker per questo server. | 1,2,3... |
| broker.rack | Rack del broker. Questo verrà utilizzato nell'assegnazione della replica in base al rack per la tolleranza ai guasti. Esempi: ``, RACK1 `us-east-1d` | ID AZ o ID di sottorete |
| default.replication.factor | Fattori di replica predefiniti per tutti gli argomenti. | 3 |
| fetch.max.bytes | Il numero massimo di byte che restituiremo per una richiesta di recupero. | Apache Kafka (impostazione predefinita) |
| dimensione massima del gruppo | Il numero massimo di consumatori che un singolo gruppo di consumatori può ospitare. | Apache Kafka (impostazione predefinita) |
| inter.broker.listener.name | Nome dell'ascoltatore utilizzato per la comunicazione tra i broker. | REPLICATION\$1SECURE o REPLICATION |
| inter.broker.protocol. version | Speciifica quale versione del protocollo inter-broker viene utilizzata. | Apache Kafka (impostazione predefinita) |
| listener | Elenco degli ascoltatori - Elenco separato da virgole dei nomi degli ascoltatori su cui URIs ascolteremo. È possibile impostare iladvertised.listeners property, ma non la proprietà. listeners | Generato da MSK |
| log.message.format.version | Specificare la versione del formato del messaggio che il broker utilizzerà per aggiungere messaggi ai log. | Apache Kafka predefinito |
| min.insync.replicas | Quando un produttore imposta acks su `all` (or`-1`), il valore in `min.insync.replicas` specifica il numero minimo di repliche che devono confermare una scrittura affinché la scrittura sia considerata riuscita. Se questo minimo non può essere raggiunto, il produttore solleva un'eccezione (o`NotEnoughReplicas`). `NotEnoughReplicasAfterAppend` Puoi utilizzare il valore degli ack del tuo produttore per far valere maggiori garanzie di durabilità. Impostando acks su «all». Ciò garantisce che il produttore generi un'eccezione se la maggior parte delle repliche non riceve una scrittura. | 2 |
| num.io.thread | Numero di thread utilizzati dal server per produrre richieste, che possono includere l'I/O del disco. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 16), (m7g.4xlarge, 32), (m7g.8xlarge, 64), (m7g.12xlarge, 96), (m7g.16xlarge, 128) | In base al tipo di istanza. =Math.max (8, 2\$1 v) CPUs |
| num.network.threads | Numero di thread utilizzati dal server per ricevere richieste dalla rete e inviare risposte alla rete. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 8), (m7g.4xlarge, 16), (m7g.8xlarge, 32), (m7g.12xlarge, 48), (m7g.16xlarge, 64) | In base al tipo di istanza. =Math.max (8, v) CPUs |
| replica.fetch.response.max.bytes | Il numero massimo di byte previsto per l'intera risposta di recupero. I record vengono recuperati in batch. Se il primo batch di record nella prima partizione non vuota del recupero è più grande di questo valore, il batch di record verrà comunque restituito per garantire l'avanzamento. Questo non è un massimo assoluto. Le proprietà message.max.bytes (broker config) o max.message.bytes (topic config) specificano la dimensione massima del batch di record che il broker accetta. | Apache Kafka (impostazione predefinita) |
| request.timeout.ms | La configurazione controlla il tempo massimo di attesa del client per la risposta di una richiesta. Se la risposta non viene ricevuta prima dello scadere del timeout, il client invierà nuovamente la richiesta se necessario o fallirà la richiesta se i nuovi tentativi sono esauriti. | Apache Kafka predefinito |
| transaction.state.log.min.isr | min.insync.replicasConfigurazione sostituita per l'argomento della transazione. | 2 |
| transaction.state.log.replication.factor | Il fattore di replica per l'argomento di transazione. | Apache Kafka (impostazione predefinita) |
| unclean.leader.election.enable | Consente alle repliche non incluse nel set ISR di fungere da leader come ultima risorsa, anche se ciò potrebbe comportare la perdita di dati. | FALSE |
# Operazioni di configurazione del broker
Le configurazioni del broker Apache Kafka sono statiche o dinamiche. Le configurazioni statiche richiedono il riavvio del broker per poter applicare la configurazione. Le configurazioni dinamiche non richiedono il riavvio del broker per aggiornare la configurazione. Per ulteriori informazioni sulle proprietà di configurazione e sulle modalità di aggiornamento, consulta Configurazione di Apache Kafka.
In questo argomento viene descritto come creare configurazioni MSK personalizzate e come eseguire operazioni su di esse. Per informazioni su come utilizzare configurazioni MSK per creare o aggiornare cluster, consulta [Caratteristiche e concetti chiave di Amazon MSK](operations.md).
**Topics**
+ [Creazione di una configurazione](msk-configuration-operations-create.md)
+ [Aggiornamento della configurazione](msk-configuration-operations-update.md)
+ [Eliminare la configurazione](msk-configuration-operations-delete.md)
+ [Ottieni i metadati di configurazione](msk-configuration-operations-describe.md)
+ [Ottieni dettagli sulla revisione della configurazione](msk-configuration-operations-describe-revision.md)
+ [Elenca le configurazioni presenti nel tuo account per la regione corrente](msk-configuration-operations-list.md)
+ [Stati di configurazione di Amazon MSK](msk-configuration-states.md)
# Creazione di una configurazione
Questo processo descrive come creare una configurazione Amazon MSK personalizzata e come eseguire operazioni su di essa.
1. Creare un file in cui specificare le proprietà di configurazione che si desidera impostare e i valori da assegnare alle stesse. Di seguito sono riportati i contenuti di un file di configurazione di esempio.
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
1. Esegui il AWS CLI comando seguente e sostituiscilo *config-file-path* con il percorso del file in cui hai salvato la configurazione nel passaggio precedente.
**Nota**
Il nome scelto per la configurazione deve corrispondere alla seguente espressione regolare: "^[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
```
Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"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. Il comando precedente restituisce un nome della risorsa Amazon (ARN) per la configurazione appena creata. Salvare questo ARN perché occorre per fare riferimento a questa configurazione in altri comandi. Se l'ARN della configurazione viene perso, è possibile trovarlo nuovamente elencando tutte le configurazioni presenti nell'account.
# Aggiornamento della configurazione
Questo processo descrive come aggiornare una configurazione Amazon MSK personalizzata.
1. Crea un file in cui specificare le proprietà di configurazione che desideri aggiornare e i valori da assegnare alle stesse. Di seguito sono riportati i contenuti di un file di configurazione di esempio.
```
auto.create.topics.enable = true
min.insync.replicas = 2
```
1. Esegui il AWS CLI comando seguente e sostituiscilo *config-file-path* con il percorso del file in cui hai salvato la configurazione nel passaggio precedente.
Sostituisci *configuration-arn* con l'ARN che hai ottenuto quando hai creato la configurazione. Se l'ARN non è stato salvato al momento della creazione della configurazione, è possibile utilizzare il comando `list-configurations` per elencare tutte le configurazioni presenti nell'account. La configurazione desiderata viene visualizzata nell'elenco di risposta. L'ARN della configurazione viene visualizzato anche in tale elenco.
```
aws kafka update-configuration --arn configuration-arn --description "Example configuration revision description." --server-properties fileb://config-file-path
```
1. Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"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
}
}
```
# Eliminare la configurazione
Nella procedura seguente viene illustrato come eliminare una configurazione non collegata a un cluster. Non è possibile eliminare una configurazione collegata a un cluster.
1. Per eseguire questo esempio, sostituiscilo *configuration-arn* con l'ARN che hai ottenuto quando hai creato la configurazione. Se l'ARN non è stato salvato al momento della creazione della configurazione, è possibile utilizzare il comando `list-configurations` per elencare tutte le configurazioni presenti nell'account. La configurazione desiderata viene visualizzata nell'elenco di risposta. L'ARN della configurazione viene visualizzato anche in tale elenco.
```
aws kafka delete-configuration --arn configuration-arn
```
1. Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"arn": " arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"state": "DELETING"
}
```
# Ottieni i metadati di configurazione
La procedura seguente mostra come descrivere una configurazione Amazon MSK per ottenere i metadati relativi alla configurazione.
1. Il comando seguente restituisce i metadati relativi alla configurazione. Per ottenere una descrizione dettagliata della configurazione, eseguire `describe-configuration-revision`.
Per eseguire questo esempio, sostituiscilo *configuration-arn* con l'ARN che hai ottenuto quando hai creato la configurazione. Se l'ARN non è stato salvato al momento della creazione della configurazione, è possibile utilizzare il comando `list-configurations` per elencare tutte le configurazioni presenti nell'account. La configurazione desiderata viene visualizzata nell'elenco di risposta. L'ARN della configurazione viene visualizzato anche in tale elenco.
```
aws kafka describe-configuration --arn configuration-arn
```
1. Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"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"
}
```
# Ottieni dettagli sulla revisione della configurazione
Questo processo consente di ottenere una descrizione dettagliata della revisione della configurazione di Amazon MSK.
Se utilizzi il comando `describe-configuration` per descrivere una configurazione MSK, visualizzerai i metadati della configurazione. Per ottenere una descrizione dettagliata della configurazione, utilizza il comando `describe-configuration-revision`.
+ Esegui il comando seguente e sostituiscilo *configuration-arn* con l'ARN ottenuto quando hai creato la configurazione. Se l'ARN non è stato salvato al momento della creazione della configurazione, è possibile utilizzare il comando `list-configurations` per elencare tutte le configurazioni presenti nell'account. La configurazione desiderata viene visualizzata nell'elenco di risposta. L'ARN della configurazione viene visualizzato anche in tale elenco.
```
aws kafka describe-configuration-revision --arn configuration-arn --revision 1
```
Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"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"
}
```
Il valore di `ServerProperties` è codificato con base64. Se si utilizza un decodificatore base64 (ad esempio, https://www.base64decode.org/) per decodificarlo manualmente, si ottiene il contenuto del file di configurazione originale utilizzato per creare la configurazione personalizzata. In questo caso, si ottiene quanto segue:
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
# Elenca le configurazioni presenti nel tuo account per la regione corrente
Questo processo descrive come elencare tutte le configurazioni Amazon MSK nel tuo account per la regione corrente AWS .
+ Eseguire il seguente comando seguente.
```
aws kafka list-configurations
```
Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"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"
}
]
}
```
# Stati di configurazione di Amazon MSK
Una configurazione Amazon MSK può trovarsi in uno dei seguenti stati. Per eseguire un'operazione su una configurazione, la configurazione deve trovarsi nello stato `ACTIVE` o `DELETE_FAILED`:
+ `ACTIVE`
+ `DELETING`
+ `DELETE_FAILED`
# Ribilanciamento intelligente per i cluster
Amazon MSK fornisce un ribilanciamento intelligente per tutti i nuovi cluster MSK Provisioned con broker Express. Questa funzionalità gestisce automaticamente la distribuzione delle partizioni e le operazioni di scalabilità del cluster, eliminando la necessità di strumenti di terze parti. Il ribilanciamento intelligente riequilibra automaticamente le partizioni quando si aumentano o diminuiscono i cluster. Inoltre, monitora continuamente lo stato del cluster per rilevare eventuali squilibri o sovraccarichi delle risorse e ridistribuisce il carico di lavoro.
Il ribilanciamento intelligente fornisce operazioni di scalabilità rapide che vengono completate entro 30 minuti e non influisce sulla disponibilità del cluster durante la scalabilità. È attivato per impostazione predefinita per tutti i nuovi cluster Provisioned basati su MSK Express e funziona con il limite massimo di partizioni consigliato di 20.000 partizioni per broker. Inoltre, questa funzionalità è disponibile senza costi aggiuntivi e non richiede alcuna configurazione.
A partire dal 20 novembre 2025, Intelligent Rebalancing è disponibile in tutte le regioni in AWS cui sono supportati i broker Amazon MSK Express.
**Topics**
+ [Come funziona il ribilanciamento intelligente](#how-intelligent-rebalancing-works)
+ [Monitoraggio delle metriche di ribilanciamento intelligente](#intelligent-rebalancing-metrics)
+ [Considerazioni sull'utilizzo del ribilanciamento intelligente](#intelligent-rebalancing-considerations)
+ [Scalabilità verso l'alto e verso il basso dei cluster Amazon MSK con un'unica operazione](intelligent-rebalancing-scaling-clusters.md)
+ [Ribilanciamento dello stato stazionario per i cluster Amazon MSK](intelligent-rebalancing-self-balancing-paritions.md)
## Come funziona il ribilanciamento intelligente
Il ribilanciamento intelligente è attivato per impostazione predefinita per tutti i nuovi cluster MSK Provisioned con broker Express. Include il supporto per le seguenti situazioni:
+ **Scalabilità verso l'alto e verso il basso**: consente di aggiungere o rimuovere broker ai cluster basati su MSK Express con un solo clic. Una volta specificati i broker da aggiungere o rimuovere, il ribilanciamento intelligente ridistribuisce automaticamente le partizioni nella nuova configurazione del cluster in base alle best practice interne. AWS
+ **Ribilanciamento allo stato stazionario: allo stato stazionario, questa funzionalità monitora continuamente lo stato del cluster e ribilancia** automaticamente le partizioni quando:
+ L'utilizzo delle risorse diventa distorto tra i broker.
+ I broker vengono sovraforniti o sottoutilizzati.
+ Vengono aggiunti nuovi broker o rimossi i broker esistenti.
**Nota**
Se il ribilanciamento intelligente è attivato, non potrai utilizzare strumenti di terze parti, come Cruise Control, per il ribilanciamento delle partizioni. Devi prima mettere in pausa il ribilanciamento intelligente per utilizzare l'API di riassegnazione delle partizioni fornita da questi strumenti di terze parti.
Puoi utilizzare questa funzionalità nella console Amazon MSK. Puoi utilizzare questa funzionalità anche utilizzando Amazon MSK APIs o AWS SDK e. AWS CLI AWS CloudFormation Per ulteriori informazioni, consultare [Scalabilità dei cluster Amazon MSK](intelligent-rebalancing-scaling-clusters.md) e [Ribilanciamento allo stato stazionario](intelligent-rebalancing-self-balancing-paritions.md).
## Monitoraggio delle metriche di ribilanciamento intelligente
Puoi monitorare lo stato delle operazioni di ribilanciamento intelligente in corso e storiche utilizzando i seguenti parametri di Amazon CloudWatch :
+ `RebalanceInProgress`: Questa metrica viene pubblicata ogni minuto con il valore 1 quando il ribilanciamento è in corso e 0 in caso contrario.
+ `UnderProvisioned`: indica che il provisioning di un cluster è attualmente insufficiente e che non è possibile eseguire alcun ribilanciamento delle partizioni. È necessario aggiungere altri broker o aumentare il tipo di istanza del cluster.
Per informazioni sul monitoraggio di un cluster MSK Provisioned, vedere e. [](monitoring.md) [](cloudwatch-metrics.md)
## Considerazioni sull'utilizzo del ribilanciamento intelligente
+ Il supporto per il ribilanciamento intelligente è disponibile solo per i nuovi cluster MSK Provisioned con broker Express.
+ Per la riassegnazione automatica delle partizioni, è disponibile il supporto massimo per un massimo di 20.000 partizioni per broker.
+ Non è possibile utilizzare strumenti di riassegnazione delle partizioni APIs o strumenti di ribilanciamento di terze parti quando è abilitato il ribilanciamento intelligente. Per utilizzare questi strumenti APIs o quelli di terze parti, è necessario prima sospendere il ribilanciamento intelligente per il cluster basato su MSK Express.
# Scalabilità verso l'alto e verso il basso dei cluster Amazon MSK con un'unica operazione
Con il ribilanciamento intelligente, puoi aumentare o ridurre i cluster modificando il numero di broker presenti nei cluster con un'unica azione. Puoi eseguire questa operazione nella console Amazon MSK o utilizzando Amazon MSK APIs o AWS SDK e. AWS CLI AWS CloudFormation Quando modifichi il numero di broker, Amazon MSK effettua le seguenti operazioni:
+ Distribuisce automaticamente le partizioni ai nuovi broker.
+ Sposta le partizioni dai broker che vengono rimossi.
Aumentando o diminuendo i cluster, la disponibilità dei cluster per i clienti per la produzione e l'utilizzo dei dati rimane inalterata.
**Topics**
------
#### [ Scaling clusters using Console di gestione AWS ]
1. Aprire la console Amazon MSK a [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nella pagina Cluster, scegli un **cluster basato su Express appena creato**. Per informazioni sulla creazione di un cluster basato su Express con provisioning, vedere. [Fase 1: creare un cluster MSK Provisioned](create-cluster.md)
1. Nell'elenco a discesa **Azioni**, scegli **Modifica il numero di broker**.
1. Nella pagina **Modifica il numero di broker per zona**, esegui una delle seguenti operazioni:
+ Per aggiungere altri broker al cluster, scegli **Aggiungi broker a ciascuna zona di disponibilità**, quindi inserisci il numero di broker che desideri aggiungere.
+ Per rimuovere i broker dal tuo cluster, scegli **Rimuovi un broker da** ogni zona di disponibilità.
1. Scegli **Save changes** (Salva modifiche).
------
#### [ Scaling clusters using AWS CLI ]
Puoi aumentare o diminuire i cluster modificando il numero di broker. A tale scopo AWS CLI, utilizzate il [update-broker-count](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-broker-count.html)comando, come illustrato nell'esempio seguente. In questo comando, specificate nel `target-broker-count` parametro il numero di broker che desiderate inserire nel cluster.
```
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 ]
Puoi aumentare o ridurre i cluster modificando in modo programmatico il numero di broker. Per eseguire questa operazione utilizzando l' AWS SDK, utilizzate l'[UpdateBrokerCount](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-count.html#UpdateBrokerCount)API, come illustrato nell'esempio seguente. Per il `TargetNumberOfBrokerNodes` parametro, specifica il numero di broker che desideri inserire nel cluster.
```
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
)
```
------
# Ribilanciamento dello stato stazionario per i cluster Amazon MSK
Il ribilanciamento allo stato stazionario fa parte della funzionalità di ribilanciamento intelligente, che è attivata per impostazione predefinita per tutti i nuovi cluster MSK Provisioned con broker Express. Man mano che aumenti o riduci i cluster, Amazon MSK gestisce automaticamente la gestione delle partizioni distribuendo le partizioni a nuovi broker e spostando le partizioni dai broker da rimuovere. Per garantire una distribuzione ottimale del carico di lavoro tra i broker, il ribilanciamento intelligente utilizza le best practice di Amazon MSK per determinare le soglie per l'avvio automatico del ribilanciamento per i broker.
Puoi mettere in pausa e riprendere il riequilibrio allo stato stazionario quando necessario. Il ribilanciamento dello stato stazionario monitora continuamente il cluster ed esegue le seguenti operazioni:
+ Tiene traccia dell'utilizzo delle risorse del broker (CPU, rete, storage).
+ Regola automaticamente il posizionamento delle partizioni senza alcun impatto sulla disponibilità dei dati.
+ Completa le operazioni di ribilanciamento fino a 180 volte più velocemente per i broker Express rispetto ai broker Standard.
+ Mantiene le prestazioni del cluster.
**Topics**
------
#### [ Pause and resume steady state rebalancing in Console di gestione AWS ]
1. Aprire la console Amazon MSK a [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. **Nella pagina Cluster, scegli un cluster basato su Express.** Per informazioni sulla creazione di un cluster basato su Express con provisioning, vedere. [Fase 1: creare un cluster MSK Provisioned](create-cluster.md)
1. **Nella pagina dei dettagli del cluster, verifica che lo stato di **ribilanciamento intelligente** sia Attivo.** Se il ribilanciamento intelligente non è disponibile o lo stato è **Sospeso**, crea un nuovo cluster basato su Express.
1. **Nell'elenco a discesa **Azioni**, scegli Modifica ribilanciamento intelligente.**
1. Nella pagina **Modifica ribilanciamento intelligente, procedi** come segue:
1. **Scegli In pausa.**
1. Scegli **Save changes** (Salva modifiche).
------
#### [ Pause and resume steady state rebalancing using AWS CLI ]
Per impostare lo stato di ribilanciamento di un cluster sull'**ACTIVE**utilizzo di AWS CLI, utilizzate il comando [update-rebalancing](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-rebalancing.html), come illustrato nell'esempio seguente. In questo comando, specificate lo stato con il parametro. `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 ]
È inoltre possibile impostare lo stato di ribilanciamento di un cluster utilizzando l'[UpdateRebalancingRequest](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-rebalancing.html#UpdateRebalancing)API per modificare a livello di codice il conteggio dei broker. Gli esempi seguenti mostrano come impostare lo stato di ribilanciamento su e. **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"));
```
------
# Applicazione di patch sui cluster MSK Provisioned
Periodicamente, Amazon MSK aggiorna il software sui broker del tuo cluster. La manutenzione include aggiornamenti pianificati o riparazioni non pianificate. La manutenzione pianificata include aggiornamenti del sistema operativo, aggiornamenti di sicurezza e altri aggiornamenti software necessari per mantenere l'integrità, la sicurezza e le prestazioni del cluster. Eseguiamo una manutenzione non pianificata per risolvere il degrado improvviso dell'infrastruttura. Eseguiamo la manutenzione su broker Standard ed Express, ma le esperienze sono diverse.
## Applicazione di patch per broker Standard
[Gli aggiornamenti ai broker Standard non hanno alcun impatto sulle scritture e sulle letture delle applicazioni se segui le best practice.](bestpractices.md)
Amazon MSK utilizza aggiornamenti periodici per il software per mantenere un'elevata disponibilità dei cluster. Durante questo processo, i broker vengono riavviati uno alla volta e Kafka trasferisce automaticamente la leadership a un altro broker online. Quando si visualizzano le operazioni del cluster in modalità Console di gestione AWS o in modalità wireless `ListClusterOperations` APIs, queste operazioni di manutenzione vengono visualizzate con un tipo di operazione di. `DescribeClusterOperation` `SECURITY_PATCHING` I client Kafka dispongono di meccanismi integrati per rilevare automaticamente il cambio di leadership per le partizioni e continuare a scrivere e leggere dati in un cluster MSK. Segui le istruzioni [Le migliori pratiche per i client Apache Kafka](bestpractices-kafka-client.md) per garantire il corretto funzionamento del cluster in ogni momento, anche durante l'applicazione delle patch.
In seguito alla disconnessione di un broker, è normale riscontrare errori di disconnessione transitori sui clienti. Inoltre, per una breve finestra (fino a 2 minuti, in genere meno), osserverete alcuni picchi nella latenza di lettura e scrittura di p99 (in genere alti millisecondi, fino a \$12 secondi). Questi picchi sono previsti e sono causati dalla riconnessione del client a un nuovo broker leader; non influiscono sulla produzione o sul consumo e si risolveranno dopo la riconnessione. Per ulteriori informazioni, consulta [Broker offline](https://docs.aws.amazon.com/msk/latest/developerguide/troubleshooting-offlinebroker-clientfailover.html) e client failover.
Noterai anche un aumento della metrica`UnderReplicatedPartitions`, previsto poiché le partizioni del broker che è stato chiuso non replicano più i dati. Ciò non ha alcun impatto sulle scritture e le letture delle applicazioni, poiché le repliche di queste partizioni ospitate su altri broker ora soddisfano le richieste.
Dopo l'aggiornamento del software, quando il broker torna online, deve «recuperare il ritardo» sui messaggi prodotti mentre era offline. Durante il catch up, si può anche osservare un aumento dell'utilizzo del volume, del throughput e della CPU. Questi non dovrebbero avere alcun impatto sulle scritture e le letture nel cluster se i broker dispongono di risorse sufficienti di CPU, memoria, rete e volume.
## Applicazione di patch per i broker Express
Non ci sono finestre di manutenzione per i broker Express. Amazon MSK aggiorna automaticamente il cluster su base continuativa in modo distribuito nel tempo, il che significa che puoi aspettarti riavvii occasionali e singolari del broker nel corso del mese. In questo modo non è necessario elaborare piani o adattamenti in base a finestre di manutenzione una tantum a livello di cluster. Come sempre, il traffico rimarrà ininterrotto durante il riavvio del broker poiché la leadership passerà ad altri broker che continueranno a soddisfare le richieste. Quando si visualizzano le operazioni del cluster in modalità diretta Console di gestione AWS o diretta `ListClusterOperations` APIs, queste operazioni di manutenzione vengono visualizzate con un tipo di operazione di. `DescribeClusterOperation` `BROKER_UPDATE`
I broker Express sono configurati con impostazioni e protezioni basate sulle best practice che rendono il cluster resiliente alle variazioni di carico che possono verificarsi durante la manutenzione. Amazon MSK imposta quote di throughput sui broker Express per mitigare l'impatto del sovraccarico del cluster, che può causare problemi durante il riavvio del broker. Questi miglioramenti eliminano la necessità di notifiche anticipate, pianificazione e finestre di manutenzione quando si utilizzano i broker Express.
I broker Express replicano sempre i dati in tre modi, in modo che i client effettuino automaticamente il failover durante i riavvii. Non devi preoccuparti che gli argomenti diventino non disponibili a causa del fattore di replica impostato su 1 o 2. Inoltre, il catch up per un broker Express riavviato è più veloce rispetto ai broker Standard. La maggiore velocità di applicazione delle patch sui broker Express significa che le interruzioni della pianificazione di tutte le attività del piano di controllo che potresti aver pianificato per il tuo cluster saranno minime.
Come per tutte le applicazioni Apache Kafka, esiste ancora un contratto client-server condiviso per i clienti che si connettono ai broker Express. È ancora fondamentale configurare i clienti per gestire il failover della leadership tra i broker. Segui le istruzioni [Le migliori pratiche per i client Apache Kafka](bestpractices-kafka-client.md) per un funzionamento senza intoppi del cluster in ogni momento, anche durante l'applicazione delle patch. Dopo il riavvio del broker, è normale che si verifichino [errori di disconnessione](troubleshooting-offlinebroker-clientfailover.md) transitori sui client. Ciò non influirà sulla produzione e sul consumo, in quanto i broker follower assumeranno la leadership della partizione. I vostri client Apache Kafka eseguiranno automaticamente il failover e inizieranno a inviare richieste ai nuovi broker leader.
# Broker offline e failover del client
Kafka consente l'utilizzo di un broker offline; un unico broker offline in un cluster sano ed equilibrato che segue le migliori pratiche non avrà alcun impatto né causerà l'interruzione della produzione o del consumo. Questo perché un altro broker assumerà la guida delle partizioni e perché la libreria dei client di Kafka eseguirà automaticamente il failover e inizierà a inviare richieste ai nuovi broker leader.
**Contratto client-server**
Ciò si traduce in un contratto condiviso tra la libreria client e il comportamento lato server; il server deve assegnare correttamente uno o più nuovi leader e il client deve cambiare broker per inviare le richieste ai nuovi leader in modo tempestivo.
Kafka utilizza le eccezioni per controllare questo flusso:
**Un esempio di procedura**
1. Il broker A entra in uno stato offline.
1. Il client Kafka riceve un'eccezione (in genere la disconnessione della rete o not\$1leader\$1for\$1partition).
1. Queste eccezioni fanno sì che il client Kafka aggiorni i propri metadati in modo da conoscere i leader più recenti.
1. Il client Kafka riprende a inviare richieste ai nuovi responsabili delle partizioni su altri broker.
Questo processo richiede in genere meno di 2 secondi con il client Java fornito e le configurazioni predefinite. Gli errori lato client sono dettagliati e ripetitivi, ma non sono motivo di preoccupazione, come indicato dal livello «WARN».
**Esempio: eccezione 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`
**Esempio: eccezione 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"`
I client Kafka risolveranno automaticamente questi errori in genere entro 1 secondo e al massimo 3 secondi. Ciò si presenta come produce/consume una latenza a p99 nelle metriche lato client (in genere millisecondi elevati negli anni 100). Un periodo superiore a questo valore indica in genere un problema con la configurazione client o il carico del controller sul lato server. Consulta la sezione relativa alla risoluzione dei problemi.
Un failover riuscito può essere verificato controllando l'`BytesInPerSec`aumento delle `LeaderCount` metriche su altri broker, il che dimostra che il traffico e la leadership si sono mossi come previsto. Noterai anche un aumento della `UnderReplicatedPartitions` metrica, previsto quando le repliche sono offline con il broker di shutdown.
**Risoluzione dei problemi**
Il flusso di cui sopra può essere interrotto interrompendo il contratto client-server. I motivi più comuni del problema includono:
+ Configurazione errata o utilizzo errato delle librerie dei client Kafka.
+ Comportamenti e bug predefiniti imprevisti con librerie di client di terze parti.
+ Controller sovraccarico con conseguente rallentamento dell'assegnazione del leader di partizione.
+ Viene eletto un nuovo controller, con conseguente rallentamento dell'assegnazione del leader di partizione.
Per garantire un comportamento corretto in caso di fallimento della leadership, consigliamo di:
+ È necessario seguire [le migliori pratiche](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html) lato server per garantire che il controller broker sia dimensionato in modo appropriato per evitare rallentamenti nell'assegnazione dei dirigenti.
+ Le librerie client devono avere i nuovi tentativi abilitati per garantire che il client gestisca il failover.
+ Le librerie client devono avere retry.backoff.ms configurato (impostazione predefinita 100) per evitare tempeste. connection/request
+ Le librerie client devono impostare request.timeout.ms e delivery.timeout.ms su valori in linea con lo SLA delle applicazioni. Valori più elevati comporteranno un failover più lento per determinati tipi di errore.
+ Le librerie client devono garantire che bootstrap.servers contenga almeno 3 broker casuali per evitare un impatto sulla disponibilità sulla scoperta iniziale.
+ Alcune librerie client sono di livello inferiore rispetto ad altre e si aspettano che lo sviluppatore dell'applicazione implementi autonomamente la logica dei tentativi e la gestione delle eccezioni. Fate riferimento alla documentazione specifica di Client Lib, ad esempio sull'utilizzo, e assicuratevi che venga seguita la reconnect/retry logica corretta.
+ Consigliamo di monitorare la latenza lato client per verificare la produzione, il conteggio delle richieste riuscite e il conteggio degli errori per errori non ripetibili.
+ Abbiamo osservato che le vecchie librerie golang e ruby di terze parti rimangono dettagliate durante l'intero periodo di tempo offline del broker, nonostante le richieste di produzione e consumo non ne risentano. Ti consigliamo di monitorare sempre le metriche a livello aziendale, oltre a quelle relative alle richieste di successo e agli errori, per determinare se i log registrano un impatto reale rispetto al rumore.
+ I clienti non devono allarmarsi per le eccezioni transitorie per network/not\$1leader, in quanto sono normali, ininfluenti e previste dal protocollo kafka.
+ I clienti non devono attivare gli allarmi in UnderReplicatedPartitions quanto sono normali, ininfluenti e previsti da un singolo broker offline.
# Sicurezza in Amazon MSK
La sicurezza del cloud AWS è la massima priorità. In qualità di AWS cliente, puoi beneficiare di un data center e di un'architettura di rete progettati per soddisfare i requisiti delle organizzazioni più sensibili alla sicurezza.
La sicurezza è una responsabilità condivisa tra AWS te e te. Il [modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/) descrive questo aspetto come sicurezza *del* cloud e sicurezza *nel* cloud:
+ **Sicurezza del cloud**: AWS è responsabile della protezione dell'infrastruttura che gestisce AWS i servizi nel AWS cloud. AWS ti fornisce anche servizi che puoi utilizzare in modo sicuro. I revisori esterni testano e verificano regolarmente l'efficacia della nostra sicurezza nell'ambito dei [AWS Programmi di AWS conformità dei Programmi di conformità](https://aws.amazon.com/compliance/programs/) dei di . Per ulteriori informazioni sui programmi di conformità applicabili a Streaming gestito da Amazon per Apache Kafka, consulta la pagina [Amazon Web Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicurezza nel cloud**: la responsabilità dell'utente è determinata dal AWS servizio che utilizza. Inoltre, sei responsabile anche di altri fattori, tra cui la riservatezza dei dati, i requisiti dell’azienda e le leggi e le normative applicabili.
La presente documentazione aiuta a comprendere come applicare il modello di responsabilità condivisa quando si utilizza Amazon MSK. Gli argomenti seguenti descrivono come configurare Amazon MSK per soddisfare gli obiettivi di sicurezza e conformità. Vengono inoltre fornite informazioni su come utilizzare altri servizi di Amazon Web Services che consentono di monitorare e proteggere le risorse Amazon MSK.
**Topics**
+ [Protezione dei dati in Streaming gestito da Amazon per Apache Kafka](data-protection.md)
+ [Autenticazione e autorizzazione per Amazon MSK APIs](security-iam.md)
+ [Autenticazione e autorizzazione per Apache Kafka APIs](kafka_apis_iam.md)
+ [Modifica del gruppo di sicurezza di un cluster Amazon MSK](change-security-group.md)
+ [Controlla l'accesso ai ZooKeeper nodi Apache nel tuo cluster Amazon MSK](zookeeper-security.md)
+ [Convalida della conformità per Streaming gestito da Amazon per Apache Kafka](MSK-compliance.md)
+ [Resilienza in Streaming gestito da Amazon per Apache Kafka](disaster-recovery-resiliency.md)
+ [Sicurezza dell'infrastruttura in Streaming gestito da Amazon per Apache Kafka](infrastructure-security.md)
# Protezione dei dati in Streaming gestito da Amazon per Apache Kafka
Il modello di [responsabilità AWS condivisa modello](https://aws.amazon.com/compliance/shared-responsibility-model/) si applica alla protezione dei dati in Amazon Managed Streaming for Apache Kafka. Come descritto in questo modello, AWS è responsabile della protezione dell'infrastruttura globale che gestisce tutti i. Cloud AWS L’utente è responsabile del controllo dei contenuti ospitati su questa infrastruttura. L’utente è inoltre responsabile della configurazione della protezione e delle attività di gestione per i Servizi AWS utilizzati. Per maggiori informazioni sulla privacy dei dati, consulta le [Domande frequenti sulla privacy dei dati](https://aws.amazon.com/compliance/data-privacy-faq/). Per informazioni sulla protezione dei dati in Europa, consulta il post del blog relativo al [AWS Modello di responsabilità condivisa e GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) nel *AWS Blog sulla sicurezza*.
Ai fini della protezione dei dati, consigliamo di proteggere Account AWS le credenziali e configurare i singoli utenti con AWS IAM Identity Center or AWS Identity and Access Management (IAM). In tal modo, a ogni utente verranno assegnate solo le autorizzazioni necessarie per svolgere i suoi compiti. Suggeriamo, inoltre, di proteggere i dati nei seguenti modi:
+ Utilizza l’autenticazione a più fattori (MFA) con ogni account.
+ SSL/TLS Da utilizzare per comunicare con AWS le risorse. È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Configura l'API e la registrazione delle attività degli utenti con AWS CloudTrail. Per informazioni sull'utilizzo dei CloudTrail percorsi per acquisire AWS le attività, consulta [Lavorare con i CloudTrail percorsi](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) nella *Guida per l'AWS CloudTrail utente*.
+ Utilizza soluzioni di AWS crittografia, insieme a tutti i controlli di sicurezza predefiniti all'interno Servizi AWS.
+ Utilizza i servizi di sicurezza gestiti avanzati, come Amazon Macie, che aiutano a individuare e proteggere i dati sensibili archiviati in Amazon S3.
+ Se hai bisogno di moduli crittografici convalidati FIPS 140-3 per accedere AWS tramite un'interfaccia a riga di comando o un'API, usa un endpoint FIPS. Per ulteriori informazioni sugli endpoint FIPS disponibili, consulta il [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Ti consigliamo di non inserire mai informazioni riservate o sensibili, ad esempio gli indirizzi e-mail dei clienti, nei tag o nei campi di testo in formato libero, ad esempio nel campo **Nome**. Ciò include quando lavori con Amazon MSK o altro Servizi AWS utilizzando la console, l'API o AWS SDKs. AWS CLI I dati inseriti nei tag o nei campi di testo in formato libero utilizzati per i nomi possono essere utilizzati per i la fatturazione o i log di diagnostica. Quando si fornisce un URL a un server esterno, suggeriamo vivamente di non includere informazioni sulle credenziali nell’URL per convalidare la richiesta al server.
**Topics**
+ [Crittografia di Amazon MSK](msk-encryption.md)
+ [Inizia a usare la crittografia Amazon MSK](msk-working-with-encryption.md)
+ [Usa Amazon MSK APIs con endpoint VPC di interfaccia](privatelink-vpc-endpoints.md)
# Crittografia di Amazon MSK
Amazon MSK fornisce opzioni di crittografia dei dati che puoi utilizzare per soddisfare rigidi requisiti di gestione dei dati. I certificati utilizzati da Amazon MSK per la crittografia devono essere rinnovati ogni 13 mesi. Amazon MSK rinnova automaticamente questi certificati per tutti i cluster. I cluster Express broker rimangono attivi quando Amazon MSK avvia l'operazione di aggiornamento dei certificati. `ACTIVE` Per i cluster di broker standard, Amazon MSK imposta lo stato del cluster su `MAINTENANCE` quando avvia l'operazione di aggiornamento dei certificati. MSK lo riporta a quando l'aggiornamento è terminato. `ACTIVE` Mentre un cluster è in corso l'operazione di aggiornamento dei certificati, è possibile continuare a produrre e consumare dati, ma non è possibile eseguire alcuna operazione di aggiornamento su di esso.
## Crittografia Amazon MSK a riposo
Amazon MSK si integra con [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/) (KMS) per offrire una crittografia lato server trasparente. Amazon MSK esegue sempre la crittografia dei dati a riposo. Quando crei un cluster Amazon MSK, puoi specificare la AWS KMS key che desideri far utilizzare ad Amazon MSK per crittografare i dati a riposo. Se non specifichi una chiave KMS, Amazon MSK crea una chiave KMS gestita da [Chiave gestita da AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) e la utilizza per tuo conto. Per ulteriori informazioni sulle chiavi KMS, consulta [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) nella *Guida per gli sviluppatori di AWS Key Management Service *.
## Crittografia Amazon MSK in transito
Amazon MSK utilizza TLS 1.2. Per impostazione predefinita, effettua la crittografia dei dati in transito tra i broker del cluster MSK. Puoi ignorare questa impostazione predefinita al momento della creazione del cluster.
Per la comunicazione tra client e broker, è necessario specificare una delle tre impostazioni seguenti:
+ Consenti solo dati crittografati TLS. Questa è l'impostazione predefinita.
+ Consenti dati non crittografati e dati crittografati TLS.
+ Consenti solo dati non crittografati.
I broker Amazon MSK utilizzano certificati pubblici AWS Certificate Manager . Pertanto, qualsiasi truststore che considera attendibili gli Amazon Trust Services considera attendibili anche i certificati dei broker Amazon MSK.
Anche se consigliamo vivamente di abilitare la crittografia dei dati in transito, questa potrebbe aggiungere un sovraccarico aggiuntivo della CPU e alcuni millisecondi di latenza. Tuttavia, la maggior parte dei casi d'uso non è sensibile a queste differenze e l'entità dell'impatto dipende dalla configurazione del cluster, dei client e del profilo di utilizzo.
# Inizia a usare la crittografia Amazon MSK
Durante la creazione di un cluster MSK, puoi specificare le impostazioni di crittografia in formato JSON. Di seguito è riportato un esempio di :
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdabcd-1234-abcd-1234-abcd123e8e8e"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Per `DataVolumeKMSKeyId`, puoi specificare una [chiave gestita dal cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) o la Chiave gestita da AWS per MSK nel tuo account (`alias/aws/kafka`). Se non lo specifichi`EncryptionAtRest`, Amazon MSK crittografa comunque i tuoi dati inattivi in base a. Chiave gestita da AWS Per determinare la chiave utilizzata dal cluster, invia una richiesta `GET` o richiama l'operazione API `DescribeCluster`.
Per `EncryptionInTransit`, il valore predefinito di `InCluster` è true, ma puoi impostarlo su false se Amazon MSK non deve crittografare i dati durante il passaggio tra i broker.
Per specificare la modalità di crittografia per i dati in transito tra client e broker, imposta `ClientBroker` su uno di tre valori: `TLS`, `TLS_PLAINTEXT` o `PLAINTEXT`.
**Topics**
+ [Specificare le impostazioni di crittografia durante la creazione di un cluster Amazon MSK](msk-working-with-encryption-cluster-create.md)
+ [Prova la crittografia TLS di Amazon MSK](msk-working-with-encryption-test-tls.md)
# Specificare le impostazioni di crittografia durante la creazione di un cluster Amazon MSK
Questo processo descrive come specificare le impostazioni di crittografia durante la creazione di un cluster Amazon MSK.
**Specificare le impostazioni di crittografia durante la creazione di un cluster**
1. Salvare il contenuto dell'esempio precedente in un file e assegnare al file il nome desiderato. Ad esempio, chiamarlo `encryption-settings.json`.
1. Eseguire il comando `create-cluster` e utilizzare l'opzione `encryption-info` per puntare al file in cui il JSON di configurazione è stato salvato. Di seguito è riportato un esempio di : Sostituisci *\$1YOUR MSK VERSION\$1* con una versione che corrisponda alla versione del client Apache Kafka. Per informazioni su come trovare la versione del cluster MSK in uso, consulta la pagina [Determinazione della versione del cluster MSK](create-topic.md#find-msk-cluster-version). Tieni presente che l'utilizzo di una versione del client Apache Kafka diversa da quella del cluster MSK può causare il danneggiamento, la perdita dei dati e tempi di inattività di Apache Kafka.
```
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
```
Di seguito è riportato un esempio di una risposta corretta dopo l'esecuzione di questo comando.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:123456789012:cluster/SecondTLSTest/abcdabcd-1234-abcd-1234-abcd123e8e8e",
"ClusterName": "ExampleClusterName",
"State": "CREATING"
}
```
# Prova la crittografia TLS di Amazon MSK
Questo processo descrive come testare la crittografia TLS su Amazon MSK.
**Per testare la crittografia TLS**
1. Creare un computer client seguendo le linee guida in [Passaggio 3: creazione di un computer client](create-client-machine.md).
1. Installare Apache Kafka sul computer client.
1. In questo esempio, utilizziamo il truststore JVM per comunicare con il cluster MSK. A tale scopo, creare innanzitutto una cartella denominata `/tmp` sul computer client. Quindi, passare alla cartella `bin` dell'installazione di Apache Kafka ed eseguire il seguente comando. (Il percorso JVM potrebbe essere diverso.)
```
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. Sempre nella cartella `bin` dell'installazione di Apache Kafka sul computer client, creare un file di testo denominato `client.properties` con il seguente contenuto.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka.client.truststore.jks
```
1. Esegui il comando seguente su un computer su cui è AWS CLI installato, sostituendolo *clusterARN* con l'ARN del tuo cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Se l'operazione riesce, il risultato sarà simile al seguente. Salvare questo risultato perché è necessario per la fase successiva.
```
{
"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. Esegui il comando seguente, sostituendolo *BootstrapBrokerStringTls* con uno degli endpoint del broker ottenuti nel passaggio precedente.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringTls --producer.config client.properties --topic TLSTestTopic
```
1. Apri una nuova finestra di comando e connettiti allo stesso computer client. Quindi, esegui il comando seguente per creare un utente della console.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringTls --consumer.config client.properties --topic TLSTestTopic
```
1. Nella finestra del produttore, digita un messaggio di testo seguito da un invio e cerca lo stesso messaggio nella finestra del consumatore. Amazon MSK ha crittografato questo messaggio in transito.
Per ulteriori informazioni sulla configurazione dei client Apache Kafka per l'utilizzo di dati crittografati, consulta [Configuring Kafka Clients](https://kafka.apache.org/documentation/#security_configclients).
# Usa Amazon MSK APIs con endpoint VPC di interfaccia
Puoi utilizzare un endpoint VPC di interfaccia, alimentato da AWS PrivateLink, per impedire che il traffico tra Amazon VPC e Amazon MSK APIs lasci la rete Amazon. Gli endpoint VPC di interfaccia non richiedono un gateway Internet, un dispositivo NAT, una connessione VPN o una connessione Direct Connect AWS . [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)è una AWS tecnologia che consente la comunicazione privata tra AWS i servizi utilizzando un'interfaccia di rete elastica con private IPs nel tuo Amazon VPC. Per ulteriori informazioni, consulta [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) and [Interface VPC Endpoints ()](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).AWS PrivateLink
Le tue applicazioni possono connettersi con Amazon MSK Provisioned e MSK Connect APIs utilizzando. AWS PrivateLink Per iniziare, crea un endpoint VPC di interfaccia per la tua API Amazon MSK per avviare il flusso di traffico da e verso le tue risorse Amazon VPC tramite l'endpoint VPC di interfaccia. Gli endpoint VPC con interfaccia FIPS sono disponibili per le regioni degli Stati Uniti. [Per ulteriori informazioni, consulta Create an Interface Endpoint.](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint)
Utilizzando questa funzionalità, i client Apache Kafka possono recuperare dinamicamente le stringhe di connessione per connettersi alle risorse MSK Provisioned o MSK Connect senza dover attraversare Internet per recuperare le stringhe di connessione.
Quando crei un endpoint VPC di interfaccia, scegli uno dei seguenti endpoint con nome di servizio:
**Per MSK Provisioned:**
+ I seguenti endpoint con nomi di servizio non sono più supportati per le nuove connessioni:
+ com.amazonaws.region.kafka
+ com.amazonaws.region.kafka-fips (compatibile con FIPS)
+ I servizi endpoint Dualstack che supportano entrambi e il traffico sono i seguenti: IPv4 IPv6
+ aws.api.region.kafka-api
+ aws.api.region. kafka-api-fips (abilitato per FIPS)
[Per configurare gli endpoint dualstack è necessario seguire le linee guida sugli endpoint Dual-stack e FIPS.](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html)
Dove region è il nome della tua regione. Scegliete questo nome di servizio per utilizzare MSK Provisioned APIs Compatible. *Per ulteriori informazioni, vedere [Operazioni](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) nella versione 1.0/apireference/. https://docs.aws.amazon.com/msk/*
**Per MSK Connect:**
+ com.amazonaws.region.kafkaconnect
Dove regione è il nome della tua regione. Scegliete questo nome di servizio per lavorare con MSK Connect compatibile. APIs Per ulteriori informazioni, consulta [Azioni](https://docs.aws.amazon.com/MSKC/latest/mskc/API_Operations.html) nel *riferimento all'API Amazon MSK Connect*.
*Per ulteriori informazioni, incluse step-by-step le istruzioni per creare un endpoint VPC di interfaccia, vedere [Creazione di un endpoint di interfaccia nella Guida](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).AWS PrivateLink *
## Controlla l'accesso agli endpoint VPC per Amazon MSK Provisioned o MSK Connect APIs
Le policy degli endpoint VPC consentono di controllare l'accesso allegando una policy a un endpoint VPC o utilizzando campi aggiuntivi in una policy allegata a un utente, gruppo o ruolo IAM per limitare l'accesso solo tramite l'endpoint VPC specificato. Utilizzare la politica di esempio appropriata per definire le autorizzazioni di accesso per il servizio MSK Provisioned o MSK Connect.
Se non colleghi una policy durante la creazione di un endpoint, Amazon VPC collega una policy predefinita che consente l'accesso completo al servizio. Una policy endpoint non esclude né sostituisce policy IAM basate sull'identità o policy specifiche del servizio. Si tratta di una policy separata per controllare l'accesso dall'endpoint al servizio specificato.
*Per ulteriori informazioni, consulta [Controllare l'accesso ai servizi con gli endpoint VPC nella Guida](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html).AWS PrivateLink *
------
#### [ MSK Provisioned — VPC policy example ]
**Accesso in sola lettura**
Questa policy di esempio può essere associata a un endpoint VPC. Per ulteriori informazioni, consulta Controllo dell'accesso alle risorse VPC di Amazon. Limita le azioni solo a elencare e descrivere le operazioni tramite l'endpoint VPC a cui è collegato.
```
{
"Statement": [
{
"Sid": "MSKReadOnly",
"Principal": "*",
"Action": [
"kafka:List*",
"kafka:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
**MSK Provisioned — Esempio di policy per gli endpoint VPC**
Limita l'accesso a un cluster MSK specifico
Questa policy di esempio può essere associata a un endpoint VPC. Limita l'accesso a uno specifico cluster Kafka tramite l'endpoint VPC a cui è collegato.
```
{
"Statement": [
{
"Sid": "AccessToSpecificCluster",
"Principal": "*",
"Action": "kafka:*",
"Effect": "Allow",
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster"
}
]
}
```
------
#### [ MSK Connect — VPC endpoint policy example ]
**Elenca i connettori e crea un nuovo connettore**
Di seguito è riportato un esempio di policy sugli endpoint per MSK Connect. Questa politica consente al ruolo specificato di elencare i connettori e creare un nuovo connettore.
```
{
"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 — Esempio di policy per gli endpoint VPC**
Consente solo le richieste provenienti da un indirizzo IP specifico nel VPC specificato
L'esempio seguente mostra una policy che consente l'esito positivo solo delle richieste provenienti da un indirizzo IP specificato nel VPC specificato. Le richieste provenienti da altri indirizzi IP avranno esito negativo.
```
{
"Statement": [
{
"Action": "kafkaconnect:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:VpcSourceIp": "192.0.2.123"
},
"StringEquals": {
"aws:SourceVpc": "vpc-555555555555"
}
}
}
]
}
```
------
# Autenticazione e autorizzazione per Amazon MSK APIs
AWS Identity and Access Management (IAM) è uno strumento Servizio AWS che aiuta un amministratore a controllare in modo sicuro l'accesso alle risorse. AWS Gli amministratori IAM controllano chi può essere *autenticato* (accesso effettuato) e *autorizzato* (dotato di autorizzazioni) per utilizzare le risorse Amazon MSK. IAM è un software Servizio AWS che puoi utilizzare senza costi aggiuntivi.
**Topics**
+ [Funzionamento di Amazon MSK con IAM](security_iam_service-with-iam.md)
+ [Esempi di policy basate sull'identità per Amazon MSK](security_iam_id-based-policy-examples.md)
+ [Ruoli collegati ai servizi per Amazon MSK](using-service-linked-roles.md)
+ [AWS politiche gestite per Amazon MSK](security-iam-awsmanpol.md)
+ [Risolvi i problemi relativi all'identità e all'accesso ad Amazon MSK](security_iam_troubleshoot.md)
# Funzionamento di Amazon MSK con IAM
Prima di utilizzare IAM per gestire l'accesso ad Amazon MSK, è necessario comprendere quali funzioni IAM sono disponibili per l'uso con Amazon MSK. Per avere una visione di alto livello di come Amazon MSK e altri AWS servizi funzionano con IAM, consulta [AWS Services That Work with IAM nella IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) *User Guide*.
**Topics**
+ [Policy basate sull'identità di Amazon MSK](security_iam_service-with-iam-id-based-policies.md)
+ [Policy basate sulle risorse di Amazon MSK](security_iam_service-with-iam-resource-based-policies.md)
+ [Autorizzazione basata sui tag Amazon MSK](security_iam_service-with-iam-tags.md)
+ [Ruoli IAM di Amazon MSK](security_iam_service-with-iam-roles.md)
# Policy basate sull'identità di Amazon MSK
Con le policy basate sull’identità di IAM, è possibile specificare quali operazioni e risorse sono consentite o respinte, nonché le condizioni in base alle quali le operazioni sono consentite o respinte. Amazon MSK supporta operazioni, risorse e chiavi di condizione specifiche. Per informazioni su tutti gli elementi utilizzati in una policy JSON, consulta [Documentazione di riferimento degli elementi delle policy JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) nella *Guida per l'utente IAM*.
## Azioni per le politiche basate sull'identità di Amazon MSK
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L'elemento `Action` di una policy JSON descrive le operazioni che è possibile utilizzare per consentire o negare l'accesso in una policy. Includere le operazioni in una policy per concedere le autorizzazioni a eseguire l’operazione associata.
Le operazioni delle policy in Amazon MSK utilizzano il seguente prefisso prima dell'operazione: `kafka:`. Ad esempio, per concedere a qualcuno l'autorizzazione per descrivere un cluster MSK con l'operazione API `DescribeCluster` di Amazon MSK, includi l'operazione `kafka:DescribeCluster` nella policy. Le istruzioni della policy devono includere un elemento `Action` o `NotAction`. Amazon MSK definisce un proprio set di operazioni che descrivono le attività che puoi eseguire con quel servizio.
Tieni presente che le azioni politiche per l'argomento MSK APIs utilizzano il `kafka-cluster` prefisso prima dell'azione, consulta. [Semantica delle azioni e delle risorse della politica di autorizzazione IAM](kafka-actions.md)
Per specificare più azioni in una sola istruzione, separa ciascuna di esse con una virgola come mostrato di seguito:
```
"Action": ["kafka:action1", "kafka:action2"]
```
È possibile specificare più azioni tramite caratteri jolly (\$1). Ad esempio, per specificare tutte le azioni che iniziano con la parola `Describe`, includi la seguente azione:
```
"Action": "kafka:Describe*"
```
Per visualizzare un elenco delle operazioni di Amazon MSK, consulta la pagina [Actions, resources, and condition keys for Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonmanagedstreamingforapachekafka.html) nella *Guida per l'utente di IAM*.
## Risorse per le politiche basate sull'identità di Amazon MSK
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento JSON `Resource` della policy specifica l’oggetto o gli oggetti ai quali si applica l’operazione. Come best practice, specifica una risorsa utilizzando il suo [nome della risorsa Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Per le azioni che non supportano le autorizzazioni a livello di risorsa, si utilizza un carattere jolly (\$1) per indicare che l’istruzione si applica a tutte le risorse.
```
"Resource": "*"
```
La risorsa istanza di Amazon MSK dispone del seguente ARN:
```
arn:${Partition}:kafka:${Region}:${Account}:cluster/${ClusterName}/${UUID}
```
Per ulteriori informazioni sul formato di ARNs, consulta [Amazon Resource Names (ARNs) e AWS Service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Ad esempio, per specificare l'istanza `CustomerMessages` nell'istruzione, utilizza il seguente ARN:
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/CustomerMessages/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2"
```
Per specificare tutti le istanze che appartengono ad un account specifico, utilizza il carattere jolly (\$1):
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*"
```
Alcune operazioni di Amazon MSK, ad esempio quelle per la creazione delle risorse, non possono essere eseguite su una risorsa specifica. In questi casi, è necessario utilizzare il carattere jolly (\$1).
```
"Resource": "*"
```
Per specificare più risorse in una singola istruzione, separale con virgole. ARNs
```
"Resource": ["resource1", "resource2"]
```
*Per visualizzare un elenco dei tipi di risorse Amazon MSK e relativi ARNs, consulta [Resources Defined by Amazon Managed Streaming for Apache](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-resources-for-iam-policies) Kafka nella IAM User Guide.* Per informazioni sulle operazioni con cui è possibile specificare l'ARN di ogni risorsa, consulta la pagina [Actions Defined by Amazon Managed Service for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Chiavi di condizione per le politiche basate sull'identità di Amazon MSK
Gli amministratori possono utilizzare le policy AWS JSON per specificare chi ha accesso a cosa. In altre parole, quale **entità principale** può eseguire **operazioni** su quali **risorse** e in quali **condizioni**.
L’elemento `Condition` specifica quando le istruzioni vengono eseguite in base a criteri definiti. È possibile compilare espressioni condizionali che utilizzano [operatori di condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), ad esempio uguale a o minore di, per soddisfare la condizione nella policy con i valori nella richiesta. Per visualizzare tutte le chiavi di condizione AWS globali, consulta le chiavi di [contesto delle condizioni AWS globali nella Guida](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) per l'*utente IAM*.
Amazon MSK definisce il proprio set di chiavi di condizione e supporta anche l'utilizzo di alcune chiavi di condizione globali. Per vedere tutte le chiavi di condizione AWS globali, consulta [AWS Global Condition Context Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) nella *Guida per l'utente IAM*.
Per visualizzare un elenco delle chiavi di condizione di Amazon MSK, consulta la pagina [Condition Keys for Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-policy-keys) nella *Guida per l'utente di IAM*. Per informazioni sulle operazioni e le risorse con le quali è possibile utilizzare una chiave di condizione, consulta la pagina [Actions Defined by Amazon Managed Service for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Esempi di policy basate sull'identità di Amazon MSK
Per visualizzare degli esempi di policy basate sull'identità di Amazon MSK, consulta la pagina [Esempi di policy basate sull'identità per Amazon MSK](security_iam_id-based-policy-examples.md).
# Policy basate sulle risorse di Amazon MSK
Amazon MSK supporta una policy del cluster (nota anche come policy basata sulle risorse) da utilizzare con i cluster Amazon MSK. Puoi utilizzare una policy del cluster per definire quali principali IAM dispongono delle autorizzazioni multi-account per configurare la connettività privata al tuo cluster Amazon MSK. In combinazione con l'autenticazione del client IAM, puoi utilizzare la policy del cluster anche per definire in modo granulare le autorizzazioni del piano dati Kafka per i client che si connettono.
La dimensione massima supportata per una policy di cluster è di 20 KB.
Per visualizzare un esempio di come configurare una policy del cluster, consulta la sezione [Passaggio 2: collegamento di una policy del cluster al cluster MSK](mvpc-cluster-owner-action-policy.md).
# Autorizzazione basata sui tag Amazon MSK
È possibile associare tag ai cluster Amazon MSK. Per controllare l’accesso basato su tag, fornire informazioni sui tag nell’[elemento condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) di una policy utilizzando le chiavi di condizione `kafka:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`. Per informazioni sull'etichettatura delle risorse Amazon MSK, consulta. [Contrassegna un tag a un cluster Amazon MSK](msk-tagging.md)
Puoi controllare l'accesso al cluster solo con l'aiuto dei tag. Per etichettare argomenti e gruppi di consumatori, devi aggiungere una dichiarazione separata nelle tue politiche senza tag.
Per visualizzare un esempio di politica basata sull'identità per limitare l'accesso a un cluster in base ai tag di quel cluster, vedi. [Accesso ai cluster Amazon MSK in base ai tag](security_iam_id-based-policy-examples-view-widget-tags.md)
Nella policy basata sull'identità, puoi utilizzare le condizioni per controllare l'accesso alle risorse Amazon MSK in base ai tag. L'esempio seguente mostra una policy che consente a un utente di descrivere il cluster, ottenere i relativi broker bootstrap, elencare i relativi nodi broker, aggiornarlo ed eliminarlo. Tuttavia, questa politica concede l'autorizzazione solo se il tag del cluster `Owner` ha il valore di quell'utente. `username` La seconda dichiarazione della seguente politica consente l'accesso agli argomenti del cluster. La prima dichiarazione di questa politica non autorizza l'accesso ad alcun argomento.
------
#### [ 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/*"
]
}
]
}
```
------
# Ruoli IAM di Amazon MSK
Un [ruolo IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) è un'entità all'interno dell'account Amazon Web Services che dispone di autorizzazioni specifiche.
## Utilizzo delle credenziali temporanee con Amazon MSK
È possibile utilizzare credenziali temporanee per effettuare l'accesso con la federazione, assumere un ruolo IAM o un ruolo multi-account. È possibile ottenere credenziali di sicurezza temporanee chiamando operazioni AWS STS API come [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)o. [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)
Amazon MSK supporta l'uso delle credenziali temporanee.
## Ruoli collegati ai servizi
I [ruoli collegati ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) permettono ad Amazon Web Services di accedere a risorse in altri servizi per completare un'operazione a tuo nome. I ruoli collegati ai servizi sono visualizzati nell'account IAM e sono di proprietà del servizio. Un amministratore può visualizzare, ma non modificare le autorizzazioni dei ruoli collegati ai servizi.
Amazon MSK supporta i ruoli collegati ai servizi. Per maggiori dettagli su come creare e gestire i ruoli collegati ai servizi di Amazon MSK, consulta la pagina [Ruoli collegati ai servizi per Amazon MSK](using-service-linked-roles.md).
# Esempi di policy basate sull'identità per Amazon MSK
Per impostazione predefinita, gli utenti e i ruoli IAM non sono autorizzati a eseguire le operazioni API di Amazon MSK. Un amministratore deve creare le policy IAM che concedono a utenti e ruoli l'autorizzazione per eseguire operazioni API specifiche sulle risorse specificate di cui hanno bisogno. L'amministratore deve quindi allegare queste policy a utenti o IAM che richiedono tali autorizzazioni.
Per informazioni su come creare una policy basata su identità IAM utilizzando questi documenti di policy JSON di esempio, consulta [Creazione di policy nella scheda JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) nella *Guida per l'utente IAM*.
**Topics**
+ [Best practice delle policy](security_iam_service-with-iam-policy-best-practices.md)
+ [Consentire agli utenti di visualizzare le loro autorizzazioni](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Accesso a un cluster Amazon MSK](security_iam_id-based-policy-examples-access-one-cluster.md)
+ [Accesso ai cluster Amazon MSK in base ai tag](security_iam_id-based-policy-examples-view-widget-tags.md)
# Best practice delle policy
Le policy basate sull'identità determinano se qualcuno può creare, accedere o eliminare risorse Amazon MSK all'interno dell'account. Queste azioni possono comportare costi aggiuntivi per l’ Account AWS. Quando si creano o modificano policy basate sull’identità, seguire queste linee guida e raccomandazioni:
+ **Inizia con le policy AWS gestite e passa alle autorizzazioni con privilegi minimi: per iniziare a concedere autorizzazioni** a utenti e carichi di lavoro, utilizza le *politiche AWS gestite* che concedono le autorizzazioni per molti casi d'uso comuni. Sono disponibili nel tuo. Account AWS Ti consigliamo di ridurre ulteriormente le autorizzazioni definendo politiche gestite dai AWS clienti specifiche per i tuoi casi d'uso. Per maggiori informazioni, consulta [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o [Policy gestite da AWS per le funzioni dei processi](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) nella *Guida per l’utente di IAM*.
+ **Applicazione delle autorizzazioni con privilegio minimo** - Quando si impostano le autorizzazioni con le policy IAM, concedere solo le autorizzazioni richieste per eseguire un’attività. È possibile farlo definendo le azioni che possono essere intraprese su risorse specifiche in condizioni specifiche, note anche come *autorizzazioni con privilegio minimo*. Per maggiori informazioni sull’utilizzo di IAM per applicare le autorizzazioni, consulta [Policy e autorizzazioni in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) nella *Guida per l’utente di IAM*.
+ **Condizioni d’uso nelle policy IAM per limitare ulteriormente l’accesso** - Per limitare l’accesso ad azioni e risorse è possibile aggiungere una condizione alle policy. Ad esempio, è possibile scrivere una condizione di policy per specificare che tutte le richieste devono essere inviate utilizzando SSL. Puoi anche utilizzare le condizioni per concedere l'accesso alle azioni del servizio se vengono utilizzate tramite uno specifico Servizio AWS, ad esempio CloudFormation. Per maggiori informazioni, consultare la sezione [Elementi delle policy JSON di IAM: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l’utente di IAM*.
+ **Utilizzo dello strumento di analisi degli accessi IAM per convalidare le policy IAM e garantire autorizzazioni sicure e funzionali** - Lo strumento di analisi degli accessi IAM convalida le policy nuove ed esistenti in modo che aderiscano al linguaggio (JSON) della policy IAM e alle best practice di IAM. Lo strumento di analisi degli accessi IAM offre oltre 100 controlli delle policy e consigli utili per creare policy sicure e funzionali. Per maggiori informazioni, consultare [Convalida delle policy per il Sistema di analisi degli accessi IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) nella *Guida per l’utente di IAM*.
+ **Richiedi l'autenticazione a più fattori (MFA**): se hai uno scenario che richiede utenti IAM o un utente root nel Account AWS tuo, attiva l'MFA per una maggiore sicurezza. Per richiedere la MFA quando vengono chiamate le operazioni API, aggiungere le condizioni MFA alle policy. Per maggiori informazioni, consultare [Protezione dell’accesso API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) nella *Guida per l’utente di IAM*.
Per maggiori informazioni sulle best practice in IAM, consulta [Best practice di sicurezza in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) nella *Guida per l’utente di IAM*.
# Consentire agli utenti di visualizzare le loro autorizzazioni
Questo esempio mostra in che modo è possibile creare una policy che consente agli utenti IAM di visualizzare le policy inline e gestite che sono collegate alla relativa identità utente. Questa policy include le autorizzazioni per completare questa azione sulla console o utilizzando programmaticamente l'API o. 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": "*"
}
]
}
```
# Accesso a un cluster Amazon MSK
In questo esempio, si desidera concedere a un utente IAM nell'account Amazon Web Services l'accesso a uno dei cluster, `purchaseQueriesCluster`. Questa policy consente all'utente di descrivere il cluster, ottenere i broker bootstrap, elencare i nodi broker e aggiornarlo.
------
#### [ 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"
}
]
}
```
------
# Accesso ai cluster Amazon MSK in base ai tag
Nella policy basata sull'identità, puoi utilizzare le condizioni per controllare l'accesso alle risorse Amazon MSK in base ai tag. In questo esempio viene illustrato come creare una policy che consente all'utente di descrivere il cluster, ottenere i broker bootstrap, elencare i nodi broker, aggiornarlo ed eliminarlo. Tuttavia, l'autorizzazione viene concessa solo se il valore del tag di cluster `Owner` è quello del nome utente.
------
#### [ 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}"
}
}
}
]
}
```
------
Puoi allegare questa policy agli utenti IAM nel tuo account. Se un utente denominato `richard-roe` tenta di aggiornare un cluster MSK, al cluster deve essere applicato il tag `Owner=richard-roe` o `owner=richard-roe`. In caso contrario, gli viene negato l'accesso. La chiave di tag di condizione `Owner` corrisponde a `Owner` e `owner` perché i nomi delle chiavi di condizione non effettuano la distinzione tra maiuscole e minuscole. Per ulteriori informazioni, consulta la sezione [Elementi delle policy JSON di IAM: condizione](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) nella *Guida per l'utente di IAM*.
# Ruoli collegati ai servizi per Amazon MSK
Amazon MSK utilizza ruoli collegati ai [servizi AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un ruolo collegato ai servizi è un tipo di ruolo IAM univoco collegato direttamente ad Amazon MSK. I ruoli collegati ai servizi sono predefiniti da Amazon MSK e includono tutte le autorizzazioni richieste dal servizio per chiamare altri AWS servizi per tuo conto.
Un ruolo collegato ai servizi semplifica la configurazione di Amazon MSK perché consente di evitare l'aggiunta manuale delle autorizzazioni necessarie. Amazon MSK definisce le autorizzazioni dei ruoli collegati ai servizi. Se non diversamente definito, solo Amazon MSK può assumere i suoi ruoli. Le autorizzazioni definite includono la policy di attendibilità e la policy delle autorizzazioni. Una policy delle autorizzazioni specifica non può essere collegata a un'altra entità IAM.
Per informazioni sugli altri servizi che supportano i ruoli collegati ai servizi, consulta la pagina [Amazon Web Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e cerca i servizi che riportano **Sì **nella colonna **Ruolo collegato ai servizi**. Scegliere **Sì** in corrispondenza di un link per visualizzare la documentazione relativa al ruolo collegato al servizio per tale servizio.
**Topics**
+ [Autorizzazioni del ruolo collegato ai servizi](slr-permissions.md)
+ [Crea un ruolo collegato al servizio](create-slr.md)
+ [Modifica di un ruolo collegato al servizio](edit-slr.md)
+ [Regioni supportate per i ruoli collegati ai servizi](slr-regions.md)
# Autorizzazioni del ruolo collegato ai servizi per Amazon MSK
Amazon MSK usa il ruolo collegato ai servizi denominato **AWSServiceRoleForKafka**. Amazon MSK utilizza questo ruolo per accedere alle risorse ed eseguire operazioni come:
+ `*NetworkInterface`: crea e gestisci interfacce di rete nell'account cliente che rendano i broker del cluster accessibili ai client nel VPC del cliente.
+ `*VpcEndpoints`— gestire gli endpoint VPC nell'account cliente che rendono i broker di cluster accessibili ai clienti nel VPC del cliente utilizzando. AWS PrivateLink Amazon MSK utilizza le autorizzazioni per `DescribeVpcEndpoints`, `ModifyVpcEndpoint` e `DeleteVpcEndpoints`.
+ `secretsmanager`— gestisci le credenziali dei clienti con. Gestione dei segreti AWS
+ `GetCertificateAuthorityCertificate`: recupera il certificato per la tua autorità di certificazione privata.
+ `*Ipv6Addresses`— assegna e annulla l'assegnazione di IPv6 indirizzi alle interfacce di rete nell'account cliente per abilitare la connettività per i cluster MSK. IPv6
+ `ModifyNetworkInterfaceAttribute`— modifica gli attributi dell'interfaccia di rete nell'account cliente per configurare IPv6 le impostazioni per la connettività del cluster MSK.
Questo ruolo collegato ai servizi è collegato alle seguenti policy gestite: `KafkaServiceRolePolicy`. Per gli aggiornamenti a questa policy, consulta [KafkaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KafkaServiceRolePolicy.html).
Ai fini dell’assunzione del ruolo, il ruolo collegato al servizio AWSServiceRoleForKafka considera attendibili i seguenti servizi:
+ `kafka.amazonaws.com`
La policy delle autorizzazioni del ruolo consente ad Amazon MSK di completare le seguenti operazioni sulle risorse.
Per consentire a un'entità IAM (come un utente, un gruppo o un ruolo) di creare, modificare o eliminare un ruolo collegato al servizio è necessario configurare le relative autorizzazioni. Per ulteriori informazioni, consulta [Autorizzazioni del ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) nella *Guida per l'utente di IAM*.
# Crea un ruolo collegato ai servizi per Amazon MSK
Non è necessario creare manualmente un ruolo collegato ai servizi. Quando crei un cluster Amazon MSK nell'API Console di gestione AWS, nell'o nell' AWS API AWS CLI, Amazon MSK crea automaticamente il ruolo collegato al servizio.
Se elimini questo ruolo collegato al servizio, è possibile ricrearlo seguendo lo stesso processo utilizzato per ricreare il ruolo nell’account. Quando si crea un cluster Amazon MSK, Amazon MSK crea di nuovo automaticamente il ruolo collegato ai servizi per conto dell'utente.
# Modificare un ruolo collegato al servizio per Amazon MSK
Amazon MSK non consente di modificare il ruolo collegato al servizio AWSServiceRoleForKafka. Dopo avere creato un ruolo collegato al servizio, non sarà possibile modificarne il nome perché varie entità potrebbero farvi riferimento. È possibile tuttavia modificarne la descrizione utilizzando IAM. Per ulteriori informazioni, consulta la sezione [Modifica di un ruolo collegato ai servizi](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) nella *Guida per l'utente di IAM*.
# Regioni supportate per i ruoli collegati ai servizi di Amazon MSK
Amazon MSK supporta l'utilizzo di ruoli collegati ai servizi in tutte le regioni in cui il servizio è disponibile. Per ulteriori informazioni, consulta [AWS Regioni ed endpoint](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# AWS politiche gestite per Amazon MSK
Una politica AWS gestita è una politica autonoma creata e amministrata da. AWS AWS le politiche gestite sono progettate per fornire autorizzazioni per molti casi d'uso comuni, in modo da poter iniziare ad assegnare autorizzazioni a utenti, gruppi e ruoli.
Tieni presente che le policy AWS gestite potrebbero non concedere le autorizzazioni con il privilegio minimo per i tuoi casi d'uso specifici, poiché sono disponibili per tutti i clienti. AWS Si consiglia pertanto di ridurre ulteriormente le autorizzazioni definendo [policy gestite dal cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) specifiche per i propri casi d'uso.
Non è possibile modificare le autorizzazioni definite nelle politiche gestite. AWS Se AWS aggiorna le autorizzazioni definite in una politica AWS gestita, l'aggiornamento ha effetto su tutte le identità principali (utenti, gruppi e ruoli) a cui è associata la politica. AWS è più probabile che aggiorni una policy AWS gestita quando ne Servizio AWS viene lanciata una nuova o quando diventano disponibili nuove operazioni API per i servizi esistenti.
Per ulteriori informazioni, consultare [Policy gestite da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) nella *Guida per l'utente di IAM*.
# AWS politica gestita: Amazon MSKFull Access
Questa policy concede autorizzazioni amministrative che consentono a un principale l'accesso completo a tutte le operazioni di Amazon MSK. Le autorizzazioni in questa policy sono raggruppate come segue:
+ Le autorizzazioni Amazon MSK consentono tutte le operazioni di Amazon MSK.
+ **`Amazon EC2`autorizzazioni**: in questa politica sono necessarie per convalidare le risorse passate in una richiesta API. Questo serve a garantire che Amazon MSK sia in grado di utilizzare correttamente le risorse di un cluster. Le altre autorizzazioni di Amazon EC2 incluse in questa policy consentono ad Amazon MSK di creare AWS le risorse necessarie per consentirti di connetterti ai tuoi cluster.
+ **`AWS KMS`autorizzazioni**: vengono utilizzate durante le chiamate API per convalidare le risorse passate in una richiesta. Sono necessarie per consentire ad Amazon MSK di utilizzare la chiave passata con il cluster Amazon MSK.
+ **`CloudWatch Logs, Amazon S3, and Amazon Data Firehose`autorizzazioni**: sono necessarie per consentire ad Amazon MSK di garantire che le destinazioni di consegna dei log siano raggiungibili e che siano valide per l'utilizzo dei log da parte dei broker.
+ **`IAM`autorizzazioni**: sono necessarie per consentire ad Amazon MSK di creare un ruolo collegato al servizio nel tuo account e per consentirti di passare un ruolo di esecuzione del servizio ad Amazon MSK.
------
#### [ 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 politica gestita: Amazon MSKRead OnlyAccess
Questa policy concede autorizzazioni di sola lettura che consentono agli utenti di visualizzare informazioni in Amazon MSK. I principali ai quali è collegata questa policy non possono effettuare aggiornamenti o eliminare risorse esistenti, né possono creare nuove risorse Amazon MSK. Ad esempio, i principali con queste autorizzazioni possono visualizzare l'elenco dei cluster e delle configurazioni associati al proprio account, ma non possono modificare la configurazione o le impostazioni di alcun cluster. Le autorizzazioni in questa policy sono raggruppate come segue:
+ **`Amazon MSK`autorizzazioni**: consentono di elencare le risorse Amazon MSK, descriverle e ottenere informazioni su di esse.
+ **`Amazon EC2`autorizzazioni**: vengono utilizzate per descrivere Amazon VPC, le sottoreti, i gruppi di sicurezza ENIs e sono associati a un cluster.
+ **`AWS KMS`autorizzazione**: viene utilizzata per descrivere la chiave associata al cluster.
------
#### [ 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 politica gestita: KafkaServiceRolePolicy
Non puoi collegarti KafkaServiceRolePolicy alle tue entità IAM. Questa policy è collegata a un ruolo collegato ai servizi che consente ad Amazon MSK di eseguire operazioni come la gestione degli endpoint VPC (connettori) nei cluster MSK, la gestione delle interfacce di rete e la gestione delle credenziali del cluster con Gestione dei segreti AWS. Per ulteriori informazioni, consulta [Ruoli collegati ai servizi per Amazon MSK](using-service-linked-roles.md).
La tabella seguente descrive gli aggiornamenti alla policy KafkaServiceRolePolicy gestita da quando Amazon MSK ha iniziato a tracciare le modifiche.
| Modifica | Descrizione | Data |
| --- | --- | --- |
| [IPv6 supporto per la connettività aggiunto a KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy): aggiornamento di una policy esistente | Amazon MSK ha aggiunto le autorizzazioni per KafkaServiceRolePolicy abilitare la IPv6 connettività per i cluster MSK. Queste autorizzazioni consentono ad Amazon MSK di assegnare e annullare l'assegnazione di IPv6 indirizzi alle interfacce di rete e di modificare gli attributi dell'interfaccia di rete nell'account del cliente. | 17 novembre 2025 |
| [KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy): aggiornamento di una policy esistente | Amazon MSK ha aggiunto le autorizzazioni per supportare la connettività privata multi-VPC. | 8 marzo 2023 |
| Amazon MSK ha iniziato a tenere traccia delle modifiche | Amazon MSK ha iniziato a tracciare le modifiche per le policy KafkaServiceRolePolicy gestite. | 8 marzo 2023 |
# AWS politica gestita: AWSMSKReplicator ExecutionRole
La `AWSMSKReplicatorExecutionRole` policy concede le autorizzazioni al replicatore Amazon MSK per replicare i dati tra cluster MSK. Le autorizzazioni in questa policy sono raggruppate come segue:
+ **`cluster`**— Concede ad Amazon MSK Replicator le autorizzazioni per connettersi al cluster utilizzando l'autenticazione IAM. Concede inoltre le autorizzazioni per descrivere e modificare il cluster.
+ **`topic`**— Concede ad Amazon MSK Replicator le autorizzazioni per descrivere, creare e modificare un argomento e per modificare la configurazione dinamica dell'argomento.
+ **`consumer group`**— Concede ad Amazon MSK Replicator le autorizzazioni per descrivere e modificare gruppi di consumatori, leggere e scrivere dati da un cluster MSK e eliminare argomenti interni creati dal replicatore.
------
#### [ 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 aggiorna le politiche AWS gestite
Visualizza i dettagli sugli aggiornamenti delle politiche AWS gestite per Amazon MSK da quando questo servizio ha iniziato a tracciare queste modifiche.
| Modifica | Descrizione | Data |
| --- | --- | --- |
| [WriteDataIdempotently autorizzazione aggiunta a AWSMSKReplicator ExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md): aggiornamento a una politica esistente | Amazon MSK ha aggiunto WriteDataIdempotently l'autorizzazione alla AWSMSKReplicator ExecutionRole policy per supportare la replica dei dati tra cluster MSK. | 12 marzo 2024 |
| [AWSMSKReplicatorExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md): nuova policy | Amazon MSK ha aggiunto una AWSMSKReplicator ExecutionRole policy per supportare Amazon MSK Replicator. | 04 dicembre 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md): aggiornamento a una politica esistente | Amazon MSK ha aggiunto le autorizzazioni per supportare il replicatore Amazon MSK. | 28 settembre 2023 |
| [KafkaServiceRolePolicy](security-iam-awsmanpol-KafkaServiceRolePolicy.md): aggiornamento di una policy esistente | Amazon MSK ha aggiunto le autorizzazioni per supportare la connettività privata multi-VPC. | 8 marzo 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md): aggiornamento a una politica esistente | Amazon MSK ha aggiunto nuove autorizzazioni Amazon EC2 per consentire la connessione a un cluster. | 30 novembre 2021 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md): aggiornamento a una politica esistente | Amazon MSK ha aggiunto una nuova autorizzazione per consentirgli di descrivere le tabelle di routing di Amazon EC2. | 19 novembre 2021 |
| Amazon MSK ha iniziato a tenere traccia delle modifiche | Amazon MSK ha iniziato a tracciare le modifiche per le sue politiche AWS gestite. | 19 novembre 2021 |
# Risolvi i problemi relativi all'identità e all'accesso ad Amazon MSK
Utilizza le informazioni seguenti per eseguire la diagnosi e risolvere i problemi comuni che possono verificarsi durante l'utilizzo di Amazon MSK e IAM.
**Topics**
+ [Non dispongo dell'autorizzazione per eseguire un'operazione in Amazon MSK](#security_iam_troubleshoot-no-permissions)
## Non dispongo dell'autorizzazione per eseguire un'operazione in Amazon MSK
Se ti Console di gestione AWS dice che non sei autorizzato a eseguire un'azione, devi contattare l'amministratore per ricevere assistenza. L’amministratore è colui che ti ha fornito le credenziali di accesso.
L'errore di esempio seguente si verifica quando l'utente IAM `mateojackson` cerca di utilizzare la console per eliminare un cluster senza disporre delle autorizzazioni `kafka:DeleteCluster`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: kafka:DeleteCluster on resource: purchaseQueriesCluster
```
In questo caso, Mateo chiede al suo amministratore di aggiornare le policy per poter accedere alla risorsa `purchaseQueriesCluster` mediante l'operazione `kafka:DeleteCluster`.
# Autenticazione e autorizzazione per Apache Kafka APIs
Puoi utilizzare IAM per autenticare i client e consentire o rifiutare le operazioni di Apache Kafka. In alternativa, puoi utilizzare TLS o SASL/SCRAM per autenticare i client e Apache ACLs Kafka per consentire o negare azioni.
Per informazioni su come controllare chi può eseguire le [operazioni di Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) sul tuo cluster, consulta la pagina [Autenticazione e autorizzazione per Amazon MSK APIs](security-iam.md).
**Topics**
+ [Controllo degli accessi IAM](iam-access-control.md)
+ [Autenticazione client TLS reciproca per Amazon MSK](msk-authentication.md)
+ [Autenticazione delle credenziali di accesso con Secrets Manager AWS](msk-password.md)
+ [Apache Kafka ACLs](msk-acls.md)
# Controllo degli accessi IAM
Il Controllo degli accessi IAM per Amazon MSK ti consente di gestire sia l'autenticazione sia l'autorizzazione per il cluster MSK. Ciò elimina la necessità di utilizzare meccanismi separati per l'autenticazione e l'autorizzazione. Ad esempio, quando un client tenta di scrivere sul cluster, Amazon MSK utilizza IAM per verificare se tale client è un'identità autenticata e se è autorizzato a produrre nel cluster.
Il controllo degli accessi IAM funziona per client Java e non Java, inclusi i client Kafka scritti in Python, Go e.NET. JavaScript Il controllo degli accessi IAM per client non Java è disponibile per i cluster MSK con Kafka versione 2.7.1 o successiva.
Per rendere possibile il Controllo degli accessi IAM, Amazon MSK apporta piccole modifiche al codice sorgente di Apache Kafka. Queste modifiche non causeranno differenze evidenti nella tua esperienza con Apache Kafka. Amazon MSK registra gli eventi di accesso in modo da poterli controllare.
È possibile richiamare Apache Kafka ACL per un cluster MSK che utilizza il controllo degli accessi IAM. APIs Tuttavia, Apache Kafka ACLs non ha alcun effetto sull'autorizzazione per le identità IAM. È necessario utilizzare le policy IAM per controllare l'accesso alle identità IAM.
**Considerazioni importanti**
Quando utilizzi il controllo degli accessi IAM con il tuo cluster MSK, tieni presenti le seguenti importanti considerazioni:
Il controllo degli accessi IAM non si applica ai nodi ZooKeeper Apache. Per ulteriori informazioni sul controllo degli accessi a tali nodi, consulta la pagina [Controlla l'accesso ai ZooKeeper nodi Apache nel tuo cluster Amazon MSK](zookeeper-security.md).
L'impostazione `allow.everyone.if.no.acl.found` di Apache Kafka non ha effetto se il cluster utilizza il Controllo degli accessi IAM.
Puoi richiamare Apache Kafka ACL APIs per un cluster MSK che utilizza il controllo degli accessi IAM. Tuttavia, Apache Kafka ACLs non ha alcun effetto sull'autorizzazione per le identità IAM. È necessario utilizzare le policy IAM per controllare l'accesso alle identità IAM.
# Come funziona il Controllo degli accessi IAM per Amazon MSK
Per utilizzare il controllo degli accessi IAM per Amazon MSK, esegui i seguenti passaggi, descritti in dettaglio in questi argomenti:
+ [Crea un cluster Amazon MSK che utilizza il controllo degli accessi IAM](create-iam-access-control-cluster-in-console.md)
+ [Configurazione dei client per il Controllo degli accessi IAM](configure-clients-for-iam-access-control.md)
+ [Crea politiche di autorizzazione per il ruolo IAM](create-iam-access-control-policies.md)
+ [Recupero dei broker di bootstrap per il Controllo degli accessi IAM](get-bootstrap-brokers-for-iam.md)
# Crea un cluster Amazon MSK che utilizza il controllo degli accessi IAM
Questa sezione spiega come utilizzare Console di gestione AWS, l'API o il AWS CLI per creare un cluster Amazon MSK che utilizza il controllo degli accessi IAM. Per informazioni su come attivare il Controllo degli accessi IAM per un cluster esistente, consulta la pagina [Aggiornamento delle impostazioni di sicurezza di un cluster Amazon MSK](msk-update-security.md).
**Utilizza il Console di gestione AWS per creare un cluster che utilizza il controllo degli accessi IAM**
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Scegli **Crea cluster**.
1. Scegli **Crea cluster con impostazioni personalizzate**.
1. Nella sezione **Autenticazione**, scegli **Controllo degli accessi IAM**.
1. Completa il resto del flusso di lavoro per creare un cluster.
**Utilizza l'API o il AWS CLI per creare un cluster che utilizza il controllo degli accessi IAM**
+ Per creare un cluster con il controllo degli accessi IAM abilitato, utilizza l'[CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)API o il comando [CLI create-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/create-cluster.html) e passa il seguente JSON per il parametro:. `ClientAuthentication` `"ClientAuthentication": { "Sasl": { "Iam": { "Enabled": true } }`
# Configurazione dei client per il Controllo degli accessi IAM
Per consentire ai client di comunicare con un cluster MSK che utilizza il controllo degli accessi IAM, è possibile utilizzare uno di questi meccanismi:
+ Configurazione client non Java tramite meccanismo SASL\$1OAUTHBEARER
+ Configurazione del client Java mediante SASL\$1OAUTHBEARER meccanismo o AWS\$1MSK\$1IAM meccanismo
## Usa il SASL\$1OAUTHBEARER meccanismo per configurare IAM
1. Modifica il tuo file di configurazione client.properties usando il seguente esempio di client Python Kafka. Le modifiche alla configurazione sono simili in altri linguaggi.
```
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. Scarica la libreria di supporto per la lingua di configurazione scelta e segui le istruzioni nella sezione *Guida introduttiva* della home page della libreria di lingue in questione.
+ JavaScript: [https://github.com/aws/aws-msk-iam-sasl-signer-js \$1getting -started](https://github.com/aws/aws-msk-iam-sasl-signer-js#getting-started)
+ Python: [https://github.com/aws/aws-msk-iam-sasl-signer-python \$1get -avviato](https://github.com/aws/aws-msk-iam-sasl-signer-python#get-started)
+ Vai: [https://github.com/aws/aws-msk-iam-sasl-signer-go \$1getting -started](https://github.com/aws/aws-msk-iam-sasl-signer-go#getting-started)
+ [.NET: -signer-net \$1getting -iniziato https://github.com/aws/ aws-msk-iam-sasl](https://github.com/aws/aws-msk-iam-sasl-signer-net#getting-started)
+ JAVA: SASL\$1OAUTHBEARER il supporto per Java è disponibile tramite il file jar [https://github.com/aws/aws-msk-iam-auth/releases](https://github.com/aws/aws-msk-iam-auth/releases)
## Utilizza il AWS\$1MSK\$1IAM meccanismo personalizzato MSK per configurare IAM
1. Aggiungi quanto segue al file `client.properties`. Sostituisci ** con il percorso completo del file di trust store sul client.
**Nota**
Se non desideri utilizzare un certificato specifico, puoi rimuovere `ssl.truststore.location=` dal tuo file `client.properties`. Se non specifichi un valore per `ssl.truststore.location`, il processo Java utilizza il certificato predefinito.
```
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
```
Per utilizzare un profilo denominato creato per AWS le credenziali, includilo `awsProfileName="your profile name";` nel file di configurazione del client. Per informazioni sui profili denominati, consulta [Profili denominati](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html) nella AWS CLI documentazione.
1. Scaricate l'ultimo file [aws-msk-iam-auth](https://github.com/aws/aws-msk-iam-auth/releases)JAR stabile e inseritelo nel percorso della classe. Se utilizzi Maven, aggiungi la seguente dipendenza, modificando il numero di versione secondo necessità:
```
software.amazon.msk
aws-msk-iam-auth
1.0.0
```
Il plug-in client di Amazon MSK è open source con licenza Apache 2.0.
# Crea politiche di autorizzazione per il ruolo IAM
Collega una policy di autorizzazione al ruolo IAM corrispondente al client. In una policy di autorizzazione, specifichi quali operazioni consentire o rifiutare per il ruolo. Se il tuo client è su un'istanza Amazon EC2, associa la policy di autorizzazione al ruolo IAM per quell'istanza Amazon EC2. In alternativa, puoi configurare il client per utilizzare un profilo denominato e quindi associare la policy di autorizzazione al ruolo per quel profilo denominato. [Configurazione dei client per il Controllo degli accessi IAM](configure-clients-for-iam-access-control.md) descrive come configurare un client per utilizzare un profilo denominato.
Per informazioni sulla creazione di una policy IAM, consulta la pagina [Creating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).
Di seguito è riportato un esempio di politica di autorizzazione per un cluster denominato MyTestCluster. Per comprendere la semantica degli elementi `Action` e `Resource`, consulta la pagina [Semantica delle azioni e delle risorse della politica di autorizzazione IAM](kafka-actions.md).
**Importante**
Le modifiche apportate a una policy IAM si riflettono nell'IAM APIs e nell' AWS CLI immediatezza. Tuttavia, può trascorrere molto tempo prima che la modifica della policy abbia effetto. Nella maggior parte dei casi, le modifiche alle policy entrano in vigore in meno di un minuto. A volte le condizioni della rete possono aumentare il ritardo.
------
#### [ 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/*"
]
}
]
}
```
------
Per informazioni su come creare una policy con elementi di operazione che corrispondano ai casi d'uso comuni di Apache Kafka, come la produzione e l'utilizzo di dati, consulta la pagina [Casi d'uso comuni per la politica di autorizzazione dei client](iam-access-control-use-cases.md).
[Per le versioni di Kafka 2.8.0 e successive, l'**WriteDataIdempotently**autorizzazione è obsoleta (KIP-679).](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default) Per impostazione predefinita, viene utilizzato `enable.idempotence = true`. Pertanto, per le versioni di Kafka 2.8.0 e successive, IAM non offre le stesse funzionalità di Kafka. ACLs Non è possibile accedere a un argomento fornendo solo `WriteDataIdempotently` l'accesso a quell'argomento. `WriteData` Ciò non influisce sul caso in cui `WriteData` venga fornito a **TUTTI gli** argomenti. In tal caso, l'operazione `WriteDataIdempotently` è consentita. Ciò è dovuto alle differenze nell'implementazione della logica IAM e nel modo in cui ACLs vengono implementati i Kafka. Inoltre, scrivere su un argomento in modo idempotente richiede anche l'accesso a. `transactional-ids`
Per ovviare a questo problema, consigliamo di utilizzare una politica simile alla seguente politica.
------
#### [ 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 questo caso, `WriteData` consente le scritture sul `TestTopic`, mentre `WriteDataIdempotently` consente le scritture idempotenti sul cluster. Questa politica aggiunge anche l'accesso alle `transactional-id` risorse che saranno necessarie.
Poiché `WriteDataIdempotently` si tratta di un'autorizzazione a livello di cluster, non è possibile utilizzarla a livello di argomento. Se `WriteDataIdempotently` è limitato al livello di argomento, questo criterio non funzionerà.
# Recupero dei broker di bootstrap per il Controllo degli accessi IAM
Per informazioni, consulta [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md).
# Semantica delle azioni e delle risorse della politica di autorizzazione IAM
**Nota**
Per i cluster che eseguono Apache Kafka versione 3.8 o successiva, il controllo degli accessi IAM supporta l'API per terminare le transazioni. WriteTxnMarkers Per i cluster che eseguono versioni di Kafka precedenti alla 3.8, il controllo degli accessi IAM non supporta le azioni interne del cluster, tra cui. WriteTxnMarkers Per queste versioni precedenti, per terminare le transazioni, utilizza l'autenticazione SCRAM o MTLS con l'autenticazione appropriata anziché l'autenticazione IAM. ACLs
In questa sezione viene illustrata la semantica degli elementi di operazione e risorsa che è possibile utilizzare in una policy di autorizzazione IAM. Per un esempio di policy, consulta [Crea politiche di autorizzazione per il ruolo IAM](create-iam-access-control-policies.md).
## Azioni relative alla politica di autorizzazione
La tabella seguente elenca le operazioni che è possibile includere in una policy di autorizzazione quando si utilizza il Controllo degli accessi IAM per Amazon MSK. Quando includi nella tua policy di autorizzazione un'operazione dalla colonna *Operazione* della tabella, devi includere anche le operazioni corrispondenti dalla colonna *Operazioni richieste*.
| Azione | Description | Operazioni necessarie | Risorse obbligatorie | Applicabile ai cluster serverless |
| --- | --- | --- | --- | --- |
| kafka-cluster:Connect | Concede l'autorizzazione per connettersi e autenticarsi al cluster. | Nessuno | cluster | Sì |
| kafka-cluster:DescribeCluster | Concede l'autorizzazione per descrivere vari aspetti del cluster, equivalente all'ACL DESCRIBE CLUSTER di Apache Kafka. | `kafka-cluster:Connect` | cluster | Sì |
| kafka-cluster:AlterCluster | Concede l'autorizzazione per modificare vari aspetti del cluster, equivalente all'ACL ALTER CLUSTER di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeCluster` | cluster | No |
| kafka-cluster:DescribeClusterDynamicConfiguration | Concede l'autorizzazione per descrivere la configurazione dinamica di un cluster, equivalente all'ACL DESCRIBE\$1CONFIGS CLUSTER di Apache Kafka. | `kafka-cluster:Connect` | cluster | No |
| kafka-cluster:AlterClusterDynamicConfiguration | Concede l'autorizzazione per modificare la configurazione dinamica di un cluster, equivalente all'ACL ALTER\$1CONFIGS CLUSTER di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` | cluster | No |
| kafka-cluster:WriteDataIdempotently | Concede l'autorizzazione per scrivere dati in modo idempotente su un cluster, equivalente all'ACL IDEMPOTENT\$1WRITE CLUSTER di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:WriteData` | cluster | Sì |
| kafka-cluster:CreateTopic | Concede l'autorizzazione a creare argomenti su un cluster, equivalente all'ACL CREATE di Apache Kafka. CLUSTER/TOPIC | `kafka-cluster:Connect` | topic | Sì |
| kafka-cluster:DescribeTopic | Concede l'autorizzazione per descrivere gli argomenti in un cluster, equivalente all'ACL DESCRIBE TOPIC di Apache Kafka. | `kafka-cluster:Connect` | topic | Sì |
| kafka-cluster:AlterTopic | Concede l'autorizzazione per modificare gli argomenti in un cluster, equivalente all'ACL ALTER TOPIC di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Sì |
| kafka-cluster:DeleteTopic | Concede l'autorizzazione per eliminare gli argomenti in un cluster, equivalente all'ACL DELETE TOPIC di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Sì |
| kafka-cluster:DescribeTopicDynamicConfiguration | Concede l'autorizzazione per descrivere la configurazione dinamica degli argomenti in un cluster, equivalente all'ACL DESCRIBE\$1CONFIGS TOPIC di Apache Kafka. | `kafka-cluster:Connect` | topic | Sì |
| kafka-cluster:AlterTopicDynamicConfiguration | Concede l'autorizzazione per modificare la configurazione dinamica degli argomenti in un cluster, equivalente all'ACL ALTER\$1CONFIGS TOPIC di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` | topic | Sì |
| kafka-cluster:ReadData | Concede l'autorizzazione per leggere i dati da argomenti in un cluster, equivalente all'ACL READ TOPIC di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterGroup` | topic | Sì |
| kafka-cluster:WriteData | Concede l'autorizzazione per scrivere dati su argomenti in un cluster, equivalente all'ACL WRITE TOPIC di Apache Kafka | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topic | Sì |
| kafka-cluster:DescribeGroup | Concede l'autorizzazione per descrivere i gruppi in un cluster, equivalente all'ACL DESCRIBE GROUP di Apache Kafka. | `kafka-cluster:Connect` | gruppo | Sì |
| kafka-cluster:AlterGroup | Concede l'autorizzazione per unire dei gruppi all'interno di un cluster, equivalente all'ACL READ GROUP di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | gruppo | Sì |
| kafka-cluster:DeleteGroup | Concede l'autorizzazione per eliminare gruppi all'interno di un cluster, equivalente all'ACL DELETE GROUP di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | gruppo | Sì |
| kafka-cluster:DescribeTransactionalId | Concede l'autorizzazione a descrivere le transazioni IDs su un cluster, equivalente all'ACL DESCRIBE TRANSACTIONAL\$1ID di Apache Kafka. | `kafka-cluster:Connect` | transactional-id | Sì |
| kafka-cluster:AlterTransactionalId | Concede l'autorizzazione a modificare le transazioni su un cluster, equivalente all'ACL WRITE IDs TRANSACTIONAL\$1ID di Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:WriteData` | transactional-id | Sì |
In un'operazione, dopo i due punti, è possibile utilizzare qualsiasi quantità di caratteri jolly asterisco (\$1). Di seguito vengono mostrati gli esempi.
+ `kafka-cluster:*Topic` sta per `kafka-cluster:CreateTopic`, `kafka-cluster:DescribeTopic`, `kafka-cluster:AlterTopic` e `kafka-cluster:DeleteTopic`. Non include `kafka-cluster:DescribeTopicDynamicConfiguration` o `kafka-cluster:AlterTopicDynamicConfiguration`.
+ `kafka-cluster:*` indica tutte le autorizzazioni.
## Risorse relative alla politica di autorizzazione
La tabella seguente mostra i quattro tipi di risorse che è possibile utilizzare in una policy di autorizzazione quando si utilizza il Controllo degli accessi IAM per Amazon MSK. Puoi ottenere il cluster Amazon Resource Name (ARN) da o utilizzando l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)API Console di gestione AWS o il comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). È quindi possibile utilizzare l'ARN del cluster per creare un argomento, un gruppo e un ID transazionale. ARNs Per specificare una risorsa nella policy di autorizzazione, utilizza l'ARN della risorsa.
| Risorsa | Formato ARN |
| --- | --- |
| Cluster | arn:aws:kafka: :cluster//regionaccount-idcluster-namecluster-uuid |
| Topic | arn:aws:kafka: region ::argomento///account-idcluster-namecluster-uuidtopic-name |
| Gruppo | arn:aws:kafka: region :group///account-idcluster-namecluster-uuidgroup-name |
| ID transazionale | arn:aws:kafka: region ::identificativo-transazione///account-idcluster-namecluster-uuidtransactional-id |
È possibile utilizzare qualsiasi quantità di caratteri jolly asterisco (\$1) in qualsiasi punto dell'ARN successivo a `:cluster/`, `:topic/`, `:group/` e `:transactional-id/`. Di seguito sono riportati alcuni esempi di come utilizzare il carattere jolly asterisco (\$1) per fare riferimento a più risorse:
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/*`: tutti gli argomenti di qualsiasi cluster denominato, indipendentemente dall'UUID del cluster. MyTestCluster
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*_test`: tutti gli argomenti il cui nome termina con «\$1test» nel cluster il cui nome è MyTestCluster e il cui UUID è abcd1234-0123-abcd-5678-1234abcd-1.
+ `arn:aws:kafka:us-east-1:0123456789012:transactional-id/MyTestCluster/*/5555abcd-1111-abcd-1234-abcd1234-1`: tutte le transazioni il cui ID transazionale è MyTestCluster 5555abcd-1111-abcd-1234-abcd1234-1, in tutte le incarnazioni di un cluster denominato nel tuo account. Ciò significa che se si crea un cluster denominato MyTestCluster, quindi lo si elimina e quindi si crea un altro cluster con lo stesso nome, è possibile utilizzare questa risorsa ARN per rappresentare lo stesso ID delle transazioni su entrambi i cluster. Tuttavia, il cluster eliminato non è accessibile.
# Casi d'uso comuni per la politica di autorizzazione dei client
La prima colonna della tabella seguente mostra alcuni casi d'uso comuni. Per autorizzare un client a eseguire un determinato caso d'uso, includi le operazioni richieste per tale caso d'uso nella policy di autorizzazione del client e imposta `Effect` su `Allow`.
Per informazioni su tutte le operazioni che fanno parte del Controllo degli accessi IAM per Amazon MSK, consulta la pagina [Semantica delle azioni e delle risorse della politica di autorizzazione IAM](kafka-actions.md).
**Nota**
Le operazioni non sono consentite per impostazione predefinita. È necessario consentire esplicitamente ogni operazione che si desidera autorizzare il client a eseguire.
****
| Caso d’uso | Operazioni necessarie |
| --- | --- |
| Admin | `kafka-cluster:*` |
| Crea un argomento | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` |
| Produzione di dati | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` |
| Utilizzo di dati | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeGroup` `kafka-cluster:AlterGroup` `kafka-cluster:ReadData` |
| Produzione di dati in modo idempotente | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:WriteDataIdempotently` |
| Produzione di dati in modo transazionale | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:AlterTransactionalId` |
| Descrizione della configurazione di un cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` |
| Aggiornamento della configurazione di un cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` `kafka-cluster:AlterClusterDynamicConfiguration` |
| Descrizione della configurazione di un argomento | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` |
| Aggiornamento della configurazione di un argomento | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` `kafka-cluster:AlterTopicDynamicConfiguration` |
| Modifica di un argomento | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` |
# Autenticazione client TLS reciproca per Amazon MSK
Puoi abilitare l'autenticazione client con TLS per le connessioni dalle tue applicazioni ai broker Amazon MSK. Per utilizzare l'autenticazione client, è necessario un CA privata AWS. CA privata AWS Possono appartenere allo Account AWS stesso cluster o a un account diverso. Per informazioni su CA privata AWS s, vedere [Creazione e gestione di un CA privata AWS](https://docs.aws.amazon.com/acm-pca/latest/userguide/create-CA.html).
Amazon MSK non supporta gli elenchi di revoca dei certificati ()CRLs. Per controllare l'accesso agli argomenti del cluster o bloccare i certificati compromessi, usa Apache ACLs Kafka e i gruppi di sicurezza. AWS Per informazioni sull'uso di Apache Kafka, consulta. ACLs [Apache Kafka ACLs](msk-acls.md)
**Topics**
+ [Crea un cluster Amazon MSK che supporti l'autenticazione dei client](msk-authentication-cluster.md)
+ [Configura un client per utilizzare l'autenticazione](msk-authentication-client.md)
+ [Produci e consuma messaggi utilizzando l'autenticazione](msk-authentication-messages.md)
# Crea un cluster Amazon MSK che supporti l'autenticazione dei client
Questa procedura mostra come abilitare l'autenticazione del client utilizzando un CA privata AWS.
**Nota**
Si consiglia vivamente di utilizzare Independent CA privata AWS per ogni cluster MSK quando si utilizza il TLS reciproco per controllare l'accesso. In questo modo assicurerai che i certificati TLS firmati da si autentichino PCAs solo con un singolo cluster MSK.
1. Crea un file denominato `clientauthinfo.json` con i seguenti contenuti. Sostituisci *Private-CA-ARN* con l'ARN del tuo PCA.
```
{
"Tls": {
"CertificateAuthorityArnList": ["Private-CA-ARN"]
}
}
```
1. Crea un file denominato `brokernodegroupinfo.json` come descritto in [Crea un cluster Amazon MSK di cui è stato effettuato il provisioning utilizzando il AWS CLI](create-cluster-cli.md).
1. L'autenticazione client richiede di abilitare anche la crittografia dei dati in transito tra client e broker. Crea un file denominato `encryptioninfo.json` con i seguenti contenuti. Sostituisci *KMS-Key-ARN* con l'ARN della tua chiave KMS. Puoi impostare `ClientBroker` su `TLS` o `TLS_PLAINTEXT`.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "KMS-Key-ARN"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Per ulteriori informazioni sulla crittografia, consulta [Crittografia di Amazon MSK](msk-encryption.md).
1. Su una macchina su cui è AWS CLI installata, esegui il comando seguente per creare un cluster con l'autenticazione e la crittografia in transito abilitate. Salva l'ARN del cluster fornito nella risposta.
```
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
```
# Configura un client per utilizzare l'autenticazione
Questo processo descrive come configurare un'istanza Amazon EC2 da utilizzare come client per utilizzare l'autenticazione.
Questo processo descrive come produrre e utilizzare messaggi utilizzando l'autenticazione creando una macchina client, creando un argomento e configurando le impostazioni di sicurezza richieste.
1. Crea un'istanza Amazon EC2 da utilizzare come un computer client. Per semplicità, creare questa istanza nello stesso VPC utilizzato per il cluster. Consulta [Passaggio 3: creazione di un computer client](create-client-machine.md) per un esempio di come creare un computer client di questo tipo.
1. Creazione di un argomento. Per un esempio, consulta le istruzioni in [Fase 4: creare un argomento nel cluster Amazon MSK](create-topic.md).
1. Su una macchina su cui è AWS CLI installato, esegui il comando seguente per ottenere i broker bootstrap del cluster. Sostituisci *Cluster-ARN* con l'ARN del tuo cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn Cluster-ARN
```
Salvare la stringa associata a `BootstrapBrokerStringTls` nella risposta.
1. Sul computer client, eseguire il comando seguente per utilizzare il truststore JVM per creare il truststore client. Se il percorso JVM è diverso, modificare il comando di conseguenza.
```
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. Sul computer client, eseguire il comando seguente per creare una chiave privata per il client. Sostituisci *Distinguished-Name**Example-Alias*,*Your-Store-Pass*, e *Your-Key-Pass* con stringhe a tua scelta.
```
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. Sul computer client, eseguire il comando seguente per creare una richiesta di certificato con la chiave privata creata nella fase precedente.
```
keytool -keystore kafka.client.keystore.jks -certreq -file client-cert-sign-request -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Aprire il file `client-cert-sign-request` e accertarsi che inizi con `-----BEGIN CERTIFICATE REQUEST-----` e termini con `-----END CERTIFICATE REQUEST-----`. Se inizia con `-----BEGIN NEW CERTIFICATE REQUEST-----`, eliminare la parola `NEW` (e il singolo spazio che la segue) dall'inizio e dalla fine del file.
1. Su un computer in cui è AWS CLI installato, esegui il comando seguente per firmare la richiesta di certificato. Sostituisci *Private-CA-ARN* con l'ARN del tuo PCA. Se lo si desidera, è possibile modificare il valore di validità. In questo esempio viene utilizzato 300.
```
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"
```
Salvare il certificato ARN fornito nella risposta.
**Nota**
Per recuperare il certificato client, utilizza il comando `acm-pca get-certificate` e specifica l'ARN del certificato. Per ulteriori informazioni, consulta la sezione [get-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm-pca/get-certificate.html) nella *documentazione di riferimento alla AWS CLI *.
1. Esegui il comando seguente per ottenere il certificato CA privata AWS firmato per te. Sostituisci *Certificate-ARN* con l'ARN ottenuto dalla risposta al comando precedente.
```
aws acm-pca get-certificate --certificate-authority-arn Private-CA-ARN --certificate-arn Certificate-ARN
```
1. Dal risultato JSON dell'esecuzione del comando precedente, copiare le stringhe associate a `Certificate` e `CertificateChain`. Incolla queste due stringhe in un nuovo file denominato. signed-certificate-from-acm Incollare innanzitutto la stringa associata a `Certificate`, seguita dalla stringa associata a `CertificateChain`. Sostituire i caratteri `\n` con nuove righe. Di seguito è riportata la struttura del file dopo aver incollato al suo interno il certificato e la catena di certificati.
```
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
1. Eseguire il comando seguente sul computer client per aggiungere questo certificato al keystore in modo da poterlo presentare quando si parla con i broker MSK.
```
keytool -keystore kafka.client.keystore.jks -import -file signed-certificate-from-acm -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Crea un file denominato `client.properties` con i seguenti contenuti. Regolare le posizioni del truststore e del keystore sui percorsi in cui è stato salvato `kafka.client.truststore.jks`. Sostituisci i segnaposto con la versione del tuo client Kafka. *\$1YOUR KAFKA VERSION\$1*
```
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
```
# Produci e consuma messaggi utilizzando l'autenticazione
Questo processo descrive come produrre e utilizzare messaggi utilizzando l'autenticazione.
1. Eseguire il comando seguente per creare un argomento. Il file denominato `client.properties` è quello creato nella procedura precedente.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBroker-String --replication-factor 3 --partitions 1 --topic ExampleTopic --command-config client.properties
```
1. Eseguire il comando seguente per avviare un produttore della console. Il file denominato `client.properties` è quello creato nella procedura precedente.
```
/bin/kafka-console-producer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --producer.config client.properties
```
1. In una nuova finestra di comando sul computer client, eseguire il comando seguente per avviare un consumatore della console.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --consumer.config client.properties
```
1. Digitare i messaggi nella finestra del produttore e guardarli apparire nella finestra del consumatore.
# Autenticazione delle credenziali di accesso con Secrets Manager AWS
Puoi controllare l'accesso ai tuoi cluster Amazon MSK utilizzando credenziali di accesso archiviate e protette tramite Secrets Manager. AWS L'archiviazione delle credenziali utente in Secrets Manager riduce il sovraccarico dell'autenticazione del cluster, ad esempio il controllo, l'aggiornamento e la rotazione delle credenziali. Secrets Manager consente inoltre di condividere le credenziali utente tra i cluster.
Dopo aver associato un segreto a un cluster MSK, MSK sincronizza periodicamente i dati delle credenziali.
**Topics**
+ [Come funziona l'autenticazione delle credenziali di accesso](msk-password-howitworks.md)
+ [Configurare SASL/SCRAM l'autenticazione per un cluster Amazon MSK](msk-password-tutorial.md)
+ [Operazioni con gli utenti](msk-password-users.md)
+ [Limitazioni nell'uso dei segreti SCRAM](msk-password-limitations.md)
# Come funziona l'autenticazione delle credenziali di accesso
L'autenticazione delle credenziali di accesso per Amazon MSK utilizza l'autenticazione SASL/SCRAM (Simple Authentication and Security Layer/ Salted Challenge Response Mechanism). Per configurare l'autenticazione delle credenziali di accesso per un cluster, crea una risorsa segreta in [AWS Secrets Manager](https://docs.aws.amazon.com//secretsmanager/?id=docs_gateway) e associa le credenziali di accesso a quel segreto.
SASL/SCRAM è definito in [RFC 5802](https://tools.ietf.org/html/rfc5802). SCRAM utilizza algoritmi di hashing protetti e non trasmette credenziali di accesso non crittografate tra client e server.
**Nota**
Quando configuri SASL/SCRAM l'autenticazione per il tuo cluster, Amazon MSK attiva la crittografia TLS per tutto il traffico tra clienti e broker.
# Configurare SASL/SCRAM l'autenticazione per un cluster Amazon MSK
Per impostare un segreto in AWS Secrets Manager, segui il tutorial [Creazione e recupero di un segreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) nella Guida per l'[utente di AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
Tieni presente i seguenti requisiti quando crei un segreto per un cluster Amazon MSK:
+ Per il tipo di segreto, scegli **Altro tipo di segreto (es. chiave API)**.
+ Il nome del segreto deve iniziare con il prefisso **AmazonMSK\$1**.
+ È necessario utilizzare una AWS KMS chiave personalizzata esistente o creare una nuova AWS KMS chiave personalizzata per il segreto. Secrets Manager utilizza la AWS KMS chiave predefinita per un segreto per impostazione predefinita.
**Importante**
Un segreto creato con la AWS KMS chiave predefinita non può essere utilizzato con un cluster Amazon MSK.
+ I dati delle credenziali di accesso devono essere nel seguente formato per inserire coppie chiave-valore utilizzando l'opzione **Non crittografato**.
```
{
"username": "alice",
"password": "alice-secret"
}
```
+ Prendi nota del valore del nome della risorsa Amazon (ARN) del segreto.
+
**Importante**
Non è possibile associare un segreto di Secrets Manager a un cluster che supera i limiti descritti in [Dimensioni corrette del cluster: numero di partizioni per broker Standard](bestpractices.md#partitions-per-broker).
+ Se si utilizza il AWS CLI per creare il segreto, specificare un ID chiave o un ARN per il `kms-key-id` parametro. Non specificare un alias.
+ Per associare il segreto al cluster, utilizza la console Amazon MSK o l'[ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)operazione.
**Importante**
Quando associ un segreto a un cluster, Amazon MSK collega al segreto una policy delle risorse che consente al cluster di accedere e leggere i valori del segreto che hai definito. Questa policy delle risorse non dovrebbe essere modificata. In questo modo, è possibile impedire al cluster di accedere al segreto. Se apporti modifiche alla policy delle risorse Secrets e/o alla chiave KMS utilizzata per la crittografia segreta, assicurati di riassociare i segreti al tuo cluster MSK. In questo modo il cluster potrà continuare ad accedere al segreto.
L'esempio seguente di input JSON per l'operazione `BatchAssociateScramSecret` associa un segreto a un cluster:
```
{
"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"
]
}
```
# Connessione al cluster con credenziali di accesso
Dopo aver creato un segreto e averlo collegato al cluster, è possibile collegare il client al cluster. La procedura seguente mostra come connettere un client a un cluster che utilizza SASL/SCRAM l'autenticazione. Viene inoltre illustrato come produrre e consumare partendo da un argomento di esempio.
**Topics**
+ [Connessione di un client al cluster tramite SASL/SCRAM l'autenticazione](#w2aab9c13c29c17c13c11b9b7)
+ [Risoluzione dei problemi di connessione](#msk-password-tutorial-connect-troubleshooting)
## Connessione di un client al cluster tramite SASL/SCRAM l'autenticazione
1. Esegui il comando seguente su un computer che è stato AWS CLI installato. Sostituisci *clusterARN* con l'ARN del tuo cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Dal risultato JSON di questo comando, salva il valore associato alla stringa denominata. `BootstrapBrokerStringSaslScram` Utilizzerai questo valore nei passaggi successivi.
1. Sul tuo computer client, crea un file di configurazione JAAS che contenga le credenziali utente archiviate nel tuo segreto. Ad esempio, per l'utente **alice**, crea un file chiamato `users_jaas.conf` con il seguente contenuto.
```
KafkaClient {
org.apache.kafka.common.security.scram.ScramLoginModule required
username="alice"
password="alice-secret";
};
```
1. Utilizza il seguente comando per esportare il file di configurazione JAAS come parametro di ambiente `KAFKA_OPTS`.
```
export KAFKA_OPTS=-Djava.security.auth.login.config=/users_jaas.conf
```
1. Nella directory `/tmp`, crea un file denominato `kafka.client.truststore.jks`.
1. (Facoltativo) Utilizzate il seguente comando per copiare il file dell'archivio chiavi JDK dalla `cacerts` cartella JVM nel `kafka.client.truststore.jks` file creato nel passaggio precedente. *JDKFolder*Sostituiscilo con il nome della cartella JDK sull'istanza. Ad esempio, la tua cartella JDK potrebbe avere il nome `java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64`.
```
cp /usr/lib/jvm/JDKFolder/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Nella directory `bin` di installazione di Apache Kafka, crea un file delle proprietà del client chiamato `client_sasl.properties` con il seguente contenuto. Questo file definisce il meccanismo e il protocollo SASL.
```
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
```
1. Per creare un argomento di esempio, esegui il comando seguente. Sostituisci *BootstrapBrokerStringSaslScram* con la stringa del broker bootstrap ottenuta nel passaggio 1 di questo argomento.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBrokerStringSaslScram --command-config /client_sasl.properties --replication-factor 3 --partitions 1 --topic ExampleTopicName
```
1. Per produrre l'argomento di esempio che hai creato, esegui il comando seguente sul computer client. Sostituiscila *BootstrapBrokerStringSaslScram* con la stringa del broker bootstrap recuperata nel passaggio 1 di questo argomento.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringSaslScram --topic ExampleTopicName --producer.config client_sasl.properties
```
1. Per utilizzare l'argomento che hai creato, esegui il comando seguente sul tuo computer client. Sostituiscila *BootstrapBrokerStringSaslScram* con la stringa del broker bootstrap ottenuta nel passaggio 1 di questo argomento.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --from-beginning --consumer.config client_sasl.properties
```
## Risoluzione dei problemi di connessione
Quando si eseguono i comandi del client Kafka, è possibile riscontrare errori nella memoria heap di Java, specialmente quando si lavora con argomenti o set di dati di grandi dimensioni. Questi errori si verificano perché gli strumenti Kafka vengono eseguiti come applicazioni Java con impostazioni di memoria predefinite che potrebbero essere insufficienti per il carico di lavoro.
Per risolvere `Out of Memory Java Heap` gli errori, è possibile aumentare la dimensione dell'heap Java modificando la variabile di `KAFKA_OPTS` ambiente per includere le impostazioni di memoria.
L'esempio seguente imposta la dimensione massima dell'heap su 1 GB (). `-Xmx1G` È possibile regolare questo valore in base alla memoria di sistema disponibile e ai requisiti.
```
export KAFKA_OPTS="-Djava.security.auth.login.config=/users_jaas.conf -Xmx1G"
```
Per approfondire argomenti di grandi dimensioni, prendi in considerazione l'utilizzo di parametri basati sul tempo o sull'offset anziché `--from-beginning` limitare l'utilizzo della memoria:
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --max-messages 1000 --consumer.config client_sasl.properties
```
# Operazioni con gli utenti
**Creazione di utenti:** crea utenti nel tuo segreto come coppie chiave-valore. Quando si utilizza l'opzione **Non crittografato** nella console Secrets Manager, è necessario specificare i dati delle credenziali di accesso nel formato seguente.
```
{
"username": "alice",
"password": "alice-secret"
}
```
**Revoca dell'accesso utente:** per revocare le credenziali di accesso a un cluster di un utente, si consiglia di rimuovere o applicare un'ACL al cluster e successivamente annullare l'associazione del segreto. Ciò può essere dovuto ai motivi seguenti:
+ La rimozione di un utente non chiude le connessioni esistenti.
+ La propagazione delle modifiche al segreto richiede fino a 10 minuti.
Per ulteriori informazioni sull'utilizzo delle ACL con Amazon MSK, consulta la pagina [Apache Kafka ACLs](msk-acls.md).
Per i cluster che utilizzano ZooKeeper la modalità, si consiglia di limitare l'accesso ai ZooKeeper nodi per impedire agli utenti di apportare modifiche. ACLs Per ulteriori informazioni, consulta [Controlla l'accesso ai ZooKeeper nodi Apache nel tuo cluster Amazon MSK](zookeeper-security.md).
# Limitazioni nell'uso dei segreti SCRAM
Quando utilizzi i segreti SCRAM, tieni presente le limitazioni seguenti:
+ Amazon MSK supporta solo l'autenticazione SCRAM-SHA-512.
+ Un cluster Amazon MSK può avere fino a 1.000 utenti.
+ Devi usare un AWS KMS key con il tuo segreto. Non è possibile utilizzare un segreto che utilizza la chiave di crittografia Secrets Manager predefinita con Amazon MSK. Per ulteriori informazioni sulla creazione di una chiave KMS, consulta la pagina [Creating symmetric encryption KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk).
+ Non è possibile utilizzare una chiave KMS asimmetrica con Secrets Manager.
+ È possibile associare fino a 10 segreti a un cluster alla volta utilizzando l'[ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)operazione.
+ Il nome dei segreti associati a un cluster Amazon MSK deve avere il prefisso **AmazonMSK\$1.**
+ I segreti associati a un cluster Amazon MSK devono trovarsi nello stesso account e nella stessa AWS regione Amazon Web Services del cluster.
# Apache Kafka ACLs
Apache Kafka dispone di un autorizzatore collegabile e viene fornito con un'implementazione di autorizzazione. out-of-box Amazon MSK abilita questo provider di autorizzazioni nel file `server.properties` sui broker.
Apache Kafka ACLs ha il formato «Principal P è [Consentita/Negata] Operazione O dall'host H su qualsiasi risorsa R corrispondente a RP». ResourcePattern Se RP non corrisponde a una risorsa specifica R, allora R non ha alcuna risorsa associata ACLs e quindi solo gli utenti privilegiati possono accedere a R. Per modificare questo comportamento di Apache Kafka, impostate la proprietà su true. `allow.everyone.if.no.acl.found` In Amazon MSK è impostata su true per impostazione predefinita. Ciò significa che con i cluster Amazon MSK, se non ACLs imposti esplicitamente una risorsa, tutti i principali possono accedere a tale risorsa. Se abiliti una ACLs risorsa, solo i responsabili autorizzati possono accedervi. Se desideri limitare l'accesso a un argomento e autorizzare un client utilizzando l'autenticazione reciproca TLS, aggiungi ACLs utilizzando la CLI di autorizzazione Apache Kafka. [Per ulteriori informazioni sull'aggiunta, la rimozione e l'elenco, consulta Kafka Authorization Command Line ACLs Interface.](https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorization+Command+Line+Interface)
Poiché Amazon MSK configura i broker come utenti privilegiati, possono accedere a tutti gli argomenti. Questo aiuta i broker a replicare i messaggi dalla partizione primaria indipendentemente dal fatto che la `allow.everyone.if.no.acl.found` proprietà sia definita o meno per la configurazione del cluster.
**Per aggiungere o rimuovere l'accesso in lettura e scrittura a un argomento**
1. Aggiungi i tuoi broker alla tabella ACL per consentire loro di leggere tutti gli argomenti esistenti. ACLs Per concedere ai broker l'accesso in lettura a un argomento, esegui il comando seguente su un computer client in grado di comunicare con il cluster MSK.
Sostituiscila *Distinguished-Name* con il DNS di uno qualsiasi dei broker bootstrap del tuo cluster, quindi sostituisci la stringa prima del primo punto di questo nome distinto con un asterisco (). `*` Ad esempio, se uno dei broker di bootstrap del tuo cluster dispone del DNS`b-6.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`, sostituiscilo nel comando seguente con. *Distinguished-Name* `*.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com` Per informazioni su come ottenere i broker bootstrap, consulta [Ottieni i broker bootstrap per un cluster Amazon MSK](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. Per concedere a un'applicazione client l'accesso in lettura a un argomento, esegui il comando seguente sul computer client. Se utilizzi l'autenticazione TLS reciproca, utilizza la stessa *Distinguished-Name* che hai usato quando hai creato la chiave privata.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
Per rimuovere l'accesso in lettura, è possibile eseguire lo stesso comando, sostituendo `--add` con `--remove`.
1. Per concedere l'accesso in scrittura a un argomento, eseguire il comando seguente sul computer client. Se utilizzi l'autenticazione TLS reciproca, utilizza la stessa *Distinguished-Name* che hai usato per creare la chiave privata.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Write --topic Topic-Name
```
Per rimuovere l'accesso in scrittura, è possibile eseguire lo stesso comando, sostituendo `--add` con `--remove`.
# Modifica del gruppo di sicurezza di un cluster Amazon MSK
Questa pagina spiega come modificare il gruppo di sicurezza di un cluster MSK esistente. Potrebbe essere necessario modificare il gruppo di sicurezza di un cluster per fornire l'accesso a un determinato gruppo di utenti o per limitare l'accesso al cluster. Per ulteriori informazioni sui gruppi di sicurezza, consulta la pagina [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella Guida per l'utente di Amazon VPC.
1. Usa l'[ListNodes](https://docs.amazonaws.cn/en_us/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes)API o il comando [list-nodes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/list-nodes.html) in AWS CLI per ottenere un elenco dei broker del tuo cluster. I risultati di questa operazione includono le interfacce IDs di rete elastiche (ENIs) associate ai broker.
1. Accedi Console di gestione AWS e apri la console Amazon EC2 all'indirizzo. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Utilizzando l'elenco a discesa nell'angolo in alto a destra della schermata, seleziona la regione in cui è implementato il cluster.
1. Nel riquadro a sinistra, in **Rete e sicurezza**, scegli **Interfacce di rete**.
1. Seleziona il primo ENI che hai ottenuto nel primo passaggio. Scegli il menu **Operazioni** nella parte superiore dello schermo, quindi scegli **Modifica gruppi di sicurezza**. Assegna il nuovo gruppo di sicurezza a questo ENI. Ripeti questo passaggio per ognuno dei ENIs passaggi ottenuti nel primo passaggio.
**Nota**
Le modifiche apportate al gruppo di sicurezza di un cluster utilizzando la console Amazon EC2 non si riflettono nelle **Impostazioni di rete** della console MSK.
1. Configura le regole del nuovo gruppo di sicurezza per garantire che i tuoi client abbiano accesso ai broker. Per informazioni sull'impostazione delle regole del gruppi di sicurezza, consulta la pagina [Adding, Removing, and Updating Rules](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) nella guida per l'utente di Amazon VPC.
**Importante**
Se modifichi il gruppo di sicurezza associato ai broker di un cluster e poi aggiungi nuovi broker a tale cluster, Amazon MSK associa i nuovi broker al gruppo di sicurezza originale associato al cluster al momento della creazione dello stesso. Tuttavia, affinché un cluster funzioni correttamente, tutti i relativi broker devono essere associati allo stesso gruppo di sicurezza. Pertanto, se si aggiungono nuovi broker dopo aver modificato il gruppo di sicurezza, è necessario seguire nuovamente la procedura precedente e aggiornare i ENIs nuovi broker.
# Controlla l'accesso ai ZooKeeper nodi Apache nel tuo cluster Amazon MSK
Per motivi di sicurezza, puoi limitare l'accesso ai ZooKeeper nodi Apache che fanno parte del tuo cluster Amazon MSK. Per limitare l'accesso ai nodi, puoi assegnare loro un gruppo di sicurezza separato. Puoi quindi stabilire chi ottiene l'accesso a tale gruppo di sicurezza.
**Importante**
Questa sezione non si applica ai cluster in esecuzione in modalità. KRaft Per informazioni, consulta [KRaft modalità](metadata-management.md#kraft-intro).
**Topics**
+ [Per collocare i ZooKeeper nodi Apache in un gruppo di sicurezza separato](zookeeper-security-group.md)
+ [Utilizzo della sicurezza TLS con Apache ZooKeeper](zookeeper-security-tls.md)
# Per collocare i ZooKeeper nodi Apache in un gruppo di sicurezza separato
Per limitare l'accesso ai ZooKeeper nodi Apache, puoi assegnare loro un gruppo di sicurezza separato. Puoi scegliere chi ha accesso a questo nuovo gruppo di sicurezza impostando le regole del gruppo di sicurezza.
1. Ottieni la stringa di ZooKeeper connessione Apache per il tuo cluster. Per scoprire come, consulta [ZooKeeper modalità](metadata-management.md#msk-get-connection-string). La stringa di connessione contiene i nomi DNS dei tuoi nodi ZooKeeper Apache.
1. Utilizzare uno strumento simile a `host` o `ping` per convertire i nomi DNS ottenuti nel passaggio precedente in indirizzi IP. Salvare questi indirizzi IP perché saranno necessari più avanti in questa procedura.
1. Accedi Console di gestione AWS e apri la console Amazon EC2 all'indirizzo. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Nel riquadro di navigazione, in **NETWORK & SECURITY (Rete e sicurezza)**, scegliere **Network Interfaces (Interfacce di rete)**.
1. Nel campo di ricerca sopra la tabella delle interfacce di rete, digitare il nome del cluster, quindi premere Invio. Questo limita il numero di interfacce di rete visualizzate nella tabella a quelle associate al cluster.
1. Selezionare la casella di controllo all'inizio della riga corrispondente alla prima interfaccia di rete nell'elenco.
1. Nel riquadro dei dettagli in fondo alla pagina, cerca l'** IPv4 IP privato primario**. Se questo indirizzo IP corrisponde a uno degli indirizzi IP ottenuti nel primo passaggio di questa procedura, significa che questa interfaccia di rete è assegnata a un ZooKeeper nodo Apache che fa parte del cluster. In caso contrario, deselezionare la casella di controllo accanto a questa interfaccia di rete e selezionare l'interfaccia di rete successiva nell'elenco. L'ordine di selezione delle interfacce di rete non ha importanza. Nei passaggi successivi, eseguirai le stesse operazioni su tutte le interfacce di rete assegnate ai ZooKeeper nodi Apache, una per una.
1. Quando selezioni un'interfaccia di rete che corrisponde a un ZooKeeper nodo Apache, scegli il menu **Azioni** nella parte superiore della pagina, quindi scegli **Cambia** gruppi di sicurezza. Assegnare un nuovo gruppo di sicurezza a questa interfaccia di rete. Per ulteriori informazioni sulla creazione dei gruppi di sicurezza, consulta la pagina [Creating a Security Group](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#CreatingSecurityGroups) nella documentazione di Amazon VPC.
1. Ripeti il passaggio precedente per assegnare lo stesso nuovo gruppo di sicurezza a tutte le interfacce di rete associate ai ZooKeeper nodi Apache del cluster.
1. È ora possibile scegliere chi dispone dell'accesso a questo nuovo gruppo di sicurezza. Per informazioni sull'impostazione delle regole dei gruppi di sicurezza, consulta la pagina [Adding, Removing, and Updating Rules](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) nella documentazione di Amazon VPC.
# Utilizzo della sicurezza TLS con Apache ZooKeeper
Puoi utilizzare la sicurezza TLS per la crittografia in transito tra i tuoi client e i tuoi nodi Apache. ZooKeeper Per implementare la sicurezza TLS con i tuoi ZooKeeper nodi Apache, procedi come segue:
+ I cluster devono utilizzare Apache Kafka versione 2.5.1 o successiva per utilizzare la sicurezza TLS con Apache. ZooKeeper
+ Abilita la sicurezza TLS quando crei o configuri il cluster. I cluster creati con Apache Kafka versione 2.5.1 o successiva con TLS abilitato utilizzano automaticamente la sicurezza TLS con gli endpoint Apache. ZooKeeper Per informazioni sulla configurazione della sicurezza TLS, consulta la pagina [Inizia a usare la crittografia Amazon MSK](msk-working-with-encryption.md).
+ Recupera gli endpoint TLS Apache utilizzando l'operazione. ZooKeeper [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
+ Crea un file di ZooKeeper configurazione Apache da utilizzare con [https://kafka.apache.org/documentation/#security_authz_cli](https://kafka.apache.org/documentation/#security_authz_cli)gli strumenti `kafka-configs.sh` and o con la shell. ZooKeeper Con ogni strumento, si utilizza il `--zk-tls-config-file` parametro per specificare la configurazione di Apache ZooKeeper .
L'esempio seguente mostra un tipico file di configurazione di Apache ZooKeeper :
```
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
```
+ Per altri comandi (come`kafka-topics`), è necessario utilizzare la variabile di `KAFKA_OPTS` ambiente per configurare i parametri di Apache ZooKeeper. L'esempio seguente mostra come configurare la variabile di `KAFKA_OPTS` ambiente per passare i ZooKeeper parametri Apache ad altri comandi:
```
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"
```
Dopo aver configurato la variabile di ambiente `KAFKA_OPTS`, è possibile utilizzare normalmente i comandi della CLI. L'esempio seguente crea un argomento di Apache Kafka utilizzando la ZooKeeper configurazione di Apache dalla variabile di ambiente: `KAFKA_OPTS`
```
/bin/kafka-topics.sh --create --zookeeper ZooKeeperTLSConnectString --replication-factor 3 --partitions 1 --topic AWSKafkaTutorialTopic
```
**Nota**
I nomi dei parametri utilizzati nel file di ZooKeeper configurazione di Apache e quelli utilizzati nella variabile di `KAFKA_OPTS` ambiente non sono coerenti. Presta attenzione ai nomi che usi con ciascun parametri nel file di configurazione e nella variabile di ambiente `KAFKA_OPTS`.
Per ulteriori informazioni sull'accesso ai ZooKeeper nodi Apache con TLS, vedi [KIP-515: Abilita il client ZK a usare la nuova autenticazione supportata da](https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+ZK+client+to+use+the+new+TLS+supported+authentication) TLS.
# Convalida della conformità per Streaming gestito da Amazon per Apache Kafka
Revisori di terze parti valutano la sicurezza e la conformità di Streaming gestito da Amazon per Apache Kafka nell'ambito dei programmi di conformità di AWS . Questi includono PCI e HIPAA BAA.
Per un elenco di AWS servizi nell'ambito di programmi di conformità specifici, consulta [Amazon Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) . Per informazioni generali, consulta Programmi di [AWS conformità Programmi](https://aws.amazon.com/compliance/programs/) di di .
È possibile scaricare report di audit di terze parti utilizzando AWS Artifact. Per ulteriori informazioni, consulta [Scaricamento dei report in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
La tua responsabilità di conformità quando usi Amazon MSK è determinata dalla sensibilità dei tuoi dati, dagli obiettivi di conformità della tua azienda e dalle leggi e dai regolamenti applicabili. AWS fornisce le seguenti risorse per contribuire alla conformità:
+ [Le guide rapide per la sicurezza e la conformità](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance): queste guide all'implementazione illustrano considerazioni architettoniche e forniscono i passaggi per l'implementazione di ambienti di base incentrati sulla sicurezza e sulla conformità su AWS.
+ [Whitepaper sull'architettura per la sicurezza e la conformità HIPAA: questo white paper](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) descrive come le aziende possono utilizzare per creare applicazioni conformi allo standard HIPAA. AWS
+ AWS Risorse per [la conformità Risorse per la conformità](https://aws.amazon.com/compliance/resources/): questa raccolta di potrebbe riguardare il settore e la località in cui operate.
+ [Valutazione delle risorse con le regole](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) nella *Guida per gli AWS Config sviluppatori*: il AWS Config servizio valuta la conformità delle configurazioni delle risorse alle pratiche interne, alle linee guida del settore e alle normative.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Questo AWS servizio offre una visione completa dello stato di sicurezza dell'utente, AWS che consente di verificare la conformità agli standard e alle best practice del settore della sicurezza.
# Resilienza in Streaming gestito da Amazon per Apache Kafka
L'infrastruttura AWS globale è costruita attorno a regioni e zone di disponibilità. AWS AWS Le regioni forniscono più zone di disponibilità fisicamente separate e isolate, collegate con reti a bassa latenza, ad alto throughput e altamente ridondanti. Con le zone di disponibilità è possibile progettare e gestire applicazioni e database che eseguono automaticamente il failover tra zone di disponibilità senza interruzioni. Le zone di disponibilità sono più disponibili, tolleranti ai guasti e scalabili rispetto alle infrastrutture a data center singolo o multiplo tradizionali.
[Per ulteriori informazioni su AWS regioni e zone di disponibilità, consulta Global Infrastructure.AWS](https://aws.amazon.com/about-aws/global-infrastructure/)
# Sicurezza dell'infrastruttura in Streaming gestito da Amazon per Apache Kafka
In quanto servizio gestito, Amazon Managed Streaming for Apache Kafka è protetto AWS dalle procedure di sicurezza di rete globali descritte nel white paper di [Amazon Web Services:](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) Overview of Security Processes.
Utilizzi chiamate API AWS pubblicate per accedere ad Amazon MSK attraverso la rete. I client devono supportare Transport Layer Security (TLS) 1.0 o versioni successive. È consigliabile TLS 1.2 o versioni successive. I client devono, inoltre, supportare le suite di cifratura con PFS (Perfect Forward Secrecy), ad esempio Ephemeral Diffie-Hellman (DHE) o Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). La maggior parte dei sistemi moderni, come Java 7 e versioni successive, supporta tali modalità.
Inoltre, le richieste devono essere firmate utilizzando un ID chiave di accesso e una chiave di accesso segreta associata a un principale IAM. In alternativa è possibile utilizzare [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) per generare credenziali di sicurezza temporanee per sottoscrivere le richieste.
# Registrazione Amazon MSK
Puoi inviare i log del broker Apache Kafka a uno o più dei seguenti tipi di destinazione: Amazon Logs, Amazon S3 CloudWatch , Amazon Data Firehose. Puoi anche registrare le chiamate API Amazon MSK con AWS CloudTrail.
**Nota**
I log dei broker sono disponibili sia sui broker MSK Standard che Express.
## Log di broker
I log di broker consentono di risolvere i problemi delle applicazioni Apache Kafka e di analizzare le comunicazioni con il cluster MSK. È possibile configurare il cluster MSK nuovo o esistente per fornire i log dei broker a livello Info a uno o più dei seguenti tipi di risorse di destinazione: un gruppo di CloudWatch log, un bucket S3, un flusso di distribuzione Firehose. Tramite Firehose è quindi possibile inviare i dati di registro dal flusso di distribuzione a OpenSearch Service.
È necessario creare una risorsa di destinazione prima di configurare il cluster per consegnargli i log del broker. Amazon MSK non crea queste risorse di destinazione se non esistono già. Per informazioni su questi tre tipi di risorse di destinazione e su come crearle, consultare la documentazione seguente:
+ [ CloudWatch Registri Amazon](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)
### Autorizzazioni richieste
Per configurare una destinazione per i log del broker Amazon MSK, l'identità IAM che utilizzi per le operazioni Amazon MSK deve disporre delle autorizzazioni descritte nella policy [AWS politica gestita: Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md).
Per eseguire lo streaming dei log di broker a un bucket S3, è richiesta anche l'autorizzazione `s3:PutBucketPolicy`. Per informazioni sulle policy dei bucket S3, consulta la pagina [How Do I Add an S3 Bucket Policy?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html) nella Guida per l'utente di Amazon S3. Per informazioni sulle policy IAM in generale, consulta la pagina [Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) nella Guida per l'utente di IAM.
### Policy della chiave KMS necessaria per l'utilizzo con i bucket SSE-KMS
Se hai abilitato la crittografia lato server per il tuo bucket S3 utilizzando chiavi AWS KMS gestite (SSE-KMS) con una chiave gestita dal cliente, aggiungi quanto segue alla policy chiave per la tua chiave KMS in modo che Amazon MSK possa scrivere i file del broker nel bucket.
```
{
"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": "*"
}
```
### Configura i log del broker utilizzando Console di gestione AWS
Se stai creando un nuovo cluster, cerca l'intestazione **Broker log delivery (Recapito del log del broker)** nella sezione **Monitoring (Monitoraggio)** . Puoi specificare le destinazioni a cui Amazon MSK deve consegnare i log del broker.
Per un cluster esistente, scegli il cluster dall'elenco di cluster, quindi seleziona la scheda **Proprietà**. Scorri verso il basso fino alla sezione **Consegna dei log** e scegli il relativo pulsante **Modifica**. Puoi specificare le destinazioni a cui Amazon MSK deve consegnare i log del broker.
### Configurare i log del broker utilizzando il AWS CLI
Quando utilizzi i comandi `create-cluster` o `update-monitoring`, puoi specificare facoltativamente il parametro `logging-info` e passarlo a una struttura JSON come nell'esempio seguente. In questo JSON, tutti e tre i tipi di destinazione sono facoltativi.
**Nota**
È necessario impostare il `LogDeliveryEnabled` tag `true` su Firehose Streams per configurare la consegna dei log. Il ruolo collegato al servizio che AWS crea per CloudWatch i log utilizza questo tag per concedere l'autorizzazione per tutti i flussi di distribuzione Firehose. Se rimuovi questo tag, il ruolo collegato al servizio non sarà in grado di inviare i log allo stream Firehose. *Per vedere un esempio di policy IAM che mostra le autorizzazioni incluse nel ruolo collegato al servizio, consulta i [ruoli IAM usati per le autorizzazioni delle risorse nella](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html) Amazon User Guide. CloudWatch *
```
{
"BrokerLogs": {
"S3": {
"Bucket": "amzn-s3-demo-bucket",
"Prefix": "ExamplePrefix",
"Enabled": true
},
"Firehose": {
"DeliveryStream": "ExampleDeliveryStreamName",
"Enabled": true
},
"CloudWatchLogs": {
"Enabled": true,
"LogGroup": "ExampleLogGroupName"
}
}
}
```
### Configura i log del broker utilizzando l'API
È possibile specificare la `loggingInfo` struttura opzionale nel file JSON che si passa alle operazioni [CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)or [UpdateMonitoring](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-monitoring.html#UpdateMonitoring).
**Nota**
Per impostazione predefinita, quando la registrazione del broker è abilitata, Amazon MSK registra i log di livello `INFO` nelle destinazioni specificate. [Tuttavia, per i broker Standard, gli utenti di Apache Kafka 2.4.X e versioni successive possono impostare dinamicamente il livello di log del broker su uno qualsiasi dei livelli di log log4j.](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html) Per informazioni sull'impostazione dinamica del livello di log del broker, consulta la pagina [KIP-412: Extend Admin API to support dynamic application log levels](https://cwiki.apache.org/confluence/display/KAFKA/KIP-412%3A+Extend+Admin+API+to+support+dynamic+application+log+levels). Se imposti dinamicamente il livello di registro su `DEBUG` o`TRACE`, ti consigliamo di utilizzare Amazon S3 o Firehose come destinazione del registro. Se utilizzi CloudWatch Logs come destinazione di log e abiliti `DEBUG` o `TRACE` livelli dinamicamente la registrazione, Amazon MSK può fornire continuamente un campione di log. Ciò può influire in modo significativo sulle prestazioni del broker e deve essere utilizzato solo quando il livello di log `INFO` non è sufficientemente dettagliato da consentire di determinare la causa principale di un problema.
# Registra le chiamate API con AWS CloudTrail
**Nota**
AWS CloudTrail i log sono disponibili per Amazon MSK solo quando li usi. [Controllo degli accessi IAM](iam-access-control.md)
Amazon MSK è integrato con AWS CloudTrail, un servizio che fornisce un registro delle azioni intraprese da un utente, un ruolo o un AWS servizio in Amazon MSK. CloudTrail acquisisce le chiamate API come eventi. Le chiamate acquisite includono le chiamate dalla console Amazon MSK e le chiamate di codice alle operazioni API di Amazon MSK. Registra anche le operazioni di Apache Kafka come la creazione e la modifica di argomenti e gruppi.
Se crei un trail, puoi abilitare la distribuzione continua di CloudTrail eventi a un bucket Amazon S3, inclusi gli eventi per Amazon MSK. **Se non configuri un percorso, puoi comunque visualizzare gli eventi più recenti nella CloudTrail console nella cronologia degli eventi.** Utilizzando le informazioni raccolte da CloudTrail, puoi determinare la richiesta effettuata ad Amazon MSK o l'azione Apache Kafka, l'indirizzo IP da cui è stata effettuata la richiesta, chi ha effettuato la richiesta, quando è stata effettuata e dettagli aggiuntivi.
[Per ulteriori informazioni CloudTrail, incluso come configurarlo e abilitarlo, consulta la Guida per l'utente.AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)
## Informazioni su Amazon MSK in CloudTrail
CloudTrail è abilitato sul tuo account Amazon Web Services al momento della creazione dell'account. Quando si verifica un'attività di evento supportata in un cluster MSK, tale attività viene registrata in un CloudTrail evento insieme ad altri eventi di AWS servizio nella **cronologia** degli eventi. Puoi visualizzare, cercare e scaricare gli eventi recenti nell'account Amazon Web Services. Per ulteriori informazioni, consulta [Visualizzazione di eventi mediante la cronologia eventi di CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Per una registrazione continua degli eventi nell'account Amazon Web Services che includa gli eventi per Amazon MSK, crea un percorso. Un *trail* consente di CloudTrail inviare file di log a un bucket Amazon S3. Per impostazione predefinita, quando si crea un trail nella console, il trail sarà valido in tutte le Regioni . Il trail registra gli eventi di tutte le Regioni nella partizione AWS e distribuisce i file di log nel bucket Amazon S3 specificato. Inoltre, puoi configurare altri servizi Amazon per analizzare ulteriormente e agire in base ai dati sugli eventi raccolti nei CloudTrail log. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [Panoramica della creazione di un trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Servizi e integrazioni supportati](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configurazione delle notifiche Amazon SNS per CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Ricezione di file di CloudTrail registro da più regioni](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) e [ricezione di file di CloudTrail registro da](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html) più account
Amazon MSK registra tutte le [operazioni di Amazon MSK](https://docs.aws.amazon.com/MSK/2.0/APIReference/operations.html) come eventi nei CloudTrail file di registro. Inoltre, registra le seguenti operazioni di Apache Kafka.
+ cluster kafka: DescribeClusterDynamicConfiguration
+ ammasso kafka: AlterClusterDynamicConfiguration
+ ammasso kafka: CreateTopic
+ ammasso kafka: DescribeTopicDynamicConfiguration
+ ammasso kafka: AlterTopic
+ ammasso kafka: AlterTopicDynamicConfiguration
+ ammasso kafka: DeleteTopic
Ogni evento o voce di log contiene informazioni sull’utente che ha generato la richiesta. Le informazioni di identità consentono di determinare quanto segue:
+ Se la richiesta è stata effettuata con credenziali utente root o utente AWS Identity and Access Management (IAM).
+ Se la richiesta è stata effettuata con le credenziali di sicurezza temporanee per un ruolo o un utente federato.
+ Se la richiesta è stata effettuata da un altro AWS servizio.
Per ulteriori informazioni, consulta [Elemento CloudTrail userIdentity](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Esempio: voci del file di log di Amazon MSK
Un trail è una configurazione che consente la distribuzione di eventi come file di log in un bucket Amazon S3 specificato dall'utente. CloudTrail i file di registro contengono una o più voci di registro. Un evento rappresenta una singola richiesta proveniente da qualsiasi fonte e include informazioni sull'azione richiesta, la data e l'ora dell'azione, i parametri della richiesta e così via. CloudTrail i file di registro non sono una traccia stack ordinata delle chiamate API pubbliche e delle azioni di Apache Kafka, quindi non vengono visualizzati in un ordine specifico.
L'esempio seguente mostra le voci di CloudTrail registro che illustrano le azioni `DescribeCluster` e `DeleteCluster` Amazon MSK.
```
{
"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"
}
]
}
```
L'esempio seguente mostra una voce di CloudTrail registro che illustra l'`kafka-cluster:CreateTopic`azione.
```
{
"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"
}
```
# Gestione dei metadati
Amazon MSK supporta Apache ZooKeeper o le modalità di gestione KRaft dei metadati.
Dalla versione 3.7.x di Apache Kafka su Amazon MSK, puoi creare cluster che utilizzano la modalità anziché la modalità. KRaft ZooKeeper KRafti cluster basati su controller all'interno di Kafka per gestire i metadati.
**Topics**
+ [ZooKeeper modalità](#msk-get-connection-string)
+ [KRaft modalità](#kraft-intro)
## ZooKeeper modalità
[Apache ZooKeeper](https://zookeeper.apache.org/) è «un servizio centralizzato per la gestione delle informazioni di configurazione, la denominazione, la sincronizzazione distribuita e la fornitura di servizi di gruppo. Tutti questi tipi di servizi vengono utilizzati in una forma o nell'altra da applicazioni distribuite», incluso Apache Kafka.
Se il tuo cluster utilizza la ZooKeeper modalità, puoi utilizzare i passaggi seguenti per ottenere la stringa di connessione ZooKeeper Apache. Tuttavia, ti consigliamo di utilizzare il `BootstrapServerString` per connetterti al tuo cluster ed eseguire operazioni di amministrazione poiché il `--zookeeper` flag è stato reso obsoleto in Kafka 2.5 ed è stato rimosso da Kafka 3.0.
### ZooKeeper Ottenere la stringa di connessione di Apache utilizzando il Console di gestione AWS
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. La tabella mostra tutti i cluster per la regione corrente in questo account. Scegli il nome di un cluster per visualizzarne la descrizione.
1. Nella pagina **Riepilogo del cluster**, scegli **Visualizza informazioni sul client**. Questo mostra i broker bootstrap e la stringa di connessione ZooKeeper Apache.
### Ottenere la stringa di connessione Apache usando ZooKeeper il AWS CLI
1. Se l'Amazon Resource Name (ARN) del cluster non è noto, puoi trovarlo elencando tutti i cluster nell'account. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
1. Per ottenere la stringa di ZooKeeper connessione Apache, insieme ad altre informazioni sul cluster, esegui il comando seguente, sostituendolo *ClusterArn* con l'ARN del cluster.
```
aws kafka describe-cluster --cluster-arn ClusterArn
```
L'output di questo comando `describe-cluster` è simile all'esempio JSON seguente.
```
{
"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"
}
}
```
L'esempio JSON precedente mostra la chiave `ZookeeperConnectString` nell'output del comando `describe-cluster`. Copia il valore corrispondente a questa chiave e salvalo per utilizzarlo quando è necessario creare un argomento nel cluster.
**Importante**
Il cluster Amazon MSK deve trovarsi nello `ACTIVE` stato in cui è possibile ottenere la stringa di ZooKeeper connessione Apache. Quando un cluster è ancora nello stato `CREATING`, l'output del comando `describe-cluster` non include `ZookeeperConnectString`. In questo caso, occorre attendere alcuni minuti ed eseguire nuovamente `describe-cluster` dopo che il cluster raggiunge lo stato `ACTIVE`.
### Ottenere la stringa di ZooKeeper connessione Apache tramite l'API
Per ottenere la stringa di ZooKeeper connessione Apache utilizzando l'API, vedi. [DescribeCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
## KRaft modalità
Amazon MSK ha introdotto il supporto per KRaft (Apache Kafka Raft) nella versione 3.7.x di Kafka. [La community Apache Kafka si è sviluppata KRaft per sostituire Apache per la gestione dei metadati nei cluster Apache Kafka. ZooKeeper](#msk-get-connection-string) In KRaft modalità, i metadati del cluster vengono propagati all'interno di un gruppo di controller Kafka, che fanno parte del cluster Kafka, anziché tra i nodi. ZooKeeper KRafti controller sono inclusi senza costi aggiuntivi per l'utente e non richiedono alcuna configurazione o gestione aggiuntiva da parte dell'utente. Vedi [KIP-500](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum) per ulteriori informazioni su. KRaft
Ecco alcuni punti da tenere in considerazione sulla KRaft modalità su MSK:
+ KRaft la modalità è disponibile solo per i nuovi cluster. Non è possibile cambiare modalità di metadati una volta creato il cluster.
+ Sulla console MSK, è possibile creare un cluster basato su Kraft scegliendo la versione 3.7.x di Kafka e selezionando la casella di controllo nella finestra di creazione del cluster. KRaft
+ Per creare un cluster in KRaft modalità utilizzando l'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)o le operazioni MSK, è necessario utilizzare come versione. [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)`3.7.x.kraft` Utilizza `3.7.x` come versione per creare un cluster in ZooKeeper modalità.
+ Il numero di partizioni per broker è lo stesso su KRaft e per i cluster ZooKeeper basati. Tuttavia, KRaft consente di ospitare più partizioni per cluster fornendo [più broker](https://docs.aws.amazon.com/msk/latest/developerguide/limits.html) in un cluster.
+ Non sono necessarie modifiche all'API per utilizzare la KRaft modalità su Amazon MSK. Tuttavia, se i tuoi client utilizzano ancora la stringa di `--zookeeper` connessione oggi, dovresti aggiornarli in modo che utilizzino la stringa di `--bootstrap-server` connessione per connettersi al cluster. Il `--zookeeper` flag è obsoleto nella versione 2.5 di Apache Kafka e viene rimosso a partire dalla versione 3.0 di Kafka. Ti consigliamo quindi di utilizzare le versioni recenti del client Apache Kafka e la stringa di connessione per tutte le connessioni al tuo cluster. `--bootstrap-server`
+ ZooKeeper la modalità continua a essere disponibile per tutte le versioni rilasciate in cui zookeeper è supportato anche da Apache Kafka. Vedi [Versioni di Apache Kafka supportate](supported-kafka-versions.md) i dettagli sulla fine del supporto per le versioni di Apache Kafka e gli aggiornamenti futuri.
+ È necessario verificare che tutti gli strumenti utilizzati siano in grado di utilizzare Kafka Admin senza connessioni. APIs ZooKeeper Consulta la procedura aggiornata [Usa LinkedIn il Cruise Control per Apache Kafka con Amazon MSK](cruise-control.md) per connettere il cluster a Cruise Control. Cruise Control fornisce anche istruzioni per utilizzare [il Cruise Control senza ZooKeeper](https://github.com/linkedin/cruise-control/wiki/Run-without-ZooKeeper).
+ Non è necessario accedere direttamente ai KRaft controller del cluster per eventuali azioni amministrative. Tuttavia, se si utilizza il monitoraggio aperto per raccogliere le metriche, sono necessari anche gli endpoint DNS dei controller per raccogliere alcune metriche non correlate ai controller sul cluster. È possibile ottenere questi endpoint DNS dalla console MSK o utilizzando l'operazione API. [ListNodes](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes) Vedi [Monitora un cluster MSK Provisioned con Prometheus](open-monitoring.md) i passaggi aggiornati per configurare il monitoraggio aperto per i cluster basati. KRaft
+ Non sono necessarie [CloudWatch metriche](https://docs.aws.amazon.com/msk/latest/developerguide/metrics-details.html) aggiuntive per monitorare i cluster modali rispetto ai cluster KRaft modali. ZooKeeper MSK gestisce i KRaft controller utilizzati nei cluster.
+ È possibile continuare a gestire ACLs utilizzando i cluster in KRaft modalità utilizzando la stringa di connessione. `--bootstrap-server` Non è necessario utilizzare la stringa di `--zookeeper` connessione per gestire ACLs. Per informazioni, consulta [Apache Kafka ACLs](msk-acls.md).
+ In KRaft modalità, i metadati del cluster vengono archiviati su KRaft controller all'interno di Kafka e non su nodi esterni. ZooKeeper Pertanto, non è necessario controllare l'accesso ai nodi del controller separatamente [come si fa](https://docs.aws.amazon.com/msk/latest/developerguide/zookeeper-security.html) con i nodi. ZooKeeper
# Argomento Operazioni
Puoi usare Amazon MSK APIs per gestire argomenti nel tuo cluster MSK Provisioned senza la necessità di configurare e gestire i client di amministrazione Kafka. Con questi APIs, puoi definire o leggere le proprietà degli argomenti come il fattore di replica e il numero di partizioni, oltre a impostazioni di configurazione come le politiche di conservazione e pulizia. Puoi gestire in modo programmatico gli argomenti di Kafka utilizzando le tue interfacce familiari, tra cui AWS CLI e. AWS SDKs AWS CloudFormation Questi APIs sono inoltre integrati nella console Amazon MSK, riunendo tutte le operazioni tematiche in un unico posto. Ora puoi creare o aggiornare argomenti con pochi clic utilizzando impostazioni predefinite guidate, ottenendo al contempo una visibilità completa sulle configurazioni degli argomenti, sulle informazioni a livello di partizione e sulle metriche.
**Importante**
Le risposte API di questi argomenti riflettono i dati che si aggiornano all'incirca ogni minuto. Per conoscere lo stato più recente dell'argomento dopo aver apportato le modifiche, attendi circa un minuto prima di eseguire l'interrogazione.
## Requisiti per l'utilizzo dell'argomento APIs
+ Il cluster deve essere un cluster MSK Provisioned. Questi non APIs sono disponibili per i cluster MSK Serverless.
+ Il cluster deve eseguire Apache Kafka versione 3.6.0 o successiva. Per ulteriori informazioni sulle versioni supportate, consulta. [Versioni di Apache Kafka supportate](supported-kafka-versions.md)
+ Il cluster deve trovarsi nello `ACTIVE` stato. Per ulteriori informazioni sugli stati del cluster, consulta [Comprendi gli stati del cluster MSK Provisioned](msk-cluster-states.md).
+ È necessario disporre delle autorizzazioni IAM appropriate. Per ulteriori informazioni, consulta [Autorizzazioni IAM per le operazioni tematiche APIs](#topic-operations-permissions).
## Autorizzazioni IAM per le operazioni tematiche APIs
Per chiamarle APIs, devi disporre delle autorizzazioni IAM appropriate. La tabella seguente elenca le autorizzazioni richieste per ogni API.
**Autorizzazioni richieste per le operazioni sugli argomenti APIs**
| "Hello, World\$1" | Autorizzazioni richieste | Risorsa |
| --- | --- | --- |
| ListTopics | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | ARN del cluster, Argomento ARN |
| DescribeTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | ARN del cluster, Argomento ARN |
| DescribeTopicPartitions | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | ARN del cluster, Argomento ARN |
| CreateTopic | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` | ARN del cluster, Argomento ARN |
| DeleteTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DeleteTopic` | ARN del cluster, Argomento ARN |
| UpdateTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` `kafka-cluster:AlterTopicDynamicConfiguration` | ARN del cluster, Argomento ARN |
**Nota**
Per`kafka-cluster:Connect`, specifica l'ARN del cluster nella tua policy IAM. Per tutte le altre azioni, specifica l'argomento ARN nella tua policy IAM.
**Nota**
Infatti`ListTopics`, puoi usare un carattere jolly (\$1) per abbinare tutti gli argomenti di un cluster. Ad esempio: `arn:aws:kafka:us-east-1:123456789012:topic/my-cluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/*`.
Per ulteriori informazioni sul controllo degli accessi IAM per Amazon MSK, consulta[Controllo degli accessi IAM](iam-access-control.md).
**Topics**
+ [Requisiti per l'utilizzo dell'argomento APIs](#topic-operations-requirements)
+ [Autorizzazioni IAM per le operazioni tematiche APIs](#topic-operations-permissions)
+ [Elenca gli argomenti in un cluster Amazon MSK](msk-list-topics.md)
+ [Ottieni informazioni dettagliate su un argomento](msk-describe-topic.md)
+ [Visualizzare le informazioni sulla partizione per un argomento](msk-describe-topic-partitions.md)
+ [Crea argomenti in un cluster Amazon MSK](msk-create-topic.md)
+ [Aggiornare un argomento in un cluster Amazon MSK](msk-update-topic.md)
+ [Eliminare un argomento in un cluster Amazon MSK](msk-delete-topic.md)
# Elenca gli argomenti in un cluster Amazon MSK
È possibile elencare tutti gli argomenti del cluster MSK Provisioned per visualizzare i metadati di base come il numero di partizioni e i fattori di replica. Ciò è utile per monitorare gli argomenti del cluster, eseguire controlli di inventario o identificare argomenti per ulteriori approfondimenti.
**Nota**
L'`ListTopics`API fornisce metadati tematici di base. Per ottenere informazioni dettagliate su un argomento specifico, inclusi lo stato e la configurazione correnti, utilizza l'`DescribeTopic`API. Per ulteriori informazioni, consulta [Ottieni informazioni dettagliate su un argomento](msk-describe-topic.md).
**Nota**
Questa risposta API riflette i dati che si aggiornano all'incirca ogni minuto. Per conoscere lo stato più recente dell'argomento dopo aver apportato le modifiche, attendi circa un minuto prima di eseguire la query.
**Topics**
+ [Elenca gli argomenti utilizzando il Console di gestione AWS](list-topics-console.md)
+ [Elenca gli argomenti utilizzando il AWS CLI](list-topics-cli.md)
+ [Elenca gli argomenti utilizzando l'API](list-topics-api.md)
# Elenca gli argomenti utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster per il quale desideri elencare gli argomenti.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. La tabella mostra tutti gli argomenti del cluster, inclusi il nome dell'argomento, il numero di partizioni, il fattore di replica e il numero di out-of-sync repliche.
# Elenca gli argomenti utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
```
aws kafka list-topics --cluster-arn ClusterArn
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"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
}
]
}
```
## Impaginazione dei risultati
Se il tuo cluster ha molti argomenti, puoi utilizzare l'impaginazione per recuperare i risultati in batch più piccoli. Utilizzate il `--max-results` parametro per specificare il numero massimo di argomenti da restituire e utilizzate il `--next-token` parametro per recuperare la pagina successiva di risultati.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10
```
Se sono disponibili più risultati, la risposta include un `nextToken` valore. Usa questo token per recuperare la pagina successiva di risultati.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10 --next-token NextToken
```
## Filtrare gli argomenti per nome
È possibile filtrare l'elenco degli argomenti specificando un prefisso utilizzando il parametro. `--topic-name-filter` Ciò restituisce solo gli argomenti i cui nomi iniziano con il prefisso specificato.
```
aws kafka list-topics --cluster-arn ClusterArn --topic-name-filter "prod-"
```
Questo comando restituisce solo gli argomenti i cui nomi iniziano con`prod-`, ad esempio `prod-orders` o`prod-inventory`.
# Elenca gli argomenti utilizzando l'API
Per elencare gli argomenti che utilizzano l'API, consulta [ListTopics](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#ListTopics).
# Ottieni informazioni dettagliate su un argomento
È possibile recuperare informazioni dettagliate su un argomento specifico nel cluster MSK Provisioned, tra cui lo stato corrente, il numero di partizioni, il fattore di replica e la configurazione. Ciò è utile per la risoluzione dei problemi, la convalida delle impostazioni degli argomenti o il monitoraggio dello stato degli argomenti durante le operazioni.
**Nota**
Questa risposta API riflette i dati che si aggiornano all'incirca ogni minuto. Per conoscere lo stato più recente dell'argomento dopo aver apportato le modifiche, attendi circa un minuto prima di eseguire la query.
**Topics**
+ [Descrivi un argomento utilizzando il Console di gestione AWS](describe-topic-console.md)
+ [Descrivere un argomento utilizzando il AWS CLI](describe-topic-cli.md)
+ [Descrivi un argomento utilizzando l'API](describe-topic-api.md)
# Descrivi un argomento utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster che contiene l'argomento che desideri descrivere.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. Nell'elenco degli argomenti, scegli il nome dell'argomento che desideri visualizzare.
1. La pagina dei dettagli dell'argomento mostra informazioni sull'argomento, tra cui lo stato, il numero di partizioni, il fattore di replica e le impostazioni di configurazione.
# Descrivere un argomento utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster e *TopicName* con il nome dell'argomento che desideri descrivere.
```
aws kafka describe-topic --cluster-arn ClusterArn --topic-name TopicName
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"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"
}
```
## Comprendere lo stato dell'argomento
Il `status` campo indica lo stato attuale dell'argomento. La tabella seguente descrive i possibili valori di stato.
**Valori di stato dell'argomento**
| Status | Description |
| --- | --- |
| CREAZIONE IN CORSO | L'argomento è in fase di creazione. |
| ACTIVE | L'argomento è attivo e pronto per l'uso. |
| AGGIORNAMENTO IN CORSO | La configurazione dell'argomento è in fase di aggiornamento. |
| ELIMINAZIONE IN CORSO | L'argomento viene eliminato. |
## Comprendere le configurazioni degli argomenti
Il `configs` campo contiene le proprietà di configurazione Kafka dell'argomento, codificate in formato Base64. Per visualizzare la configurazione in un formato leggibile, è necessario decodificare la stringa Base64.
L'esempio seguente mostra come decodificare la configurazione utilizzando il `base64` comando su Linux o macOS.
```
echo "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw" | base64 --decode
```
L'output decodificato mostra le proprietà di configurazione dell'argomento in formato chiave-valore.
```
compression.type=producer
retention.ms=604800000
```
Per ulteriori informazioni sulle proprietà di configurazione a livello di argomento, vedere. [Configurazione Amazon MSK a livello di argomento](msk-configuration-properties.md#msk-topic-confinguration)
# Descrivi un argomento utilizzando l'API
Per descrivere un argomento utilizzando l'API, vedi [DescribeTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DescribeTopic).
# Visualizzare le informazioni sulla partizione per un argomento
È possibile recuperare informazioni dettagliate sulle partizioni di un argomento specifico nel cluster MSK Provisioned. Queste informazioni includono il numero di partizione, il broker leader, i broker di replica e le repliche in-sync (ISR). Ciò è utile per monitorare la distribuzione delle partizioni, identificare partizioni sottoreplicate o risolvere problemi di replica.
**Nota**
Questa risposta API riflette i dati che si aggiornano all'incirca ogni minuto. Per conoscere lo stato più recente dell'argomento dopo aver apportato le modifiche, attendi circa un minuto prima di eseguire l'interrogazione.
**Topics**
+ [Visualizzate le informazioni sulla partizione utilizzando il Console di gestione AWS](describe-topic-partitions-console.md)
+ [Visualizza le informazioni sulla partizione utilizzando il AWS CLI](describe-topic-partitions-cli.md)
+ [Visualizza le informazioni sulle partizioni utilizzando l'API](describe-topic-partitions-api.md)
# Visualizzate le informazioni sulla partizione utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster che contiene l'argomento.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. Nell'elenco degli argomenti, scegli il nome dell'argomento per il quale desideri visualizzare le informazioni sulla partizione.
1. Nella pagina dei dettagli dell'argomento, vengono visualizzate le informazioni sulla partizione, che mostrano il numero di partizione, il leader broker, le repliche e le repliche sincronizzate per ogni partizione.
# Visualizza le informazioni sulla partizione utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster e *TopicName* con il nome dell'argomento.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"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]
}
]
}
```
## Comprensione delle informazioni sulla partizione
La risposta include le seguenti informazioni per ogni partizione:
+ **partizione**: il numero della partizione. Le partizioni sono numerate a partire da 0.
+ **leader**: l'ID del broker del leader per questa partizione. Il leader gestisce tutte le richieste di lettura e scrittura per la partizione.
+ **repliche**: l'elenco dei broker IDs che dispongono di repliche di questa partizione. Ciò include sia le repliche in-sync che quelle in-sync. out-of-sync
+ **isr**: l'elenco dei broker IDs che sono repliche sincronizzate. Queste repliche sono pienamente in contatto con il leader e possono subentrare come leader, se necessario.
Nell'esempio precedente, la partizione 2 ha una out-of-sync replica. L'`replicas`elenco include il broker 2, ma l'`isr`elenco no. Ciò indica che il broker 2 non è completamente al passo con il leader di questa partizione.
## Impaginazione dei risultati
Se l'argomento ha molte partizioni, puoi utilizzare l'impaginazione per recuperare i risultati in batch più piccoli. Utilizzate il `--max-results` parametro per specificare il numero massimo di partizioni da restituire e utilizzate il `--next-token` parametro per recuperare la pagina successiva di risultati.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10
```
Se sono disponibili più risultati, la risposta include un `nextToken` valore. Usa questo token per recuperare la pagina successiva di risultati.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10 --next-token NextToken
```
## Casi di utilizzo comune
La visualizzazione delle informazioni sulle partizioni è utile per diversi scenari:
+ **Identificazione delle partizioni poco replicate**: confronta `isr` gli elenchi `replicas` and per identificare le partizioni in cui alcune repliche non sono sincronizzate. Ciò può indicare problemi di prestazioni o problemi di broker.
+ **Monitoraggio della distribuzione delle partizioni**: verifica che i leader delle partizioni siano distribuiti uniformemente tra i broker per garantire un carico bilanciato.
+ **Risoluzione dei problemi di replica: identifica quali broker hanno problemi** a tenere il passo con la replica esaminando l'elenco ISR.
+ **Pianificazione del ribilanciamento delle partizioni**: utilizzate queste informazioni per comprendere il layout corrente delle partizioni prima di eseguire le operazioni di ribilanciamento.
# Visualizza le informazioni sulle partizioni utilizzando l'API
Per visualizzare le informazioni sulla partizione utilizzando l'API, vedere. [DescribeTopicPartitions](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname-partitions.html#DescribeTopicPartitions)
# Crea argomenti in un cluster Amazon MSK
È possibile creare argomenti nel cluster MSK Provisioned utilizzando direttamente questa API senza configurare alcun Kafka personalizzato. AdminClient Quando si crea un argomento, si specificano il nome dell'argomento, il numero di partizioni, il fattore di replica e, facoltativamente, le configurazioni dell'argomento.
**Topics**
+ [Crea argomenti utilizzando il Console di gestione AWS](create-topic-console.md)
+ [Crea un argomento utilizzando il AWS CLI](create-topic-cli.md)
+ [Crea un argomento utilizzando l'API](create-topic-api.md)
# Crea argomenti utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster in cui desideri creare gli argomenti.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. Scegli **Create topic** (Crea argomento).
1. Inserisci il nome dell'argomento, il numero di partizioni e il fattore di replica. Facoltativamente, aggiungi configurazioni. Puoi creare più argomenti contemporaneamente.
1. Scegli **Create topic** (Crea argomento).
# Crea un argomento utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
```
aws kafka create-topic --cluster-arn ClusterArn --topic-name MyTopic --partition-count 3 --replication-factor 3
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "CREATING"
}
```
# Crea un argomento utilizzando l'API
Per creare un argomento utilizzando l'API, consulta [CreateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#CreateTopic).
# Aggiornare un argomento in un cluster Amazon MSK
Aggiornate il conteggio delle partizioni o le configurazioni a livello di argomento per un argomento esistente. Questa operazione modifica l'argomento senza richiedere attività ricreative.
**Nota**
È possibile aggiornare il conteggio delle partizioni o le configurazioni degli argomenti in una singola chiamata API, ma non entrambi contemporaneamente. Per aggiornare entrambi, effettua chiamate API separate.
**Topics**
+ [Aggiorna un argomento utilizzando il Console di gestione AWS](update-topic-console.md)
+ [Aggiornare un argomento utilizzando il AWS CLI](update-topic-cli.md)
+ [Aggiorna un argomento utilizzando l'API](update-topic-api.md)
# Aggiorna un argomento utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster contenente l'argomento che desideri aggiornare.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. **Seleziona l'argomento che desideri aggiornare, quindi scegli **Modifica impostazioni delle partizioni** o **Modifica configurazioni** da Azioni.**
1. Aggiorna il numero di partizioni o le configurazioni in base alle esigenze.
1. Scegli **Save** (Salva).
# Aggiornare un argomento utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster e *TopicName* con il nome dell'argomento che desideri aggiornare.
```
aws kafka update-topic --cluster-arn ClusterArn --topic-name TopicName --partition-count 6
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "UPDATING"
}
```
# Aggiorna un argomento utilizzando l'API
Per aggiornare un argomento utilizzando l'API, consulta [UpdateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#UpdateTopic).
# Eliminare un argomento in un cluster Amazon MSK
L'eliminazione di un argomento rimuove definitivamente tutti i dati, i metadati e le informazioni sulla partizione. Questa operazione non può essere annullata.
**Topics**
+ [Eliminare un argomento utilizzando il Console di gestione AWS](delete-topic-console.md)
+ [Eliminare un argomento utilizzando il AWS CLI](delete-topic-cli.md)
+ [Elimina un argomento utilizzando l'API](delete-topic-api.md)
# Eliminare un argomento utilizzando il Console di gestione AWS
1. Accedere a e aprire la console Amazon MSK da [https://console.aws.amazon.com/msk/casa? Console di gestione AWS region=us-east-1\$1/home/.](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/)
1. Nell'elenco dei cluster, scegli il nome del cluster contenente l'argomento che desideri eliminare.
1. Nella pagina dei dettagli del cluster, scegli la scheda **Argomenti**.
1. Seleziona gli argomenti che desideri eliminare, quindi scegli **Elimina** da **Azioni**.
1. Conferma l'eliminazione, quindi scegli **Elimina**.
# Eliminare un argomento utilizzando il AWS CLI
Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) del cluster e *TopicName* con il nome dell'argomento che desideri eliminare.
```
aws kafka delete-topic --cluster-arn ClusterArn --topic-name TopicName
```
L'output di questo comando è simile all'esempio JSON seguente.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "DELETING"
}
```
# Elimina un argomento utilizzando l'API
Per eliminare un argomento utilizzando l'API, consulta [DeleteTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DeleteTopic).
# Risorse Amazon MSK
Il termine *risorse* ha due significati in Amazon MSK, a seconda del contesto. Nel contesto di APIs una risorsa c'è una struttura sulla quale è possibile richiamare un'operazione. Per un elenco di queste risorse e delle operazioni che è possibile richiamare su di esse, consulta la sezione [Resources](https://docs.aws.amazon.com/msk/1.0/apireference/resources.html) nella documentazione di riferimento dell'API di Amazon MSK. Nel contesto di [Controllo degli accessi IAM](iam-access-control.md), una risorsa è un'entità a cui è possibile consentire o rifiutare l'accesso, come definito nella sezione [Risorse relative alla politica di autorizzazione](kafka-actions.md#msk-iam-resources).
# Versioni di Apache Kafka
Quando si crea un cluster Amazon MSK, specifica quale versione di Apache Kafka desideri utilizzare. Puoi inoltre aggiornare la versione di Apache Kafka di un cluster esistente. Gli argomenti del capitolo aiutano a comprendere le tempistiche per il supporto delle versioni di Kafka e i suggerimenti per le migliori pratiche.
**Topics**
+ [Versioni di Apache Kafka supportate](supported-kafka-versions.md)
+ [Supporto per la versione di Amazon MSK](version-support.md)
# Versioni di Apache Kafka supportate
Streaming gestito da Amazon per Apache Kafka (Amazon MSK) supporta le seguenti versioni di Apache Kafka e Amazon MSK. La community di Apache Kafka fornisce circa 12 mesi di supporto per una versione successiva alla data di rilascio. Per ulteriori dettagli, consulta la politica [EOL (end of life) di Apache Kafka](https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatIsOurEOLPolicy?).
La tabella seguente elenca le versioni di Apache Kafka supportate da Amazon MSK.
| Versione Apache Kafka | Data di rilascio di MSK | Data di fine supporto |
| --- | --- | --- |
| [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 |
| [24.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-04-02 | 2024-06-08 |
| [2,41.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-09-09 | 2024-06-08 |
| [2.5.1](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) | 2020-09-30 | 2024-06-08 |
| [2,6,0](https://archive.apache.org/dist/kafka/2.6.0/RELEASE_NOTES.html) | 2020-10-21 | 2024-09-11 |
| [2,6,1](https://archive.apache.org/dist/kafka/2.6.1/RELEASE_NOTES.html) | 2021-01-19 | 2024-09-11 |
| [2,6,2](https://archive.apache.org/dist/kafka/2.6.2/RELEASE_NOTES.html) | 2021-04-29 | 2024-09-11 |
| [2,6,3](https://archive.apache.org/dist/kafka/2.6.3/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2,7,0](https://archive.apache.org/dist/kafka/2.7.0/RELEASE_NOTES.html) | 2020-12-29 | 2024-09-11 |
| [2,7,1](https://archive.apache.org/dist/kafka/2.7.1/RELEASE_NOTES.html) | 2021-05-25 | 2024-09-11 |
| [2,7,2](https://archive.apache.org/dist/kafka/2.7.2/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2,80](https://archive.apache.org/dist/kafka/2.8.0/RELEASE_NOTES.html) | 2021-05-19 | 2024-09-11 |
| [28,1](https://archive.apache.org/dist/kafka/2.8.1/RELEASE_NOTES.html) | 2022-10-28 | 2024-09-11 |
| [2.8.2 livelli](https://archive.apache.org/dist/kafka/2.8.2/RELEASE_NOTES.html) | 2022-10-28 | 2025-01-14 |
| [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [32,0](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [3,31](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) | 2022-10-26 | 2024-09-11 |
| [3,32](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) | -02 | 2024-09-11 |
| [3,40](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) | 2023-11-16 | 2026-06-01 |
| [3.7. x](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html) | 2024-05-29 | -- |
| [3.8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html) | 2025-02-20 | -- |
| [3.9.x (consigliato)](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html) | 2025-04-21 | -- |
| [4,0x](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html) | 2025-05-16 | -- |
| [4.1.x](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) | 2025-10-15 | -- |
Per ulteriori informazioni sulla politica di supporto delle versioni di Amazon MSK, consulta[Politica di supporto delle versioni di Amazon MSK](version-support.md#version-support-policy).
## Amazon MSK versione 4.1.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta Apache Kafka versione 4.1, che introduce Queues come funzionalità di anteprima, un nuovo Streams Rebalance Protocol in accesso anticipato e Eligible Leader Replicas (ELR). Oltre a queste funzionalità, la versione 4.1 di Apache Kafka include varie correzioni di bug e miglioramenti.
Uno dei punti salienti di Kafka 4.1 è l'introduzione di Queues come funzionalità di anteprima. È possibile utilizzare più utenti per elaborare i messaggi dalle partizioni dello stesso argomento, migliorando il parallelismo e la velocità effettiva per i carichi di lavoro che richiedono il recapito dei messaggi. point-to-point Il nuovo Streams Rebalance Protocol si basa sul protocollo di ribilanciamento dei consumatori di Kafka 4.0, estendendo le funzionalità di coordinamento dei broker a Kafka Streams per l'assegnazione delle attività e il ribilanciamento ottimizzati. Inoltre, ELR è ora abilitato di default per rafforzare la disponibilità.
Per maggiori dettagli e un elenco completo dei miglioramenti e delle correzioni di bug, consulta le note di [rilascio di Apache Kafka](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) per la versione 4.1.
Per iniziare a utilizzare Apache Kafka 4.1 su Amazon MSK, scegli la versione 4.1.x quando crei un nuovo cluster tramite, o. Console di gestione AWS AWS CLI AWS SDKs Puoi anche aggiornare i cluster con provisioning MSK esistenti con un aggiornamento continuo sul posto. Amazon MSK orchestra i riavvii del broker per mantenere la disponibilità e proteggere i dati durante l'aggiornamento. Il supporto per la versione 4.1 di Kafka è disponibile ovunque sia offerto Regioni AWS Amazon MSK.
## Amazon MSK versione 4.0.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta Apache Kafka versione 4.0. Questa versione apporta i più recenti progressi nella gestione e nelle prestazioni dei cluster a MSK Provisioned. Kafka 4.0 introduce un nuovo protocollo di ribilanciamento per i consumatori, ora disponibile a tutti, che aiuta a garantire ribilanciamenti di gruppo più fluidi e rapidi. Inoltre, Kafka 4.0 richiede broker e strumenti per utilizzare Java 17, che offre sicurezza e prestazioni migliorate, include varie correzioni di bug e miglioramenti e rende obsoleta la gestione dei metadati tramite Apache. ZooKeeper
[Per maggiori dettagli e un elenco completo di miglioramenti e correzioni di bug, consulta le note di rilascio di Apache Kafka per la versione 4.0.](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html)
## Amazon MSK versione 3.9.x (consigliata)
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta Apache Kafka versione 3.9. Questa versione migliora la funzionalità di storage su più livelli consentendoti di conservare i dati su più livelli quando disabiliti lo storage su più livelli a livello di argomento. Le applicazioni consumer possono leggere i dati storici dal Remote Log Start Offset (Rx) mantenendo al contempo gli offset di log continui sullo storage locale e remoto.
La versione 3.9 è l'ultima versione a supportare entrambi i sistemi di gestione dei ZooKeeper metadati KRaft . Amazon MSK fornirà il supporto esteso per la versione 3.9 per un minimo di due anni dalla data di rilascio.
Per ulteriori dettagli e un elenco completo di miglioramenti e correzioni di bug, consulta le note di rilascio di [Apache Kafka](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html) per la versione 3.9.x.
## Amazon MSK versione 3.8.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta Apache Kafka versione 3.8. Ora puoi creare nuovi cluster utilizzando la versione 3.8 con KRAFT o la ZooKeeper modalità per la gestione dei metadati o aggiornare i cluster basati esistenti per utilizzare la versione 3.8. ZooKeeper La versione 3.8 di Apache Kafka include diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Le nuove funzionalità chiave includono il supporto per la configurazione del livello di compressione. Ciò consente di ottimizzare ulteriormente le prestazioni quando si utilizzano tipi di compressione come lz4, zstd e gzip, modificando il livello di compressione predefinito.
Per maggiori dettagli e un elenco completo dei miglioramenti e delle correzioni di bug, consulta le note di rilascio di [Apache Kafka per la versione 3.8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html).
## Apache Kafka versione 3.7.x (con storage su più livelli pronto per la produzione)
La versione 3.7.x di Apache Kafka su MSK include il supporto per Apache Kafka versione 3.7.0. È possibile creare cluster o aggiornare i cluster esistenti per utilizzare la nuova versione 3.7.x. Con questa modifica nella denominazione delle versioni, non è più necessario adottare versioni di patch fix più recenti come la 3.7.1 quando vengono rilasciate dalla community di Apache Kafka. Amazon MSK aggiornerà automaticamente la versione 3.7.x per supportare le future versioni delle patch non appena saranno disponibili. In questo modo puoi beneficiare della sicurezza e delle correzioni di bug disponibili tramite le versioni di patch fix senza attivare un aggiornamento della versione. Queste versioni di patch fix rilasciate da Apache Kafka non compromettono la compatibilità delle versioni e puoi trarre vantaggio dalle nuove versioni di patch fix senza preoccuparti degli errori di lettura o scrittura delle applicazioni client. Assicurati che gli strumenti di automazione dell'infrastruttura, ad esempio CloudFormation, siano aggiornati per tenere conto di questa modifica nella denominazione delle versioni.
Amazon MSK ora supporta la KRaft modalità (Apache Kafka Raft) nella versione 3.7.x di Apache Kafka. Su Amazon MSK, come per i ZooKeeper nodi, KRaft i controller sono inclusi senza costi aggiuntivi e non richiedono alcuna configurazione o gestione aggiuntiva da parte dell'utente. Ora puoi creare cluster in entrambe le KRaft modalità o ZooKeeper modalità su Apache Kafka versione 3.7.x. In modalità Kraft, puoi aggiungere fino a 60 broker per ospitare più partizioni per cluster, senza richiedere un aumento del limite, rispetto alla quota di 30 broker sui cluster basati su ZooKeeper. [KRaft modalità](metadata-management.md#kraft-intro)Per ulteriori informazioni su MSK, consulta. KRaft
La versione 3.7.x di Apache Kafka include anche diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. I miglioramenti principali includono le ottimizzazioni di Leader Discovery per i client e le opzioni di ottimizzazione del log Segment Flush. [Per un elenco completo dei miglioramenti e delle correzioni di bug, consultate le note di rilascio di Apache Kafka per la versione 3.7.0.](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html)
## Apache Kafka versione 3.6.0 (con archiviazione a più livelli pronta per la produzione)
Per informazioni su Apache Kafka versione 3.6.0 (con archiviazione a più livelli pronta per la produzione), consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
Per motivi di stabilità, Amazon MSK continuerà a utilizzare e gestire ZooKeeper per la gestione del quorum in questa versione.
## Amazon MSK versione 3.5.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta la versione 3.5.1 di Apache Kafka per cluster nuovi ed esistenti. Apache Kafka 3.5.1 include diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Le caratteristiche principali includono l'introduzione di una nuova assegnazione delle partizioni compatibile con i rack per i consumatori. Amazon MSK continuerà a utilizzare e gestire Zookeeper per la gestione del quorum in questa versione. Per un elenco completo dei miglioramenti e delle correzioni di bug, consulta le note di rilascio di Apache Kafka per la versione 3.5.1.
Per informazioni su Apache Kafka versione 3.5.1, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
## Amazon MSK versione 3.4.0
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta Apache Kafka versione 3.4.0 per cluster nuovi ed esistenti. Apache Kafka 3.4.0 include diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Le funzionalità principali includono una correzione per migliorare la stabilità da recuperare dalla replica più vicina. Amazon MSK continuerà a utilizzare e gestire Zookeeper per la gestione del quorum in questa versione. Per un elenco completo dei miglioramenti e delle correzioni di bug, consulta le note di rilascio di Apache Kafka per la versione 3.4.0.
Per informazioni su Apache Kafka versione 3.4.0, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
## Amazon MSK versione 3.3.2
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta la versione 3.3.2 di Apache Kafka per cluster nuovi ed esistenti. Apache Kafka 3.3.2 include diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Le funzionalità principali includono una correzione per migliorare la stabilità da recuperare dalla replica più vicina. Amazon MSK continuerà a utilizzare e gestire Zookeeper per la gestione del quorum in questa versione. Per un elenco completo dei miglioramenti e delle correzioni di bug, consulta le note di rilascio di Apache Kafka per la versione 3.3.2.
Per informazioni su Apache Kafka versione 3.3.2, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
## Amazon MSK versione 3.3.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta la versione 3.3.1 di Apache Kafka per cluster nuovi ed esistenti. Apache Kafka 3.3.1 include diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Alcune delle funzionalità principali includono miglioramenti alle metriche e al partizionatore. Per motivi di stabilità, Amazon MSK continuerà a utilizzare e gestire ZooKeeper per la gestione del quorum in questa versione. Per un elenco completo dei miglioramenti e delle correzioni di bug, consultate le note di rilascio di Apache Kafka per la versione 3.3.1.
Per informazioni su Apache Kafka versione 3.3.1, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
## Amazon MSK versione 3.1.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) ora supporta le versioni 3.1.1 e 3.2.0 di Apache Kafka per cluster nuovi ed esistenti. Apache Kafka 3.1.1 e Apache Kafka 3.2.0 includono diverse correzioni di bug e nuove funzionalità che migliorano le prestazioni. Alcune delle funzionalità principali includono miglioramenti alle metriche e l'uso dell'argomento. IDs MSK continuerà a utilizzare e gestire Zookeeper per la gestione del quorum in questa versione per motivi di stabilità. Per un elenco completo dei miglioramenti e delle correzioni di bug, consultate le note di rilascio di Apache Kafka per 3.1.1 e 3.2.0.
[Per informazioni sulle versioni 3.1.1 e 3.2.0 di Apache Kafka, consultate le relative note di rilascio 3.2.0 e le note di [rilascio](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) 3.1.1 sul sito di download di Apache Kafka.](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html)
## Archiviazione a più livelli Amazon MSK versione 2.8.2.tiered
Questa versione è una versione solo per Amazon MSK di Apache Kafka versione 2.8.2 ed è compatibile con i client open source Apache Kafka.
[La versione 2.8.2.tiered contiene funzionalità di storage su più livelli compatibili con quelle introdotte in KIP-405 per Apache Kafka. APIs ](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) Per ulteriori informazioni sulla funzionalità di archiviazione a più livelli di Amazon MSK, consulta la sezione [Storage su più livelli per broker Standard](msk-tiered-storage.md).
## Apache Kafka versione 2.5.1
La versione 2.5.1 di Apache Kafka include diverse correzioni di bug e nuove funzionalità, tra cui la crittografia in transito per Apache e i client di amministrazione. ZooKeeper Amazon MSK fornisce ZooKeeper endpoint TLS, che possono essere interrogati durante l'operazione. [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
L'output dell'[ DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operazione include il `ZookeeperConnectStringTls` nodo, che elenca gli endpoint TLS zookeeper.
L'esempio seguente mostra il nodo `ZookeeperConnectStringTls` della risposta per l'operazione `DescribeCluster`:
```
"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"
```
Per informazioni sull'utilizzo della crittografia TLS con ZooKeeper, consulta la sezione [Utilizzo della sicurezza TLS con Apache ZooKeeper](zookeeper-security-tls.md).
Per ulteriori informazioni su Apache Kafka versione 2.5.1, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
## Versione di correzione dei bug Amazon MSK 2.4.1.1
Questa versione è una versione di correzione dei bug di Apache Kafka 2.4.1 disponibile solo per Amazon MSK. Questa versione di correzione contiene una correzione per [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752), un problema raro che causa il continuo ribilanciamento dei gruppi di consumatori e la permanenza nello stato `PreparingRebalance`. Questo problema riguarda i cluster che eseguono Apache Kafka versioni 2.3.1 e 2.4.1. Questa versione contiene una correzione prodotta dalla comunità disponibile nella versione 2.5.0 di Apache Kafka.
**Nota**
I cluster Amazon MSK che eseguono la versione 2.4.1.1 sono compatibili con qualsiasi client Apache Kafka compatibile con la versione 2.4.1 di Apache Kafka.
Se preferisci usare Apache Kafka 2.4.1, ti consigliamo di utilizzare la versione 2.4.1.1 di correzione dei bug MSK per i nuovi cluster Amazon MSK. Per incorporare questa correzione, puoi aggiornare i cluster esistenti che eseguono Apache Kafka versione 2.4.1 a questa versione. Per informazioni sull'aggiornamento di un cluster esistente, consulta la sezione [Aggiorna la versione di Apache Kafka](version-upgrades.md).
Per risolvere questo problema senza aggiornare il cluster alla versione 2.4.1.1, consulta la sezione [Gruppo di consumatori bloccato nello stato `PreparingRebalance`](troubleshooting.md#consumer-group-rebalance) della guida [Risolvi i problemi del tuo cluster Amazon MSK](troubleshooting.md).
## Apache Kafka versione 2.4.1 (usa invece 2.4.1.1)
**Nota**
Non è più possibile creare un cluster MSK con la versione 2.4.1 di Apache Kafka. In alternativa, è possibile utilizzare [Versione di correzione dei bug Amazon MSK 2.4.1.1](#2.4.1.1) con client compatibili con la versione 2.4.1 di Apache Kafka. Se disponi già di un cluster MSK con Apache Kafka versione 2.4.1, ti consigliamo di aggiornarlo per utilizzare invece la versione 2.4.1.1 di Apache Kafka.
KIP-392 è una delle principali proposte di miglioramento di Kafka incluse nella versione 2.4.1 di Apache Kafka. Questo miglioramento consente ai consumatori di recuperare dati dalla replica più vicina. Per utilizzare questa caratteristica, imposta `client.rack` nelle proprietà consumatore sull'ID della zona di disponibilità del consumatore. Un esempio di ID di zona di disponibilità è `use1-az1`. Amazon MSK imposta `broker.rack` le zone IDs di disponibilità dei broker. Inoltre, devi impostare la proprietà di configurazione `replica.selector.class` su `org.apache.kafka.common.replica.RackAwareReplicaSelector`, che è un'implementazione di consapevolezza rack fornita da Apache Kafka.
Quando utilizzi questa versione di Apache Kafka, i parametri nel livello di monitoraggio `PER_TOPIC_PER_BROKER` vengono visualizzati solo dopo che i valori diventano diversi da zero per la prima volta. Per ulteriori informazioni, consulta [Monitoraggio del livello `PER_TOPIC_PER_BROKER`](metrics-details.md#broker-topic-metrics).
Per informazioni su come trovare la zona di disponibilità IDs, consulta [AZ IDs for Your Resource nella guida](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) per l' AWS Resource Access Manager utente.
Per informazioni sull'impostazione delle proprietà di configurazione, consulta [Configurazione Amazon MSK Provisioned](msk-configuration.md).
Per ulteriori informazioni su KIP-392, consulta [Allow Consumers to Fetch from Closest Replica](https://cwiki.apache.org/confluence/display/KAFKA/KIP-392:+Allow+consumers+to+fetch+from+closest+replica) nelle pagine di Confluence.
Per ulteriori informazioni su Apache Kafka versione 2.4.1, consulta le relative [note di rilascio](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) sul sito dei download di Apache Kafka.
# Supporto per la versione di Amazon MSK
Questo argomento descrive [Politica di supporto delle versioni di Amazon MSK](#version-support-policy) e la procedura per[Aggiorna la versione di Apache Kafka](version-upgrades.md). Se stai aggiornando la tua versione di Kafka, segui le migliori pratiche descritte in. [Best practice per gli aggiornamenti delle versioni](version-upgrades-best-practices.md)
**Topics**
+ [Politica di supporto delle versioni di Amazon MSK](#version-support-policy)
+ [Aggiorna la versione di Apache Kafka](version-upgrades.md)
+ [Best practice per gli aggiornamenti delle versioni](version-upgrades-best-practices.md)
## Politica di supporto delle versioni di Amazon MSK
Questa sezione descrive la politica di supporto per le versioni di Kafka supportate da Amazon MSK.
+ Tutte le versioni di Kafka sono supportate fino al raggiungimento della data di fine del supporto. Per informazioni dettagliate sulle date di fine del supporto, consulta. [Versioni di Apache Kafka supportate](supported-kafka-versions.md) Aggiorna il tuo cluster MSK alla versione di Kafka consigliata o alla versione successiva prima della data di fine del supporto. Per dettagli sull'aggiornamento della versione di Apache Kafka, consulta. [Aggiorna la versione di Apache Kafka](version-upgrades.md) Un cluster che utilizza una versione di Kafka dopo la data di fine del supporto viene aggiornato automaticamente alla versione Kafka consigliata. Gli aggiornamenti automatici possono avvenire in qualsiasi momento dopo la data di fine del supporto. Non riceverai alcuna notifica prima dell'aggiornamento.
+ MSK eliminerà gradualmente il supporto per i cluster di nuova creazione che utilizzano versioni di Kafka con date di fine supporto pubblicate.
# Aggiorna la versione di Apache Kafka
È possibile aggiornare un cluster MSK esistente a una versione più recente di Apache Kafka. Prima di aggiornare la versione di Kafka del cluster, verificate che la versione del software lato client supporti le funzionalità della nuova versione di Kafka.
Per informazioni su come rendere un cluster altamente disponibile durante un aggiornamento, consulta. [Creazione di cluster a disponibilità elevata](bestpractices.md#ensure-high-availability)
**Aggiornare la versione di Apache Kafka utilizzando il Console di gestione AWS**
1. Apri la console Amazon MSK all'indirizzo [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Nella barra di navigazione, scegli la regione in cui hai creato il cluster MSK.
1. Scegli il cluster MSK che desideri aggiornare.
1. Nella scheda **Proprietà**, scegli **Aggiorna** nella sezione relativa alla versione di **Apache Kafka**.
1. Nella sezione relativa alla **versione di Apache Kafka**, procedi come segue:
1. Nell'elenco a discesa *Scegli la versione di Apache Kafka, scegli la versione* di destinazione a cui desideri eseguire l'aggiornamento. Ad esempio, scegli **3.9.x**.
1. (Facoltativo) Scegliete **Visualizza compatibilità delle versioni** per verificare la compatibilità tra la versione corrente del cluster e le versioni di aggiornamento disponibili. Quindi, seleziona **Scegli** per procedere.
**Nota**
Amazon MSK supporta gli aggiornamenti in loco alla maggior parte delle versioni di Apache Kafka. Tuttavia, quando si esegue l'aggiornamento da una versione basata su Kafka ZooKeeper a una versione basata su Kafka, è necessario creare un nuovo cluster KRaft. Quindi, copia i dati nel nuovo cluster e sposta i client nel nuovo cluster.
1. (Facoltativo) Seleziona la casella di controllo **Aggiorna la configurazione del cluster** per applicare gli aggiornamenti di configurazione compatibili con la nuova versione. Ciò abilita le funzionalità e i miglioramenti della nuova versione.
Puoi saltare questo passaggio se devi mantenere le configurazioni personalizzate esistenti.
**Nota**
Gli aggiornamenti lato server non aggiornano automaticamente le applicazioni client.
Per mantenere la stabilità del cluster, i downgrade di versione non sono supportati.
1. Scegli **Aggiorna** per avviare il processo.
**Aggiorna la versione di Apache Kafka usando il AWS CLI**
1. Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
```
aws kafka get-compatible-kafka-versions --cluster-arn ClusterArn
```
L'output di questo comando include un elenco delle versioni di Apache Kafka a cui è possibile aggiornare il cluster. Il risultato sembra l'esempio seguente.
```
{
"CompatibleKafkaVersions": [
{
"SourceVersion": "2.2.1",
"TargetVersions": [
"2.3.1",
"2.4.1",
"2.4.1.1",
"2.5.1"
]
}
]
}
```
1. Esegui il comando seguente, sostituendolo *ClusterArn* con l'Amazon Resource Name (ARN) che hai ottenuto quando hai creato il cluster. Se non disponi dell'ARN per il cluster, puoi trovarlo elencando tutti i cluster. Per ulteriori informazioni, consulta [Elenca i cluster Amazon MSK](msk-list-clusters.md).
Sostituiscilo *Current-Cluster-Version* con la versione corrente del cluster. Perché *TargetVersion* è possibile specificare una qualsiasi delle versioni di destinazione dall'output del comando precedente.
**Importante**
Le versioni del cluster non sono interi semplici. Per trovare la versione corrente del cluster, usa l'[DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operazione o il comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Una versione di esempio è `KTVPDKIKX0DER`.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version TargetVersion
```
L'output del comando precedente è simile al JSON seguente.
```
{
"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. Per ottenere il risultato dell'`update-cluster-kafka-version`operazione, esegui il comando seguente, sostituendolo *ClusterOperationArn* con l'ARN ottenuto nell'output del `update-cluster-kafka-version` comando.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
L'output di questo comando `describe-cluster-operation` è simile all'esempio JSON seguente.
```
{
"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"
}
}
}
```
Se il valore di `OperationState` è `UPDATE_IN_PROGRESS`, attendi qualche minuto, quindi esegui nuovamente il comando `describe-cluster-operation`. Al termine dell'operazione, il valore di `OperationState` diventa `UPDATE_COMPLETE`. Poiché il tempo necessario ad Amazon MSK per completare l'operazione varia, potrebbe essere necessario eseguire ripetutamente il controllo fino al completamento dell'operazione.
**Aggiorna la versione di Apache Kafka utilizzando l'API**
1. Richiama l'[GetCompatibleKafkaVersions](https://docs.aws.amazon.com//msk/1.0/apireference/compatible-kafka-versions.html#GetCompatibleKafkaVersions)operazione per ottenere un elenco delle versioni di Apache Kafka a cui è possibile aggiornare il cluster.
1. Richiama l'[UpdateClusterKafkaVersion](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-version.html#UpdateClusterKafkaVersion)operazione per aggiornare il cluster a una delle versioni compatibili di Apache Kafka.
# Best practice per gli aggiornamenti delle versioni
Per garantire la continuità del client durante l'aggiornamento progressivo eseguito come parte del processo di aggiornamento della versione di Kafka, esamina la configurazione dei client e gli argomenti di Apache Kafka come segue:
+ Imposta il fattore di replica dell'argomento (RF) su un valore minimo di per i cluster Two-AZ e un valore minimo di `2` per i cluster Three-AZ. `3` Un valore RF di `2` può portare a partizioni offline durante l'applicazione delle patch.
+ Imposta il numero minimo di repliche in-sync (miniSR) su un valore massimo di 1 in meno rispetto al tuo Replication Factor (RF), che è. `miniISR = (RF) - 1` Ciò garantisce che il set di repliche delle partizioni possa tollerare che una replica sia offline o poco replicata.
+ Configura i client per utilizzare più stringhe di connessione del broker. La presenza di più broker nella stringa di connessione di un client consente il failover se uno specifico broker che supporta il client I/O inizia a ricevere le patch. Per informazioni su come ottenere una stringa di connessione con più broker, consulta [Ottenere i broker bootstrap per un cluster Amazon MSK](https://docs.aws.amazon.com//msk/latest/developerguide/msk-get-bootstrap-brokers.html).
+ Ti consigliamo di aggiornare i client che si connettono alla versione consigliata o superiore per beneficiare delle funzionalità disponibili nella nuova versione. Gli upgrade dei client non sono soggetti alle date di fine del ciclo di vita (EOL) della versione Kafka del cluster MSK e non è necessario che vengano completati entro la data di fine del ciclo di vita. Apache Kafka fornisce una [politica di compatibilità dei client bidirezionale che consente ai client](https://kafka.apache.org/protocol#protocol_compatibility) più vecchi di lavorare con cluster più recenti e viceversa.
+ È probabile che i client Kafka che utilizzano le versioni 3.x.x abbiano le seguenti impostazioni predefinite: e. `acks=all` `enable.idempotence=true` `acks=all`è diverso dall'impostazione predefinita precedente di `acks=1` e offre una maggiore durabilità assicurando che tutte le repliche sincronizzate riconoscano la richiesta di produzione. Analogamente, l'impostazione predefinita per `enable.idempotence` era precedente. `false` La modifica all'`enable.idempotence=true`impostazione predefinita riduce la probabilità di messaggi duplicati. Queste modifiche sono considerate impostazioni di best practice e possono introdurre una piccola quantità di latenza aggiuntiva che rientra nei normali parametri di prestazione.
+ Utilizzate la versione consigliata di Kafka per creare nuovi cluster MSK. L'utilizzo della versione consigliata di Kafka consente di sfruttare le funzionalità più recenti di Kafka e MSK.
# Risolvi i problemi del tuo cluster Amazon MSK
Le seguenti informazioni consentono di semplificare la risoluzione dei problemi che si potrebbero verificare con il cluster Amazon MSK. Puoi anche pubblicare il problema in [AWS re:Post](https://repost.aws/). Per la risoluzione dei problemi di Amazon MSK Replicator, consulta. [Risolvete i problemi relativi a MSK Replicator](msk-replicator-troubleshooting.md)
**Topics**
+ [La sostituzione del volume causa la saturazione del disco a causa del sovraccarico della replica](#replication-overload-disk-saturation)
+ [Gruppo di consumatori bloccato nello stato `PreparingRebalance`](#consumer-group-rebalance)
+ [Errore nell'invio dei log del broker ad Amazon CloudWatch Logs](#cw-broker-logs-error)
+ [Nessun gruppo di sicurezza predefinito](#troubleshooting-shared-vpc)
+ [I cluster sono bloccati nello stato CREATING](#troubleshooting-cluster-stuck)
+ [Lo stato del cluster passa da CREATING a FAILED](#troubleshooting-cluster-failed)
+ [Lo stato del cluster è ACTIVE ma i produttori non possono inviare dati o i consumatori non possono ricevere dati](#troubleshooting-nodata)
+ [AWS CLI non riconosce Amazon MSK](#troubleshooting-nocli)
+ [Le partizioni vengono messe offline o le repliche non sono sincronizzate](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [Lo spazio su disco è insufficiente](#troubleshooting-lowdiskspace)
+ [La memoria è insufficiente](#troubleshooting-lowmemory)
+ [Il produttore ottiene NotLeaderForPartitionException](#troubleshooting-NotLeaderForPartitionException)
+ [Partizioni sottoreplicate (URP) superiori a zero](#troubleshooting-urp)
+ [Il cluster ha argomenti chiamati \$1\$1amazon\$1msk\$1canary e \$1\$1amazon\$1msk\$1canary\$1state](#amazon_msk_canary)
+ [La replica delle partizioni ha esito negativo](#partition_replication_fails)
+ [Impossibile accedere al cluster con accesso pubblico attivato](#public-access-issues)
+ [Impossibile accedere al cluster tramite bootstrap IPv6](#dualstack-issues)
+ [Impossibile accedere al cluster dall'interno AWS: problemi di rete](#networking-trouble)
+ [Autenticazione non riuscita: troppe connessioni](#troubleshoot-too-many-connects)
+ [Autenticazione fallita: sessione troppo breve](#troubleshoot-session-too-short)
+ [MSK Serverless: la creazione del cluster ha esito negativo](#troubleshoot-serverless-create-cluster-failure)
+ [Impossibile eseguire l'aggiornamento KafkaVersionsList nella configurazione MSK](#troubleshoot-kafkaversionslist-cfn-update-failure)
## La sostituzione del volume causa la saturazione del disco a causa del sovraccarico della replica
In caso di guasto hardware non pianificato del volume, Amazon MSK può sostituire il volume con una nuova istanza. Kafka ripopola il nuovo volume replicando le partizioni di altri broker del cluster. Una volta che le partizioni sono state replicate e recuperate, sono idonee per l'iscrizione alla leadership e all'In-Sync Replica (ISR).
**Problema**
In un broker che si sta riprendendo dalla sostituzione dei volumi, alcune partizioni di dimensioni diverse potrebbero tornare online prima di altre. Ciò può essere problematico in quanto tali partizioni possono servire il traffico proveniente dallo stesso broker che sta ancora recuperando (replicando) altre partizioni. Questo traffico di replica a volte può saturare i limiti di throughput del volume sottostanti, che nel caso predefinito sono 250 MiB al secondo. Quando si verifica questa saturazione, tutte le partizioni già interessate ne risentono, con conseguente latenza all'interno del cluster per tutti i broker che condividono ISR con quelle partizioni interessate (non solo le partizioni leader dovute agli ack remoti). `acks=all` Questo problema è più comune nei cluster più grandi che hanno un numero maggiore di partizioni di dimensioni variabili.
**Raccomandazione**
+ Per migliorare la I/O postura di replica, assicuratevi che siano state adottate le [migliori impostazioni dei thread.](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads)
+ Per ridurre la probabilità di saturazione del volume sottostante, abilita lo storage fornito con un throughput più elevato. Un valore minimo di throughput pari a 500 MiB/s è consigliato per i casi di replica con throughput elevato, ma il valore effettivo necessario varia a seconda del throughput e del caso d'uso. [Esegui il provisioning del throughput di storage per i broker Standard in un cluster Amazon MSK](msk-provision-throughput.md).
+ Per ridurre al minimo la pressione di replica, `num.replica.fetchers` abbassare al valore predefinito di`2`.
## Gruppo di consumatori bloccato nello stato `PreparingRebalance`
Se uno o più gruppi di consumatori sono bloccati in uno stato di ribilanciamento perpetuo, la causa potrebbe essere il problema [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752) di Apache Kafka, che riguarda le versioni 2.3.1 e 2.4.1 di Apache Kafka.
Per risolvere questo problema, ti consigliamo di aggiornare il cluster alla versione [Versione di correzione dei bug Amazon MSK 2.4.1.1](supported-kafka-versions.md#2.4.1.1), che contiene una correzione per questo problema. Per informazioni sull'aggiornamento di un cluster esistente alla versione 2.4.1.1 di correzione dei bug di Amazon MSK, consulta la pagina [Aggiorna la versione di Apache Kafka](version-upgrades.md).
Le soluzioni alternative per risolvere questo problema senza aggiornare il cluster alla versione di correzione del bug Amazon MSK 2.4.1.1 consistono nell'impostare i client Kafka in modo da utilizzare [Protocollo di iscrizione statico](#consumer-group-rebalance-static) oppure [Identificazione e riavvio](#consumer-group-rebalance-reboot) il nodo dei broker di coordinamento del gruppo di consumatori bloccato.
### Implementazione del protocollo di iscrizione statico
Per implementare il protocollo di iscrizione statico nei client, procedi come indicato di seguito:
1. Imposta la proprietà `group.instance.id` della configurazione dei [consumatori Kafka](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html) su una stringa statica che identifica il consumatore nel gruppo.
1. Assicurati che le altre istanze della configurazione siano aggiornate in modo da utilizzare la stringa statica.
1. Implementa le modifiche ai tuoi consumatori Kafka.
L'utilizzo del protocollo di iscrizione statico è più efficace se il timeout della sessione nella configurazione client è impostato su una durata che consenta al consumatore di ripristinare il sistema senza innescare prematuramente un ribilanciamento del gruppo di consumatori. Ad esempio, se l'applicazione consumatore può tollerare 5 minuti di indisponibilità, un valore ragionevole per il timeout della sessione sarebbe 4 minuti anziché il valore predefinito di 10 secondi.
**Nota**
L'utilizzo del protocollo di iscrizione statico riduce solamente la probabilità di riscontrare questo problema. È possibile che questo problema si verifichi ancora anche quando si utilizza il protocollo di iscrizione statico.
### Riavvio del nodo dei broker di coordinamento
Per riavviare il nodo dei broker di coordinamento, procedi come segue:
1. Identifica il coordinatore del gruppo utilizzando il comando `kafka-consumer-groups.sh`.
1. Riavvia il coordinatore del gruppo di consumatori bloccato utilizzando l'azione [ RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker)API.
## Errore nell'invio dei log del broker ad Amazon CloudWatch Logs
Quando provi a configurare il tuo cluster per inviare i log del broker ad Amazon CloudWatch Logs, potresti ottenere una delle due eccezioni.
Se viene restituita un'eccezione `InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded`, riprova utilizzando i gruppi di log che iniziano con `/aws/vendedlogs/`. Per ulteriori informazioni, consulta la pagina [Enabling Logging from Certain Amazon Web Services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html).
Se ricevi un'`InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded`eccezione, scegli una policy Amazon CloudWatch Logs esistente nel tuo account e aggiungi il seguente codice JSON.
```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```
Se provi ad aggiungere il codice JSON sopra riportato a una policy esistente ma ricevi un errore che indica che hai raggiunto la lunghezza massima per la policy che hai scelto, prova ad aggiungere il codice JSON a un'altra delle tue politiche Amazon Logs. CloudWatch Dopo aver aggiunto il codice JSON a una policy esistente, prova ancora una volta a configurare la distribuzione dei log del broker ad Amazon Logs. CloudWatch
## Nessun gruppo di sicurezza predefinito
Se cerchi di creare un cluster e ricevi un errore che indica che non esiste un gruppo di sicurezza predefinito, è possibile che il VPC che stai utilizzando sia stato condiviso con te. Chiedi all'amministratore di concedere l'autorizzazione per descrivere i gruppi di sicurezza in questo VPC e riprova. Per un esempio di una policy che consente questa operazione, consulta [Amazon EC2: consente la gestione dei gruppi di sicurezza EC2 associati a uno specifico VPC, in modo programmatico e nella console ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html).
## I cluster sono bloccati nello stato CREATING
A volte la creazione del cluster può richiedere fino a 30 minuti. Attendi 30 minuti e controlla nuovamente lo stato del cluster.
## Lo stato del cluster passa da CREATING a FAILED
Prova a creare nuovamente il cluster.
## Lo stato del cluster è ACTIVE ma i produttori non possono inviare dati o i consumatori non possono ricevere dati
+ Se la creazione del cluster va a buon fine (lo stato del cluster è `ACTIVE`), ma non è possibile inviare o ricevere dati, assicurati che le applicazioni produttore e consumatore dispongano dell'accesso al cluster. Per ulteriori informazioni, consulta le linee guida in [Passaggio 3: creazione di un computer client](create-client-machine.md).
+ Se i produttori e i consumatori dispongono dell'accesso al cluster ma si verificano ancora problemi nella produzione e nel consumo di dati, è possibile che la causa sia riconducibile a [KAFKA-7697](https://issues.apache.org/jira/browse/KAFKA-7697), che influenza Apache Kafka versione 2.1.0 e può condurre a un deadlock in uno o più broker. Valuta la possibilità di eseguire la migrazione ad Apache Kafka 2.2.1, che non è influenzato da questo bug. Per informazioni sulla migrazione, consulta [Esegui la migrazione dei carichi di lavoro Kafka in un cluster Amazon MSK](migration.md).
## AWS CLI non riconosce Amazon MSK
Se lo hai AWS CLI installato, ma non riconosce i comandi di Amazon MSK, esegui l'upgrade AWS CLI alla versione più recente. Per istruzioni dettagliate su come aggiornare AWS CLI, consulta [Installazione di AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html). Per informazioni su come utilizzare per AWS CLI eseguire i comandi Amazon MSK, consulta[Caratteristiche e concetti chiave di Amazon MSK](operations.md).
## Le partizioni vengono messe offline o le repliche non sono sincronizzate
Questi sintomi possono essere causati da spazio su disco insufficiente. Per informazioni, consulta [Lo spazio su disco è insufficiente](#troubleshooting-lowdiskspace).
## Lo spazio su disco è insufficiente
Vedere le best practice seguenti per gestire lo spazio su disco: [Monitoraggio dello spazio su disco](bestpractices.md#bestpractices-monitor-disk-space) e [Regolazione dei parametri di conservazione dei dati](bestpractices.md#bestpractices-retention-period).
## La memoria è insufficiente
Se il parametro `MemoryUsed` diventa alto o il parametro `MemoryFree` diventa basso, ciò non significa che ci sia un problema. Apache Kafka è progettato per utilizzare e gestire in maniera ottimale la massima quantità di memoria.
## Il produttore ottiene NotLeaderForPartitionException
Questo è spesso un errore temporaneo. Impostare il parametro di configurazione `retries` del produttore su un valore più alto del valore corrente.
## Partizioni sottoreplicate (URP) superiori a zero
Il parametro `UnderReplicatedPartitions` è importante da monitorare. In un cluster MSK integro, il valore di questo parametro è 0. Se è maggiore di zero, il motivo potrebbe essere uno dei seguenti.
+ Se `UnderReplicatedPartitions` presenta un picco, è possibile che non sia stato effettuato il provisioning del cluster alle dimensioni corrette per gestire il traffico in entrata e in uscita. Per informazioni, consulta [Le migliori pratiche per i broker standard](bestpractices.md).
+ Se `UnderReplicatedPartitions` è costantemente maggiore di 0, anche durante i periodi di traffico limitato, il problema potrebbe essere dovuto al fatto che hai impostato delle restrizioni ACLs che non garantiscono l'accesso all'argomento ai broker. Per replicare le partizioni, i broker devono disporre dell'autorizzazione per gli argomenti READ e DESCRIBE. L'argomento DESCRIBE viene concesso per impostazione predefinita con l'autorizzazione READ. Per informazioni sull'impostazione ACLs, consulta [Autorizzazione e ACLs](https://kafka.apache.org/documentation/#security_authz) nella documentazione di Apache Kafka.
## Il cluster ha argomenti chiamati \$1\$1amazon\$1msk\$1canary e \$1\$1amazon\$1msk\$1canary\$1state
Potresti notare che il tuo cluster MSK ha un argomento con il nome `__amazon_msk_canary` e un altro con il nome `__amazon_msk_canary_state`. Si tratta di argomenti interni che Amazon MSK crea e utilizza per i parametri diagnostici e di salute dei cluster. Questi argomenti sono di dimensioni trascurabili e non possono essere eliminati.
## La replica delle partizioni ha esito negativo
Assicurati di non aver impostato ACLs CLUSTER\$1ACTIONS.
## Impossibile accedere al cluster con accesso pubblico attivato
Se il cluster ha attivato l'accesso pubblico, ma non riesci ancora ad accedervi da Internet, esegui i passaggi seguenti:
1. Assicurati che le regole in entrata del gruppo di sicurezza del cluster consentano il tuo indirizzo IP e la porta del cluster. Per un elenco dei numeri di porta del cluster, consulta la pagina [Informazioni sulle porte](port-info.md). Assicurati inoltre che le regole in uscita del gruppo di sicurezza consentano le comunicazioni in uscita. Per ulteriori informazioni sui gruppi di sicurezza e le rispettive regole in entrata e in uscita, consulta la pagina [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella Guida per l'utente di Amazon VPC.
1. Assicurati che il tuo indirizzo IP e la porta del cluster siano consentiti nelle regole in entrata dell'ACL della rete VPC del cluster. A differenza dei gruppi di sicurezza, le reti sono prive di ACLs stato. Ciò significa che è necessario configurarne le regole in entrata e in uscita. Nelle regole in uscita, consenti tutto il traffico (intervallo di porte: 0-65535) verso il tuo indirizzo IP. Per ulteriori informazioni, consulta la pagina [Add and delete rules](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules) nella Guida per l'utente di Amazon VPC.
1. Assicurati di utilizzare la stringa bootstrap-brokers ad accesso pubblico per accedere al cluster. Un cluster MSK con accesso pubblico attivato ha due diverse stringhe bootstrap-brokers, una per l'accesso pubblico e una per l'accesso dall'interno di AWS. Per ulteriori informazioni, consulta [Ottieni i broker bootstrap usando il Console di gestione AWS](get-bootstrap-console.md).
## Impossibile accedere al cluster tramite bootstrap IPv6
Se hai problemi a connetterti a un cluster utilizzando le stringhe di IPv6 bootstrap fornite, segui questi passaggi:
1. Assicurati che al tuo client siano assegnati sia gli indirizzi IPv4 che IPv6. L'applicazione client deve essere in esecuzione in una sottorete con indirizzi IPv4 e IPv6 abilitati e configurati correttamente. Verifica se il tuo VPC ha sia il blocco CIDR IPv4 che un blocco CIDR IPv6 associato, conferma che la sottorete abbia entrambi gli indirizzi IPv4 e IPv6 abilitati e verifica che l'istanza EC2 o l'ambiente client abbiano entrambi gli indirizzi assegnati. IPv4 IPv6 Per ulteriori informazioni, consulta la sezione [Indirizzamento IP per le tue sottoreti VPCs e subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) nella Amazon VPC User Guide.
1. Assicurati che le IPv6 porte pertinenti siano presenti nelle regole in entrata e in uscita del gruppo di sicurezza. Aggiungi regole in entrata per consentire il traffico sulle porte del cluster dai tuoi IPv6 indirizzi e configura le regole in uscita per consentire il traffico. IPv6 Per numeri di porta specifici, consultate [Informazioni sulle porte](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html) nella documentazione MSK. Ricordatevi di aggiornare sia le regole che IPv4 le IPv6 regole se eseguite in modalità dual-stack. Per ulteriori informazioni sui gruppi di sicurezza e le rispettive regole in entrata e in uscita, consulta la pagina [Security groups for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) nella Guida per l'utente di Amazon VPC.
1. Assicurati che la configurazione delle proprietà JVM sia corretta per il supporto. IPv6 Nell'applicazione client, imposta su `true` e `java.net.preferIPv6Addresses` `java.net.preferIPv4Stack` su. `false` Queste impostazioni possono essere configurate come proprietà di sistema o argomenti JVM. Riavvia l'applicazione dopo aver apportato queste modifiche per renderle effettive.
## Impossibile accedere al cluster dall'interno AWS: problemi di rete
Se disponi di un'applicazione Apache Kafka che non è in grado di comunicare correttamente con un cluster MSK, inizia eseguendo il seguente test di connettività.
1. Utilizzare uno dei metodi descritti in [Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md) per ottenere gli indirizzi dei broker bootstrap.
1. Nel comando seguente *bootstrap-broker* sostituiscilo con uno degli indirizzi del broker che hai ottenuto nel passaggio precedente. Sostituire *port-number* con 9094 se il cluster è configurato per utilizzare l'autenticazione TLS. Se il cluster non utilizza l'autenticazione TLS, *port-number* sostituiscila con 9092. Eseguire il comando dal computer client.
```
telnet bootstrap-broker port-number
```
Dove il numero di porta è:
+ 9094 se il cluster è configurato per utilizzare l'autenticazione TLS.
+ 9092 Se il cluster non utilizza l'autenticazione TLS.
+ È necessario un numero di porta diverso se l'accesso pubblico è abilitato.
Eseguire il comando dal computer client.
1. Ripetere il comando precedente per tutti i broker bootstrap.
Se la macchina client è in grado di accedere ai broker, significa che non ci sono problemi di connettività. In questo caso, eseguire il comando seguente per verificare se il client Apache Kafka è configurato correttamente. Per ottenerlo*bootstrap-brokers*, usa uno dei metodi descritti in[Ottieni i broker bootstrap per un cluster Amazon MSK](msk-get-bootstrap-brokers.md). Sostituiscilo *topic* con il nome del tuo argomento.
```
/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```
Se il comando precedente va a buon fine, significa che il client è configurato correttamente. Se non è ancora possibile produrre e consumare da un'applicazione, eseguire il debug del problema a livello di applicazione.
Se il computer client non è in grado di accedere ai broker, consulta le seguenti sottosezioni per una guida basata sulla configurazione del computer client.
### Client Amazon EC2 e cluster MSK nello stesso VPC
Se il computer client si trova nello stesso VPC del cluster MSK, assicurati che il gruppo di sicurezza del cluster disponga di una regola in entrata che accetta il traffico dal gruppo di sicurezza del computer client. Per informazioni sull'impostazione di queste regole, consulta [Regole del gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules). Per un esempio di come accedere a un cluster da un'istanza Amazon EC2 che si trova nello stesso VPC del cluster, consulta la pagina [Inizia a usare Amazon MSK](getting-started.md).
### Client Amazon EC2 e cluster MSK in diversi VPCs
Se il computer client e il cluster si trovano in due ambienti diversi VPCs, verifica quanto segue:
+ I due VPCs sono peer-to-peer.
+ Lo stato della connessione peering è attivo.
+ Le tabelle dei percorsi delle due VPCs sono impostate correttamente.
Per informazioni sul peering VPC, consulta [Utilizzo di connessioni peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html).
### Client locale
Nel caso di un client locale configurato per connettersi al cluster MSK utilizzando Site-to-Site VPN, assicurati quanto segue:
+ Lo stato della connessione VPN è `UP`. Per informazioni su come verificare lo stato della connessione VPN, consulta [How do I check the current status of my VPN tunnel?](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/).
+ La tabella di routing del VPC del cluster contiene la route per un CIDR locale la cui destinazione ha il formato `Virtual private gateway(vgw-xxxxxxxx)`.
+ Il gruppo di sicurezza del cluster MSK consente il traffico sulla porta 2181, sulla porta 9092 (se il cluster accetta traffico non crittografato) e sulla porta 9094 (se il cluster accetta traffico crittografato TLS).
Per ulteriori indicazioni Site-to-Site VPN sulla risoluzione dei problemi, consulta [Troubleshooting Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html).
### Direct Connect
Se il client utilizza Direct Connect, consulta [Risoluzione dei problemi Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html).
Se le linee guida per risoluzione dei problemi precedenti non consentono di risolvere il problema, assicurarsi che il traffico di rete non sia bloccato da un firewall. Per ulteriori operazioni di debug, utilizza strumenti come `tcpdump` e `Wireshark` per analizzare il traffico e assicurarti che raggiunga il cluster MSK.
## Autenticazione non riuscita: troppe connessioni
L'errore `Failed authentication ... Too many connects` indica che un broker si sta proteggendo perché uno o più client IAM stanno tentando di connettersi ad esso a una velocità aggressiva. Per aiutare i broker ad accettare nuove connessioni IAM a una velocità più elevata, puoi aumentare il parametro di configurazione [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms).
Per ulteriori informazioni sui limiti di velocità per le nuove connessioni per broker, consulta la pagina [Quota di Amazon MSK](limits.md).
## Autenticazione fallita: sessione troppo breve
L'`Failed authentication ... Session too short`errore si verifica quando il client tenta di connettersi a un cluster utilizzando credenziali IAM che stanno per scadere. Assicurati di controllare come vengono aggiornate le tue credenziali IAM. Molto probabilmente, le credenziali vengono sostituite troppo vicino alla scadenza della sessione, il che comporta problemi sul lato server e errori di autenticazione.
## MSK Serverless: la creazione del cluster ha esito negativo
Se si tenta di creare un cluster MSK Serverless e il flusso di lavoro ha esito negativo, è possibile che non si disponga dell'autorizzazione per creare un endpoint VPC. Verifica che l'amministratore ti abbia concesso l'autorizzazione a creare un endpoint VPC consentendo l'operazione `ec2:CreateVpcEndpoint`.
Per un elenco completo delle autorizzazioni necessarie per eseguire tutte le operazioni di Amazon MSK, consulta la pagina [AWS politica gestita: Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md).
## Impossibile eseguire l'aggiornamento KafkaVersionsList nella configurazione MSK
Quando si aggiorna la [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist)proprietà nella [AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html)risorsa, l'aggiornamento ha esito negativo e viene visualizzato il seguente errore.
```
Resource of type 'AWS::MSK::Configuration' with identifier '' already exists.
```
Quando si aggiorna la `KafkaVersionsList` proprietà, AWS CloudFormation ricrea una nuova configurazione con la proprietà aggiornata prima di eliminare la configurazione precedente. L'aggiornamento CloudFormation dello stack non riesce perché la nuova configurazione utilizza lo stesso nome della configurazione esistente. Tale aggiornamento richiede la [sostituzione di una risorsa](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement). Per eseguire correttamente l'aggiornamento`KafkaVersionsList`, è necessario aggiornare anche la proprietà [Name](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) nella stessa operazione.
Inoltre, se la configurazione è associata a qualsiasi cluster creato utilizzando Console di gestione AWS o AWS CLI, aggiungete quanto segue alla risorsa di configurazione per evitare [tentativi falliti di eliminazione delle risorse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted).
```
UpdateReplacePolicy: Retain
```
Una volta completato l'aggiornamento, vai alla console Amazon MSK ed elimina la vecchia configurazione. Per informazioni sulle configurazioni MSK, consulta [Configurazione Amazon MSK Provisioned](msk-configuration.md).