J'essaie d'exécuter Kafka avec un volume NFS monté, face à une exception et je ne peux pas démarrer Kafka:
ls -la /opt/data/kf-data/.snapshot total 80 drwxrwxrwx 33 root root 12288 Mar 28 00:10 . drwx------ 2 root domain^users 4096 Feb 21 19:20 .. drwx------ 2 root domain^users 4096 Feb 13 11:06 daily.2020-02-14_0010 drwx------ 2 root domain^users 4096 Feb 13 11:06 daily.2020-02-15_0010 drwx------ 2 root domain^users 4096 Feb 13 11:06 daily.2020-02-16_0010 drwx------ 2 root domain^users 4096 Feb 13 11:06 daily.2020-02-17_0010 drwx------ 2 root domain^users 4096 Feb 21 19:20 snapmirror.ka938443-8ea1-22e8-6608-00a067d1a20a_2148891236.2020-02-27_180700
Voici mes scripts docker-compose:
zookeeper:
image: confluentinc/cp-zookeeper:5.3.2
environment:
ZOOKEEPER_CLIENT_PORT: 2181
volumes:
- zk-data:/var/lib/zookeeper/data:nocopy
- zk-log:/var/lib/zookeeper/log:nocopy
kafka:
image: confluentinc/cp-kafka:5.3.2
environment:
KAFKA_ADVERTISED_HOST_NAME: kafka
KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092
KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT
KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
volumes:
- kf-data:/var/lib/kafka/data:nocopy
volumes:
zk-data:
driver: local
driver_opts:
type: "nfs"
o: addr=18.0.3.227 #IP of NFS
device: ":/opt/data/zk-data"
zk-log:
driver: local
driver_opts:
type: "nfs"
o: addr=18.0.3.227
device: ":/opt/data/zk-log"
kf-data:
driver: local
driver_opts:
type: "nfs"
o: addr=18.0.3.227
device: ":/opt/data/kf-data"
3 Réponses :
Il existe un dossier caché nommé .snapshot, ce dossier est généré automatiquement par NFS et ne peut pas être supprimé
Eh bien, s'il n'y a pas moyen de contourner cela, alors Kafka ne pourra pas commencer, point final.
À ma connaissance, nulle part dans la documentation ne dit-on que le stockage attaché à distance est pris en charge.
Il est possible d'utiliser un volume externe à distance, bien sûr, c'est une mauvaise façon et non recommandée. À partir de ce lien, sbg.technology/2018/07/10/kafka-nfs Ils utilisaient auparavant le volume NFS.
D'accord, mais quel logiciel de serveur NFS ont-ils utilisé? Clairement, il n'a pas généré ces fichiers instantanés
enfin, je savais que nous utilisons NetApp pour le serveur NFS. mais la solution ici désactiver l'accès dans NetApp est une fonction vFilter globale, qui n'est pas une fonction par dossier ou par partage. Cette solution a donc été refusée par notre support informatique.
Si vous utilisez NetApp comme plate-forme NFS, ces informations peuvent vous aider: désactiver L'accès au .snapshot dans NetApp est une fonction vFilter globale, qui n'est pas une fonction par dossier ou par partage.
Si vous ne pouvez pas désactiver l'accès à .snapshot, il n'y a pas de solution, sauf si vous utilisez d'autres plates-formes NFS, qui ne généreront pas de dossier .snapshot dans chaque dossier.
Comme indiqué ci-dessus, Kafka sur NFS est une solution défectueuse en raison du fonctionnement du système de fichiers NFS. Vous rencontrerez des problèmes de repartitionnement et d'extension. Cela a à voir avec la façon dont NFS gère la suppression des fichiers ouverts - comportement de changement de nom idiot. Vous pouvez en savoir plus dans ce billet de blog ( Kafka sur NFS ).
Avez-vous essayé de créer un dossier sur NFS et de l'utiliser à la place comme répertoire de données Kafka?
@Zsolt le répertoire de données dans NFS était toujours créé manuellement. le répertoire .snapshot a été généré à chaque fois par NFS lorsque je crée un nouveau répertoire.
Il semble que vous puissiez masquer le répertoire des instantanés des clients NFS, mais il s'agit d'un paramètre côté serveur NFS par volume, ici est une mention de cela dans la base de connaissances NetApp, ressemble au paramètre exact devrait dépendre du type de serveur NFS que vous utilisez.
C'est une manière fortement déconseillée d'exécuter Kafka, btw. Il préfère les disques rotatifs, pas les volumes réseau
@Zsolt Merci pour le lien, je peux peut-être essayer de désactiver l'accès à l'instantané. Je vais demander aux autres gars qui gèrent le serveur NFS.
@ cricket_007 Oui, je suis totalement d'accord avec vous, que les volumes réseau ne doivent pas être utilisés pour Kafka. Mais ... c'est la décision de la direction.
Votre direction comprend-elle des architectes logiciels qui ont déjà utilisé / installé Kafka avec succès auparavant? Vos courtiers fonctionnent sur des machines avec un système d'exploitation local, n'est-ce pas? Qu'est-ce qui vous empêche de monter des disques physiques et rotatifs sur ces serveurs?
@ cricket_007 en raison d'une sorte de politique de sécurité de la direction, nous devons conserver toutes les données "devraient être persistantes" telles que le journal de la base de données MySQL, le journal Kafka sur le serveur NFS distant. il faut danser sur un bouchon de bouteille, sans choix.
D'accord, très bien. Ensuite, vous devez utiliser un fournisseur NFS qui ne crée pas ces répertoires d'instantanés. Comme répondu, ce n'est possible avec votre solution actuelle que si vous avez un montage de répertoire propre. Même dans le blog que vous avez publié, il est clairement indiqué que les sujets et les fichiers ne peuvent pas être supprimés sans planter Kafka (ce qui signifie essentiellement que vous avez un répertoire de stockage en croissance infinie)