12
© 2011-2012 StackOps Technologies S.L. – All rights reserved 02/08/2022 1

Stackops - Openstack Nova sizing & service definition

Embed Size (px)

DESCRIPTION

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

Citation preview

Page 1: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved13/04/20231

Page 2: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

Prerequisites & Provisioning definition

2

Page 3: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

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

3

Page 4: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

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

4

Page 5: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

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

5

Page 6: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

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.

6

Page 7: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

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.

7

Page 8: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

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

8

Page 9: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

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.

9

Page 10: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

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).

10

Page 11: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

To summarize…

11

Oversubscribe CPU

Do not oversubscribe memory

Choose flavors to fully use your servers

Size storage per compute server

Use raw formats for Golden images

Page 12: Stackops - Openstack Nova sizing & service definition

© 2011-2012 StackOps Technologies S.L. – All rights reserved

Thank you!

Visit us in http://www.stackops.com

12