Use MetroMirror with IBM MQ
IBM Metro Mirror, previously known as Synchronous Peer to Peer Remote Copy (PPRC), is a synchronous replication solution between two storage subsystems, where write operations are completed on both the primary and secondary volumes before the write operation is considered to be complete. Metro Mirror can be used in environments that require no data loss in the event of a storage subsystem failure.
Supported data set types
All of the following IBM MQ data set types can be replicated using Metro Mirror. However, exactly which ones are replicated depends on the availability requirements of our enterprise:- Active logs
- Archive logs
- Bootstrap data set (BSDS)
- Page sets
- Shared message data set (SMDS)
- Data sets used for configuration, for example, in the CSQINP* DD cards on the MSTR JCL
Use zHyperWrite with IBM MQ active logs
When a write is made to a data set that is replicated using Metro Mirror, the write is first made to the primary volume, and then replicated to the secondary volume. This replication is done by the storage subsystem and is transparent to the application that issued the write, for example IBM MQ.
This process is illustrated in the following diagram.
Because both writes to the primary and secondary storage subsystems need to complete before the write returns to IBM MQ, use of Metro Mirror can have a performance impact. We need to balance this performance impact against the availability benefits of using Metro Mirror.
The IBM MQ active logs are most sensitive to the performance impact of using Metro Mirror. IBM MQ Version 9.1.2 adds support for using zHyperWrite with the active logs to help reduce this performance impact.
zHyperWrite is a storage subsystem technology that works with z/OS to reduce the performance impact of writes made to data sets that are replicated using Metro Mirror. When zHyperWrite is used, the write to the primary and secondary volumes are issued in parallel at the Data Facility Storage Management Subsystem (DFSMS) level, instead of sequentially at the storage subsystem level, thereby reducing the performance impact.
The following diagram illustrates zHyperWrite being used for the active logs, and Metro Mirror being used for the other IBM MQ data set types. Note that if a zHyperWrite write fails, DFSMS will transparently reissue the write using Metro Mirror.
zHyperWrite on IBM MQ, is supported only on the active log data sets.
In order to use zHyperWrite with the active logs, we need to:- Configure IBM MQ to use zHyperWrite, and
- The active logs need to be on zHyperWrite capable volumes
If both of these conditions are met, writes to active logs are enabled for zHyperWrite. We can configure IBM MQ to use zHyperWrite by using one of the following methods:
Set the following conditions for active log data sets to be on zHyperWrite capable volumes:
- Enable the volumes for Metro Mirror, and the volumes support zHyperWrite
- Ensure that the volumes are HyperSwap enabled
- Specify HYPERWRITE=YES in the IECIOSxx parameter
If all the preceding conditions are met, then writes to the active logs are enabled for zHyperWrite.
If one, or more, of these conditions are not met, IBM MQ writes to the active logs as normal, and Metro Mirror replicates the writes if it is configured.Notes:- IBM MQ does not require that all active log data
sets are on zHyperWrite capable volumes.
If IBM MQ detects that some active log data sets are on zHyperWrite capable volumes, and others are not, it issues message CSQJ166E and carries on processing.
- IBM MQ checks whether active log data sets are
zHyperWrite capable when the data sets are first opened.
Log data sets are opened either at queue manager start up, or when dynamically adding using the DEFINE LOG command. If the log data sets are made zHyperWrite capable while a queue manager has them open, the queue manager will not detect this until it has been restarted.
We can use the output of the DISPLAY LOG command to indicate whether the current active log data sets are zHyperWrite capable. The following example shows that both of the data sets are zHyperWrite capable. If the queue manager has been configured with ZHYWRITE(YES), writes to these logs would be enabled for zHyperWrite:
Copy %Full zHyperWrite DSName 1 4 CAPABLE MQTST.SUBSYS.MQDL.LOGCOPY1.DS001 2 4 CAPABLE MQTST.SUBSYS.MQDL.LOGCOPY2.DS001Parent topic: Plan your logging environment