<div dir="ltr">Hi Damir,<div><br></div><div>I'm not sure whether this applies to you, but this was my experience.</div><div><br></div><div>GPFS absolutely depends on a reliable network interconnect.  If anything goes wrong on the network layer, GPFS may not be able to recover.</div><div><br></div><div>Do you have visibility and monitoring on all the low-level network counters on all the relevant network interfaces?</div><div><br></div><div>e.g. if one of your clients is connected to a switch port that is flaky in some way and some GPFS message goes unacked, you can get unusual client state and then the whole cluster hangs...</div><div><br></div><div>In my case years ago we ended up replacing some flaky HP switches and all our GPFS troubles went away!  And we were able to show those switches had some issues when doing non-GPFS testing with iperf, etc.</div><div><br></div><div>Regards,</div><div>Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 22, 2017 at 9:44 AM, Damir Krstic <span dir="ltr"><<a href="mailto:damir.krstic@gmail.com" target="_blank">damir.krstic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It's been a very frustrating couple of months with our 2 ESS systems. IBM tells us we had blueflame bug and they came on site and updated our ESS to the latest version back in middle of November. Wednesday night one of the NSD servers in one of our ESS building blocks kernel panicked. No idea why and none of the logs are insightful. We have a PMR open with IBM. I am not very confident we will get to the bottom of what's causing kernel panics on our IO servers. The system has gone down over 4 times now in 2 months. <div><br></div><div>When we tried brining it back up, it rejoined the recovery group and the IO on the entire cluster locked up until we were able to find couple of compute nodes with pending state in mmfsadm dump tscomm. Killing gpfs on those nodes resolved the issue of the filesystem locking up.<div><br></div><div>So far we have never been successful in brining back an IO server and not having a filesystem lock up until we find a node with pending state with tscomm. Anyway, the system was stable for few minutes until the same IO server that went down on Wednesday night went into an arbitrating mode. It never recovered. We stopped gpfs on that server and IO recovered again. We left gpfs down and cluster seems to be OK.</div><div><br></div><div>My question is, is there a way of brining back the IO server into the mix without the recoverygroup takeover happening? Could I just start a gpfs and have it back in the mix as a backup server for the recoverygroup and if so, how do you do that. Right now that server is designated as primary server for the recovery group. I would like to have both IO servers in the mix for redundancy purposes.</div></div><div><br></div><div>This ESS situation is beyond frustrating and I don't see end in sight.</div><div><br></div><div>Any help is appreciated.</div></div>
<br>______________________________<wbr>_________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/<wbr>listinfo/gpfsug-discuss</a><br>
<br></blockquote></div><br></div>