- Overview
- Product Documentation
- CML 2.8 Release Notes
- CML 2.8 Installation Guide
- CML 2.8 User Guide
- CML 2.8 Admin Guide
- CML Administrator's Guide
- Cisco Modeling Labs System Overview
- System Defaults
- Creating a New Node Definition
- Node Definition SMBIOS Parameters Specification
- Custom VM Images
- Clustering
- CML Admin Tools
- System Settings
- Networking
- Resources
Clustering¶
Since version 2.4.0, Cisco Modeling Labs has offered a clustering feature.
When you deploy a CML cluster, the running simulation for a lab is no longer restricted to the resources of a single computer (the all-in-one controller). It can instead use the resources from multiple servers.
Note
Clustering is only available in the non-personal CML product offerings, such as CML-Enterprise and CML-Education.
Clustering Terminology¶
The documentation uses the following terms when referring to a CML cluster:
- node / VM
a virtual machine, which is part of a lab topology
- fabric
the software component that connects VM NICs with each other, also provides external connectivity
- controller
the CML instance that hosts the CML controller services, the CML UI and the CML APIs
- compute host
a host of a cluster where CML runs the VMs for running nodes
- cluster
a set of CML servers with one controller and one or more compute hosts
You can configure the CML controller in a cluster so that it runs VMs just like the compute hosts, or you can use a dedicated controller that does not run any node VMs. We generally recommend disallowing VMs from running on the controller, if possible.
Clustering Overview¶
When planning your CML deployment, you have two ways to scale your CML server.
Vertical scaling - increase CML’s capacity by provisioning a larger CML server or adding more and faster CPU cores, RAM, and disk storage to a single server.
Horizontal scaling - increase CML’s capacity by adding additional servers to a CML cluster.
CML clustering adds the ability to connect one or more compute hosts to a CML controller, forming a CML cluster. Within such a cluster, users can start large topologies, which would not fit into a single all-in-one CML server, and the CML controller will dynamically assign nodes to the compute hosts of the cluster. The cluster controller can place VMs for nodes from a single topology on different compute hosts. During the initial setup of a CML instance, you must choose whether it will be a cluster controller, a cluster compute host, or a standalone (non-cluster) instance.
Clustering provides the following high-level features:
Dynamic registration of compute hosts to the cluster controller
Sharing of reference platform images from the cluster controller to each compute host
Automatic distribution of large labs across available compute hosts
In-place upgrade from a standalone CML server to a CML cluster where the controller is also permitted to run node VMs.
After a node was created or wiped, and before it is started, an administrator may pin it to start on a specific compute host. See Compute Pinning.
Nodes which are not pinned are placed in no particular order on compute hosts. CML starts the node VM on an arbitrary compute host that can run it.
Clustering constraints¶
Before deploying a CML cluster, you should be aware of the current constraints. In this release, CML clustering has the following constraints:
Clustering is only available on non-personal CML products. Personal products, i.e., CML-Personal and CML-Personal Plus, cannot run a CML cluster.
No migration of nodes. Once a node has been allocated to a specific compute host, it will stay on that compute host every time you start the lab unless you wipe the node (or lab) first. The next time you start a node after wiping it, it will be assigned to a compute host again. It may be allocated to the same compute host as before.
No re-balancing. For example, if all running nodes were allocated to one compute host, and other compute hosts of the cluster are idle, there is no automatic re-balancing of the nodes to the available compute hosts. As above, stopping and wiping the lab will cause the nodes to be reallocated the next time you start the lab, and that reallocation may rebalance the nodes across the compute hosts.
No external connectivity via compute hosts. All external traffic by design goes only through the controller’s interfaces.
Software upgrade for a cluster. To upgrade a cluster, you must manually trigger the upgrade of the controller and all the compute hosts.
A CML cluster may be licensed for up to 300 additional nodes. That is, you may add 0 - 300 expansion node licenses on top of the CML base license.
Cluster size is currently limited to 8 compute hosts.