T.Rob
2013-07-24 15:18:47 UTC
That response form the PMR was almost but not quite true. If your only
consideration is performance, then having queues and logs on the same SAN or
the same spindle it won't matter whether you do so in one or two
filesystems. However, if you are using linear logs and have an outage of an
entire filesystem, LUN or mount point, you have some additional
recoverability options by splitting off queues and logs.
I've never heard of anyone creating dedicated mount points for individual
queues or sets of queues before it came up on this thread however, it
strikes me as a Bad Idea T. The scenario would be that doing so isolates
applications form the effects of filling up the filesystem. However, I'd
*always* prefer to get a soft message due to hitting MAXDEPTH than a fatal
resource exception. That strategy requires tuning queue limits and once
those are tuned, it doesn't matter whether that queue has dedicated space or
shares with the rest of the QMgr. Or perhaps it does matter inasmuch as any
individual resource with transient peaks benefits from the excess capacity
of neighboring resources not also experiencing a simultaneous peak. There
may be advantages I'm overlooking but it seems to me to be a lot of
complexity for a net-negative ROI.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, July 24, 2013 8:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Seperate File Systems for logs and queues - on virtual Linux
servers too?
Historically we always broke out /var/mqm and /var/mqm/logs onto separate
disks on a physical server. Then when we started heavy with physical servers
in VCS clusters we made a separate cluster resource for the virtual drive
for the logs and another virtual drive for the rest of the queue manager.
Although with all the SAN storage in the back end a giant pool of disks
fronted with cache I wondered how much benefit there really was.
We are standing up a bunch of virtual RHEL 6 servers on VMware. We are not
using the Hypervisor edition. The whole virtual server is nothing but a
vmdk file on SAN now. The virtual server is running in a physical ESX
cluster among dozens of other virtual servers, all sharing the same physical
I/O to the back end storage that hosts my virtual server and all the other
virtual servers, and any additional virtual disks I may ask to have assigned
to my virtual server.
So is there any benefit to making /var/mqm and /var/mqm/logs separate file
systems on a virtual server? I did not find anything on IBM's site, and my
PMR confirmed that unless I can guarantee separate distinct physical disks
for the logs versus the queues there was no reason to make /var/mqm and
/var/mqm/logs separate file systems. I can guarantee that I will NOT be able
to have separate physical disks for my file systems in our SAN environment.
So I'm leaning to just asking for a single /var/mqm file system so I have a
dedicated amount of disk capacity for my queue manager, and not bother with
a separate file system for the logs.
Thoughts?
Oh, I always wondered, if /var/mqm/logs is separate file system, is there
still a reason to break out /var/mqm/qmgrs from /var/mqm?
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
consideration is performance, then having queues and logs on the same SAN or
the same spindle it won't matter whether you do so in one or two
filesystems. However, if you are using linear logs and have an outage of an
entire filesystem, LUN or mount point, you have some additional
recoverability options by splitting off queues and logs.
I've never heard of anyone creating dedicated mount points for individual
queues or sets of queues before it came up on this thread however, it
strikes me as a Bad Idea T. The scenario would be that doing so isolates
applications form the effects of filling up the filesystem. However, I'd
*always* prefer to get a soft message due to hitting MAXDEPTH than a fatal
resource exception. That strategy requires tuning queue limits and once
those are tuned, it doesn't matter whether that queue has dedicated space or
shares with the rest of the QMgr. Or perhaps it does matter inasmuch as any
individual resource with transient peaks benefits from the excess capacity
of neighboring resources not also experiencing a simultaneous peak. There
may be advantages I'm overlooking but it seems to me to be a lot of
complexity for a net-negative ROI.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, July 24, 2013 8:52 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Seperate File Systems for logs and queues - on virtual Linux
servers too?
Historically we always broke out /var/mqm and /var/mqm/logs onto separate
disks on a physical server. Then when we started heavy with physical servers
in VCS clusters we made a separate cluster resource for the virtual drive
for the logs and another virtual drive for the rest of the queue manager.
Although with all the SAN storage in the back end a giant pool of disks
fronted with cache I wondered how much benefit there really was.
We are standing up a bunch of virtual RHEL 6 servers on VMware. We are not
using the Hypervisor edition. The whole virtual server is nothing but a
vmdk file on SAN now. The virtual server is running in a physical ESX
cluster among dozens of other virtual servers, all sharing the same physical
I/O to the back end storage that hosts my virtual server and all the other
virtual servers, and any additional virtual disks I may ask to have assigned
to my virtual server.
So is there any benefit to making /var/mqm and /var/mqm/logs separate file
systems on a virtual server? I did not find anything on IBM's site, and my
PMR confirmed that unless I can guarantee separate distinct physical disks
for the logs versus the queues there was no reason to make /var/mqm and
/var/mqm/logs separate file systems. I can guarantee that I will NOT be able
to have separate physical disks for my file systems in our SAN environment.
So I'm leaning to just asking for a single /var/mqm file system so I have a
dedicated amount of disk capacity for my queue manager, and not bother with
a separate file system for the logs.
Thoughts?
Oh, I always wondered, if /var/mqm/logs is separate file system, is there
still a reason to break out /var/mqm/qmgrs from /var/mqm?
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html