Eseguire la migrazione di carichi di lavoro di Apache Kafka ad Azure HDInsight 4.0

  • Articolo

Azure HDInsight 4.0 offre i componenti open source più recenti con miglioramenti significativi in termini di prestazioni, connettività e sicurezza. Questo documento illustra come eseguire la migrazione di carichi di lavoro Apache Kafka in HDInsight 3.6 a HDInsight 4.0. Dopo la migrazione dei carichi di lavoro a HDInsight 4.0, è possibile usare molte delle nuove funzionalità non disponibili in HDInsight 3.6.

Percorsi di migrazione kafka di HDInsight 3.6

HDInsight 3.6 supporta due versioni di Kafka: 1.0.0 e 1.1.0. HDInsight 4.0 supporta le versioni 1.1.0 e 2.1.0. A seconda della versione di Kafka e della versione di HDInsight da eseguire, sono disponibili più percorsi di migrazione supportati. Questi percorsi sono illustrati di seguito e illustrati nel diagramma seguente.

  • Eseguire sia Kafka che HDInsight nelle versioni più recenti (scelta consigliata): eseguire la migrazione di un'applicazione HDInsight 3.6 e Kafka 1.0.0 o 1.1.0 a HDInsight 4.0 con Kafka 2.1.0 (percorsi D e E seguenti).
  • Eseguire HDInsight nella versione più recente, ma Kafka solo in una versione più recente: eseguire la migrazione di un'applicazione HDInsight 3.6 e Kafka 1.0.0 a HDInsight 4.0 con Kafka 1.1.0 (percorso B seguente).
  • Eseguire HDInsight nella versione più recente, mantenere la versione kafka: eseguire la migrazione di un'applicazione HDInsight 3.6 e Kafka 1.1.0 a HDInsight 4.0 con Kafka 1.1.0 (percorso C riportato di seguito).
  • Eseguire Kafka in una versione più recente, mantenere la versione di HDInsight: eseguire la migrazione di un'applicazione Kafka 1.0.0 alla versione 1.1.0 e rimanere in HDInsight 3.6 (percorso A riportato di seguito). Si noti che questa opzione richiede comunque la distribuzione di un nuovo cluster. L'aggiornamento della versione kafka in un cluster esistente non è supportato. Dopo aver creato un cluster con la versione desiderata, eseguire la migrazione dei client Kafka per usare il nuovo cluster.

Upgrade paths for Apache Kafka on 3.6.

Versioni di Apache Kafka

Kafka 1.1.0

Se si esegue la migrazione da Kafka 1.0.0 a 1.1.0, è possibile sfruttare le nuove funzionalità seguenti:

  • Miglioramenti al controller Kafka accelerano l'arresto controllato, in modo da poter riavviare i broker e recuperare da problemi più velocemente.
  • Miglioramenti nella logica FetchRequests che consentono di avere più partizioni (e quindi altri argomenti) nel cluster.
  • Kafka Connessione supporta intestazioni di record ed espressioni regolari per gli argomenti.

Per un elenco completo degli aggiornamenti, vedere Le note sulla versione di Apache Kafka 1.1.

Apache Kafka 2.1.0

Se si esegue la migrazione a Kafka 2.1, è possibile sfruttare le funzionalità seguenti:

  • Migliore resilienza del broker grazie a un protocollo di replica migliorato.
  • Nuove funzionalità nell'API Kafka Amministrazione Client.
  • Gestione delle quote configurabili.
  • Supporto per la compressione Zstandard.

Per un elenco completo degli aggiornamenti, vedere Note sulla versione di Apache Kafka 2.0 e note sulla versione di Apache Kafka 2.1.

Compatibilità del client Kafka

I nuovi broker Kafka supportano i client meno recenti. KIP-35 - La versione del protocollo di recupero ha introdotto un meccanismo per determinare in modo dinamico la funzionalità di un broker Kafka e kip-97: i criteri di compatibilità RPC del client Kafka migliorati hanno introdotto nuovi criteri di compatibilità e garanzie per il client Java. In precedenza, un client Kafka doveva interagire con un broker della stessa versione o una versione più recente. A questo punto, le versioni più recenti dei client Java e di altri client che supportano KIP-35, librdkafka ad esempio, possono eseguire il fallback ai tipi di richiesta meno recenti o generare errori appropriati se la funzionalità non è disponibile.

Upgrade Kafka client compatibility.

Si noti che non significa che il client supporta broker meno recenti. Per altre informazioni, vedere Matrice di compatibilità.

Processo di migrazione generale

Le indicazioni seguenti sulla migrazione presuppongono che un cluster Apache Kafka 1.0.0 o 1.1.0 distribuito in HDInsight 3.6 in una singola rete virtuale. Il broker esistente ha alcuni argomenti e viene usato attivamente dai produttori e dai consumatori.

Current Kafka presumed environment.

Per completare la migrazione, seguire questa procedura:

  1. Distribuire un nuovo cluster e client HDInsight 4.0 per il test. Distribuire un nuovo cluster Kafka di HDInsight 4.0. Se è possibile selezionare più versioni del cluster Kafka, è consigliabile selezionare la versione più recente. Dopo la distribuzione, impostare alcuni parametri in base alle esigenze e creare un argomento con lo stesso nome dell'ambiente esistente. Impostare anche la crittografia TLS e BYOK (Bring Your Own Key) in base alle esigenze. Controllare quindi se funziona correttamente con il nuovo cluster.

    Deploy new HDInsight 4.0 clusters.

  2. Cambiare il cluster per l'applicazione producer e attendere che tutti i dati della coda vengano utilizzati dai consumer correnti. Quando il nuovo cluster Kafka di HDInsight 4.0 è pronto, passare la destinazione producer esistente al nuovo cluster. Lasciarlo invariato fino a quando l'app consumer esistente non ha utilizzato tutti i dati del cluster esistente.

    Switch cluster for producer app.

  3. Cambiare il cluster nell'applicazione consumer. Dopo aver verificato che l'applicazione consumer esistente abbia terminato di utilizzare tutti i dati del cluster esistente, passare alla connessione al nuovo cluster.

    Switch cluster on consumer app.

  4. Rimuovere il cluster precedente e testare le applicazioni in base alle esigenze. Al termine e al corretto funzionamento dell'opzione, rimuovere il vecchio cluster Kafka HDInsight 3.6 e i produttori e i consumer usati nel test in base alle esigenze.

Passaggi successivi