Dicas profissionais para depuração do MinIO: superando problemas comuns em ambientes Kubernetes e Bare Metal

As implantações MinIO vêm em todos os formatos e tamanhos. Oferecemos suporte a instalações bare metal em qualquer versão do Linux , instalações em contêineres em qualquer versão do Kubernetes (incluindo Red Hat OpenShift) e instalações em praticamente qualquer lugar onde você possa implantar um binário pequeno e leve. Mas com a flexibilidade vem a inevitabilidade de que problemas extremos exigirão depuração.

Nesta postagem do blog, mostraremos como depurar uma instalação do MinIO em execução no Kubernetes e também alguns dos problemas comuns que você pode encontrar ao fazer uma instalação bare metal e como corrigi-los.

Pod de depurador do Kubernetes

Existem algumas maneiras de acessar a API MinIO em execução dentro de um cluster Kubernetes. Podemos usar kubectl port-forwarding ou configurar um Service de escuta no NodePort para poder acessar a API. Ambos os métodos oferecem uma maneira de acessar o serviço de fora da rede, mas apresentam uma grande desvantagem: você só pode acessar o serviço referenciado pelo NodePort ou Port Forwarding em uma porta disponível (não a configuração usual para o aplicativo). ). Por exemplo, você precisa acessar a API MinIO, geralmente encontrada na porta 9000 , por meio de uma porta 3xxxx atribuída aleatoriamente.

E se eu lhe dissesse que existe uma maneira melhor – e não é novidade? Ao depurar aplicativos, você deseja ter acesso total ao ambiente de tempo de execução nativo para poder usar diversas ferramentas para solucionar problemas e depurar o cluster. Uma maneira de fazer isso é iniciar um pod estilo “busybox” e instalar todas as ferramentas necessárias para depurar o aplicativo.

Primeiro, inicie um Pod no mesmo namespace da instalação do MinIO. Para fazer isso, crie um arquivo yaml chamado debugger-pod.yaml com o seguinte 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

A configuração do Pod acima está extraindo a imagem para o utilitário MinIO mc . Para garantir que o pod não seja apenas iniciado e encerrado, adicionamos um comando sleep .

Depois que o yaml for salvo, aplique a configuração ao namespace Kubernetes onde o cluster MinIO está sendo executado

kubectl apply -f debugger-pod.yaml

Assim que o pod estiver instalado e funcionando, acesse-o via shell

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

Então com mc você pode acessar o cluster MinIO

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

Agora que temos um pod de depurador instalado e em execução, você pode executar ações no cluster diretamente na mesma rede. Por exemplo, se a replicação foi interrompida devido a um site ficar off-line ou a uma falha de hardware, você poderá sincronizar novamente quaisquer objetos pendentes a serem replicados usando o seguinte comando

 [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

Outro motivo pelo qual você executaria o pod do depurador é se houver algumas permissões de sistema de arquivos ou configurações de grupos inválidas em seu pod, você pode atualizá-las usando o pod do depurador

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

O método de depuração acima também pode ser usado em ambientes bare metal. Por exemplo, você pode iniciar um nó busybox ou bastião com mc instalado e seguir as mesmas instruções acima.

Depurando Bare Metal

As instalações bare metal do Linux são as mais diretas. Na verdade, são necessários apenas alguns comandos para instalar o MinIO e executá-lo com o SystemD. Para obter detalhes, consulte Configurando MinIO com SystemD .

De vez em quando, as instalações bare metal dão errado. Aqui estão algumas das armadilhas (não tão comuns) sobre as quais somos questionados em SUB-REDE ou Folga . Essas armadilhas não são específicas do hardware ou da operação, mas podem ser úteis em qualquer tipo de ambiente.

Permissão de arquivo

Uma das armadilhas mais comuns são as permissões de arquivo do binário MinIO e do arquivo de configuração. Se isso ocorrer, ao iniciar o MinIO usando SystemD você verá

Assertion failed for MinIO. e aqui está o rastreamento completo da pilha

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

Isso pode ser causado por vários motivos. Vamos analisar a lista e verificar cada um deles.

Binário MinIO : O binário, neste exemplo localizado em /usr/local/bin/minio precisa ter permissão root:root para usuário e grupo, respectivamente.

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

Usuário e grupo do serviço MinIO : O serviço MinIO precisa ser executado sob um usuário e grupo Linux exclusivo para fins de segurança, nunca executado como um usuário root . Por padrão usamos minio-user para os nomes de usuários e grupos. No arquivo de configuração do serviço SystemD você deverá ver algo assim

 User=minio-user Group=minio-user

MinIO Data Dir : O diretório onde os dados do MinIO serão armazenados precisa pertencer a minio-user:minio-user ou a qualquer usuário que você decidir executar o serviço MinIO como acima.

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

Configuração SystemD e MinIO : Ambos os arquivos de configuração devem ter permissões root:root para usuário e grupo assim

 # 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

Executar como Root : Todo o processo de instalação deve ser executado como root . Você também pode tentar sudo se o seu usuário tiver permissões, mas a recomendação é executar como root, pois a instalação precisa colocar os arquivos em vários locais que somente o usuário root pode acessar. Seu prompt do bash deve ter um # e não um $ assim

# versus $

Se nenhuma das opções acima funcionar, a melhor abordagem é remover o aplicativo, diretórios e configurações e iniciar uma nova instalação como usuário root.

Conflito portuário

Outro problema comum relacionado a arquivos excluídos que ainda permanecem no processo, o que causa conflitos de porta. Mesmo quando um serviço não está em execução, você pode não conseguir iniciar um novo serviço na porta existente ou o serviço que está em execução se comportará mal (como não permitir que você faça login).

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

Você pode ver erros como os abaixo em uma instalação do MinIO

• Falha no login net::ERR_FAILED
• 500 Erro interno do servidor
• 401 não autorizado

A captura de tela acima mostra um erro interno do servidor e um erro não autorizado. Embora olhando superficialmente não esteja claro o que causou esse erro, podemos depurar com um pouco de conhecimento sobre Linux o que procurar que possa causar isso, vamos dar uma olhada.

Existem várias maneiras de depurar esse problema. Primeiro, vamos verificar se vários processos MinIO estão sendo executados no mesmo nó

 # 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

Como podemos ver acima, existem 2 processos MinIO em execução. Comece eliminando o processo mais antigo ou que está em execução há mais tempo; neste caso, parece ser o ID do processo 5048 .

kill -9 5048

Às vezes, mesmo depois de encerrar o processo, o serviço ainda pode não iniciar ou travar porque reservou um número de processo, mas não o deixou ir. Isso pode ser causado por arquivos que foram excluídos, mas ainda estão sendo rastreados pelo sistema operacional. Você pode encontrar os arquivos excluídos via LSOF

lsof -n | grep '(deleted)'

Por último, mas não menos importante, se não sobrarem arquivos excluídos ou processos travados e se tudo parecer absolutamente limpo, o último recurso é reiniciar rapidamente o nó. Este é um método prático que desliga e limpa todos os arquivos e processos pendentes para que você inicie uma nova instalação.

SUBNET para o resgate

Embora raros, sempre existirão casos extremos de instalação. Os clientes do MinIO sabem que não precisam se preocupar porque podem enviar mensagens rapidamente aos nossos engenheiros – que escreveram o código – por meio do SUB-REDE portal. Já vimos quase tudo sob o sol, portanto, embora o problema possa parecer enigmático ou incompreensível à primeira vista, colocaremos nossos anos de experiência em depuração de instalações em diversos ambientes para funcionar e ajudá-lo em um instante.