Example directory configurations on UNIX and Linux
systems
Examples of alternative file system configurations on UNIX and Linux systems.
We can customize the IBM MQ directory structure in
various ways to achieve a number of different objectives.
Place the qmgrs and log directories on remote shared
file systems to configure a multi-instance queue manager.
Use separate file systems for the data and log directories, and allocate the directories to
different disks, to improve performance by reducing I/O contention.
Use faster storage devices for directories that have a greater effect on performance. Physical
device latency is frequently a more important factor in the performance of persistent messaging than
whether a device is mounted locally or remotely. The following list shows which directories are most
and least performance sensitive.
log
qmgrs
Other directories, including /usr/mqm
Create the qmgrs and log directories on file systems
that are allocated to storage with good resilience, such as a redundant disk array, for example.
It is better to store the common error logs in var/mqm/errors, locally,
rather than on a network file system, so that error relating to the network file system can be
logged.
Figure 1 is a template from which
alternative IBM MQ directory structures are derived. In
the template, dotted lines represent paths that are configurable. In the examples, the dotted lines
are replaced by solid lines that correspond to the configuration information stored in the
AMQ_MQS_INI_LOCATION environment variable, and in the mqs.ini and
qm.ini files. Note: The path information is shown as it appears in the
mqs.ini or qm.ini files. If you supply path parameters in
the crtmqm command, omit the name of the queue manager directory: the queue
manager name is added to the path by IBM MQ.
Figure 1. Directory structure pattern template
Examples of configured directory structures follow. The first example shows a typical default
directory structure for IBM WebSphere MQ Version 7.0.1 created by issuing
the crtmqm
QM1 command. The second example shows how a typical directory structure appears
for a queue manager created using an IBM MQ release
earlier than Version 7.0.1. The directory structure does not
change.
Queue managers newly created in Version 7.0.1 have a
different configuration file from earlier releases of Version 7. For to remove the Version 7.0.1 fix pack to revert to Version 7.0.0, Fix Pack 2, you
need to re-create the configuration files. We might only need to use the Prefix attribute to define
the path to the new queue manager data directory, or you might need to move the queue manager data
directory and log directories to a different location. The safest way to reconfigure the queue
manager is to save the queue manager data and log directories, delete and re-create the queue
manager, and then replace the data and log directories in their new location, with the ones that
have been saved.
Typical directory structure for Version 7.0.1
onwards
Figure 2 is the default directory structure created
in Version 7.0.1 by issuing the command
crtmqm
QM1.
The mqs.ini file has a stanza for the QM1 queue manager, created by
referring to the value of DefaultPrefix. The Log stanza in the
qm.ini file has a value for LogPath, set by reference to
LogDefaultPath in mqs.ini.
Use the optional crtmqm parameters to override the default values of
DataPath and LogPath.
Figure 2. Example default IBM MQ directory structure for
UNIX and Linux systems
Typical directory structure for releases earlier than Version 7.0.1
The DataPath attribute did not
exist before Version 7.0.1; the attribute is not present in
the mqs.ini file. The location of the qmgrs directory was
configured using the Prefix attribute. The location of individual directories could
be configured by using symbolic links to point to different file system locations.Figure 3. Typical directory structure for releases earlier than Version 7.0.1
Share default qmgrs and log directories (Version 7.0.1 onwards)
An alternative to Share everything (Version 7.0.1 onwards), is to share the qmgrs
and log directories separately ( Figure 4 ). In this configuration, there is no need to
set AMQ_MQS_INI_LOCATION as the default mqs.ini is stored in the local
/var/mqm file system. The files and directories, such as
mqclient.ini and mqserver.ini are also not shared.Figure 4. Share qmgrs and log directories
Share named qmgrs and log directories (Version 7.0.1 onwards)
The configuration in Figure 5 places the log and
qmgrs in a common named remote shared file system called
/ha. The same physical configuration can be created in two different ways.
Set LogDefaultPath=/ha and then run the command, crtmqm -
md
/ha/qmgrs
QM1. The result is exactly as illustrated in Figure 5.
Leave the default paths unchanged and then run the command, crtmqm -
ld
/ha/log - md
/ha/qmgrs
QM1.
Figure 5. Share named qmgrs and log directories
Share everything (Version 7.0.1 onwards)
Figure 6 is a simple configuration for system
with fast networked file storage.
Mount /var/mqm as a remote shared file system. By default, when you start
QM1, it looks for /var/mqm, finds it on the shared file system, and reads the
mqs.ini file in /var/mqm. Rather than use the single
/var/mqm/mqs.ini file for queue managers on all your servers, we can set the
AMQ_MQS_INI_LOCATION environment variable on each server to point to different
mqs.ini files. Note: The contents of the generic error file in
/var/mqm/errors/ are shared between queue managers on different servers.
Figure 6. Share everything
Note that we cannot use this for multi-instance queue managers. The reason is that it is
necessary for each host in a multi-instance queue manager to have its own local copy of
/var/mqm to keep track of local data, such as semaphores and shared memory.
These entities cannot be shared across hosts.