DEPLOYING IBM DB2 FOR LINUX, UNIX, AND WINDOWS DATA WAREHOUSES ON EMC STORAGE ARRAYS

Transcription

1 White Paper DEPLOYING IBM DB2 FOR LINUX, UNIX, AND WINDOWS DATA WAREHOUSES ON EMC STORAGE ARRAYS Abstract This white paper provides an overview of key components, criteria, and requirements for deploying IBM DB for Linux, UNIX, and Windows (DB for LUW) data warehouse environments on EMC Symmetrix VMAX and VNX series storage arrays. March 2013

2 Copyright 2013 EMC Corporation and IBM Corporation. All Rights Reserved. The authors believe the information in this publication to be accurate as of its publication date. The information is subject to change without notice. The information contained in this publication is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied. In addition, this information is based on EMC and IBM s current product plans and strategy, which are subject to change by EMC or IBM without notice. Product release dates and/or capabilities referenced in this paper may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth, savings or other results. All performance data contained in this publication was obtained in the specific operating environment and under the conditions described and is presented as an illustration only. Performance obtained in other operating environments may vary and customers should conduct their own testing. The information in this document concerning non-ibm products was obtained from the supplier(s) of those products. IBM has not tested such products and cannot confirm the accuracy of the performance, compatibility or any other claims related to non- IBM products. Questions about the capabilities of non-ibm products should be addressed to the supplier(s) of those products. EMC and IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this publication or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from EMC, IBM or their suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of EMC or IBM software. EMC Part 2

3 The furnishing of this document does not imply the grant of a license to any EMC or IBM patents. References in this document to IBM products, Programs, or Services do not imply that IBM intends to make these available in all countries in which IBM operates. Use, copying, and distribution of any EMC or IBM software described in this publication requires an applicable software license. If you are viewing this information in softcopy, photographs and color illustrations may not appear. EMC and Symmetrix are registered trademarks of EMC Corporation. For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com. IBM, the IBM logo, ibm.com, and DB2 are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Unix is a registered trademark of the Open Group in the United States and other countries. Windows is a trademark of Microsoft Corporation in the United States, other countries, or both. Intel Xeon is a trademark or registered trademark of Intel Corporation or its subsidiaries in the United States and other countries. Other company, product, or service names may be trademarks or service marks of others. Part Number h

4 Table of Contents Executive summary... 5 Audience... 5 DB2 for Linux, UNIX, and Windows... 5 Data warehouses an overview... 6 A Modular Approach to Data Warehouse Architecture... 7 The Management module... 8 User modules... 8 Data modules... 8 Failover modules... 9 Expanding a modular data warehouse... 9 Data warehouses and storage usage... 9 DB2 DPF data warehouses that utilize EMC storage IBM Power / AIX Linux Conclusion References

