Multiinstance survey

[Pere Guerrero Olmedo]

Hi,

We are having lot of problems with multiinstance qmgrs, when a takeover/giveback is made by our storage people, our qmgr active tends to crash and then swith to the standby instance. Sometimes is even worse, so 2 processes remains active in the "active crashed instance" and although standby instance is started QMGR doesn't work.

The thing is our storage people told us 120 seconds is an acceptable time for a takeover or giveback process, and we now 20 seconds is the limit the active instance waits before try to switch to the standby one.

To the people that is using M.I. qmgrs: in your installations , is it normal that a takeover needs over 120 seconds?

In that case do you have any bypass?

Thanks in advance.
Pere


________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la informaci?n contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene informaci?n confidencial cuyo uso, copia, reproducci?n o distribuci?n est? expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminaci?n sin copiarlo, imprimirlo o utilizarlo de ning?n modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.

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

[Neil Casey]

Hi,

my experience with MIQM using NFS (IBM N-Series or NetApp Filers) was similar to yours. Storage failover tended to cause MQ failover. It sometimes then caused Linux issues because we were using kerberos encryption (krb5p) on the NFS sessions. Several times we had to reboot linux in order to be able to reconnect to the storage and restart the queue manager as a backup instance.

In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.

Using SAN worked very well for us. The MIQM tech note lists the SAN shared file systems that have been tested by the labs, and which ones worked with MQ.

The technote (http://www-01.ibm.com/support/docview.wss?uid=swg21433474) lists Data ONTAP 7.3.2 as the compatible version. We were not able to run that release as it was not supported on our hardware. We had 8.1.1, running in 7 mode, but had lots of issues, not only with storage failover, but also with NFS storage reporting protocol errors (sequence number failures from memory).

Regards,


Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Hi,
We are having lot of problems with multiinstance qmgrs, when a takeover/giveback is made by our storage people, our qmgr active tends to crash and then swith to the standby instance. Sometimes is even worse, so 2 processes remains active in the “active crashed instance” and although standby instance is started QMGR doesn’t work.
The thing is our storage people told us 120 seconds is an acceptable time for a takeover or giveback process, and we now 20 seconds is the limit the active instance waits before try to switch to the standby one.
To the people that is using M.I. qmgrs: in your installations , is it normal that a takeover needs over 120 seconds?
In that case do you have any bypass?
Thanks in advance.
Pere
AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.
CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

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

[Potkay, Peter M (CTO Architecture + Engineering)]

Neil,
"In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems."
What role did the Red Hat Cluster suite play in this topology with a Multi Instance Queue Manager? Did you have other application components being managed in a classic hardware cluster solution, while the QM independently failed over using Multi Instance?

Peter Potkay


From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, November 21, 2013 4:36 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Multiinstance survey

Hi,

my experience with MIQM using NFS (IBM N-Series or NetApp Filers) was similar to yours. Storage failover tended to cause MQ failover. It sometimes then caused Linux issues because we were using kerberos encryption (krb5p) on the NFS sessions. Several times we had to reboot linux in order to be able to reconnect to the storage and restart the queue manager as a backup instance.

In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.

Using SAN worked very well for us. The MIQM tech note lists the SAN shared file systems that have been tested by the labs, and which ones worked with MQ.

The technote (http://www-01.ibm.com/support/docview.wss?uid=swg21433474) lists Data ONTAP 7.3.2 as the compatible version. We were not able to run that release as it was not supported on our hardware. We had 8.1.1, running in 7 mode, but had lots of issues, not only with storage failover, but also with NFS storage reporting protocol errors (sequence number failures from memory).

Regards,


Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:image001.jpg-***@public.gmane.org] [phone]<tel:+61%20414%20615%20334>[cid:image002.jpg-***@public.gmane.org] neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:image003.png-***@public.gmane.org]

On 21 Nov 2013, at 6:25 pm, Pere Guerrero Olmedo <***@EVERIS.COM<mailto:Pere.Guerrero.Olmedo-***@public.gmane.org>> wrote:


Hi,

