Page Comparison

...

• Full reboot notifies every chassis in the cluster to reboot itself at the same time. The entire cluster is temporarily offline as the chassis reboot.

  Full reboot

  Code Block
  language bash
  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 is rebooted. A rolling reboot includes several options, such as to limit the reboot to one or more chassis:

  Rolling reboot

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

...

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

• paused: The rolling reboot has been is 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 is stopped due to an error of some kind.

...

1. Create a node.cfg file and add any node-specific Swarm settings to apply, or leave it blank to accept all current settings.

2. Power on the chassis for the first time.

3. Wait until the chassis enlists and powers off.

4. Deploy the new server:

   Code Block
   language bash
   platform deploy storage -n 1 -v <#.#.#-version-to-deploy>

To Use the following process to deploy an individual chassis by system ID, use this process:

1. Create a node.cfg file and add any node-specific Swarm settings to apply , or leave it blank to accept all current settings.

2. Get a list of chassis that are available for deployment by using the following command:

   Code Block
   language bash
   platform list nodes --state New

3. Choose a System ID to deploy a single chassis using a command like the following:

   Code Block
   language bash
   platform deploy storage -y 4y3h7p -v 9.2.1

Service Proxy

If Restart the service so it picks up the new chassis list if the Service Proxy is running on the Platform Server when adding or removing chassis, restart the service so it can pick up the new chassis list:

platform restart proxy

...

The CLI parses the uploaded configuration file for changes to make to Platform.

If Swarm was running during the upload, Platform Server attempts to communicate the new configuration to Swarm if Swarm was running during the upload. Any settings that cannot be communicated to Swarm requires a reboot of the Swarm cluster in order to to take effect. For each setting contained in the file, the The CLI indicates if the setting was communicated to the Storage cluster and if a reboot is required for each setting contained in the file. The Swarm UI also indicates which settings require rebooting.

...

Permanent removal — Permanent removal is for retiring a chassis altogether or changing the chassis' main identifying information, such as changing a NIC. Removing the chassis from management causes the chassis to start the provisioning life cycle as if it were is a brand new chassis, if it is powered on again.

Once the chassis is powered off, remove Remove the chassis from Platform Server management permanently once the chassis is powered off:

Permanent removal

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

...

platform delete allclusterconfig

Managing Subclusters

After Assign chassis to subclusters after all the chassis have been are deployed and are running, assign chassis to subclusters.

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

List subclusters

platform subcluster list

...

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

Remove from subcluster

platform subcluster unassign -y <system-id>

...

Changing the Default Gateway

By default, the The Platform Server configures Swarm Storage to use the Platform Server as the default gateway by default.

To override this behavior, either Either add a "network.gateway" to the cluster configuration file or issue the following command to override this behavior:

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

...

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 the password set while the cluster is down or before the cluster has been is booted for the first time.

...

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

Add admin user

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

...

1. Upload the new version of the Swarm Storage software to Platform server, verifying 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

   
   Note: The zip file above is contained within the Swarm-{version}-{date}.zip file. Inside this zip, a folder called Storage contains a file called storage-{version}-x86_64.zip.

2. Get a full listing of all nodes along with 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. Run that command as well if restarting the node immediately after upgrade, :

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

4. Restart the cluster now if each node is not restarted individually, either full or rolling:

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

Managing Service Proxy

Status — To Use this command to check the status of the Service Proxy, use this command:

platform status proxy

Upgrade — To upgrade the Service Proxy on the Platform server, use the Use the CLI to upload the version and deploy it to upgrade the Service Proxy on the Platform server:

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

...

A Slave/Backup DNS zone is a read-only copy of the DNS records; it receives updates from the Master zone of the DNS server.

If no DNS master/slave relationships are configured, perform Perform forwarding by having the domain managed by the Platform server forward all lookups to outside domains if no DNS master/slave relationships are configured:

1. Edit /etc/bind/named.conf.options and add the following line after the "listen-on-v6" line

   Code Block
   forwarders {172.30.0.202;};

2. Run the following command to restart bind9 on the Platform Server:

   Code Block
   language bash
   sudo systemctl restart bind9

Option 2: Configuring a Slave DNS Zone

If an external DNS Zone is configured, have Have the Platform Server become a slave DNS of that zone if an external DNS Zone is configured; the reverse can be done to allow other systems to resolve names for servers managed by the Platform server.

This process assumes that the external DNS server has been is configured to allow zone transfers to the Platform server. The DNS server on the Platform server is not configured to restrict zone transfers to other DNS slaves.

...

Configuring Docker Bridge

To Edit the file /etc/docker/daemon.json to configure or modify the network information that is used by the default Docker (docker0) bridge, edit the file /etc/docker/daemon.json. Add networking properties as properties to the root JSON object in the file:

...

The bip property sets the IP address and subnet mask to use for the default docker0 bridge. For See the Docker documentation for details on the different properties, see the Docker documentation.