Initially, when you add an object to a namespace, HCP creates and stores the data on the ingest tier and metadata for the object on primary running storage. For each object that’s stored in a namespace:
- HCP creates primary metadata for it. This metadata consists of information HCP already knows, such as the creation date, and, for objects only, the data size, hash algorithm, and cryptographic hash value generated by that algorithm. It also includes metadata that was either inherited or specified in the write request, such as retention setting, UID, and GID.
- HCP creates the number of additional copies of the primary metadata required to satisfy the ingest tier metadata protection level (MPL) that’s set for the namespace by its service plan. HCP then distributes all copies of the primary metadata among the HCP storage nodes.
- HCP creates the number of copies of the object data required to satisfy the ingest tier data protection level (DPL) that’s set for the namespace by its service plan. HCP then distributes all copies of the object data either among the HCP storage nodes or HCP S Series Nodes, depending on the ingest tier.
Each copy of the primary metadata for the object points to all copies of the object data. However, the object data is not necessarily stored on the same node as the primary metadata for the object.
- HCP stores a copy of the metadata with each copy of the object data. Each copy, called the secondary metadata, lets HCP reconstruct the primary metadata should that become necessary.
Object content stored on different types of storage
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.
For each object in a given namespace, the Storage Tiering service always moves copies of the data for that object among the storage tiers that are defined for the namespace by its service plan. However, the Storage Tiering service does not move all of the other content for an object to each storage tier that’s defined for a namespace.
For each copy of an object that’s stored on primary spindown storage, only the data, custom metadata, ACL, and secondary metadata for that object are actually stored on primary spindown storage. All copies of the primary metadata for an object must always remain on primary running storage.
Objects moved from primary running storage to primary spindown storage are always kept on the same storage node.
For each copy of an object that’s moved to S Series or extended storage, only the data for that object is actually stored on primary running storage. All copies of the object metadata must always remain on primary running storage.
Storage allocation for objects on an HCP S Series or extended storage tier
Each HCP S Series or extended storage tier can be configured to use one or more storage pools. Each storage pool can be configured to include one or more access points (mount points, buckets, or containers) that can be associated with one or more storage components.
If a service plan defines an HCP S Series or extended storage tier that contains more than one storage pool and the DPL for that storage tier is greater than one, HCP uses different storage pools to store duplicate copies of the data for each object on that tier. Similarly, if a storage pool that’s used for a given storage tier contains more than one HCP S Series or extended storage component access point, HCP uses the storage that’s associated with different access points to store any duplicate copies of object data that are stored on the tier that contains the storage pool.
When HCP stores a single copy for each object on a given HCP S Series or extended storage tier, HCP still distributes the object data storage evenly across all of the storage component access points contained in all storage pools configured for a given HCP S Series or extended storage tier.
This ensures that data that’s stored on a given tier is protected as much as possible and the storage that’s used for a given tier is allocated as efficiently as possible.
Service plans and read requests
When creating service plans, you should keep in mind how HCP handles read requests.
In response to a read request, HCP tries to retrieve the data for an object from these sources, in the order specified below:
- Primary running storage
- HCP S Series storage
- Primary spindown storage
- NFS storage
- Cloud storage
- Primary storage on a remote system to which the object has been replicated
In response to a read request, HCP tries to retrieve the metadata for an object from these sources, in the order specified below:
- Primary running storage
- Primary spindown storage
- Primary running storage on a remote system to which the object has been replicated
Service plans for tenants and namespaces
When you create an HCP tenant, you have the option of associating a service plan with it. This plan then applies to each of the tenants namespaces. Alternatively, you can allow HCP tenant administrators to associate service plans with their individual namespaces. In this case, the tenant administrator can choose from any of the service plans that are defined at the system level (including Default).
When you create the default tenant and namespace, you associate a service plan with the default namespace. The default tenant administrator can choose a different service plan for the default namespace at any time.
You can change the service plan that’s associated with an HCP tenant at any time. However, if you switch to allowing the tenant to associate service plans with individual namespaces, you can no longer associate a service plan with the tenant.
When allowed to choose service plans for individual namespaces, tenant administrators see only the service plan names and descriptions, and not service plan rules. The names and descriptions can indicate the namespace usage patterns and properties with which the service plans are intended to work. Thus, tenant administrators do not need to be aware of the HCP system storage in order to associate service plans with namespaces.
Service plans and replication
HCP replicates the associations between service plan names and tenants or namespace but does not replicate the service plans themselves. If you change the associations between service plan names and tenants on namespaces on a replica HCP system, the change is replicated to the rest of the HCP systems in the replication topology, ensuring that the service plan name associated with a tenant or namespace remains the same.
HCP does not replicate service plans. This means that replicated tenants or namespaces can be associated with the same service plan name on the two systems involved in a replication link, but the service plan configuration settings on the two systems can be entirely different. For example, a service plan named External Storage can tier to Amazon storage from system A and to HCP S Series storage on system B.
You need to configure the service plans on each system in the replication topology. If you do not configure the service plans, the replicated namespaces and tenants use the Default service plan settings.