The document outlines a methodology for sizing virtual machines when migrating enterprise applications from non-virtualized to virtualized servers. It involves monitoring application CPU utilization and transaction times in the non-virtualized environment. Queuing models are then used to evaluate deployment scenarios and identify the minimum number of virtual CPUs needed for each application's VM to maintain acceptable performance levels once virtualized. The methodology aims to determine optimal virtual CPU allocations based on actual physical resource needs rather than guesses, to avoid overcommitting resources and performance issues.

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

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

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

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

26. Share this presentation Share to Facebook Share to LinkedIn Share toTwitter Share to SlideShare