Deploy Buckit on RedHat Linux
This page documents deploying Buckit on RedHat Linux operating systems, including distributions that are binary-compatible with RHEL. This page makes no distinction or special remarks between RHEL and those distributions, and guidance given for RHEL can typically be applied to those distributions.
Buckit strongly recommends that production deployments use RHEL versions in the Full Support or Maintenance Support phases of the Red Hat life cycle. At the time of writing, that includes:
RHEL 9.5+ (Recommended)
RHEL 8.10+
Your organization should have the necessary service contracts with Red Hat to ensure end-to-end supportability of your deployments.
Buckit may run on versions of RHEL no longer supported by Red Hat Linux, with limited support or troubleshooting from either Buckit or RedHat.
The procedure focuses on production-grade Multi-Node Multi-Drive (MNMD) “Distributed” configurations. MNMD deployments provide enterprise-grade performance, availability, and scalability and are the recommended topology for all production workloads.
The procedure includes guidance for deploying Single-Node Multi-Drive (SNMD) and Single-Node Single-Drive (SNSD) topologies in support of early development and evaluation environments.
Considerations
Review Checklists
Ensure you have reviewed our published Hardware, Software, and Security checklists before attempting this procedure.
Erasure Coding Parity
Buckit automatically determines the default erasure coding configuration for the cluster based on the total number of nodes and drives in the topology.
You can configure the per-object parity setting when you set up the cluster or let Buckit select the default (EC:4 for production-grade clusters).
Parity controls the relationship between object availability and storage on disk. Use the Erasure Code Calculator for guidance in selecting the appropriate erasure code parity level for your cluster.
While you can change erasure parity settings at any time, objects written with a given parity do not automatically update to the new parity settings.
Capacity-Based Planning
Buckit recommends planning storage capacity sufficient to store at least 2 years of data before reaching 70% usage. Performing server pool expansion more frequently or on a “just-in-time” basis generally indicates an architecture or planning issue.
For example, consider an application suite expected to produce at least 100 TiB of data per year and a 3 year target before expansion. By ensuring the deployment has ~500TiB of usable storage up front, the cluster can safely meet the 70% threshold with additional buffer for growth in data storage output per year.
Consider using the Erasure Code Calculator for guidance in planning capacity around specific erasure code settings.
Procedure
1. Download and install the Buckit RPM
Use the following commands to download, verify, and install the Buckit RPM for your Linux host.
curl -fsSL https://buckit-io.github.io/buckit/install-linux.sh | sh
sudo dnf install ./buckit.rpm
2. Review the systemd Service File
The RPM installs the Buckit binary at /usr/local/bin/buckit and the
following systemd
service file at /lib/systemd/system/buckit.service:
[Unit]
Description=Buckit Object Storage
Documentation=https://github.com/buckit-io/buckit
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/buckit
[Service]
Type=notify
WorkingDirectory=/usr/local
User=buckit
Group=buckit
ProtectProc=invisible
EnvironmentFile=-/etc/default/minio
ExecStart=/usr/local/bin/buckit 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=1048576
# Turn-off memory accounting by systemd, which is buggy.
MemoryAccounting=no
# Specifies the maximum number of threads this process can create
TasksMax=infinity
# Disable timeout logic and wait until process is stopped
TimeoutSec=infinity
OOMScoreAdjust=-1000
SendSIGKILL=no
[Install]
WantedBy=multi-user.target
3. Review the Buckit Service Account
The package post-install script automatically creates the buckit system
user and group if they do not already exist.
You must chown the drive paths you intend to use with Buckit so the
buckit user can access them.
For example, the following command sets buckit:buckit as the user-group
owner of all drives at /mnt/drives-n where n is between 1 and 16
inclusive:
chown -R buckit:buckit /mnt/drives-{1...16}
4. Enable TLS Connectivity
Create or provide Transport Layer Security (TLS) certificates to Buckit to automatically enable HTTPS-secured connections between the server and clients.
Place the certificates in a directory accessible by the buckit user/group:
mkdir -p /opt/buckit/certs
chown -R buckit:buckit /opt/buckit/certs
cp private.key /opt/buckit/certs
cp public.crt /opt/buckit/certs
For local testing or development environments, you can use openssl to mint self-signed certificates.
For example, the following command generates a self-signed certificate with DNS Subject Alternative Names (SANs) associated to the Buckit Server hosts:
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout private.key \
-out public.crt \
-subj "/CN=localhost" \
-addext "subjectAltName = DNS:localhost,DNS:*.example.net"
Place the generated public.crt and private.key into the /path/to/certs directory to enable TLS for the Buckit deployment.
When Buckit runs with TLS enabled, it also verifies connecting client certificates against the OS list of trusted Certificate Authorities.
To enable verification of third-party or internally-signed certificates, place the CA file in the /opt/buckit/certs/CAs folder.
The CA file should include the full chain of trust from leaf to root to ensure successful verification.
For more specific guidance on configuring Buckit for TLS, including multi-domain support via Server Name Indication (SNI), see Network Encryption (TLS). You can optionally skip this step to deploy without TLS enabled. Buckit strongly recommends against non-TLS deployments outside of early development.
5. Create the Buckit Environment File
Create an environment file at /etc/default/minio.
The Buckit service uses this file as the source of all environment variables used by Buckit and by buckit.service.
Modify the example to reflect your deployment topology.
Use Multi-Node Multi-Drive (“Distributed”) deployment topologies in production environments.
# Set the hosts and volumes Buckit uses at startup
# The command uses Buckit expansion notation {x...y} to denote a
# sequential series.
#
# The following example covers four Buckit hosts
# with 4 drives each at the specified hostname and drive locations.
#
# The command includes the port that each Buckit server listens on
# (default 9000).
# If you run without TLS, change https -> http
MINIO_VOLUMES="https://buckit{1...4}.example.net:9000/mnt/disk{1...4}/buckit"
# Set all Buckit server command-line options
#
# The following explicitly sets the Buckit Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.
MINIO_OPTS="--console-address :9001 --certs-dir /opt/buckit/certs"
# 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=buckitadmin
# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.
MINIO_ROOT_PASSWORD=buckit-secret-key-CHANGE-ME
Use Single-Node Multi-Drive deployments in development and evaluation environments. You can also use them for smaller storage workloads which can tolerate data loss or unavailability due to node downtime.
# Set the volumes Buckit uses at startup
# The command uses Buckit expansion notation {x...y} to denote a
# sequential series.
#
# The following specifies a single host with 4 drives at the specified location
#
# The command includes the port that the Buckit server listens on
# (default 9000).
# If you run without TLS, change https -> http
MINIO_VOLUMES="https://buckit1.example.net:9000/mnt/drive{1...4}/buckit"
# Set all Buckit server command-line options
#
# The following explicitly sets the Buckit Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.
MINIO_OPTS="--console-address :9001 --certs-dir /opt/buckit/certs"
# 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=buckitadmin
# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.
MINIO_ROOT_PASSWORD=buckit-secret-key-CHANGE-ME
Use Single-Node Single-Drive (“Standalone”) deployments in early development and evaluation environments. Buckit does not recommend Standalone deployments in production, as the loss of the node or its storage medium results in data loss.
Important
SNSD deployments do not support storage expansion through adding new server pools.
# Set the volume Buckit uses at startup
#
# The following specifies the drive or folder path
MINIO_VOLUMES="/mnt/drive1/buckit"
# Set all Buckit server command-line options
#
# The following explicitly sets the Buckit Console listen address to
# port 9001 on all network interfaces.
# The default behavior is dynamic port selection.
MINIO_OPTS="--console-address :9001 --certs-dir /opt/buckit/certs"
# 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=buckitadmin
# Set the root password
#
# Use a long, random, unique string that meets your organizations
# requirements for passwords.
MINIO_ROOT_PASSWORD=buckit-secret-key-CHANGE-ME
Specify any other environment variables or server command-line options as required by your deployment.
For distributed deployments, all nodes must have matching /etc/default/minio environment files.
Use a utility such as shasum -a 256 /etc/default/minio on each node to verify an exact match across all nodes.
6. Start the Buckit Deployment
Enable and start the Buckit service on each node:
sudo systemctl enable --now buckit
Check service status and startup logs:
sudo systemctl status buckit
sudo journalctl -u buckit -f
You may see increased log churn as the cluster starts up and synchronizes.
Common reasons for startup failure include:
The Buckit process does not have read-write-list access to the specified drives
The drives are not empty or contain non-Buckit data
The drives are not formatted or mounted properly
One or more hosts are not reachable over the network
Following our checklists typically mitigates the risk of encountering those or similar issues.
7. Connect to the Deployment
Open your browser and access any of the Buckit hostnames at port :9001 to open the Buckit Console login page.
For example, https://buckit1.example.com:9001.
Log in with the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD from the previous step.
You can use the Buckit Console for general administration tasks like Identity and Access Management, Metrics and Log Monitoring, or Server Configuration. Each Buckit server includes its own embedded Buckit Console.
Install bm on your local host.
Run bm --version to verify the installation.
Once installed, create an alias for the Buckit deployment:
bm alias set mybuckit https://buckit1.example.net:9000 USERNAME PASSWORD
If your Buckit deployment uses third-party or self-signed TLS certificates,
bm may prompt you to trust the certificate when run in an interactive
terminal.
For non-interactive use, or to bypass certificate verification
temporarily, use --insecure:
bm --insecure alias set mybuckit https://buckit1.example.net:9000 USERNAME PASSWORD
Change the hostname, username, and password to reflect your deployment. The hostname can be any Buckit node in the deployment. You can also specify the hostname load balancer, reverse proxy, or similar network control plane that handles connections to the deployment.