How to manage full disks in Kafka - E-MapReduce - Centre de documentation Alibaba Cloud

Cette rubrique explique comment procéder lorsque l'espace disque d'un cluster Kafka est saturé. Les exemples présentés utilisent la version 2.4.1 d'EMR Kafka.

Scénario métier

Kafka stocke les données de journalisation sur le disque. Si l'espace disque vient à manquer, le répertoire de logs Kafka correspondant passe hors ligne. Il devient alors impossible de lire ou d'écrire dans les réplicas de partition situés sur ce disque, ce qui réduit la disponibilité et la tolérance aux pannes des partitions. La charge des autres brokers augmente car le réplica leader de la partition est migré vers d'autres nœuds. Il est donc impératif de résoudre ce problème dès que possible.

Vue d'ensemble

Cette rubrique présente les stratégies de maintenance applicables en cas de saturation du disque d'un cluster Kafka, sous deux angles : la surveillance et la récupération après incident.

Surveiller un disque saturé

Service Kafka : configurez des règles d'alerte pour la métrique OfflineLogDirectoryCount des clusters EMR Kafka dans la console CloudMonitor afin de détecter en temps réel les répertoires de logs hors ligne.

Récupérer un disque saturé

Si le répertoire de logs Kafka d'un disque passe hors ligne, commencez par vérifier si l'espace disque est effectivement saturé.

Lorsque l'espace disque d'un répertoire de logs est épuisé, envisagez les stratégies de maintenance suivantes :

Redimensionnement du disque : augmentez la capacité du disque cloud. Cette méthode convient aux scénarios où les brokers utilisent des disques cloud attachés. Pour plus d'informations, consultez la section Récupération par redimensionnement du disque.
Migration intra-nœud des partitions : déplacez les partitions d'un disque saturé vers d'autres disques du même nœud. Cette approche est adaptée aux situations où l'utilisation du disque est déséquilibrée sur un nœud broker. Pour plus de détails, voir Récupération par migration intra-nœud des partitions.
Nettoyage des données : supprimez les données de journalisation du disque saturé. Cette méthode s'applique lorsque les anciennes données peuvent être supprimées en toute sécurité. Consultez la section Récupération par nettoyage des données pour en savoir plus.

Redimensionner un disque

Description

Si l'espace d'un disque est saturé sur un broker, augmentez sa capacité via cette stratégie pour répondre aux besoins opérationnels. Ses avantages résident dans la simplicité de mise en œuvre, les risques limités et la rapidité de résolution du problème de manque d'espace.

Scénario

Cette stratégie s'applique aux scénarios où des disques sont attachés à un broker.

Procédure

Redimensionnez les disques de données des nœuds broker dans la console E-MapReduce. Pour plus d'informations, reportez-vous à la rubrique Redimensionner un disque.

Migrer des partitions au sein d'un broker

Description

Si l'espace d'un disque est saturé sur un broker, le répertoire de logs Kafka associé passe hors ligne. L'outil kafka-reassign-partitions.sh ne peut alors plus être utilisé pour migrer les partitions. Dans ce cas, intervenez directement sur l'instance Elastic Compute Service (ECS) hébergeant le broker : déplacez les données des réplicas de partition vers d'autres disques du broker et modifiez les métadonnées dans le répertoire de données Kafka correspondant. Cette opération permet de résoudre le problème de manque d'espace disque.

Scénario

Cette stratégie convient aux situations où l'utilisation du disque est déséquilibrée sur un broker, avec un disque saturé coexistant avec d'autres disques faiblement utilisés.

Remarques d'utilisation

Cette méthode prend uniquement en charge la migration de partitions entre disques situés sur le même nœud.
La migration de partitions peut générer des points chauds d'E/S sur les disques, affectant ainsi les performances du cluster. Évaluez l'impact du volume de données et de la durée de chaque migration sur vos services.
Comme cette méthode implique des opérations non standard, testez-la préalablement sur la version de Kafka correspondante avant de l'appliquer à un cluster de production.

Procédure

En cas de saturation du disque, le répertoire de logs Kafka concerné passe hors ligne, rendant l'outil kafka-reassign-partitions.sh inutilisable pour la migration des partitions. Cette section décrit comment effectuer des opérations non standard pour migrer les partitions en déplaçant directement les fichiers et en modifiant les métadonnées liées à Kafka.

Créez un topic de test.
1. Connectez-vous au nœud maître du cluster Kafka source via SSH. Pour plus d'informations, consultez la rubrique Se connecter à un cluster.
2. Exécutez la commande suivante pour créer un topic de test. Les réplicas de partition sont répartis sur le broker 0 et le broker 1.
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --replica-assignment 0:1 --create
```
  Exécutez la commande suivante pour afficher les détails du topic.
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
```
  Les informations renvoyées indiquent que le broker 0 figure dans la liste des réplicas synchronisés (ISR).
```
Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
        Topic: test-topic       Partition: 0    Leader: 0       Replicas: 0,1   ISR: 0,1
```

Exécutez la commande suivante pour simuler l'écriture de données.

kafka-producer-perf-test.sh --topic test-topic --record-size 1000 --num-records 600000000 --print-metrics --throughput 10240 --producer-props linger.ms=0 bootstrap.servers=core-1-1:9092

Modifiez les permissions du répertoire de logs sur le broker 0.
1. Sur le nœud maître, basculez vers le compte emr-user.
```
su emr-user
```
2. Connectez-vous au nœud core correspondant sans mot de passe.
```
ssh core-1-1
```
3. Obtenez les privilèges root via sudo.
```
sudo su - root
```
4. Exécutez la commande suivante pour identifier le disque sur lequel se trouve la partition.
```
sudo find / -name test-topic-0
```
  La réponse ci-dessous indique que la partition se trouve dans le répertoire /mnt/disk4/kafka/log.
