Skip to main content
Sign Out

Welcome to Dell

My Account
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Enjoy members-only rewards and discounts
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.
Sign In Create an Account Dell Financial Services Premier Sign In Partner Program Sign In
Contact Us

Your Dell.com Carts

PowerScale OneFS 9.2.1.0 CloudPools Administration Guide

PDF

Configure write access to cloud pool data in long-term failover situations

In the case of a long-term failover situation, you can provide write access to data in the cloud to the secondary (failover) cluster.

Prerequisites

Prerequisites are:

  • Data from the primary (source) cluster must have been replicated to or restored on the secondary (target) cluster by a SyncIQ or NDMP process.
  • The secondary (target) cluster must have both a SmartPools and CloudPools license.
  • You must know or be able to obtain the GUID associated with the cloud data. Best practice would be to obtain and save this information before you actually need to use it, when the cloud data is configured. Otherwise, see Step 1 in the procedure below.

About this task

By default, write access to cloud data can occur only from the OneFS cluster that originally archived the data to the cloud. In a short-term failover scenario, the secondary cluster reads the data from the cloud and, if the user makes any modifications, the secondary cluster collects modifications in cache. When the original cluster is available again and failover is complete, the original cluster takes over and writes the cached modifications to the cloud.

In a long-term failover situation, dependence on cached modifications is risky. In that case, you might choose to provide the secondary cluster with write access to the cloud data.

CAUTION This capability is offered to work around cases where the primary cluster will be unavailable for an extended period. Never allow write access to cloud data from more than one cluster at a time because it can result in data corruption. Before allowing another cluster to have cloud write access, make sure that cloud write access is removed from the primary cluster, or that the primary cluster is offline and remains offline. If the primary cluster becomes available again, continue to ensure that only one cluster has write access to the cloud data. Do this by removing write access from the secondary cluster before allowing the primary cluster to regain write access.

The following procedure describes how to remove write access to cloud data from one cluster and provide that access to another cluster. Follow the steps in the order shown.

CAUTION If the primary cluster is not operational and cannot be made operational, you are forced to skip step 3. In that case, you must be sure to remove the write access from the secondary cluster before attempting to restart the primary cluster. Data corruption could result if two clusters have write access to the cloud data.

Steps

  1. Obtain the GUID that is associated with the cloud data.

    The GUID of the cluster that originally archived the cloud data is permanently associated with the cloud data. In most scenarios, this is the GUID of the primary cluster. If you have reconfigured clusters, it is possible that the primary cluster is not the one that originally archived to the cloud.

    On the cluster that originally archived to the cloud, run this command: 

    isi cloud access list
    The GUID of the cluster on which you are running the command is identified with the phrase (current).

    Other GUIDs, if any, identify other clusters on which data was archived (using another account) and from which data has been replicated with SyncIQ or restored with NDMP.

  2. Failover to the secondary cluster.
  3. On the primary cluster, remove write access to the cloud data. 
    # isi cloud access remove <GUID>
    where <GUID> is the GUID of the cluster that originally archived the cloud data. For example: 
    # isi cloud access remove ab9dd991261e11e382240800200c9a66
  4. On the secondary cluster, give write access to the cloud data. 
    # isi cloud access add <GUID>
    where <GUID> is the GUID of the cluster that originally archived the data. For example: 
    # isi cloud access add ab9dd991261e11e382240800200c9a66

Results

The secondary cluster can write modifications to the cloud, rather than storing the modifications in cache.

Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\