Implementing IBM DB2 on Linux with IBM Storwize V7000 Unified system

Transcription

1 Implementing IBM DB2 on Linux with IBM Storwize V7000 Unified system Reference guide for DB2 database and storage administrators Shashank Shingornikar IBM Systems and Technology Group ISV Enablement Mayur Shetty IBM Systems and Technology Group ISV Enablement for Storwize V7000 March 2012 Copyright IBM Corporation, 2012.

2 Table of content Abstract... 1 Intended audience... 1 Scope... 1 Introduction to IBM Storwize V7000 Unified system... 1 IBM Storwize V7000 Unified overview... 2 IBM Storwize V7000 functionalities... 3 IBM Storwize V7000 terminology... 4 Benefits of IBM DB2 deployment on the IBM Storwize V7000 Unified system... 6 IBM DB2 introduction... 7 Planning DB2 databases on an IBM V7000 Unified system... 8 Preparing the Storwize V7000 Unified system for DB2 deployment... 9 NFS-based deployment of DB2 database... 9 Creating NFS shares (using GUI)... 9 Block-based deployment of DB2 database IBM Storwize V7000 configuration SAN configuration planning Storwize V7000 overview Storage pool configuration MDisk configuration Volume configuration Mapping volumes to the host Prerequisites on the Linux host Installation requirements for DB DB2 software installation Storing data on Storwize V7000 Unified system shares Mounting the Storwize V7000 Unified system NFS share Using specific mount options on Linux hosts Mounting the Storwize V7000 Unified system block storage Updating the DB2 instance configuration file Creating the database Migrating existing DB2 databases Migrating DB2 databases using redirected restore Migrating the DB2 databases using the db2look and db2move utilities Database backup and restore Creating an offline backup Backing up to named pipes Lab setup Storwize V Host nodes Test scenarios and test tools... 39

3 Summary Acknowledgements Resources About the authors Trademarks and special notices... 43

4 Abstract This paper explores the use of IBM Storwize V7000 Unified storage product as an essential component of the IBM DB2 infrastructure solution. The paper demonstrates practical implementation of the IBM DB2 v9.7 database on Red Hat Enterprise Linux (RHEL) operating environment through network-attached storage (NAS) services using Network File System (NFS) protocol or using block storage provided by the Storwize V7000 Unified storage system. Intended audience This technical report is intended for: Scope Customers and prospects looking to implement effective database solution on the IBM Storwize V7000 Unified system using the IBM DB2 software. Administrators and management seeking detailed information to implement the IBM DB2 solution on the IBM Storwize V7000 Unified system. This technical report provides: Detailed instructions for the implementation of DB2 database (for Linux ) on IBM Storwize V7000 Unified system by using both NFS and block storage. This technical report does not: Discuss any performance impact and analysis from a user perspective. Replace any official manuals and documents from IBM on Storwize V7000 or IBM DB2. Introduction to IBM Storwize V7000 Unified system The IBM Storwize V7000 solution provides a modular storage system that includes the capability to virtualize external storage area network (SAN) attached storage as well as its own internal storage. IBM Storwize V7000 provides a number of preset configuration options that are aimed at simplifying the implementation process. It also provides an active-active solution, and is a clustered, scalable, midrange storage, as well as an external virtualization device. Included with IBM Storwize V7000 is a simple and easy-to-use graphical user interface (GUI) that allows storage to be deployed quickly and efficiently. The GUI runs on the IBM Storwize V7000 system and therefore, there is no need for a separate console. The IBM Storwize V7000 solution consists of a control enclosure which includes the chassis, node canisters, drives, and energy sources that include batteries, and expansion enclosures which is a hardware unit that includes expansion canisters, drives, and energy sources that do not include batteries. Within each enclosure are two canisters which are the hardware units that include the node hardware, fabric and service interfaces, and serial-attached SCSI (SAS) expansion ports, determining the role of the enclosure. 1

5 IBM Storwize V7000 Unified overview IBM Storwize V7000 Unified system, when attached to a customer s Internet Protocol (IP) network, serves files using the industry-standard protocols, such as NFS, Common Internet File System (CIFS), File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), and Hypertext Transfer Protocol Secure (HTTPS). At the same time, the Storwize V7000 Unified system offers block devices by means of storage logical unit number (LUN) which can be mapped to host using Fibre Channel (FC) or using Internet Small Computer System Interface (iscsi). Figure 1: IBM Storwize V7000 Unified System As shown in Figure 1, the unique architecture of the IBM Storwize V7000 Unified system offers greater flexibility and high availability when compared to traditional NAS or FC solutions. For more information about the IBM Storwize V7000 Unified system, refer to the URL: ibm.com/systems/storage/disk/storwize_v7000/specifications.html 2

