Managing IFS IASPs

MFS operational role definitions

The server file system (SFS) is the file system mounted on the node where the configured IASP is varied on and active. An SFS acts like a server in a traditional client/server architecture. There is always a corresponding client file system (CFS) on the other node that is paired to this SFS. The SFS handles all local requests that originate on its node for operations intended for the IASP. Additionally, the SFS receives and handles requests for the IASP that originated from the paired CFS node. Those requests are physically fulfilled on the SFS node. Responses are sent back to the CFS node.

The client file system (CFS) is the file system instance that resides on the node that does not own the IASP in this configuration. A CFS acts like a client in a traditional client/server architecture. The configured IASP is never physically varied on for the CFS node but appears to be local and accessible to the end user. Requests that originate from the CFS node for the IASP are sent to the SFS to be physically processed on that node. The response and outcome of the SFS processing is received by the CFS and passed back to the user application. From the user's point of view, the operation appears to have taken place locally on the CFS node.

The following figure shows how a server file system is represented by the Db2 Mirror GUI. The SFS is on the secondary node where the IASP is varied on. The CFS is on the primary node.

Stand-alone system (SAS) mode occurs when the file system is not connected to another MFS to form an operational Db2 Mirror relationship. In this mode, the SAS will act as a solitary local node. Once the node pair relationship is re-attached, based on the user’s intent and configuration, each node’s MFS will change to its appropriate role once more.

The SFS and CFS relationship might not correspond to Db2 Mirror’s primary and secondary node designations. While many deployments of this environment will have the SFS residing on the primary node, it is architected that the IFS IASP (and MFS roles) can switch independently from switching the Db2 Mirror primary and secondary roles. Therefore, an SFS instance could reside on the secondary node of a Db2 Mirror node pair, while the corresponding CFS resides on the primary node. Figure 1 is an example of this configuration.

All the infrastructure and support for the MFS runs in the QMPFS1 system job. This job runs under the QSYS user profile. A single instance of this job is active on each of the nodes in the Db2 Mirror pair.

IFS IASP switchover

The IFS IASP support in the Db2 Mirror environment allows switching an IFS IASP in planned and unplanned situations from one node to another. The MFS reacts to these scenarios and will change the operational role of the file system on its respective node. An instance of an MFS can change its operational role from server file system to client or stand-alone file system and vice versa. These changes are system initiated and controlled, minimizing the effort needed for active management and monitoring. A role swap of the Db2 Mirror primary and secondary roles will not cause an IFS IASP switchover.

Planned switchover

An administrator-initiated IFS IASP switchover can be performed from the Manage IASP - Integrated File System page in the Db2 Mirror GUI, as shown in the following figure. A switchover can also be initiated using the PowerHA® CL command Change CRG Primary (CHGCRGPRI).

During a planned switchover, the active IASP on the SFS node will vary off. The IASP on the paired node will vary on and become active. The file systems on each node will automatically change roles. The original server file system will change from local (SFS) to remote (CFS) operation role, while the original client file system will become the new server file system. A delay may be experienced while the IASP is physically varying off and on. Otherwise, the end user will not experience any interruption of service from the switchover. The only active management involved in a planned switchover is the initiation of the action. Once started, no further action is needed. The planned switchover and the status of the IASP can be monitored from the Db2 Mirror GUI or using the PowerHA CL command Work with Cluster (WRKCLU).

Node failures

In the event of an unplanned outage on the server file system’s node, the IASP on the surviving node will vary on and the CFS on that node will change to a SAS. End users on the surviving node will not experience any interruption of service. When the failing node recovers, both nodes’ MFS will change so the client/server file system relationship is reestablished. The SAS will change to an SFS and the recovering node will establish itself as the CFS. The final roles will be the reverse of the pre-outage configuration.

In the event of an unplanned outage on the client file system’s node, there is no vary off or vary on of the IASP since the node that owns the IASP is still operational. However, the SFS will automatically change to an SAS type. End users on the surviving node will not experience any interruption of service. When the failing node recovers, both nodes’ MFS will change so the client/server file system relationship is reestablished. In this case the SAS will change back to an SFS instance. The recovering node will establish itself as a CFS instance again.

Similar to the planned switchover, there is no active management required for handling node failures. The reactive behaviors of the MFS are performed automatically. Administrators can monitor the related activities from the Db2 Mirror GUI or using the PowerHA CL command Work with Cluster (WRKCLU). For unplanned outages to be properly detected and handled by Db2 Mirror for IFS IASPs, cluster monitoring is required.

Adding an IFS IASP to Db2 Mirror

For instructions to add an IFS IASP to Db2 Mirror, see Adding IFS IASPs to Db2 Mirror.

Managing geographic mirroring

An IFS IASP made highly available using IBM i geographic mirroring technology is managed using the Db2 Mirror GUI. From the Manage IASP - Integrated File System page, right click on an IFS IASP to open a list of actions and choose Geographic Mirroring, as shown in the following figure.

The default view shows you information about the cluster resource group (CRG), including status and the recovery domain, as seen in the following figure.

The CRG must have an active status for the IASP to be switchable. A node in the recovery domain must have an active status to be an eligible target for a switchover.

Buttons to start, end, and switchover the CRG are provided. Buttons to modify the CRG recovery domain are also provided, which includes actions such as adding nodes, removing nodes, updating existing nodes, setting the primary node, and ordering backup nodes.

Click on the Geographic Mirroring tab to view and manage the geographic mirroring session, as shown in the following figure.

The copy state must be active and the copy data state must be usable for the IASP to be switchable.

Buttons to suspend, resume, detach, reattach, and delete the geographic mirroring session are provided.

Removing an IFS IASP from Db2 Mirror

From the Manage IASP - Integrated File System page in the Db2 Mirror GUI, right click on an IFS IASP to open a list of actions and choose Remove the IASP, as shown in the following figure.

The QSYS2.REMOVE_MIRROR_IASP SQL procedure can also be used to remove an IASP from the Db2 Mirror environment. For more information, see REMOVE_MIRROR_IASP procedure.

Limitations