Before I undertake this upgrade I thought I would see if anyone has any advice on how to do this on a production system. Maybe someone has already "fought this dragon". Current config Gluster V3.0.0. This has been in production for over 16 months: 2 servers with 8 x 2TB hard drives (bricks) replicated svr1:vol1 <-> srv2:vol1 -> rbrick1 svr1:vol2 <-> srv2:vol2 -> rbrick2 svr1:vol3 <-> srv2:vol3 -> rbrick3 svr1:vol4 <-> srv2:vol4 -> rbrick4 svr1:vol5 <-> srv2:vol5 -> rbrick5 svr1:vol6 <-> srv2:vol6 -> rbrick6 svr1:vol7 <-> srv2:vol7 -> rbrick7 svr1:vol8 <-> srv2:vol8 -> rbrick8 Then distributed across all 8 replicated bricks rbrick1+rbrick2+rbrick3+rbrick4+>rbrick5+>rbrick6+rbrick7+rbrick8 -> dhtvolume (16TB dht glusterfs volume) I'm currently using over 12TB of storage and am seeing a time when I will run out of space. I want to upgrade our storage system to Gluster V3.3 and upgrade hard drives to 4TB models. I purchased a new server (same base hardware as the existing ones), but outfitted with new controller (that supports 4TB drives) and with 8 x 4TB drives (this is all working fine). When I get the first server running and populated I want to take one of the two old servers offline to upgrade HD controller and hard drives to match the new server and then replicate across the bricks/servers the same as I was doing previously. BTW-I'd rather not have to purchase an additional (4th) server at this time, unless it is totally necessary. I'm going to end up with a spare as things are now. Problems: 1) Is there any way to have the V3.0 subsystem replicate to the V3.3 subsystem? 2) If not I'm going to have to manually rsync the files from the old Gluster V3.0 to new Gluster V3.3 on some machine. Can I load both client versions on a single machine for the copy? If not, how can I accomplish this upgrade? 3) Given that this is a production system that is used 24 x 7, how do I make the changes while system is running with a minimum of downtime? Hopefully I'm not making this more difficult that is required. Thanks in advance for ANY pointers. Regards, Larry Bates vitalEsafe, Inc.
