Configuring MinIO with SystemD

MinIO is one of the most widely implemented object stores because it offers high-performance, massive scalability, high-availability and adheres to the industry-standard S3 protocol. MinIO is capable of tremendous performance - a recent benchmark achieved 325 GiB/s (349 GB/s) on GETs and 165 GiB/s (177 GB/s) on PUTs with just 32 nodes of off-the-shelf NVMe SSDs. No matter where you run MinIO – bare metal, virtual instances or Kubernetes – MinIO’s performance and scalability provide an excellent foundation for such cloud-native applications as data lakes, analytics, AI/ML and more.

In addition to Kubernetes, customers run MinIO on virtual instances and bare metal, frequently relying on Supermicro hardware in the datacenter and clouds like AWS, GCP and Azure. Linux’s small footprint coupled with efficient resource utilization make it a versatile and flexible choice for running MinIO. Yet, the greater numbers of Linux machines and instances require automation to reduce administrative burden. There is a need for managing MinIO servers as an init service using SystemD because it helps to automate the service lifecycle, particularly during startup, shutdown and restart.

SystemD is a service manager that maintains services in Linux systems during boot up, shutdown, initialization and more. Think of it as the successor to init scripts where you had to write the whole thing from scratch, but with SystemD you just fill in a few parameters and the commands and logging are standardized.

One of the several challenges of using the older init.d service management was that you had to write the entire file from scratch. Each init.d file was unique and had a different way of managing the lifecycle of the service. SystemD takes the lessons learned from init.d and standardizes them. For instance, the SystemD service files will work any service as long as it's written to run – only the paths, names, and semantics are different – but the basic structure, how to restart services, reading logs, gracefully un-mounting filesystems, waiting for network connections to come up, among other things, are now common among all services, so no matter which service you run you know exactly where to look for its logs.

Not only is SystemD versatile among different services, but you can take the same SystemD service file and use it across multiple operating systems, as long as the operating system is also using SystemD to manage the lifecycle of its services. This simplifies automation as you can be working on Ubuntu while creating the initial file, but the same file can then be deployed to CentOS/RedHat operating system as long as the paths and other things remain the same, which in most cases they do.

There are several main components to SystemD but a few that you will come across more often are:

• systemctl: This is what is used to control the processes, whether to stop, start and restart mostly. The most common commands used are:
  • systemctl start <service>
  • systemctl stop <service>
  • systemctl restart <service>
• journalctl: The logs for the services when they do their startup, shutdown and restart operations. It’s a good way to get insight if something is not working properly. The most common command I use, which shows logs enough to fill up your terminal window and scrolls to the very end:
  • journalctl -e -u <service>

To run most of the commands in this guide you need to have `sudo` or root access because SystemD config files need to be permissioned as root.

You can also find additional instructions for MinIO and SystemD in our repository.

MinIO Binary

• Fetch the MinIO binary from upstream

• Make it executable so SystemD can run MinIO as a service

• Move it to a location that is executable under $PATH

Service File

MinIO can be installed in a few different ways on Linux based on the operating system. RedHat/CentOS and its derivatives rely on the.rpm package and Debian/Ubuntu  use the .deb package. In both cases, the following SystemD service file is included in the installation package.

However, we manually fetched the MinIO binary from upstream, so we’ll manually create the SystemD service file.

• Use your favorite text editor to create a SystemD file at /etc/systemd/system/minio.service with the following contents.

• Group=minio-user: The Linux system group the Minio daemon will run as. Create it using the following command:
  • groupadd -r minio-user
• User=minio-user: The Linux system user the MinIO daemon will run as. Create the user using the following command:
  • useradd -M -r -g minio-user minio-user
    • -M: This prevents creating a home directory for the user since this is a service.
    • -r: Systems users have a separate UID/GID range for tracking purposes, this flag will create the user from the predetermined range.
    • -g <group_name>: Group to add the user under.

MinIO

Distributed Setup

There are a couple of prerequisites that are required to set up on the bare metal node before MinIO service can be started.

• Create a new disk and ensure it is not on the same partition as root volume, to avoid the following message:
  • Error: Disk /mnt/disk1/minio is part of root disk, will not be used

• Create 4 directories on your local host where the new disk was just mounted, in this case /mnt/data:

• chown the directories with the MinIO user and group
  • chown minio-user:minio-user /mnt/data/disk1 /mnt/data/disk2 /mnt/data/disk3 /mnt/data/disk4

Environment Service Files

• Update this file  /etc/default/minio with the following content

Start the MinIO Process

• We have all the pieces we need to enable and start the service

• Check the status of the service and logs

• Verify that the MinIO service has come up. In the logs you should see something similar to this

Log in to Console

Using a browser, log in to the MinIO console using the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD from the configuration we made earlier.

Note the above setup is for you to quickly get up and running with MinIO. You can expand from a single node to a multi-node distributed configuration for additional testing. If you would like to deploy and configure MinIO  in a production environment, please refer to the documentation.

SystemD Simplifies MinIO Virtual and Bare Metal Deployments

Integration with SystemD is very versatile.

• The syntax of the service file is the same across all services
• The same service file will work across any OS that supports SystemD
• You can use SystemD with bare metal or on VMs in any cloud such as AWS, GCP and Azure.
• This can help with automation for DevOps by standardizing the format and making it simple to automate deployments.

Automation goes a long way towards maintaining availability when running a mission critical service like object storage. Automation is a requirement for operating at scale across multiple clouds and environments. With the help of SystemD and MinIO you can automate your cloud object storage deployments and ensure the service lifecycle is managed smoothly and successfully.

Got questions? Want to get started? Reach out to us on  Slack.