...
Required network services. Provides network services that are configured to support a Swarm cluster: DHCP, PXE/Network Boot, TFTP, Syslog, and NTP.
Service Proxy and Swarm UI. Provides a cluster management dashboard, dynamic configuration of Swarm settings, health report graphics and logs, and Swarm software version management.
Swarm configuration management. Provides the ability to configure and update the cluster and individual chassis as needed.
Command-line interface. The CLI gives you provides a direct interface to Platform management tasks.
...
CLI (Command-Line Interface) — see Platform CLI Commands
The CLI is a native application installed on the Platform server. Versions for other platforms are available, so it can run anywhere.
To Type:
platformto get CLI help, just type:platformAll CLI commands start with “platform”:
To list all nodes:
platform list nodesTo deploy a node:
platform deploy storage
Swarm UI — see Platform UI
REST API, underlying both the CLI and the Swarm UI
API is discoverable through the root:
http://<platform>:8095/platform
...
Each chassis goes through the following lifecycle on the way to becoming a functioning Swarm Storage node. Once a chassis is running as a Storage node, it will is always boot as a Storage node and will have has a statically assigned IP address that is consistent across reboots.
...
1. | Add Hardware Enlist | Before new hardware can be managed by the Platform server, you need to power it on manually for the first and only time. This initial step enlists the machine with the Platform server, after which the hardware will automatically power powers itself off. After enlistment, new hardware appears in the CLI with the state “New”, and it can remain in that state indefinitely until needed. Note: Enlistment is non-destructive to existing data. If the machine was added by mistake to the subnet that Platform server manages and is enlisted, you can correct it. No installation happens until you use the CLI to deploy Swarm to the chassis.  |
|---|---|---|
2. | Deploy Hardware Commission | Once new hardware is enlisted, Platform sees it as available for commissioning, which occurs when you run a CLI command that deploys the hardware and boots Swarm. The deployment command automatically pushes the new hardware through all of the required operations. After the deploy operation starts, you can use the “list nodes” CLI command to view the chassis moving through the different states. Note: The first power on and commissioning steps are also non-destructive to any existing data on the disks. Any data on the disks will persist persists until Swarm is booted on the second power on operation, after which the persistence of any existing data is determined by Swarm.  |
...
New — It has been powered on for the first time and has enlisted with the Platform Server.
Commissioning — It is in the process of or just recently finished the initial hardware interrogation stage on the way to deployment.
Ready — It has completed all the initial stages and is ready to be deployed with software.
Deploying/Deployed — It is in the process of or finished with the deployment of the Storage software.
Failed <X> — It encountered an error in completing one of the stages.
...
If you make no explicit subcluster assignments in the Swarm configuration and there are more than one storage process running on a chassis, then each chassis forms a de facto subcluster. In Swarm, the "node.subcluster" value is an free-form name that you assign assigned to one or more chassis.
The storage process looks at all the names assigned to the different chassis and forms them into groups, which can then be used to determine how replicas are handled. You can group the chassis in any way you need to achieve your desired replica/fail-over paradigm.