Mẹo chuyên nghiệp để gỡ lỗi MinIO: Khắc phục các sự cố thường gặp trong môi trường Kubernetes và Bare Metal

Việc triển khai MinIO có đủ hình dạng và kích cỡ. Chúng tôi hỗ trợ cài đặt kim loại trần trên mọi phiên bản Linux , cài đặt trong bộ chứa trên bất kỳ phiên bản Kubernetes nào (bao gồm Red Hat OpenShift) và cài đặt ở hầu hết mọi nơi mà bạn có thể triển khai một tệp nhị phân đơn nhỏ, nhẹ. Nhưng với tính linh hoạt, chắc chắn các vấn đề về trường hợp biên sẽ cần phải được gỡ lỗi.

Trong bài đăng trên blog này, chúng tôi sẽ hướng dẫn bạn cách gỡ lỗi bản cài đặt MinIO đang chạy trong Kubernetes cũng như một số vấn đề phổ biến mà bạn có thể gặp phải khi thực hiện cài đặt kim loại trần và cách khắc phục chúng.

Trình gỡ lỗi Kubernetes

Có một số cách để truy cập API MinIO chạy bên trong cụm Kubernetes. Chúng ta có thể sử dụng kubectl port-forwarding hoặc thiết lập Service listen trên NodePort để có thể truy cập API. Cả hai phương pháp này đều cung cấp cách truy cập dịch vụ từ bên ngoài mạng, nhưng chúng có một nhược điểm lớn: Bạn chỉ có thể truy cập Dịch vụ mà NodePort hoặc Port Forwarding tham chiếu trên một cổng khả dụng (không phải cấu hình thông thường cho ứng dụng ). Ví dụ: bạn phải truy cập API MinIO, thường được tìm thấy trên cổng 9000 , thông qua cổng 3xxxx được chỉ định ngẫu nhiên.

Điều gì sẽ xảy ra nếu tôi nói với bạn rằng có một cách tốt hơn – và nó không hề mới lạ? Khi gỡ lỗi ứng dụng, bạn muốn có toàn quyền truy cập vào môi trường thời gian chạy gốc để có thể sử dụng nhiều công cụ khác nhau nhằm khắc phục sự cố và gỡ lỗi cụm. Một cách để làm điều đó là khởi chạy nhóm kiểu “busybox” và cài đặt tất cả các công cụ cần thiết để gỡ lỗi ứng dụng.

Trước tiên, hãy khởi chạy Pod vào cùng không gian tên với bản cài đặt MinIO của bạn. Để thực hiện việc này, hãy tạo một tệp yaml có tên debugger-pod.yaml với yaml sau.

 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

Cấu hình Pod ở trên đang pull image cho tiện ích MinIO mc . Để đảm bảo nhóm không chỉ khởi chạy rồi thoát ra, chúng tôi đã thêm lệnh sleep .

Sau khi yaml được lưu, hãy áp dụng cấu hình cho vùng tên Kubernetes nơi cụm MinIO đang chạy

kubectl apply -f debugger-pod.yaml

Sau khi nhóm hoạt động và chạy, hãy truy cập nó qua shell

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

Sau đó với mc bạn có thể truy cập vào cụm MinIO

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

