Quick overview of some simple recipes about how to size your cloud with StackOps Enterprise Edition based distro with Openstack & KVM

1. 24/09/2012 © 2011-2012 StackOps Technologies S.L. – All rights reserved
1

2. Prerequisites & Provisioning definition
© 2011-2012 StackOps Technologies S.L. – All rights reserved
2

3. Objectives
 Understand what “oversubscription” is
 Get the right list of resource ratios
 Understand how storage system works
 Get the right storage sizing
 Understand what is a flavor
 Get the right list of flavors for your environment
 Understand how golden images works
 Get the right list of images for your environment
© 2011-2012 StackOps Technologies S.L. – All rights reserved
3

4. Oversubscription
 “To sold in excess of available resources"
 We can oversubscribe three different resources:
 Cores per Server
 Memory per Server
 Storage per Zone
 Memory oversubscription is not recommended
 Unexcepted performance  Cannot define a valid SLA
 Cores are oversubscribed using ^2 (1:2, 1:4, 1:8)
 Storage can only oversubscribe if it can autoexpand
 Not recommend, can mislead the user
 Use thin provisioning and deduplication
© 2011-2012 StackOps Technologies S.L. – All rights reserved
4

5. Oversubscription - Exercise
 vCPU and Memory are ALWAYS correlated in “flavors”
 All servers should have the same configuration (can be different, but scheduler is
not bullet proof)
 Server: 12Cores, 128GB of RAM
1. If server has HT, then we can assume 24 cores
2. Real memory for Hypervisor, 120GB (4GB per 64GB of Hugepages used explains the 8GB gap)
3. Divide 120GB and 24 = 5GB per core.
4. Sounds huge to me… let’s oversubscribe the vCPU at 1:2 ratio
5. 48 vCPU and 2.5GB per VM.
6. Still too big? Let’s oversubscribe 1:4
7. 96 vCPU and 1.25GB per VM
© 2011-2012 StackOps Technologies S.L. – All rights reserved
5

6. Storage System
 Openstack was designed for shared-nothing storage (local disks)
 StackOps has modified Nova to use Shared
 Shared storage per Zone must be the aggregate of:
 Images uploaded by Customer and default Images
 Base Images (copy of in-use images (OS disks) and ephemeral (local disks)
 Instance disks (use base-image technology)
 Volumes
 StackOps has modified the Scheduler to not overcommit storage (Ex: checks if the system
has enough space to allocate the requests)
 Also modified checks in the UI. Enabled Quota control at different levels
 If the size of the shared storage changes, the system detects it automatically.
 Quotas are modified if used the ‘vpc’ command.
© 2011-2012 StackOps Technologies S.L. – All rights reserved
6

7. Storage Sizing - Exercise
 We have a maximum of 96 VMs of 1vCPU per server with former calculations
 Let’s assume 10GB of storage for OS Disk
 Let’s assume 10GB of local disk per vCPU (flavor)
 96VM * 20GB = 1920GB
 Let’s assume 10GB per Golden Image and 20 Golden Images
 20 Golden images * 10GB = 200GB
 Let’s assume the customer will create 50 volumes of 20GB each maximum
 50 Volumes * 20GB = 1000GB
 Total Storage per Compute Node added = 1920 + 200 + 1000 = 3120 (3TB)
 As seen, VM density per server is critical.
© 2011-2012 StackOps Technologies S.L. – All rights reserved
7

8. Flavors
 Openstack was designed following AWS vm approach: vCPU x Memory x
Ephemeral disk size
 Using the shared storage approach and volumes, then may be it’s worth
to avoid adding ephemeral storage by default
 The concept of flavor was created to maximize server resources usage
 So it’s very important to create the right list of flavours.
 As a rule of thumb, a bigger flavor duplicates resources from smaller
 Very important to avoid server resources fragmentation (Example: 3vCPU
and 7GB). Again, use ^2
© 2011-2012 StackOps Technologies S.L. – All rights reserved
8

9. Flavors - Exercise
 96 vCPU and 120GB of RAM
 1.25GB per vCPU
 10GB of extra local storage per vCPU
 So the BASE FLAVOR would be: 1vCPU / 1.25GB / 10GB (small)
 And so on…
 2 vCPU / 3GB / 20GB (medium)
 4 vCPU / 6GB / 40GB (large)
 8 vCPU / 12GB / 80GB (extra large)
 16 vCPU / 24GB / 160GB (extra extra large)
 Note: it’s possible to use flavors without local storage.
© 2011-2012 StackOps Technologies S.L. – All rights reserved
9

10. Golden Images
 Golden Images can be in different formats:
 Qcow2
 Raw
 Vmdk
 To calculate the available size in the system, the images must be in raw format.
 Images can be preprovisioned from Head-manager
 Images can be uploaded with glance utility by users
 Anybody can create their own images.
 Existing images inject keypairs at deployment time
 It’s recommended to mount a shared storage with deduplication and compression
of the filesystem (if possible).
© 2011-2012 StackOps Technologies S.L. – All rights reserved
10

11. To summarize…
Oversubscribe CPU
Do not oversubscribe memory
Choose flavors to fully use your servers
Size storage per compute server
Use raw formats for Golden images
© 2011-2012 StackOps Technologies S.L. – All rights reserved
11

12. Thank you!
Visit us in http://www.stackops.com
© 2011-2012 StackOps Technologies S.L. – All rights reserved
12