paint-brush
Automatización de implementaciones de almacenamiento en la nube con MinIO y SystemDby@minio
6,170
6,170

Automatización de implementaciones de almacenamiento en la nube con MinIO y SystemD

MinIO8m2023/08/10
Read on Terminal Reader

La automatización contribuye en gran medida a mantener la disponibilidad cuando se ejecuta un servicio de misión crítica como el almacenamiento de objetos. La automatización es un requisito para operar a escala en múltiples nubes y entornos. Con la ayuda de SystemD y MinIO, puede automatizar sus implementaciones de almacenamiento de objetos en la nube y garantizar que el ciclo de vida del servicio se gestione sin problemas y con éxito.
featured image - Automatización de implementaciones de almacenamiento en la nube con MinIO y SystemD
MinIO HackerNoon profile picture
0-item
1-item
2-item

MinIO es uno de los almacenes de objetos más implementados porque ofrece alto rendimiento, escalabilidad masiva, alta disponibilidad y se adhiere al protocolo S3 estándar de la industria. MinIO es capaz de un rendimiento tremendo: un punto de referencia reciente logró 325 GiB/s (349 GB/s) en GET y 165 GiB/s (177 GB/s) en PUT con solo 32 nodos de SSD NVMe listos para usar. Independientemente de dónde ejecute MinIO (bare metal, instancias virtuales o Kubernetes), el rendimiento y la escalabilidad de MinIO proporcionan una base excelente para aplicaciones nativas de la nube como lagos de datos, análisis, IA/ML y más.


Además de Kubernetes, los clientes ejecutan MinIO en instancias virtuales y bare metal, confiando con frecuencia en el hardware de Supermicro en el centro de datos y nubes como AWS , GCP y Azure . El tamaño reducido de Linux junto con la utilización eficiente de los recursos lo convierten en una opción versátil y flexible para ejecutar MinIO. Sin embargo, la mayor cantidad de máquinas e instancias de Linux requiere automatización para reducir la carga administrativa. Existe la necesidad de administrar los servidores MinIO como un servicio de inicio utilizando SystemD porque ayuda a automatizar el ciclo de vida del servicio, particularmente durante el inicio, el apagado y el reinicio.


SystemD es un administrador de servicios que mantiene los servicios en los sistemas Linux durante el arranque, el apagado, la inicialización y más. Piense en ello como el sucesor de los scripts de inicio en los que tenía que escribir todo desde cero, pero con SystemD solo completa algunos parámetros y los comandos y el registro están estandarizados.


Uno de los varios desafíos de usar la antigua administración de servicios init.d era que tenía que escribir todo el archivo desde cero. Cada archivo init.d era único y tenía una forma diferente de administrar el ciclo de vida del servicio. SystemD toma las lecciones aprendidas de init.d y las estandariza. Por ejemplo, los archivos de servicio de SystemD funcionarán con cualquier servicio siempre que esté escrito para ejecutarse (solo las rutas, los nombres y la semántica son diferentes), pero la estructura básica, cómo reiniciar los servicios, leer registros, desmontar correctamente los sistemas de archivos, esperar que surjan conexiones de red, entre otras cosas, ahora son comunes entre todos los servicios, por lo que no importa qué servicio ejecute, sabrá exactamente dónde buscar sus registros.


SystemD no solo es versátil entre diferentes servicios, sino que puede tomar el mismo archivo de servicio de SystemD y usarlo en varios sistemas operativos, siempre que el sistema operativo también use SystemD para administrar el ciclo de vida de sus servicios. Esto simplifica la automatización, ya que puede estar trabajando en Ubuntu mientras crea el archivo inicial, pero el mismo archivo se puede implementar en el sistema operativo CentOS/RedHat siempre que las rutas y otras cosas sigan siendo las mismas, lo que en la mayoría de los casos es así.


Hay varios componentes principales en SystemD, pero algunos con los que se encontrará más a menudo son:


  • systemctl : Esto es lo que se usa para controlar los procesos, ya sea para detener, iniciar y reiniciar en su mayoría. Los comandos más comunes utilizados son:
    • systemctl start <service>

    • systemctl stop <service>

    • systemctl restart <service>


  • journalctl: los registros de los servicios cuando realizan sus operaciones de inicio, apagado y reinicio. Es una buena manera de obtener información si algo no funciona correctamente. El comando más común que uso, que muestra registros suficientes para llenar la ventana de su terminal y se desplaza hasta el final:
    • journalctl -e -u <service>


