paint-brush
Automatizando implantações de armazenamento em nuvem com MinIO e SystemDpor@minio
6,183 leituras
6,183 leituras

Automatizando implantações de armazenamento em nuvem com MinIO e SystemD

por MinIO8m2023/08/10
Read on Terminal Reader

Muito longo; Para ler

A automação ajuda muito a manter a disponibilidade ao executar um serviço de missão crítica, como o armazenamento de objetos. A automação é um requisito para operar em escala em várias nuvens e ambientes. Com a ajuda do SystemD e do MinIO, você pode automatizar suas implantações de armazenamento de objetos em nuvem e garantir que o ciclo de vida do serviço seja gerenciado sem problemas e com sucesso.
featured image - Automatizando implantações de armazenamento em nuvem com MinIO e SystemD
MinIO HackerNoon profile picture
0-item
1-item
2-item

O MinIO é um dos armazenamentos de objetos mais amplamente implementados porque oferece alto desempenho, escalabilidade massiva, alta disponibilidade e adere ao protocolo S3 padrão do setor. O MinIO é capaz de um desempenho tremendo - um benchmark recente alcançou 325 GiB/s (349 GB/s) em GETs e 165 GiB/s (177 GB/s) em PUTs com apenas 32 nós de SSDs NVMe prontos para uso. Não importa onde você execute o MinIO – bare metal, instâncias virtuais ou Kubernetes – o desempenho e a escalabilidade do MinIO fornecem uma base excelente para aplicativos nativos da nuvem, como data lakes, análises, AI/ML e muito mais.


Além do Kubernetes, os clientes executam MinIO em instâncias virtuais e bare metal, frequentemente contando com hardware da Supermicro no datacenter e nuvens como AWS , GCP e Azure . O tamanho reduzido do Linux, juntamente com a utilização eficiente de recursos, o torna uma escolha versátil e flexível para executar o MinIO. No entanto, o maior número de máquinas e instâncias Linux requer automação para reduzir a carga administrativa. Existe a necessidade de gerenciar servidores MinIO como um serviço init usando SystemD porque ajuda a automatizar o ciclo de vida do serviço, principalmente durante a inicialização, desligamento e reinicialização.


SystemD é um gerenciador de serviços que mantém serviços em sistemas Linux durante a inicialização, desligamento, inicialização e muito mais. Pense nisso como o sucessor dos scripts de inicialização onde você tinha que escrever tudo do zero, mas com o SystemD você apenas preenche alguns parâmetros e os comandos e logs são padronizados.


Um dos vários desafios de usar o antigo gerenciamento de serviço init.d era que você tinha que escrever todo o arquivo do zero. Cada arquivo init.d era único e tinha uma maneira diferente de gerenciar o ciclo de vida do serviço. O SystemD pega as lições aprendidas com o init.d e as padroniza. Por exemplo, os arquivos de serviço do SystemD funcionarão com qualquer serviço, desde que seja escrito para executar - apenas os caminhos, nomes e semântica são diferentes - mas a estrutura básica, como reiniciar serviços, ler logs, desmontar sistemas de arquivos normalmente, aguardar para o surgimento de conexões de rede, entre outras coisas, agora são comuns entre todos os serviços, portanto, não importa qual serviço você execute, você saberá exatamente onde procurar seus logs.


O SystemD não é apenas versátil entre diferentes serviços, mas você pode pegar o mesmo arquivo de serviço SystemD e usá-lo em vários sistemas operacionais, desde que o sistema operacional também esteja usando o SystemD para gerenciar o ciclo de vida de seus serviços. Isso simplifica a automação, pois você pode trabalhar no Ubuntu enquanto cria o arquivo inicial, mas o mesmo arquivo pode ser implantado no sistema operacional CentOS/RedHat, desde que os caminhos e outras coisas permaneçam os mesmos, o que acontece na maioria dos casos.


Existem vários componentes principais do SystemD, mas alguns que você encontrará com mais frequência são:


  • systemctl : É o que é usado para controlar os processos, seja para parar, iniciar e reiniciar principalmente. Os comandos mais comuns usados são:
    • systemctl start <service>

    • systemctl stop <service>

    • systemctl restart <service>


  • journalctl: Os logs dos serviços quando eles executam suas operações de inicialização, desligamento e reinicialização. É uma boa maneira de obter informações se algo não estiver funcionando corretamente. O comando mais comum que uso, que mostra logs suficientes para preencher a janela do terminal e rolar até o final:
    • journalctl -e -u <service>


