Re: Replace brick 3.4.2 with 3.6.2?

[John Gardeniers <jgardeniers@xxxxxxxxxxxxxxxxx>]

Hi Aytac,

Two gluster server nodes. Two volumes, each being a replica 2 of one brick.

One volume is currently still being prepared, so I won't mention it any further.

The other node is used as the main storage domain for our RHEV environment, which connects natively using the gluster client. The configuration at the RHEV end points to one node, with the second node configured as a failover. Clearly, any changes to that volume require extreme caution and planned downtime.

At this stage the VMs do not directly access the gluster storage, although one VM will soon have a gluster volume attached to it (the one that's still being prepared), as it requires a lot of storage space.

We use RHEV bare-metal hypervisors, so there is no option to upgrade, other than to install new versions as they become available. They are installed from an ISO, just like a regular distro, but these are extremely cut down versions of RHEL6, with all the good stuff left out. They could potentially be upgraded by building the client from source and copying it over but I'm not going down that road, for multiple reasons.

regards,
John

On 25/02/15 10:36, aytac zeren wrote:

Hi John,

Would you please share your scenario? 

* How many nodes are running as gluster server?

* Which application is accesing gluster volume by which means (NFS, CIFS, Gluster Client)?

* Are you accessing volume through a client or the clients are accessing volume themselves (like KVM nodes)

Best Regards

Aytac

On Wed, Feb 25, 2015 at 1:18 AM, John Gardeniers <jgardeniers@xxxxxxxxxxxxxxxxx> wrote:

Problem solved, more or less.

After reading Aytac's comment about 3.6.2 not being considered stable yet I removed it from the new node,  removed /var/lib/glusterd/, rebooted (just to be sure) and installed 3.5.3. After detaching and re-probing the peer the replace-brick command worked and the volume is currently happily undergoing a self-heal. At a later and more convenient time I'll upgrade the 3.4.2 node to the same version. As previously stated, I cannot upgrade the clients, so they will just have to stay where they are.

regards,
John

On 25/02/15 08:27, aytac zeren wrote:

Hi John,

3.6.2 is a major release and introduces some new features in cluster wide concept. Additionally it is not stable yet. The best way of doing it would be establishing another 3.6.2 cluster, accessing 3.4.0 cluster via nfs or native client, and copying content to 3.6.2 cluster gradually. While your volume size decreases on 3.4.0 cluster, you can unmount 3.4.0 members from cluster, upgrade them and add 3.6.2 trusted pool with brick. Please be careful while doing this operation, as number of nodes in your cluster should be reliable with your cluster design. (Stripped, Replicated, Distributed or a combination of them).

Notice: I don't take any responsibility on the actions you have undertaken with regards to my recommendations, as my recommendations are general and does not take your archtiectural design into consideration.

BR

Aytac

On Tue, Feb 24, 2015 at 11:19 PM, John Gardeniers <jgardeniers@xxxxxxxxxxxxxxxxx> wrote:

Hi All,

We have a gluster volume consisting of a single brick, using replica 2. Both nodes are currently running gluster 3.4.2 and I wish to replace one of the nodes with a new server (rigel), which has gluster 3.6.2

Following this link:

https://access.redhat.com/documentation/en-US/Red_Hat_Storage/2.1/html/Administration_Guide/Replacing_an_Old_Brick_with_a_New_Brick_on_a_Replicate_or_Distribute-replicate_Volume.html

I tried to do a replace brick but got "volume replace-brick: failed: Host rigel is not in 'Peer in Cluster' state". Is this due to a version incompatibility or is it due to some other issue? A bit of googling reveals the error message in bug reports but I've not yet found anything that applies to this specific case.

Incidentally, the clients (RHEV bare metal hypervisors, so we have no upgrade option) are running 3.4.0. Will this be a problem if the nodes are on 3.6.2?

regards,
John

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users