Советы для профессионалов по отладке MinIO: решение распространенных проблем в Kubernetes и средах с голым железом

Развертывания MinIO бывают разных форм и размеров. Мы поддерживаем установку на «голое железо» в любой версии Linux , контейнерную установку в любой версии Kubernetes (включая Red Hat OpenShift) и установку практически везде, где можно развернуть небольшой и легкий одиночный двоичный файл. Но вместе с гибкостью неизбежно возникает ситуация, когда проблемы в крайних случаях потребуют отладки.

В этом сообщении блога мы покажем вам, как отлаживать установку MinIO, работающую в Kubernetes, а также некоторые распространенные проблемы, с которыми вы можете столкнуться при установке на «голое железо», и способы их устранения.

Модуль отладчика Kubernetes

Существует несколько способов доступа к API MinIO, работающему внутри кластера Kubernetes. Мы можем использовать kubectl port-forwarding или настроить Service прослушивающую NodePort , чтобы иметь доступ к API. Оба эти метода предлагают способ доступа к службе извне сети, но у них есть один существенный недостаток: вы можете получить доступ только к службе, на которую ссылается NodePort или переадресация портов, через доступный порт (а не обычная конфигурация для приложения). ). Например, вам необходимо получить доступ к API MinIO, который обычно находится на порту 9000 , через случайно назначенный порт 3xxxx .

Что, если я скажу вам, что есть лучший способ – и он не новаторский? При отладке приложений вам нужен полный доступ к собственной среде выполнения, чтобы вы могли использовать различные инструменты для устранения неполадок и отладки кластера. Один из способов сделать это — запустить модуль в стиле «busybox» и установить все необходимые инструменты, необходимые для отладки приложения.

Сначала запустите Pod в том же пространстве имен, что и ваша установка MinIO. Для этого создайте файл 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

Приведенная выше конфигурация Pod извлекает образ для утилиты MinIO mc . Чтобы модуль не просто запустился, а затем завершил работу, мы добавили команду sleep .

После сохранения yaml примените конфигурацию к пространству имен Kubernetes, где работает кластер MinIO.

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/

Описанный выше метод отладки также можно использовать в средах с «голым железом». Например, вы можете запустить узел busybox или bastion с установленным mc и следовать тем же инструкциям, что и выше.

Отладка «голого металла»

Установка Linux на «голое железо» является самой простой. На самом деле для установки и запуска MinIO с SystemD требуется всего несколько команд. Подробности см. Настройка MinIO с помощью SystemD .

Время от времени установка на «голое железо» выходит из строя. Вот некоторые из (не очень распространенных) ошибок, о которых нас спрашивают в ПОДСЕТЬ или Слабый . Эти ловушки не связаны с аппаратным обеспечением или операционной системой, но их полезно знать в любой среде.

Разрешение файла

Одной из наиболее распространенных ошибок являются права доступа к двоичному файлу MinIO и файлу конфигурации. Если это произойдет, при запуске MinIO с помощью SystemD вы увидите

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 : каталог, в котором будут храниться данные 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 : Весь процесс установки должен выполняться от 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)

При установке 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. Начните с уничтожения процесса, который старше или работает дольше всего, в данном случае это процесс с идентификатором 5048 .

kill -9 5048

Иногда даже после завершения процесса служба все равно может не запуститься или зависнуть, поскольку она зарезервировала номер процесса, но не отпустила его. Это может быть вызвано файлами, которые были удалены, но все еще отслеживаются операционной системой. Вы можете найти удаленные файлы через LSOF.

lsof -n | grep '(deleted)'

И последнее, но не менее важное: если не осталось удаленных файлов или зависших процессов и если все выглядит абсолютно чисто, последним средством является быстрый перезапуск узла. Это серьезный метод, который завершает работу и очищает все ожидающие файлы и процессы, чтобы вы могли начать новую установку.

ПОДСЕТЬ в помощь

Хотя и редко, крайние случаи установки всегда будут существовать. Клиенты MinIO знают, что им не о чем беспокоиться, поскольку они могут быстро отправить сообщение нашим инженерам, написавшим код, через ПОДСЕТЬ портал. Мы видели почти все на свете, поэтому, хотя на первый взгляд проблема может показаться загадочной или ошеломляющей, мы приложим наш многолетний опыт отладки установок в самых разных средах, чтобы работать и помочь вам в одно мгновение.