Automatisation des déploiements de stockage cloud avec MinIO et SystemD

MinIO est l'un des magasins d'objets les plus largement implémentés car il offre des performances élevées, une évolutivité massive, une haute disponibilité et adhère au protocole S3 standard de l'industrie. MinIO est capable de performances exceptionnelles - une référence récente a atteint 325 Gio/s (349 Go/s) sur les GET et 165 Gio/s (177 Go/s) sur les PUT avec seulement 32 nœuds de SSD NVMe prêts à l'emploi. Quel que soit l'endroit où vous exécutez MinIO (bare metal, instances virtuelles ou Kubernetes), les performances et l'évolutivité de MinIO constituent une excellente base pour des applications cloud natives telles que les lacs de données, l'analyse, l'IA/ML, etc.

En plus de Kubernetes, les clients exécutent MinIO sur des instances virtuelles et du bare metal, s'appuyant fréquemment sur du matériel Supermicro dans le centre de données et des clouds comme AWS , GCP et Azure . Le faible encombrement de Linux associé à une utilisation efficace des ressources en font un choix polyvalent et flexible pour l'exécution de MinIO. Pourtant, le plus grand nombre de machines et d'instances Linux nécessite une automatisation pour réduire la charge administrative. Il est nécessaire de gérer les serveurs MinIO en tant que service d'initialisation à l'aide de SystemD car cela permet d'automatiser le cycle de vie du service, en particulier lors du démarrage, de l'arrêt et du redémarrage.

SystemD est un gestionnaire de services qui gère les services dans les systèmes Linux pendant le démarrage, l'arrêt, l'initialisation et plus encore. Considérez-le comme le successeur des scripts d'initialisation où vous deviez tout écrire à partir de zéro, mais avec SystemD, vous ne remplissez que quelques paramètres et les commandes et la journalisation sont standardisées.

L'un des nombreux défis liés à l'utilisation de l'ancienne gestion de service init.d était que vous deviez écrire le fichier entier à partir de zéro. Chaque fichier init.d était unique et avait une manière différente de gérer le cycle de vie du service. SystemD prend les leçons apprises de init.d et les standardise. Par exemple, les fichiers de service SystemD fonctionneront avec n'importe quel service tant qu'il est écrit pour s'exécuter - seuls les chemins, les noms et la sémantique sont différents - mais la structure de base, comment redémarrer les services, lire les journaux, démonter gracieusement les systèmes de fichiers, attendre les connexions réseau à venir, entre autres, sont maintenant communes à tous les services, donc quel que soit le service que vous exécutez, vous savez exactement où chercher ses journaux.

Non seulement SystemD est polyvalent parmi différents services, mais vous pouvez prendre le même fichier de service SystemD et l'utiliser sur plusieurs systèmes d'exploitation, tant que le système d'exploitation utilise également SystemD pour gérer le cycle de vie de ses services. Cela simplifie l'automatisation car vous pouvez travailler sur Ubuntu lors de la création du fichier initial, mais le même fichier peut ensuite être déployé sur le système d'exploitation CentOS/RedHat tant que les chemins et autres éléments restent les mêmes, ce qui est le cas dans la plupart des cas.

Il existe plusieurs composants principaux de SystemD, mais certains que vous rencontrerez plus souvent sont :

• systemctl : C'est ce qui est utilisé pour contrôler les processus, qu'il s'agisse d'arrêter, de démarrer et de redémarrer principalement. Les commandes les plus couramment utilisées sont :

  • systemctl start <service>

  • systemctl stop <service>

  • systemctl restart <service>

    
    

• journalctl : les journaux des services lorsqu'ils effectuent leurs opérations de démarrage, d'arrêt et de redémarrage. C'est un bon moyen d'avoir un aperçu si quelque chose ne fonctionne pas correctement. La commande la plus courante que j'utilise, qui affiche suffisamment de journaux pour remplir la fenêtre de votre terminal et défile jusqu'à la fin :

  • journalctl -e -u <service>

    
    

Pour exécuter la plupart des commandes de ce guide, vous devez disposer d'un accès "sudo" ou root, car les fichiers de configuration SystemD doivent être autorisés en tant que root.

Vous pouvez également trouver des instructions supplémentaires pour MinIO et SystemD dans notre référentiel.

Binaire MinIO

• Récupérer le binaire MinIO en amont

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

• Rendez-le exécutable pour que SystemD puisse exécuter MinIO en tant que service

 # chmod +x minio

