When the storage tiering service moves an object off of the ingest tier and onto another storage tier, the service removes all copies of the object data from ingest tier and stores the specified number of copies of the object data on the new storage tier. However, at least one copy of the object metadata must always remain on primary running storage. For each storage tier that’s defined for a given namespace, the service plan specifies the number of copies of object data that must be stored on the tier and the number of copies of object metadata that must be stored on primary running storage.
If a given namespace is being replicated to another system, you can configure the service plan for that namespace to define a metadata-only storage tier. For each object that’s stored on a metadata-only tier, the service plan specifies the number of copies of the object metadata that must be stored on primary running storage, but service plan also specifies that no copies of the data for that object can be stored on any storage tier, including the ingest tier. Read-from-remote functionality enables clients to read the data for replicated metadata-only objects.
![]() |
Note: Each service plan can be configured to define only one metadata-only storage tier. In addition, if the storage plan for a namespace defines a metadata-only tier, that tier must be the last storage tier that’s defined by the service plan. Once objects in a namespace are moved to the metadata-only tier that’s defined for that namespace, the data for those objects is removed from all storage tiers defined for the namespace. |
The storage tiering service makes an object metadata-only only when all of these conditions are true:
•The service plan for the namespace that contains the object defines a metadata-only storage tier.
•The object is on the storage tier that immediately precedes the metadata-only tier defined in the namespace service plan, and the object meets the transition criteria specified for the metadata-only storage tier.
•A copy of the data for the object exists on at least one other HCP system in the replication topology in which the current system participates. (This is possible because service plans with the same name can have different definitions on different systems.)
When all of these conditions are true, the storage tiering service deletes all copies of the data for the object from the preceding storage tier. If the preceding storage tier is not the ingest tier, the storage tiering service also deletes any copies of the object data that exist on the ingest tier. After deleting all copies of the data for the object, the storage tiering service creates or deletes copies of the object metadata on primary running storage, as necessary, to satisfy the primary running storage MPL that’s specified for the metadata-only storage tier.
If rehydration is enabled for a metadata-only storage tier, when rehydrating a replicated object that’s been read from the ingest tier on a remote system, the storage tiering service rehydrates all copies of that object on the ingest tier of the local system.
When replicating an object in a namespace to a system on which objects in that namespace can be made metadata-only, HCP replicates only the object metadata if the object is larger than one MB. If the object is smaller than one MB, HCP replicates both the data and metadata.
Here’s a scenario that shows how allowing metadata-only objects can be used to advantage:
You have a many-to-one replication topology in which the HCP systems at the outlying sites are much smaller than the central HCP system to which they all replicate. To optimize the use of storage on the outlying systems, you allow the namespaces on those systems to have metadata-only objects while requiring the central system to have the object data. The outlying systems respond to client requests for object data by reading the data from the central system.
In this scenario, the replication topology should include a disaster recovery system (that is, a replica of the central system) to protect against data loss in case of a catastrophic failure of the central system.
![]() |
Important: HCP does not prevent you from removing a namespace from a replication topology even if the namespace contains metadata-only objects on one or more systems in that topology. This can result in data for objects in that namespace being permanently inaccessible from those systems. In most cases, HCP warns you if the modification you’re making to a replication link would cause this condition to occur. |
![]() |
Note: For the HDDS search facility to index the data for metadata-only objects, the objects must be rehydrated. |
For more information on replication, see Replicating Tenants and Namespaces.
© 2017 Hitachi Data Systems Corporation. All rights reserved.