We are having lot of problems with multiinstance qmgrs, when a takeover/giveback is made by our storage people, our qmgr active tends to crash and then swith to the standby instance. Sometimes is even worse, so 2 processes remains active in the "active crashed instance" and although standby instance is started QMGR doesn't work.

The thing is our storage people told us 120 seconds is an acceptable time for a takeover or giveback process, and we now 20 seconds is the limit the active instance waits before try to switch to the standby one.

To the people that is using M.I. qmgrs: in your installations , is it normal that a takeover needs over 120 seconds?

In that case do you have any bypass?

Thanks in advance.
Pere


________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.
________________________________
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>


________________________________
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>
************************************************************
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.
************************************************************

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

[Neil Casey]

Hi Peter,

RHCS is a pre-requisite to running gfs2 file system for the shared clustered disk. The actual component of RHCS needed is “Resilient Storage”. cman, corosync, clvm and some other stuff all need to be in place to provide cluster consistency and communications before gfs2 will run and mount the file system.

In order to allow us to detect and force failover for things like ip interface failure, which MQ won’t detect on its own, we also used quorum disk and heuristics scripts to provide status info back to the cluster software. This allows RHCS to eject a broken node running the active instance from the cluster (it fences the node causing a reboot) and so the other instance takes over.

So we didn’t run any applications under cluster control at all.

My original statement was somewhat sloppy, as you don’t need the full cluster suite running just to access gfs2, although you do need significant parts of it.

Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Neil,
“In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.”
What role did the Red Hat Cluster suite play in this topology with a Multi Instance Queue Manager? Did you have other application components being managed in a classic hardware cluster solution, while the QM independently failed over using Multi Instance?
Peter Potkay
Sent: Thursday, November 21, 2013 4:36 AM
Subject: Re: Multiinstance survey
Hi,
my experience with MIQM using NFS (IBM N-Series or NetApp Filers) was similar to yours. Storage failover tended to cause MQ failover. It sometimes then caused Linux issues because we were using kerberos encryption (krb5p) on the NFS sessions. Several times we had to reboot linux in order to be able to reconnect to the storage and restart the queue manager as a backup instance.
In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.
Using SAN worked very well for us. The MIQM tech note lists the SAN shared file systems that have been tested by the labs, and which ones worked with MQ.
The technote (http://www-01.ibm.com/support/docview.wss?uid=swg21433474) lists Data ONTAP 7.3.2 as the compatible version. We were not able to run that release as it was not supported on our hardware. We had 8.1.1, running in 7 mode, but had lots of issues, not only with storage failover, but also with NFS storage reporting protocol errors (sequence number failures from memory).
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
Hi,
We are having lot of problems with multiinstance qmgrs, when a takeover/giveback is made by our storage people, our qmgr active tends to crash and then swith to the standby instance. Sometimes is even worse, so 2 processes remains active in the “active crashed instance” and although standby instance is started QMGR doesn’t work.
The thing is our storage people told us 120 seconds is an acceptable time for a takeover or giveback process, and we now 20 seconds is the limit the active instance waits before try to switch to the standby one.
To the people that is using M.I. qmgrs: in your installations , is it normal that a takeover needs over 120 seconds?
In that case do you have any bypass?
Thanks in advance.
Pere
AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.
CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
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 - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

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

[Pere Guerrero Olmedo]

Thanks all guys.
Pere

De: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] En nombre de Neil Casey
Enviado el: jueves, 21 de noviembre de 2013 23:01
Para: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Asunto: Re: Multiinstance survey

Hi Peter,

RHCS is a pre-requisite to running gfs2 file system for the shared clustered disk. The actual component of RHCS needed is "Resilient Storage". cman, corosync, clvm and some other stuff all need to be in place to provide cluster consistency and communications before gfs2 will run and mount the file system.

In order to allow us to detect and force failover for things like ip interface failure, which MQ won't detect on its own, we also used quorum disk and heuristics scripts to provide status info back to the cluster software. This allows RHCS to eject a broken node running the active instance from the cluster (it fences the node causing a reboot) and so the other instance takes over.