6 IBM Storwize V7000 functionalities The following functionalities are available with the IBM Storwize V7000 system. Thin provisioning: With thin provisioning, applications can grow dynamically, but consume only the space that they are actually using. Without thin provisioning, preallocated space is reserved, irrespective of whether the application uses it or not. Volume Mirroring: Volume Mirroring provides a single volume image to the attached host systems while maintaining pointers to two copies of data in separate storage pools. Copies can be on completely separate disk storage systems that are being virtualized. IBM Tivoli Storage FlashCopy Manager: FlashCopy creates instant application copies that can be used for backup or application testing. FlashCopy makes better use of the space with incremental copy, where only changed blocks are copied. Metro Mirror: Metro Mirror provides synchronous remote mirroring function up to approximately 300 km between sites. As the host I/O completes only after the data is cached at both the locations, performance requirements might limit the practical distance. Metro Mirror is designed to provide fully-synchronized copies at both the sites with zero data loss after the initial copy is completed. Global Mirror: Global Mirror provides long distance asynchronous remote mirroring function up to approximately 8,000 km between sites. With Global Mirror, the host I/O completes locally, and the changed data is sent to the remote site later. This is designed to maintain a consistent, recoverable copy of data at the remote site which lags behind the local site. Data migration: A data migration wizard can be used to import external storage system into the IBM Storwize V7000 system. IBM System Storage Easy Tier : Easy Tier provides a mechanism to seamlessly migrate hot spots to a higher performing storage pool within the IBM Storwize V7000 solution. Migration can be to internal drives within the IBM Storwize V7000 system or to external storage systems that are virtualized by the IBM Storwize V7000 system. 3

7 Figure 2: Storwize V7000 Unified system virtualizing external and internal storage IBM Storwize V7000 terminology Table 1 lists the Storwize V7000 terminology used in the paper. For an entire list of the Storwize V7000 terminology, refer to IBM Storwize V7000 Introduction and Implementation Guide at: ibm.com/redbooks/redpieces/abstracts/sg html?open 4

8 IBM Storwize V7000 term Control enclosure Expansion enclosure Node canister Host mapping Internal storage Managed disk (MDisk) Storage pool Thin provisioning or thin provisioned Volume Extent Definition A hardware unit that includes the chassis, node canisters, drives, and energy sources including batteries. A hardware unit that includes expansion canisters, drives, and energy sources that do not include batteries. A hardware unit that includes the node hardware, fabric and service interfaces, and SAS expansion ports. A controlling process in which hosts have access to only specific volumes within a cluster. Array-managed disks and drives that are held in enclosures and nodes that are part of the cluster. A component of a storage pool that is managed by a cluster. An MDisk is either a part of a Redundant Array of Independent Disks (RAID) array of internal storage or a SCSI logical unit (LU) for external storage. An MDisk is not visible to a host system on the SAN. A collection of storage capacity that provides the capacity requirements for a volume. The ability to define a storage unit (full system, storage pool, or volume) with a logical capacity size that is larger than the physical capacity assigned to that storage unit. A discrete unit of storage on disk, tape, or other data recording medium that supports some form of identifier and parameter list, such as a volume label or I/O control. Each MDisk is divided into segments of equal size called extents. When a volume is created from a storage pool, the volume is allocated based on the number of extents required to satisfy the capacity requirements for the volume. Table 1: IBM Storwize V7000 Unified system terminology 5

9 Benefits of IBM DB2 deployment on the IBM Storwize V7000 Unified system IBM Storwize V7000 Unified system provides greater flexibility for deploying database solution through its architecture. Customers can use the file protocol (NFS) or block storage to deploy database environments. Both the file and block storages can be used on the same database host. Table 2 gives a summary of deployment benefits of IBM DB2 on the IBM Storwize V7000 Unified system. Benefit Lower total cost of operation (TCO) Central management Greater flexibility Single global name space Intelligent policy engine High availability Description IBM Storwize V7000 Unified system reduces the cost for administration and maintenance by scaling capacity and performance independent of each other. IBM Storwize V7000 Unified system provides ease of use, maintenance, provisioning and implementation, and centralized management with alert and event logs through a single GUI or command-line interface (CLI). The database can be created on NFS shares or on the block device depending on application requirements. Data islands can be consolidated into a single globally-accessible network-based store alongside block databases store. Intelligent policy engine and tiered storage are built into each IBM Storwize V7000 Unified system. Automatic striping of file system allows the use of all available storage based on user-defined file system policies. IBM Storwize V7000 Unified system, with its unique robust architecture is able to provide the high-availability feature without any additional changes or setup Table 2: DB2 deployment benefits on the IBM Storwize V7000 Unified system 6

10 IBM DB2 introduction The IBM DB2 database software offers industry-leading performance, scalability, and reliability on a variety of platforms from Linux, UNIX, and Microsoft Windows to IBM z/os. Some of the following features explain the benefits of using the IBM DB2 data management system. Autonomics: DB2 includes numerous autonomic features, such as the self-tuning memory manager that relieves database administrators from many common administration tasks. As a result, database administrators can spend less time administering the system and more time focusing on other activities that benefit the business. Deep compression: DB2 can dramatically reduce storage cost with industry-leading data compression technologies that compress rows, indexes, temporary tables, line of businesses (LOBs), XML, and backup data with compression rates that can reach over 80%. Moreover, as compression allows DB2 to keep more data in memory, thereby avoiding performance-robbing disk I/O, database performance can increase considerably. Performance: DB2 has dominated key performance benchmarks many times over the years, including both online transaction processing (OLTP) and online analytical processing (OLAP) benchmarks. These world-class performance means for businesses running DB is that they can do more work with their existing hardware, thereby avoiding or delaying costly server upgrades. Scalability: IBM DB2 purescale uses a cluster-based, shared-disk architecture to offer easy scalability and high availability. DB2 purescale avoids many of the drawbacks of cluster-based shared-disk solutions from other vendors. Other solutions incur cluster restrictions that limit their ability to scale beyond a few nodes, while DB2 purescale grows with near-linear efficiency. Other solutions take minutes to resume processing after a node failure, while DB2 purescale continues to operate without performance degradation. Adding servers to other solutions requires complex tuning and updates to application code, while DB2 purescale allows you to scale the database without tuning the system and requires minimal changes to application code. DB2 purescale is not available for NFS file systems. Security: DB2 offers a comprehensive suite of security features that effectively and decisively minimize this threat. DB2 provides more relief with lightweight security audit mechanism that can be used to verify that there has been no unauthorized data access. IBM DB2 purexml : XML can significantly reduce the cost of developing and maintaining applications with continuously evolving input or reporting capabilities. With the breakthrough of the native XML support provided 7

