This page reflects limits and thresholds that apply to AIStor Server. S3 API limits Item Specification Maximum object size 50 TiB Minimum object size 0 B Maximum object size per PUT operation 5 TiB for non-multipart upload50 TiB for multipart upload Maximum number of parts per upload 10,000 Part size range 5 MiB to 5 GiB. Last part can be 0 B to 5 GiB Maximum number of parts returned per list parts request 10,000 Maximum number of objects returned per list objects request 1,000 Maximum number of multipart uploads returned per list multipart uploads request 1,000 Maximum length for bucket names 63 Maximum length for object names 1024 Maximum length for each / separated segment of an object name 255 Maximum number of object versions for a unique object 10000 (Configurable) Erasure code limits Item Specification Maximum number of servers per cluster no limit Minimum number of servers 1 Minimum number of drives per server when server count is 1 1 (for deployments, which do not provide additional reliability or availability) Minimum number of drives per server when server count is 2 or more 1 Maximum number of drives per server no limit Read quorum $$N/2$$ Write quorum $$(N/2)+1$$ Object name limitations Filesystem and operating system restrictions Object names in AIStor are restricted primarily by the local operating system and filesystem. Windows and some other operating systems restrict file systems with certain special characters, such as ^, *, |, \, /, &, ", or ;.

Networking has the greatest impact on AIStor Server performance. Low per-host bandwidth artificially constrains the potential performance of the storage. MinIO recommends high speed networking to support the maximum possible throughput of the attached storage (aggregated drives, storage controllers, and PCIe busses). For best performance, use 100GbE or higher networking infrastructure. The following table provides a general guideline for the maximum storage throughput supported by a given physical or virtual network interface. This table assumes all network infrastructure components, such as routers, switches, and physical cabling, also supports the NIC bandwidth.

This tutorial deploys AIStor onto Kubernetes distributions that follow the upstream API and functionality. The steps in this procedure may work on forked Kubernetes distributions. This procedure requires the installation of Kubernetes operators and associated resources including CustomResourceDefinitions, Statefulsets, and secrets into new or existing namespaces. You must perform the operations in this procedure as a user that has broad permissions to create resources within multiple namespaces. Deploy AIStor using Helm This procedure documents installation on Kubernetes with the AIStor Helm Charts. MinIO recommends Helm version 3.17 or later.

AIStor server-side bucket replication is an automatic bucket-level configuration that synchronizes objects between a source and destination bucket. AIStor server-side replication requires the source and destination bucket be two separate AIStor clusters running the same Object Store version. For each write operation to the bucket, AIStor checks all configured replication rules for the bucket and applies the matching rule with highest configured priority. AIStor synchronizes new objects and object mutations, such as new object versions or changes to object metadata. This includes metadata operations such as enabling or modifying object locking or retention settings.

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 replicate batch job replicates objects from one AIStor deployment (the source deployment) to another AIStor deployment (the target deployment). The deployment specified as the alias becomes the ’local’ deployment for the purposes of replication.

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 server to take advantage of the server-side processing power without constraints of the local machine where you run the AIStor Client. The expire batch job applies Automatic Object Expiration behavior to a single bucket. The job determines expiration eligibility based on the provided configuration, independent of any configured expiration rules.

MinIO publishes the following Software Development Kits (SDK): Go Download from GitHub Python Install methods Java Install methods .NET Download from NuGet JavaScript Install Haskell Install C++ Install Rust Go GitHub: minio/minio-go

AIStor’s Object Lambda enables developers to programmatically transform objects on demand. You can transform objects as needed for your use case, such as redacting personally identifiable information (PII), enriching data with information from other sources, or converting between formats. Overview An Object Lambda handler is a small code module that transforms the contents of an object and returns the results. Like Amazon S3 Object Lambda functions, you trigger an AIStor Object Lambda handler function with a GET request from an application. The handler retrieves the requested object from AIStor, transforms it, and returns the modified data back to AIStor to send to the original application. The original object remains unchanged.

This page documents the installation of the AIStor Key Encryption Service. You may require root or sudo permissions to perform some of the steps. Install the AIStor KES binary on each node in your KES cluster. Linux AMD64 curl --progress-bar --retry 10 -L https://dl.min.io/aistor/kes/release/linux-amd64/kes -o kes chmod +x ./kes mv ./kes /usr/local/bin/kes kes --version ARM64

The AIStor Security Token Service (STS) AssumeRoleWithCustomToken API endpoint generates a token for use with the AIStor External Identity Management Plugin. Request endpoint The AssumeRoleWithCustomToken endpoint has the following form: POST https://aistor.example.net?Action=AssumeRoleWithCustomToken[&ARGS] The following example uses all supported arguments. Replace the aistor.example.net hostname with the appropriate URL for your AIStor cluster: