Suspending the node doesn't stop the services though, we've done a bunch of testing by connecting to the "real" IP on the box we wanted to test and that works fine.
OK, so you end up connecting to shares like \\192.168.1.20\sharename, but its perfectly fine for testing purposes. In our experience, suspending the node has been fine for this as it moves the IP to a "working" node and keeps user service running whilst we test. 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: Tuesday, 13 June 2017 at 09:08 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [gpfsug-discuss] 'mmces address move' weirdness? Yes, suspending the node would do it, but in the case where you want to remove a node from service but keep it running for testing it’s not ideal. I think you can set the IP address balancing policy to none which might do what we want. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Simon Thompson (IT Research Support) Sent: 12 June 2017 21:06 To: gpfsug main discussion list <[email protected]<mailto:[email protected]>> Subject: Re: [gpfsug-discuss] 'mmces address move' weirdness? 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
