Among

Definition

Signature

among(vs : set<VM>, ns : set<set<server>>)

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

• ns : an non-empty set of set of servers or the constraint is sure of not being satisfiable. Sets composing ns must be disjoint. Servers not in the Online state are ignored.

The among constraint forces each running VM in vs to be hosted on one of the set of servers in ns.

Classification

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

Usage

The among constraint may be used by a datacenter administrator or an application administrator to group closely related VMs with regards to specific criteria. A datacenter network is usually designed as a fat-tree [30], [1] that provides a non-uniform network latency and bandwidth between the servers. An application administrator having strongly communicating VMs may then require to have its VMs hosted on servers connected to a same edge switch to improve their communication. This can be achieved using one among constraint where each set of servers denotes the servers connected to a same edge switch.

A datacenter administrator may also rely on among constraints to part the datacenter and ease its management. First, the administrator reflects, using disjoint set of servers, the current physical partitioning (different geographical sites, administrative zones, shipping containers of servers [23], ...) of the datacenter. Among constraints are then use to force groups of VMs to stay inside a single physical partition.

Example

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

• among({VM1, VM2, VM3}, {{N1, N2},{N3, N4}}). This constraint was not satisfied in the source configuration as VM1 and VM2 were running on the partition {N1, N2} while VM3 was running on the partition {N3, N4}. The reconfiguration fixed this violation by relocating VM3 to N2. VM2 was relocated to N2 but this action does not contradict the constraint.

• among({VM4, VM5}, {{N1},{N2, N3, N4}}). This constraint was not satisfied in the source configuration as VM4 and VM5 were running on distinct partitions. This violation was fixed by suspending VM5.

• among({VM6, VM7}, {{N1,N2},{N3, N4}}). This constraint was already satisfied in the source configuration as both VMs were running on the partition {N1,N2}. The constraint is still satisfied in the destination configuration as both VMs have been relocated to the partition {N3,N4}.

N1: VM1 VM2 VM6 VM7

N2: VM5

N3: VM3

N4: VM4

N1: VM1

N2: VM2 VM3 (VM5)

N3: VM6

N4: VM4 VM7

Figure 5: A reconfiguration motivated by among constraints.

See also

Related Constraints

• fence: The fence constraint is a specialization of the among constraint: only one set of servers is possible to restrict the VMs placement. A among constraint is then equivalent to a fence constraint when there is only one possible set of servers to host the VMs. This occurs when only one set of servers is specified, when other sets are offline, or when one of the given VMs is ensured to be hosted on a known server as the other VMs will necessarily be hosted on the set of servers the known server belong to.

Reformulation(s)

• Using splitAmong: among(vs1, ns1) ↔ splitAmong({vs1},ns1)

Specialization(s)

• To gather: among(s,N/|N|) ↔ gather(s)

• To ban: among(vs1,{ns1}) ↔ ban(vs1, ns1)