Profi-Tipps zum Debuggen von MinIO: Überwindung häufiger Probleme in Kubernetes- und Bare-Metal-Umgebungen

MinIO- Bereitstellungen gibt es in allen Formen und Größen. Wir unterstützen Bare-Metal-Installationen auf jeder Linux- Version, Containerinstallationen auf jeder Kubernetes -Version (einschließlich Red Hat OpenShift) und Installationen praktisch überall dort, wo Sie eine kleine, leichte einzelne Binärdatei bereitstellen können. Mit der Flexibilität geht jedoch zwangsläufig einher, dass bei Randfällen ein Debugging erforderlich ist.

In diesem Blogbeitrag zeigen wir Ihnen, wie Sie eine in Kubernetes laufende MinIO-Installation debuggen. Außerdem erfahren Sie mehr über einige der häufigsten Probleme, die bei einer Bare-Metal-Installation auftreten können, und wie Sie diese beheben.

Kubernetes-Debugger-Pod

Es gibt mehrere Möglichkeiten, auf die MinIO-API zuzugreifen, die in einem Kubernetes-Cluster ausgeführt wird. Wir können kubectl port-forwarding verwenden oder einen Service einrichten, der auf NodePort lauscht, um auf die API zugreifen zu können. Beide Methoden bieten eine Möglichkeit, von außerhalb des Netzwerks auf den Dienst zuzugreifen, haben jedoch einen großen Nachteil: Sie können nur auf den Dienst zugreifen, auf den der NodePort oder die Portweiterleitung auf einem verfügbaren Port verweist (nicht die übliche Konfiguration für die Anwendung). Beispielsweise müssen Sie auf die MinIO-API, die normalerweise auf Port 9000 zu finden ist, über einen zufällig zugewiesenen 3xxxx Port zugreifen.

Was wäre, wenn ich Ihnen sagen würde, dass es einen besseren Weg gibt – und dieser ist nicht neuartig? Beim Debuggen von Anwendungen möchten Sie vollen Zugriff auf die native Laufzeitumgebung haben, damit Sie verschiedene Tools zur Fehlerbehebung und zum Debuggen des Clusters verwenden können. Eine Möglichkeit hierfür besteht darin, einen Pod im „Busybox“-Stil zu starten und alle erforderlichen Tools zum Debuggen der Anwendung zu installieren.

Starten Sie zunächst einen Pod im selben Namespace wie Ihre MinIO-Installation. Erstellen Sie dazu eine YAML-Datei namens debugger-pod.yaml mit dem folgenden YAML.

 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

Die obige Pod-Konfiguration ruft das Image für das MinIO mc Dienstprogramm ab. Um sicherzustellen, dass der Pod nicht einfach gestartet und dann beendet wird, haben wir einen sleep -Befehl hinzugefügt.

Sobald das YAML gespeichert ist, wenden Sie die Konfiguration auf den Kubernetes-Namespace an, in dem der MinIO-Cluster ausgeführt wird

kubectl apply -f debugger-pod.yaml

Sobald der Pod läuft, greifen Sie über die Shell darauf zu

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

Anschließend können Sie mit mc auf den MinIO-Cluster zugreifen

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

