Object Tiering

Object tiering is the moving of the data of an object from one set of hardware to another set of hardware. This is often done as a cost-saving measure, keeping more expensive and performant hardware for the newest or most accessed objects while placing other objects to less expensive and less performant storage solutions.

When MinIO AIStor moves an object to another tier, the object’s metadata remains on the primary tier while the object’s data moves to the secondary tier. When MinIO AIStor needs to serve a tiered object, it transparently retrieves the object from the secondary tier.

Because the data of a tiered object lives on the secondary tier, AIStor never treats tiered objects as dangling during healing, even if metadata copies are lost on the primary tier. Healing restores only the object’s metadata on the primary tier.

Users can temporarily restore an object to the primary tier by returning its data there for a fixed span of time using the AIStor Client’s mc ilm restore command. After the specified time passes, MinIO AIStor automatically returns the object to the secondary tier. MinIO AIStor does not support permanently restoring an object to the primary tier.

MinIO AIStor supports a single level of tiering, with a primary and secondary level of storage. For example, a “hot” storage and a “warm” storage.

MinIO AIStor does not support moving objects from the secondary tier to yet another level, such as from a warm storage to a deeper “cold” storage for long term archival.

Secondary tiers can be any of the following types of storage:

• Another MinIO AIStor
• S3-compatible storage
• Azure Cloud Storage
• Google Cloud Storage

MinIO AIStor loads the remote tier configuration when the server starts. If that load fails — during a brief loss of quorum on a full-cluster restart, for example — MinIO AIStor retries in the background until it succeeds, and also reloads on the first operation that needs a tier.

While the configuration is unavailable, MinIO AIStor returns an error rather than acting as though no tiers exist:

• mc ilm tier ls and mc ilm tier check fail with 503 XMinioAdminTierNotInitialized, Remote tier configuration not initialized, followed by the underlying cause.
• Adding a lifecycle rule that names a tier, and reading an object already moved to a tier, fail with 503 SlowDown, Tier configuration is temporarily unavailable, please retry.
• mc admin cluster bucket import reports that error for each bucket whose lifecycle names a tier, and imports the rest.

Retry the operation. A valid tier name is never rejected as invalid while the configuration is only unavailable. If the errors persist, MinIO AIStor cannot read the tier configuration at all. Check the server log, then open a SUBNET issue.