Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

Service plans

About service plans


Each namespace has a service plan that defines both a storage tiering strategy and a data protection strategy for the objects in that namespace. At any given point in the lifecycle of an object, its storage tiering strategy specifies the types of storage on which copies of that object must be stored, and its data protection strategy specifies the number of object copies that must be stored on each type of storage.

For the purposes of storage tiering and data protection, HCP treats these as individual objects:

Parts of multipart objects

Chunks for erasure-coded objects

Chunks for erasure-coded parts of multipart objects

The service plan for a given namespace defines one or more tiers of storage that can be used to store objects in that namespace. For each object in the namespace, at any given point in the object lifecycle, the service plan specifies the criteria that determine which storage tiers must be used to store copies of that object and the number of copies of that object that must be stored on each tier.

Primary running storage is designed to provide both high data availability and high performance for object data storage and retrieval operations. To optimize data storage price/performance for the objects in a namespace, you can configure the service plan for that namespace to define S Series storage as the ingest tier or create a storage tiering strategy that specifies multiple storage tiers.

By default, HCP stores every object on primary running storage, so every service plan automatically defines primary running storage as the initial storage tier, called the ingest tier. If the HCP system is using S Series storage, this storage can be used as the ingest tier instead of primary running storage. This causes object data to be written directly to the S Series Nodes. Even if you set S Series storage as the ingest tier, metadata is stored on primary running storage.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Storage tiers


The service plan for a given namespace defines one or more storage tiers for that namespace. For each storage tier, the service plan specifies the data protection level (DPL) and the primary running storage metadata protection level (MPL) for each storage tier:

The DPL for a given storage tier is the number of copies of the object data that HCP must maintain for each object that’s stored on that tier.

The MPL for a given storage tier is the number of copies of the object metadata that HCP must maintain on primary running storage for each object that’s stored on the tier.

For any given storage tier, the primary running storage MPL must be equal to or greater than the DPL.

NoteWebHelp.png

Note: For the purpose of storage tiering, HCP treats parts of multipart objects, chunks for erasure-coded objects, and chunks for erasure-coded parts of multipart objects as individual objects.

Every service plan initially defines primary running storage as the initial storage tier, called the ingest tier, and specifies a DPL setting and an MPL setting for that tier. If the HCP system is using S Series storage, you can define S Series storage as a service plan ingest tier to be used as an alternative to primary running storage. If an S Series pool, or pools, is selected as the ingest tier, DPL copies of objects are written directly to S Series storage. MPL copies of object metadata are written to primary running storage.

Tiering objects that are subject to erasure coding

HCP does not tier objects that are subject to erasure coding but not yet erasure coded unless the target tier is primary running storage, an S Series Node, or primary spindown storage. Instead, on any given system in an erasure coding topology, if the system initially receives a full copy of the data for an object that's subject to erasure coding, HCP waits to tier the object until the full copy of the data has been reduced to a chunk.

Once the system has a chunk for the object, HCP can move the chunk to the applicable tier, according to the tiering strategy in the service plan associated with the namespace that contains the object. If the object was due to be tiered before the full copy of the data was reduced to chunk, HCP immediately moves the chunk to the applicable tier.

If a system initially receives a chunk for an object, that chunk is immediately subject to the tiering strategy in the applicable service plan.

On any given storage tier, for an object that's subject to erasure coding, HCP keeps DPL copies of the full object data or the chunk for the object, as applicable, where DPL is the DPL specified for that storage tier.

For more information on erasure coding, see Protection types.

DPL settings for objects and default-namespace directories

Objects have a DPL setting as part of their metadata. This setting is the DPL for the tier where the object data currently should be stored, according the service plan associated with the namespace that contains the object. If the object is not yet on that tier or if the DPL for the tier changes while the object is on that tier, the actual number of copies of the object data may not immediately match the DPL setting for the object.

Directories in the default namespace also have a DPL setting as part of their metadata. This setting is the DPL for the ingest tier in the service plan associated with the default namespace.

Users and applications can see, but not modify, the DPL setting for an object or directory.

Default ingest tier DPL setting

