调试 MinIO 安装

MinIO 部署形式多样。我们支持在任意版本的 Linux 上进行裸金属安装，支持在任何版本的 Kubernetes（包括 Red Hat OpenShift）上进行容器化安装，还支持在大大小小的环境中部署单个轻量级二进制文件。但是，随着灵活性增加，边缘情况问题也就不可避免地需要进行调试。
在这篇博客文章中，我们将向您展示如何调试在 Kubernetes 中运行的 MinIO 安装，以及在进行裸金属安装时可能遇到的常见问题及其解决方法。

Kubernetes 调试器 Pod

有几种方法可以访问 Kubernetes 集群内运行的 MinIO API。我们可以使用 kubectl 端口转发，或者设置一个监听 NodePort 的 Service，以便能够访问 API。这两种方法都提供了一种从外部网络访问服务的方式，但它们都存在一个主要缺点：您只能通过可用的端口（而不是应用程序的通常配置）访问 NodePort 或端口转发引用的服务。例如，您必须通过随机分配的 3xxxx 端口访问通常在端口 9000 上找到的 MinIO API。
如果我告诉你有一个更好的方法，而且这个方法并不新颖，你会感兴趣吗？在调试应用程序时，您希望拥有对原生运行时环境的完全访问权限，以便您可以使用各种工具来排除故障和调试集群。实现这一目标的一种方式是启动一个“busybox”风格的 pod，并安装所有必需的工具来调试应用程序。

首先，在与您的 MinIO 安装相同的命名空间中启动一个 Pod。为此，请创建一个名为 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

上面的 Pod 配置是为 MinIO mc 实用程序拉取映像。为了确保 pod 不会只是启动然后退出，我们添加了一个 sleep 命令。

保存 yaml 后，将配置应用于运行 MinIO 集群的 Kubernetes 命名空间

kubectl apply -f debugger-pod.yaml

Pod 启动并运行后，通过 shell 访问它

$ kubectl exec -i -t -n default mc -c mc -- sh -c "(bash || ash || sh)"

[root@mc /]# 
1
2
3
4

然后， mc 您可以访问 MinIO 集群

[root@mc /]# mc alias set myminio    --insecure

Added `myminio` successfully.
1
2
3

现在，我们已经启动并运行了调试器 pod，您可以直接在同一网络中对集群执行操作。例如，如果由于站点脱机或硬件故障而中断复制，则可以使用以下命令重新同步要复制的任何挂起对象

[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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

运行调试器 Pod 的另一个原因是，如果 Pod 中存在某些文件系统权限或无效的组配置，则可以使用调试器 Pod 更新它们

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

1
2

上述调试方法也可用于裸机环境。例如，您可以启动已安装的 mc busybox 或堡垒节点，并按照与上述相同的说明进行操作。

调试裸机

裸机 Linux 安装是最直接的。事实上，只需几个命令即可安装 MinIO 并与 SystemD 一起运行。有关详细信息，请参阅使用 SystemD 配置 MinIO。

偶尔，裸机安装会出错。以下是我们在 SUBNET 或 Slack 中被问到的一些（不太常见的）陷阱。这些陷阱不是特定于硬件或操作的，但在任何类型的环境中了解都很有用。

文件权限

最常见的陷阱之一是 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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

这可能是由多种原因引起的，让我们向下看列表并检查其中的每一个。

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*
1
2
3
4
5
6

MinIO 服务用户和组：出于安全考虑，MinIO 服务需要在唯一的 Linux 用户和组下运行，切勿以 root 用户身份运行。默认情况下，我们用于 minio-user 用户名和组名。在 SystemD 服务配置文件中，您应该看到如下内容

MinIO 数据目录：存储 MinIO 数据的目录需要由 minio-user:minio-user 您决定运行 MinIO 服务的用户拥有，如上所述。

User=minio-user

Group=minio-user
1
2
3

SystemD 和 MinIO 配置：这两个配置文件都应具有用户和组的权限 root:root ，如下所示

# ls -l /mnt

total 4

drwxrwxr-x 2 minio-user minio-user 4096 Dec 27 09:58 data
1
2
3
4
5

# 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
1
2
3
4
5
6
7
8

以 root 身份运行：整个安装过程应以 root .您也可以尝试 sudo 您的用户是否具有权限，但建议以 root 身份运行，因为安装需要将文件放置在只有 root 用户才能访问的一堆位置。你的 bash 提示应该有一个 # 而不是 $ 一个类似的东西

如果上述方法都不起作用，最好的方法是删除应用程序、目录和配置，然后以 root 用户身份开始全新安装。

端口冲突

另一个常见问题与已删除的文件有关，这些文件仍保留在进程中，这会导致端口冲突。即使服务未运行，您也可能无法在现有端口上启动新服务，或者正在运行的服务将出现异常行为（例如不允许登录）。

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

1
2
3
4
5
6
7
8
9
10

您可能会在 MinIO 安装中看到如下错误

• Login Failed net::ERR_FAILED 登录失败 net::ERR_FAILED

• 500 内部服务器错误

• 401 Unauthorized 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

1
2
3
4
5
6
7
8

正如我们在上面看到的，有 2 个 MinIO 进程在运行。首先杀死较旧或运行时间最长的进程，在这种情况下，它似乎是 进程 ID 5048 .

kill -9 5048

有时，即使在终止进程后，服务可能仍无法启动，或者可能仍会挂断，因为它保留了进程编号，但不让它离开。这可能是由已删除但仍作系统跟踪的文件引起的。您可以通过LSOF找到已删除的文件

lsof -n | grep '(deleted)'

最后但并非最不重要的一点是，如果没有删除的文件或挂起的进程，并且如果一切看起来绝对干净，最后的手段是快速重新启动节点。这是一种严肃的方法，可以关闭并清除任何待处理的文件和进程，以便您开始全新安装。

最后

虽然很少见，但安装边缘情况将始终存在。MinIO 客户知道他们没有什么可担心的，因为他们可以通过购买MinIO授权后，向我们的工程师发起咨询和求助。我们几乎已经看到了阳光下的一切，所以虽然这个问题乍一看可能看起来很神秘或令人难以置信，但我们将利用我们多年来在许多不同环境中调试安装的专业知识来工作，并立即为您提供帮助。