So we didn't run any applications under cluster control at all.

My original statement was somewhat sloppy, as you don't need the full cluster suite running just to access gfs2, although you do need significant parts of it.

Regards,

Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

[cid:image001.jpg-***@public.gmane.org] [phone]<tel:+61%20414%20615%20334>[cid:image002.jpg-***@public.gmane.org] neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

[cid:image003.png-***@public.gmane.org]

On 21 Nov 2013, at 11:41 pm, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>> wrote:


Neil,
"In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems."
What role did the Red Hat Cluster suite play in this topology with a Multi Instance Queue Manager? Did you have other application components being managed in a classic hardware cluster solution, while the QM independently failed over using Multi Instance?

Peter Potkay



From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, November 21, 2013 4:36 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: Multiinstance survey

Hi,

my experience with MIQM using NFS (IBM N-Series or NetApp Filers) was similar to yours. Storage failover tended to cause MQ failover. It sometimes then caused Linux issues because we were using kerberos encryption (krb5p) on the NFS sessions. Several times we had to reboot linux in order to be able to reconnect to the storage and restart the queue manager as a backup instance.

In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.

Using SAN worked very well for us. The MIQM tech note lists the SAN shared file systems that have been tested by the labs, and which ones worked with MQ.

The technote (http://www-01.ibm.com/support/docview.wss?uid=swg21433474) lists Data ONTAP 7.3.2 as the compatible version. We were not able to run that release as it was not supported on our hardware. We had 8.1.1, running in 7 mode, but had lots of issues, not only with storage failover, but also with NFS storage reporting protocol errors (sequence number failures from memory).

Regards,


Neil


--
Neil Casey
Senior Consultant | Syntegrity Solutions

<image001.jpg> [phone]<tel:+61%20414%20615%20334><image002.jpg> neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

<image003.png>

On 21 Nov 2013, at 6:25 pm, Pere Guerrero Olmedo <***@EVERIS.COM<mailto:Pere.Guerrero.Olmedo-***@public.gmane.org>> wrote:



Hi,

We are having lot of problems with multiinstance qmgrs, when a takeover/giveback is made by our storage people, our qmgr active tends to crash and then swith to the standby instance. Sometimes is even worse, so 2 processes remains active in the "active crashed instance" and although standby instance is started QMGR doesn't work.

The thing is our storage people told us 120 seconds is an acceptable time for a takeover or giveback process, and we now 20 seconds is the limit the active instance waits before try to switch to the standby one.

To the people that is using M.I. qmgrs: in your installations , is it normal that a takeover needs over 120 seconds?

In that case do you have any bypass?

Thanks in advance.
Pere


________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.
________________________________
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>


________________________________
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>

************************************************************
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>


________________________________
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>

________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.

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

[d***@public.gmane.org]

do you think I could run multi-instance QMs with automated failover turned on using Red Hat Storage Server (RHSS)?

I was going to take a look at it some time this week, but I won't do it if one of you says "don't bother and here's why..."

Derek.





De: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] En nombre de Neil Casey
Enviado el: jueves, 21 de noviembre de 2013 23:01
Para: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Asunto: Re: Multiinstance survey




Hi Peter,





RHCS is a pre-requisite to running gfs2 file system for the shared clustered disk. The actual component of RHCS needed is “Resilient Storage”. cman, corosync, clvm and some other stuff all need to be in place to provide cluster consistency and communications before gfs2 will run and mount the file system.





In order to allow us to detect and force failover for things like ip interface failure, which MQ won’t detect on its own, we also used quorum disk and heuristics scripts to provide status info back to the cluster software. This allows RHCS to eject a broken node running the active instance from the cluster (it fences the node causing a reboot) and so the other instance takes over.





So we didn’t run any applications under cluster control at all.





My original statement was somewhat sloppy, as you don’t need the full cluster suite running just to access gfs2, although you do need significant parts of it.





Regards,





Neil
--
Neil Casey


Senior Consultant | Syntegrity Solutions