Each HCP system has a default service plan that’s automatically created and configured during the HCP software installation. The default service plan is applied to each tenant and namespace for which another service plan is not explicitly selected.

For any given HCP system, the ingest tier DPL setting that’s initially configured for the default service plan is used as the default ingest tier DPL setting for each new service plan that’s created on the HCP system. When you create a new service plan, you can choose to use the default ingest tier DPL setting or select a different setting. You can also modify any service plan, including the default service plan, to change the ingest tier DPL setting. However, changing the ingest tier DPL setting used for the default service plan does not change the default ingest tier DPL setting that’s used for new service plans.

Typically, the default ingest tier DPL setting used for service plans created on an HCP system is the optimal setting for the type of physical storage that the HCP system uses. For RAIN systems, the default ingest tier DPL is two. For SAIN systems, for which SAN arrays provide a high level of data protection, and for VM systems, for which the virtual environment provides node failover capabilities, the default ingest tier DPL is one.

The default ingest tier DPL setting used for all service plans that are created on an HCP system is the optimal setting for the type of storage used by that system. However, the optimal ingest tier DPL setting that’s configured for the service plan that’s assigned to a specific tenant or namespace is subject to considerations such as whether the tenant or namespace is being replicated and whether the HCP system owner or the tenant administrator has any particular data protection needs.

On HCP RAIN systems, by default, service plans can be configured to set the ingest tier DPL to two, three, or four. To enable HCP RAIN system administrators to configure service plans to set the ingest tier DPL to one, contact your authorized HCP service provider.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

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 on 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 on restore periods for erasure-coded objects, see Erasure coding topology properties.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

How HCP uses the information in service plans


If the service plan for a given namespace defines only the ingest tier, for each object in that namespace, the protection service works to ensure that:

The correct number of copies of the object data are always stored on the ingest tier, which can be primary running storage or S Series storage

The correct number of copies of the object metadata are always stored on primary running storage

For details on how the protection service works, see Protection service.

If the service plan for a given namespace defines multiple storage tiers, the storage tiering service works to ensure that each object in that namespace is stored on the correct tier and the correct number of copies of the object are stored on each tier.

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 from the previous tier, creates or deletes copies of the object data as required to satisfy the DPL setting for the new tier

oIf the new tier has a different primary running storage metadata protection level (MPL) from the previous tier, creates or deletes copies of object metadata as 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 the ingest tier (primary running storage or S Series storage)

Checks to see whether 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 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 (primary running storage or S Series storage)

For more information about how the storage tiering service works, see Storage tiering service.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Metadata-only storage tiers


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 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.

A service plan can include 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 the service plan also specifies that no copies of the data for that object can be stored on any storage tier, including the ingest tier.

Each service plan can be configured to define only one metadata-only storage tier. Additionally, 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 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.

For the purpose of making objects metadata-only, the storage tiering service treats each part of a multipart object as a separate object. The applicable number of copies of the metadata for the part are stored on primary running storage, and no data for the part is stored on any storage tier.

Erasure-coded objects are never made metadata-only on any system in the applicable erasure coding topology. If an erasure-coded object is due to move to a metadata-only storage tier, the chunk for the object remains on the previous tier.

On the other hand, an object that is subject to erasure coding but not yet erasure coded can be made metadata-only on a system if all of these are true:

The system does not have a chunk for the object.

The erasure coding delay has not yet expired for the object.

The object is due to be made metadata-only on that system.

At least one other available system in the erasure coding topology has a full copy of the object data.

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.

ImportantWebHelp.png

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.

NoteWebHelp.png

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.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Rehydration


HCP reads objects most efficiently from the ingest tier, which can be either primary running storage or S Series storage, on the system that’s the target of the read request. If you anticipate frequent reads of the same objects in a namespace while the objects are stored on a specific extended storage tier, consider reconfiguring the service plan used by the namespace to enable rehydration on the applicable tier. Similarly, if you anticipate frequent reads of the same objects in a namespace that contains metadata-only objects, consider configuring the service plan used by the namespace to enable rehydration on the metadata-only tier.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Default service plan configuration settings


Each HCP system has a service plan named Default that’s automatically created and configured during the HCP software installation. The Default service plan is applied to each tenant and namespace for which another service plan is not explicitly selected.