Bây giờ chúng ta đã thiết lập và chạy một nhóm trình gỡ lỗi, bạn có thể thực hiện hành động trực tiếp trên cụm trong cùng một mạng. Ví dụ: nếu quá trình sao chép bị hỏng do trang web ngoại tuyến hoặc lỗi phần cứng, bạn có thể đồng bộ lại mọi đối tượng đang chờ sao chép bằng lệnh sau

 [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

Một lý do khác khiến bạn chạy nhóm trình gỡ lỗi là nếu có một số quyền hệ thống tệp hoặc cấu hình nhóm không hợp lệ trong nhóm của bạn, bạn có thể cập nhật chúng bằng cách sử dụng nhóm trình gỡ lỗi

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

Phương pháp gỡ lỗi ở trên cũng có thể được sử dụng trong môi trường kim loại trần. Ví dụ: bạn có thể khởi chạy một nút busybox hoặc bastion có cài đặt mc và làm theo các hướng dẫn tương tự như trên.

Gỡ lỗi kim loại trần

Cài đặt Linux bằng kim loại trần là đơn giản nhất. Trên thực tế, chỉ cần một vài lệnh để cài đặt và chạy MinIO với SystemD. Để biết chi tiết, vui lòng xem Định cấu hình MinIO với SystemD .

Đôi khi, việc lắp đặt kim loại trần gặp trục trặc. Sau đây là một số cạm bẫy (không phổ biến) mà chúng tôi được hỏi trong MẠNG PHỤ hoặc chùng xuống . Những cạm bẫy này không liên quan đến phần cứng hoặc hoạt động cụ thể nhưng có thể hữu ích khi biết trong bất kỳ loại môi trường nào.

Quyền tập tin

Một trong những cạm bẫy phổ biến nhất là quyền truy cập tệp của tệp nhị phân MinIO và tệp cấu hình. Nếu điều này xảy ra, khi bạn khởi động MinIO bằng SystemD, bạn sẽ thấy

Assertion failed for MinIO. và đây là dấu vết ngăn xếp đầy đủ

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

Điều này có thể do một số lý do gây ra, hãy cùng xuống danh sách và kiểm tra từng lý do.

MinIO Binary : Tệp nhị phân, trong ví dụ này nằm ở /usr/local/bin/minio cần có quyền root:root tương ứng cho người dùng và nhóm.

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

Nhóm và người dùng dịch vụ MinIO : Dịch vụ MinIO cần chạy dưới một nhóm và người dùng Linux duy nhất vì mục đích bảo mật, không bao giờ chạy với tư cách là người dùng root . Theo mặc định, chúng tôi sử dụng minio-user cho tên người dùng và nhóm. Trong tệp cấu hình dịch vụ SystemD, bạn sẽ thấy một cái gì đó như thế này

 User=minio-user Group=minio-user

MinIO Data Dir : Thư mục lưu trữ dữ liệu MinIO cần phải được sở hữu bởi minio-user:minio-user hoặc bất kỳ người dùng nào bạn quyết định chạy dịch vụ MinIO như trên.

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

Cấu hình SystemD và MinIO : Cả hai tệp cấu hình đều phải có quyền root:root cho người dùng và nhóm như vậy

 # 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

Chạy bằng quyền root : Toàn bộ quá trình cài đặt phải được chạy bằng root . Bạn cũng có thể thử sudo nếu người dùng của bạn có quyền nhưng khuyến nghị là nên chạy bằng root vì quá trình cài đặt cần đặt các tệp ở nhiều nơi mà chỉ người dùng root mới có thể truy cập. Dấu nhắc bash của bạn phải có # chứ không phải $ như vậy

# so với $

Nếu không có cách nào ở trên hiệu quả, cách tiếp cận tốt nhất là xóa ứng dụng, thư mục và cấu hình rồi bắt đầu cài đặt mới với tư cách là người dùng root.

Xung đột cổng

Một vấn đề phổ biến khác liên quan đến các tệp đã xóa vẫn tồn tại trong quá trình, gây ra xung đột cổng. Ngay cả khi một dịch vụ không chạy, bạn có thể không khởi động được dịch vụ mới trên cổng hiện tại hoặc dịch vụ đang chạy sẽ hoạt động sai (chẳng hạn như không cho phép bạn đăng nhập).

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

Bạn có thể thấy các lỗi như lỗi bên dưới khi cài đặt MinIO

• Đăng nhập không thành công net::ERR_FAILED
• Lỗi máy chủ nội bộ 500
• 401 trái phép

Ảnh chụp màn hình ở trên hiển thị lỗi máy chủ nội bộ và lỗi trái phép. Nhìn bề ngoài có vẻ không rõ nguyên nhân gây ra lỗi này, chúng ta có thể gỡ lỗi bằng một chút kiến thức về linux những gì cần tìm có thể gây ra lỗi này, chúng ta hãy cùng xem xét.

Có một số cách để gỡ lỗi vấn đề này, trước tiên hãy kiểm tra xem liệu có nhiều quy trình MinIO đang chạy trên cùng một nút hay không

 # 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

Như chúng ta có thể thấy ở trên có 2 tiến trình MinIO đang chạy. Bắt đầu bằng cách tắt tiến trình cũ hơn hoặc đã chạy lâu nhất, trong trường hợp này có vẻ như đó là ID tiến trình 5048 .

kill -9 5048

Đôi khi, ngay cả sau khi tắt tiến trình, dịch vụ vẫn có thể không khởi động hoặc vẫn có thể bị treo vì nó đã đặt trước số tiến trình nhưng không cho phép nó đi. Điều này có thể xảy ra do các tập tin đã bị xóa nhưng vẫn đang được hệ điều hành theo dõi. Bạn có thể tìm thấy các tập tin đã xóa thông qua LSOF

lsof -n | grep '(deleted)'

Cuối cùng nhưng không kém phần quan trọng, nếu không còn tệp nào bị xóa hoặc quá trình bị treo và nếu mọi thứ trông hoàn toàn sạch sẽ thì biện pháp cuối cùng là nhanh chóng khởi động lại nút. Đây là một phương pháp đơn giản giúp tắt và xóa mọi tệp và quy trình đang chờ xử lý để bạn bắt đầu cài đặt mới.

SUBNET để giải cứu

Mặc dù hiếm gặp nhưng các trường hợp khó cài đặt sẽ luôn tồn tại. Khách hàng của MinIO biết rằng họ không có gì phải lo lắng vì họ có thể nhanh chóng nhắn tin cho các kỹ sư của chúng tôi – những người đã viết mã – thông qua MẠNG PHỤ cổng thông tin. Chúng tôi đã nhìn thấy hầu hết mọi thứ, vì vậy mặc dù vấn đề này thoạt nhìn có vẻ khó hiểu hoặc khó hiểu, nhưng chúng tôi sẽ vận dụng kinh nghiệm chuyên môn nhiều năm gỡ lỗi cài đặt trong nhiều môi trường khác nhau để hoạt động và giúp bạn nhanh chóng.