The SCS server is responsible in part for coordinating and maintaining configuration across the various elements of a Swarm site ecosystem. It is not oriented to any part of the ecosystem and has a separate conceptual approach to managing the various elements.

Services Node for Swarm

The SCS server is an extensible service 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 replaces the original Caringo Services Node (CSN).

An SCS server automatically installs and configures the network infrastructure required for the Swarm environment when brought online.

Swarm Orchestration

SCS orchestration spans initial Swarm setup and deployment as well as all ongoing maintenance.

• Installation and configuration of Swarm Storage software

• Network boot support

• Automatic provisioning of network and node configurations

Swarm Environment and Networking

The initial configuration of the SCS server sets up and initializes the following system services:

1. DHCP server, to allocate Swarm node addresses

2. TFTP server, for Swarm network boot

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

4. Syslog server for centralized logging (log files can be found within: /var/log/datacore)

5. Configuration and License Server for Swarm node access

Network Architecture

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

• SCS server addresses are IPs on a routable subnet.

• Application servers can be dual-homed, like the SCS server, for ease of access to the cluster, but the preferred architecture is to access the cluster via a Gateway installed alongside the SCS server.

• Swarm Storage nodes’ default network gateway is the SCS server, which can be changed to support existing routers. Direct-routed access to storage nodes bypasses access control and should be avoided in most cases.

Open

Swarm Interfaces

The SCS CLI is the sole interface to SCS functionality.

• CLI (Command-Line Interface) - see Swarm Cluster Services (SCS) CLI Commands

  • The CLI, called scsctl, is a native application installed on the SCS server.

  • To get CLI help, type: scsctl help

Components

A “component” refers to a piece of the Swarm ecosystem. This can be Swarm Storage, the Content Gateway service, PXE booting services, or even the SCS server itself. A component must be registered with the SCS server for it to be brought under the umbrella of SCS management capabilities. Additionally, multiple versions of a component may be registered at the same time, though one may be marked as the currently active version.

Components may additionally provide settings available to be adjusted for a given site. These settings may then be used to populate configuration for running instances of the various components. Configuration files exist within SCS as template files that reference these settings. When the configuration file is requested (by a booting storage node, for example), the template is filled in with the current values of those settings.

However, configuration files are not limited to only referencing settings associated with that component. For example, the configuration file for a storage node is not limited only to settings provided by the storage component. Any setting provided by any component within SCS may be referenced (logging server IP address provided by platform, DNS settings provided by network_boot, etc).

Groups

A “group” refers to a cluster or pool of instances of a given component. The most common example is a Swarm Storage cluster; the cluster is represented as a “group” within SCS. Accordingly, the group’s name is also the name of the cluster. Other installation topologies may involve multiple concurrent pools of Content Gateways:

• A group solely for S3 access

• A group for administrative purposes, outside of the normal data path

• A group providing a content portal

The SCS server also supports the notion of a default group (referred to using the keyword _default).

Instances

An “instance” refers to a single running unit of a component. For example, a single Storage node, a single Content Gateway, or a single SCS server. Each of these represents an instance of the respective component.

Settings

Settings are self-describing values adjusted or modified to suit the needs of a given Swarm site. A setting is associated with the component providing it, and is referenced by name. A setting has a data type, a description, a value, and may have a default value. Additionally, settings may be marked as secure, in which case SCS redacts the value under certain circumstances.

Settings are defined at the component level but may have overrides provided at the group and/or instance level. An instance-level override takes precedence over a group-level override, and if no overrides are given then the base component definition is used.

Templates

Templates and settings are the two sides of the configuration coin. Settings define what values are available for configuration, but templates are what actually pull those values into a usable form. Each component is unique in the configuration needs: Storage has one configuration file (node.cfg), while Content Gateway has multiple (gateway.cfg, logging.yaml, etc.). Each configuration file may also have a distinct format.

To support the wide variety of configuration needs, components also register templates with the SCS server, one for each configuration file an instance may need. These templates refer to settings provided by one or more components and may also refer to other SCS server information (all known IP addresses of instances of a group within a certain component, for example). The sole formatting “rule” for a template is it must conform to Jinja2 templating rules. Templates are rendered to a usable form when requested by a running instance.