Upgrade from MinIO Community Edition

This section documents procedures for upgrading from MinIO Community Edition to AIStor Object Store on both Linux and Kubernetes infrastructure.

Test this upgrade procedure in a lower environment before proceeding in production.

Upgrading from MinIO Community Edition to AIStor involves:

1. Backing up your existing cluster configuration and data
2. Installing the AIStor operator or binary
3. Configuring the AIStor license
4. Upgrading your existing clusters to AIStor
5. Validating the upgrade was successful

The specific steps vary depending on your cluster platform and environment.

AIStor takes advantage of server hardware with optimizations for newer technologies such as NVMe drives and modern CPU instructions.

The following cluster configurations may have limited resources for driving AIStor capabilities:

• Aged hardware, such as HDD storage or older CPUs
• Small clusters (less than 4 nodes and 8 drives)
• Low-bandwidth clusters (less than 25GbE)

Compare your existing hardware against the recommended requirements to identify potential performance costs. For the best performance, consider creating a new cluster on recommended hardware.

AIStor uses a testing and validation suite as part of all releases. However, no testing suite can account for unique combinations and permutations of hardware, software, and workloads of your production environment.

You should always validate any AIStor upgrades in a lower environment (Dev/QA/Staging) before applying those upgrades to Production clusters, or any other environment containing critical data. Performing upgrades to production environments without first validating in lower environments is done at your own risk.

Before beginning any upgrade, back up your cluster settings:

• For Linux clusters: Use mc admin config export, mc admin cluster bucket export, and mc admin cluster iam export
• For Kubernetes clusters: Use kubectl get tenant and kubectl get secrets to export configurations

You can use these snapshots to restore bucket, IAM, and cluster settings if needed.

The upgrade process requires at least one restart to load the new AIStor binaries. In Kubernetes, this period may require at least 30 seconds for resource deletion and recreation.

S3 clients typically include transparent retry mechanisms, such that they can resume operations during this period of time. Clients should experience minimal interruption, excluding scenarios which require taking the cluster entirely offline.

For clusters that are significantly behind the latest stable release (6+ months), or for complex upgrade scenarios, consider using MinIO SUBNET for additional support and guidance during the upgrade procedure.

If you encounter issues during the upgrade, see Troubleshooting upgrade issues.