[Gluster-users] glusterFS 3.6.2 migrate data by remove brick command

Tue Apr 14 13:15:30 UTC 2015

Jiri,

thanks, I totally missed the op-version part as it’s not mentioned in the upgrade instructions as per the link you send. Actually I read that link and because I do not use quota I didn’t use that script either.

Can I update the op-version when the volume is online and currently doing a rebalance or shall I stop the rebalance, set the new op-version and then start the rebalance again?

many thanks for all the input….

Met vriendelijke groet / kind regards,

Sander Zijlstra

| Linux Engineer | SURFsara | Science Park 140 | 1098XG Amsterdam | T +31 (0)6 43 99 12 47 | sander.zijlstra at surfsara.nl <mailto:sander.zijlstra at surfsara.nl> | www.surfsara.nl <http://www.surfsara.nl/> |

Regular day off on friday

> On 14 Apr 2015, at 15:01, Jiri Hoogeveen <j.hoogeveen at bluebillywig.com> wrote:
> 
> Hi Sander,
> 
> If I take a look at http://www.gluster.org/community/documentation/index.php/OperatingVersions <http://www.gluster.org/community/documentation/index.php/OperatingVersions>
> 
> Then operating-version=2 is for glusterfs version 3.4, so I guess you still will be using the old style.
> I think this is useful http://www.gluster.org/community/documentation/index.php/Upgrade_to_3.6 <http://www.gluster.org/community/documentation/index.php/Upgrade_to_3.6>
> 
> And don’t forget to upgrade the clients also.
> 
> 
> Grtz, Jiri
> 
>> On 14 Apr 2015, at 14:14, Sander Zijlstra <sander.zijlstra at surfsara.nl <mailto:sander.zijlstra at surfsara.nl>> wrote:
>> 
>> Jiri,
>> 
>> thanks for the information, I just commented on a question about op-version….
>> 
>> I upgraded all systems to 3.6.2 does this mean they all will use the correct op-version and will not revert to old style behaviour?
>> 
>> Met vriendelijke groet / kind regards,
>> 
>> Sander Zijlstra
>> 
>> | Linux Engineer | SURFsara | Science Park 140 | 1098XG Amsterdam | T +31 (0)6 43 99 12 47 | sander.zijlstra at surfsara.nl <mailto:sander.zijlstra at surfsara.nl> | www.surfsara.nl <http://www.surfsara.nl/> |
>> 
>> Regular day off on friday
>> 
>>> On 14 Apr 2015, at 14:11, Jiri Hoogeveen <j.hoogeveen at bluebillywig.com <mailto:j.hoogeveen at bluebillywig.com>> wrote:
>>> 
>>> Hi Sander,
>>> 
>>> 
>>>> Since version 3.6 the remove brick command migrates the data away from the brick being removed, right?
>>> It should :)
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3/pdf/Administration_Guide/Red_Hat_Storage-3-Administration_Guide-en-US.pdf <https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3/pdf/Administration_Guide/Red_Hat_Storage-3-Administration_Guide-en-US.pdf> page 100, is I think a good start.
>>> I think this is the most complete documentation.
>>> 
>>>> When I have replicated bricks (replica 2), I also need to do "remove brick <volume> replica 2 brick1 brick2 …. , right?
>>> 
>>> Yes, you need to remove both replica’s at the same time.
>>> 
>>> 
>>>> Last but not least, is there any way to tell how long a “remove brick” will take when it’s moving the data? I have dual 10GB ethernet between the cluster members and the brick storage is a RAID-6 set which can read 400-600MB/sec without any problems.
>>> 
>>> 
>>> Depends on the size of the disk, the number of files and type of file. Network speed is less a issu, then the IO on the disks/brick.
>>> To migratie data from one disk to a other (is like self-healing) GlusterFS will do a scan of all files on the disk, which can cause a high IO on the disk.
>>> 
>>> Because you had also some performance issues, when you added some bricks, I will expect the same issue with remove brick. So do this at night if possible.
>>> 
>>> 
>>> Grtz, Jiri
>>> 
>>> 
>>>> On 14 Apr 2015, at 12:53, Sander Zijlstra <sander.zijlstra at surfsara.nl <mailto:sander.zijlstra at surfsara.nl>> wrote:
>>>> 
>>>> LS,
>>>> 
>>>> I’m planning to decommission a few servers from my cluster, so to confirm:
>>>> 
>>>> Since version 3.6 the remove brick command migrates the data away from the brick being removed, right?
>>>> When I have replicated bricks (replica 2), I also need to do "remove brick <volume> replica 2 brick1 brick2 …. , right?
>>>> 
>>>> Last but not least, is there any way to tell how long a “remove brick” will take when it’s moving the data? I have dual 10GB ethernet between the cluster members and the brick storage is a RAID-6 set which can read 400-600MB/sec without any problems.
>>>> 
>>>> Met vriendelijke groet / kind regards,
>>>> 
>>>> Sander Zijlstra
>>>> 
>>>> | Linux Engineer | SURFsara | Science Park 140 | 1098XG Amsterdam | T +31 (0)6 43 99 12 47 | sander.zijlstra at surfsara.nl <mailto:sander.zijlstra at surfsara.nl> | www.surfsara.nl <http://www.surfsara.nl/> |
>>>> 
>>>> Regular day off on friday
>>>> 
>>>> _______________________________________________
>>>> Gluster-users mailing list
>>>> Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>>>> http://www.gluster.org/mailman/listinfo/gluster-users <http://www.gluster.org/mailman/listinfo/gluster-users>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20150414/33bce587/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20150414/33bce587/attachment.sig>