CSN Installation

This section describes how to install and configure your Swarm CSN on a dedicated node.

1 Installing the CSN
- 1.1 Requirements
- 1.2 RHEL edition
- 1.3 Root passwords
- 1.4 Important
2 CSN Network Setup
- 2.1 Important
3 Swarm Licensing Setup
- 3.1 Note
4 Booting Swarm Nodes
- 4.1 Swarm 10 and higher

Installing the CSN

The CSN distribution is available as a collection of RPM packages that are installed with a shell script. The packages and their dependencies must be installed as a user with root privileges from an attached monitor and keyboard with at least one NIC connected to the external network.

Requirements

Before installing, be sure to read the CSN Requirements.
To install the software, you must log in to the CSN machine You cannot install the CSN using an SSH session because the network configuration can terminate the connection prior to completion. Do not use "sudo" or "su" for installing CSN as this can interfere with installation. (CSN-2066)

RHEL edition

During installation, administrators installing from the RHEL gnome desktop may see errors stating "An internal system error has occurred". This error is related to package update software running before the CSN is fully initialized and can be safely ignored. The Basic Server edition of RHEL is recommended.

Root passwords

CSN root passwords must be alphanumeric with no spaces or special characters.

As a user with root privileges, copy caringo-csn-{version}.zip to your Cluster Services Node and unzip it into an empty directory of your choice. This directory is referred to as csn-extract-dir. For example, if csn-extract-dir is /tmp/csninstall:
cd /tmp/csninstall unzip caringo-csn-{version}.zip
Install the CSN by running the self-extracting script from the directory location where the shell script was unzipped. You must run the following command as a user with root privileges:
cd caringo-csn-{version} ./caringo-csn-bundle-install.sh
This command initiates installation of the CSN and its dependent packages. If you are upgrading an existing CSN, you will be prompted to reboot when the install process completes; no further configuration is required.
When a new installation is complete, the following prompt displays: Would you like to proceed with CSN network configuration? (yes/no):
- yes - Proceed with configuring the CSN and continue to "Dual-network Primary Configuration" if you are installing the CSN in a dual-network configuration or "Single-Network Primary CSN Configuration" if you are installing the CSN in a single-network configuration within a larger network.
- no - Set up the network at a later time by running the command: / opt/caringo/csn/bin/firstcsnboot.

CSN Network Setup

After running the CSN installation script and answering yes to the question about CSN network configuration, you must enter some minimal configuration data to configure the server on the overall network. Network settings are central to all CSN services and should be planned with care in advance by an administrator knowledgeable about the environment. The initial configuration process is required only once after the initial installation. Any necessary subsequent updates to the initial configuration parameters can be made from the CSN Console. Several prompts will suggest a default value in brackets that you can accept by pressing Enter.

Dual-network Primary Configuration

The following prompts will display if you are configuring the Primary CSN on a dual-network:

Prompt	Description

