Your SlideShare is downloading. ×
0
Gilad Zlotkin & Gary Kotton - VM Ensembles
Gilad Zlotkin & Gary Kotton - VM Ensembles
Gilad Zlotkin & Gary Kotton - VM Ensembles
Gilad Zlotkin & Gary Kotton - VM Ensembles
Gilad Zlotkin & Gary Kotton - VM Ensembles
Gilad Zlotkin & Gary Kotton - VM Ensembles
Gilad Zlotkin & Gary Kotton - VM Ensembles
Gilad Zlotkin & Gary Kotton - VM Ensembles
Gilad Zlotkin & Gary Kotton - VM Ensembles
Gilad Zlotkin & Gary Kotton - VM Ensembles
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Gilad Zlotkin & Gary Kotton - VM Ensembles

730

Published on

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

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
730
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Group SchedulingGilad Zlotkin - RadwareGary Kotton - Red HatVM 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 faulttolerance and high performance
  • 3. ExampleBad placement: if a host goes downentire service is down!Placement strategy - anti affinity:achieving fault tolerance
  • 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. 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. Havana• Groups CRUD• Membership of individual resources ingroupso Sub groups• Composite provisioning
  • 7. Network ProximityAZ 1 AZ 2
  • 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. 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. 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

×