• Déplacez-le vers un emplacement exécutable sous $PATH # mv minio /usr/local/bin/

Fichier de services

MinIO peut être installé de différentes manières sur Linux en fonction du système d'exploitation. RedHat/CentOS et ses dérivés reposent sur le package .rpm et Debian/Ubuntu utilisent le package .deb. Dans les deux cas, le fichier de service SystemD suivant est inclus dans le package d'installation.

Cependant, nous avons récupéré manuellement le binaire MinIO en amont, nous allons donc créer manuellement le fichier de service SystemD.

• Utilisez votre éditeur de texte préféré pour créer un fichier SystemD dans /etc/systemd/system/minio.service avec le contenu suivant.

 [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 : Le groupe système Linux sous lequel le démon Minio sera exécuté. Créez-le à l'aide de la commande suivante :

  
  

  • groupadd -r minio-user

    
    

• User=minio-user : L'utilisateur du système Linux sous lequel le démon MinIO sera exécuté. Créez l'utilisateur à l'aide de la commande suivante :

  
  

  • useradd -M -r -g minio-user minio-user
    • -M : Cela empêche la création d'un répertoire personnel pour l'utilisateur puisqu'il s'agit d'un service.
    • -r : les utilisateurs des systèmes ont une plage UID/GID distincte à des fins de suivi, cet indicateur créera l'utilisateur à partir de la plage prédéterminée.
    • -g <group_name> : Groupe sous lequel ajouter l'utilisateur.

  
  

MinIO

Configuration distribuée

Quelques conditions préalables sont requises pour la configuration sur le nœud bare metal avant que le service MinIO puisse être démarré.

• Créez un nouveau disque et assurez-vous qu'il ne se trouve pas sur la même partition que le volume racine, pour éviter le message suivant :

  • Error: Disk /mnt/disk1/minio is part of root disk, will not be used

    
    

• Créez 4 répertoires sur votre hôte local où le nouveau disque vient d'être monté, dans ce cas /mnt/data :

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

• chown les répertoires avec l'utilisateur et le groupe MinIO
  • chown minio-user:minio-user /mnt/data/disk1 /mnt/data/disk2 /mnt/data/disk3 /mnt/data/disk4

Fichiers de service d'environnement

• Mettez à jour ce fichier /etc/default/minio avec le contenu suivant

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

Démarrer le processus MinIO

• Nous avons toutes les pièces dont nous avons besoin pour activer et démarrer le service

 # systemctl enable minio.service # systemctl start minio.service

• Vérifier l'état du service et des journaux

 # systemctl status minio.service # journalctl -e -u minio.service

• Vérifiez que le service MinIO est activé. Dans les journaux, vous devriez voir quelque chose de similaire à ceci :

 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

Connectez-vous à la console

À l'aide d'un navigateur, connectez-vous à la console MinIO en utilisant MINIO_ROOT_USER et MINIO_ROOT_PASSWORD à partir de la configuration que nous avons effectuée précédemment.

 http://<server_host_ip>:9001/ 

Notez que la configuration ci-dessus vous permet de vous familiariser rapidement avec MinIO. Vous pouvez passer d'un nœud unique à une configuration distribuée à plusieurs nœuds pour des tests supplémentaires. Si vous souhaitez déployer et configurer MinIO dans un environnement de production, veuillez vous référer à la documentation .

SystemD simplifie les déploiements MinIO Virtual et Bare Metal

L'intégration avec SystemD est très polyvalente.

• La syntaxe du fichier de service est la même pour tous les services

• Le même fichier de service fonctionnera sur tous les systèmes d'exploitation prenant en charge SystemD

• Vous pouvez utiliser SystemD avec du métal nu ou sur des machines virtuelles dans n'importe quel cloud tel qu'AWS, GCP et Azure.

• Cela peut aider à l'automatisation de DevOps en normalisant le format et en simplifiant l'automatisation des déploiements.

  
  

L'automatisation contribue grandement au maintien de la disponibilité lors de l'exécution d'un service critique comme le stockage d'objets. L'automatisation est une exigence pour fonctionner à grande échelle sur plusieurs clouds et environnements. Avec l'aide de SystemD et MinIO, vous pouvez automatiser vos déploiements de stockage d'objets dans le cloud et vous assurer que le cycle de vie du service est géré de manière fluide et réussie.

Vous avez des questions ? Vous voulez commencer ? Contactez-nous sur Slack .