mmces node suspend -N Is what you want. This will move the address and stop it being assigned one, otherwise the rebalance will occur. I think you can change the way it balances, but the default is to distribute.
Simon From: <[email protected]<mailto:[email protected]>> on behalf of "Sobey, Richard A" <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Monday, 12 June 2017 at 21:01 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [gpfsug-discuss] 'mmces address move' weirdness? I think it's intended but I don't know why. The AUTH service became unhealthy on one of our CES nodes (SMB only) and we moved its float address elsewhere. CES decided to move it back again moments later despite the node not being fit. Sorry that doesn't really help but at least you're not alone! ________________________________ From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> on behalf of [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: 12 June 2017 20:41 To: [email protected]<mailto:[email protected]> Subject: [gpfsug-discuss] 'mmces address move' weirdness? So here's our address setup: mmces address list Address Node Group Attribute ------------------------------------------------------------------------- 172.28.45.72 arproto1.ar.nis.isb.internal isb none 172.28.45.73 arproto2.ar.nis.isb.internal isb none 172.28.46.72 arproto2.ar.nis.vtc.internal vtc none 172.28.46.73 arproto1.ar.nis.vtc.internal vtc none Having some nfs-ganesha weirdness on arproto2.ar.nis.vtc.internal, so I try to move the address over to its pair so I can look around without impacting users. However, seems like something insists on moving it right back 60 seconds later... Question 1: Is this expected behavior? Question 2: If it is, what use is 'mmces address move' if it just gets undone a few seconds later... (running on arproto2.ar.nis.vtc.internal): ## (date; ip addr show | grep '\.72';mmces address move --ces-ip 172.28.46.72 --ces-node arproto1.ar.nis.vtc.internal; while (/bin/true); do date; ip addr show | grep '\.72'; sleep 1; done;) | tee migrate.not.nailed.down Mon Jun 12 15:34:33 EDT 2017 inet 172.28.46.72/26 brd 172.28.46.127 scope global secondary bond1:0 Mon Jun 12 15:34:40 EDT 2017 Mon Jun 12 15:34:41 EDT 2017 Mon Jun 12 15:34:42 EDT 2017 Mon Jun 12 15:34:43 EDT 2017 (skipped) Mon Jun 12 15:35:44 EDT 2017 Mon Jun 12 15:35:45 EDT 2017 inet 172.28.46.72/26 brd 172.28.46.127 scope global secondary bond1:0 Mon Jun 12 15:35:46 EDT 2017 inet 172.28.46.72/26 brd 172.28.46.127 scope global secondary bond1:0 Mon Jun 12 15:35:47 EDT 2017 inet 172.28.46.72/26 brd 172.28.46.127 scope global secondary bond1:0 ^C
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