Para executar a maioria dos comandos neste guia, você precisa ter `sudo` ou acesso root porque os arquivos de configuração do SystemD precisam ter permissão de root.


Você também pode encontrar instruções adicionais para MinIO e SystemD em nosso repositório.

Binário MinIO

  • Buscar o binário MinIO do upstream


 # wget https://dl.min.io/server/minio/release/linux-amd64/minio --2022-07-24 11:31:33-- https://dl.min.io/server/minio/release/linux-amd64/minio Resolving dl.min.io (dl.min.io)... 132.68.11.115, 138.118.66.212 Connecting to dl.min.io (dl.min.io)|132.68.11.115|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 96649216 (92M) [application/octet-stream] Saving to: 'minio' minio 100%[==========================================>] 92.17M 50.2MB/s in 1.8s 2022-07-24 11:31:35 (50.2 MB/s) - 'minio' saved [96649216/96649216]


  • Torne-o executável para que o SystemD possa executar o MinIO como um serviço
 # chmod +x minio


  • Mova-o para um local executável em $PATH # mv minio /usr/local/bin/

Arquivo de serviço

O MinIO pode ser instalado de algumas maneiras diferentes no Linux com base no sistema operacional. RedHat/CentOS e seus derivados dependem do pacote .rpm e Debian/Ubuntu usam o pacote .deb. Em ambos os casos, o seguinte arquivo de serviço SystemD está incluído no pacote de instalação.


No entanto, buscamos manualmente o binário MinIO do upstream, portanto, criaremos manualmente o arquivo de serviço SystemD.


  • Use seu editor de texto favorito para criar um arquivo SystemD em /etc/systemd/system/minio.service com o seguinte conteúdo.


 [Unit] Description=MinIO Documentation=https://docs.min.io Wants=network-online.target After=network-online.target AssertFileIsExecutable=/usr/local/bin/minio [Service] WorkingDirectory=/usr/local User=minio-user Group=minio-user ProtectProc=invisible EnvironmentFile=-/etc/default/minio ExecStartPre=/bin/bash -c "if [ -z \"${MINIO_VOLUMES}\" ]; then echo \"Variable MINIO_VOLUMES not set in /etc/default/minio\"; exit 1; fi" ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES # Let systemd restart this service always Restart=always # Specifies the maximum file descriptor number that can be opened by this process LimitNOFILE=65536 # Specifies the maximum number of threads this process can create TasksMax=infinity # Disable timeout logic and wait until process is stopped TimeoutStopSec=infinity SendSIGKILL=no [Install] WantedBy=multi-user.target # Built for ${project.name}-${project.version} (${project.name})


  • Group=minio-user : O grupo do sistema Linux no qual o daemon do Minio será executado. Crie-o usando o seguinte comando:


    • groupadd -r minio-user


  • User=minio-user : O usuário do sistema Linux com o qual o daemon MinIO será executado. Crie o usuário usando o seguinte comando:


    • useradd -M -r -g minio-user minio-user
      • -M : Isso evita a criação de um diretório inicial para o usuário, pois é um serviço.
      • -r : Os usuários do sistema têm um intervalo UID/GID separado para fins de rastreamento, este sinalizador criará o usuário a partir do intervalo predeterminado.
      • -g <group_name> : Grupo ao qual adicionar o usuário.


MinIO

Configuração Distribuída

Há alguns pré-requisitos necessários para configurar o nó bare metal antes que o serviço MinIO possa ser iniciado.


  • Crie um novo disco e verifique se ele não está na mesma partição que o volume raiz, para evitar a seguinte mensagem:
    • Error: Disk /mnt/disk1/minio is part of root disk, will not be used


  • Crie 4 diretórios em seu host local onde o novo disco acabou de ser montado, neste caso /mnt/data :


 mkdir -p /mnt/data/disk1 \ mkdir -p /mnt/data/disk2 \ mkdir -p /mnt/data/disk3 \ mkdir -p /mnt/data/disk4


  • chown os diretórios com o usuário e grupo MinIO
    • chown minio-user:minio-user /mnt/data/disk1 /mnt/data/disk2 /mnt/data/disk3 /mnt/data/disk4

