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 services 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).

...

• Installation and configuration of Swarm Storage software

• Network boot support

• Automatic provisioning of network and node configsconfigurations

Swarm Environment and Networking

The following system services are set up and initialized by 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, 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. Jira LegacyserverSystem JIRAserverId531626c3-9736-37df-aa7a-4fbff3a1ead8keySCS-226

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

...

The SCS CLI is the sole interface to SCS functionality:.

• CLI (Command-Line Interface) — - see SCS CLI Commands

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

  • To get CLI help, type: scsctl help

...

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

...

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 Content Portala content portal

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

...

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

...

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 in to 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 the a usable form when requested by a running instance.