...

The Platform infrastructure provides these essential features:

• 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.

Platform Concepts

Services Node for Swarm

The Platform server is an extensible services node for managing Swarm. On a single server, it configures the environment and coordinates the support services needed to deploy hardware into and support a Swarm cluster. It is the next generation of the original Caringo Services Node (CSN).

...

1. DHCP server, to allocate Swarm node addresses

2. DNS server, for the management subnet

3. TFTP server, for Swarm network boot

4. NTP time server, essential for Swarm clock synchronization (defaults to pool.ntp.org) 

5. Syslog server, for centralized logging

   • Platform and Storage: /var/log/caringo

   • Service Proxy: /var/log/gateway

6. Service Proxy, a lightweight Gateway instance to host the Swarm UI

7. HTTP proxy, to allow for HTTP access outside the private network

8. Configuration and License server, for Swarm node access

Network Architecture

Swarm architecture uses a private network that is dedicated to the Swarm Storage nodes and application servers. Access to this cluster is restricted to the Platform server and any applications that reside on private subnet (in the absence of existing routers). Platform server owns this private storage network, but it can support flexible network topologies.

• Platform server addresses are IPs on a routable subnet.

• Application servers can be dual-homed like the Platform server, for ease of access to cluster.

• Swarm Storage nodes’ default gateway is the Platform server, which can be changed to support existing routers.

...

Swarm Interfaces

There are three interfaces to Platform functionality:

• 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: platform to get CLI help, just type: platform

  • All CLI commands start with “platform”:

    • To list all nodes:        platform list nodes

    • To 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. Image Modified
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.  Image Modified

Chassis Statuses

As a chassis moves through the phases of deployment, it may show the following statuses:

• 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.

Chassis Grouping

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.