2018-03-12 10:31 AM
past friday during an operation given as NDO we've had a service interruption on NAS component.
We had to move the root aggregate from some old disks to new ones and we've literally followed the procedure reported here (our cDOT is 8.3.2P9)
In a very simple way it says:
Well, NFS was restarted and all servers and apps belonging to it went down! I let you imagine customer reaction...
Also console after this command:
system node modify -node node01 -eligibility false
give us a warning about SAN disruption. As I wrote it did not matter us.
Only after that we've found on manual this, but as usual manuals are always less updated than knowledgebase so it could be the last place where to find fresh informations!
Moving epsilon for certain manually initiated takeovers
Note: Although cluster formation voting can be modified by using the cluster modify -eligibility false command, you should avoid this except for situations such as restoring the node configuration or prolonged node maintenance. If you set a node to be ineligible, it stops serving SAN data until the node is reset to eligible and rebooted. NAS data access to the node might also be affected when the node is ineligible.
And, what does it mean "might be". I translate that as a "nobody knows, try..."
Now the most important question (we must migrate other three nodes!) is this:
Assuming that we've well understood that 1. migrate lif and only 2. epsilon false, it there an official answer/doc with updated information that ensure that is this the right procedure to avoid also NAS protocols interruption?
Thank you very much,
Solved! SEE THE SOLUTION
2018-03-12 06:18 PM
As you've experienced service disruption at a client site, I would suggest you should log a support case with our support centre, and ask for clarification of the documentation and correct steps to avoid an outage in the future.
I've brought this issue and this thread to the attention of the writer of that KB article.
2018-03-13 12:41 AM
2018-03-13 03:27 AM
Just for clarification, what Giacomo is refering to is this:
2018-03-13 04:01 AM
Thank you very much Sebastian.
Now we'll attempt to have some official answer by support on the sequence that you're suggesting, and on which I completely agree as suspected after that fault.
My best regards,