Restoring a WAN Connection

This sequence of steps restores a bidirectional WAN connection to a service instance when the service instance has been restored from backup.

In this description, cluster A is an existing, running service instance that was formerly connected to cluster B over a WAN connection, and cluster B is the service that has been freshly restored from backup, and needs to be reconnected.

At this point in the process, cluster B should have the following characteristics:

  • All data restored from backup
  • The same distributed_system_id as its predecessor
  • A freshly-generated service key

If the restored distributed_system_id matches that in the backup, then there is no need to recreate gateway senders and receivers; they are already defined. This procedure manually updates gateway senders with pointers to remote locators and credentials, re-enabling their ability to connect across the WAN without authentication errors.

  1. Obtain the service key for cluster A. The service key will contain generated credentials that this example will use in reconnecting the cluster B service instance:

    $ cf service-key A k1
    

    The contents of the service key will differ based upon the cluster configuration, and if an authentication and enterprise single sign-on (SSO) system such as LDAP has been configured. With the enterprise SSO, there will not be cluster operator and developer users in the service key. Without the enterprise SSO, the service key appears as in this example. Within the service key, each username is generated with a unique string appended so there will be unique user names for the different roles. The user names and passwords in this example have been modified to be easy to understand, and they are not representative of the user names and passwords that will be displayed on your screen. Here is sample output from cf service-key A k1:

    Getting key k1 for service instance A as admin...
    
    {
     "distributed_system_id": "1",
     "locators": [
      "10.0.16.21[55221]"
      "10.0.16.22[55221]"
      "10.0.16.23[55221]"
     ],
     "urls": {
      "gfsh": "https://cloudcache-1.example.com/gemfire/v1",
      "pulse": "https://cloudcache-1.example.com/pulse"
     },
     "users": [
      {
       "password": "cl-op-ABC-password",
       "roles": [
        "cluster_operator"
       ],
       "username": "cluster_operator_ABC"
      },
      {
       "password": "dev-DEF-password",
       "roles": [
        "developer"
       ],
       "username": "developer_DEF"
      }
     ],
     "wan": {
      "sender_credentials": {
       "active": {
        "password": "gws-GHI-password",
        "username": "gateway_sender_GHI"
       }
      }
     }
    }
    
  2. Obtain the service key of cluster B:

    $ cf service-key B k2
    

    The contents of the service key will differ based upon the cluster configuration, and if an authentication and enterprise single sign-on (SSO) system such as LDAP has been configured. With the enterprise SSO, there will not be cluster operator and developer users in the service key. Without the enterprise SSO, the service key appears as in this example.

    Here is sample output from cf service-key B k2, which outputs details of the cluster B service key:

    Getting key k2 for service instance destination as admin...
    
    {
     "distributed_system_id": "2",
     "locators": [
      "10.0.24.21[55221]"
      "10.0.24.22[55221]"
      "10.0.24.23[55221]"
     ],
     "urls": {
      "gfsh": "https://cloudcache-2.example.com/gemfire/v1",
      "pulse": "https://cloudcache-2.example.com/pulse"
     },
     "users": [
      {
       "password": "cl-op-JKL-password",
       "roles": [
        "cluster_operator"
       ],
       "username": "cluster_operator_JKL"
      },
      {
       "password": "dev-MNO-password",
       "roles": [
        "developer"
       ],
       "username": "developer_MNO"
      }
     ],
     "wan": {
      "remote_clusters": [
      {
        "remote_locators": [
          "10.0.16.21[55221]",
          "10.0.16.21[55221]",
          "10.0.16.21[55221]"
        ],
        "trusted_sender_credentials": [
         "gateway_sender_GHI"
        ]
       }
      ],
      "sender_credentials": {
       "active": {
        "password": "gws-PQR-password",
        "username": "gateway_sender_PQR"
       }
      }
     }
    }
    
  3. Update the cluster A service instance to include the cluster B locators and the cluster B sender_credentials:

    $ cf update-service A -c '
    {
      "remote_clusters":[
      {
        "remote_locators":[
          "10.0.24.21[55221]",
          "10.0.24.22[55221]",
          "10.0.24.23[55221]"],
        "trusted_sender_credentials":[
        {
          "username":"gateway_sender_PQR",
          "password":"gws-PQR-password"
        }]
      }]
    }'
    Updating service instance A as admin
    
  4. To observe and verify that the cluster A service instance has been correctly updated, it is necessary to delete and recreate the cluster A service key. As designed, the recreated service key will have the same user identifiers and passwords; new unique strings and passwords are not generated. Use the cluster A Cloud Foundry credentials in these commands:

    $ cf delete-service-key A k1
    
    $ cf create-service-key A k1
    

    This example service key is shown assuming that an authentication and enterprise single sign-on (SSO) system such as LDAP has not been configured. The cluster A service key will now appear as:

    Getting key k1 for service instance A as admin...
    
    {
     "distributed_system_id": "1",
     "locators": [
      "10.0.16.21[55221]",
      "10.0.16.22[55221]",
      "10.0.16.23[55221]"
     ],
     "urls": {
      "gfsh": "https://cloudcache-1.example.com/gemfire/v1",
      "pulse": "https://cloudcache-1.example.com/pulse"
     },
     "users": [
      {
       "password": "cl-op-ABC-password",
       "roles": [
        "cluster_operator"
       ],
       "username": "cluster_operator_ABC"
      },
      {
       "password": "dev-DEF-password",
       "roles": [
        "developer"
       ],
       "username": "developer_DEF"
      }
     ],
     "wan": {
      "remote_clusters": [
       {
        "remote_locators": [
         "10.0.24.21[55221]",
         "10.0.24.22[55221]",
         "10.0.24.23[55221]"
        ],
        "trusted_sender_credentials": [
         "gateway_sender_PQR"
        ]
       }
      ],
      "sender_credentials": {
       "active": {
        "password": "gws-GHI-password",
        "username": "gateway_sender_GHI"
       }
      }
     }
    }
    
  5. Update the cluster B service instance to include the cluster A locators and the cluster A sender_credentials:

    $ cf update-service B -c '
    {
      "remote_clusters":[
      {
        "remote_locators":[
          "10.0.16.21[55221]",
          "10.0.16.22[55221]",
          "10.0.16.23[55221]"],
        "trusted_sender_credentials":[
        {
          "username":"gateway_sender_GHI",
          "password":"gws-GHI-password"
        }]
      }]
    }'
    Updating service instance B as admin
    
  6. To observe and verify that the cluster B service instance has been correctly updated, it is necessary to delete and recreate the cluster B service key. As designed, the recreated service key will have the same user identifiers and passwords; new unique strings and passwords are not generated. Use the cluster B Cloud Foundry credentials in these commands:

    $ cf delete-service-key B k1
    
    $ cf create-service-key B k1
    

    This example service key is shown assuming that an authentication and enterprise single sign-on (SSO) system such as LDAP has not been configured. The cluster B service key will now appear as:

    Getting key k1 for service instance B as admin...
    
    {
     "distributed_system_id": "2",
     "locators": [
      "10.0.24.21[55221]",
      "10.0.24.22[55221]",
      "10.0.24.23[55221]"
     ],
     "urls": {
      "gfsh": "https://cloudcache-2.example.com/gemfire/v1",
      "pulse": "https://cloudcache-2.example.com/pulse"
     },
     "users": [
      {
       "password": "cl-op-JKL-password",
       "roles": [
        "cluster_operator"
       ],
       "username": "cluster_operator_JKL"
      },
      {
       "password": "dev-MNO-password",
       "roles": [
        "developer"
       ],
       "username": "developer_MNO"
      }
     ],
     "wan": {
      "remote_clusters": [
       {
        "remote_locators": [
         "10.0.16.21[55221]",
         "10.0.26.22[55221]",
         "10.0.16.23[55221]"
        ],
        "trusted_sender_credentials": [
         "gateway_sender_GHI"
        ]
       }
      ],
      "sender_credentials": {
       "active": {
        "password": "gws-PQR-password",
        "username": "gateway_sender_PQR"
       }
      }
     }
    }
    
  7. To verify that the connection has been successfully restored, see Verify Bidirectional WAN Setup.