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.

This page explains how to deploy AIStor with KES for Server Side Encryption. For instructions on running KES, see the KES docs. Broadly, the required steps are: Create a new external key (EK) for server-side encryption (SSE). Create or modify an AIStor deployment to support SSE with KES. Configure automatic bucket-default SSE. Enabling SSE on an AIStor deployment automatically encrypts the backend data for that deployment using the default encryption key.

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.

AIStor supports publishing bucket notification events to a Redis service endpoint. Prerequisites The AIStor mc command line tool This procedure uses the mc command line tool for certain actions. See the mc Quickstart for installation instructions. Add a Redis endpoint to an AIStor Server The following procedure adds a new Redis service endpoint for supporting bucket notifications in an AIStor Server.

AIStor uses Policy-Based Access Control (PBAC) to define the authorized actions and resources to which an authenticated user has access. Each policy describes one or more actions and conditions that outline the permissions of a user or group of users. AIStor PBAC is built for compatibility with AWS IAM policy syntax, structure, and behavior. This documentation makes a best-effort to cover IAM-specific behavior and functionality. Refer also to the AWS IAM documentation for more information.

AIStor Server implements Erasure Coding as a core component in providing data redundancy and availability. The diagrams and content in this section present a simplified view of erasure coding operations and are not intended to represent the complexities of the AIStor Server’s full erasure coding implementation. AIStor groups drives in each server pool into one or more Erasure Sets of the same size.

The AIStor Batch Framework allows you to create, manage, monitor, and execute jobs using a YAML-formatted job definition file (a “batch file”). The batch jobs run directly on the AIStor deployment to take advantage of the server-side processing power without constraints of the local machine where you run the AIStor Client. The keyrotate batch job type cycles the SSE-S3 or SSE-KMS keys for encrypted objects on an AIStor deployment. The YAML configuration supports filters to restrict key rotation to a specific set of objects by creation date, tags, metadata, or kms key. You can also define retry attempts or set a notification endpoint and token.

AIStor supports hot-swapping failed drives with new healthy drives. AIStor detects and heals those drives without requiring any node or deployment-level restart. AIStor healing occurs only on the replaced drive(s) and in most cases has minimal or negligible impact on 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.

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.

AIStor Helm installations consist of two primary parts: The operator chart that controls resources like CustomResourceDefinitions The object-store chart that deploys the AIStor Server You can also upgrade only the AIStor Server image used by a given chart. This page documents a procedure for all three upgrade paths. All AIStor software supports non-disruptive upgrades with zero downtime. In optimal environments, cluster-wide upgrades typically complete in under 500 milliseconds with large clusters (1000+ nodes) completing in less than 5 seconds.