Gluster users - May 2016 - Gluster update

On 5/26/2016 5:11 PM, Gandalf Corvotempesta wrote:
>> Upgrade part of the Gluster infrastructure, then migrate your critical
>> items to the upgraded servers, then upgrade the rest, etc.
>
> This is exactly what i would like to archieve but is not possible.
>
I am not sure I understand what isn't possible.

Install the new version of Gluster on a new server or reuse an existing 
server.  Set it up as a new Gluster instance (not part of the existing 
one).  Migrate all of your VMs to it.  When they are all migrated, 
upgrade the remaining servers and bring them into the new Gluster instance.

Depending on your VM infrastructure, you might be able to do this with 
no downtime, otherwise each VM will be down for the amount of time it 
takes to migrate, but you aren't taking down the entire Gluster 
infrastructure which is what you have mentioned.

-Dj

2016-05-27 3:37 GMT+02:00 Dj Merrill <gluster at
deej.net>:
> Install the new version of Gluster on a new server or reuse an existing
> server.  Set it up as a new Gluster instance (not part of the existing
one).
> Migrate all of your VMs to it.  When they are all migrated, upgrade the
> remaining servers and bring them into the new Gluster instance.
Let's assume a huge cluster, with many petabytes.
Are you saying that for upgrading the existing one, I have to set up a new
petabyte cluster and move all images to the new cluster?
> Depending on your VM infrastructure, you might be able to do this with no
> downtime, otherwise each VM will be down for the amount of time it takes to
> migrate, but you aren't taking down the entire Gluster infrastructure
which
> is what you have mentioned.
If you have to move VM between two different clusters, you'll always have
a downtime, as you have to physically move files between servers.

Please read this:
http://www.gluster.org/community/documentation/index.php/Upgrade_to_3.7

"GlusterFS upgrade to 3.7.x
"a) Scheduling a downtime
For this approach, schedule a downtime and prevent all your clients
from accessing (umount your volumes, stop gluster Volumes..etc)the
servers."

If I understood properly, you have to bring down the WHOLE CLUSTER,
stopping all clients that are using it
and thus stopping ALL VMs running from that cluster.