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.

The procedure on this page creates a new object lifecycle management rule that transition objects from an AIStor bucket to a remote storage tier on the storage backend. This procedure supports use cases like moving aged data to low-cost public cloud storage solutions after a certain time period or calendar date. Requirements Install and configure mc This procedure uses mc for performing operations on the AIStor cluster. Install mc on a machine with network access to both source and destination clusters. See the mc Installation Quickstart for instructions on downloading and installing mc.

This page documents the installation and management of AIStor object storage using MinIO’s Red Hat OpenShift-certified operator. 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 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.

This section documents steps for running AIStor as a container. Procedure Pull the latest stable image of AIStor Server Docker docker pull quay.io/minio/aistor/minio Podman podman pull quay.io/minio/aistor/minio Create a data directory for use with the server

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.

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.

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.11.x or later for access to critical performance features.Red Hat Enterprise Linux (RHEL) 10 and Ubuntu Server 24.0.2 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.

Distributed AIStor deployments rely on Erasure Coding to provide built-in tolerance for multiple drive or node failures. Depending on the deployment topology and the selected erasure code parity, AIStor can tolerate the loss of up to half the drives or nodes in the deployment while maintaining read access (“read quorum”) to objects. The following table lists the typical types of failure in an AIStor deployment and links to procedures for recovering from each:

If an AIStor node suffers complete hardware failure (for example, loss of all drives, data, etc.), the node begins healing operations once it rejoins the deployment. AIStor healing occurs only on the replaced hardware and does not typically impact deployment performance. AIStor healing ensures consistency and correctness of all data restored onto the drive. Changed in RELEASE.2025-02-04T00-52-01Z If multiple drives within the same erasure set require healing, AIStor prioritizes the first drive that begins healing within the erasure set. Other drives in the erasure set wait until healing finishes on the first drive before the next drive starts healing.