How To
Summary
Information for installing and setting up Infor LX 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 LX with IBM Db2 Mirror for i.
Objective
You are in: ERP Solutions on IBM i > Infor and Lawson Solutions on IBM i > IBM Db2 Mirror for i and Infor LX Notes
IBM i Db2 Mirror and Infor LX
The introduction of IBM i 7.4 includes the new IBM Db2 Mirror 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. The synchronous database access is enabled via remote direct memory access (RDMA) over Converged Ethernet (RoCE) network and requires IBM POWER8 or POWER9 systems with supported RoCE network cards.
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_74/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 Infor LX 8.4 in order to prepare this techdoc so that we could list our experiences and recommendation.
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.4 with TR1, POWER9 S924 servers with two different partitions, connected with 100GbE RoCE network adapters, and using Storwize V7000 storage.
Installation
When setting up Infor LX in a Db2 Mirror environment it is recommended that you install and configure LX 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 Infor LX 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, etc. If you decide to instead do the LX install after creating the Db2 Mirror pair – you will need to do the LX 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 Infor LX in a Db2 Mirror environment it is recommended that you install and configure LX 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 Infor LX 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, etc. If you decide to instead do the LX install after creating the Db2 Mirror pair – you will need to do the LX install on each node separately to get these application specific objects (outside of the replicated database) to install and exists on both nodes.
In addition to installing and configuring LX before doing the Db2 Mirror pair creation, you should also install and configure WebTop and IDF. Like setting up High Availability in general, you may want to configure LX 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.
Infor LX as well as IDF includes data that is stored in the Integrated File System (IFS) which can be made synchronously available via Db2 Mirror on both nodes. 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 Infor LX 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 /INFOR, 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/INFOR’)
> MOV OBJ(‘/INFOR/*’) TODIR(‘/DB2MIASP/INFOR’)
… verify everything from /INFOR directory is now in directory /DB2MIASP/INFOR,
and that /INFOR is now empty …
> RMVDIR DIR(‘/INFOR’)
> ADDLNK OBJ(‘/DB2MIASP/INFOR’) NEWLNK(‘/INFOR’)
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 data 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 LX, 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.
After installing and setting up LX, 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 LX data libraries to the replication control list for Db2 Mirror. In our testing we added the following LX libraries to the RCL:
- AM2000
- LX840EC
- LX840ECQA
- LX840F
- LX840O
- LX840PTF
- V840AQSOAF
There will be objects excluded in these libraries – for example AMDAIxx, AMDBDM, AMDBIC, etc. which are all display files in the AM2000 library, and not mirrored by Db2 Mirror. Other examples of excluded file objects include 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.
The following files objects are not eligible for mirroring and require special handling:
- AMPLOG, library AM2000 – file uses an identity column defined with CYCLE value which makes it ineligible for mirroring. Leaving this file local to a given node is fine.
- AMPOBJC, library AM2000 – file uses an identity column defined with CYCLE value which makes it ineligible for mirroring. Leaving this file local to a given node is fine.
- ERPUSR, library QGPL – objects in “Q” libraries, including QGPL, cannot be mirrored. If this file needs to be synced between nodes, you can use a manual process or setup the file in a non-Q library (use DDM file in QGPL to mask location).
- MMLIST, library QGPL – objects in “Q” libraries, including QGPL, cannot be mirrored. If this file needs to be synced between nodes, you can use a manual process or setup the file in a non-Q library (use DDM file in QGPL to mask location).
NOTE: 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 LX840O library includes very few data files (~10) that can be mirrored. And it includes over 3000 files that are ineligible for mirroring (print files, display files, etc.). The key LX libraries to include in the mirroring would be AM2000, LX840F, V840AQSOAF.
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:
28 October 2022
UID
ibm16358015