IBM MQ: Considerations for PortWorx 2.5.5

Problem

• Regardless of deployment architecture, ensure that Portworx has been installed on an infrastructure that meets at least the minimum hardware requirements.
• The use of a journal device is also recommended, because IBM MQ requires synchronous writes and the use of the journal device feature is noted as beneficial.
• Portworx does not, at time of writing, have the ability to rate limit individual volumes. Applications such as IBM MQ have a dynamic IO footprint that depends on the workload. Under heavy loads the application grabs as much IO as it possibly can, which can impact other pods that are using Portworx PVs backed by the same Physical volumes in the "noisy neighbor" scenario. 

• Portworx Version: The first Portworx version supporting NFSv4 is 2.5.5. Any versions below this do not have the characteristics required for Multi-instance queue managers.
• Deployment Architecture: Portworx describes two possible architectures for a Portworx installation.  With respect to multi-instance, MQ either make use of a Disaggregated deployment architecture, where the storage nodes are different to the compute nodes,  or MQ uses something akin to a Converged deployment architecture. In the latter case, you must have storageless nodes and you must ensure that the MQ Queue managers pods runs on those storageless nodes with the storage on the storage nodes.
• Storage Class: there are various parameters that Portworx provides to customize storage classes for the different needs of a given application. IBM MQ multi-instance requires several parameters to be set in the storage class definition:
  • IBM MQ Multi-instance queue manager requires use of Portworx sharedv4 (ReadWriteMany) volumes. Therefore the following parameter needs to be set
    • sharedv4: “true”
  • IBM MQ Multi-instance queue manager failover behavior requires lease locking on a shared file and as such requires NFSv4. Therefore the following parameter needs to be set
    • nfs_v4 : “true” 
  • The io_profile parameter needs to be set to one that is synchronous. Portworx recommends the use of the following profile
    • io_profile: “db_remote”
• Stork scheduler: Testing has been completed both with and without the Stork scheduler being explicitly set.  With respect to multi-instance and remote PVs, Stork did not appear to have an impact. However, with Stork specified during testing, no negative consequences were observed. 
• Failover Time: Multi-instance allows for a slightly faster fail over when compared to that of single-instance. The failover time is the sum of the lease lock timeout plus a small amount of time for the Standby to become active.

• Portworx Version: There are no known restrictions to the version of Portworx. However, as noted previously our testing was done with version 2.5.5 
• Deployment Architecture: Portworx describes possible architectures for a Portworx installation. With respect to single-instance the recommend setup is to use a Converged deployment architecture with hyper-convergence.
• Storage Class: there are various parameters that Portworx provides to customize storage classes for the different needs of a given application. IBM MQ single-instance requires a number of parameters to be set in the storage class definition
  • The io_profile parameter needs to be set to one that is synchronous. Portworx recommends the use of the following profile
    • io_profile: “db_remote”
• Stork scheduler: use the stork scheduler to gain hyper-convergence.
• Failover Time: Single-instance has a slower fail over when compared to that of multi-instance due to the detection and pod restart time.  As such this will roughly be the time for the error condition to be detected and the pod restarted on the existing or an alternative node, depending on the failure scenario.