MinIO デバッグのプロのヒント: Kubernetes とベアメタル環境での一般的な問題の克服

MinIO のデプロイメントには、さまざまな形やサイズがあります。Linuxのあらゆるバージョンでのベアメタル インストール、 Kubernetesのあらゆるバージョン (Red Hat OpenShift を含む) でのコンテナー化されたインストール、および小型で軽量な単一バイナリをデプロイできるほぼすべての場所へのインストールをサポートしています。ただし、柔軟性には、エッジ ケースの問題のデバッグが必要になることが必然的に伴います。

このブログ記事では、Kubernetes で実行されている MinIO インストールをデバッグする方法と、ベアメタル インストールを実行するときに発生する可能性のある一般的な問題とその修正方法について説明します。

Kubernetes デバッガーポッド

Kubernetes クラスター内で実行されている MinIO API にアクセスする方法はいくつかあります。kubectl kubectl port-forwarding使用するか、 NodePortでリッスンするServiceを設定して API にアクセスできます。どちらの方法でもネットワークの外部からサービスにアクセスできますが、大きな欠点が 1 つあります。つまり、NodePort またはポート転送が参照するサービスには、使用可能なポート (アプリケーションの通常の構成ではない) でしかアクセスできないということです。たとえば、通常はポート9000にある MinIO API には、ランダムに割り当てられた3xxxxポート経由でアクセスする必要があります。

もっと良い方法があると言ったらどう思いますか? 目新しいことではありませんが。アプリケーションをデバッグするときは、ネイティブ ランタイム環境に完全にアクセスして、さまざまなツールを使用してクラスターのトラブルシューティングとデバッグを行えるようにする必要があります。そのための 1 つの方法は、「busybox」スタイルのポッドを起動し、アプリケーションのデバッグに必要なすべてのツールをインストールすることです。

まず、MinIO インストールと同じ名前空間でPodを起動します。これを行うには、次の yaml を含むdebugger-pod.yamlという 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

上記の Pod 構成は、MinIO mcユーティリティのイメージをプルしています。Pod が起動して終了しないようにするために、 sleepコマンドを追加しました。

yamlを保存したら、MinIOクラスターが稼働しているKubernetes名前空間に構成を適用します。

kubectl apply -f debugger-pod.yaml

ポッドが起動したら、シェル経由でアクセスします。

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

次にmcでMinIOクラスタにアクセスします

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

デバッガーポッドが起動して実行されているので、同じネットワーク内でクラスターに対して直接アクションを実行できます。たとえば、サイトがオフラインになったりハードウェア障害が発生したりしてレプリケーションが中断された場合、次のコマンドを使用して、レプリケートする保留中のオブジェクトを再同期できます。

 [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

デバッガーポッドを実行するもう1つの理由は、ポッドにファイルシステムの権限や無効なグループ構成がある場合に、デバッガーポッドを使用してそれらを更新できることです。

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

上記のデバッグ方法は、ベアメタル環境でも使用できます。たとえば、 mcがインストールされた busybox または bastion ノードを起動し、上記と同じ手順に従います。

ベアメタルのデバッグ

ベアメタルLinuxのインストールは最も簡単です。実際、SystemDでMinIOをインストールして実行するには、いくつかのコマンドを実行するだけです。詳細については、 SystemD で MinIO を構成する。

たまに、ベアメタルのインストールがうまくいかないことがあります。ここでは、私たちがよく質問される（それほど一般的ではない）落とし穴をいくつか紹介します。サブネットまたはスラックこれらの落とし穴はハードウェアやオペレーティングに特有のものではありませんが、どのような環境でも知っておくと役立ちます。

ファイル権限

最も一般的な落とし穴の1つは、MinIOバイナリと設定ファイルのファイル権限です。これが発生すると、SystemDを使用してMinIOを起動すると、

Assertion failed for MinIO.完全なスタックトレースは次のとおりです。

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

これにはいくつかの原因が考えられます。リストを順に確認して、それぞれの原因を確認してみましょう。

MinIO バイナリ: この例では/usr/local/bin/minioにあるバイナリには、ユーザーとグループに対してそれぞれroot:root権限が必要です。

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

MinIO サービスのユーザーとグループ: MinIO サービスは、セキュリティ上の理由から、一意の Linux ユーザーとグループで実行する必要があります。決してrootユーザーとして実行しないでください。デフォルトでは、ユーザー名とグループ名にminio-userを使用します。SystemD サービス構成ファイルには、次のような内容が表示されます。

 User=minio-user Group=minio-user

MinIO データ ディレクトリ: MinIO データが保存されるディレクトリはminio-user:minio-userまたは上記のように MinIO サービスを実行することにしたユーザーが所有する必要があります。

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

SystemDとMinIOの設定: 両方の設定ファイルには、次のようにユーザーとグループのroot:root権限が必要です。

 # 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

ルートとして実行: インストールプロセス全体はrootとして実行する必要があります。ユーザーに権限がある場合はsudoを試すこともできますが、インストールではrootユーザーのみがアクセスできる場所にファイルを配置する必要があるため、ルートとして実行することをお勧めします。bash プロンプトには次のように$ではなく#が必要です。

#対$

上記のいずれも機能しない場合は、アプリ、ディレクトリ、および構成を削除し、ルート ユーザーとして新規インストールを開始するのが最善の方法です。

ポート競合

削除されたファイルがまだプロセスに保持されており、ポートの競合を引き起こすという、よくある問題もあります。サービスが実行されていない場合でも、既存のポートで新しいサービスを開始できないか、実行中のサービスが誤動作することがあります (ログインできないなど)。

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

MinIOのインストール時に以下のようなエラーが表示される場合があります。

• ログインに失敗しましたnet::ERR_FAILED
• 500内部サーバーエラー
• 401 権限がありません

上のスクリーンショットは、内部サーバー エラーと不正なエラーを示しています。表面的には、このエラーの原因が不明ですが、Linux の知識を少し使って、このエラーの原因となる可能性のあるものを探してデバッグすることができます。詳しく見てみましょう。

この問題をデバッグする方法はいくつかありますが、まず複数のMinIOプロセスが同じノードで実行されているかどうかを確認します。

 # 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

上の図からわかるように、2 つの MinIO プロセスが実行されています。まず、最も古いプロセス、または最も長く実行されているプロセスを強制終了します。この場合、プロセス ID は5048のようです。

kill -9 5048

場合によっては、プロセスを強制終了した後でも、サービスが起動しなかったり、プロセス番号を予約したが解放しなかったためにハングアップしたりすることがあります。これは、削除されたがオペレーティングシステムによって追跡されているファイルによって発生する可能性があります。削除されたファイルは、LSOFで見つけることができます。

lsof -n | grep '(deleted)'

最後に、削除されたファイルが残っておらず、プロセスがハングしておらず、すべてが完全にクリーンであるように見える場合、最後の手段はノードをすぐに再起動することです。これは、保留中のファイルとプロセスをシャットダウンしてクリアし、新規インストールを開始する実用的な方法です。

SUBNETが救世主

稀ではありますが、インストールのエッジケースは常に存在します。MinIOのお客様は、コードを書いた当社のエンジニアにすぐにメッセージを送ることができるので、心配する必要はありません。サブネットポータル。私たちは、ありとあらゆる問題を経験してきました。そのため、一見すると問題が不可解で理解しにくいように見える場合でも、さまざまな環境でインストールをデバッグしてきた長年の専門知識を活かして、すぐにお手伝いいたします。