In this chapter, we describe the TS7760 Cloud Storage Tier and its components.

Building on over 20 years of virtual tape experience, the TS7760 now supports the ability to store virtual tape volumes in an object store. The TS7700 supported offloading to physical tape for over two decades.

Offloading to physical tape behind a TS7700 is utilized by hundreds of organizations around the world. By using the same hierarchical storage techniques, the TS7700 can also offload to object storage.

Because object storage is cloud-based and accessible from different regions, the TS7760 Cloud Storage Tier support allows the cloud to be an extension of the grid. A high-level overview of TS7760 Cloud Storage Tier support is shown in Figure 4-1.

A Cloud Storage Tier enabled cluster, or TS7760C, can be a member of any grid if the peer cluster code levels are compatible. Peers can be other TS7760C clusters, TS7700T clusters, or disk only TS7700 clusters. By using management class policies, virtual volumes are replicated among peers in the grid. Those peers with Cloud Storage Tier support then can offload to an object store.

After one TS7760C cluster offloads a logical volume, other peers that attempt to offload the same logical volume detect that the volume exists in the object store and can skip the premigration phase. Either cluster can then recall the logical volume from the cloud, if needed.

Logical volumes offload in their entirety to the object store. If the only available logical volume copy in the grid is within an object store, one of the TS7760C clusters who migrated that volume previously can recall it into disk cache. After the entire volume is present in disk cache, the content is accessible by using the existing grid techniques.

Because a volume must be recalled entirely, choosing logical volume sizes that are smaller can provide faster time to access when the entire content of the logical tape is not being accessed.

A high-level view of how a TS7760C can use an object store as a tier of storage is shown in Figure 4-2.

Similar to TS7760 Tape Attach, the TS7760C includes disk cache partitions that are available to manage the disk cache footprint of the TS7760C. Workloads that benefit from larger disk cache footprints can use a large disk cache partition; workloads that do not require as much disk cache residency can target smaller partitions.

TS7760C disk cache partition support works much the same as TS7760T, as shown in Figure 4-3.

Logical volumes that target any partition other than the residency-only partition premigrate to an object store immediately. The policy that is assigned to the logical volume and how much space is available in the partition determines if and when the logical volume is removed from disk cache after the premigration. That is, as with the TS7760T, the copy in disk cache is removed, which makes the cloud instance the only available copy in that cluster. A recall of the logical volume from the object store into the disk cache is required if that cluster was chosen for the tape volume cache (TVC) or a copy source.

By using the TS7700 grid network (same physical link), the TS7760C can communicate with regional and multi-region object store configurations. For example, a two site configuration is shown in Figure 4-4 in which each site has three Accessers that are used for connectivity to the IBM Cloud Object Storage vault.

Another sample of a cross region replication configuration for Amazon S3 is shown in Figure 4-5.

Similar to TS7700 disk-only that is mixed with TS7760T clusters, the TS7760C can be mixed within the same grid. At the time of this writing, a particular cluster cannot be both Tape Attach and support Cloud Storage Tier at the same time; therefore, the two features are mutually exclusive.

However, Cloud Storage Tier clusters can be mixed in a grid with disk-only and Tape Attach clusters. Hybrid grid concepts apply with TS7760C clusters as they did with TS7700T clusters. An example of a Hybrid grid where TS7760, TS7760C, and TS7760T clusters exist is shown in Figure 4-6. By using auto-removal policies, data can migrate towards the clusters with deep capacity through physical tape or cloud storage tier support.

Cloud pools are used by the TS7760C to segregate data in the cloud. A user can define a grid-scope cloud pool as a method to separate data by type, by user or tenant or even by object store target. Through policy management, workloads are assigned to a particular cloud pool so all logical volumes that are assigned to the particular cloud pool are in the same object store container or mirrored container. As of this writing, only one cloud pool per grid is supported. Future enhancements will support up to 128 cloud pools.

Accounts are used by the TS7760C to authenticate with a particular object store. A user can define up to 128 grid-scope accounts, which contain information, such as user key and a secret key or password. By using accounts, the TS7760C can authenticate with object stores to store data for a specific cloud pool.

Containers are used by the TS7760C to store and retrieve data in an object store. A user defines a container for a specific vault or bucket in the object store. The container is then tied to a cloud pool and account.

Data that is associated with the assigned cloud pool uses the provided account information to authenticate with the assigned vault or bucket. More than one container can be defined because each region of the grid can access a different bucket or require different user credentials to authenticate with the object store. Up to 128 grid-scope containers can be defined.

URLs are required before vaults or buckets can be accessed. After one or more TS7760C containers are defined, one or more URLs can be assigned to that container. The URLs provide the address of how the TS7760C can communicate with the vault or bucket in the object store. For IBM Cloud Object Storage, this URL can be one or more IP addresses that are associated with Accessers or network load balancers.

For Amazon S3, a single URL is generated by using the bucket name that is provided in the container definition. After a container has one or more URLs assigned to it, one or more TS7760C clusters in the grid must be associated with the URLs. That is, the URLs that are provided are grid-scope and can be used by any TS7760C cluster. However, which clusters use which URLs can be unique; therefore, a cluster association with each cluster and its assigned URLs must be made.

A high-level overview of how URLs are used to connect to a vault in an object store by using credentials that are assigned in an account is shown in Figure 4-7. The container definition ties them together.

In this section, we describe how the TS7760C works with different object store resiliency use cases. As described in Chapter 2, “Container resiliency” on page 9, there are different methods of which object stores can be resilient.

For availability purposes, the TS7700 supports multiple URLs for a specific container, which allows one or more Accesser to be used from an IBM Cloud Object Storage setup. With container URL definitions, each region can access a different set of URLs or Accessers so that the local most efficient connection into the object store is used.

When vault mirroring or cross-region replication is enabled, two containers can be defined at each region that are tied to the same cloud pool. This way, each region can use its own container definition, set of URLs, and credentials to access the same content in the cloud pool.

When the TS7760C attempts to premigrate logical volumes to a mirrored bucket, the TS7760C always checks if the mirror copy exists before skipping the premigration. This extra audit provides another layer of security by not removing grid replicated volumes from disk cache unless the “copy in the cloud” truly is available at the alternative location.