```
/mnt/disk4/kafka/log/test-topic-0
```
5. Exécutez la commande suivante pour définir les permissions du répertoire de logs sur le broker 0 à 000. Cela simule une erreur de disque rendant le répertoire inaccessible en écriture.
```
sudo chmod 000 /mnt/disk4/kafka/log
```
6. Exécutez la commande suivante pour vérifier l'état de test-topic.
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
```
  Les informations renvoyées montrent que le broker 0 ne figure plus dans la liste ISR.
```
Topic: test-topic       PartitionCount: 1       ReplicationFactor: 2    Configs:
        Topic: test-topic       Partition: 0    Leader: 1       Replicas: 0,1   ISR: 1
```
Arrêtez le service Kafka sur le broker 0.

Arrêtez le service Kafka sur le Broker 0 dans la console EMR.
Exécutez la commande suivante pour déplacer la partition de test-topic située sur le broker 0 vers un autre disque du même nœud.
```
mv /mnt/disk4/kafka/log/test-topic-0 /mnt/disk1/kafka/log/
```
Modifiez les fichiers de métadonnées.

En vous basant sur les fichiers de métadonnées présents dans le répertoire source /mnt/disk4/kafka/log et dans le répertoire de destination /mnt/disk1/kafka/log, les fichiers à modifier incluent replication-offset-checkpoint et recovery-point-offset-checkpoint.
- Modifiez le fichier replication-offset-checkpoint en déplaçant les entrées relatives à test-topic depuis le fichier replication-offset-checkpoint du répertoire de logs d'origine vers le fichier replication-offset-checkpoint du répertoire de logs cible, puis ajustez le nombre total d'entrées. Dans le fichier replication-offset-checkpoint modifié, la première ligne « 0 » correspond au numéro de version, la deuxième ligne « 18 » indique le nombre total d'entrées (ce chiffre doit correspondre au nombre réel de lignes d'entrées), et la dernière ligne « test-topic 0 4901378 » représente l'enregistrement d'offset de la partition migrée. Exemple de contenu :
```
0
18
__consumer_offsets 22 0
__consumer_offsets 8 0
__consumer_offsets 21 0
__consumer_offsets 9 0
__consumer_offsets 35 0
__consumer_offsets 33 0
__consumer_offsets 23 0
__consumer_offsets 47 0
__consumer_offsets 2 0
__consumer_offsets 14 0
__consumer_offsets 45 0
__consumer_offsets 10 0
__consumer_offsets 4 0
__consumer_offsets 17 0
__consumer_offsets 30 0
__consumer_offsets 36 0
__consumer_offsets 48 0
test-topic 0 4901378
```
- Modifiez le fichier recovery-point-offset-checkpoint. Déplacez les entrées pour test-topic depuis le fichier recovery-point-offset-checkpoint du répertoire de logs d'origine vers le fichier recovery-point-offset-checkpoint du répertoire de logs de destination, puis mettez à jour le nombre total d'entrées dans le fichier de destination. Voici un exemple du fichier recovery-point-offset-checkpoint modifié. Dans cet exemple, 13 sur la deuxième ligne représente le nombre total d'entrées, et test-topic 0 4952628 correspond à l'entrée migrée pour test-topic :
```
0
13
__consumer_offsets 22 0
__consumer_offsets 8 0
__consumer_offsets 21 0
__consumer_offsets 9 0
__consumer_offsets 35 0
__consumer_offsets 33 0
__consumer_offsets 23 0
__consumer_offsets 47 0
__consumer_offsets 2 0
__consumer_offsets 14 0
test-topic 0 4952628
__consumer_offsets 45 0
__consumer_offsets 10 0
```
Exécutez la commande suivante pour restaurer les permissions correctes du répertoire de logs sur le broker 0 source.
```
sudo chmod 755 /mnt/disk4/kafka/log
```
Démarrez le service Kafka sur le broker 0.

Démarrez le service Kafka sur le Broker 0 dans la console EMR.
Exécutez la commande suivante pour vérifier que l'état du cluster est normal.
```
kafka-topics.sh --bootstrap-server core-1-1:9092 --topic test-topic --describe
```

Nettoyer les logs

Description

Si l'espace d'un disque est saturé sur un broker, supprimez les données de logs métier dans l'ordre chronologique, des plus anciennes aux plus récentes, jusqu'à libérer suffisamment d'espace disque. Il est interdit de supprimer les données des topics internes d'un cluster Kafka.

Scénario

Cette stratégie s'applique aux scénarios où il est possible de supprimer des données de logs métier obsolètes d'un disque saturé.

Si la période de rétention des données reste inchangée, le disque risque d'être à nouveau saturé rapidement. Par conséquent, cette stratégie convient généralement aux situations où une augmentation soudaine du volume de données survient en raison de circonstances exceptionnelles.

Remarques d'utilisation

Vous ne pouvez pas supprimer les données des topics dont le nom commence par un tiret bas (_).

Procédure

Connectez-vous à la machine concernée.
Identifiez le disque saturé et supprimez les données métier inutiles.
Respectez les principes suivants lors du nettoyage des données :
- Ne supprimez pas directement les répertoires de données de Kafka afin d'éviter toute perte de données involontaire.
- Repérez les topics consommant beaucoup d'espace ou devenus inutiles. Pour les partitions sélectionnées au sein de ces topics, commencez par supprimer les segments de logs les plus anciens. Cela inclut la suppression des fichiers .log, .index et .timeindex pour chaque segment. Ne supprimez pas les données des topics internes, tels que __consumer_offsets et _schema.
Redémarrez le service Kafka sur le broker concerné pour remettre le répertoire de logs en ligne.