AIStor automatically creates remote targets based on a given file path or resource location (such as an IP or DNS address). Users defining a remote target no longer need to determine an ARN for the remote bucket. The mc replicate add command creates a new server-side replication rule for a bucket on an AIStor deployment. The remote bucket must be on an AIStor deployment running the same version of AIStor as the local deployment.

Configure load balancers and Ingress controllers for AIStor on Kubernetes. Includes examples for NGINX, HAProxy, and Traefik.

This procedure provides guidance for enabling Server-Side Encryption (SSE) using AIStor Key Manager as the Key Management Service (KMS). Enabling SSE on an AIStor deployment automatically encrypts the backend data for that deployment using the default encryption key selected during the setup process.

AIStor supports deploying resources onto macOS hosts for local development and evaluation. For the purposes of evaluation or local development, MinIO recommends using a machine released in the last 4 years with at least 8 GB of RAM. You can use any supported version of macOS. For testing or local development using a virtualized environment, use a machine with a higher number of cores and 16 or 32GB of RAM.

Install on Red Hat Enterprise Linux Deploy AIStor onto RHEL 10+

This procedure downloads and installs the AIStor Server onto bare-metal hosts running Red Hat Enterprise Linux Review the Hardware and System Requirements to ensure your target infrastructure meets our guidance. You can also open a SUBNET issue to request an architecture review or assistance during deployment. MinIO strongly recommends using only RHEL releases in the Full Support lifecycle with Long-Term Support (LTS) Kernels in the 6.12 or later release series, such as RHEL 10. These Linux kernels include support for critical performance features.

You can suspend bucket versioning at any time using the AIStor Console, the AIStor mc CLI, or using an S3-compatible SDK. Behavior While versioning is suspended, AIStor does the following in the bucket: Objects created while versioning is suspended are assigned a null version ID. Any changes to an object while versioning is suspended result in overwriting that null versioned object. AIStor does not remove or otherwise alter existing versioned objects as part of suspending versioning. Clients can continue interacting with any existing object versions in the bucket. Procedure To disable versioning, select whether you want to use the AIStor Console or the AIStor Client (mc).

Overview AIStor supports keeping multiple “versions” of an object in a single bucket. When enabled, versioning allows AIStor to keep multiple iterations of the same object. Write operations which would normally overwrite an existing object instead result in the creation of a new version of the object. AIStor versioning protects from unintended overwrites and deletions while providing support for “undoing” a write operation. Bucket versioning is a prerequisite for configuring object locking and retention rules.

The procedure on this page creates a new bucket replication rule for two-way “active-active” synchronization of objects between AIStor buckets. Requirements Replication requires all participating clusters meet the bucket replication requirements. This procedure assumes you have reviewed and validated those requirements.

For identities managed by an external OpenID Connect (OIDC) compatible provider, AIStor can use either of two methods to assign policies to the authenticated user. AIStor by default denies access to all actions or resources not explicitly allowed by a user’s assigned or inherited policies. Authorization options with OIDC OIDC integration in AIStor supports either of the following authorization methods: