Fence

Definition

Signature

fence(s1 : set<VM>, s2 : set<server>)

• s1 : an non-empty set of VMs for a meaningful constraint. VMs not in the Running state are ignored.

• s2 : an non-empty set of servers or the constraint is sure of not being satisfiable. Servers not in the Online state are ignored.

The fence constraint forces each running VM in s1 to be running on one of the online servers in s2.

Classification

• Primary users: datacenter administrator
• Manipulated elements: VM placement
• Concerns: Partitioning, VM-to-server placement

Usage

A fence constraint deserves partitioning purposes. First, it may be used by a datacenter administrator to part the infrastructure. Such a situation is typically motivated for security or administrative purposes. As an example, a datacenter may be the property of multiple organizations that have aggregated their servers. However, administrative policies may disallow to have specific VMs of one organization running on servers belonging to another organization. In this setting, fence constraints may be used to specify the list of allowed servers for these VMs.

Another possible usage of fence constraints consist in splitting the VMs when the infrastructure is designed using an aggregation of independent partitions of servers. As an example, a partition may consist of a standalone shipping container of servers or all the servers connected to a same storage space when VMs disk images are only available to these servers. In this setting, fence constraint allow the datacenter administrator to restrict the placement of the VMs to their assigned partition.

Finally, a fence constraint may be used as a backend for a resource matchmaking system [38] for non-cumulative resources. As an example, a VM may require a particular hypervisor, processor or GPU. Fence constraints may then be used to force the VMs to be running on compatible environments. The list of the compatible servers must be established before using the constraint. It has to be noticed that this use case is not suitable when the matchmaking is focusing shareable but finite resources such as memory or computing power.

Example

Figure 3 depicts a sample reconfiguration between a source and a destination configuration. In this example, the following fence constraints were considered.

• fence({VM1,VM2}, {N1, N2}). This constraint was already satisfied in the source configuration as both VMs were running on N1. The constraint is still satisfied in the destination configuration despite VM2 has been relocated to N2 as this action is allowed by the constraint.

• fence({VM2, VM3}, {N2}). This constraint was not satisfied in the source configuration as VM2 was not running on N2. Its relocation to N2 during the reconfiguration fixed this violation. During the reconfiguration process, VM3 has been stopped and is now in the Waiting state. The VM was then ignored by the constraint.

N1: VM1 VM2

N2: VM3

N3:

?: VM4

N1: VM1 VM4

N2: VM2

N3:

?: VM3

Figure 3: A reconfiguration motivated by fence constraints.

See also

Related Constraints

• ban: the opposite constraint of fence. One fence constraint can be emulated using a ban constraint by specifying to the ban constraint the absolute complement of the set of servers specified in the fence constraint.

• quarantine: This constraint encapsulates the fence constraint but also disallows the VMs outside the fence to be relocated to servers inside the fence.

• among: The among constraint encapsulates the fence constraint. The given VMs will necessarily be running on a single set of servers but multiple candidate set of servers may be passed as an argument to let the among constraint state about the set of servers to choose. A fence constraint can be emulated using one among constraint when only of set of servers is specified.

Reformulation(s)

• Using ban: fence(vs1, ns1) ↔ ban(vs1,ns1)

Specialization(s)

• To ban: fence(vs1,ns1) ↔ ban(vs1, ns1)