When the HCP system is first installed, the Default service plan defines primary running storage (the ingest tier) as the only storage tier. On SAIN and VM systems, by default, the ingest tier DPL and MPL are both set to one. On RAIN systems, by default, the ingest tier DPL and MPL are both set to two.

You can modify the Default service plan at any time to define one or more additional storage tiers or to change the ingest tier DPL and MPL settings.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

General considerations for namespace service plans


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:

1.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.

2.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.

3.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.

4.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.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

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.

NoteWebHelp.png

Note: 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.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Storage allocation for objects on an S Series or extended storage tier


Each 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 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 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 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 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.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

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:

1.Primary running storage

2.S Series storage

3.Primary spindown storage

4.NFS storage

5.Cloud storage

6.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:

1.Primary running storage

2.Primary spindown storage

3.Primary running storage on a remote system to which the object has been replicated

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

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.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

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 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.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Considerations for service plans on an upgraded system


Starting in HCP 7.0, the behavior that’s governed by namespace service plans has been expanded to include the specification of the DPL setting and the primary running storage tier MPL setting for each storage tier that’s defined for a namespace by its service plan. As a result, starting in HCP 7.0, the system-level DPL setting has been deprecated and replaced with the ingest tier DPL setting for the default service plan, and the namespace DPL and MPL settings have also been deprecated.

During an upgrade from HCP 6.x to HCP 7.0 or later, to maintain the behavior of the system-level DPL setting and the namespace DPL and MPL settings that are in effect for each namespace that’s defined on an HCP system, the HCP Setup program will update existing service plans and create new service plans for each namespace, as needed.

After an upgrade completes, all existing service plans will be upgraded to use the HCP 7.x format. In addition, HCP will ensure that each namespace has a new or existing service plan that sets the correct DPL and primary running storage MPL for each storage tier that’s defined for the namespace.

During an upgrade from HCP 6.x to HCP 7.0 or later, if the system-level DPL setting was in use before the upgrade, HCP Setup modifies the default service plan to use the system-level DPL setting as the ingest tier DPL. If any namespace has a DPL setting of Dynamic and the default service plan is not assigned to that namespace, then HCP Setup either modifies the existing service plan for that namespace or creates a new service plan for that namespace to ensure that the current system-level DPL setting is used for each storage tier that’s defined for the namespace.

After modifying the ingest tier DPL setting for the default service plan (if necessary) then for each existing service plan:

If the existing service plan is assigned to one or more namespaces, and all of those namespaces have the same DPL setting (for example, Dynamic, or 1), HCP Setup reconfigures the existing service plan to specify the existing namespace DPL setting as the ingest tier DPL.

If the existing service plan is assigned to multiple namespaces that have different DPL settings, then for those namespaces, HCP Setup performs the following procedure:

1.HCP Setup creates a new, retired service plan for each unique combination of an existing namespace DPL setting and the existing service plan storage tier specification.

2.HCP configures each namespace to replace the existing service plan with the applicable retired service plan that’s required to maintain the behavior of the original namespace DPL setting on each storage tier that was defined by the original service plan.

After an upgrade from HCP 6.x to HCP 7.0 or later, the new retired service plans created by HCP Setup are not configurable, and each assignment of a retired service plan to a given namespace overrides the previous service plan assignment that was configured for that namespace before the upgrade.

As a result, for each namespace to which HCP Setup has assigned an automatically generated, retired service plan:

If the namespace is owned by a tenant that’s not configured to allow the tenant administrator to assign a new service plan to the namespace:

oBecause a retired service plan is currently in use by the namespace, HCP generates a system-level alert to inform you that you need to assign a new service plan to the namespace.

oTo respond to the alert, you need to take one of these actions:

Change the status of the retired service plan from retired to active, and continue to use the new service plan that HCP Setup has generated for the namespace.

Assign a new service plan to the tenant that owns the namespace (and, therefore, assign that new service plan to all namespaces owned by that tenant).

Configure the tenant that owns the namespace to allow tenant administrators to assign a specific service plan to each of the tenant's namespaces. In this case, the retired service plan will continue to be assigned to the namespace until a tenant administrator configures the namespace to assign a new service plan to it.

