The most efficient way to manage a Swarm cluster's configuration and software is to use a Cluster Services Node (CSN). This offers the ability to centrally manage the cluster's software and configuration.
Situations exist where PXE booting storage nodes is not an option. Perhaps the only available network interface cards on the chassis do not support PXE. Perhaps no other hardware in the Swarm subnet is available for the role of a PXE server. See the available options:
1. USB drive boot
In this scenario, as already outlined in the Swarm guides (specifics on creating the USB drive are in the README.txt file), the Swarm software and configuration files all reside on a USB drive which is used to boot the Swarm node. All configuration changes need to be made using one of the following methods:
The USB drive
The cluster settings in the Swarm Admin Console
Since many parameters are not available using the Swarm Admin Console or settable using SNMP, this leaves many parameters unchangeable without physically removing the USB drive, changing the caringo/node.cfg file, re-inserting the USB drive, and rebooting the chassis.
2. USB drive boot with centralized license server
This is the same scenario as above, but in the node.cfg file on the USB drive. Specify an http reachable web server where the license is stored.
Once the node boots in this method, if the license file needs to be changed, do so at any time on the web server itself which is periodically polled by the node. This allows changing licenses without physically accessing to the USB key.
3. USB drive boot with centralized configuration
This last method completely bypasses the node.cfg but requires DHCP in the subnet where the Swarm node is located. The centrally available configuration server is not reachable without DHCP.
Where cfg-list.txt is a container that includes the text below.
Each of the above files are layers of configuration including parameters normally configured in the node.cfg file, applied in order. Subsequently parameters override previous parameters if the parameters are the same. Specify cip.group=126.96.36.199 in the cluster.cfg; and then specify cip.group=188.8.131.52 in the subcluster.cfg, 184.108.40.206 is applied as the cip group.
In the above files, parameters belonging to every node in the cluster (like multicast group, vols, license url) may exist. Add those parameters to cluster.cfg file. Multiple subclusters may exist. Add subcluster-specific parameters to the subcluster.cfg (like the node.subcluster configuration parameter). Some configuration elements only apply to the individual node (like IP addresses, number of processes) which are set in the testnode.cfg file.
When the castor_cfg parameter is used in the syslinux.cfg file, keep in mind the node.cfg in the caringo folder on the USB drive is no longer valid.
This setup only works if the node can get DHCP, even if the final IP address assigned by the node-specific configuration file (testnode.cfg in the above example) is not the same as the original DHCP address. In a scenario where the node has multiple processes, the multiple processes need to be specified (and thereby multiple IP addresses) in the testnode.cfg file.
In this setup, in order to change a configuration parameter normally changed on the USB drive, change the applicable configuration file on the web server and then reboot the node to pick up the change.
None of the above scenarios allows central management of the Swarm software itself, so upgrades require physically updating the USB drives.