This chapter describes the general connectivity and network setup for Transparent Cloud Tiering (TCT). It also addresses best practices for a high availability (HA) configuration.

This chapter includes the following topics:

When planning the network connectivity for the tiered storage, you need to consider two parts for the communication path. Figure 5-1 shows the IP communication paths between the host and cloud object storage.

The first part is the communication between DFSMS on the host and the HMC that is acting as cloud proxy (except for SWIFT). This connection is used to exchange the meta-data objects and controls the data that is sent to or received from the cloud.

DFSMS communicates with the HMC through REST API calls. These API calls are issued for a single HMC and you can only configure one HMC connection in DFSMS. Therefore you can come into a situation where the HMC is not available and the API call fails. This situation can occur, for example, when the HMC is updated, rebooted or a service action is performed against the HMC. In this case, TCT operations will fail. You either have to wait until the HMC is operational again or configure another HMC in the DFSMS networking definitions, as described in 7.4, “Creating a DFSMS cloud network connection by using ISMF” on page 70.

The second part is the connection between the DS8000 internal servers and the cloud storage, which is used to transfer the meta data objects and the customer data between the DS8000 and the cloud storage. The configuration of this connection depends on the type of object storage you use and is described in detail in the following sections.

While connecting to a cloud storage service that is hosted by a cloud provider, you just have to configure the access URI, whereby connecting to a TS7700 or an on-premises cloud storage you might need to take additional considerations to ensure the redundant access.

You can mix and match the following connection methods to prepare a multi-cloud storage configuration.

The internal servers communicate only with the cloud endpoint and the DNS service (if defined). Network communication is always initiated by the DS8000 internal servers. Their internal firewall blocks all inbound requests.

When using TS7700 Tape Virtualisation Engine as object storage, you have to connect the DS8900F internal servers to the TS7700 grid network.

Each internal server of the DS8000 must be able to communicate with each IP address of the TS7000 that you define in the DS8000 logical configuration (according to “Connecting to a TS7700 Virtualization Engine” on page 57).

If you are using multiple independent grid networks (physically or virtually separated) as shown in Figure 5-2 on page 47, you must connect one network port of each DS8900F internal server to each of the independent networks.

When you plan to connect to a privately hosted cloud object store, the access can be either direct or through a load balancer. You can benefit from using a load balancer, as it provides fail-over capabilities and workload distribution to your object store nodes as illustrated in Figure 5-3 on page 48. Follow the cloud object store recommendations to install and configure a load balancer to improve fault tolerance and highly availability.

When you connect to a cloud hosted object storage instance, the cloud provider usually provides the URI to access your cloud storage. From a networking perspective, you must ensure that both DS8000 internal servers can access the URI destination. Both internal servers must also be able to access your DNS service to resolve the hostname of your cloud endpoint.