Abiquo 4.5 introduces new
Table of Contents |
---|
Introduction to concurrent VM operations
Excerpt |
---|
The platform uses configuration properties to |
...
control |
...
the number of concurrent operations |
...
to:
|
...
|
...
|
...
|
...
The platform can control concurrency for:
You can define concurrency limits at the level of:
|
...
|
...
|
...
|
...
You can also allow concurrent operations to change the state of a VM |
...
(e.g. |
...
power on), while limiting |
...
concurrent configure operations. See the "openSession" properties at Abiquo configuration properties#virtualfactory |
List of VM operations for which the platform controls concurrency
...
The platform controls concurrency for VMs, which means the following operations that are managed through the provider/hypervisor, device, or backup manager.
- VM state changes (powerOn, powerOff, etc)
- Configure/Deconfigure/Reconfigure VM
- Register/Unregister/Update VM with Firewall Policy / Load Balancer / Nat Rule
- Perform Backup / Schedule Backup / Restore From Backup of a VM
Control concurrency at the platform level
...
An example of the application of concurrency limits is when you are deploying a virtual appliance with multiple VMs.
The concurrency limits do not apply to non-VM entities related to virtual datacenters because the platform does not use the same pool for these, for example, the platform does not restrict the number of concurrent operations to create a private network.
Set default concurrency limits for the platform
The top level of concurrency configuration is the existing control at the platform level. This limits These properties limit the number of concurrent operations for the same connection (hypervisor IP or endpoint), device, or backup manager.
Code Block | ||||
---|---|---|---|---|
| ||||
abiquo.virtualfactory.openSession
abiquo.virtualfactory.device.openSession
abiquo.virtualfactory.backup.openSession
|
For example, to allow 2 two connections to vCenter1 + 2 connections to vCenter2 + 2 connections to each of the public cloud regionsregion and hypervisor, set openSession to 2.
Code Block | ||||
---|---|---|---|---|
| ||||
abiquo.virtualfactory.openSession=2 |
For example, the platform can perform 2 concurrent operations on the same vCenter (for VMX_04 or CLUSTER plugins) or AWS region.
...
This means that if you have two vCenters and some public cloud regions, you can perform two concurrent operations on vCenter1, and two on vCenter2, and two on each of the public cloud regions.
Set concurrency limits for a type of hypervisor or public cloud provider, device, or backup manager
To limit concurrency for specific plugins, devices, or backup managers.If not specified by type, then the defaults are the platform level properties, set the specific properties for this purpose.
Code Block | ||||
---|---|---|---|---|
| ||||
abiquo.virtualfactory.{pluginTypeInLowerCase}.openSession abiquo.virtualfactory.{backupManagerLowerCase}.backup.openSession abiquo.virtualfactory.{deviceLowerCase}.device.openSession |
If you do not specify a value, then the default is the platform level property.
For example, to allow only one operation at any time on each AWS region.
Code Block |
---|
abiquo.virtualfactory.amazon.openSession=1 |
Control concurrency at the virtual datacenter level
Concurrency control at the VDC level means that the platform will apply the properties for concurrency values (including plugin typelimits (for hypervisor/PCR endpoint, device, and backup manager) to an individual PER VDC.
The default values allow concurrent operations to the same provider type, device, and platform supports "byvdc" properties when you have either a public cloud region with native support for VDCs (e.g. AWS VPC, Azure Virtual Network, vCloud vApp) or a hypervisor with a network device, (e.g. vCenter + NSX device).
If you do not specify these properties, the default values are false, which means that the platform will apply the concurrency limits PER hypervisor/public cloud endpoint, device, or backup manager.
Code Block | ||||
---|---|---|---|---|
| ||||
abiquo.virtualfactory.openSession.byvdc=false abiquo.virtualfactory.device.openSession.byvdc=false abiquo.virtualfactory.backup.openSession.byvdc=false |
To prevent compute concurrency in the same virtual datacenter, which means all the operations to the same VDC will be executed one after another, set the following propertiesthe "byvdc" property to true and restrict the total number of sessions as the platform or provider/hypervisor level.
For the same PCR endpoint (connection data)example, with the the following properties, it will only be possible to execute multiple concurrent operations but only (for the same hypervisor/PCR endpoint (connection data)) if they affect different virtual datacenters.
Code Block | ||||
---|---|---|---|---|
| ||||
abiquo.virtualfactory.openSession.byvdc=true abiquo.virtualfactory.openSession=1 |
Note that when using When you use ''openSession.byvdc'' properties, the platform does not limit the maximum number of concurrent connections to the same ConnectionData (provider endpoint or hypervisor IP). the hypervisor/PCR endpoint, device, or backup manager.
For example, for the following configuration, in AWS you could have a total number of concurrent operations equal to the number of virtual datacenters x 2.
Code Block | ||||
---|---|---|---|---|
| ||||
abiquo.virtualfactory.openSession.byvdc=true
abiquo.virtualfactory.amazon.openSession=2 |
In contrast, if the "byvdc" properties are false (or not present) the platform will only allow two concurrent operations for each hypervisor/provider endpoint, device, or backup manager.
Allow fast VM state changes
When you use the fast state changes functionality, the platform will always execute VM state changes when you request them, without waiting for any concurrent operations to finish.
The VM state changes change operations are as follows:
- powerOn
- powerOff
- shutdown
- reset
- pause
- resume
...
Code Block | ||||
---|---|---|---|---|
| ||||
abiquo.virtualfactory.openSession.faststatechanges=true |
...
For example, with the following configuration, the platform will only allow one configure/deconfigure/reconfigure at a time, but several state changes can occur concurrently.
Code Block | ||||
---|---|---|---|---|
| ||||
abiquo.virtualfactory.openSession.faststatechanges=true abiquo.virtualfactory.openSession=1 |
Limitations
—
* the properties only apply to the virtualfactory (vm centric ops) so don't expect other operations with entities related to virtualdatacenter are also executed in the same pool (eg: create private network doesn't follow this concurrency limitations)
* byvdc requires a Vpc interface implementation
** compute plugin also implements Vpc. eg: PCR vcloud
** compute plugin + networking device. eg: vcenter + nsx device
* when using ''faststatechanges'' the max number of concurrent operations coulb be <= opensessions x 2 for deploy operations (configure + powerOn) or unlimited if performing other state changes in vms.
* changing the behavior of the pool when using a provider also capable of device ops (public clouds with lb,fw, net or nat features), previously using 2 pools (opensessions + device.opensessions), now a plugin capable of executin device ops only use the opensessions pool.
Examples
no concurrency in a virtualdatacenter (by type)
Panel |
---|
Given
When |
no limitation if not specified by type
Panel |
---|
Given
When |
change the default concurrency context
Panel |
---|
Given
When |
compute plugin without vpc device
Panel |
---|
Given
When |
fast powerOn
Panel |
---|
Given
When |
fast powerOn during configure
Panel |
---|
Given
deploy a vapp with +1 vms powerOn/powerOff/reset/pause or resume another vm (same vdc or not) Then only one configure operation concurrently, but the state change in the other vm is executed immediately |