5 Executive summary What s the best way to configure an EMC storage array for a DB2 for Linux, UNIX, and Windows (DB2 for LUW) database so that optimum performance is achieved? is a question that s frequently asked by EMC customers who are looking to deploy a DB2 for LUW database on an EMC Symmetrix VMAX or VNX series storage array. And while IBM offers some basic guidelines for deploying DB2 for LUW databases in SAN and NAS environments, when it comes to provisioning storage for a DB2 for LUW database, a strong understanding of the database s performance and scalability requirements (type of workload anticipated, desired performance in terms of IOPS and throughput, projected growth rate, and so forth), coupled with knowledge about the host(s) configuration and capacity, storage platform, and network interconnect used, is essential. This is particularly true for data warehouse and decision support system (DSS) environments. This white paper presents an overview of DB2 data warehousing core components, requirements, and planning criteria, and discusses recommendations on ways to design a data warehouse environment that mirrors one of the most popular data warehouse solutions available today using IBM DB for LUW Data Warehouse Edition (DWE) and EMC Symmetrix VMAX and VNX series storage arrays. The designs presented here are the product of collaborative work between IBM and EMC engineers and have been utilized in customer environments; both designs have proven to deliver high performing data warehouse solutions for both IBM POWER / AIX and Intel / Linux server environments. Audience This white paper is intended for DB database administrators, engineers, field consultants, advanced services specialists, and customers who are interested in deploying a DB data warehouse on EMC Symmetrix VMAX or VNX series storage products. DB2 for Linux, UNIX, and Windows DB2 (or more formally, DATABASE 2) was introduced on MVS in 1983 and it arrived on the Personal Computer as a component of OS/2 1.3 Extended Edition (known as Database Manager ) in A year later, it emerged as a product called SQL/400 for IBM s new AS/400 server and by 1992, it had become a stand-alone product on OS/2 (named DB2/2 ). In 1993, DB2 appeared on AIX (this prompted another name change DB2/2 became DB2 for Common Servers ); in 1994, new editions of DB2 were introduced on HP-UX and Solaris; and in 1999, a version of DB2 became available for Linux. Along the way, the name changed yet again and DB2 for Common Servers became DB2 Universal Database. DB for Linux, UNIX, and Windows is the latest release of IBM s data management software for distributed systems (with the version 9 release, the 5

6 Universal Database moniker was replaced with the predominant operating systems that DB2 runs on), and like previous versions, DB runs on a wide variety of platforms AIX, HP-UX, Linux (RedHat and SUSE), Solaris, Windows, i5/os, and z/os. Several editions of DB2 are available and each has been designed to meet a specific business need. DB2 Data Warehouse Edition (DWE) is IBM s top-of-line edition for dynamic data warehousing. DWE is designed for today's data center environments where On-Line Transaction Processing (OLTP) and decision support are merged into integrated information management systems. This integrated platform for developing warehouse-based analytics includes core components for warehouse construction and administration as well as Web-based applications with embedded data mining and multi-dimensional Online Analytical Processing (OLAP). The core engine for DB2 Data Warehouse Edition consists of DB2 Enterprise Server Edition and the DB2 Data Partitioning Feature (DPF). DB2 Enterprise Server Edition includes data warehouse enhancing features such as materialized query tables, the starburst optimizer, and multidimensional clusters. The DB2 Database Partitioning Feature (DPF) provides increased parallelism to aid in managing very large databases by dividing them into multiple partitions and storing those partitions across a cluster of multiple, inexpensive servers. DPF processes complex queries more efficiently, giving better performance with smaller systems while providing scalability to support very large databases and complex workloads. DPF can also improve data availability by reducing both the time required to perform and the overall impact of standard maintenance activities (such as backup and recovery operations). Data warehouses an overview An increasing amount of information is available to businesses regarding their customers, products, sales channels, inventory, and so forth. More and more businesses are performing analytics on this data to help them make quick decisions and improve their business agility by analyzing data they already have on hand, businesses can move from reacting to challenges to predicting trends and outcomes, thus serving their customers better. Starting with standard reports and ending with predictive modeling, businesses can achieve the productivity, growth and infrastructure needed to make decisions that will result in the best business outcomes. The way in which data flows in a typical Business Intelligence (BI) database environment can be seen in Figure 1. Operational data normally arrives from transactional databases as well as other sources (both internal and external). This data is then cleansed and transformed to fit a well-defined data model through some type of ETL (extract, transform, and load) solution. The cleansed data is then fed into a data warehouse, which typically is built on a relational database management system (RDBMS). Various services can be run on top of the data warehouse providing the reporting and analytics capabilities needed in a typical BI environment. 6

7 Figure 1. Data flow in a typical business intelligence database environment A data warehouse is a key tool in such a business intelligence solution, enabling enterprises to bring together data from various transactional systems into one location, and allowing business managers to query the efficiency and performance of their businesses as well as glean answers to questions like: Which of our customers are the most profitable? Where do the most profitable customers live, in relation to the stores they frequent? Which product lines are most profitable? Is there a correlation between product placement in stores and sales volume? What has been the effectiveness of previous marketing campaigns? DB2 s parallel database technology (aforementioned DB2 with DPF) provides a highly scalable and performant platform for hosting typical data warehousing workloads. Such workloads are often comprised of ad-hoc queries that are used to check on the health of the business, to create projections for what-if scenarios, and to produce a variety of standard reports. The queries coming to the data warehouse environment may be generated by a standard OLAP facility, such as Cognos, or a data mining environment, such as SAS or SPSS. Data may come into the data warehouse by way of Load or data ingest operations that are triggered by an ETL (extract, transform, and load) tool, such as Informatica or IBM Information Server. A Modular Approach to Data Warehouse Architecture DB2 s parallel database engine (DPF) allows for a data warehouse architecture to be defined in a very scalable fashion. A typical architecture would be built from several 7

