PowerScale OneFS 9.2.1.0 CloudPools Administration Guide

Configuring access to cloud data from a secondary cluster

You can make cloud data available on a secondary cluster if your primary cluster becomes unavailable.

To configure such access, you must have replicated the primary cluster's data onto a secondary cluster using SyncIQ. Alternatively, you can restore an NDMP backup of the data to a secondary cluster.

The secondary cluster must have active SyncIQ, SmartPools, and CloudPools licenses.

With SyncIQ, when failover to a secondary cluster is required, two use cases are supported: short-term failover versus long-term failover.

In the short-term failover use case, the intention is to restore and failback to the primary cluster as quickly as possible. The secondary cluster is a temporary solution, enabling users to open SmartLink files from supported protocols and access cloud data as usual. Instead of writing any changes back to the cloud, however, CloudPools caches these changes locally in the SmartLink files on the secondary cluster. After the primary cluster is restored to service, CloudPools writes back any changes on the secondary cluster to the primary cluster. Cached data in SmartLink files will then be written back to cloud storage.

In a long-term failover situation, in which the primary cluster will be out of service for an extended period or decommissioned entirely, other considerations become important. In this scenario, because only one cluster can have write access to cloud storage, you need to transfer write access to the failover cluster. From a CloudPools perspective in this scenario, the failover cluster effectively becomes the primary cluster. See Configure write access to cloud pool data in long-term failover situations

With the NDMP approach, however, the short-term failover scenario is less practical. The secondary cluster should be given cloud write access to enable any cached modifications to SmartLink files to be written back to cloud storage. The alternative would be to somehow write modified SmartLink files back to the primary cluster after it is restored to service, but this might be more time-consuming.