MINIO Cluster Model

MINIO is the compatibility module name for object storage. Pigsty v4.5.0 deploys Silo with minio_type: silo. It groups object storage instances into a cluster.

Each cluster is an autonomous S3-compatible object store with at least one instance. It exposes services through the S3 API port.

There are three core entities in Pigsty’s MINIO module:

• Cluster: An autonomous object storage service unit and the top-level namespace for other entities.
• Instance: One Silo server process on a node, managing local disks.
• Node: An implicitly declared hardware resource that runs Linux and Systemd.

Silo also retains the Storage Pool concept for expansion.

Deployment Modes

Silo supports Pigsty’s three inventory deployment modes:

For a quick SNSD experiment, you can use a regular directory. For multiple drives, use real disk mount points. Otherwise, Silo refuses to start.

Examples

This example explicitly selects Silo, the current default backend, and defines a four-node cluster with multiple drives:

minio:
  hosts:
    10.10.10.10: { minio_seq: 1 }
    10.10.10.11: { minio_seq: 2 }
    10.10.10.12: { minio_seq: 3 }
    10.10.10.13: { minio_seq: 4 }
  vars:
    minio_cluster: minio
    minio_type: silo
    minio_data: '/data{1...4}'
    minio_node: '${minio_cluster}-${minio_seq}.pigsty'

The configuration defines four Silo nodes with four disks each. Instance identifiers retain MINIO compatibility names:

Identity Parameters

The MINIO parameter group assigns deterministic identities to MINIO entities. Two parameters are required:

Set the cluster name at cluster level and the instance number at instance level. Pigsty generates unique identifiers with these rules:

MINIO uses the existing hostname or IP address as the host node identity. It does not assign another identity. minio_node generates internal Silo node names for cluster discovery in /etc/hosts. These names do not identify the host node.

Roles find members throughout the inventory by minio_cluster. The Ansible group name can differ from the cluster name. The retained backend selector minio_type currently must be silo.

Core Configuration Parameters

These parameters are also critical for Silo cluster configuration:

These parameters determine minio_volumes, which the role writes to Silo’s MINIO_VOLUMES:

• SNSD: Direct minio_data value, e.g., /data/minio
• SNMD: Expanded minio_data directories, e.g., /data{1...4}
• MNMD: Combined minio_node and minio_data, e.g., https://minio-{1...4}.pigsty:9000/data{1...4}

Ports & Services

Each object-storage instance listens on the following ports:

MINIO enables HTTPS by default through minio_https. For the default pgBackRest S3 repository configuration, keep HTTPS enabled and install the Pigsty CA correctly.

Clients can reach a multi-node Silo cluster through any member. For a stable entry point, use a load balancer such as HAProxy with a VIP.

Resource Provisioning

After deployment, Pigsty creates these Silo resources. minio_provision controls this step:

Default Buckets (defined by minio_buckets):

Default Users (defined by minio_users):

These public default credentials are only for demonstrations and local development. Replace them before production deployment.

pgbackrest serves PostgreSQL cluster backups. The reserved users s3user_meta and s3user_data are not actively used.

Monitoring Label System

Pigsty uses these identity parameters to identify object storage entities. This example shows a Silo availability series:

minio_up{cls="minio", ins="minio-1", ip="10.10.10.10", job="minio"}
minio_up{cls="minio", ins="minio-2", ip="10.10.10.11", job="minio"}
minio_up{cls="minio", ins="minio-3", ip="10.10.10.12", job="minio"}
minio_up{cls="minio", ins="minio-4", ip="10.10.10.13", job="minio"}

cls, ins, and ip identify the cluster name, instance name, and node IP. For monitoring compatibility, job="minio" remains unchanged. The current backend label is flavor=silo. See the metric list for details.