this depends on , where the clustermanager and the filesystem manager runs .. when a node and half of the disk disappear at the same time...
for a real active-active configuration you may consider
https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.1/com.ibm.spectrum.scale.v4r21.doc/bl1adv_actact.htm
From: Jan-Frode Myklebust <[email protected]>
To: gpfsug main discussion list <[email protected]>
Date: 05/04/2017 07:27 AM
Subject: Re: [gpfsug-discuss] Tiebreaker disk question
Sent by: [email protected]
This doesn't sound like normal behaviour. It shouldn't matter which filesystem your tiebreaker disks belong to. I think the failure was caused by something else, but am not able to guess from the little information you posted.. The mmfs.log will probably tell you the reason.
-jf
ons. 3. mai 2017 kl. 19.08 skrev Shaun Anderson <[email protected]>:
We noticed some odd behavior recently. I have a customer with a small Scale (with Archive on top) configuration that we recently updated to a dual node configuration. We are using CES and setup a very small 3 nsd shared-root filesystem(gpfssr). We also set up tiebreaker disks and figured it would be ok to use the gpfssr NSDs for this purpose.
When we tried to perform some basic failover testing, both nodes came down. It appears from the logs that when we initiated the node failure (via mmshutdown command...not great, I know) it unmounts and remounts the shared-root filesystem. When it did this, the cluster lost access to the tiebreaker disks, figured it had lost quorum and the other node came down as well.
We got around this by changing the tiebreaker disks to our other normal gpfs filesystem. After that failover worked as expected. This is documented nowhere as far as I could find. I wanted to know if anybody else had experienced this and if this is expected behavior. All is well now and operating as we want so I don't think we'll pursue a support request.
Regards,
SHAUN ANDERSON
STORAGE ARCHITECT
O208.577.2112
M214.263.7014
NOTICE: This email message and any attachments
here to may contain confidential
information. Any unauthorized review, use, disclosure, or distribution
of such
information is prohibited. If you are not the intended recipient, please
contact
the sender by reply email and destroy the original message and all copies
of it.
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
