Page Comparison

Platform's CLI (command-line interface) is installed by default on the Platform server and supports common administrative tasks.

Rebooting a Cluster

There are two CLI options for rebooting a cluster: full versus rolling.

• Full reboot notifies every chassis in the cluster to reboot itself at the same time, meaning that the entire cluster will temporarily be offline as the chassis reboot.

  Full reboot

  Code Block
  language bash title Full reboot
  platform restart storagecluster --full

• Rolling reboot is a long-running process that keeps the cluster operational by rebooting the cluster one chassis at a time, until the entire cluster has been rebooted. A rolling reboot includes several options, such as to limit the reboot to one or more chassis:

  Rolling reboot

  Code Block
  language bash title Rolling reboot
  platform restart storagecluster --rolling [--chassis <comma-separated system IDs>] [--skipConnectionTest] [--skipUptimeTest] [--continueWithOfflineChassis] [--stopOnNodeError]

  Info
  title Requirements
  Before a rolling reboot can begin, these conditions must be met: All chassis targeted for rebooting must be running and reachable. If you have offline chassis, be sure to set a flag to have them ignored: To skip the connection check altogether, add the flag --skipConnectionTest To have the reboot process ignore currently offline chassis, add the flag --continueWithOfflineChassis All chassis must have an uptime greater than 30 minutes. To skip this requirement, add the flag --skipUptimeTest

...

You have 10 seconds to cancel a rolling reboot before it begins. Once a rolling reboot has started, it will stop and report an error if any of these occur:

1. A chassis is offline when it is selected for reboot. To have the reboot process ignore currently offline chassis, add the flag --continueWithOfflineChassis.

2. The reboot process will continue if the volumes come up but a node goes into an error state. To have the reboot process stop, add the flag --stopOnNodeError.

3. If the chassis boots with a number of volumes that doesn't match the number present before the chassis was rebooted. A volume is considered up if it has a state of: ok, retiring, retired, or unavailable

4. The chassis does not come back online after 3 hours has passed.

If a rolling reboot has stopped due to an error, you can resume the reboot using the resume command below after you have resolved the error.

Status check —  To retrieve the status of a rolling reboot task, use the following commands for reboots remaining and reboots completed:

Rolling reboots remaining

platform status rollingreboot

Rolling reboots completed

platform status rollingreboot --completed

Global states — When viewing the status for a rolling reboot, a rolling reboot task can have the following global states:

• in-progress: The rolling reboot is currently running.

• paused: The rolling reboot has been paused (using the pause command).

• completed: The rolling reboot finished successfully.

• cancelled: The rolling reboot was caused per a user request.

• error: The reboot has been stopped due to an error of some kind.

Chassis states — The status listing will also show the status for each chassis that is processed by the rolling reboot task. Each chassis can have one of the following states:

• pending: The rolling reboot task has yet to process the chassis.

• in-progress: The rolling reboot task is in the process of rebooting the chassis.

• completed: The chassis was successfully rebooted.

• removed: The chassis was removed from the list of chassis to process after the rolling reboot was started (using the delete rolling reboot command).

• error: The chassis encountered an error of some kind.

• abandoned: The chassis was currently being processed when a user cancelled the rolling reboot.

• dropped: The rolling reboot was in the process of waiting for the chassis to reboot when a user request was made to move to the next chassis (using the --skip flag).

• offline: The chassis was already offline when the reboot task attempted to reboot the chassis.

Cancel reboot — To cancel (not pause) an active rolling reboot, issue the delete command, which the reboot process at the earliest moment and thus cannot be restarted later.

...

Example: Increase Swarm processes

...

There may be times when you need to release a chassis from the Swarm cluster, either for temporary maintenance or for permanent removal.

Temporary release — Temporary release of a chassis assumes that the chassis will be added back into the cluster at a later time. Releasing a chassis lets you unallocate deallocate its cluster resources, such as IP Addresses, or wipe and reset its configuration.

Once the chassis is powered off, you can release the chassis from the Swarm cluster:

Temporary removal

platform release storagechassis -y <system-id>

...

Once the chassis is powered off, you can remove the chassis from Platform Server management permanently:

Permanent removal

platform release storagechassis -y <system-id> --remove

...

If you would like to clear out all existing setting customizations from a given chassis or the entire cluster, you can issue the following commands.

Delete All Default Chassis Settings

platform delete allchassisconfig

Delete All Cluster Settings

platform delete allclusterconfig

...

To see the current subcluster assignments, use the list command:

List subclusters

platform subcluster list

To assign a chassis to a subcluster, use the assign command:

Add to subcluster

platform subcluster assign -y <system-id> --subcluster <subcluster-name>

To remove a chassis from a subcluster, use the unassign command:

Remove from subcluster

platform subcluster unassign -y <system-id>

Changing the Default Gateway

...

platform add config --name "network.gateway" --value "<ip-of-gateway>"

Managing Administrators

With one exception, modifying the admin users for the Storage cluster requires the Storage cluster to be up and running before the operations can be done. The one exception to this is the "snmp" user which which can have its password set while the cluster is down or before the cluster has been booted for the first time.

...

Adding or Updating Users

...

To add a new admin user, use the following CLI command

Add admin user

...

platform add adminuser 	
	[--askpassword]
	[--username <username>]
	[--password <user password>]
	[--update]

The --askpassword flag lets you avoid specifying a password via the command line by providing the password via stdin. When this flag is used, you'll be prompted to enter a new/updated password for the user. You can also use the Linux pipe functionality:

cat password.txt | platform add adminuser --askpassword --username admin --update

...

To delete an admin user from the cluster, use the following CLI command:

Delete admin user

...

platform delete adminuser --username <username>

Upgrading Swarm Storage

To upgrade Swarm Storage in a live cluster, you can use the CLI to upload the version and then take steps to deploy it to your running nodes, either by restarting the entire cluster or each chassis in turn.

1. Upload the new version of the Swarm Storage software to Platform server, making sure that the <version-name> matches the version of Swarm Storage being uploaded:

   Code Block
   language bash
   platform upload storageimages -i <path-to-zip> -v <version-name> platform upload storageimages -i ./storage-9.6.0-x86_64.zip -v 9.6

   Info
   title Note
   The zip file to use above is contained with the Swarm-{version}-{date}.zip file that was downloaded. Inside this zip, there is a folder called Storage which contains a file called storage-{version}-x86_64.zip. This is the zip file to use for the command above.

2. Get a full listing of all of the nodes and their IPs, MAC addresses, and system IDs:

   Code Block
   language bash
   platform list nodes --state Deployed

3. Using the list of system IDs, deploy the upgrade on each of the nodes. If you want to restart the node immediately after upgrade, run that command as well:

   Code Block
   language bash
   platform deploy storage --upgrade -v 9.2.1 -y <system-id> platform restart storagenode -y <system-id>

4. If you did not restart each node individually, restart the cluster now, either full or rolling:

   Code Block
   language bash
   platform restart storagecluster --full or platform restart storagecluster --rolling [<options>]

...

platform deploy proxy -b <path-to-zip> --upgrade

...