Home > Blogs > VMware VROOM! Blog > Monthly Archives: December 2009

Monthly Archives: December 2009

VMware vCenter Site Recovery Manager 4.0 Performance and Best Practices White Paper Posted

VMware vCenter Site Recovery Manager 4.0 is a component of VMware Infrastructure that ensures a speedy and successful datacenter recovery by automating the recovery process and eliminating the complexity of managing and testing recovery plans. A new white paper, VMware vCenter Site Recovery Manager 4.0 Performance and Best Practices, is now available at http://www.vmware.com/files/pdf/VMware-vCenter-SRM-WP-EN.pdf

You can also find it under the technical resources section at http://www.vmware.com/products/site-recovery-manager/resource.html.

In this paper we discuss VMware vCenter Site Recovery Manager 4.0 performance, various dimensions on which the recovery time depends and certain performance tips/considerations on architecting recovery plans to minimize recovery time.
You will also find Database sizing guides under the Tools section at http://www.vmware.com/products/site-recovery-manager/resource.html which will help you in estimating the Site Recovery Manager Database growth as a function of the number of protection groups, recovery plans and more .

SAP Performance and Scalability with IBM System x3850 M2 and vSphere 4

Back in June, I wrote about some scale-up experiments that we conducted with SAP software on vSphere 4.  That work focused on a single VM, so we decided to follow it up with a study of multiple VMs on a single server.  Collaborating with IBM, we performed experiments to study the scale-out behavior of SAP software: using vSphere 4 to run multiple VMs on a 24-core IBM x3850 M2.  We presented this joint work at VMworld 2009 (EA 1640), and have recently written a whitepaper that contains the results: ftp://ftp.software.ibm.com/eserver/benchmarks/wp_x3850M2_VMware_SAP_Scaling_112009.pdf

This new whitepaper highlights the fairness of scheduling in vSphere and the hardware features of the x3850 M2 that allowed us to run 12 concurrent 2vCPU VMs with excellent performance.  In addition, we showed that a variety of choices of vCPU count and VM count are possible with very little impact on performance (see figure).