You can perform various operations on a Node by clicking the link for it in the System Control Panel. Various options are then displayed.
If at any point a Node detects an error in its running, it will automatically place itself into an error state, to prevent any further virtual machines being started on it.
If a node reboots, then it will come back into maintenance mode and will need manually placing back in the pool (by placing back into running mode). This is to prevent faulty hardware that has rebooted becoming live again in the available resource pool.
Flexiant Cloud Orchestrator supports having nodes of different configurations, including different:
- Network Configuration
To deal with the issues of having heterogenus nodes of different configuration, Flexiant Cloud Orchestrator has introduced the following features to ensure they can work together, even within the same cluster: CPU Contention, RAM Contention, and Node Groups.
Compute Nodes have two contention settings: CPU and RAM.
RAM Contention is available on KVM only and should be used with caution. KVM allows you to 'thin allocate' RAM to virtual machines, only allocating them what they need as they use it. This potentially allows you to over-allocate/contend the RAM resources on a node.
Caution: Over allocating RAM resources can overwhelm the contention and cause the Virtual Machines to crash.
Flexiant Cloud Orchestrator allows you to set different contention levels on different Nodes, which can mean you can balance overall CPU performance between nodes of different capabilities, ensuring smoother performance for users of the platform.
As standard, Flexiant Cloud Orchestrator will allocate virtual machines to nodes so that the ratio of virtual CPU cores used by the VMs to physical CPU cores on the machines evened out across the platform. This ensures even loading of each CPU core. However, it assumes that each CPU core is equally powerful. The CPU contention setting acts a multiplier for the number of physical CPU cores. If a node was added with CPU cores with twice the performance of all other nodes, it should be set to have CPU contention of 2, so in the CPU part of the VM allocation algorithm, the system will assume there is twice as much CPU capacity given the number of CPU nodes. If a very slow node with CPU cores with half the normal speed, it should have its CPU contention set to 0.5.
Where allowed by the hypervisor, Flexiant Cloud Orchestrator allows you to contend the RAM offered to each virtual machine. This offers the ability to 'oversell' the RAM. If the RAM contention is set to a number greater than 1, the allocation algorithm will treat the node as having the amount of physical RAM it does have multiplied by that contention ratio. So, if the node has 1GB of RAM and a RAM contention setting of 1.5, it will treat it as having 1.5GB. It will therefore allocate VMs to that node with RAM requirements totalling 1.5GB rather than 1GB. This strategy will succeed so long as VMs either do not use more than an average of 2/3 of their allocated RAM, or successfully page share such that 1/3 of their allocated RAM is shared with other VMs, or a combination of the two. If each of the VMs happens to allocate more RAM than this, VMs will start to fail; therefore you should use this setting with caution.
WARNING: RAM contention settings greater than one can cause your system to become unreliable. The probability of failure increases as the ratio of the largest VM RAM size to the physical memory increases.
For technical reasons, notwithstanding the RAM contention setting, a node will not be allocated a VM unless there is sufficient physical RAM (ignoring contention) to start the virtual machine.
RAM contention is only currently available under KVM.
As Flexiant Cloud Orchestrator PXE boots its nodes, it needs to know about their network configuration before they boot. Node Groups allow you to specify multiple different network configurations for nodes, even within the same cluster. More details are available from Config Groups