Para ejecutar la mayoría de los comandos de esta guía, debe tener acceso `sudo` o root porque los archivos de configuración de SystemD deben tener permiso como root.


También puede encontrar instrucciones adicionales para MinIO y SystemD en nuestro repositorio.

MinIO binario

  • Obtener el binario MinIO de 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]


  • Hágalo ejecutable para que SystemD pueda ejecutar MinIO como un servicio
 # chmod +x minio


  • Muévalo a una ubicación que sea ejecutable bajo $PATH # mv minio /usr/local/bin/

Archivo de servicio

MinIO se puede instalar de diferentes maneras en Linux según el sistema operativo. RedHat/CentOS y sus derivados se basan en el paquete .rpm y Debian/Ubuntu usan el paquete .deb. En ambos casos, el siguiente archivo de servicio de SystemD se incluye en el paquete de instalación.


Sin embargo, obtuvimos manualmente el binario MinIO desde arriba, por lo que crearemos manualmente el archivo de servicio SystemD.


  • Use su editor de texto favorito para crear un archivo SystemD en /etc/systemd/system/minio.service con los siguientes contenidos.


 [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 : El grupo del sistema Linux en el que se ejecutará el demonio Minio. Créalo usando el siguiente comando:


    • groupadd -r minio-user


  • User=minio-user : El usuario del sistema Linux con el que se ejecutará el demonio MinIO. Crea el usuario usando el siguiente comando:


    • useradd -M -r -g minio-user minio-user
      • -M : Esto evita la creación de un directorio de inicio para el usuario ya que se trata de un servicio.
      • -r : los usuarios de los sistemas tienen un rango UID/GID separado para fines de seguimiento, este indicador creará el usuario a partir del rango predeterminado.
      • -g <group_name> : Grupo para agregar el usuario.


E/S mínima

Configuración distribuida

Hay un par de requisitos previos que se requieren para configurar el nodo bare metal antes de que se pueda iniciar el servicio MinIO.


  • Cree un nuevo disco y asegúrese de que no esté en la misma partición que el volumen raíz, para evitar el siguiente mensaje:
    • Error: Disk /mnt/disk1/minio is part of root disk, will not be used


  • Cree 4 directorios en su host local donde acaba de montar el nuevo disco, en este caso /mnt/data :


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


  • chown los directorios con el usuario y grupo MinIO
    • chown minio-user:minio-user /mnt/data/disk1 /mnt/data/disk2 /mnt/data/disk3 /mnt/data/disk4

Archivos de servicios ambientales

  • Actualice este archivo /etc/default/minio con el siguiente contenido


 # 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 el proceso MinIO

  • Tenemos todas las piezas que necesitamos para habilitar e iniciar el servicio
 # systemctl enable minio.service # systemctl start minio.service


  • Consultar el estado del servicio y los registros
 # systemctl status minio.service # journalctl -e -u minio.service


  • Verifique que haya aparecido el servicio MinIO. En los registros debería ver algo similar a esto:


 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

Iniciar sesión en la consola

Usando un navegador, inicie sesión en la consola MinIO usando MINIO_ROOT_USER y MINIO_ROOT_PASSWORD de la configuración que hicimos anteriormente.


 http://<server_host_ip>:9001/ 



Tenga en cuenta que la configuración anterior es para que pueda comenzar a utilizar MinIO rápidamente. Puede expandirse de un solo nodo a una configuración distribuida de varios nodos para realizar pruebas adicionales. Si desea implementar y configurar MinIO en un entorno de producción, consulte la documentación .

SystemD simplifica las implementaciones virtuales y bare metal de MinIO

La integración con SystemD es muy versátil.


  • La sintaxis del archivo de servicio es la misma en todos los servicios

  • El mismo archivo de servicio funcionará en cualquier sistema operativo compatible con SystemD

  • Puede usar SystemD con hardware dedicado o en máquinas virtuales en cualquier nube, como AWS, GCP y Azure.

  • Esto puede ayudar con la automatización de DevOps al estandarizar el formato y simplificar la automatización de las implementaciones.


La automatización contribuye en gran medida a mantener la disponibilidad cuando se ejecuta un servicio de misión crítica como el almacenamiento de objetos. La automatización es un requisito para operar a escala en múltiples nubes y entornos. Con la ayuda de SystemD y MinIO, puede automatizar sus implementaciones de almacenamiento de objetos en la nube y garantizar que el ciclo de vida del servicio se gestione sin problemas y con éxito.


¿Tienes preguntas? ¿Quieres empezar? Comuníquese con nosotros en Slack .


También publicado aquí .