Gilad Zlotkin & Gary Kotton - VM Ensembles

992 views

Published on

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

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
992
On SlideShare
0
From Embeds
0
Number of Embeds
460
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Gilad Zlotkin & Gary Kotton - VM Ensembles

  1. 1. Group SchedulingGilad Zlotkin - RadwareGary Kotton - Red HatVM Ensembles
  2. 2. Motivation• Group together VMs to provide a certain service• Enables scheduling policies per group/sub-group• Provides a multi-VM application designed for faulttolerance and high performance
  3. 3. ExampleBad placement: if a host goes downentire service is down!Placement strategy - anti affinity:achieving fault tolerance
  4. 4. Placement Strategies• Availability - anti affinityo VMs should be placed in different failure domains (e.g., on differenthosts) to ensure application fault tolerance• Performanceo Network proximity Group members should be placed as closely as possible to oneanother on the network (same connectivity domain) to ensurelow latency and high performanceo Host Capability IO-Intensive, Network-Intensive, CPU-Intensive,...o Storage Proximity• Security - Resource Isolation/exclusivityo Host, Storage, Network, ...
  5. 5. Grizzly• Anti affinity per groupo nova boot --hint group=WS[:anti-affinity]--image ws.img --flavor 2 --num 3 WS1• Review in progresso Pending review in Havana• API - postponed to Havana
  6. 6. Havana• Groups CRUD• Membership of individual resources ingroupso Sub groups• Composite provisioning
  7. 7. Network ProximityAZ 1 AZ 2
  8. 8. API - Aiming for H2• Proposed API (Nova Extension)o id - a unique UUIDo name - human readable nameo tenant_id - the ID of the tenant that owns the groupo policies - a list of policies for the group (anti affinity,network proximity and host capabilities)o metadata - a way to store arbitrary key value pairson a groupo members - UUIDs of all of the instances that aremembers of the group
  9. 9. Flow• Group will be created with no members• Group ID will be used for schedulingo Passed as a hinto Scheduler will act according to group policieso Scheduler will update members• Pending support for group of groups• Group membership will be removed wheninstance is deleted
  10. 10. Discussion• API: Policy, Scope• Data model• Implementation• Volume placement strategieso VM - to volume performance• Consuming Quantums network proximity• VM Ensembles• https://etherpad.openstack.org/group-scheduling

×