Deployment Checklists The following checklists provide a high-level guideline for validating production-readiness of AIStor Servers. These checklists may not meet the precise requirements of your unique deployment topology or architecture, and are intended as a best-effort guide to reliable production deployments.

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.

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

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.

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.

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.

The mc od command copies a local file to a remote location in a specified number of parts and part sizes. The command outputs the time it took to upload the file. Use the mc od to mimic the functionality of the Linux dd command. Example The following command Upload 200MiB of a file to a bucket in 5 parts of size 40MiB. The output shows the results of the upload, including the length of time it took for the upload to complete.

This page covers settings that manage access and behavior for the AIStor Console. You can establish or modify settings by defining: an environment variable on the host system prior to starting or restarting the AIStor Server. Refer to your operating system’s documentation for how to define an environment variable. a configuration setting using mc admin config set. If you define both an environment variable and the similar configuration setting, AIStor uses the environment variable value.

This page documents settings for configuring an MQTT service as a target for Bucket Notifications. See Publish Events to MQTT for a tutorial on using these settings. You can establish or modify settings by defining: an environment variable on the host system prior to starting or restarting the AIStor Server. Refer to your operating system’s documentation for how to define an environment variable. a configuration setting using mc admin config set. If you define both an environment variable and the similar configuration setting, AIStor uses the environment variable value.