AIStor bucket notifications allow administrators to send notifications to supported external services when events occur on objects or buckets, similar to Amazon S3 Event Notifications. This page lists supported event types that trigger notifications, including bucket-level and object-level S3 events. Supported notification targets AIStor supports publishing event notifications to the following targets:

Configure AIStor to authenticate users with OpenID Connect providers like Okta, Keycloak, Microsoft Entra ID, or Google for SSO integration.

AIStor supports publishing bucket notification events to MQTT server/broker endpoint. Prerequisites MQTT 3.1 or 3.1.1 Server/Broker This procedure assumes an existing MQTT 3.1 or 3.1.1 server/broker to which the AIStor Server has connectivity. See the mqtt.org software listing for a list of MQTT-compatible server/brokers.

This page documents all requirements of bucket replication configurations, including: Active-Passive Active-Active Data Resynchronization Ensure you meet the following prerequisites before you set up any of these replication configurations. Permissions required for setting up bucket replication Bucket replication requires specific permissions on the source and destination deployments to configure and enable replication rules.

The following procedures decommissions one or more pools on a Linux bare-metal deployment. Review the AIStor deployment topology The mc admin decommission command returns a list of all pools in the AIStor deployment: mc admin decommission status myaistor The command returns output similar to the following: ┌─────┬──────────────────────────────────────────────────────────────────┬──────────────────────────────────┬────────┐ │ ID │ Pools │ Capacity │ Status │ │ 1st │ https://aistor-{01...04}.example.com:9000/mnt/disk{1...4}/aistor │ 10 TiB (used) / 10 TiB (total) │ Active │ │ 2nd │ https://aistor-{05...08}.example.com:9000/mnt/disk{1...4}/aistor │ 60 TiB (used) / 100 TiB (total) │ Active │ │ 3rd │ https://aistor-{09...12}.example.com:9000/mnt/disk{1...4}/aistor │ 40 TiB (used) / 100 TiB (total) │ Active │ └─────┴──────────────────────────────────────────────────────────────────┴──────────────────────────────────┴────────┘ The example deployment above has three pools. Each pool has four servers with four drives each.

You can use the AIStor Console to perform many of the deployment monitoring and management functions available in AIStor, such as: License to monitor the status and expiration of the MinIO Commercial License used for the AIStor deployment. Monitor the health and activity of the deployment by reviewing metrics, server or audit logs, trace history, S3 events, or drive health. Configure alerts by adding or managing a notification target. Set up site replication to synchronize datacenters for timely access across geographically dispersed workforces or for disaster preparedness. Configure deployment settings. Overview The Overview page displays summary information for a deployment including:

The following procedure adds a server pool to an existing AIStor cluster running on bare-metal infrastructure. Each pool expands the total available storage capacity of the cluster while maintaining the overall availability of the cluster. A new pool is a set of new nodes and drives that meet the cluster’s erasure set requirements and parity levels. You can use MinIO’s Erasure Code Calculator to check the Erasure Code Stripe Size (K+M) of your new pool to confirm that it meets the EC:M value of current cluster. MinIO strongly recommends seeking an architecture review from MinIO Engineering through SUBNET to analyze potential performance impacts before committing to a new pool for your cluster.

Each procedure on this page creates a new object lifecycle management rule that expires objects on an AIStor bucket. This procedure supports use cases like removing “old” objects after a certain time period or calendar date. Requirements Install and configure AIStor Client This procedure uses the AIStor Client (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 procedure deploys AIStor Object Store on Kubernetes clusters in an airgapped environment. An airgapped environment is a network environment that has no direct connection to external networks or the internet. Installing AIStor in an airgapped environment requires copying all required container images and Helm charts to private registries accessible within the airgapped network. Airgap deployment consists of two phases: External Preparation (requires internet access): Download Helm charts and copy container images to your private registries from a system with network access to both the internet and your private registries. Airgapped Deployment (within airgapped environment): Install AIStor using the mirrored resources from within your airgapped Kubernetes environment. This procedure assumes you or your organization have existing procedures and tooling for facilitating such copying. Defer to your organization’s procedures on importing data from the internet into the airgapped environment. You cannot complete the first phase without tooling to facilitate the download-and-copy steps.

AIStor supports deploying resources onto Linux infrastructures and provides packages for Red Hat Enterprise Linux and Ubuntu Server platforms. Setting up AIStor on Linux involves these steps: Install AIStor Configure load balancing Set up network encryption Set up server-side encryption Enable FIPS mode (optional, for regulatory compliance)