[phone] neil.casey-VLLIzlmz+***@public.gmane.org


Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006


Analyse >> Integrate >> Secure >> Educate








On 21 Nov 2013, at 11:41 pm, Potkay, Peter M (CTO Architecture + Engineering) < Peter.Potkay-***@public.gmane.org > wrote:






Neil,


“ In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems. ”


What role did the Red Hat Cluster suite play in this topology with a Multi Instance Queue Manager? Did you have other application components being managed in a classic hardware cluster solution, while the QM independently failed over using Multi Instance?





Peter Potkay







From: MQSeries List [ mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org ] On Behalf Of Neil Casey
Sent: Thursday, November 21, 2013 4:36 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Multiinstance survey





Hi,





my experience with MIQM using NFS (IBM N-Series or NetApp Filers) was similar to yours. Storage failover tended to cause MQ failover. It sometimes then caused Linux issues because we were using kerberos encryption (krb5p) on the NFS sessions. Several times we had to reboot linux in order to be able to reconnect to the storage and restart the queue manager as a backup instance.





In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.





Using SAN worked very well for us. The MIQM tech note lists the SAN shared file systems that have been tested by the labs, and which ones worked with MQ.





The technote ( http://www-01.ibm.com/support/docview.wss?uid=swg21433474 ) lists Data ONTAP 7.3.2 as the compatible version. We were not able to run that release as it was not supported on our hardware. We had 8.1.1, running in 7 mode, but had lots of issues, not only with storage failover, but also with NFS storage reporting protocol errors (sequence number failures from memory).





Regards,








Neil
--
Neil Casey


Senior Consultant | Syntegrity Solutions



<image001.jpg> [phone] <image002.jpg> neil.casey-VLLIzlmz+***@public.gmane.org


Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006


Analyse >> Integrate >> Secure >> Educate



<image003.png>





On 21 Nov 2013, at 6:25 pm, Pere Guerrero Olmedo < ***@EVERIS.COM > wrote:







Hi,





We are having lot of problems with multiinstance qmgrs, when a takeover/giveback is made by our storage people, our qmgr active tends to crash and then swith to the standby instance. Sometimes is even worse, so 2 processes remains active in the “active crashed instance” and although standby instance is started QMGR doesn’t work.





The thing is our storage people told us 120 seconds is an acceptable time for a takeover or giveback process, and we now 20 seconds is the limit the active instance waits before try to switch to the standby one.





To the people that is using M.I. qmgrs: in your installations , is it normal that a takeover needs over 120 seconds?





In that case do you have any bypass?





Thanks in advance.


Pere










AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.



List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com









List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
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 - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com









List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com



AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


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

[Neil Casey]

Hi Derek,

I took a look at the documentation for RHSS (I haven’t used it, so please take comments with a grain of salt).

It looks to me like NFS v4 support might not be available yet. It seems to have NFS v3 with some lock management enhancements. If this is the case, then unix based MQ is likely to have problems, because it is very sensitive to lock management behaviour.

If you run MQ on Windows, and mount the storage using CIFS/SMB you might be OK, as that seems to be supported.

I think you would want to do quite extensive failover and performance testing to ensure that the storage infrastructure supported MQ in a way that was equivalent to the environments described in the MIQM storage support tech note.

Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Post by d***@public.gmane.org
do you think I could run multi-instance QMs with automated failover turned on using Red Hat Storage Server (RHSS)?
I was going to take a look at it some time this week, but I won't do it if one of you says "don't bother and here's why..."
Derek.
Enviado el: jueves, 21 de noviembre de 2013 23:01
Asunto: Re: Multiinstance survey
Hi Peter,
RHCS is a pre-requisite to running gfs2 file system for the shared clustered disk. The actual component of RHCS needed is “Resilient Storage”. cman, corosync, clvm and some other stuff all need to be in place to provide cluster consistency and communications before gfs2 will run and mount the file system.
In order to allow us to detect and force failover for things like ip interface failure, which MQ won’t detect on its own, we also used quorum disk and heuristics scripts to provide status info back to the cluster software. This allows RHCS to eject a broken node running the active instance from the cluster (it fences the node causing a reboot) and so the other instance takes over.
So we didn’t run any applications under cluster control at all.
My original statement was somewhat sloppy, as you don’t need the full cluster suite running just to access gfs2, although you do need significant parts of it.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
Neil,
“In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.”
What role did the Red Hat Cluster suite play in this topology with a Multi Instance Queue Manager? Did you have other application components being managed in a classic hardware cluster solution, while the QM independently failed over using Multi Instance?
Peter Potkay
Sent: Thursday, November 21, 2013 4:36 AM
Subject: Re: Multiinstance survey
Hi,
my experience with MIQM using NFS (IBM N-Series or NetApp Filers) was similar to yours. Storage failover tended to cause MQ failover. It sometimes then caused Linux issues because we were using kerberos encryption (krb5p) on the NFS sessions. Several times we had to reboot linux in order to be able to reconnect to the storage and restart the queue manager as a backup instance.
In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.
Using SAN worked very well for us. The MIQM tech note lists the SAN shared file systems that have been tested by the labs, and which ones worked with MQ.
The technote (http://www-01.ibm.com/support/docview.wss?uid=swg21433474) lists Data ONTAP 7.3.2 as the compatible version. We were not able to run that release as it was not supported on our hardware. We had 8.1.1, running in 7 mode, but had lots of issues, not only with storage failover, but also with NFS storage reporting protocol errors (sequence number failures from memory).
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
Hi,
We are having lot of problems with multiinstance qmgrs, when a takeover/giveback is made by our storage people, our qmgr active tends to crash and then swith to the standby instance. Sometimes is even worse, so 2 processes remains active in the “active crashed instance” and although standby instance is started QMGR doesn’t work.
The thing is our storage people told us 120 seconds is an acceptable time for a takeover or giveback process, and we now 20 seconds is the limit the active instance waits before try to switch to the standby one.
To the people that is using M.I. qmgrs: in your installations , is it normal that a takeover needs over 120 seconds?
In that case do you have any bypass?
Thanks in advance.
Pere
AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.
CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
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 - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.
CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

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

[d***@public.gmane.org]

thanks Neil, so I am already going down the road of getting a NFS V4 setup for my NetApp filers, so I guess that's the way I will continue to go....

----- Original Message -----

From: "Neil Casey" <neil.casey-+***@public.gmane.org>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Sent: Tuesday, December 3, 2013 4:28:50 PM
Subject: Re: Multiinstance survey

Hi Derek,

I took a look at the documentation for RHSS (I haven’t used it, so please take comments with a grain of salt).

It looks to me like NFS v4 support might not be available yet. It seems to have NFS v3 with some lock management enhancements. If this is the case, then unix based MQ is likely to have problems, because it is very sensitive to lock management behaviour.

If you run MQ on Windows, and mount the storage using CIFS/SMB you might be OK, as that seems to be supported.

I think you would want to do quite extensive failover and performance testing to ensure that the storage infrastructure supported MQ in a way that was equivalent to the environments described in the MIQM storage support tech note.

Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions


[phone] neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate


On 4 Dec 2013, at 6:48 am, dhornby5-***@public.gmane.org wrote:




do you think I could run multi-instance QMs with automated failover turned on using Red Hat Storage Server (RHSS)?

I was going to take a look at it some time this week, but I won't do it if one of you says "don't bother and here's why..."

Derek.



De: MQSeries List [ mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org ] En nombre de Neil Casey
Enviado el: jueves, 21 de noviembre de 2013 23:01
Para: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Asunto: Re: Multiinstance survey



Hi Peter,



RHCS is a pre-requisite to running gfs2 file system for the shared clustered disk. The actual component of RHCS needed is “Resilient Storage”. cman, corosync, clvm and some other stuff all need to be in place to provide cluster consistency and communications before gfs2 will run and mount the file system.



In order to allow us to detect and force failover for things like ip interface failure, which MQ won’t detect on its own, we also used quorum disk and heuristics scripts to provide status info back to the cluster software. This allows RHCS to eject a broken node running the active instance from the cluster (it fences the node causing a reboot) and so the other instance takes over.



So we didn’t run any applications under cluster control at all.



My original statement was somewhat sloppy, as you don’t need the full cluster suite running just to access gfs2, although you do need significant parts of it.



Regards,



Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

<image001.jpg> [phone] <image002.jpg> neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

<image003.png>



On 21 Nov 2013, at 11:41 pm, Potkay, Peter M (CTO Architecture + Engineering) < Peter.Potkay-***@public.gmane.org > wrote:


Neil,
“ In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems. ”
What role did the Red Hat Cluster suite play in this topology with a Multi Instance Queue Manager? Did you have other application components being managed in a classic hardware cluster solution, while the QM independently failed over using Multi Instance?



Peter Potkay




From: MQSeries List [ mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org ] On Behalf Of Neil Casey
Sent: Thursday, November 21, 2013 4:36 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Multiinstance survey



Hi,



my experience with MIQM using NFS (IBM N-Series or NetApp Filers) was similar to yours. Storage failover tended to cause MQ failover. It sometimes then caused Linux issues because we were using kerberos encryption (krb5p) on the NFS sessions. Several times we had to reboot linux in order to be able to reconnect to the storage and restart the queue manager as a backup instance.



In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.



Using SAN worked very well for us. The MIQM tech note lists the SAN shared file systems that have been tested by the labs, and which ones worked with MQ.



The technote ( http://www-01.ibm.com/support/docview.wss?uid=swg21433474 ) lists Data ONTAP 7.3.2 as the compatible version. We were not able to run that release as it was not supported on our hardware. We had 8.1.1, running in 7 mode, but had lots of issues, not only with storage failover, but also with NFS storage reporting protocol errors (sequence number failures from memory).



Regards,






Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

<image001.jpg> [phone] <image002.jpg> neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

<image003.png>



On 21 Nov 2013, at 6:25 pm, Pere Guerrero Olmedo < ***@EVERIS.COM > wrote:


Hi,



We are having lot of problems with multiinstance qmgrs, when a takeover/giveback is made by our storage people, our qmgr active tends to crash and then swith to the standby instance. Sometimes is even worse, so 2 processes remains active in the “active crashed instance” and although standby instance is started QMGR doesn’t work.



The thing is our storage people told us 120 seconds is an acceptable time for a takeover or giveback process, and we now 20 seconds is the limit the active instance waits before try to switch to the standby one.



To the people that is using M.I. qmgrs: in your installations , is it normal that a takeover needs over 120 seconds?



In that case do you have any bypass?



Thanks in advance.
Pere










AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.



CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.

List Archive - Manage Your List Settings - Unsubscribe


Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com







List Archive - Manage Your List Settings - Unsubscribe


Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

************************************************************
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 - Manage Your List Settings - Unsubscribe


Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com







List Archive - Manage Your List Settings - Unsubscribe


Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com



AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.


List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com



List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com






List Archive - Manage Your List Settings - Unsubscribe

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com


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

[Neil Casey]

Hi Derek,

take a close look at the NetApp filers too. The tech note (http://www-01.ibm.com/support/docview.wss?uid=swg21433474) lists that they tested successfully against Data ONTAP v7.3.2, using MQ on RHEL 5.3.

The new filers run v8, which even in v7 compatibility mode doesn’t behave exactly the same way, at least in early releases. In a previous role, I saw problems getting NFS Client on RHEL 5.8 to connect reliably with Data ONTAP 8.1.1 storage using NFS v4. The NFS client would report some sort of sequence number error (essentially a protocol state error) and MQ would fail over due to the IO error reported up from the kernel.

I understand that there were fixes to this issue due for release (I think in Data ONTAP 8.1.3) but I don’t know whether the issues are resolved or not. I would recommend extensive testing over extended time periods (> 24 hour soak and intermittent test cycles).

You might also find NFS v4 Client issues either fixed or introduced in various releases of RHEL.

Regards,

Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions

[phone] neil.casey-VLLIzlmz+***@public.gmane.org
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate

Post by d***@public.gmane.org
thanks Neil, so I am already going down the road of getting a NFS V4 setup for my NetApp filers, so I guess that's the way I will continue to go....
Sent: Tuesday, December 3, 2013 4:28:50 PM
Subject: Re: Multiinstance survey
Hi Derek,
I took a look at the documentation for RHSS (I haven’t used it, so please take comments with a grain of salt).
It looks to me like NFS v4 support might not be available yet. It seems to have NFS v3 with some lock management enhancements. If this is the case, then unix based MQ is likely to have problems, because it is very sensitive to lock management behaviour.
If you run MQ on Windows, and mount the storage using CIFS/SMB you might be OK, as that seems to be supported.
I think you would want to do quite extensive failover and performance testing to ensure that the storage infrastructure supported MQ in a way that was equivalent to the environments described in the MIQM storage support tech note.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<PastedGraphic-1.tiff>
do you think I could run multi-instance QMs with automated failover turned on using Red Hat Storage Server (RHSS)?
I was going to take a look at it some time this week, but I won't do it if one of you says "don't bother and here's why..."
Derek.
Enviado el: jueves, 21 de noviembre de 2013 23:01
Asunto: Re: Multiinstance survey
Hi Peter,
RHCS is a pre-requisite to running gfs2 file system for the shared clustered disk. The actual component of RHCS needed is “Resilient Storage”. cman, corosync, clvm and some other stuff all need to be in place to provide cluster consistency and communications before gfs2 will run and mount the file system.
In order to allow us to detect and force failover for things like ip interface failure, which MQ won’t detect on its own, we also used quorum disk and heuristics scripts to provide status info back to the cluster software. This allows RHCS to eject a broken node running the active instance from the cluster (it fences the node causing a reboot) and so the other instance takes over.
So we didn’t run any applications under cluster control at all.
My original statement was somewhat sloppy, as you don’t need the full cluster suite running just to access gfs2, although you do need significant parts of it.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
Neil,
“In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.”
What role did the Red Hat Cluster suite play in this topology with a Multi Instance Queue Manager? Did you have other application components being managed in a classic hardware cluster solution, while the QM independently failed over using Multi Instance?
Peter Potkay
Sent: Thursday, November 21, 2013 4:36 AM
Subject: Re: Multiinstance survey
Hi,
my experience with MIQM using NFS (IBM N-Series or NetApp Filers) was similar to yours. Storage failover tended to cause MQ failover. It sometimes then caused Linux issues because we were using kerberos encryption (krb5p) on the NFS sessions. Several times we had to reboot linux in order to be able to reconnect to the storage and restart the queue manager as a backup instance.
In the end, we adopted SAN instead of NAS, using Red Hat Cluster Suite, and gfs2 file systems.
Using SAN worked very well for us. The MIQM tech note lists the SAN shared file systems that have been tested by the labs, and which ones worked with MQ.
The technote (http://www-01.ibm.com/support/docview.wss?uid=swg21433474) lists Data ONTAP 7.3.2 as the compatible version. We were not able to run that release as it was not supported on our hardware. We had 8.1.1, running in 7 mode, but had lots of issues, not only with storage failover, but also with NFS storage reporting protocol errors (sequence number failures from memory).
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
Syntegrity Solutions Pty Ltd | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
Hi,
We are having lot of problems with multiinstance qmgrs, when a takeover/giveback is made by our storage people, our qmgr active tends to crash and then swith to the standby instance. Sometimes is even worse, so 2 processes remains active in the “active crashed instance” and although standby instance is started QMGR doesn’t work.
The thing is our storage people told us 120 seconds is an acceptable time for a takeover or giveback process, and we now 20 seconds is the limit the active instance waits before try to switch to the standby one.
To the people that is using M.I. qmgrs: in your installations , is it normal that a takeover needs over 120 seconds?
In that case do you have any bypass?
Thanks in advance.
Pere
AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.
CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
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 - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.
CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute any portion of this E-mail.
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com

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