The Cluster command is used to set up clustering and manage clustered resources.
|
Gets the current cluster configuration state and resource properties.
Example Request:
GET /api/hardware/v1/cluster HTTP/1.1 Authorization: Basic abcd45sMWE= Host: zfs-storage.example.com:215 Accept: application/json
Example Response:
HTTP/1.1 200 OK X-Zfssa-Appliance-Api: 1.0 Content-Type: application/json Content-Length: 529 X-Zfssa-Api: 1.0 { "cluster": { "description": "Clustering is not configured", "peer_asn": "", "peer_description": "", "peer_hostname": "", "peer_state": "", "resources": { "net/ixgbe0": { "details": ["ipaddr-1"], "href": "/hardware/v1/cluster/resources/resources/net/ixgbe0", "owner": "admin1", "type": "singleton", "user_label": "Untitled Interface" }, "zfs/zfs-storage-1": { "details": ["821G"], "href": "/hardware/v1/cluster/resources/resources/zfs/zfs-storage-1", "owner": "admin1", "type": "singleton", "user_label": "" } }, "state": "AKCS_UNCONFIGURED" } }
By following the href property from cluster resources, it is possible to get the data for that single cluster resource. In the previous example, two resources are available: /hardware/v1/cluster/resources/resources/zfs/zfs-storage-1 and /hardware/v1/cluster/resources/resources/net/ixgbe0.
When a system is clustered, it is possible to modify the properties for each cluster resource with this command. For more information, see CLI "configuration cluster resources."
The commands supported by cluster are failback, takeover, and unconfigure. All commands take a PUT request to the cluster resource with the name of the command appended. On success, the commands return HTTP status 202 (Accepted).
The failback operation is asynchronous. When the REST client sends a failback request using the PUT command, HTTP status 202 (Accepted) is returned after successfully receiving the request. The client will need to monitor failback progress by listening for alerts or polling the cluster state.
Example Request:
PUT /api/hardware/v1/cluster/failback HTTP/1.1 Authorization: Basic abcd123MWE= Host: zfs-storage.example.com:215
Example Result:
HTTP/1.1 202 Accepted X-Zfssa-Appliance-Api: 1.0
If the cluster is not in the correct state to accept the command, an HTTP status 409 (Conflict) is returned.
This command returns the current link status of the cluster card. The output is the same as the aksh command "configuration cluster links." It is recommended to run this command before running cluster setup to ensure that there is no issue with the cluster cabling. All links should be in the AKCIOS_ACTIVE state before running setup.
Example Request:
GET /api/hardware/v1/cluster/links HTTP/1.1 Authorization: Basic abcd123MWE= Host: zfs-storage.example.com:215 Accept: application/json
Example Response:
HTTP/1.1 200 OK X-Zfssa-Appliance-Api: 1.0 Content-Type: application/json Content-Length: 181 { "links": { "clustron2_embedded:0/clustron_uart:0 = AKCIOS_TIMEDOUT\n clustron2_embedded:0/clustron_uart:1 = AKCIOS_TIMEDOU\n clustron2_embedded:0/dlpi:0 = AKCIOS_TIMEDOUT" } }
The setup cluster command sets up initial clustering for the system. All cluster links should be in the AKCIOS_ACTIVE state and the peer system should powered on but not configured or this command fails.
Example Request:
PUT /api/hardware/v1/cluster/setup HTTP/1.1 Authorization: Basic abcd123MWE= Host: zfs-storage.example.com:215 Accept: application/json {"nodename": "zfs-storage-2", "password": "password"}
Example Result:
HTTP/1.1 202 Accepted X-Zfssa-Appliance-Api: 1.0