8 different building blocks known as modules. These modules provide specific functionality in the data warehouse solution. At a minimum, a good data warehouse solution will consist of the following four modules: A management module A user/administration module A data module A failover module Certain modules are mandatory and others are optional, depending on the quantity of data you have, your concurrency needs, and the analytics software you require; the idea is to start with the required basic modules and add new modules as your business grows and as system requirements increase. The Management module The management module contains one management node that provides the management functionality for all other modules. The management node is a server that is used to automate the process of building the other servers at installation time. It also houses management software such as Optim Performance Manager. User modules Each user module contains one administration node; and while at least one user module is required, multiple user modules can exist. (Administration nodes, apart from the first one, are often called user nodes.) In a DB2 for LUW data warehouse environment, the first administration node hosts a single database partition that houses the system catalog for the core warehouse database, along with any nonpartitioned data that belongs to the core warehouse database. It also acts as a coordinator for user connections. Additional user nodes can store non-partitioned data and act as a coordinator for user connections, but unlike the first administration node, they do not contain system catalog tables (a SYSCATSPACE table space). Additional user nodes are not required, but when provided, they can act as DB2 coordinator nodes by helping to balance database connections. For example, user connections can be routed to a second user node allowing the administration node to focus solely on application requests. Data modules As the name implies, the data module is where the data warehouse data is stored, and at least one data module is required. Each data module includes one data node that hosts multiple (typically four or eight) database partitions. Data modules are the main workhorse for the warehouse environment. This is where a bulk of the work towards any queries and updates happen; this is where data is scanned, joined, and shared between various data modules, before a final response to a query is sent to the coordinator of the query (which runs on one or more user modules). 8

9 In a data warehouse environment, as the amount of data grows, a database administrator can grow the data warehouse cluster by adding additional data modules. Failover modules A failover module is configured as a high availability module that is similar to a data module, but that has no storage disks assigned to it. The failover module sits in standby mode and acts as a substitute for any failing administration, user, or data modules within its high availability group. The failover module needs to have access to the storage of the modules it is providing a standby for, and this access is typically provided via a SAN setup. In a DB2 for LUW data warehouse environment, Tivoli Systems Automation for Multiplatforms can constantly monitor DB2 resources (hardware and software) and automatically substitute a failing module with the failover module to restore normal system operation. The failover process takes place in just a few minutes; however, all uncommitted database operations are rolled back and will need to be resubmitted. IBM recommends the use of one failover module for every group of four modules used a group of four modules can be comprised of one administration module and three data modules, or they can consist of four data modules. Expanding a modular data warehouse The modular architecture for a DB2 DPF solution provides flexibility in expanding a system as the business grows. For example, you can easily add data modules to the existing system when the data volume increases. Or, you can add additional user modules to manage a large number of users and to balance the data access load. Data warehouses and storage usage The storage design for data warehousing workloads must take into account the stringent storage I/O demands that are often posed by the diversity of complex queries that scan large tables, perform joins between these large tables resulting in sort (and other) overflows to temporary table spaces, as well as constant insert and delete activity that is typical of an active data warehouse environment. In addition, storage designers must be able to ensure that a fast and smooth recovery is possible in the event a catastrophic failure occurs, requiring a need to deliver a high availability design as well as disaster recovery options. In a data warehousing solution that is built with DB2 DPF, data is partitioned amongst logical constructs known as logical data partitions (LDPs). Consequently, each LDP has its own share of data (a hashing algorithm is used to distribute data across each LDP used, so all LDPs have roughly the same amount of data). Each LDP also has its own CPU, memory, and I/O resources. When a query is submitted for execution, all LDPs participate in processing the query in parallel, resulting in high performance and scalability of the database engine. 9

10 The storage design for a data warehousing solution that is built on DB2 DPF typically has the following key requirements: The storage system has to deliver equal performance to all of the DB2 logical data partitions. I/O requirements typically have a high read to write ratio. Quite often, the sequential bandwidth requirements are very high, and therefore must be factored into the storage system configuration. The storage system has to provide the ability to access all storage within a group of active servers via a SAN configuration. (Increasingly customers are building their solutions to be highly available; a data warehouse solution using DB2 DPF delivers this capability via the use of standby servers.) DB2 DPF data warehouses that utilize EMC storage The following sections show the results of collaborative work between IBM and EMC engineers to define highly-performant storage systems design for a DB2 DPF data warehousing solution in both an IBM POWER / AIX and an Intel / Linux based environment. These designs have since been deployed at several customer sites, and have proven to deliver the stringent requirements of today's high-end data warehousing solutions. IBM Power / AIX Many DB2 DPF data warehouse environments rely on IBM POWER processors for mission critical performance and reliability, to support complex workloads for large numbers of concurrent users. A typical DB2 DPF data warehouse built on IBM Power Servers has the following configuration: two data modules, one management module, one user/administration module, and one failover module. These components and their relationship with EMC Symmetrix storage is depicted in Figure 2. 10

