One of the functions of the storage tiering service is to move copies of objects in a namespace among storage tiers that are defined for that namespace by its service plan.
The service plan for a given namespace defines one or more storage tiers that can be used to store copies of the objects in that namespace. Because HCP initially stores every object on primary running storage, every service plan automatically has primary runnng storage defined as the initial storage tier, called the ingest tier.
For each storage tier, including the ingest tier, the service plan for a given namespace specifies:
•The storage pools that are used to store copies of each object on the tier. Each storage pool consists of one or more storage components. Each storage component represents a type of primary storage (running or spindown), an extended storage device, or a cloud storage service endpoint.
•For each object that’s stored on the tier, the number of copies of the object data that HCP must maintain on each storage pool and the number of copies of object metadata that HCP must maintain on the ingest tier.
•The transition criteria for each tier except for the ingest tier. The transition criteria for a storage tier are the rules that determine when one or more copies of each object in the namespace must be stored on the tier:
oThe object age (number of days since ingest) at which one or more copies of the object data must be moved from the previous tier onto this tier
oFor service plans that define exactly two tiers, including the ingest tier, whether a threshold will be applied to the second tier, and if so, the percentage of primary running storage capacity that must be used (the threshold) before object data can be moved to the second storage tier
•For a namespace that’s currently being replicated to another system, whether the copies of the object that are stored on the tier are to be made metadata-only.
Regardless of the transition criteria that are specified for a metadata-only tier, objects are moved to such a tier only after they are replicated. When a replicated object is moved to a metadata-only tier, all existing copies of the object data are deleted from the previous tier and from primary running storage, and stores the specified number of copies of the object metadata on primary running storage.
•Whether the data for each object stored on the tier is rehydrated (that is, restored on primary running storage) upon being read from the tier, and if so, the number of days HCP is required to keep a rehydrated copy of object data on primary running storage
If the service plan for a given namespace defines multiple storage tiers, then for each object in that namespace, the storage tiering service:
•Moves copies of the object data among the storage tiers that are defined for the namespace to satisfy the transition criteria that are defined for each storage tier
•Upon moving all existing copies of the data for an object from one tier to another:
oIf the new tier has a different DPL than the previous tier, creates or deletes the number of copies of object data that’s required to satisfy the DPL setting for the new tier
oIf the new tier has a different primary running storage metadata protection level (MPL), than the previous tier, creates or deletes the number of copies of object data that’s required to satisfy the DPL setting for the new tier
•Upon moving a replicated object to a metadata-only tier, deletes all copies of the object data from the previous tier, and if the previous tier is not the ingest tier, deletes any copies of the object data that exist on primary running storage
•Checks to see if the object data has been read from a data storage tier for which rehydration is enabled, and if so, creates an extra copy of the object data on primary running storage
•After moving a replicated object to a metadata-only tier for which rehydration is enabled and making that object metadata-only, checks to see whether that object has been read from a remote system, and if so, restores the data to each copy of the object that’s stored on primary running storage
For information on creating and configuring service plans and assigning each plan to a namespace, see Working with service plans.
© 2016 Hitachi Data Systems Corporation. All rights reserved.