Conseils de pro pour déboguer MinIO : surmonter les problèmes courants dans les environnements Kubernetes et Bare Metal

Les déploiements MinIO sont de toutes formes et tailles. Nous prenons en charge les installations nues sur n'importe quelle version de Linux , les installations conteneurisées sur n'importe quelle version de Kubernetes (y compris Red Hat OpenShift) et nous installons à peu près partout où vous pouvez déployer un petit binaire unique et léger. Mais avec la flexibilité, il est inévitable que les problèmes extrêmes nécessitent un débogage.

Dans cet article de blog, nous allons vous montrer comment déboguer une installation MinIO exécutée dans Kubernetes, ainsi que certains des problèmes courants que vous pourriez rencontrer lors d'une installation sans système d'exploitation et comment les corriger.

Pod de débogueur Kubernetes

Il existe plusieurs façons d'accéder à l'API MinIO exécutée dans un cluster Kubernetes. Nous pouvons utiliser kubectl port-forwarding ou mettre en place un Service d'écoute sur NodePort pour pouvoir accéder à l'API. Ces deux méthodes offrent un moyen d'accéder au service depuis l'extérieur du réseau, mais elles présentent un inconvénient majeur : vous ne pouvez accéder au service que le NodePort ou le Port Forwarding référence sur un port disponible (pas la configuration habituelle de l'application). ). Par exemple, vous devez accéder à l'API MinIO, généralement présente sur le port 9000 , via un port 3xxxx attribué aléatoirement.

Et si je vous disais qu'il existe une meilleure solution – et que ce n'est pas nouveau ? Lors du débogage d'applications, vous souhaitez avoir un accès complet à l'environnement d'exécution natif afin de pouvoir utiliser divers outils pour dépanner et déboguer le cluster. Une façon d'y parvenir consiste à lancer un pod de style «busybox» et à installer tous les outils requis pour déboguer l'application.

Lancez d’abord un Pod dans le même espace de noms que votre installation MinIO. Pour ce faire, créez un fichier yaml appelé debugger-pod.yaml avec le yaml suivant.

 apiVersion: v1 kind: Pod metadata: name: mc labels: app: mc spec: containers: - image: minio/mc:latest command: - "sleep" - "604800" imagePullPolicy: IfNotPresent name: mc restartPolicy: Always

La configuration du Pod ci-dessus extrait l'image pour l'utilitaire MinIO mc . Afin de garantir que le pod ne se contente pas de se lancer puis de se fermer, nous avons ajouté une commande sleep .

Une fois le yaml enregistré, appliquez la configuration à l'espace de noms Kubernetes où le cluster MinIO est exécuté

kubectl apply -f debugger-pod.yaml

Une fois le pod opérationnel, accédez-y via le shell

 $ kubectl exec -i -t -n default mc -c mc -- sh -c "(bash || ash || sh)" [root@mc /]#

Ensuite avec mc vous pouvez accéder au cluster MinIO

 [root@mc /]# mc alias set myminio --insecure Added `myminio` successfully.

Maintenant que nous avons un module de débogueur opérationnel, vous pouvez effectuer une action sur le cluster directement au sein du même réseau. Par exemple, si la réplication a été interrompue en raison de la mise hors ligne d'un site ou d'une panne matérielle, vous pouvez resynchroniser tous les objets en attente à répliquer à l'aide de la commande suivante

 [root@mc /]# mc admin replicate resync start minio1 minio2 [root@mc /]# mc admin replicate resync status minio1 minio2 ✔ ✔ ✔ ResyncID: 2248d1d1-633f-4d61-b938-d8ea0b9b2d31 Status: Completed Objects: 2225 Versions: 2225 FailedObjects: 0 Throughput: 5.3 MiB/s IOPs: 124.23 objs/s Transferred: 94 MiB Elapsed: 17.909833202s CurrObjName: testbucket/web-app/tsconfig.json

Une autre raison pour laquelle vous exécuteriez le pod du débogueur est que s'il existe des autorisations de système de fichiers ou des configurations de groupes non valides dans votre pod, vous pouvez les mettre à jour à l'aide du pod du débogueur.

 [root@mc /]# chgrp -R 1000780050 .minio.sys/

La méthode de débogage ci-dessus peut également être utilisée dans des environnements nus. Par exemple, vous pouvez lancer un nœud Busybox ou Bastion avec mc installé et suivre les mêmes instructions que ci-dessus.

Débogage du métal nu

Les installations Linux nues sont les plus simples. En fait, il suffit de quelques commandes pour installer et exécuter MinIO avec SystemD. Pour plus de détails, veuillez consulter Configuration de MinIO avec SystemD .

De temps en temps, les installations nues tournent mal. Voici quelques-uns des pièges (pas si courants) sur lesquels nous sommes interrogés dans SOUS-RÉSEAU ou Mou . Ces pièges ne sont pas spécifiques au matériel ou au fonctionnement, mais peuvent être utiles à connaître dans tout type d'environnement.

Autorisation de fichier

L'un des pièges les plus courants concerne les autorisations de fichiers du binaire MinIO et du fichier de configuration. Si cela se produit, lorsque vous démarrez MinIO à l'aide de SystemD, vous verrez

Assertion failed for MinIO. et voici la trace complète de la pile

 # systemctl status minio.service ● minio.service - MinIO Loaded: loaded (/etc/systemd/system/minio.service; enabled; vendor preset: enabled) Active: inactive (dead) Assert: start assertion failed at Tue 2023-12-26 18:21:38 PST; 8s ago AssertFileIsExecutable=/usr/local/bin/minio was not met Docs: https://docs.min.io Dec 26 18:13:37 minio1 systemd[1]: minio.service: Starting requested but asserts failed. Dec 26 18:17:50 minio1 systemd[1]: Assertion failed for MinIO. Dec 26 18:21:38 minio1 systemd[1]: minio.service: Starting requested but asserts failed. Dec 26 18:21:38 minio1 systemd[1]: Assertion failed for MinIO.

Cela peut être dû à un certain nombre de raisons, parcourons la liste et vérifions chacune d'entre elles.

Binaire MinIO : le binaire, dans cet exemple situé dans /usr/local/bin/minio doit avoir l'autorisation root:root pour l'utilisateur et le groupe, respectivement.

 # ll /usr/local/bin/minio total 93804 -rwxr-xr-x 1 root root 96018432 Nov 15 16:35 minio*

Utilisateur et groupe du service MinIO : le service MinIO doit être exécuté sous un utilisateur et un groupe Linux uniques pour des raisons de sécurité, jamais exécuté en tant qu'utilisateur root . Par défaut, nous utilisons minio-user pour les noms d'utilisateur et de groupe. Dans le fichier de configuration du service SystemD, vous devriez voir quelque chose comme ceci

 User=minio-user Group=minio-user

MinIO Data Dir : Le répertoire dans lequel les données MinIO seront stockées doit appartenir à minio-user:minio-user ou à l'utilisateur que vous décidez d'exécuter le service MinIO comme ci-dessus.

 # ls -l /mnt total 4 drwxrwxr-x 2 minio-user minio-user 4096 Dec 27 09:58 data

Configuration SystemD et MinIO : les deux fichiers de configuration doivent avoir les autorisations root:root pour l'utilisateur et le groupe, comme ceci

 # ls -l /etc/default/minio -rw-r--r-- 1 root root 1330 Dec 27 09:52 /etc/default/minio # ls -l /etc/systemd/system/minio.service -rw-r--r-- 1 root root 941 Dec 26 17:13 /etc/systemd/system/minio.service

Exécuter en tant que root : L'ensemble du processus d'installation doit être exécuté en tant que root . Vous pouvez également essayer sudo si votre utilisateur dispose d'autorisations, mais il est recommandé de l'exécuter en tant que root car l'installation doit placer les fichiers dans de nombreux endroits auxquels seul l'utilisateur root peut accéder. Votre invite bash devrait avoir un # et non un $ comme ça

# contre $

Si aucune des solutions ci-dessus ne fonctionne, la meilleure approche consiste à supprimer l'application, les répertoires et les configurations et à démarrer une nouvelle installation en tant qu'utilisateur root.

Conflit portuaire

Un autre problème courant concerne les fichiers supprimés qui sont toujours conservés dans le processus, ce qui provoque des conflits de ports. Même lorsqu'un service n'est pas en cours d'exécution, vous ne pourrez peut-être pas démarrer un nouveau service sur le port existant ou le service en cours d'exécution se comportera mal (par exemple en ne vous permettant pas de vous connecter).

 # lsof -n | grep (deleted) COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME nginx 13423 root 5u REG 253,3 42949672960 17 (deleted) minio 13423 minio 6u REG 253,3 0 18 (deleted) minio 13423 minio 7u REG 253,3 0 19 (deleted)

Vous pourriez voir des erreurs telles que celles ci-dessous lors d'une installation MinIO

• Échec de la connexion net::ERR_FAILED
• 500 Erreur de serveur interne
• 401 Non autorisé

La capture d'écran ci-dessus montre une erreur de serveur interne et une erreur non autorisée. En regardant la surface, il ne semble pas clair ce qui a causé cette erreur, nous pouvons déboguer avec un peu de connaissances Linux ce qu'il faut rechercher qui pourrait causer cela, jetons un coup d'œil.

Il existe plusieurs façons de déboguer ce problème, vérifions d'abord si plusieurs processus MinIO sont en cours d'exécution sur le même nœud.

 # ps aux | grep -i minio minio-u+ 5048 0.3 1.7 1594008 144384 ? Ssl 11:03 0:01 /usr/local/bin/minio server --console-address :9001 /mnt/data/disk1/minio minio-u+ 9276 0.3 1.7 1594208 144301 ? Ssl 11:25 0:01 /usr/local/bin/minio server --console-address :9001 /mnt/data/disk1/minio

Comme nous pouvons le voir ci-dessus, 2 processus MinIO sont en cours d'exécution. Commencez par supprimer le processus le plus ancien ou qui s'exécute le plus longtemps, dans ce cas, il semble s'agir de l'ID de processus 5048 .

kill -9 5048

Parfois, même après avoir arrêté le processus, le service peut toujours ne pas démarrer ou se bloquer car il a réservé un numéro de processus mais ne l'a pas laissé partir. Cela peut être dû à des fichiers qui ont été supprimés mais qui sont toujours suivis par le système d'exploitation. Vous pouvez retrouver les fichiers supprimés via LSOF

lsof -n | grep '(deleted)'

Enfin et surtout, s'il ne reste aucun fichier supprimé ou processus bloqué et si tout semble absolument propre, le dernier recours consiste à redémarrer rapidement le nœud. Il s'agit d'une méthode simple qui arrête et efface tous les fichiers et processus en attente afin que vous puissiez démarrer une nouvelle installation.

SUBNET à la rescousse

Bien que rares, des cas extrêmes d’installation existeront toujours. Les clients MinIO savent qu'ils n'ont rien à craindre car ils peuvent rapidement envoyer un message à nos ingénieurs – qui ont écrit le code – via le SOUS-RÉSEAU portail. Nous avons presque tout vu sous le soleil, alors même si le problème peut paraître énigmatique ou ahurissant à première vue, nous mettrons à profit nos années d'expertise en matière de débogage d'installations dans de nombreux environnements variés et vous aiderons en un tournemain.