Arquivos de serviço de ambiente

  • Atualize este arquivo /etc/default/minio com o seguinte conteúdo


 # Set the hosts and volumes MinIO uses at startup # The command uses MinIO expansion notation {x...y} to denote a # sequential series. # # The following example covers four MinIO hosts # with 4 drives each at the specified hostname and drive locations. # The command includes the port that each MinIO server listens on # (default 9000) MINIO_VOLUMES="https://minio1.example.com:9000/mnt/data/disk{1...4}/minio" # Set all MinIO server options # # The following explicitly sets the MinIO Console listen address to # port 9001 on all network interfaces. The default behavior is dynamic # port selection. MINIO_OPTS="--console-address :9001" # Set the root username. This user has unrestricted permissions to # perform S3 and administrative API operations on any resource in the # deployment. # # Defer to your organizations requirements for superadmin user name. MINIO_ROOT_USER=minioadmin # Set the root password # # Use a long, random, unique string that meets your organizations # requirements for passwords. MINIO_ROOT_PASSWORD=minioadmin # Set to the URL of the load balancer for the MinIO deployment # This value *must* match across all MinIO servers. If you do # not have a load balancer, set this value to to any *one* of the # MinIO hosts in the deployment as a temporary measure. MINIO_SERVER_URL="https://minio.example.net:9000"

Inicie o processo MinIO

  • Temos todas as peças que precisamos para habilitar e iniciar o serviço
 # systemctl enable minio.service # systemctl start minio.service


  • Verifique o status do serviço e dos logs
 # systemctl status minio.service # journalctl -e -u minio.service


  • Verifique se o serviço MinIO foi ativado. Nos logs você deve ver algo parecido com isto:


 Aug 01 13:27:06 aj-test-3 systemd[1]: Starting MinIO... Aug 01 13:27:06 aj-test-3 systemd[1]: Started MinIO. Aug 01 13:27:07 aj-test-3 minio[3241]: Formatting 1st pool, 1 set(s), 4 drives per set. Aug 01 13:27:07 aj-test-3 minio[3241]: WARNING: Host minio1.example.com:9000 has more than 2 drives of set. A host fai> Aug 01 13:27:07 aj-test-3 minio[3241]: You are running an older version of MinIO released 4 days ago Aug 01 13:27:07 aj-test-3 minio[3241]: Update: Run `mc admin update` Aug 01 13:27:07 aj-test-3 minio[3241]: MinIO Object Storage Server Aug 01 13:27:07 aj-test-3 minio[3241]: Copyright: 2015-2022 MinIO, Inc. Aug 01 13:27:07 aj-test-3 minio[3241]: License: GNU AGPLv3 <https://www.gnu.org/licenses/agpl-3.0.html> Aug 01 13:27:07 aj-test-3 minio[3241]: Version: RELEASE.2022-07-26T00-53-03Z (go1.18.4 linux/amd64) Aug 01 13:27:07 aj-test-3 minio[3241]: Status: 4 Online, 0 Offline. Aug 01 13:27:07 aj-test-3 minio[3241]: API: https://minio.example.net:9000 Aug 01 13:27:07 aj-test-3 minio[3241]: Console: http://10.128.0.4:9001 http://127.0.0.1:9001 Aug 01 13:27:07 aj-test-3 minio[3241]: Documentation: https://docs.min.io

Faça login no console

Usando um navegador, faça login no console MinIO usando o MINIO_ROOT_USER e MINIO_ROOT_PASSWORD da configuração que fizemos anteriormente.


 http://<server_host_ip>:9001/ 



Observe que a configuração acima é para você começar a usar o MinIO rapidamente. Você pode expandir de um único nó para uma configuração distribuída de vários nós para testes adicionais. Se você deseja implantar e configurar o MinIO em um ambiente de produção, consulte a documentação .

SystemD Simplifica Implantações MinIO Virtual e Bare Metal

A integração com o SystemD é muito versátil.


  • A sintaxe do arquivo de serviço é a mesma em todos os serviços

  • O mesmo arquivo de serviço funcionará em qualquer sistema operacional compatível com SystemD

  • Você pode usar o SystemD com bare metal ou em VMs em qualquer nuvem, como AWS, GCP e Azure.

  • Isso pode ajudar na automação do DevOps, padronizando o formato e simplificando a automatização das implantações.


A automação ajuda muito a manter a disponibilidade ao executar um serviço de missão crítica, como o armazenamento de objetos. A automação é um requisito para operar em escala em várias nuvens e ambientes. Com a ajuda do SystemD e do MinIO, você pode automatizar suas implantações de armazenamento de objetos em nuvem e garantir que o ciclo de vida do serviço seja gerenciado sem problemas e com sucesso.


Tem perguntas? Quer começar? Entre em contato conosco no Slack .


Publicado também aqui .