- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Re: Upgrading 3 members cluster
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Upgrading 3 members cluster
Hi,
I need to upgrade a 3 member cluster from R77.30 to R80.10
Until now i have been using the CP_Conectivity_Upgrade.
Where you upgrade first the two passive members to R80.10 and later the last one.
This time i need to upgrade one by one the members like this:
member1 - R77.30 active
member2 -R77.30 standby
member3 - R77.30 standby
to
member1 - R77.30 down
member2 - R77.30 down
member3 - R80.10 active
to
member1 - R77.30 down
member2 - R80.10 active
member3 - R80.10 standby
to
member1 - R80.10 active
member2 - R80.10 standby
member3 - R80.10 standby
Do i need to do a cpstop in member2 then follow the CP_Conectivity_Upgrade with member1 and 3. And then upgrade member1 and 2 one by one
Is this correct?
Thank you!
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've upgraded a number of 80.10 3-node clusters using the CU method and it has worked just fine.
However, the document I used did not exactly line up with 3 nodes.
With node 1 active, I did a cpstop on node 3. Then I upgraded node 2. Then I changed OS version in the cluster object and pushed policy with the "deploy to individual nodes" option. Then forced the fault as the CU document noted.
Then I went and upgraded the other 2 nodes, pushed policy and every thing worked.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"The more pertinent question is why are you upgrading to R80.10 and not R80.30, which is the widely recommended release? Even R80.20 would be a better choice here:"
There could be a million reasons why they can't go to a higher version. Their MDS being on 80.10 comes immediately to mind.
And perhaps they're not ready to upgrade to 80.20 or 80.30.
Sorry for being a little salty with this reply. I spent 17 hours this past Saturday and 5 hours on Sunday trying to get to 80.30 only to have the installer tank our primary MDS and having to revert a 200 gig snapshot in the slowest possible manner.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've upgraded a number of 80.10 3-node clusters using the CU method and it has worked just fine.
However, the document I used did not exactly line up with 3 nodes.
With node 1 active, I did a cpstop on node 3. Then I upgraded node 2. Then I changed OS version in the cluster object and pushed policy with the "deploy to individual nodes" option. Then forced the fault as the CU document noted.
Then I went and upgraded the other 2 nodes, pushed policy and every thing worked.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is what i needed to confirm.
Thanks!