11 Figure 2. A simple DB2 DPF data warehouse environment built on IBM POWER servers and an EMC Symmetrix VMAX 40K storage array In this environment, each module uses an IBM Power 740 as a standard compute server each Power 740 server has: 16 CPU 3.55 GHz 128 GB of DRAM One 800 GB Solid-State Disk (SSD) drive The storage consists of an EMC Symmetric VMAX 40K; this Symmetrix VMAX 40K is comprised of: 8 engines 288 data disks (300 GB, 15K rpm, Fibre Channel drives) 32 hot spare disks (300 GB, 15K rpm, Fibre Channel drives) Note: Not all configurations require an 8 engine Symmetrix VMAX 40K; smaller data warehouses can be constructed on 1 and 2 engine Symmetrix VMAX 40K storage arrays. 11

12 In a typical DB2 DPF environment, each database partition resides on its own physical workstation (or logical partition), and has its own processor, memory, and disks. This is referred to as a shared-nothing environment since memory and storage are not shared between partitions. Instead, partitions are connected to each other by a communications facility known as the fast communications manager or FCM. As shown in Figure 2, redundant Ethernet switches provide connectivity for the FCM, which links each module together; redundant SAN switches connect each Power 740 to the Symmetrix VMAX 40K storage array. Because a DB2 DPF data warehouse is a shared-nothing environment, the storage allocated for each data module must be completely isolated from all other modules, with the exception of the failover module, which sits in standby mode and has no storage assigned to it. Similarly, the storage needed for the user module/administration node must be completely isolated from the storage that is allocated for each data module. To facilitate this, the Symmetrix VMAX 40K storage array is provisioned in sets of physical drives, called RAIDSETS; these RAIDSETS are then presented to the AIX Servers as StorageGroups of RAID 5 (3+1) protected disks. (AIX views these StorageGroups as hdisks.) Each data module has eight logical data partitions (LDPs) and four RAIDSETS are used to store the data associated with a single LDP. In addition, two LDPs are distributed across a single Symmetrix VMAX 40K engine. In contrast, eight RAIDSETS are used to store the data associated with the user module/administration node and the workload for this module is distributed across all eight engines in the Symmetrix VMAX 40K used. Linux DB2 DPF data warehouse environments built on IBM System x hardware are frequently used by medium to large companies that need powerful analytics capabilities and growth flexibility at an exceptional price-to-performance ratio. Customers have typically used RedHat or SUSE Linux as the operating system for these configurations. As with DB2 DPF data warehouse environments built on IBM Power 740 systems, similar environments that are built on System x hardware have, at a minimum, two data modules, one management module, one user/administration module, and one failover module. Such a system can be seen in Figure 3. 12

13 Figure 3. A simple DB2 DPF data warehouse environment built on IBM System x servers and EMC VNX series storage arrays In this environment, each module uses an IBM System x server that contains the following components: 6 CPU 3.46 GHz 64 GB of DRAM The storage consists of an EMC VNX 5300 series storage array that consists of 48 disks (300 GB, 15K rpm, Fibre Channel drives) and once again, redundant Ethernet switches provide connectivity for the FCM, while redundant SAN switches connect each System x server to the VNX 5300 storage array. As with any DB2 DPF data warehouse environment, the storage allocated for each data module must be completely isolated from all other modules. Similarly, the storage needed for the user module/administration node must be completely isolated from the storage that is allocated for each data module. To facilitate this, the VNX 5300 storage array is provisioned in sets of physical drives, called RAIDSETS, which are then presented to the Linux Servers as StorageGroups of RAID 6 (10+2) disks. 13

14 Each data module has four logical data partitions (LDPs) and one RAIDSET is used to store the data associated with one logical data partition. In contrast, two RAIDSETS are used to store the data associated with the user module/administration node; consequently, one VNX 5300 is dedicated to this module/node. Conclusion This paper provided an overview of how to configure a DB2 for LUW data warehousing environment that utilizes EMC storage. The solutions presented are based upon years of experience using DB2 for LUW to build a powerful data warehousing solution with powerful analytics capability. A blueprint for an IBM Power-based hardware as well as an Intel-based solution was provided; both were based on popular customer scenarios, detailing the most commonly deployed configurations. Proof-of-concept testing with customer workloads has shown that these configurations work well together, DB2 DPF databases deployed on EMC storage deliver extremely good performance and reliability characteristics. References 1. Wikipedia entry for data warehouse 2. Up and Running with DB2 UDB ESE: Partitioning for Performance in an e-business Intelligence World 3. Database Partitioning, Table Partitioning, and MDC for DB IBM Smart Analytics System 5. Deploying DB2 for Linux, UNIX, and Windows Databases on EMC Symmetrix Arrays deploy-db2-linux-unix-windows-symmetrix-dmx-tb.pdf 14