Prompt	Description
Is this the Primary CSN (yes/no)? [yes]:	This prompt enables you to specify whether or not the CSN is a primary or secondary CSN. For a review of primary and secondary CSN, see "Primary vs. Secondary" . Make sure that only one primary CSN is configured on the internal network to prevent IP address conflicts as well as conflicts with both DHCP and Swarm netboot configuration. The primary server must be configured prior to configuration of a secondary. DHCP is not started on the secondary CSN.
Is this a single or dual network CSN (single/dual)? [dual]	Enter whether the CSN should be configured in a 'single' configuration with both the CSN and the storage nodes directly addressable on a single network or in a 'dual' configuration with the storage nodes isolated on an internal network. For a review of dual and single-network configurations, see "Networking" .
Half of the NIC ports on this system will be bonded and assigned to the external network. The following questions configure the external network:	The following message then displays if you are setting up a Primary CSN.
Enter the CSN IP address [].	Enter an available IP address on the public network. This is the address you use to access the CSN console and that external clients use to access resources on the internal network (such as the Swarm cluster through the SCSP Proxy). The CSN's IP Address must be within the x.y.z.1 - x.y.z.16 range for the configured subnet.
Enter the cluster IP address. This IP address will remain with the Primary CSN in the event of a CSN failover []:	Enter another publicly accessible CSN IP address. (The term cluster here refers to a cluster of CSNs; that is, one primary CSN and one secondary CSN.) This well-known address remains with the primary CSN in the event of a failover, meaning the cluster can always be reached at this address. The entered address must be in IPv4 format and must not already be in use by another host on the network.
Enter the subnet mask [255.255.255.0]:	Enter the subnet mask for the preceding IP addresses. The default is 255.255.255.0.
Enter the gateway IP address []:	Enter the IP address of the default gateway for the preceding IP addresses.
Half of the NIC ports on this system will be bonded and assigned to the internal network. The following questions configure the internal network: Enter the network address, e.g. 192.168.100.0 (small network), 192.168.0.0, 172.20.0.0 (large network) []:	Enter an IP address in your internal network to create an address space for Swarm nodes, third-party servers like DHCP, and other services. Enter the IP address in one of the following formats, depending on your needs: Large network (Class B - more than 128 nodes): Format like 192.168.0.0, 10.10.0.0, or 172.20.0.0 Small network (Class C - 128 or fewer nodes): Format like 192.160.100.0, 10.10.100.0, or 172.20.100.0, where the 100 in the third octet limits the number of available IP Addresses in the specified rang The interface is divided between the CSN(s), privileged applications on the internal network and the Swarm nodes. The initial configuration process automatically creates multiple alias IP addresses on the internal network for use by various system services and reserves similar IP Addresses for a Secondary CSN. Prompts similar to the following display: ^{Configuring external/internal ports. This may take some time.} ^{Checking ... eth0 ...eth1 ...eth2 ...eth3 ...} ^{Eth Device \| MAC \| Public? \| Bond} ^{eth0 \| 00:0c:29:e2:e6:65 \| Y \| bond1} ^{eth1 \| 00:0c:29:e2:e6:6f \| Y \| bond1} ^{eth2 \| 00:0c:29:e2:e6:79 \| N \| bond0} ^{eth3 \| 00:0c:29:e2:e6:83 \| N \| bond0} ^{=============================================} ^{Disconnected NICs =} ^{Recommended ethernet device assignment} ^{Internal NICs = eth2 eth3} ^{External NICs = eth0 eth1} ^{Input the list of External NICs.} The preceding shows how CSN suggests you allocate the available NICs by assigning them to internal and external CSN interfaces. The recommendation is based on how the NICs are currently cabled. All NICs that are currently connected to the network display. Any NICs that are not connected to the network display as Disconnected NICs. After you connect them to the network (or if you later need to change NIC assignments), you can assign them to internal or external CSN interfaces. See "Modifying CSN Network Configuration" . Note: If you answer no to the last configuration prompt asking if the entered values are correct, the interface table displayed on subsequent runs through the configuration prompts will show the values you previously selected for external and internal NICs NOT newly detected values based on any cabling changes.
external nics [space-separated-list]:	Displays the list of NICs the CSN has determined are for its external interface based upon responses from the external gateway. You can optionally change the list if you want to override the CSN's detection. If the NIC distribution is not as expected and you need to recable the NICs, best practice is to abort the initial configuration script, correct the cabling and then rerun initial configuration using /opt/caringo/csn/bin/firstcsnboot. Note: If the configured external gateway has ICMP turned off so that it does not respond to ping requests, the CSN will not be able to automatically detect how the NICs are cabled. You will need to manually assign the NICs to either the external or internal interface using the blank prompts.
internal nics [space-separated-list]:	Displays the list of NICs that CSN has determined are for its internal interface based on lack of response from the external gateway. You can optionally change the list if you want to override the CSN's detection. If the NIC distribution is not as expected and you need to recable the NICs, best practice is to abort the initial configuration script, correct the cabling and then rerun initial configuration using /opt/caringo/csn/bin/firstcsnboot.
Enter a list of IP addresses (separated by spaces) for external name servers [8.8.8.8 8.8.4.4]:	Enter a space-separated list of DNS server IP addresses for the external interface. The default values specify public DNS servers.
Enter a list of IP addresses or server names (separated by a space) for external time servers [0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org]:	Enter a space-separated list of Network Time Protocol (NTP) server IP addresses or fully qualified host names for the external interface. The default values specify public DNS names from the NTP pool project .
Enter a unique storage cluster name. This name cannot be changed once assigned. A fully qualified domain name is recommended []:	Enter a unique name to identify the Swarm cluster. This value must be unique among all clusters you manage; otherwise, disaster recovery will be problematic. (If the contents of more than one cluster with the same name are written to a single disaster recovery cluster, it will be very difficult to recover the contents later.) DataCore strongly recommends you use a fully qualified IANA domain name (for example, csn.example.com). The name you enter displays as the name of the storage cluster on the CSN Console as well as in metadata for all objects written to the local cluster. The CSN also uses this name to detect all the nodes participating in the cluster.
Enter the multicast group that should be used to uniquely identify the storage cluster on the network. Different storage clusters on the same network must have unique multicast addresses or the nodes will merge into a single cluster (224.0.10.100):	Enter a multicast group address for the storage cluster. Each cluster on the same network must have a unique multicast group address. It must be a Class D IP address in the range 224.0.0.0 - 239.255.255.255.
Are these values correct (yes/no)?	This last step allows you to review the values entered for all prompts before submitting them. Entering yes enables the initial configuration process to proceed with network and service configuration, resulting in a fully functional CSN. Entering no to the final initial configuration prompt restarts the initial configuration script at the first prompt, with the previously entered values populated. Values other than yes or no (case sensitive) are not supported. Note: After you complete the installation, but before CSN reboots, Fail messages might display. These messages are harmless and can be ignored.

At the completion of a successful initial configuration, the CSN immediately reboots the server to initialize all services. When the node comes back up, all network services are configured and available, including SNMP v2, syslog, DHCP, DNS, NTP, and firewall. Additionally, the CSN Console is available and the SCSP Proxy will be configured and started.

Dual-network Secondary CSN Configuration

