...

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

Getting Help

Every command within the CLI offers help. Some examples:

...

scsctl help

...

scsctl init dhcp help

...

Getting Help

Every command within the CLI offers help. Some examples:

• scsctl help

• scsctl init dhcp help

• scsctl repo component add help

Listing Components

...

List the instances within a given the default group of a component (most common usage):

scsctl {component} instance list -d

List the instances within a specific group of a component:

scsctl {component} instance list --group "{group name}"

List the nodes in the Swarm Storage cluster (-d is used to refer to the default group rather than referring to it by name):

...

Assuming an Old Instance Identity

Any time Whenever the identity of an instance identity changes (typically when a storage node has a change to its networking cards), it will appear to SCS SCS will recognize it as an entirely new instance, even if nothing really substantial has changed. Also, the the change is not substantial. The former identity still exists in SCS, but will never be used ( including any instance-specific setting or template overrides). There However, there is a way method to tell instruct SCS to associate the former identity with the new instance ID, clearing which will also clear out the old identity in the process.

scsctl {component} instance rename "{new instance ID}" "{former instance ID}" --force

...

If SCS ever needs to “forget” about an instance, use the following command to fully remove it from SCS. The example below uses the default group, but you can use the -g {group name} form of the command as needed.

scsctl {component} instance remove -d {instance ID}

Defining the Storage Cluster

...

Each node forms a de-facto subcluster if no explicit subcluster assignments are made in the Swarm Storage configuration. The Swarm Storage component (storage) provides the node.subcluster setting as a free-form name that may can be assigned to one or more nodes.

The storage process looks at all names assigned to the different nodes and forms them into groups, which can then be used to determine how groups nodes based on their assigned names, which are then used to manage object replica distribution and protection are handled. The nodes may be . Nodes that are grouped using subclusters can be configured in any way needed necessary to achieve the desired replica/fail-over paradigmstrategy.

Update the subcluster for a storage node:

scsctl storage config set -d --instance "{instance name/ID}" "node.subcluster={subcluster name}"

...

scsctl storage config set -d --instance "{instance name/ID}" "{setting name}={setting value}"

...

scsctl storage config set -d --instance "{instance name/ID}" "ec.protectionLevel=node"
scsctl storage config set -d --instance "{instance name/ID}" "feeds.maxMem=500000"

...

Removing a setting override means that the value for the setting is inherited from a higher scope. Removing an instance-level override means that the value for the setting is obtained from either the group (if a group-level override has been setexists) or the component level. Removing a group-level override has no influence on does not affect any existing instance-level overrides that may exist within that group.

Instance Level

Reset an instance-level override. Either the default-group or specific-group form of the command may be used:

scsctl {component} config unset -d -group-instance "{instance ID}" "{setting name}"

or

scsctl {component} config unset --group "{group name}" --instance "{instance name/ID}" "{setting name}"

Group Level

Reset a group-level override. Either the default-group or specific-group form of the command may be used:

scsctl {component} config unset --groupd "{groupsetting name}" "

or

scsctl {component} config unset --group "{group name}" "{setting name}"

Updating Network Settings

Shared network settings, such as DNS information and NTP time sources, may can be updated as the need arisesper requirement.

DNS Servers

Update the list of DNS servers (specified as comma- or space-delimited list):.

scsctl network_boot config set -d "network.dnsServers={new DNS servers}"

This also requires that the DHCP server be updated so the setting can be made available to booting Storage nodes.The example output is:

scsctl init network_boot config show -d network.dnsServers 
['10.166.2.18']

This also requires updating the DHCP server so the setting can be made available to booting Storage nodes. See Configure DHCP.

scsctl init dhcp {reserved ranges}

NTP Servers

Update the list of NTP servers (specified as comma- or space-delimited list):

scsctl platform config set -d "network.ntpServers={new NTP servers}"

This also requires that the DHCP server be updated so the setting can be made available to booting Storage nodes.It is recommended to check the bash history on the SCS to view the prior command and its settings. Run the below command on the SCS to view the last DHCP setting command used.

history | grep "scsctl init dhcp" | tail -1

DNS Domain

Update the DNS domain (specified as comma- or space-delimited list):

scsctl platform config set -d "network.dnsDomain={new DNS domain}"

The example output is:

scsctl platform config show -d network.dnsDomain
certlab.local

This also requires updating the DHCP server so the setting can be made available to booting Storage nodes. See Configure DHCP.

scsctl init dhcp {reserved ranges}

It is recommended to check the bash history on the SCS to view the prior command and its settings. Run the below command on the SCS to view the last DHCP setting command used.

history | grep "scsctl init dhcp" | tail -1

NTP Servers

Update the list of NTP servers (specified as comma- or space-delimited list):

scsctl platform config set -d "network.ntpServers={new NTP servers}"

This also requires updating the DHCP server so the setting can be made available to booting Storage nodes. See Configure DHCP.

scsctl init dhcp {reserved ranges}

