Storage Tiering service

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 tier on which HCP initially stores every object in the namespace is called the ingest tier. The ingest tier must be either primary running storage or HCP S Series storage.

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), HCP S Series storage, 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:
  • The 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
  • For 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 ingest tier storage capacity that must be used (the threshold) before object data can be moved to the second storage tier
  • For HCP systems with replication enabled, whether objects must be fully replicated before they can be transitioned from the previous tier onto this tier. If replication is disabled for the HCP system, this transition criterion does not appear in the HCP System Management Console.
• 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 the specified number of copies of the object metadata are stored on primary running storage.

• Whether the data for each object stored on the tier is rehydrated (that is, restored on the ingest tier) 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 the ingest tier.

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:
  • If the new tier has a different DPL from 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
  • If the new tier has a different primary running storage metadata protection level (MPL) from the previous tier, creates or deletes the number of copies of object metadata that’s required to satisfy the MPL 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 whether the object data has been read from a storage tier for which rehydration is enabled, and if so, creates an extra copy of the object data on the ingest tier.
• 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 the ingest tier.

Another function of the Storage Tiering service is to maintain the correct number of copies of each object in a namespace on each storage tier that’s defined for that namespace by its service plan.

If the number of object copies on a storage tier is less than the number of object copies specified for that tier in the applicable service plan, the Storage Tiering service creates the applicable number of new copies of that object on that tier. If the number of copies of an object on a storage tier is higher than the number of object copies specified for that tier in the applicable service plan, the Storage Tiering service deletes all unnecessary copies of that object from that tier.

The Protection service performs work that is nearly identical to the work performed by the Storage Tiering service to maintain the correct number of copies of object data and metadata on each service tier that’s defined for a namespace. However, the two services perform the work that they do in slightly different ways.

The Storage Tiering service runs only when it’s scheduled to run. When the Storage Tiering service processes an object in a given namespace, the Storage Tiering service first checks to see whether copies of the object data are stored on the correct storage tier and moves the object data among tiers if necessary. The Storage Tiering service then checks to see whether the correct number of object copies exists on each tier that’s defined for the namespace and takes corrective action if necessary.

The Protection service runs when it’s scheduled to run and in response to its triggers. When the Protection service processes an object in a given namespace, the service first checks to see whether the correct number of copies of the object exist on all storage tiers. If not, the Protection service first checks to see whether the correct number of object copies exist on the active storage tier (the one on which the object is currently supposed to be stored) and takes corrective action if necessary. The Protection service then checks to see if the correct number of object copies exists on the other storage tiers and takes corrective action if necessary.

The Storage Tiering service is designed to optimize storage utilization. The Storage Tiering service, therefore, first moves objects among storage tiers and then checks to make sure all copies of each object in a given namespace have been stored on the correct storage tiers.

The Protection service is designed to optimize data availability and maintain the correct level of data redundancy for each object in a given namespace. The Protection service, therefore, constantly checks to see whether the correct number of copies of the object data are available to clients, and takes corrective action as soon as a violation occurs. When the Protection service runs on a schedule, it checks the availability of each object on the active storage tier first, and then checks whether the correct number of objects copies exists on the other tiers.

The third function of the Storage Tiering service is to delete all existing copies of the data for any object that’s moved to a metadata-only storage tier and ensure that the correct number of copies of the metadata for that object are stored on primary running storage.

The Storage Tiering service also restores data for metadata-only objects to the ingest tier. Restoring the data for an object to the ingest tier is called rehydrating the object.

When the Storage Tiering service moves an object off the ingest tier and onto another storage tier, the service removes all copies of the object data from the 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. This type of tier specifies the number of copies of object metadata that must be stored on primary running storage, but it also specifies that no copies of the object data can be stored on any storage tier, including the ingest tier.

For a multipart object on a metadata-only storage tier, the applicable number of copies of the metadata for each part must be stored on primary running storage, and no copies of the part data can be stored on any storage tier.

The Storage Tiering service makes objects 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 object data 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 object data from the preceding storage tier. If the preceding storage tier is not primary running storage, the Storage Tiering service also deletes any copies of the object data that exist on primary running storage. After deleting all copies of the object data, the Storage Tiering service creates or deletes copies of the object metadata on primary running storage as necessary so that the number of copies of object metadata match the number of copies that the service plan requires for the metadata-only tier.

If rehydration is enabled for a metadata-only storage tier, when rehydrating a replicated object that’s been read from primary running storage on a remote system, the Storage Tiering service rehydrates all copies of the object on the ingest tier on 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.

For the HDDS search facility to index the data for metadata-only objects, the objects must be rehydrated.

The Storage Tiering service processes one object at a time. For each object, the service checks the applicable service plan to determine the storage tiers on which copies of the object data should be stored, the number of copies of the object data that should be stored on each tier, and the number of copies of the object metadata that should be stored on primary running storage. The Storage Tiering service then checks to see whether the object data has been read from a storage tier for which rehydration is enabled. Finally, the Storage Tiering service checks to see whether the object data has been read from a remote system because that object is metadata-only on the local system, and if so, the service checks to see whether rehydration is enabled for the metadata-only tier on which the object resides.

For each object in a namespace, if all of these conditions are true, the storage plan takes no action on that object:

• The object is stored on the correct storage tier.
• The correct number of copies of the object data exist on the current storage tier.
• The correct number of copies of the object metadata exist on primary running storage.
• If the object is on a storage tier for which rehydration is enabled, the correct number of rehydrated copies of the object exist on the ingest tier.

If one or more of the above conditions is not true, the Storage Tiering service takes the applicable actions to bring the object into compliance with the namespace service plan.

The Storage page in the HCP System Management Console displays graphs and statistics that provide information about the use of primary running storage, primary spindown storage, and each type of extended storage that’s used to store objects in a repository. The Storage page also provides information about metadata-only objects.

To display the Storage page, in the System Management Console, click Storage.