1701

This procedure deploys AIStor Object Store on Kubernetes clusters using a private container registry for images while installing Helm charts from the public MinIO Helm repository. Use this procedure when your environment has internet access to install Helm charts from helm.min.io but you need to pull container images from a private container registry instead of the public quay.io registry. This procedure requires installation of Kubernetes operators and associated resources including CustomResourceDefinitions, StatefulSets, and Secrets into new or existing Namespaces. You must perform the operations in this procedure as a user that has broad permissions to create resources within multiple Namespaces.

AIStor implements Transport Layer Security (TLS) 1.2+ encryption with support for Server Name Indication (SNI) for selecting relevant TLS certificates in response to client requests. AIStor supports two types of certificate management: Automatic TLS certificate provisioning (default) User-provided TLS certificates When deploying an AIStor Object Store resource, the CRD definition provides a certificates field for controlling certificate generation and behavior. This field is also available in the object store Helm chart.

This page documents the installation and management of AIStor object storage using MinIO’s Red Hat OpenShift-certified operator through the Red Hat OLM. If you prefer to install on OpenShift using regular Helm charts, use the regular install instructions. This procedure assumes that the user interacting with the OpenShift cluster has authorization to: Install Kubernetes operators and associated resources including CustomResourceDefinitions, StatefulSets, and Secrets into new or existing Namespaces. Perform operations as a user that has broad permissions to create resources within multiple Namespaces. Install the AIStor Operator This section installs the OpenShift-certified AIStor Operator. You must complete this section before proceeding to deploying AIStor.

This page describes how to enable FIPS 140-3 ready cryptography for AIStor deployments on Linux. When enabled, FIPS mode restricts cryptographic operations to algorithms that align with the Federal Information Processing Standards (FIPS) 140-3 program. Organizations subject to U.S. federal government compliance requirements, or those with similar regulatory needs, may require FIPS-aligned cryptography. AIStor FIPS mode uses Go’s native cryptographic module, which restricts operations to FIPS 140-3 approved algorithms. MinIO makes no statements or representations regarding FIPS 140-3 certification status. Evaluate whether this implementation meets your specific compliance requirements. Overview AIStor uses Go 1.24’s native FIPS 140-3 cryptographic module. Enable FIPS mode at runtime with the GODEBUG environment variable. There is no separate binary required.

Configure load balancers and reverse proxies for AIStor on Linux. Includes example configurations for NGINX and HAProxy.

Use the following checklist when planning the software configuration for a production, distributed MinIO deployment. AIStor pre-requisites Description ☐ Servers running a Linux operating system with a kernel of 6.8 or later for access to critical performance features.Red Hat Enterprise Linux (RHEL) 10, Rocky Linux 10, AlmaLinux 10, and Ubuntu Server 24.04 LTS use appropriate kernel versions by default. ☐ A method to synchronize time servers across nodes, such as with ntp, timedatectl or timesyncd.The method to use varies by operating system.Check with your operating system’s documentation for how to synchronize time with a time server. ☐ Disable system services that index, scan, or audit the filesystem, system-level calls, or kernel-level calls.These services can reduce performance due to resource contention or interception of AIStor operations.MinIO strongly recommends uninstalling or disabling the following services on hosts running AIStor:- mlocate or plocate- updatedb- auditd- Antivirus software (clamav)The above list represents the most common services or softwares known to cause performance or behavioral issues with high performance systems like AIStor.Consider removing or disabling any other service or software which functions similarly to those listed above on AIStor hosts.Alternatively, configure these services to ignore or exclude the AIStor process and all drives or drive paths accessed by AIStor. ☐ System administrator access to the remote servers ☐ A management tool for distributed systems, such as Ansible, Terraform, or Kubernetes for orchestrated environments.Kubernetes infrastructures should use the AIStor Operator for best results. ☐ Load balancer to handle routing of requests (for example, NGINX) ☐ Prometheus or a Prometheus-compatible setup for monitoring and metrics ☐ Grafana or similar Prometheus-compatible visual dashboard ☐ (Optional) mc installed on the local host system AIStor install Install a matching version of AIStor across all nodes in the deployment.

This procedure explains how to specify the TLS certificates your AIStor deployment requires and configure your deployment to work with the certificates. See also Enable Network Encryption for explanations of how AIStor requires TLS and which cipher suites AIStor supports. Prerequisites The appropriate X.509 certificates for your environment.

Site replication configures multiple independent AIStor deployments as a cluster of replicas called peer sites. Site replication assumes the use of either the included AIStor identity provider (IDP) or an external IDP. All configured deployments must use the same IDP. Deployments using an external IDP must use the same configuration across sites. AIStor does not recommend using macOS, Windows, or non-orchestrated containerized deployments for site replication except for early development, evaluation, or general experimentation.

mc support telemetry generates OpenTelemetry-formatted trace information to either live-stream or record-then-transmit to an OpenTelemetry Protocol (OTLP)-compatible service. The command collects trace data across all nodes in the AIStor deployment. The information can be relayed to a specified collector, recorded to a local encrypted or unencrypted file, or replayed from a local file to a collector. These commands are designed to capture traces in support of ongoing troubleshooting and diagnostics with MinIO Engineering.