After you configure a dual-network Primary CSN, you can optionally configure a Secondary CSN. The Secondary requires only the entry of a single unique external IP address and identification of the internal interface that is already defined on the Primary. The Secondary will then pull much of its network configuration data from the Primary. To ensure current configuration data is pulled, make sure a backup has occurred after the last configuration change on the Primary prior to installing the Secondary CSN. To facilitate this, a one-time use of the Primary's root password is required as follows (blank passwords are not supported):

^{Additional information about the network will be obtained from the primary CSN}
^{Please enter the primary csn root password []:}
^{Please re-enter the primary csn root password []:}

Taken from the confirmation at the end of the initial configuration script, the Secondary configuration parameters are simply:

^{Primary: no}
^{CSN Type: dual}
^{External CSN IP address: 192.168.66.11}
^{Internal network address: 172.20.20.0}
^{external nics [defaults from system scan]:}
^{internal nics [defaults from system scan]:}
^{Are these values correct (yes/no)?}

Note: If a server on the Secondary's public network has an address that conflicts with the private internal address (.3) of the Primary CSN, then discovery of the Primary will fail and the Secondary CSN will not be able to boot. Administrators should take care to ensure IP address spaces do not overlap.

Once configured, a secondary CSN will register with the Primary CSN on the internal network using a privileged SSH channel setup during configuration. This allows the primary to periodically sync needed information to the secondary, specifically the Primary's Backup Manifest UUID. Changes in the Primary's configuration are NOT automatically updated on the Secondary CSN, but will be restored from the Primary's last backup in the event of an admin-initiated Failover.

Single-Network Primary CSN Configuration

The primary CSN in a single-network configuration should already have its network interfaces and IP address configured prior to installation, so the configuration prompts do not include those settings in single-network. During the configuration process, the CSN will read the subnet that was statically pre-configured in the CSN's network services files and use it to define the ranges that will be used for DHCP and netboot. The ranges will be printed during the configuration process to verify they are as intended. Administrators only need to define that the configuration should be for a primary CSN on a single network and then provide name server IP Addresses(es), NTP server(s), and a unique name and multicast group to identify the Swarm cluster as described in the dual-network configuration above.

Taken from the confirmation at the end of the initial configuration script, the single-network primary csn configuration parameters are simply:

^{DHCP Range: 172.20.20.33 - 172.20.20.83}
^{Netboot Range: 172.20.20.84 - 172.20.20.254}
^{Primary: yes}
^{CSN Type: single}
^{Name Servers: 8.8.8.8 8.8.4.4}
^{Time Servers: 0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org}
^{Storage cluster name: cluster.example.com}
^{Multicast Group: 224.0.10.100}
^{Are these values correct (yes/no)?}

Note the DHCP and Netboot Ranges are not entered during configuration but derived from the configured subnet.

Single-Network Secondary CSN Configuration

The secondary CSN in a single-network configuration should also already have its network interfaces and IP address configured prior to installation. Similar to a secondary CSN in a dual-network configuration, the secondary in a single-network configuration gets most of the rest of its configuration information from the primary CSN. To ensure current configuration data is pulled, make sure a backup has occurred after the last configuration change on the Primary prior to installing the Secondary CSN. You will need to enter the primary's IP address and root password to allow the primary's configuration settings to be shared. Note that changes in the Primary's configuration are NOT automatically updated on the Secondary CSN, but will be restored from the Primary's last backup in the event of an admin-initiated Failover.

Taken from the confirmation at the end of the initial configuration script, the single-network secondary CSN configuration parameters are just these:

^{Primary CSN IP Address: 192.168.1.14}
^{Primary: no}
^{CSN Type: single}
^{Are these values correct (yes/no)?}

Swarm Licensing Setup

After you reboot post-configuration but before booting any storage cluster nodes, you need to publish the Swarm license file you received with your purchased capacity via the administrative CSN Console. The console allows web-based configuration of all CSN services after the initial network configuration.

To correctly publish a license, you need to upload the file:

Browse to the CSN Console: http://{CSN·host}:8090
Log in to the console. The username is 'admin' and the default password is 'caringo'.
Click the the Content Storage tab.
Click the Licensing link.
Next to Upload New License File, browse to the location of the license file you received with your published capacity.
Upload the license.

After the file has been updated, the licensing interface will show the company information populated in the license file as well as a last modified date for the license file.

The following characters are accepted: letters, numbers, and characters available by pressing Shift on the number keys (!, @, #, and so on).

Booting Swarm Nodes

Prior to booting, make sure that the CSN has had adequate time to sync with a reliable NTP source and is sync ready as a time source for the nodes. Enter the following at the command line:

$ ntpq -c rv

Check the returned output for these flags:

'sync_alarm' - indicates that the CSN is not yet ready to serve as an NTP server for the Swarm nodes on the internal network.
'sync_ntp' - indicates that all alarms have cleared; this can take as long as 20 minutes.

Once the CSN has been configured and rebooted, the NTP server is synced, and a Swarm license has been published with licensed capacity, you are ready to start booting Swarm nodes.

In a dual-network configuration, no additional steps are required; in a single-network CSN, you must first configure the nodes that should be recognized and netbooted.