Skip to main content
A newer release of this product is available.

Cluster peers endpoint overview

Contributors
PDFs

Cluster peer operations

Cluster peering allows administrators of ONTAP systems to establish relationships between two or more independent clusters. Once a relationship exists between two clusters, they may then exchange user data, configuration information and coordinate operations. The /cluster/peers endpoint supports operations such as create, get, modify and delete using GET, PATCH and POST HTTP requests.

Creating a cluster peer

A new cluster peer relationship can be set up by issuing a POST request to /cluster/peers. Parameters in the POST body define the settings of the peering relationship. A successful POST request that succeeds in creating a peer returns a HTTP status code, code 201, along with the details of the created peer such as peer UUID, name, authentication information. A failed POST request returns an HTTP error code along with a message indicating the reason for the error. This can include malformed request and invalid operations.

Sample request

curl -X POST 'https://<mgmt-ip>/api/cluster/peers/' -d '{"authentication":{"expiry_time":"12/25/2018 12:34:56","generate_passphrase":true}}'
Examples
# Create - no params
body = {}

# Create with a peer address and a passphrase
body =
{
  "remote":
    {
        "ip_addresses":["1.2.3.4"]
    }
}

# Create with a peer name and a generated passphrase that is true
body =
{
  "name":"cp_xyz123",
  "authentication":
    {
        "generate_passphrase":true
    }
}

# Create with a name, a peer address, and a passphrase
body =
{
  "name":"cp_xyz123",
  "remote":
    {
        "ip_addresses": ["1.2.3.4"]
    },
  "authentication":
    {
        "passphrase":"xyz12345"
    }
 }

# Create with a proposed encryption protocol
body =
{
  "encryption":
    {
        "proposed":"tls-psk"
    }
}

Creating local intercluster LIFs

The local cluster must have an intercluster LIF on each node for the correct operation of cluster peering. If no local intercluster LIFs exist, you can optionally specify LIFs to be created for each node in the local cluster. These local interfaces, if specified, are created on each node before proceeding with the creation of the cluster peering relationship. Cluster peering relationship would be established if there is an error preventing the LIFs from being created. Local interfaces, once created, should not be specified for subsequent cluster peering relationships.

Local LIF creation fields

  • local_network.ip_addresses - list of IP addresses to assign, one per node in the local cluster

  • local_network.netmask - IPv4 mask or netmask length

  • local_network.broadcast_domain - Broadcast domain that is in use within the IPspace.

  • local_network.gateway - The IPv4 or IPv6 address of the default router.

Additional information on network routes

It might happen that when creating LIFs the network route discovery mechanism could take additional time (1-5 seconds) to become visible in the network outside of the cluster. This delay in publishing the routes might cause an initial cluster peer "create" request to fail. This error disappears with a retry of the same request.

Example
curl -X POST "https://<mgmt-ip>/api/cluster/peers" -d body

where "" is replaced by the IP address of the cluster management LIF, and "body" is replaced by the JSON body of the POST, containing the fields for the new peering relationship and local LIFs.

Example POST body

To create 4 intercluster LIFs on a 4-node cluster before creating a cluster peer relationship:

{
  "local_network":
  {
      "interfaces": [
          {"ip_address":"1.2.3.4"},
          {"ip_address":"1.2.3.5"},
          {"ip_address":"1.2.3.6"}
          ],
      "netmask": "255.255.0.0",
      "broadcast_domain": "Default",
      "gateway": "1.2.0.1"
  }
  "remote.ip_addresses": ["1.2.9.9"],
  "authentication.passphrase": "xyz12345"
}

Retrieve a cluster peer

Peers in a cluster can be retrieved by issuing a GET request to /cluster/peers. It is also possible to retrieve a specific peer when qualified by its UUID to /cluster/peers/{uuid}.

Overview of fields used for retrieving a cluster peer

A GET request might have no query parameters or a valid cluster UUID. The former retrieves all records while the latter retrieves the record for the cluster peer with that UUID.

Required fields

There are no required fields for GET requests.

Optional fields

The following fields are optional for GET requests

  • UUID - uuid of the cluster peer

Examples
curl -X GET "https://<mgmt-ip>/api/cluster/peers/"
curl -X GET "https://<mgmt-ip>/api/cluster/peers/{uuid}"
curl -X GET "https://<mgmt-ip>/api/cluster/peers/{uuid}?fields=*"

Update a cluster peer

A cluster peer relationship can be updated by issuing a PATCH request to /cluster/peers/{uuid}. As in the CLI mode, you can toggle the proposed encryption protocol, update the passphrase, or specify a new set of stable addresses. All PATCH requests take the parameters that are to be updated in the request body. If the generate_passphrase is 'true', the passphrase is returned in the PATCH response.

Fields overview

This sections highlights the parameters that control the modification of an existing cluster peering relationship.

Required fields

A PATCH request with an empty body has no effect on the cluster peer instance. All other fields and the combinations in which they are valid are indicated below:

  • encryption_proposed - Toggle the proposed encryption protocol (from 'none' to 'tls-psk' or otherwise). Authentication must be true and a passphrase must be present in body.

  • passphrase

  • passphrase or generate passphrase

  • remote.ip_addresses

Optional fields

  • expiration time - Set the expiration time of the passphrase

Examples
# Update with an empty body
body = {}

# Update the proposed encryption protocol from tls-psk to none
body =
{
  "authentication":
    {
        "passphrase":"xyz12345",
        "in_use":"ok"
    },
  "encryption":
    {
        "proposed":"none"
    }
}

# Update the passphrase
body =
{
  "authentication":
   {
       "passphrase":"xyz12345",
       "in_use":"ok"
   }
}

# Set an auto-generated passphrase
body =
{
  "authentication":
   {
       "generate_passphrase": true,
       "in_use":"ok"
   }
}

# Update remote IP addresses
body =
{
  "remote":
    {
        "ip_addresses":["10.224.65.30"]
    }
}
Sample requests
# Set a passphrase
curl -X PATCH 'https://<mgmt-ip>/api/cluster/peers/73123071-d0b9-11e8-a686-005056a7179a' -d '{"authentication":{"passphrase":"xyz12345","in_use":"ok"}}'

# Update a peer address
curl -X PATCH 'https://<mgmt-ip>/api/cluster/peers/73123071-d0b9-11e8-a686-005056a7179a' -d '{"remote":{"ip_addresses":["1.2.3.4"]}}'

Delete a cluster peer

This interface allows you to delete a cluster peer using the HTTP DELETE request.

Required fields

All delete operations must be performed on a valid peer UUID. Deleting an invalid peer returns 'HTTP 404' indicating an error.

Optional fields

The DELETE operation has no optional fields.

Request format

DELETE "https:///api/cluster/peers/{uuid}"

Examples

The request -

curl -X DELETE "https://<mgmt-ip>/api/cluster/peers/8becc0d4-c12c-11e8-9ceb-005056bbd143"

deletes a peer with peer UUID '8becc0d4-c12c-11e8-9ceb-005056bbd143'