Cloud Computing Patterns, Mechanisms > Virtual Server and Hypervisor Connectivity and Management Patterns > Virtual Server-to-Host Anti-Affinity
Virtual Server-to-Host Anti-Affinity (Erl, Naserpour)
How can a virtual server be guaranteed to not be hosted on a particular host or group of hosts?
A virtual server cannot be hosted on a specific host or group of hosts.
Anti-affinity rules are used to ensure that the virtual server or bundled workload will not be hosted on the target host or hosts.
Virtual server-to-host anti-affinity rules are applied and configured, and controlled and dedicated by the VIM server to prevent the virtual server or workload from being hosted on the target host or group of hosts.
Burst In, Burst Out to Private Cloud, Burst Out to Public Cloud, Cloud Authentication, Cloud Balancing, Elastic Environment, Infrastructure-as-a-Service (IaaS), Isolated Trust Boundary, Multitenant Environment, Platform-as-a-Service (PaaS), Private Cloud, Public Cloud, Resilient Environment, Resource Workload Management, Secure Burst Out to Private Cloud/Public Cloud, Software-as-a-Service (SaaS)
The Virtual Server-to-Host Anti-Affinity pattern is applied by configuring rules that create an anti-affinity relation between Virtual Server A and Hypervisor C. This configuration is performed via the VIM server and is replicated across the cluster.
An anti-affinity rule is created and applied to the virtual server and hypervisor (Part I).
The steps involved in applying this pattern are shown (Part II).
Virtual Server B is now powered on at Hypervisor C, while Virtual Server A has been powered on at Hypervisor B (Part III).