Gilad Zlotkin & Gary Kotton's group presentation at OpenStack Israel May 2013

1. Group Scheduling
Gilad Zlotkin - Radware
Gary Kotton - Red Hat
VM Ensembles

2. Motivation
• Group together VMs to provide a certain service
• Enables scheduling policies per group/sub-group
• Provides a multi-VM application designed for fault
tolerance and high performance

3. Example
Bad placement: if a host goes down
entire service is down!
Placement strategy - anti affinity:
achieving fault tolerance

4. Placement Strategies
• Availability - anti affinity
o VM's should be placed in different 'failure domains' (e.g., on different
hosts) to ensure application fault tolerance
• Performance
o Network proximity
 Group members should be placed as closely as possible to one
another on the network (same 'connectivity domain') to ensure
low latency and high performance
o Host Capability
 IO-Intensive, Network-Intensive, CPU-Intensive,...
o Storage Proximity
• Security - Resource Isolation/exclusivity
o Host, Storage, Network, ...

5. Grizzly
• Anti affinity per group
o nova boot --hint group=WS[:anti-affinity]
--image ws.img --flavor 2 --num 3 WS1
• Review in progress
o Pending review in Havana
• API - postponed to Havana

6. Havana
• Groups CRUD
• Membership of individual resources in
groups
o Sub groups
• Composite provisioning

7. Network Proximity
AZ 1 AZ 2

8. API - Aiming for H2
• Proposed API (Nova Extension)
o id - a unique UUID
o name - human readable name
o tenant_id - the ID of the tenant that owns the group
o policies - a list of policies for the group (anti affinity,
network proximity and host capabilities)
o metadata - a way to store arbitrary key value pairs
on a group
o members - UUIDs of all of the instances that are
members of the group

9. Flow
• Group will be created with no members
• Group ID will be used for scheduling
o Passed as a hint
o Scheduler will act according to group policies
o Scheduler will update members
• Pending support for group of groups
• Group membership will be removed when
instance is deleted

10. Discussion
• API: Policy, Scope
• Data model
• Implementation
• Volume placement strategies
o VM - to volume performance
• Consuming Quantum's network proximity
• VM Ensembles
• https://etherpad.openstack.org/group-
scheduling