paint-brush
MinIO 디버깅을 위한 전문가 팁: Kubernetes 및 베어메탈 환경의 일반적인 문제 극복~에 의해@minio
8,088 판독값
8,088 판독값

MinIO 디버깅을 위한 전문가 팁: Kubernetes 및 베어메탈 환경의 일반적인 문제 극복

~에 의해 MinIO8m2024/04/12
Read on Terminal Reader

너무 오래; 읽다

이 블로그 게시물에서는 Kubernetes에서 실행되는 MinIO 설치를 디버깅하는 방법과 베어 메탈 설치를 수행할 때 발생할 수 있는 몇 가지 일반적인 문제 및 이를 해결하는 방법을 보여 드리겠습니다.
featured image - MinIO 디버깅을 위한 전문가 팁: Kubernetes 및 베어메탈 환경의 일반적인 문제 극복
MinIO HackerNoon profile picture
0-item
1-item


MinIO 배포는 형태와 규모가 다양합니다. 우리는 모든 버전의 Linux 에서 베어메탈 설치를 지원하고, 모든 버전의 Kubernetes (Red Hat OpenShift 포함)에서 컨테이너화된 설치를 지원하며, 작고 가벼운 단일 바이너리를 배포할 수 있는 거의 모든 곳에 설치합니다. 그러나 유연성이 있으면 엣지 케이스 문제에 디버깅이 필요한 경우가 불가피합니다.


이 블로그 게시물에서는 Kubernetes에서 실행 중인 MinIO 설치를 디버깅하는 방법과 베어 메탈 설치를 수행할 때 발생할 수 있는 몇 가지 일반적인 문제 및 이를 해결하는 방법을 보여 드리겠습니다.


Kubernetes 디버거 포드

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를 실행하려면 몇 가지 명령만 있으면 됩니다. 자세한 내용은 다음을 참조하세요. SystemD로 MinIO 구성 .


아주 가끔씩 베어메탈 설치가 잘못되는 경우가 있습니다. 다음은 우리가 질문하는 (그다지 흔하지 않은) 함정 중 일부입니다. 서브넷 또는 느슨하게 . 이러한 함정은 하드웨어나 특정 운영 방식에 국한되지 않지만 모든 종류의 환경에서 알아두면 유용할 수 있습니다.

파일 권한

가장 일반적인 함정 중 하나는 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
  • 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)'


마지막으로, 삭제된 파일이 남아 있거나 중단된 프로세스가 없고 모든 것이 완전히 깨끗해 보이는 경우 최후의 수단은 노드를 빠르게 다시 시작하는 것입니다. 이는 새로 설치를 시작할 수 있도록 보류 중인 모든 파일과 프로세스를 종료하고 지우는 말도 안되는 방법입니다.

구조를 위한 서브넷

드물기는 하지만 설치에 따른 극단적인 경우는 항상 존재합니다. MinIO 고객은 코드를 작성한 엔지니어에게 다음을 통해 신속하게 메시지를 보낼 수 있으므로 걱정할 것이 없다는 것을 알고 있습니다. 서브넷 문. 우리는 태양 아래서 거의 모든 것을 보아왔기 때문에 문제가 언뜻 보기에는 이해하기 어렵거나 당황스러워 보일 수 있지만, 우리는 다양한 환경에서 수년간의 전문 디버깅 설치 경험을 활용하여 신속하게 도움을 드릴 것입니다.


문제 해결 및 디버깅에 대해 질문이 있는 경우 미니IO 설치하려면 다음 주소로 문의해 주세요. 느슨하게 !