About the Cray Management System
Introduction to the Cray Management System (CMS) and its components.
- Separation of configuration data and software content
- Separation of the management infrastructure from the product content
- Modularity
- Prescriptive results
- Scalability
- IMPS
- Image Management and Provisioning System.
IMPS enables sites to manage software content in a prescriptive way. It leverages and extends industry-standard tools such as zypper and rpm. IMPS is used to create and distribute repository content (RPMs) and to create and update standard or custom images. Cray provides image recipes for different node types: service, login, compute, DAL, etc. The image recipes tie together the collections of software defined in the package collections and the repositories that contain the software. From them, IMPS builds a list of all the software and repositories referenced, and passes it to zypper or yum, which resolves the RPM dependencies and installs the software into the specified image root. See the IMPS man page for more information.
- CMF
- Configuration Management Framework
The CMF is a combination of software and conventions that enable the modular management and application of configuration. Each application comes with the software needed to configure that application. All configuration information needed to operate the logical system is stored in a central repository called a config set. It is made available to every node in the system by means of the IMPS Distribution System (IDS), a read-only network share. Cray provides a configurator to enable sites to create, change, or add new configuration information. Configuration for all applications installed in an image is applied at boot time using cray-ansible, a wrapper that finds all Ansible plays installed on the system and executes them with Ansible.
- NIMS
- Node Image Mapping Service
NIMS enables site administrators to assign any node or group of nodes any boot image. It also provides a mechanism for passing additional kernel parameters to the nodes on boot. See the NIMS man page for more information.
Ansible is installed into each image. During boot, each node runs all Ansible plays, pulling in the configuration information needed to self-configure ("pull" mode). Ansible is called twice during system boot—once from initrd /init before Linux has started up (in_init) and once after normal Linux startup with systemd (multiuser)—to cover both early and run level 3 use cases. Ansible can be run in “push” mode after boot to support reconfiguration.