On 05/05/2015 02:27 AM, Josh Boon wrote:
Hey folks,
I'll be doing an upgrade soon for my core hypervisors running qemu 2.0
built with Gluster 3.5.2 connecting to a replicated 3.5.2 volume.
The upgrade path I'd like to do is:
1. migrate all machines to node not being upgraded
2. prevent client heals as documented over
at http://www.gluster.org/community/documentation/index.php/Upgrade_to_3.6
3. stop gluster server and gluster processes on node being upgraded
4. upgrade kvm, gluster, and supporting packages to required to 3.6.3
5. restart node being upgraded
6. Node joins pool again except one node will be running 3.6.3 and the
other 3.5.2
7. perform heal to ensure data correct
8. migrate all machines over to newly upgraded node
9. repeat steps 3-5 for other node
10. perform heal to ensure data correct
11. rebalance machines as necessary
12. upgrade complete
This method has the obvious issue of will the two nodes behave as
expected when on different major versions with the gain of no downtime
for vm's. Is this method too risky? Has anyone tried it? Would
appreciate any input.
One way to gain confidence is to perform this on a test setup to know
more about how your workload is affected by this upgrade?
Pranith
Thanks,
Josh
_______________________________________________
Gluster-users mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-users
