<html><head></head><body>"mmlscluster --ces" will show the address distribution policy.<br>
<br>
-- Lauz<br><br><div class="gmail_quote">On 22 June 2017 20:37:12 BST, Edward Wahl <ewahl@osc.edu> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><br />Is there a command to show existing node Address Policy? <br />Or are we left with grep "affinity" on /var/mmfs/gen/mmsdrfs? <br /><br />Ed<br /><br /><br />On Tue, 13 Jun 2017 08:30:18 +0000<br />"Sobey, Richard A" <r.sobey@imperial.ac.uk> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Oh? Nice to know - thanks - will try that method next.<br /> <br /> From: gpfsug-discuss-bounces@spectrumscale.org<br /> [mailto:gpfsug-discuss-bounces@spectrumscale.org] On Behalf Of Simon Thompson<br /> (IT Research Support) Sent: 13 June 2017 09:28 To: gpfsug main discussion<br /> list <gpfsug-discuss@spectrumscale.org> Subject: Re: [gpfsug-discuss] 'mmces<br /> address move' weirdness?<br /> <br /> Suspending the node doesn't stop the services though, we've done a bunch of<br /> testing by connecting to the "real" IP on the box we wanted to test and that<br /> works fine.<br /> <br /> OK, so you end up connecting to shares like<br /> \\<a href="http://192.168.1.20">192.168.1.20</a>\sharename<file://<a href="http://192.168.1.20/sharename">192.168.1.20/sharename</a>>, but its perfectly<br /> fine for testing purposes.<br /> <br /> In our experience, suspending the node has been fine for this as it moves the<br /> IP to a "working" node and keeps user service running whilst we test.<br /> <br /> Simon<br /> <br /> From:<br /> <gpfsug-discuss-bounces@spectrumscale.org<mailto:gpfsug-discuss-bounces@spectrumscale.org>><br /> on behalf of "Sobey, Richard A"<br /> <r.sobey@imperial.ac.uk<mailto:r.sobey@imperial.ac.uk>> Reply-To:<br /> "gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org>"<br /> <gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org>><br /> Date: Tuesday, 13 June 2017 at 09:08 To:<br /> "gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org>"<br /> <gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org>><br /> Subject: Re: [gpfsug-discuss] 'mmces address move' weirdness?<br /> <br /> Yes, suspending the node would do it, but in the case where you want to<br /> remove a node from service but keep it running for testing it's not ideal.<br /> <br /> I think you can set the IP address balancing policy to none which might do<br /> what we want. From:<br /> gpfsug-discuss-bounces@spectrumscale.org<mailto:gpfsug-discuss-bounces@spectrumscale.org><br /> [mailto:gpfsug-discuss-bounces@spectrumscale.org] On Behalf Of Simon Thompson<br /> (IT Research Support) Sent: 12 June 2017 21:06 To: gpfsug main discussion<br /> list<br /> <gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org>><br /> Subject: Re: [gpfsug-discuss] 'mmces address move' weirdness?<br /> <br /> mmces node suspend -N<br /> <br /> Is what you want. This will move the address and stop it being assigned one,<br /> otherwise the rebalance will occur. I think you can change the way it<br /> balances, but the default is to distribute.<br /> <br /> Simon<br /> <br /> From:<br /> <gpfsug-discuss-bounces@spectrumscale.org<mailto:gpfsug-discuss-bounces@spectrumscale.org>><br /> on behalf of "Sobey, Richard A"<br /> <r.sobey@imperial.ac.uk<mailto:r.sobey@imperial.ac.uk>> Reply-To:<br /> "gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org>"<br /> <gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org>><br /> Date: Monday, 12 June 2017 at 21:01 To:<br /> "gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org>"<br /> <gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org>><br /> Subject: Re: [gpfsug-discuss] 'mmces address move' weirdness?<br /> <br /> <br /> I think it's intended but I don't know why. The AUTH service became unhealthy<br /> on one of our CES nodes (SMB only) and we moved its float address elsewhere.<br /> CES decided to move it back again moments later despite the node not being<br /> fit.<br /> <br /> <br /> <br /> Sorry that doesn't really help but at least you're not alone!<br /> <br /><hr /><br /> From:gpfsug-discuss-bounces@spectrumscale.org<mailto:gpfsug-discuss-bounces@spectrumscale.org><br /> <gpfsug-discuss-bounces@spectrumscale.org<mailto:gpfsug-discuss-bounces@spectrumscale.org>><br /> on behalf of valdis.kletnieks@vt.edu<mailto:valdis.kletnieks@vt.edu><br /> <valdis.kletnieks@vt.edu<mailto:valdis.kletnieks@vt.edu>> Sent: 12 June 2017<br /> 20:41 To:<br /> gpfsug-discuss@spectrumscale.org<mailto:gpfsug-discuss@spectrumscale.org><br /> Subject: [gpfsug-discuss] 'mmces address move' weirdness?<br /> <br /> So here's our address setup:<br /> <br /> mmces address list<br /> <br /> Address Node Group Attribute<br /><hr /><br /> <a href="http://172.28.45.72">172.28.45.72</a> <a href="http://arproto1.ar">arproto1.ar</a>.nis.isb.internal isb none<br /> <a href="http://172.28.45.73">172.28.45.73</a> <a href="http://arproto2.ar">arproto2.ar</a>.nis.isb.internal isb none<br /> <a href="http://172.28.46.72">172.28.46.72</a> <a href="http://arproto2.ar">arproto2.ar</a>.nis.vtc.internal vtc none<br /> <a href="http://172.28.46.73">172.28.46.73</a> <a href="http://arproto1.ar">arproto1.ar</a>.nis.vtc.internal vtc none<br /> <br /> Having some nfs-ganesha weirdness on <a href="http://arproto2.ar">arproto2.ar</a>.nis.vtc.internal, so I try to<br /> move the address over to its pair so I can look around without impacting<br /> users. However, seems like something insists on moving it right back 60<br /> seconds later...<br /> <br /> Question 1: Is this expected behavior?<br /> Question 2: If it is, what use is 'mmces address move' if it just gets<br /> undone a few seconds later...<br /> <br /> (running on <a href="http://arproto2.ar">arproto2.ar</a>.nis.vtc.internal):<br /> <br /> ## (date; ip addr show | grep '\.72';mmces address move --ces-ip <a href="http://172.28.46.72">172.28.46.72</a><br /> --ces-node <a href="http://arproto1.ar">arproto1.ar</a>.nis.vtc.internal; while (/bin/true); do date; ip addr<br /> show | grep '\.72'; sleep 1; done;) | tee migrate.not.nailed.down Mon Jun 12<br /> 15:34:33 EDT 2017 inet <a href="http://172.28.46.72/26">172.28.46.72/26</a> brd <a href="http://172.28.46.127">172.28.46.127</a> scope global<br /> secondary bond1:0 Mon Jun 12 15:34:40 EDT 2017 Mon Jun 12 15:34:41 EDT 2017<br /> Mon Jun 12 15:34:42 EDT 2017<br /> Mon Jun 12 15:34:43 EDT 2017<br /> (skipped)<br /> Mon Jun 12 15:35:44 EDT 2017<br /> Mon Jun 12 15:35:45 EDT 2017<br /> inet <a href="http://172.28.46.72/26">172.28.46.72/26</a> brd <a href="http://172.28.46.127">172.28.46.127</a> scope global secondary bond1:0<br /> Mon Jun 12 15:35:46 EDT 2017<br /> inet <a href="http://172.28.46.72/26">172.28.46.72/26</a> brd <a href="http://172.28.46.127">172.28.46.127</a> scope global secondary bond1:0<br /> Mon Jun 12 15:35:47 EDT 2017<br /> inet <a href="http://172.28.46.72/26">172.28.46.72/26</a> brd <a href="http://172.28.46.127">172.28.46.127</a> scope global secondary bond1:0<br /> ^C<br /></blockquote><br /><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>