If the namespace is owned by a tenant that is configured to allow the tenant administrator to assign a new service plan to the namespace:

oBecause a retired service plan is currently in use by the namespace, HCP generates a tenant-level alert to inform tenant administrators that a new service plan needs to be assigned to the namespace.

oIn response to this alert, a tenant administrator needs to assign a new service plan to the namespace.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Working with service plans


Each namespace has a service plan that defines both a storage tiering strategy and a data protection strategy for the objects in that namespace. At any given point in the lifecycle of an object, its storage tiering strategy specifies the types of storage on which copies of that object must be stored, and its data protection strategy specifies the number of object copies that must be stored on each type of storage.

A service plan is a named specification of HCP service behavior that determines how HCP manages the storage of the data and metadata for objects in a given namespace. For example, the service plan for a namespace could specify that the storage tiering service should move objects from primary running storage to primary spindown storage 30 days after they’re stored and specify that the protection service should ensure that HCP maintains two copies of the data for each object that exists on primary spindown storage. Service plans enable you to tailor a storage tiering strategy and a data protection strategy for each tenant and its namespaces based on specific storage usage patterns or business needs.

You can create any number of service plans on an HCP system and configure each plan to use up to four different storage tiers, including the ingest tier (primary running storage or S Series storage). You can then offer a wide variety of service plans to tenant administrators in order to meet the business needs of each tenant.

You can use the Storage page in the System Management Console to create, modify, retire, and delete service plans. You can also use the Storage page to monitor the usage of all primary spindown storage and extended storage tiers that are defined by any given service plan.

To display the Storage page, in the top-level menu of the System Management Console, click on Storage.

RoleWebHelp.png

Roles: To view existing service plans and monitor storage usage for storage tiers defined for one or more service plans, you need the monitor or administrator role. To create, modify, retire, and delete service plans, you need the administrator role.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Creating a service plan


To create a service plan:

1.On the left side of the Storage page, click on the Service Plans tab.

2.At the top of the Service Plans panel, click on Create Service Plan.

The Create Service Plan wizard opens.

3.On the Name page in the wizard, use the applicable fields to specify a name for the new service plan and, optionally, a description for the service plan.

A service plan name must be from one through 64 characters long, can contain only alphanumeric characters, hyphens (-), and underscores (_), and are not case sensitive.

A service plan description can be up to 1,024 characters long and can contain any valid UTF-8 characters, including white space

4.Click on Next.

5.On the Import page in the wizard, you are given the option to import the configuration for an existing service plan into the service plan you’re creating. When you import the configuration for an existing service plan, the storage tiers that are configured for that plan are automatically defined in the new plan. You can then use the imported service plan configuration as a starting point to configure each of the tiers you want to define in the service plan.

If you want to import the configuration for an existing service plan into the new service plan you’re creating, check the box next the existing service plan you want to import.

6.Click on Next.

7.On the Review page in the wizard, review the information you entered in the wizard.

8.Take one of the following options:

oIf the information you entered is correct, click on Finish.

oIf the information is incorrect, use the Previous and Next buttons to navigate through the pages of the wizard and make the changes you want. When you’re satisfied with the configuration settings you’ve entered, click on Finish.

When you click on Finish, the wizard exits, and the Storage page displays the Tiers panel on the service plan configuration page for the service plan that you’ve just created.

You can use Tiers panel to add one or more new tiers to the service plan configuration. If you chose to import the configuration from another service plan into the new plan you created, you can also delete or modify any of the existing tiers that were imported from that plan. For more information on this, see Modifying a service plan below.

If you’re satisfied with the storage tiers that are configured for the new service plan, you can click on the Tenants tab at the top of the page and use the Tenants panel to assign the service plan to one or more tenants. For more information on this, see Assigning a service plan to one or more tenants.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Modifying a service plan


You can use the Service Plans panel on the Storage page to view and modify the configuration of any existing service plan. At any time, you can modify any service plan to:

