MinIO 배포는 형태와 규모가 다양합니다. 우리는 모든 버전의 Linux 에서 베어메탈 설치를 지원하고, 모든 버전의 Kubernetes (Red Hat OpenShift 포함)에서 컨테이너화된 설치를 지원하며, 작고 가벼운 단일 바이너리를 배포할 수 있는 거의 모든 곳에 설치합니다. 그러나 유연성이 있으면 엣지 케이스 문제에 디버깅이 필요한 경우가 불가피합니다.
이 블로그 게시물에서는 Kubernetes에서 실행 중인 MinIO 설치를 디버깅하는 방법과 베어 메탈 설치를 수행할 때 발생할 수 있는 몇 가지 일반적인 문제 및 이를 해결하는 방법을 보여 드리겠습니다.
Kubernetes 클러스터 내에서 실행되는 MinIO API에 액세스하는 방법에는 몇 가지가 있습니다. kubectl port-forwarding
사용하거나 NodePort
에서 수신 대기하는 Service
설정하여 API에 액세스할 수 있습니다. 이 두 가지 방법 모두 네트워크 외부에서 서비스에 액세스하는 방법을 제공하지만 한 가지 주요 단점이 있습니다. 사용 가능한 포트에서 NodePort 또는 포트 전달이 참조하는 서비스에만 액세스할 수 있습니다(애플리케이션의 일반적인 구성이 아님). ). 예를 들어, 무작위로 할당된 3xxxx
포트를 통해 일반적으로 포트 9000
에 있는 MinIO API에 액세스해야 합니다.
더 나은 방법이 있다고 말하면 어떻게 될까요? 그것은 참신한 것이 아닙니다. 애플리케이션을 디버깅할 때 다양한 도구를 사용하여 클러스터 문제를 해결하고 디버깅할 수 있도록 기본 런타임 환경에 대한 전체 액세스 권한을 갖고 싶습니다. 이를 수행하는 한 가지 방법은 "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
위 포드 구성은 MinIO mc
유틸리티용 이미지를 가져옵니다. 포드가 시작되었다가 종료되지 않도록 하기 위해 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
디버거 포드를 실행하는 또 다른 이유는 포드에 일부 파일 시스템 권한이나 잘못된 그룹 구성이 있는 경우 디버거 포드를 사용하여 업데이트할 수 있기 때문입니다.
[root@mc /]# chgrp -R 1000780050 .minio.sys/
위의 디버깅 방법은 베어메탈 환경에서도 사용할 수 있습니다. 예를 들어 mc
가 설치된 busybox 또는 요새 노드를 시작하고 위와 동일한 지침을 따를 수 있습니다.
베어메탈 Linux 설치가 가장 간단합니다. 실제로 MinIO를 설치하고 SystemD를 실행하려면 몇 가지 명령만 있으면 됩니다. 자세한 내용은 다음을 참조하세요.
아주 가끔씩 베어메탈 설치가 잘못되는 경우가 있습니다. 다음은 우리가 질문하는 (그다지 흔하지 않은) 함정 중 일부입니다.
가장 일반적인 함정 중 하나는 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 Data Dir : 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
위 스크린샷은 내부 서버 오류와 인증되지 않은 오류를 보여줍니다. 표면적으로 보면 이 오류의 원인이 무엇인지 불분명해 보이지만 약간의 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)'
마지막으로, 삭제된 파일이 남아 있거나 중단된 프로세스가 없고 모든 것이 완전히 깨끗해 보이는 경우 최후의 수단은 노드를 빠르게 다시 시작하는 것입니다. 이는 새로 설치를 시작할 수 있도록 보류 중인 모든 파일과 프로세스를 종료하고 지우는 말도 안되는 방법입니다.
드물기는 하지만 설치에 따른 극단적인 경우는 항상 존재합니다. MinIO 고객은 코드를 작성한 엔지니어에게 다음을 통해 신속하게 메시지를 보낼 수 있으므로 걱정할 것이 없다는 것을 알고 있습니다.