Storage tier properties specified in service plans

For each storage tier, including the ingest tier, that’s defined for a given namespace, the service plan specifies:

The storage pools that are used to store copies of object data or chunks for erasure-coded objects 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), 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 or of the chunk for an erasure-coded object that HCP must maintain on each storage pool (that is, the DPL).

For each object that’s stored on the tier, the number of copies of the object metadata that HCP must maintain on the ingest tier (that is, the MPL).

For more information about DPL and MPL, see Storage tiers.

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 to this tier.

The age of an object created by a multipart upload is counted from the time the multipart upload was completed.

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 ingest tier storage capacity that must be used (the threshold) before object data can be moved to the second storage tier.

oFor 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 current tier and the ingest tier, and HCP stores the specified number of copies of the object metadata on primary running storage.

Erasure-coded objects never become metadata-only on any systems in the applicable erasure coding topology. If an erasure-coded object reaches a point in its lifecycle where the object should move to a metadata-only tier, the chunk for the object remains on the last tier before the metadata-only tier, and the DPL for that tier still applies to the chunk.

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.

Rehydration does not apply to erasure-coded objects. Instead, if the applicable erasure coding topology specifies a restore period, after an erasure-coded object is read, the chunk for the object is restored to a full copy on the ingest tier on the system from which the object was read. For more information about restore periods for erasure-coded objects, see Erasure coding topology properties.

© 2015, 2020 Hitachi Vantara LLC. All rights reserved.