It is recommended to check the bash history on the SCS to view the prior command and its settings. Run the below command on the SCS to view the last DHCP setting command used.

history | grep "scsctl init dhcp" | tail -1

Swarm (Internal) Network MTU

Network MTU for the entire Swarm storage cluster is governed by the MTU set on the internal network interface of SCS. This value is put into DHCP configuration during the init dhcp process, and served to all storage nodes on boot.

1. Update the MTU on the internal network interface.

2. List the interface details on the SCS to ensure that the change is correct.

3. Re-initialize DHCP to apply to changes to any future booting storage nodes:

   Code Block
   scsctl init dhcp {reserved ranges}

Swarm (Internal) Network

...

Gateway

The network gateway for the entire Swarm storage cluster is governed by the MTU set on the internal network interface of SCS. This value is put into DHCP configuration during the init dhcp process, and served to all storage nodes on boot.

1. Update the MTU on the internal network interface.

2. List the interface details on the SCS to ensure that the change is correct.

3. Re-initialize DHCP to apply to changes to any future booting storage nodes:

   Code Block
   scsctl init dhcp {reserved ranges}

Swarm (Internal) Network Gateway

The network gateway for the entire Swarm storage cluster is governed by a setting available in SCS as of version 1.5. The setting is provided by the network_boot component, and is called network.gateway. By default, this setting points to the IP address of the internal network interface of SCS, but may be overridden by normal means using the CLI. This value is put into DHCP configuration during the init dhcp process, and served to all storage nodes on boot.

...

Update the network.gateway setting.

scsctl network_boot config set -d "network.gateway={gateway_ip_address}"

Re-initialize DHCP to apply to changes to any future booting storage nodes:

...

a setting available in SCS as of version 1.5. The setting is provided by the network_boot component, and is called network.gateway. By default, this setting points to the IP address of the internal network interface of SCS, but may be overridden by normal means using the CLI. This value is put into DHCP configuration during the init dhcp process and served to all storage nodes on boot.

1. Update the network.gateway setting.

   Code Block
   scsctl network_boot config set -d "network.gateway={gateway IP address}"

2. Re-initialize DHCP to apply changes to any future booting storage nodes. See Configure DHCP.

   Code Block
   scsctl init dhcp {reserved ranges}

   It is recommended to check the bash history on the SCS to view the prior command and its settings. Run the below command on the SCS to view the last DHCP setting command used.

   Code Block
   history | grep "scsctl init dhcp" | tail -1

Updating Network Bonding in Swarm Storage

...

Update the administrative password:

...

password

...

Updating CLI Credentials

The CLI requires knowing the administrative credentials to perform operations against the SCS server. To set these credentials:

scsctl platform authconfig loginset --userd "admin.password={administrativenew user namepassword}"

The CLI then securely prompts for the administrative password and proceeds with authentication.

Upgrading Swarm Storage

Obtain the component bundle for the desired version from DataCore Downloads to upgrade the Swarm Storage software of a running cluster. Transfer the bundle to the SCS server and run the following commands to register it with SCS.

Replace new-version with the version being installed:

unzip Swarm-new-version.zip

Navigate to the Storage directory and tun the following:

cd Swarm-new-version/Storage/
scsctl repo component add -f swarm-scs-storage-new-version.tgz

...

Updating CLI Credentials

The CLI requires knowing the administrative credentials to perform operations against the SCS server. To set these credentials:

scsctl auth login --user "{administrative user name}"

The CLI then securely prompts for the administrative password and proceeds with authentication.

Upgrading Swarm Storage

Obtain the component bundle for the latest version from DataCore Downloads to upgrade the Swarm Storage software of a running cluster. Transfer the bundle to the SCS server and run the following commands to register it with SCS:

1. Use the command below to get the list of Storage software versions that have been registered with SCS.

   Code Block
   scsctl storage software list

...

It has been successfully registered if the new version is in the list. It is not used for booting nodes and the current active version is used. Mark it as active to complete the upgrade:

scsctl storage software activate "new-version (new-version)"
activated

...

If the desired version already present in the list, continue with step 5 when ready to boot Swarm Storage nodes to the desired version.

2. Unpack the downloaded Swarm Storage software bundle

3. Navigate to the Storage directory within that bundle and run the following command to register the Swarm storage software with SCS (please insert the correct version string where needed).

   Code Block
   cd Swarm-{desired version}/Storage/ scsctl repo component add -f swarm-scs-storage-{desired version}.tgz

4. Verify the desired version is present in the list of available versions.

   Code Block
   scsctl storage software list

...

5. Activate this desired version to complete the upgrade.

   Code Block
   scsctl storage software activate

   Choose the desired version in the menu. The activated version will be used the next time that storage nodes reboot.

Removing an Installed Version of Swarm Storage

...

scsctl storage software list
14.0.1 (14.0.1) (active)
14.1.2 (14.1.2)

...

Remove the desired version, using the entire version string:

...