Change the service plan name or description. Note that when you change the name, the original name remains associated with any applicable tenants and namespaces. The result is that these tenants and namespaces are associated with an undefined service plan, and HCP uses the Default service plan for them. If you subsequently create a new service plan with the original name, that plan then applies to those tenants and namespaces.

Change the ingest tier.

Add one or more new storage tiers to the storage tiering strategy that’s defined in the service plan.

Delete one or more existing storage tiers from the plan.

Change any configuration settings used for any given storage tier that’s defined in the service plan.

When you change the storage tiering strategy or the data protection strategy that’s defined in a service plan, objects that complied with the original service plan requirements may not be in compliance with the new ones. The next time the storage tiering service processes such an object, the service moves, copies, deletes, or changes the object as needed to comply with the new storage tiering strategy and/or to comply with the new data protection plan.

Assign the service plan to one or more tenants.

NoteWebHelp.png

Note: When you assign a service plan to an existing tenant, that service plan replaces the one that was previously in effect for the tenant. Similar to a change in the configuration for an existing service plan for a namespace, when you change the service plan that’s assigned to a tenant, the new storage tiering strategy and data protection strategy do not take effect until the next time the storage tiering service runs.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Modifying basic configuration settings for a service plan


You can modify the basic configuration settings for any service plan to change either the name or the description that’s used for the service plan. To modify the basic configuration settings for a specific service plan:

1.On the left side of the Storage page, click on the Service Plans tab.

2.On the Service Plans panel, click on the table row that corresponds to the service plan for which you want to configure a new storage tier.

3.At the top of the panel that opens, click on the Settings tab.

4.On the Settings panel, use the applicable fields to change the service plan name or to specify a new description for the service plan.

5.At the bottom of the page, click on Update Settings.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Adding a storage tier to a service plan


You configure any storage plan to define up to four different storage tiers, including the ingest tier. To modify an existing service plan to add a new storage tier:

1.On the left side of the Storage page, click on the Service Plans tab.

2.On the Service Plans panel, click on the service plan for which you want to configure a new storage tier.

3.At the top of the panel that opens, click on the Tiers tab.

4.On the Tiers panel, click on Add Tier.

The Add Tier wizard opens.

5.On the Transition page in the wizard, use the appropriate fields to set these transition criteria:

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.

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.

6.Click on Next.

7.On the Options page in the wizard, use the applicable fields to specify:

oWhether to enable rehydration for the new storage tier, and if so, the number of days an object must remain on the ingest tier after it’s rehydrated

oWhether to make this storage tier metadata-only

8.Click on Next.

9.Take one of these actions:

oIf in step 7 above, you did not select the option to make this tier metadata-only, on the Storage Pools page:

The wizard displays a table containing a list of all of the storage pools that you can include in the storage tier, along with a check box that corresponds to each storage pool in the list. Use the checkboxes in the left column in the table to select one or more storage pools to be included in the tier.

A dropdown list box appears next to the name of each storage pool you select. Use these fields to specify the number of copies of object data that HCP must maintain on each storage pool for each object that’s moved to the storage tier you’re configuring. The total number of copies of object data that must be stored on each pool is the DPL for the storage tier.

In the Metadata Copies on Primary Storage field, specify the primary running storage MPL for the new tier. This is the number of copies of the object metadata that HCP must maintain on primary running storage for each object that’s moved to the new storage tier.

At the bottom of the page, select I Understand to indicate that you understand the consequences of moving all copies of the object data to the new tier.

oIf in step 7 above, you selected the option to make this tier metadata-only, on the Storage Pools page:

In the Metadata Copies on Primary Running Storage field, specify the primary running storage MPL for the new tier. This is the number of copies of the object metadata that HCP must maintain on primary running storage for each object that’s moved to the new storage tier.

Select I Understand to indicate that you understand the consequences of moving all copies of the object data to the new tier. In this case, this statement means that you understand that the DPL of the new tier is zero, so all copies of the object data will be deleted for each object that’s moved to the new tier.

10.Click on Next.

11.On the Review page in the wizard, review the storage tier configuration settings that you specified in the wizard.

12.Take one of the following options:

oIf the information you entered is correct, click on Finish.

oIf the information is incorrect, use the Previous and Next buttons to navigate through the pages of the wizard and make the changes you want. When you’re satisfied with the configuration settings you’ve entered, click on Finish.

