<Insert Picture Here>

Leonid Grinshpan, Ph.D. Consulting Technical Director, Oracle Corporation

Methodology of virtual machines sizing

Share to Facebook

Share to LinkedIn

Share toTwitter

Share to SlideShare

2

The views expressed in this presentation are author’s own and

do not reflect the views of the companies he had worked for neither

Oracle Corporation.

All brands and trademarks mentioned are the property of their owners.

The presentation is based on

author’s book

“Solving Enterprise Application Performance Puzzles: Queuing

Models to the Rescue”

(available in bookstores and from Web booksellers from January 2012)

3

Presentation’s goal

The presentation outlines methodology

of virtual machines (VM) CPU sizing

A real life task addressed by methodology:

A number of enterprise applications are deployed on

non-virtualized physical servers.

While moving each application to its dedicated VMs

how many CPUs have to be allocated to each VMs ?

4

Methodology highlights

1. In non-virtualized environment for each application monitor its CPU utilization on each server

2. Find out is there enough unused CPU capacity to consolidate applications on fewer servers

3. Check if consolidation does not degrade application transaction times. Two ways to do it:

• Redeploy apps and monitor live system (practically impossible for production enterprise applications)

• Build a model and evaluate

4. If a model confirms that consolidation does not impact application performance than for each application identify the number N of CPUs it utilizes on each server

5

Methodology highlights (continued 2)

5. Assigning the same N CPUs to VM hosting application will lead to transaction times degradation (this is a harsh reality explained by queuing theory); use model to find out for each VM the number of CPUs Nvm > N that provides acceptable transaction times.

6. While deploying VM use the rule:

NvCPU = Nvm

where NvCPU – number of virtual CPU

Proposed methodology is based on evaluation of a number of physical CPUs sufficient to satisfy application workload. The methodology

actually strips virtualization logistics down to bare bones of physical infrastructure; this approach eliminates guesswork,

overcomitment of resources, minimizes rescheduling downtime.

6

Methodology of VM sizing is using queuing models; visit a link below to learn about enterprise application

modeling and capacity planning

http://www.slideshare.net/samsoncat/methodology-of-enterprise-applications-capacity-planning

7

The subsequent slides demonstrate methodology of VM sizing in action

Demonstration scenario

- Non-virtualized platform includes five physical servers with 8 CPU each one.

- Applications A and B are to be deployed on that non-virtualized platform; application workloads and transaction profiles (service demands) are specified.

- Using models a few deployment scenarios are evaluated; model confirmed that both applications can be deployed on two physical servers.

- In order to isolate applications two VMs per physical server have to be deployed (one VM per application).

- The performance degrades when a number of CPUs in each VM is equal to the one utilized by application in non- virtualized servers.

- Modeling virtualized deployment identifies a number of CPUs per each VM that ensures acceptable transaction times for Applications A and B.

8

Non-virtualized deployment. Architecture

9

Application workloads

10

Transaction profiles (service demands)

Applications A and B deployed on servers 1, 2, and 3

11

Non-virtualized deployment. Transaction times for three set ups of Applications A and B

Model concludes that both applications can coexist on

Servers 1, 2, 3 as an impact on transaction times is practically unnoticeable

12

Non-virtualized deployment. Utilization of three servers

There is substantial headroom on Servers 1 and 3 which suggest that Applications A and B can be redeployed to free up one server

13

Non-virtualized deployment. Utilization of two servers

Model shows that hosting both applications on two servers is acceptable from performance standpoint as it minimizes a number of physical servers

and does not increase transaction time.

14

Virtualized deployment. Architecture

• We are going to isolate the applications by setting up two virtual machines

on each server: one machine for Application A and the second one for Application B.

• Servers 1 and 2 have eight CPUs each and we have to find out how many CPUs should be assigned to each virtual machine.

15

Virtualized deployment. Architecture (continued 2)

16

Virtualized deployment. Architecture (continued 3)

17

Comparison between non-virtualized and virtualized deployments when a number of CPUs on each VM is equal to the one utilized by application in non-virtualized servers

18

Queuing theory explains it all

Formal explanation based on queuing theory can be found

in a book:

Leonid Grinshpan. Solving Enterprise Application Performance Puzzles: Queuing Models to the Rescue,

Willey-IEEE Press; available in bookstores and from Web booksellers from January 2012

19

Queuing theory results are in line with our experience

Toll plaza

Toll plaza with booths equally accessible by any cars has lower congestion than the same plaza with booths divided by two categories: ones serving only sedans and the others serving only trucks.

An intuitive explanation is: in a non-divided plaza in an absence of the trucks a sedan can be processed by any booth and vice versa; in a divided plaza the booths dedicated to trucks will stay idle even if there is a queue of sedans.

Movie theater box office

If any wicket serves any theatergoers, then waiting queue is not as long as in a case when some wickets provide only to particular customer categories.

20

VM sizing after lesson learned

Increasing a number of CPUs per virtual machine

21

VM sizing after lesson learned (continued 2)

Deployment of Application A on non-virtual platform delivers the shortest transaction times. One-CPU virtual machines provide terrible performance. Set up with two CPUs per virtual machine increases transaction time 15% - 22%.

22

VM sizing after lesson learned (continued 3)

Deployment of Application B on non-virtual platform delivers the shortest transaction times. Four-CPU virtual machines significantly degrades performance.

Six-CPU virtual machines features only slight increase in transaction time.

23

VM sizing after lesson learned (continued 4)

24

Methodology of virtual machines sizing

1. Estimate capacity demand from each application either by monitoring production system under realistic workload or using queuing models.

2. Analyze a few what-if scenarios to find out minimal number of non-virtualized physical servers capable to support all applications and meet service level requirements.

3. Identify a number of physical CPUs in use by each application (for a server with M physical CPUs one CPU contributes 100% / M percents to total utilization. If application consumes U% of total server capacity, then a number of physical CPUs utilized by application is (U%*M)/100%).

4. To estimate a number of physical CPUs to allocate to each VM use queuing models – they ensure acceptable performance because model will identify a number of physical CPUs in addition to calculated on step 3.

25

Methodology of virtual machines sizing (continued 2)

5. When configuring VM assign to each one the same number of virtual CPUs (vCPU) as a number of physical CPUs identified in 4.

6. Proposed methodology is based on evaluation of a number of physical CPUs sufficient to satisfy application workload. The methodology actually strips virtualization logistics down to bare bones of its physical infrastructure; this approach eliminates guesswork, overcomitment of resources, minimizes rescheduling downtime.

The following relationships clarify the foggy virtualization concepts guest VM is a process on a physical server virtual CPU of a guest VM is a software thread spawn by guest VM process

26

Share this presentation

Share to Facebook

Share to LinkedIn

Share toTwitter

Share to SlideShare