Nachdem wir nun einen Debugger-Pod eingerichtet und ausgeführt haben, können Sie direkt im selben Netzwerk Aktionen am Cluster ausführen. Wenn beispielsweise die Replikation aufgrund einer Site-Offline oder eines Hardwarefehlers unterbrochen wurde, können Sie alle ausstehenden zu replizierenden Objekte mit dem folgenden Befehl erneut synchronisieren

 [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

Ein weiterer Grund, warum Sie den Debugger-Pod ausführen sollten, ist, wenn Ihr Pod einige Dateisystemberechtigungen oder ungültige Gruppenkonfigurationen enthält. Sie können diese mit dem Debugger-Pod aktualisieren.

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

Die obige Debugging-Methode kann auch in Bare-Metal-Umgebungen verwendet werden. Sie können beispielsweise eine Busybox oder einen Bastion-Knoten mit installiertem mc starten und die gleichen Anweisungen wie oben befolgen.

Bare Metal debuggen

Bare-Metal-Linux-Installationen sind am einfachsten. Tatsächlich sind nur ein paar Befehle erforderlich, um MinIO zu installieren und mit SystemD auszuführen. Weitere Informationen finden Sie unter MinIO mit SystemD konfigurieren .

Hin und wieder gehen Bare-Metal-Installationen schief. Hier sind einige der (nicht so häufigen) Fallstricke, nach denen wir gefragt werden in Subnetz oder Locker . Diese Fallstricke sind nicht hardware- oder betriebsspezifisch, aber es kann in jeder Umgebung nützlich sein, sie zu kennen.

Dateiberechtigung

Eine der häufigsten Schwierigkeiten sind die Dateiberechtigungen der MinIO-Binärdatei und der Konfigurationsdatei. Wenn dies auftritt, sehen Sie beim Starten von MinIO mit SystemD

Assertion failed for MinIO. und hier ist der vollständige Stacktrace

 # 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.

Dies kann mehrere Gründe haben. Gehen wir die Liste durch und überprüfen jeden einzelnen Grund.

MinIO-Binärdatei : Die Binärdatei, die sich in diesem Beispiel unter /usr/local/bin/minio befindet, benötigt jeweils root:root für den Benutzer und die Gruppe.

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

MinIO-Dienstbenutzer und -gruppe : Der MinIO-Dienst muss aus Sicherheitsgründen unter einem eindeutigen Linux-Benutzer und einer eindeutigen Linux-Gruppe ausgeführt werden. Er darf niemals als root Benutzer ausgeführt werden. Standardmäßig verwenden wir minio-user für die Benutzer- und Gruppennamen. In der SystemD-Dienstkonfigurationsdatei sollten Sie etwa Folgendes sehen:

 User=minio-user Group=minio-user

MinIO-Datenverzeichnis : Das Verzeichnis, in dem die MinIO-Daten gespeichert werden, muss dem minio-user:minio-user oder dem Benutzer gehören, mit dem Sie den MinIO-Dienst wie oben beschrieben ausführen möchten.

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

SystemD- und MinIO-Konfiguration : Beide Konfigurationsdateien sollten die Berechtigungen root:root für Benutzer und Gruppe haben, wie folgt

 # 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

Als Root ausführen : Der gesamte Installationsvorgang sollte als root ausgeführt werden. Sie können auch sudo ausprobieren, wenn Ihr Benutzer über die entsprechenden Berechtigungen verfügt. Es wird jedoch empfohlen, als Root auszuführen, da die Installation Dateien an einer Reihe von Orten ablegen muss, auf die nur der root Benutzer zugreifen kann. Ihre Bash-Eingabeaufforderung sollte ein # und kein $ enthalten, wie hier

# im Vergleich zu $

Wenn keine der oben genannten Möglichkeiten funktioniert, entfernen Sie am besten die App, Verzeichnisse und Konfigurationen und starten Sie eine Neuinstallation als Root-Benutzer.

Hafenkonflikt

Ein weiteres häufiges Problem sind gelöschte Dateien, die noch immer am Prozess hängen, was zu Portkonflikten führt. Selbst wenn ein Dienst nicht ausgeführt wird, können Sie möglicherweise keinen neuen Dienst auf dem vorhandenen Port starten, oder der ausgeführte Dienst verhält sich falsch (beispielsweise lässt er Sie nicht anmelden).

 # 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)

Bei einer MinIO-Installation können Fehler wie die folgenden auftreten

• Anmeldung fehlgeschlagen net::ERR_FAILED
• 500 Interner Serverfehler
• 401 nicht Autorisiert

Der Screenshot oben zeigt einen internen Serverfehler und einen nicht autorisierten Fehler. Auf den ersten Blick scheint es unklar, was diesen Fehler verursacht hat. Mit ein wenig Linux-Wissen können wir herausfinden, wonach wir suchen müssen, um diesen Fehler zu beheben. Werfen wir einen Blick darauf.

Es gibt mehrere Möglichkeiten, dieses Problem zu beheben. Überprüfen wir zunächst, ob mehrere MinIO-Prozesse auf demselben Knoten ausgeführt werden.

 # 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

Wie wir oben sehen können, laufen 2 MinIO-Prozesse. Beginnen Sie, indem Sie den Prozess beenden, der älter ist oder am längsten läuft. In diesem Fall scheint es sich um die Prozess-ID 5048 zu handeln.

kill -9 5048

Manchmal startet der Dienst auch nach dem Beenden des Prozesses nicht oder bleibt hängen, weil er eine Prozessnummer reserviert, aber nicht freigegeben hat. Dies kann durch Dateien verursacht werden, die gelöscht wurden, aber immer noch vom Betriebssystem verfolgt werden. Sie können die gelöschten Dateien über LSOF finden.

lsof -n | grep '(deleted)'

Zu guter Letzt: Wenn keine gelöschten Dateien übrig sind oder Prozesse hängen geblieben sind und alles absolut sauber aussieht, ist der letzte Ausweg ein schneller Neustart des Knotens. Dies ist eine unkomplizierte Methode, die alle ausstehenden Dateien und Prozesse herunterfährt und löscht, sodass Sie eine Neuinstallation starten können.

SUBNET zur Rettung

Obwohl selten, wird es immer Randfälle bei der Installation geben. MinIO-Kunden wissen, dass sie sich keine Sorgen machen müssen, denn sie können unseren Ingenieuren – die den Code geschrieben haben – schnell eine Nachricht über das Subnetz Portal. Wir haben so ziemlich alles unter der Sonne gesehen. Auch wenn das Problem auf den ersten Blick kryptisch oder verwirrend erscheinen mag, können wir unsere jahrelange Erfahrung beim Debuggen von Installationen in vielen unterschiedlichen Umgebungen nutzen und Ihnen im Handumdrehen helfen.