When you click on Finish, the wizard exits, and the Storage page displays the Tiers panel on the service plan configuration page for the service plan for which you’ve just created a new storage tier.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Removing one or more storage tiers from a service plan


To modify an existing service plan to delete one or more storage tiers:

1.On the left side of the Storage page, click on the Service Plans tab.

2.On the Service Plans panel, click on the table row that corresponds to the service plan for which you want to configure a new storage tier.

3.At the top of the panel that opens, click on the Tiers tab.

4.The Tiers panel opens, showing a list of storage tiers that are currently configured for the service plan. A delete control ( DeleteControl.png ) appears in the row for each storage tier except for the ingest tier.

5.Click on the delete control for any storage tier to delete it from the service plan.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Choose the ingest tier


The default ingest tier for HCP is primary running storage. If you have HCP S Series Node on your HCP system, you can select S Series storage pools as the ingest tier of a service plan. This means that all objects ingested through namespaces under that service plan are written directly to S Series Nodes rather than primary running storage. Regardless of the ingest tier, HCP keeps all object metadata on primary running storage.

If one or more namespaces on the service plan have ingested data through CIFS, NFS, or WebDAV, the service plan ingest tier cannot be changed to HCP S Series. Likewise, NFS, CIFS, and WebDAV cannot be enabled on namespaces that have HCP S Series set as the ingest tier.

NoteWebHelp.png

Note: The following services do not process objects ingested or tiered to S Series storage: compression, content verification, duplicate elimination, shredding, hardware encryption, capacity balancing, and scavenging.

Select primary running storage as the ingest tier

To select the primary running storage as the ingest tier:

1.On the left side of the Storage page, click on the Service Plans tab.

2.On the Service Plans panel, click on the table row that corresponds to the service plan for which you want to configure a new storage tier.

3.At the top of the panel that opens, click on the Tiers tab.

4.On the Tiers panel, click on the tier you want to modify.

The Edit Tier wizard opens.

5.Select Primary running as the ingest tier.

NoteWebHelp.png

Note: Selecting Primary running as the ingest tier deselects all HCP S Series options. You cannot have both Primary running and HCP S Series as the ingest tier.

6.In the Data field, select the number of data copies you want to have in your ingest tier at all times.

7.In the Metadata Copies on Primary Storage field, select the number of object metadata copies you want to keep on primary running storage at all times.

8.Click on Next.

9.On the Review page in the wizard, review the storage tier configuration settings that you specified in the wizard.

10.Take one of the following options:

oIf the information you entered is correct, click on Finish.

oIf the information you entered is incorrect, us the Previous and Next buttons to navigate through the pages of the wizard and make the changes you want. When you're satisfied with the configuration settings you've entered, click on Finish.

Select S Series storage pools as your ingest tier

To select an S Series pool, or pools, as your ingest tier:

1.On the left side of the Storage page, click on the Service Plans tab.

2.On the Service Plans panel, click on the table row that corresponds to the service plan for which you want to configure a new storage tier.

3.At the top of the panel that opens, click on the Tiers tab.

4.On the Tiers panel, click on the tier you want to modify.

The Edit Tier wizard opens.

5.Select the S Series pools you want to target as the ingest tier.

NoteWebHelp.png

Note: Selecting HCP S Series as the ingest tier deselects Primary running. You cannot have both primary running storage and S Series storage as the ingest tier. If you have the CIFS, NFS, or WebDAV protocol enabled on any namespace that's using the service plan, you cannot select HCP S Series as the ingest tier.

6.From the Data drop down field, select the number of copies you want to have in your ingest tier at all times. You can have a different number of copies for each pool.

7.From the Primary Storage panel, take one of the following steps:

oIf you want to remove all data existing on primary running storage prior to the change in ingest tier and move it to your S Series storage, deselect Keep current data on primary.

oIf you want to keep all data existing on primary running storage prior to the change in ingest tier on primary running storage, leave Keep current data on primary selected and select the number of copies of object data you want to keep of that data on primary running storage at all times.

8.From the Primary Storage panel Metadata dropdown field, select the number of copies of object metadata you want to keep on primary running storage at all times.

