Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

If the Service Proxy is running on the Platform Server when you add adding or remove removing chassis, be sure to restart the service so that it can pick up the new chassis list:

...

Reconfiguring the Cluster

You can modify your the 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 the file are preserved. That is, if you define only two settings, Platform overwrites or adds only those two settings.

  1. Create a supplemental .cfg file (such as changes.cfg) and specify any new or changed Swarm settings to apply.

  2. To upload your the configuration changes, use the following CLI command:

    Code Block
    languagebash
    platform upload config -c {Path to .cfg}

...

To set all chassis throughout the cluster to a higher number of processes, you would create a configuration file and upload it to Platform Server. 

  1. Create a text file, such as update.cfg, containing only the setting to be changed.

    Code Block
    languagebash
    chassis.processes = 6
  2. To upload your the configuration changes, use the following CLI command:

    Code Block
    languagebash
    platform upload config -c {Path to update.cfg}
    Info
    titleNote

    Include the -m <mac-address> parameter if you want to target the update to specific chassis.

...

  1. Create a .cfg file (such as changes.cfg) and specify any new or changed node-specific settings to apply.

  2. To upload your the configuration changes, use the following CLI command:

    Code Block
    languagebash
    platform upload config -c {Path to .cfg} -m {mac address}

...

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

Info

Important

To ensure guarantee a clean shut down, power off the chassis through the UI or SNMP before you run release commands.

...

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

...

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

...

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.

...

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

...

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

...

Code Block
languagebash
cat password.txt | platform add adminuser --askpassword --username admin --update
Info

Important

If you are just updating the password for an existing user , be sure to use the --update flag. 

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

Delete admin user
Code Block
languagebash
platform delete adminuser --username <username>

Upgrading Swarm Storage

To upgrade Swarm Storage in a live cluster, you can use Use the CLI to upload the version and then take steps to deploy it to your running nodes to upgrade Swarm Storage in a live cluster, 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 verifying the <version-name> matches the version of Swarm Storage being uploaded:

    Code Block
    languagebash
    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 of the nodes and their IPs, MAC addresses, and system IDs:

    Code Block
    languagebash
    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 Run that command as well if restarting the node immediately after upgrade, run that command as well :

    Code Block
    languagebash
    platform deploy storage --upgrade -v 9.2.1 -y <system-id>
    platform restart storagenode -y <system-id>
  4. If you did not restart Restart the cluster now if each node individually, restart the cluster nowis not restarted individually, either full or rolling:

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

...

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
    languagebash
    // slave other local zones
    include "/etc/bind/named.conf.slaves";
  2. Create a new file called /etc/bind/named.conf.slaves and add your the settings in this format:

    Code Block
    languagebash
    // 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
    languagebash
    sudo systemctl restart bind9

...

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 Add networking properties as properties to the root JSON object in the file:

...