11 only by DB2, the benefits of XML extend to the database and include the ability to easily evolve an XML schema in minutes to match the application changes without updating the existing table schema or the existing XML data in that table. Comprehensive tools: DB2 includes many useful tools, such as the Configuration Expert, which optimally configures DB2 to its hardware during installation. Complementing the tools included with DB2 is a broad range of IBM Data Management tools to help with all aspects of the data management lifecycle. Planning DB2 databases on an IBM V7000 Unified system This guide describes the deployment of IBM DB2 on Red Hat Enterprise Linux (RHEL) using the IBM Storwize V7000 Unified system NFS data store or using FC connectivity. The topology components include IBM V7000 Unified system, IBM xseries servers, and IBM DB2. Figure 3 provides a pictorial representation of the setup created in the lab environment. Figure 3: Lab topology Lab setup: Two separate IBM xseries servers have been used to map storage. RHEL release 5 update 5 (RHEL 5.5) is installed on both the Linux hosts. The linux-1 (isvsonas1) host is used to mount the shares exported by the IBM Storwize V7000 Unified system using the NFS protocol. The linux-2 (isvx4) host has host bus adapter (HBA) installed and is connected to the IFS system through fiber cables. For the ease of understanding, the setup instructions are given for using on the Storwize V7000 Unified system s file protocol and block access. 8

12 Note: When creating the database, decide in advance on the storage media. It is not recommended to mix file and block storage in creating a single database. Preparing the Storwize V7000 Unified system for DB2 deployment This section describes the ways to prepare the Storwize V7000 Unified system for DB2 deployment for both, using file protocol NFS and block storage. NFS-based deployment of DB2 database This section provides the prerequisites for the creation of the DB2 database on NFS storage provided by the IBM Storwize V7000 Unified system. The NFS shares needed for the DB2 database are created as described in the following sections. Creating NFS shares (using GUI) IBM Storwize V7000 Unified system s NFS shares can be created using the GUI interface when connected through a browser or using CLI tools (such as mkexport) when connected as cliuser using PuTTY or a terminal emulator of your choice. When using the GUI, you need to provide the fully qualified domain name (FQDN). FQDN is given at the time of installation of the Storwize V7000 Unified system. You need to perform the following steps to create NFS shares using the Storwize V7000 Unified system s management console. In the lab setup, the Storwize V7000 Unified System is named ifs5.storage.tucson.ibm.com. 1. Go to the URL: 2. Log in to the console using the user ID, admin and the password that has been set at the time of the installation. Figure 4: Storwize V700 Unified system login 9

13 3. On the left-hand side, click Shares under the Files submenu to start the file share creation wizard. In the panel displayed, enter the details regarding the share name that you want to create along with the directory path. Figure 5: Storwize V7000 Unified System export wizard - step 1 4. Select the NFS type for the share and enter the values in the Path and Share name fields. Clear the Read only access, Root squash, and Secure check boxes. Figure 6: Storwize V7000 Unified System export wizard - step 2 10

