Page Comparison

...

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.

  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:

  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

  
  

Managing Rolling Reboots

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:

...

platform resume rollingreboot --skip

Adding a Chassis

Which version of Swarm a given node uses is set at the time of provisioning.

...

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 the Service Proxy is running on the Platform Server when you add or remove chassis, be sure to restart the service so that it can pick up the new chassis list:

platform restart proxy

Reconfiguring the Cluster

You can modify your cluster-wide Swarm configuration at anytime using the CLI and a configuration file. The reconfiguration process is additive: all existing settings that are not referenced in your file are preserved. That is, if you define only two settings, Platform overwrites or adds only those two settings.

...

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

Example: Increase Swarm processes

...

1. Add the configuration change directly:

   Code Block
   language text
   platform add config --name "chassis.processes" --value 6

   
   

Reconfiguring a Chassis

You can modify the node-specific settings for a single chassis by the same process, but you need to specify the MAC address of any valid NIC on that chassis.

...

The CLI will parse the uploaded configuration file for changes to make to that chassis.

Releasing a Chassis

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

...

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

Resetting to Defaults

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.

...

platform delete allclusterconfig

Managing Subclusters

After all the chassis have been deployed and are running, you can assign chassis to subclusters.

...

Changing the Default Gateway

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

...

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

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

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

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>]

   
   

Managing Service Proxy

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

...

Configuring DNS

You may need to have the Storage nodes resolve names for outside resources, such as Elasticsearch or Syslog. To do so, configure the DNS server on the Platform Server to communicate with outside domains. 

Option 1: Simple forwarding

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

...

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 you have an external DNS Zone configured, you can have the Platform Server become a slave DNS of that zone; the reverse can be done to allow other systems to resolve names for servers managed by the Platform server.

...

1. Edit /etc/bind/named.conf.local and add the following line at this location:

   Code Block
   language bash
   // slave other local zones include "/etc/bind/named.conf.slaves";

   
   

2. Create a new file called /etc/bind/named.conf.slaves and add your settings in this format:

   Code Block
   language bash
   // local slave zones zone "example.com" in { type slave; masters {172.30.0.100; }; file "/var/cache/bind/slave/zone-example.com"; };

   
   

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

   Code Block
   language bash
   sudo systemctl restart bind9

   
   

Configuring Docker Bridge

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

...