Demonstrating vMotion capabilities with Oracle RAC on VMware vSphere

Please download to get full document.

View again

of 46
33 views
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.

Download

Document Related
Document Description
With today’s technologies, you can run large mission-critical databases on virtual machines safely and securely. Creating virtual servers to host databases, instead of running them on physical servers, has the potential to provide a number of time- and cost-saving benefits to your organization, as you can take advantage of the many powerful features and tools that VMware vSphere offers including vMotion, DRS, and much more. We designed this functional stress test to test the complete hardware and software stack, which was comprised of VMware vSphere, Cisco UCS, and EMC VMAX Cloud Edition storage. The EMC VMAX Cloud Edition absorbed the workload’s requested storage throughput. The Cisco B200 M3 servers were able to supply the processing power necessary for the workload. The Cisco Nexus switches, despite using only at a fraction of their maximum capacity in this test, allowed for the required network throughput, including the vMotion traffic. This physical infrastructure, used in concert with VMware vSphere, allowed vMotions to occur and the RAC application to remain active despite the migration scenarios we tested, some of which were more extreme than database administrators would typically encounter. The tests experienced no false ejections or RAC cluster fencing operations, showing the mature capabilities of VMware vMotion technology. As we showed in our tests using Cisco UCS server hardware and EMC VMAX Cloud Edition storage, VMware vSphere with vMotion made it easy to shift large databases and other workloads from one server to another in a cluster, without application downtime. By choosing to run your large databases on VMware vSphere virtual machines, you can reap the benefits of VMware vMotion for the ultimate agility and flexibility in managing your mission-critical database workloads.
Document Share
Document Tags
Document Transcript
   SEPTEMBER 2013 A PRINCIPLED TECHNOLOGIES TEST REPORT Commissioned by VMware, Inc. DEMONSTRATING VMOTION CAPABILITIES WITH ORACLE RAC ON VMWARE VSPHERE Oracle Database products have long been a mainstay of the relational database market, on which many businesses and organizations run their most critical systems. When it comes to this critical application stack layer, these organizations demand the ultimate in uptime and reliability, and have traditionally had to sacrifice some flexibility and agility to achieve these goals. In the last decade, virtualization has led to a convergence where organizations need not choose between uptime and flexibility. Now, with the features and large maximum configurations available with VMware vSphere 5.1, VMware vMotion can distribute and transition workloads of large Oracle RAC configurations seamlessly between the physical nodes in a VMware vSphere cluster. VMware vMotion can simplify previously time-consuming tasks such as moving VMs between physical servers for maintenance or distributing VMs to optimize processing power during peak workload times. Reducing the migration time required to complete these tasks is critical, along with executing the migration reliably. In the Principled Technologies labs, we set up a VMware vSphere 5.1 cluster using three Cisco UCS B200 M3 blade servers and EMC VMAX Cloud Edition storage. Each server contained one virtual machine (VM) that was a member of an Oracle Real Application Cluster. The Oracle RAC configuration ran a large Oracle Database 11 g  Release 2 database with 156 GB of memory. Using VMware vMotion technology, we were able to easily transition VMs to other servers in the cluster without downtime.   A Principled Technologies test report 2 Demonstrating vMotion capabilities with Oracle RAC on VMware vSphere VMWARE VMOTION FOR VM MIGRATION VMware vMotion, a feature of VMware vSphere, performs live migrations that transition entire running virtual machines from one physical host to another, without forcing the workload to stop. vMotion transfers the entire execution state of the VMs, by breaking down elements to move the networking and SCSI device connections and the active physical memory of the VM. With VMware vMotion, administrators can fully automate migration and schedule migrations to occur without further intervention. If desired, vSphere can use VMware vSphere Distributed Resource Scheduler (DRS) to dynamically load balance workloads across the hosts within a VMware vSphere cluster in real time using vMotion. VMware vSphere 5.1 includes multi-NIC vMotion capabilities to move vMotion data over the network as quickly as possible to minimize any impact to migrating workloads. VMware vMotion strives to keep workload transfers imperceptible to end users, which allows you to minimize maintenance windows and maintain service level agreements (SLAs) without hassle. Quick and successful virtual machine migrations are a key part of running a virtualized infrastructure. When using migration for maintenance purposes, keeping maintenance windows to a minimum requires a reliable migration solution, such as VMware vMotion, to minimize any impact on end users relying on the applicable workload. Migration performance also makes a difference in maintaining SLAs with customers, which indicates the quality of service. VMware vSphere not only transitions VMs from host to host, but also utilizes migration technologies of VMware vSphere Distributed Resource Scheduler (DRS) to balance workloads across hosts dynamically and automatically. VMware vMotion transitioned database VMs with ease In our setup, we created a three-server VMware vSphere 5.1 cluster using Cisco UCS servers and EMC VMAX Cloud Edition storage. The configuration used a single VM per ESX host. Each VM was allocated 156 GB of memory with Oracle 11 g  Release 2 (11.2.0.3) being used as the database. For detailed hardware information, see Appendix A. For detailed steps on how tested, see Appendix B.  The initial test included a single vMotion operation, proving that vMotion is capable of transitioning a large Oracle RAC instance without issue. Figure 1 shows how we completed our single vMotion test, in which we migrated the VM from host A to host B. This test mimics a scenario where host A must be taken offline for maintenance, but the large database workload is mission-critical, and must continue to run.   A Principled Technologies test report 3 Demonstrating vMotion capabilities with Oracle RAC on VMware vSphere Figure 1: Diagram of our single vMotion test, where we migrated the VM from host A to host B. To put the vMotion technology and the hardware stack to the test, we then ran two additional tests, doing a double vMotion and then a triple vMotion. While these exact scenarios are less likely to reflect everyday practice, they show the flexibility and durability that VMware vMotion provides when moving large database workloads. Figure 2   shows how we completed our double vMotion test, in which we transitioned the VM from host A to host B and the VM from host B to host A. Figure 2: Diagram of our double vMotion test, where we swapped VMs on hosts A and B.   A Principled Technologies test report 4 Demonstrating vMotion capabilities with Oracle RAC on VMware vSphere Figure 3 shows how we completed our triple vMotion test, where we migrated VMs from each host to another. Figure 3: Diagram of our triple vMotion test, where we migrated VMs in a round-robin formation across the three hosts. WHAT WE FOUND Our full vMotion test consisted of a 40-minute window. First, we began an active TPC-C like workload, using Benchmark Factory for Databases, to exercise the hardware and software stack. While the TPC-C like workload ran, we performed a single vMotion, the double vMotion, and then the triple vMotion  –  all while the workload continued to service requests to the client application. Between the single vMotion and the double vMotion event, we reset the VMs onto their srcinal physical hosts. To show the impact of the moving VMs from host to host, we measured the processor utilization of each host before, during, and after each vMotion occurred (see Figure 4). Each of the before and after CPU utilization percentages are an average taken from a 90-second sample.
Search Related
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks