Characterizing IBM DB2 with VMware® VMotion

Characterizing IBM DB2 with VMware VMotion

Robert Campbell Senior Technical Alliance Manager

VMware, Inc.

Acknowledgments IBM Software, in particular the following individuals, has provided extraordinary support to realize this effort: Sunil Kamath, Senior Technical Manager for DB2 OLTP Performance Benchmarks and Solution Development Peter Kokosielis, Advisory Software Developer, DB2 Virtualization & Performance Solutions The following VMware team members have offered valuable support: Kristen Edwards, Senior Manager, IBM Software Alliance Praveen Javehrani, Validation Test Engineer, Alliances Balayya Kamanboina, Validation Test Engineer, Alliances Madhu Rao, Manager, Systems Engineering, Alliances

Table of Contents 1. Introduction..........................................................................................................1

2. Executive Summary ............................................................................................1

3. Products, Concepts and Technology ..............................................................2

3.1. Products ...............................................................................................................................................................................2 3.2. Concepts and Technology ......................................................................................................................................3

4. Test Configuration, Methodology and Results ............................................4

4.1. First Test Scenario .........................................................................................................................................................5 4.2. Second Test Scenario ..................................................................................................................................................8 4.3. Third Test Scenario ....................................................................................................................................................11 4.4. Fourth Test Scenario.................................................................................................................................................13 4.5. Summary of Results ..................................................................................................................................................15

5. Conclusion.......................................................................................................... 16

6. References .......................................................................................................... 16

VMware White Paper Characterizing IBM DB2 with VMware VMotion

1

1. Introduction Virtualization is rapidly transforming the IT landscape and fundamentally changing the way that people compute. Today’s powerful x86 computer hardware was originally designed to run only a single OS. This approach introduced a tight coupling between Operating System (OS) and hardware. Virtualization breaks that bond between the OS and hardware by making it possible to run multiple OS and applications on the same computer at the same time, increasing the utilization and flexibility of hardware. VMware® VMotion enables live migration of virtual machines from one VMware® ESX host server to another ESX host server. Live migration means moving running executing guest operating systems, their applications and their user sessions without any interruption of service or loss of transaction data.

Figure 1. VMware VMotion technology This white paper is intended for VMware and IBM DB2 customers, partners, or employees who want more information on how VMware technologies can be used with the DB2 Database. The goal of this document is to make DB2 administrators aware of how DB2 works with VMotion. It focuses on the following:

1. Data Integrity 2. Overall impact of performance in terms of TPS 3. Loss of connectivity 4. Understanding how DB2 works with VMotion under varying workloads

2. Executive Summary One of the largest challenges that customers have to contend with in any environment is how to deal with planned downtime. In the physical world servers always need to be powered down at some point, for various reasons: firmware upgrades, adding or removing hardware, or to upgrade to newer hardware. The same is true in the VMware virtual world! VMware has pioneered a unique technology that minimizes planned downtime and allows workloads running on one physical ESX host server to be “hot” migrated (moved live) to another ESX host server, without any impact to end users. While this sounds like magic, VMware customers have been using VMotion technology successfully since it was first delivered in 2003.


2

VMware designed VMotion to handle three different use cases. It is the fundamental technology that enables each of these capabilities: 1. Minimizing planned downtime with operator managed (manual) VMotion 2. Automated server load balancing with VMware® Distributed Resource Scheduler (DRS) 3. Power savings with the automated power management subsystem VMware® Distributed Power

Management (DPM). DPM is currently available as an experimental product You may want to know what impact VMware VMotion will have on your applications when virtual machines are moved from one physical server to another. The first question is around transactional integrity: will all your data be there after the migration completes? The second question is around understanding transaction rate and overall impact to SLAs: will your transactions per second and response times be negatively impacted by VMotion? This whitepaper provides data that will help answer these questions.

3. Products, Concepts and Technology Readers should be familiar with the following VMware and IBM products, terminology and technologies when they read this white paper.

3.1. Products IBM DB2 software: DB2 delivers industry-leading performance, scalability, security, and reliability on a choice of clustered or single-servers running Windows, Linux, and UNIX. It provides comprehensive features to manage the most demanding transaction processing, business intelligence, and content management applications easily. The most current release, DB2 9.5, offers features such as deep compression to save on storage costs, workload management (WLM) to prioritize tasks, and further enhancements to its autonomics and self-tuning capabilities. VMware® Infrastructure is infrastructure virtualization software that virtualizes servers, storage, and networking, allowing multiple unmodified operating systems and their applications to run independently in virtual machines while sharing physical resources. VMware ESX is a “bare-metal” hypervisor that partitions physical servers in multiple virtual machines. Each virtual machine represents a complete system, with processors, memory, networking, storage and BIOS. VMware ESX enables multiple virtual machines to share physical resources, run unmodified operating systems and applications, and run the most resource-intensive applications side by side on the same server. VMware VMotion technology moves running virtual machines from one physical server to another with no impact to end users. VMware VMotion keeps your IT environment up and running, giving you unprecedented flexibility and availability to meet the increasing demands of your business and end users. VMware Distributed Resource Scheduler dynamically allocates and balances computing resources. VMware DRS continuously monitors utilization across resource pools and intelligently allocates available resources among the virtual machines based on pre-defined rules that reflect business needs and changing priorities. When virtual machine resources are constrained, additional capacity is made available by migrating live virtual machines to a different physical server using VMware VMotion.


3

VMware® VirtualCenter Management Server (also referred to as VirtualCenter Server) is the central management service for configuring, provisioning, and managing distributed VMware virtual IT environments. VirtualCenter provides a user-friendly interface that can help provision, monitor and manage the virtualized environments consisting of multiple ESX server hosts. The multiple VMware ESX server hosts can be combined to form a logical datacenter cluster where the virtual machines can be managed via a centralized interface. Essentially, VirtualCenter allows virtual datacenter customers to achieve the highest levels of efficiency, automation, simplicity and security via guided execution of VMware functions like VMotion, Distributed Resource Scheduling (DRS), VMware® High Availability (HA) and VMware® Consolidated Backup.

3.2. Concepts and Technology Guest Operating Systems: VMware supports a broad range of guest operating systems, including Windows and Linux systems from older generation releases to the latest versions. Consequently, DB2 enterprise customers have the luxury of choosing the best in breed x86 operating system on which to deploy DB2 database technologies. VMware VMotion and CPU Compatibility: VMware VMotion technology allows users to migrate running virtual machines between compatible physical servers with zero downtime. To ensure successful migration and subsequent functioning of the virtual machine, you must respect certain compatibility constraints. See the Resources section for a link to the VMotion Information Guide, which describes CPU compatibility issues and outlines some CPU compatibility checks that VMware VirtualCenter performs before allowing migration with VMotion. Manual Migration (Hot): Term used to describe using VMotion to move a running virtual machine from one ESX host server to another in real time, without interruption of service to end users or loss of transactions. Virtual Switch: ESX uses virtual switches to hide physical NIC cards from virtual machines. In a VMware Infrastructure Cluster, physical servers may have different NIC configurations. VMware uses consistent virtual switch naming conventions and virtual machine assignments to ensure consistency across the host servers. This is a requirement for VMotion. Virtual Machine IP Address: Physical servers with NIC cards are assigned 32-bit IP addresses to enable them connect to a network. Virtual machines with Virtual NIC cards also receive 32-bit IP addresses, as in the physical world, to connect to a network. Virtual Machine MAC Address: Virtual machines can be created with Virtual NIC Cards. Each Virtual NIC card has a unique 48-bit MAC address, just as in the physical world. Re-locatable IP / MAC: Term used to describe the fundamental networking capabilities and requirements for enabling VMotion. No matter which physical ESX host server a virtual machine runs on, its MAC addresses and IP addresses remain the same and are always consistent from a network perspective. Shared Storage: In order for virtual machines to be migrated using VMotion they must be deployed on shared storage. VMware supports SAN, iSCSI and NFS as valid shared storage platforms for VMotion.


4

4. Test Configuration, Methodology and Results In this exercise, VMware worked with IBM DB2 Labs to test the behavior of DB2 9.5 with VMotion. To make this testing relevant to real-world database environments we used an internal IBM DB2 labs OLTP workload that closely resembles the industry standard benchmark TPC-C. The database transaction workload (DTW) was scaled to 12GB in size and driven by 35 remote TCP/IP clients. The metric of the workload is the number of transactions completed per second (TPS).

The database used DB2 best practices for OLTP, including:

• Automatic Storage tablespace for data and index tables (4K page size) • Direct I/O enabled (“no filesystem caching” option on tablespace) • 4GB Buffer pool The test environment included the following components: Management and Load Driver System: One stand-alone HP 460c Blade: 2 x dual core CPUs 2.3GHz/ 16GB RAM running ESX 3.5 hosted administrative and non-DB2 load driver components: • ESX Server (Administrative virtual machine) • DB2 workload virtual machine: This virtual machine was configured with guest OS Red Hat

Enterprise Linux 5.1 64-bit and DB2 9.5 64-bit Client. The DB2 DTW comes complete with its own workload driver tool. This tool runs on Linux and can scale very well.

• VirtualCenter Management Server virtual machine: This virtual machine was configured with

guest OS Windows 2003 EE and VCMS 2.5. It ran on the same physical server as the DTW load driver utility.

VMware Infrastructure Cluster: We put two servers in a VMware Infrastructure cluster and enabled them with SAN storage. The cluster components include: • ESX Server1 (VMotion Source) is an HP 460c Blade with 2 x dual core CPUs 2.3GHz/ 16GB

RAM running ESX 3.5 (Total CPU: 2.330 * 4 cores = 9.3GHz) • ESX Server2 (VMotion Target) is an HP DL380 server with 2 x Quad Core 3.16GHz CPUs/32

GB RAM running ESX 3.5 (Total CPU: 3.160 * 8 cores = 25.28GHz) • SAN Storage: NetApp FAS3020 w/ 6TB Storage on Fibre Channel • DB2 virtual machine running RHEL 5.1 64-bit guest OS and IBM DB2 9.5 EE 64-bit, enabled with 4

virtual processors (vCPU) and 8GB RAM initially. In all four test cases, this virtual machine starts on ESX Server1 and is migrated using VMotion to ESX Server2. This virtual machine’s source files reside on the NetApp SAN, including the OS & DB2 binaries, DTW DB2 Data and DTW DB2 Logs.


5

Figure 2. Test Environment Architecture We conducted four tests scenarios, with results detailed in the next four sections.

4.1. First Test Scenario In the first test, we did not want the physical server to be fully saturated. We assumed the DB2 virtual machine is being fully consumed and meeting its SLAs with 25% of physical CPU resources allocated to it. We used VMware ESX resource allocation capabilities to limit the DB2 virtual machine to 25% of four vCPUs. Since the physical machine has four physical cores rated at ~2330 MHz and our DB2 virtual machine has four vCPUs that are limited to 25% maximum usage, our DB2 can only use ~2330 MHz CPU. With the virtual machine restricted to 25% maximum CPU usage capabilities, we ramped up the DB2 DTW workload to perform our testing.


6

Figure 3. Virtual machine properties for first test scenario

Figure 4. First test scenario ESX host server load before VMotion migration


7

Figure 5. TPS during VMotion migration – first test scenario

Figure 6. First test scenario ESX host server load after VMotion migration


8

The first test, shown in Figures 3-6, demonstrates that with the DB2 virtual machine fully saturated and the source physical server (see Figure 4) 25% saturated:

• The DB2 virtual machine was successfully migrated to the second ESX host server in approximately

10 minutes. • No transactions were lost. • No data was lost. • Transaction throughput degraded slightly during migration, dropping by approximately 27% for

about ten minutes. • There was a short, approximately two second, pause in throughput as the migration of the DB2

virtual machine from ESX Server1 to ESX Server2 completed. Transactions continue to be submitted and queued during this pause; there is no loss in DB2 connections or timeouts. Transactions are applied to a memory bitmap while the final transfer of control is handed over to the target ESX host server. When the virtual machine transfer to the target server is complete, all DTW DB2 transactions are committed and acknowledged.

• Overall TPS exceeded expectations after migration, attributed to limited CPU resources on the source server that restricted the workload from ramping up quickly. This behavior diminishes as vCPU resources on the source server increase in tests two through four.

4.2. Second Test Scenario The second test increased the amount of CPU consumption available to the virtual machine from 25% to 50%.

Figure 7. Virtual machine properties for second test scenario


9

Figure 8. Second test scenario ESX host server load before VMotion migration

Figure 9. TPS during VMotion migration – second test scenario


10

Figure 10. Second test scenario ESX host server load after VMotion migration

In the second test, shown in Figures 7 - 10 above, with the DB2 virtual machine fully saturated and the source physical server (see Figure 8) 50% saturated:

• VMotion successfully moved the DB2 virtual machine to the second ESX host server in

approximately 11.5 minutes. • No transactions were lost. • No data was lost. • Transaction throughput degraded slightly during migration, dropping by approximately 18% for

about 11.5 minutes. • There was a momentary pause (approximately 20 seconds) in throughput as migration of the DB2

virtual machine from ESX Server1 to ESX Server2 completed. • Overall TPS increased after migration.


11

4.3. Third Test Scenario The third test increased the amount of CPU consumption available to the DB2 virtual machine to 75%.

Figure 11. Third test scenario ESX host server load before VMotion migration

Figure 12. TPS during VMotion migration – third test scenario


12

Figure 13. Third test scenario ESX host server load after VMotion migration

The third test, shown in Figures 11 - 13 above, demonstrates that with the DB2 virtual machine fully saturated and the source physical server (see Figure 11) 75% saturated:

• VMotion successfully migrated DB2 to the second ESX Server in approximately 10.5 minutes. • No transactions were lost. • No data was lost. • Transaction throughput degraded slightly during migration, dropping by approximately 14% for

about 10.5 minutes. • There was a momentary pause (approximately 60 seconds) in throughput as the migration of the

DB2 virtual machine from ESX Server1 to ESX Server2 completed. • Overall TPS increased after migration.


13

4.4. Fourth Test Scenario The fourth test increased the amount of CPU consumption available to our DB2 virtual machine from 25% to 86%.

Figure 14. Fourth test scenario ESX host server load before VMotion migration

Figure 15. TPS during VMotion migration – fourth test scenario


14

Figure 16. Fourth test scenario ESX host server load after VMotion migration

The final test, shown in figures 14 - 16, demonstrates that with the DB2 virtual machine fully saturated and our source physical server (see Figure 14) 86% saturated:

• VMotion successfully migrated DB2 to the second ESX Server in approximately 11.5 minutes. • No transactions were lost. • No data was lost. • Transaction throughput degraded slightly during migration, dropping by approximately 13%

for about 11.5 minutes. • There was a momentary pause (approximately 70 seconds) in throughput as the migration of

the DB2 virtual machine from ESX Server1 to ESX Server2 completed. • TPS returns to normal after migration completes.


15

4.5. Summary of Results

VMotion Performance

0

100

200

300

400

500

600

700

1 14 27 40 53 66 79 92 105 118 131 144 157 170 183 196 209 222 235

Time Interval (10s)

TPS

2330 MHz4660 Mhz6990 Mhz8000 Mhz

Figure 17. Summary of TPS during VMotion for all test scenarios

Figure 17 shows that all test scenarios achieved similar results: • Under every condition, migrating a DB2 virtual machine with VMotion is safe, retaining full data

integrity. • Migrating DB2 when the ESX host machine has ample resources available has very little overall

impact on end user response times and overall TPS. • Migrating DB2 when the ESX host machine has fewer resources available creates a slight impact to

overall throughput, with a potential pause in computing, but user access and sessions, as well as transactions in flight, are never lost and are always committed.

• In addition, we observed some aspects of the robust scheduling capabilities of ESX. Using the baseline average TPS of 511 after the Test 4 migration, we can calculate theoretical 100% TPS being ~594TPS. From this we can deduce that the ESX scheduler scales very well:

Theoretical Linear Scalability Actual Average TPS

Test1 25% (594 * .25 = 148.5) 138 Test2 50% (594 * .50 = 297) 289 Test3 75% (594 * .75 = 445.5) 448 Test4 86% (594 * .86 = 510.84) 511

Theoretical 100% (511 / .86 = 594) N/A


16

5. Conclusion VMware VMotion is a safe and effective way to move DB2 workloads from one server to another when it is desirable for such purposes as server maintenance, load balancing or power savings during low compute hours. VMotion performs better than physical infrastructure alternatives in that VMotion does not interrupt service or user access to data, and does not necessitate planned downtime windows, application outages and after hours onsite support. Customers can run their DB2 database workloads with confidence on VMware ESX. IBM supports customers who run DB2 on VMware Infrastructure, and DB2 workloads behave well with VMware VMotion technology.

6. References VMware References

VMware and IBM Software solutions page http://www.vmware.com/partners/alliances/technology/ibm.html VMware download page: for evaluation copies of VMware Infrastructure http://www.vmware.com/download/ VMware Infrastructure overview product page http://www.vmware.com/products/vi/ VMware VMotion product page http://www.vmware.com/products/vi/vc/VMotion.html VMware DRS product page http://www.vmware.com/products/vi/vc/drs.html VMware VirtualCenter product page http://www.vmware.com/products/vi/vc/ VMware Guest Operating Systems supported http://www.vmware.com/pdf/GuestOS_guide.pdf VMotion Compatibility Information Guide http://www.vmware.com/files/pdf/VMotion_info_guide.pdf

IBM References

IBM Information Management Software http://www-01.ibm.com/software/data/?pgel=ibmhzn&cm_re=masthead-_-products-_-sw-infomgmt IBM DB2 for Linux and Windows

http://www.ibm.com/db2

VMware, Inc. 3401 Hillview Ave. Palo Alto CA 94304 USA Tel 1-877-486-9273 Fax 650-427-5001 www.vmware.com © 2008 VMware, Inc. All rights reserved. Protected by one or more of U.S. Patent Nos. 6,397,242, 6,496,847, 6,704,925, 6,711,672, 6,725,289, 6,735,601, 6,785,886, 6,789,156, 6,795,966, 6,880,022, 6,961,941, 6,961,806, 6,944,699, 7,069,413; 7,082,598 and 7,089,377; patents pending.

Characterizing IBM DB2 with VMware® VMotion · VMware White Paper Characterizing IBM DB2 with...

Documents

Transcript of Characterizing IBM DB2 with VMware® VMotion · VMware White Paper Characterizing IBM DB2 with...