9.Click on Next.

10.On the Review page in the wizard, review the storage tier configuration settings that you specified in the wizard.

11.Take one of the following options:

oIf the information you entered is correct, click on Finish.

oIf the information you entered is incorrect, us the Previous and Next buttons to navigate through the pages of the wizard and make the changes you want. When you're satisfied with the configuration settings you've entered, click on Finish.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Assigning a service plan to one or more tenants


You can configure the service plan for a namespace to assign that service plan to any existing tenant. When you assign a particular service plan to a tenant, that service plan replaces the one that was previously assigned to the tenant.

NoteWebHelp.png

Note: Similar to a change in the configuration for an existing service plan for a namespace, when you change the service plan that’s assigned to a tenant, the new storage tiering strategy and data protection strategy do not take effect until the next time the storage tiering service runs.

To assign a service plan to one or more existing tenants:

1.On the left side of the Storage page, click on the Service Plans tab.

2.On the Service Plans panel, click on the table row that corresponds to the service plan for which you want to configure a new storage tier.

3.At the top of the panel that opens, click on the Tenants tab.

4.The Tenants panel, in the Tenants assigned other service plans section, use the checkboxes in the left column in the table to select the tenants to which you want to assign the service plan.

NoteWebHelp.png

Note: You can also use the checkboxes in the Tenants assigned service plan name field to deselect one or more tenants in order to delete those service plan assignments. However, if you do this, the deselected tenants will have no service plan assigned to them, so you’ll have assign new service plans to them. If you want to change the service plan that’s assigned to a specific tenant, you should modify the configuration for that tenant or modify the configuration of the new service plan to assign it to the tenant.

5.At the bottom of the page, click on Update Settings.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Retiring a service plan


You can retire a service plan at any time. When you retire a service plan, the plan remains in effect for all namespaces and tenants to which it is currently assigned. However, a retired service plan is no longer available to be assigned to any new or existing tenants or namespaces.

You can also reactivate a retired service plan at any time to make that service plan available to be assigned to tenants and namespaces once again.

To retire or reactivate a service plan:

1.On the left side of the Storage page, click on the Service Plans tab.

2.On the Service Plans panel, click on the table row that corresponds to the service plan for which you want to configure a new storage tier.

3.At the top of the panel that opens, click on the Settings tab.

4.On the Settings tab, in the Retire service plan section, take one of these actions:

oIf you want to retire the service plan, select Retire.

oIf you want to reactivate the service plan, deselect Retire.

5.At the bottom of the page, click on Update Settings.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Deleting a service plan


You can delete any service plan except the Default service plan at any time. However, in order to delete a service plan that’s assigned to one or more tenants or namespaces, you need to specify a replacement service plan for those tenants and namespaces.

When you delete a service plan, objects to which that plan applied must now comply with the replacement service plan that you specified when you deleted the plan. The next time the storage tiering service processes such an object, the service moves or changes the object as needed to comply with the specified replacement service plan.

To delete a service plan:

1.On the left side of the Storage page, click on the Service Plans tab.

2.The Service Plans panel displays a list of service plans that are currently configured on the HCP system. A delete control ( DeleteControl.png ) appears next to each service plan that’s not currently assigned to any tenants or namespaces.

Take one of these actions:

oIf the service plan you want to delete is not currently assigned to any namespaces or service plans, on the Service Plans panel:

1.Click on the delete control ( DeleteControl.png ) in the table row that corresponds to the service plan you want to delete.

2.In response to the confirming message, click on Delete.

oIf the service plan is associated with one or more tenants or namespaces, on the Service Plans panel:

1.Click on the table row that corresponds to the service plan that you want to delete.

2.At the top of the panel that opens, click on the Manage tab.

3.On the Manage panel, in the Delete service plan section in the Replacement Service Plan field, select the service plan that you want to assign to all namespaces and tenants that are currently assigned to the service plan you want to delete.

4.Click on Delete Service Plan.

HCP deletes the service plan from the system and assigns the specified replacement service plan to each tenant and namespace to which the deleted service plan was assigned.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

 

  • Was this article helpful?