14 5. Storwize V7000 Unified system now has enough information to create data01 NFS share. Click OK to create the share. Note: When creating or configuring shares for the DB2 database, leave the Root Squash check box cleared. Clearing the Root Squash check box here allows root user on the client systems to act as the root user (only) within the share path. As soon as the share is created, a confirmation indicating the success or failure information is displayed. Creating NFS shares (using CLI) File shares can also be created using the Storwize V7000 Unified system s CLI interface. In order to create shares using CLI, log in to the Storwize V7000 Unified system s integrated management node as cliuser, Syntax: mkexport <Share-Name> <Share-Path> --nfs <Client-FQDN/IP Address/*>(NFS options) Example: mkexport data01 /ibm/gpfs0/db2data01/data01 nfs *(rw,no_root_squash,insecure,anonuid=505,anongid=500) 11

15 Table 3 provides an explanation of the options used in the command. Option Share-name Share-path FQDN Description Name to be assigned to the share. Storwize V7000 Unified system or IBM General Parallel File System (IBM GPFS ) path to be exported. This command creates the path in the GPFS directory if it does not exist. FQDN option is mandatory only if both the machines (Storwize V7000 Unified system and the client) are in different domains. If the machines are in the same domain, just the short name or host name might suffice the purpose. IP addresses as well as FQDN can be used irrespective of the domain of the two machines. NFS options rw,no_root_squash,insecure,anonuid=uidn,anongid=gidn (UIDn and GIDn are DB2 user s numeric user IDs on Linux database hosts). Table 3: Storwize V7000 Unified system command-line syntax for creating NFS shares Note: After creating the shares (using the GUI or the mkexport command) they need to be mounted on the Linux database systems. Special mount options must be used for mounting these shares. Also upon mounting the shares on the client systems, permissions on the local mount directory must be changed to DB2 instance owner and group, in case anonuid and anongid options are not used. Block-based deployment of DB2 database Figure 7 provides a simple explanation of the block storage configuration. The figure shows the RAID setup at the Storwize V7000 Unified system and the mapping of the DB2 volume group to the Linux host using multiple controllers. 12

16 Figure 7: Block-based configuration The following section explains how the Easy Tier configuration is done at the Storwize V7000 Unified systems in order to achieve the lab setup. 13

17 IBM Storwize V7000 configuration This section explains the configuration of various components that were involved in testing. It includes: SAN configuration, MDisks configuration, storage pools, volumes, and hosts. SAN configuration planning For the best practices on SAN configuration planning, refer to the IBM Storwize V7000 Introduction and Implementation Guide from IBM Redbooks. Storwize V7000 overview In the Storwize V7000 system, the internal drives cannot be directly added to storage pools. They need to be included in a RAID to provide protection against the failure of individual drives. A RAID array is created as an MDisk, and during the array creation, wizards and presets are available to suggest configurations to users based on the hardware attached to the system. The recommendation is to use these presets for easy configuration and best performance. The following content shows how to create arrays on the system using the GUI. The Storwize V7000 CLI might not be needed though it is flexible in most cases. When you first set up the Storwize V7000 system, the initial setup wizard prompts the user to use the fullyautomated RAID setup. Now, start from the Getting Started page on the GUI, as shown in Figure 8. Figure 8: Getting started with the storage configuration 14

18 Figure 9 shows the internal drives with an Online status before the MDisk configuration. Figure 9: Internal drives configuration Storage pool configuration This section explains how to create a storage pool on the system using the GUI. The Storwize V7000 CLI might not be needed though it is flexible in most cases. Perform the following steps to create a storage pool on the system using the GUI. 1. On the Storwize V7000 GUI, click Pools, which is the third icon from the top. Then click MDisks by Pools. 15

19 Figure 10: Storwize pools configuration 2. Next, click New Pool on the GUI, and in the pop-up window that is displayed, enter StoragePool_DB2_FC as the name of the new storage pool that will be used for the block storage testing, and then click Next. Figure 11: Creating a storage pool 3. A page (as shown in Figure 12) without any MDisks created at this point is displayed. Click Finish to continue with the creation of the storage pool. 16

20 Figure 12: Creating a storage pool MDisk configuration You can choose to use the recommended (fully-automatic) configuration or a different configuration for customization. (Refer to Figure 13). In this example, a different configuration has been used. In this step, first select the drive class. The GUI then provides a preset list based on the drive class. You can decide whether to configure spares automatically, and optimize the array for performance or capacity. You can also indicate the number of drives to be provisioned. The configuration summary at the bottom of the page (in Figure 14) displays information about what the system will attempt to do, or indicates that it cannot meet the RAID creation requirement. 17

21 The team configured the internal SAS drives, and chose the preset of RAID-5. In this example, the team used 21 drives, optimized for a capacity to create three RAID-5 arrays. Figure 13: Configuring internal storage step 1 With the Optimize for Performance option selected, all arrays in a pool will have the same performance characteristics, and potentially leave unused drives in the system. The Optimize for Capacity option uses all the drives in the system, which means that some of the arrays might not meet the array width goals. It will do this by reducing the number of drives in one or more arrays to be created by an equal amount, and you will get an optimal performance layout (all arrays have the same width, or a width with one drive more or one drive less, but the width will not be the same as the width goal). Note: If the perfect number of drives exists, the Optimize for Capacity option creates the same layout as the Optimize for Performance option. Both the algorithms are explained in the IBM Redbooks, Implementing the IBM Storwize V7000 at: ibm.com/redbooks/redpieces/abstracts/sg html?open Next, you need to decide whether to expand an exiting pool or create one or more new pools with the arrays. In this example, a new pool dedicated for internal storage has been created. 18

22 Figure 14: Configure internal storage step 2 Next, you need to decide whether to expand an exiting pool or create one or more new pools with the arrays. In this example, the test team added the new MDisks to the StoragePool_DB2_FC storage pool that they created earlier. 19

23 Figure 15: Configure internal storage step 3 Now, you will see the new storage pool creation progress and the command-line result, if the Details option is turned on (as shown in Figure 16). Figure 16: Details of the RAID arrays creation 20

24 Figure 17 shows that the new MDisks: mdisk9, mdisk10, and mdisk11 are now part of the StoragePool_DB2_FC storage pool. Figure 17: Mdisks overview by storage pool Next, the test team created another RAID-5 array, as shown in Figure 18. Figure 18: Creating another Mdisk 21

25 The team then added this to the existing StoragePool_DB2_NFS storage pool, as shown in Figure 19. Figure 19: Adding the Mdisk to the existing storage pool Figure 20 shows the actual command that is run to create the RAID-5 array and add it to the StoragePool_DB2_NFS storage pool. Figure 20: Actual command that runs in the background 22

26 On the Pools page, you can notice that a new StoragePool_DB2_NFS pool has been created, and it has three members mdisk12, mdisk13, and mdisk14, all having an Online status (as shown in Figure 21). Figure 21: Storage pools and array's status You have now completed managing the internal HDDs. Volume configuration A volume is a logical disk that is presented to a host system by the IBM Storwize V7000 system. The IBM Storwize V7000 storage system translates this volume into a number of extents which are allocated across the MDisks present in the storage pool. Figure 22: Volume configuration step 1 23

27 Select the StoragePool_DB2_FC storage pool from which you want to create the new volumes. On the left pane, click Volumes by Pool and then click New Volume to launch the New Volume wizard (as shown in the Figure 23). Then select the storage pool from which you want to create volumes. Figure 23: Volume configuration step 2 Figure 24: Volume configuration step 3 24

28 Figure 25 shows detailed messages that are displayed when you click Create and Map to Host in the new volume creation wizard. Figure 25: Background command to create the volumes Mapping volumes to the host A host system is connected to the Storwize V7000 system either through a FC connection or an iscsi connection. For this paper, the team used FC to connect host to the IBM Storwize V7000 system. Hosts are defined to IBM Storwize V7000 by identifying their worldwide port numbers (WWPNs) for FC hosts. After viewing the details, when you click Continue, the Modify Mappings dialog box (as shown in Figure 26) is displayed. In this example, the volumes are mapped to the isvx4 host, which is selected from the list. Figure 26: Volumes mapping to host step 1 25

29 Click Next to navigate to the Modify Host Mappings page, as shown in Figure 27. Figure 27: Volumes mapping to host step 2 On clicking Map Volumes, you can see that the volumes are mapped to the host, as shown in Figure 28. Figure 28: Volumes mapping to host step 3 26

30 Figure 29 shows the one 1.0 TB volume (db2_vol01) mapped to the isvx4 host. Figure 29: Volumes overview Prerequisites on the Linux host On the node running Linux, detect and configure the new device. It is assumed here that the zoning (soft/ hard) is already in place between Storwize V7000 and the Linux host. Run the multipath command to list the logical unit numbers (LUNs) already configured on the system. isvx4 #> multipath d -l To configure the new devices that are created on the Storwize V7000 system and mapped to the sonasisvp1_db22 host, run the ls /sys/class/fc_host command. isvx4 # > ls /sys/class/fc_host The hosts returned by the ls command are then further scanned for attached scsi targets using the echo command. echo "- - -" > /sys/classes/scsi_host/hostname_returned_by_ls_command/scan The echo command scans and maps the exposed to the isvx4 host. The sample output of the multipath command after mapping the LUNs on the isvx4 host is as follows. [root@isvx4 app]# multipath -d -l mpath28 ( f) dm-2 IBM,2145 [size=500g][features=1 queue_if_no_path][hwhandler=0][rw] \_ round-robin 0 [prio=0][active] \_ 5:0:2:2 sdj 8:144 [active][undef] \_ 5:0:3:2 sdk 8:160 [active][undef] 27

31 \_ 6:0:2:2 sdl 8:176 [active][undef] \_ 6:0:3:2 sdm 8:192 [active][undef] mpath27 ( ) dm-1 IBM,2145 [size=75g][features=0][hwhandler=0][rw] \_ round-robin 0 [prio=0][active] \_ 5:0:2:1 sdc 8:32 [active][undef] \_ 5:0:3:1 sde 8:64 [active][undef] \_ 6:0:2:1 sdg 8:96 [active][undef] \_ 6:0:3:1 sdi 8:128 [active][undef] mpath26 ( ) dm-0 IBM,2145 [size=1.0t][features=1 queue_if_no_path][hwhandler=0][rw] \_ round-robin 0 [prio=0][active] \_ 5:0:2:0 sdb 8:16 [active][undef] \_ 5:0:3:0 sdd 8:48 [active][undef] \_ 6:0:2:0 sdf 8:80 [active][undef] \_ 6:0:3:0 sdh 8:112 [active][undef] 28

32 Installation requirements for DB2 9.7 Before you install the DB2 database products on the Linux operating systems, ensure that the system you choose meets the necessary operating system, hardware, software, and communications requirements. DB2 database products are available in several different editions. Some DB2 database products and features are available only on specific operating systems. Refer to the DB2 database product and packaging information at the following URL for a list of DB2 database products that are available on each operating system: r html Software considerations The following points list the software considerations. Lab setup was done using DB2 9.7 Fix Pack 4. Minimum supported operating systems RHEL 5 update 2 SUSE Linux Enterprise Server (SLES) 10 Service Pack 2 SUSE Linux Enterprise Server (SLES) 11 For latest information about supported Linux distributions, refer to the URL: ibm.com/software/data/db2/linux/validate Package requirements libaio.so.1 is required by the DB2 database server using asynchronous I/O libstdc++.so.5 is required for DB2 Net Search Extender libstdc++.so.6 is required for DB2 database servers and clients Security-enhanced Linux considerations On RHEL 5 systems, if Security-Enhanced Linux (SELinux) is enabled and in enforcing mode, the installer might fail due to SELinux restrictions. To determine if SELinux is installed and is in the enforcing mode, you can perform one of the following tasks: Check the /etc/sysconfig/selinux file. Run the sestatus command. Check the /var/log/messages file for SELinux notices. To disable SELinux, perform one of the following tasks: Set SELinux to the permissive mode by running the setenforce 0 command as a root user. Modify the /etc/sysconfig/selinux file entry to SELINUX=disabled and reboot the machine. 29

33 DB2 software installation Now that the prerequisites at the Storwize V7000 Unified system are taken care of, you can begin installing DB2. For DB2 installation, the following prerequisites must be met. Kernel parameter settings Creating required users and groups Performing installation Kernel parameter settings For Version 9.7 Fix Pack 1, if you need to manually increase certain kernel parameter settings to the enforced minimum settings for Version 9.7 Fix Pack 2 or higher fix packs, refer to Table 4 that shows those settings for each kernel parameter. Interprocess communication (IPC) kernel parameters Enforced minimum setting for v9.7 Fix Pack 1 or earlier Enforced minimum setting for v9.7 Fix Pack 2 or higher fix packs kernel.shmmni (SHMMNI) No value is enforced 256 times <RAM size in GB> kernel.shmmax (SHMMAX) kernel.shmall (SHMALL) (32-bit kernel) (64-bit kernel) No value is enforced <size of RAM in bytes> 1 2 times <size of RAM in bytes> (setting is in 4 K pages) kernel.sem (SEMMNI) times <size of RAM in GB> kernel.sem (SEMMSL) No value is enforced 250 kernel.sem (SEMMNS) No value is enforced kernel.sem (SEMOPM) No value is enforced 32 kernel.msgmni (MSGMNI) times <size of RAM in GB> kernel.msgmax (MSGMAX) ernel.msgmnb (MSGMNB) Table 4: Kernel parameter requirements for DB2 9.7 Note: 1. On 32-bit Linux operating systems, the enforced minimum setting for SHMMAX is limited to 4,294,967,295 bytes. 30

34 Creating required users and groups Three types of users and groups are required to operate DB2. Table 6 enlists the required users and groups for installation, and the following example shows the complete command line for the creation of required users and groups. User type User name Group name Instance owner db2inst1 db2iadm1 Fenced user db2fenc1 db2fadm1 Administration server user db2as db2as Table 5: Required users and groups Example of creating required users and groups groupadd g 505 db2iadm1 groupadd g 805 db2fadm1 groupadd g 1000 db2as useradd u 500 g db2iadm1 m d /home/db2inst1 db2inst1 p db2inst1 useradd u 800 g db2fadm1 m d /home/db2fenc1 db2fenc1 p db2fenc1 useradd u 1000 g db2as m d /home/db2as db2as p db2as passwd db2inst1 passwd db2fenc1 passwd db2as Table 6: Examples of creating required users and groups Note: The user and group IDs shown in the example might change depending on the environment. 31

35 Performing DB2 installation The page titles listed in Table 7 give an overview of the setup details for single instance installation. Though the installation process differs for the DB2 partitioning feature, the steps to create NFS shares or mapping of the Storwize V7000 Unified system block volumes remain the same. It is also recommended that you install the latest fix pack for the DB2 product that you have chosen to install if this is your initial installation of DB2. If you already have an existing setup of DB2 with specific fix pack level, and you want to change it to the latest fix pack level, you need to restore or perform data migration. Page title Response Comment DB2 Setup Launchpad Install now Select an option to install the necessary product DB2 Setup DB2 Enterprise Server Edition Next None Software License Agreement Accept None Select the installation type Typical MB None Select installation, response file creation or both /root/db2ese.rsp None Select the installation directory /opt/ibm/db2/v9.7 None Install IBM Tivoli System Automation for Multiplatforms (SA MP) Select user information for the DB2 Administration Server Do not install Tivoli System Automation for Multiplatforms db2as Response depends on whether the system has SA MP available on the system or not None Set up a DB2 instance Create a DB2 instance None Select partitioning options for the DB2 instance Select user information for the DB2 instance owner Single partition instance db2inst1 None None Select user information for the fenced user Prepare the DB2 tools catalog Set up notifications db2fenc1 Do not prepare the DB2 tools catalog Do not set up your DB2 server to send notifications at this time None None Summary Finish None Table 7: DB2 V9.7 installation pages and responses Largely depends on whether you have mailing configured on the system. 32

36 Storing data on Storwize V7000 Unified system shares Assuming that the DB2 setup is now successful, perform the following steps to start using the Storwize V7000 Unified system NFS shares for storing data. 1. Use specific mount options on Linix database hosts. 2. Mount the Storwize V7000 Unified systems NFS share. 3. Update the DB2 instance configuration file. 4. Create the database. Mounting the Storwize V7000 Unified system NFS share Local mount point locations must be created on the database hosts that will be used to mount the Storwize V7000 Unified system NFS shares. On mounting the NFS share, permissions must be changed on the local mount point so that the DB2 instance owner will be able to write to this mount point. You can use the following sequence of commands to achieve this. 1. mkdir -p /db2data/data{01,02} 2. mount /db2data/data01; mount /db2data/data02; or mount a t nfs ( to mount all the nfs file systems ) 3. chown R db2inst1:db2iadm1 /db2data/data* Using specific mount options on Linux hosts NFS mounts are defined in /etc/fstab. Table 8 provides an overview of the mount options. NFS mounts definition and mount options in /etc/fstab :/ibm/gpfs0/db2data/data01 /db2data/data01 nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,vers=3,timeo=600,noac :/ibm/gpfs0/db2data/data02 /db2data/data02 nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,vers=3,timeo=600,noac 0 0 Table 8: Overview of NFS shares mount options Mounting the Storwize V7000 Unified system block storage After the Storwize V7000 Unified system volumes are mapped to the database host (refer to the Mapping volumes to the host section), the DBA can use the exposed volumes (raw volumes) as is or by creating a file system on them. The creation of file system requires running the fdisk utility with root privilege to create partitions. After the partitions are available, depending on type of file system needed (for example, ext3 or ext 4), the mkfs command can be run. The created file systems can then be mounted on directories created on database host. Care must be taken to change the permission on the mounted volume so that the DB2 instance owner is able to write to the mounted volume or the mapped raw device. 33

37 In order to auto mount the file systems at boot time, the /etc/fstab configuration file needs to contain appropriate device entry and mount point details. Updating the DB2 instance configuration file The DB2 instance parameter, dftdbpath, holds the path information used by the DB2 create database command to create database objects, such as containers or table spaces. You can use the following command to change this parameter. db2 "update dbm cfg using DFTDBPATH /db2data/data01 immediate" Note: The length of the name (dftdbpath) cannot exceed 215 characters and must be a valid, absolute path name. Also, if the value of this parameter is not modified to point to the Storwize V7000 Unified system NFS share / block or raw volume, then every create database statement must include the location where the database needs to be created. Creating the database DB2 provides a utility called db2sampl, which creates a sample database. To confirm all the changes made so far for using the Storwize V7000 Unified system database share or the mounted block or raw volume, run the db2sampl utility and create the sample database. Example output of db2sampl: Creating database "SAMPLE"... Connecting to database "SAMPLE"... Creating tables and data in schema "DB2INST2"... Creating tables with XML columns and XML data in schema "DB2INST2"... 'db2sampl' processing complete. After running the db2sampl command, the following output confirms that the sample database has been successfully created on the Storwize V7000 Unified system provided NFS share. $ db2 list db directory System Database Directory Number of entries in the directory = 1 Database alias = SAMPLE Database name = SAMPLE Local database directory = /db2data/data01 Database release level = d.00 Comment = Directory entry type = Indirect Catalog database partition number = 0 Alternate server hostname = Alternate server port number = By default, when a database is first created, circular logging is used and primary log files are created in the {DBPATH}/{InstanceName}/{NodeName}/SQLnnn/SQLOGDIR/ subdirectory. 34

38 Where: DBPATH identifies the path where the database is created. InstanceName identifies the name of the database instance. NodeName identifies the number of the database node. SQLnnn identifies the number referring to the database in the instance. When there is only one database in the instance, this value is SQL0001. Migrating existing DB2 databases The migration of existing DB2 databases is also a straightforward process that uses standard DB2 commands. It can be performed using one of the following steps. Migrating DB2 database using the redirected restore operation Migrating DB2 database using the db2look and db2move utilities Migrating DB2 databases using redirected restore The pictorial flow in Figure 30 explains the simplicity in migrating an existing locally stored DB2 database to the Storwize V7000 Unified storage. The local directory, /db2data, is used as a mount point for the storage (block or file) exposed by Storwize V7000 Unified. The backup database command followed by restore database and set tablespace containers commands on a backup image obtained from the backup server seamlessly moves the DB2 database from one type of storage to another. Detailed explanation regarding backing up or restoring the DB2 database is found in the Data Recovery and High Availability Guide and References reference manuals or at the Information Center website at: publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/c html Figure 30: Using the backup and redirected restore commands 35

39 The following example output shows the backup and restore of a database named, pmagdb. db2 connect to pmagdb db2 list tablespaces > tablespaces.lst db2 force application all db2 backup database pmagdb to /backup/pmagdb db2 restore database pmagdb from /backup/pmagdb to /db2data/pmagdb into pmagdb redirect without prompting >restore.log db2 set tablespace containsers for 0 using (path /db2data/pmagdb/catalog ) db2 set tablespace containsers for 1 using (path /db2data/pmagdb/temp ) db2 set tablespace containsers for 2 using (path /db2data/pmagdb/data01 ) db2 set tablespace containsers for 3 using (path /db2data/pmagdb/data02 ) db2 set tablespace containsers for 4 using (path /db2data/pmagdb/index01 ) db2 set tablespace containsers for 5 using (path /db2data/pmagdb/index02 ) db2 restore db pmagdb continue Migrating the DB2 databases using the db2look and db2move utilities The migration of the DB2 database done using the backup or restore operation (as described in the Migrating DB2 databases using redirected restore section) does not allow you to change the table space type from system-managed space (SMS) to database-managed space (DMS) or from DMS to SMS. For such migrations, the table space must be created beforehand and the data is then imported using the DB2 import command or by using the db2move utility. The dbo2move utility queries the system catalog tables for the specified database and compiles a list of all user tables found. It then exports the contents and the structure of each table found to a PC / IXF formatted file. These sets of files produced can be used to populate a new DB2 database to complete migration tasks. For more comprehensive example of how to perform such migrations, visit the website: publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/c html Perform the following steps to migrate data using the db2move command: It is assumed that you already have a database called pmagdb. 1. Close all the connections and restart the DB2 instance by running the following command: db2 force application all 2. Create a Data Definition Language (DDL) file by running the following command: db2look d pmagdb e o pmagdb_ddl.sql 3. Export the table data in PC / IXF format by running following command: db2move PMAGDB export 4. Use the Create database PMAGDB on /db2data command to create a new database, establish a connection to it by using the DB2 connect to pmagdb command, and run the modified DDL file generated in step 2 to create the database objects. 5. Import the data back to the newly-created database by running the following command: db2move pmagdb import 36

40 Database backup and restore The simplest form of the DB2 backup database command requires only the name of the database to create a backup. By default, the backup is created in the current directory from where the command was run. A backup image is generated with file mode 0600 and the recovery history file is updated with the summary information. On all operating systems, file names for backup images created on the disk consist of a concatenation of several elements, separated by period. When calling the BACKUP DATABASE or RESTORE DATABASE commands, you can specify that you want to use the IBM Tivoli Storage Manager product to manage database or table space backup or restore operation. The minimum required client API version for 64-bit Linux on AMD Opteron systems, is or higher. For more information on configuring the Tivoli Storage Manager client, visit: ml Example backup database: db2 backup database pmagdb The backup command generates a file with the following format: DB_alias.Type.Inst_name.NODEnnnn.CATnnnn.timestamp.Seq_num Creating an offline backup For an offline backup when the database has been activated using the activate database command, it must be deactivated first. The following steps are the commands for deactivating the SAMPLE database. 1. Db2 connect to SAMPLE 2. Db2 quiesce database immediate force connections; 3. Db2 unquiesce database; 4. Db2 terminate 5. Db2 deactivate database SAMPLE Backing up to named pipes DB2 support is also available for database backup to (and database restore from) local named pipes on UNIX-based systems. Both the users, reading and writing from the named pipe, must be on the same system. The pipe must exist and be located on a local file system. As the named pipe is treated as a local device, there is no need to specify that the target is a named pipe. Perform the following steps to create a database backup using named pipes. 1. Create a named pipe. mkfifo /db2data/backup-pipe 2. If this backup image is going to be used by the restore utility, the restore operation must be invoked before the backup operation, and as a result you can prevent data loss. db2 restore db PMAGDB into NWPMAGDB from /db2data/backup-pipe 37

41 3. Use the pipe as the target for database backup operation. db2 backup db sample to /db2data/backup-pipe You can find more details regarding various backup and restore utilities in the Data Recovery and High Availability Guide and Reference DB2 documentation at: publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.ha.doc/doc/t html 38

42 Lab setup The lab environment under which this setup was tested had the following configuration and the tests validated the setup that the team created using the configuration mentioned in this section. However, when creating the setup for production environment, depending on the number of database instances that run on the system, the hardware configuration of the system must be validated. Storwize V7000 The following table lists the Storwize V7000 configuration used in the exercise. Storage name ifs5isv.storage Node model Storwize V7000 Micro code level Table 9: Storwize V7000 Unified system details Host nodes The following table lists the LINUX host configuration that was used in the NFS exercise. Server type Processor Memory Operating system Table 10: Linux NFS hosts details IBM xseries Intel Xeon processor 24 GB Red Hat Enterprise Linux 5.4 (Tikanga) The following table lists the Linux host configuration that was used in the block exercise. Server type Processor Memory Operating system Table 11: Linux FC hosts details Test scenarios and test tools IBM xseries Intel Xeon processor 32 GB Red Hat Enterprise Linux 5.4 (Tikanga) The primary objective is to test the interoperability and robustness of Storwize V7000 Unified as NAS and block storage device with IBM DB2. The testing objectives are focused on high availability and redundant architecture of the IBM Storwize V7000 Unified system. IBM DB2 lab has developed a tool for stress testing DB2. Same tool has been used for interoperability testing and stress testing IBM DB2 on the IBM Storwize V7000 Unified system. 39

43 Summary This paper has described the implementation of the IBM DB2 database using the IBM Storwize V7000 Unified storage. The planning section lists the various components, their compatible versions, and the recommended steps for ease of planning and deployment. It is recommended that you review the information about IBM DB2 and Storwize V7000 Unified system at the web links included in the Resources section. The tests show that the Storwize V7000 Unified system, with its robust architecture can support the demanding high availability, scalable computing and storage requirements of an enterprise-level DB2 database. 40

44 Acknowledgements This paper could not have been completed without the valuable suggestions and validation efforts from DB2 Toronto team and the Storwize V7000 team. Jeremy Brumer from IBM DB2 Toronto lab has given his invaluable contribution in setting up the test tool. Special thanks to Mayur Shetty for his efforts in setting up the block storage configuration on the Storwize V7000 Unified system and co-authoring the block configuration setup in this white paper. 41

45 Resources The following websites provide useful references to supplement the information contained in this paper: IBM Systems on PartnerWorld ibm.com/partnerworld/systems IBM DB2 information link IBM Redbooks ibm.com/redbooks IBM Publications Center About the authors Shashank Shingornikar is a senior software engineer in the IBM Systems and Technology Group ISV Enablement Organization. He has more than 10 years of experience working with DBMS technologies, involved in high-availability areas. You can reach Shashank at shashank.shingornikar@in.ibm.com. Mayur Shetty is a senior software engineer in the IBM Systems and Technology Group ISV Enablement Organization for Storwize V7000. He has more than 10 years of experience working with Storwize V7000 technologies. You can reach Mayur at mayur.shetty@us.ibm.com. 42