How To
Summary
Information for installing and setting up Manhattan (WMi, PKMS) on IBM i in a Db2 Mirror high availability environment. Includes notes on what objects or files require special handling as well as usage scenarios for Manhattan with IBM Db2 Mirror for i.
Objective
IBM i Db2 Mirror and Manhattan WMi
Beginning with IBM i 7.4 Db2 Mirror provides a new continuous availability solution. Db2 Mirror provides technology that can be leveraged by your mission-critical applications to achieve a recovery time objective (RTO) of nearly zero.
Beginning with IBM i 7.4 Db2 Mirror provides a new continuous availability solution. Db2 Mirror provides technology that can be leveraged by your mission-critical applications to achieve a recovery time objective (RTO) of nearly zero.
What Is Db2 Mirror
Db2 Mirror for i synchronously mirrors database updates between two separate nodes, allowing both nodes full access to data at the same time (read, write, update, delete). Db2 Mirror supports applications using either traditional record-level access or SQL based database access. Client applications using JDBC / ODBC as well as traditional 5250 applications are supported, along with databases residing in either the system ASP (SYSBAS) or as part of an Independent ASP (IASP).
Deployment of Db2 Mirror applications allow for both an active-active deployment model or active-passive model (read only access on the secondary node). The packaging of Db2 Mirror is a new IBM i licensed program (5770DBM) and support included in IBM i 7.4 and later. The synchronous database access is enabled via remote direct memory access (RDMA) over Converged Ethernet (RoCE) network and requires IBM POWER8, POWER9 or POWER10 systems with supported RoCE network cards. Support for encryption via the RoCE network cards is also available.
The following links are a good introduction as well as details on requirements, setting up, and managing Db2 Mirror in general:
- IBM Db2 Mirror for i – Overview
https://www.ibm.com/products/db2mirroribmi - Db2 Mirror – IBM Docs
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_75/db2mi/db2mintro.htm - IBM Db2 Mirror for i Getting Started
http://www.redbooks.ibm.com/redpieces/abstracts/redp5575.html
What Are Db2 Mirror Use Cases
First off, Db2 Mirror is about creating an active replicated database across two independent nodes. The key there is an active replicated database. That doesn’t mean replicate the entire node (partition), and it does not mean active replication of an entire application. It is active replication of data, and any objects which are tied to that data (i.e. user profiles, user defined functions, triggers, etc.).
First off, Db2 Mirror is about creating an active replicated database across two independent nodes. The key there is an active replicated database. That doesn’t mean replicate the entire node (partition), and it does not mean active replication of an entire application. It is active replication of data, and any objects which are tied to that data (i.e. user profiles, user defined functions, triggers, etc.).
A couple of the use cases for Db2M would be where a given application runs on one node, with the second node in an active standby mode with live production data ready to use. We refer to this as an active-passive environment. Use cases in an active-passive environment include:
- If you have a requirement for real-time analysis of data, there is an accessible copy of the production data on the second node. You run your production environment on node one while running real-time queries and business intelligence on the second node with no performance impact to the production node. And no delay in the currency of the data on the reporting node.
- If you need to do maintenance on your system or data, you can suspend the data replication and continue with production workload on node one. While suspended, the production node will track changes to the data while the second node can have maintenance done including any required IPL. Once the maintenance is completed on the second node, you resume the Db2 Mirror replication and tracked changes are applied to the second node so that the database files are identical again. The process can then be reversed by swapping the production work to the second node, suspending replication again, and performing needed maintenance on the first node.
- Doing backups of your database can be done on the secondary node, only requiring that you quiesce your production node long enough to suspend Db2 Mirror and start the save-while-active backup on the secondary node. Once the secondary node completes check pointing and the save is in progress, you can resume Db2 Mirror without any application downtime.
- If a failure occurs on the production node, the data is already active and current on the secondary node. This allows for the recovery point objective and recovery time objective for a swap to the secondary node to be reduced to near zero. The production application which was passive on the secondary node can immediately be made active with the data fully available for processing.
It is also possible to use Db2 Mirror in an active-active environment -- in this case the application is running live on both nodes, using the active replicated database in production on both nodes. Use cases in an active-active environment include:
- If you need a level of load balancing, you can distribute users and applications using a single production database across the two nodes. Users and applications are both running and making updates to the single replicated database. Load balancing might be done manually by different departments, types of users, etc. It can also be done by front end load balancing edge components which send requests or users to each node to balance resources across the nodes.
Environment
Configuration Tested
Install and configuration testing was done by IBM i development team using Manhattan WMi 2022 in order to prepare this techdoc so that we could list our experiences and recommendations.
This was not a comprehensive test – and mainly focused on doing the install and setup of the Db2 Mirror environment across two nodes. All testing was done using IBM i 7.5 with TR2, and POWER9 S924 servers as well as POWER10 S1024 servers with two different partitions, connected with 100GbE RoCE network adapters, and using Storwize V7000 and Flash System 5200 storage.
Installation
When setting up Manhattan WMi in a Db2 Mirror environment it is recommended that you install and configure WMi before creating the Db2 Mirror pair. That way when you create the Db2 Mirror pair – which will initially clone the source node – you will have all Manhattan WMi objects cloned onto the target node. This includes non-database objects that are not replicated by Db2 Mirror such as message files, panel groups, subsystem descriptions, product definitions, etc. If you decide to instead do the WMi install after creating the Db2 Mirror pair – you will need to do the WMi install on each node separately to get these application specific objects (outside of the replicated database) to install and exists on both nodes.
When setting up Manhattan WMi in a Db2 Mirror environment it is recommended that you install and configure WMi before creating the Db2 Mirror pair. That way when you create the Db2 Mirror pair – which will initially clone the source node – you will have all Manhattan WMi objects cloned onto the target node. This includes non-database objects that are not replicated by Db2 Mirror such as message files, panel groups, subsystem descriptions, product definitions, etc. If you decide to instead do the WMi install after creating the Db2 Mirror pair – you will need to do the WMi install on each node separately to get these application specific objects (outside of the replicated database) to install and exists on both nodes.
Like setting up High Availability in general, you may want to configure WMi using a virtual hostname and IP address that can be switched between the nodes if using an active-passive configuration. This is not a requirement of Db2 Mirror but is a best practice in terms of having a common hostname and address for clients to connect to the primary node. It also assists in any takeover IP that can be used if the primary node goes down.
In order to synchronously access IFS data on both nodes of a Db2 Mirror pair, you need to setup an Independent Auxiliary Storage Pool (IASP) and then place the Manhattan WMi IFS data in that IASP. You can then create a symbolic link from the local IFS which points to the IASP IFS data. For example, if the name of the IASP is DB2MIASP and the IFS data is in directory /Manhattan, the following commands would move the directory into the IASP and then create a symbolic link to access the data with the same IFS local path name:
> CRTDIR DIR(‘/DB2MIASP/Manhattan’)
> MOV OBJ(‘/Manhattan/*’) TODIR(‘/DB2MIASP/Manhattan’)
… verify everything from /Manhattan directory is now in directory /DB2MIASP/Manhattan,
and that /Manhattan is now empty …
> RMVDIR DIR(‘/Manhattan’)
> ADDLNK OBJ(‘/DB2MIASP/Manhattan’) NEWLNK(‘/Manhattan’)
Repeat the above steps for any IFS data (directories) which you want to move into the Db2 Mirror IFS IASP to have them synchronized across the two nodes. This will allow the IFS data you move into the IASP to be leveraged using the standard path names.
Unlike the database objects which is accessed locally on each node, IFS data within an IASP is accessed using a client/server model where both nodes access the data as if it were local by going through the primary node where the IASP is active. Refer to IFS IASPs in the Db2 Mirror documentation for more details. The net result is still synchronous access to the IFS data from both nodes within a Db2 Mirror pair using the same RoCE network.
Db2 Mirror Pair Setup
After installing and setting up WMi, go through the Db2 Mirror wizard and create your Db2 Mirror pair. The recommendation would be to create the Db2 Mirror pair so that by default libraries are not included in the mirror. You should then add the specific WMi data libraries to the replication control list for Db2 Mirror.
Here is out summary of the WMi libraries and which we would recommend adding to the RCL:
- Manhattan Product Library (MA4M420WM) – product libraries, which contain product definition (PRDDFN) and product load (PRDLOD) objects are not eligible to be replicated. By default this library will be excluded from the RCL.
- Manhattan PK libraries (PKTFRFMA, PKTOOL) – recommend excluding these libraries from replication. PKTOOL library does contain a number of eligible objects, data files, programs, service programs. But it also contains display files, commands and other ineligible objects.
- Manhattan Test data libraries (WMTSTBASD, WMTSTBASS) – recommend including this set of libraries as they contain the main data objects for the WMi test environment.
- Manhattan Test program library (WMTSTBASP) – recommend excluding this library as the library contains the WMi test environment program objects; a mix of program objects and corresponding display files. The display files can not be replicated by Db2 Mirror. So you may be better off excluding this library and synchronizing changes manually.
- Manhattan Prod data libraries (WM420BASD, WM420BASS) – recommend including this set of libraries as they contain the main data objects for the WMi prod environment.
- Manhattan Prod program libraries (WM420BASP, WM420BASR) – recommend excluding this set of libraries as they contain the WMi prod environment program objects; a mix of program objects and corresponding display files. The display files can not be replicated by Db2 Mirror. You may be better off excluding these libraries and synchronizing changes manually.
- Mark Magic Product Library (MM90LICPRD) – product library, this time for Mark Magic, with product definition and product load objects are not eligible for replication. By default will be excluded.
- Mark Magic program library (MRKMAG90) – library contains mostly program objects (PGMs and SRVPGMs) – which are eligible for replication. There are also several hundred objects which are ineligible including command objects (CMD), display files, message files, translation tables, panel groups, etc. Recommendation is to exclude this library – and apply any Mark Magic program updates to each node.
- Mark Magic data library (MRKMAGDTA) – most of the objects are eligible for replication, so would recommend including this library. This library contains data queues that by default will be “definition only” for replication. Refer to the Db2 Mirror documentation for application considerations on replicating data queue entries.
- Mark Magic other libraries (MMEXAMPLES, MRKMAGFNT, MRKMAGUSRP) – recommend excluding these libraries. The only library with eligible objects is the MMEXAMPLES library, which has a number of program objects. The MRKMAGFNT library is all fonts which are ineligible.
There will be objects excluded in these libraries – for example display files, save files, message files, print files, as well as non-file objects like modules, user indexes, message queues, CL commands, job subsystem classes, panel groups and binding directories.
We found no standard WMi database objects which are not eligible for mirroring and require special handling.
The system assumes that libraries with names that begin with “Q”, including QGPL, are system libraries and restricts replication of most objects in these libraries.
There is minimal value in replicating libraries which do not contain data files. For example, the WM420BASP library includes no data files that can be mirrored. And it includes thousands of *PGM objects and files that are ineligible for mirroring (print files, display files, etc.).
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSLLPF","label":"IBM Db2 Mirror for i"},"ARM Category":[{"code":"a8m0z0000001hExAAI","label":"DB2 Mirror"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"7.4.0;and future releases"},{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CGbAAM","label":"General Information"}],"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"7.4.0;and future releases"}]
Was this topic helpful?
Document Information
Modified date:
31 January 2024
UID
ibm17112603