Chẩn đoán lỗi kết nối mạng và quyền truy cập
Khi gặp lỗi Permission denied hoặc không thể kết nối đến MinIO, nguyên nhân thường nằm ở cấu hình quyền sở hữu file (ownership) hoặc firewall chặn port.
Bước đầu tiên là kiểm tra quyền sở hữu của thư mục data được mount vào container. MinIO yêu cầu quyền root (UID 0) để chạy, nhưng khi map volume vào host, nếu thư mục host không thuộc về root, MinIO sẽ không ghi được log hoặc data.
Kiểm tra và sửa quyền sở hữu cho thư mục data (giả sử đường dẫn là /var/lib/minio/data):
sudo chown -R 1000:1000 /var/lib/minio/data
Kết quả mong đợi: Không có lỗi xuất hiện, quyền sở hữu thuộc về user UID 1000 (mặc định của MinIO trong container). Nếu bạn chạy với root (không khuyến khích), dùng UID 0.
Tiếp theo, kiểm tra xem port 9000 (API) và 9001 (Console) có bị firewall chặn không. Ubuntu 24.04 mặc định sử dụng ufw.
sudo ufw status
Nếu thấy port 9000 và 9001 không trong danh sách ALLOW, hãy mở chúng:
sudo ufw allow 9000/tcp
sudo ufw allow 9001/tcp
sudo ufw reload
Kết quả mong đợi: Lệnh chạy thành công và trạng thái ufw hiển thị 2 port mới đã được mở.
Để xác minh kết quả từ xa, sử dụng curl để test kết nối API:
curl -v http://YOUR_SERVER_IP:9000/minio/health/live
Kết quả mong đợi: Nhận được mã trạng thái HTTP 200 OK và nội dung phản hồi là OK. Nếu thấy Connection refused, kiểm tra lại Docker container có đang chạy không.
Khắc phục sự cố mất dữ liệu hoặc lỗi drive trong cụm phân tán
Trong môi trường MinIO Distributed Mode (đã cấu hình ở Phần 6), nếu một drive bị lỗi hoặc mất kết nối, hệ thống sẽ tự động chuyển sang chế độ Degraded nhưng vẫn hoạt động nếu Erasure Code còn đủ shards.
Để kiểm tra trạng thái của các node và drive trong cụm, sử dụng lệnh mc admin info:
mc admin info myminio
Kết quả mong đợi: Xuất hiện danh sách các node. Nếu có drive lỗi, dòng tương ứng sẽ hiển thị trạng thái Offline hoặc Failed màu đỏ.
Nếu một drive bị lỗi vật lý (disk failure), bạn cần thay thế nó. MinIO hỗ trợ tính năng Healing tự động phục hồi dữ liệu khi drive mới được gắn vào.
Giả sử bạn đã thay thế drive vật lý và mount vào cùng vị trí (ví dụ /mnt/disk1), hãy kích hoạt lệnh heal để MinIO tự động rebuild dữ liệu:
mc admin heal myminio --drive /mnt/disk1
Nếu muốn heal toàn bộ bucket hoặc toàn bộ cụm sau sự cố:
mc admin heal myminio --recursive
Kết quả mong đợi: Lệnh chạy và hiển thị tiến độ phục hồi dữ liệu (Rebuilding data). Trạng thái của drive sẽ chuyển từ Offline sang Online sau khi dữ liệu được rebuild xong.
Để xác minh dữ liệu đã được phục hồi, hãy kiểm tra lại trạng thái health của bucket:
mc admin info myminio --json | jq '.drives[] | select(.status == "Offline")'
Kết quả mong đợi: Trả về empty (không có drive nào offline). Nếu lệnh quay lại kết quả, drive vẫn chưa được heal hoàn toàn.
Tối ưu hóa I/O disk với fio test
Hiệu suất của MinIO phụ thuộc lớn vào I/O của disk. Để đảm bảo disk đạt hiệu suất tối đa trước khi đưa vào production, hãy chạy bài test fio để đo Bandwidth và IOPS.
Trước tiên, cài đặt công cụ fio trên Ubuntu 24.04:
sudo apt update
sudo apt install -y fio
Kết quả mong đợi: Lệnh cài đặt thành công, công cụ fio sẵn sàng sử dụng.
Tạo file cấu hình test cho bài kiểm tra Random Read/Write (mô phỏng workload thực tế của Object Storage). Lưu file vào /tmp/fio_minio.conf:
sudo tee /tmp/fio_minio.conf
Kết quả mong đợi: File cấu hình được tạo thành công với các thông số tối ưu cho MinIO (Direct I/O, Depth cao).
Chạy bài test với file cấu hình vừa tạo. Thay thế đường dẫn filename nếu cần:
fio /tmp/fio_minio.conf
Kết quả mong đợi: Sau 60 giây, xuất hiện bảng báo cáo. Quan trọng nhất là dòng bw (Bandwidth) và iops.
- SSD NVMe: Nên đạt > 500 MB/s (Write) và > 800 MB/s (Read).
- SSD SATA: Nên đạt > 200 MB/s.
- HDD: Nên đạt > 150 MB/s.
Sau khi test xong, xóa file test để giải phóng dung lượng:
rm -f /var/lib/minio/data/testfile
Kết quả mong đợi: File testfile bị xóa, không còn chiếm dung lượng trên disk.
Nâng cấp version MinIO không gián đoạn dịch vụ
Nâng cấp MinIO trong môi trường production yêu cầu kỹ thuật Rolling Update để đảm bảo dịch vụ không bị downtime. MinIO hỗ trợ tính năng Auto-heal giúp các node mới khởi động và đồng bộ ngay lập tức.
Bước 1: Kiểm tra version hiện tại của MinIO đang chạy:
mc admin info myminio
Kết quả mong đợi: Thấy dòng Version (ví dụ: 2023-10-15T12:00:00Z).
Bước 2: Pull image version mới nhất từ Docker Hub:
docker pull minio/minio:latest
Kết quả mong đợi: Image mới được tải về, hiển thị dòng Download complete.
Bước 3: Nếu đang chạy bằng Docker Compose, hãy sử dụng lệnh docker-compose up -d với tùy chọn --no-deps (nếu muốn cập nhật từng node) hoặc để Docker Compose tự xử lý rolling update nếu cấu hình đúng restart_policy.
Tuy nhiên, để kiểm soát chặt chẽ nhất, hãy restart từng container một. Giả sử bạn có 4 node (minio1, minio2, minio3, minio4).
docker restart minio1
Kết quả mong đợi: Container minio1 tắt và khởi động lại với image mới. MinIO Distributed Mode vẫn hoạt động với 3 node còn lại (trạng thái Degraded tạm thời).
Chờ minio1 khởi động xong (khoảng 10-30 giây), sau đó nâng cấp tiếp node tiếp theo:
docker restart minio2
docker restart minio3
docker restart minio4
Kết quả mong đợi: Lần lượt các node khởi động lại. Trong quá trình này, dịch vụ vẫn đáp ứng được các yêu cầu đọc/ghi (Read/Write) vì Erasure Code còn đủ shards.
Bước 4: Xác minh toàn bộ cụm đã chạy trên version mới:
mc admin info myminio
Kết quả mong đợi: Tất cả các node trong danh sách đều hiển thị cùng một Version mới nhất. Không còn node nào chạy version cũ.
Cuối cùng, kiểm tra xem có cần chạy heal không (thường MinIO tự heal, nhưng để chắc chắn):
mc admin heal myminio --recursive
Kết quả mong đợi: Lệnh chạy và báo Success, xác nhận dữ liệu đã đồng bộ hoàn toàn trên version mới.
Điều hướng series:
Mục lục: Series: Triển khai Database Object Storage với MinIO và Ubuntu 24.04
« Phần 7: Cấu hình Backup, Restore và giám sát (Monitoring)