Methodology of virtual machines sizing
Upcoming SlideShare
Loading in...5
×
 

Methodology of virtual machines sizing

on

  • 1,311 views

The presentation outlines methodology

The presentation outlines methodology
of virtual machines CPU sizing

Statistics

Views

Total Views
1,311
Slideshare-icon Views on SlideShare
1,306
Embed Views
5

Actions

Likes
0
Downloads
52
Comments
0

1 Embed 5

http://www.linkedin.com 5

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Methodology of virtual machines sizing Methodology of virtual machines sizing Presentation Transcript

    • 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
      • 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)
    • 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 ?
    • Methodology highlights
          • In non-virtualized environment for each application monitor its CPU utilization on each server
          • Find out is there enough unused CPU capacity to consolidate applications on fewer servers
          • 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
          • 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
    • Methodology highlights (continued 2)
          • 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.
          • 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.
      • 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
      • 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.
    • Non-virtualized deployment. Architecture
    • Application workloads
    • Transaction profiles (service demands) Applications A and B deployed on servers 1, 2, and 3
    • 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
    • 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
    • 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.
    • 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.
    • Virtualized deployment. Architecture (continued 2)
    • Virtualized deployment. Architecture (continued 3)
    • 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
    • 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
    • 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.
    • VM sizing after lesson learned Increasing a number of CPUs per virtual machine
    • 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%.
    • 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.
    • VM sizing after lesson learned (continued 4)
    • Methodology of virtual machines sizing
      • Estimate capacity demand from each application either by monitoring production system under realistic workload or using queuing models.
      • 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.
      • 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%).
      • 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.
    • Methodology of virtual machines sizing (continued 2)
      • When configuring VM assign to each one the same number of virtual CPUs (vCPU) as a number of physical CPUs identified in 4.
      • 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
    • Share this presentation Share to Facebook Share to LinkedIn Share toTwitter Share to SlideShare