HCP System Management Help


Storage for HCP systems

An HCP system includes multiple nodes that are networked together, where each node is either an individual server, a blade in a blade server, or a virtual machine. Each physical node can have multiple internal drives and/or can connect to SAN storage. Each virtual node emulates a server that has only internal drives.

The physical storage that’s managed by the nodes in the HCP system is called primary storage. By default, primary storage consists entirely of running storage, which is storage on continuously spinning disks. However, an HCP SAIN system can be configured to use SAN storage that includes both running storage and spindown storage, which is storage on disks that can be spun up or spun down as needed. If primary spindown storage is enabled on an HCP SAIN system, you can configure HCP to use that storage for tiering purposes.

You can also add HCP S Series Nodes to your HCP system. These nodes can be used as an alternative to primary running storage or for tiering purposes. This is known as economy storage. The amount of objects you can write to an HCP S Series Node is limited to the total storage capacity of the node. If you want more storage capacity, you need to purchase more HCP S Series Nodes. The HCP system communicates with the HCP S Series Nodes through HS3 and the management API.

You can also configure any HCP system to use extended storage, which is additional storage that’s managed by devices outside of the HCP system, for tiering purposes.

You can configure HCP to access and store object data on these different types of extended storage:

NFS — Volumes that are accessed on physical storage devices using NFS mount points

Amazon S3 — Cloud storage that’s accessed using an Amazon Web Services user account

Google Cloud — Cloud storage that’s accessed using a Google Cloud Platform user account

Microsoft Azure — Cloud storage that’s accessed using a Microsoft Azure user account

S3-compatible — Any physical storage device or cloud storage service that’s accessed using a protocol that’s compatible with the Amazon S3 access protocol

Verizon Cloud— Cloud storage that’s accessed using a Verizon Cloud Service user account

Important: Extended storage is intended to increase the amount of storage that’s available to HCP. Extended storage does not function as backup storage. You should secure, back up, and monitor the health and availability of each extended storage device and cloud storage service that you use to store data in an HCP repository.

Unless you are writing directly to HCP S Series Nodes, see Choose the ingest tier, HCP initially stores each object in a repository on primary running storage. By default, throughout the lifecycle of an object, HCP continues to store all copies of the data and metadata for that object only on primary running storage. However, you can configure HCP to offload object content from primary running storage and store that content on primary spindown storage (if it’s available), on HCP S Series Nodes, or on any of the supported types of extended storage that you have configured HCP to access and use.

Using primary spindown storage to store object content that’s accessed infrequently saves energy, thereby reducing the cost of storage.

Note: While all copies of the data, custom metadata, ACL, and secondary metadata for an object can be moved onto primary spindown storage, all copies of the primary metadata for an object must always remain on primary running storage.

For information about how HCP creates, manages, and uses copies of the data, primary metadata, secondary metadata, and ACL for each object in an HCP repository, see Metadata storage.

Note: While all of the data for an object can be written directly to economy storage or later moved off of primary running storage and stored on economy or extended storage, at least one copy of the system metadata, custom metadata, and ACL for that object must always remain on primary running storage.

HCP moves object content from primary running storage onto one or more other types of storage according to rules specified in service plans.

Each namespace has a service plan that defines one or more tiers of storage that can be used to store objects in that namespace. For each object in a given 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.

You can set the HCP initial storage tier, called the ingest tier, to either primary running storage or to the HCP S Series. When a service plan is first created, it defines only the ingest tier, so HCP stores all objects in a given namespace on the designated ingest tier throughout the entire object lifecycle.

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 a storage tiering strategy that specifies multiple storage tiers.

© 2017 Hitachi Vantara Corporation. All rights reserved.