Re: [Gluster-users] thin arbiter vs standard arbiter

2018-08-02 Thread Dmitry Melekhov 



02.08.2018 18:40, Ashish Pandey пишет:



I think it should be rephrased a little bit -

"When one brick is up: Fail FOP with EIO."
should be
"When only one brick is up out of 3 bricks: Fail FOP with EIO."

So we have 2 data bricks and one thin arbiter brick. Out of these 3 
bricks if only one brick is UP then we will fail IO.


---
Ashish



Hello!

Thank you!

This is what we need :-)




*From: *"Dmitry Melekhov" 
*To: *gluster-users@gluster.org, atumb...@redhat.com
*Sent: *Thursday, August 2, 2018 4:59:41 PM
*Subject: *Re: [Gluster-users] thin arbiter vs standard arbiter

01.08.2018 22:04, Amar Tumballi пишет:

This recently added document talks about some of the
technicalities of the feature:


https://docs.gluster.org/en/latest/Administrator%20Guide/Thin-Arbiter-Volumes/

Please go through and see if it answers your questions.

-Amar


Hello!

I have question:

Manual says:


"When one brick is up: Fail FOP with EIO."

So, if we have 2 nodes with thin arbiter and only one node is up, i.e. 
second node is down for some reason, then I/O will be stopped.

Any reasons to have two nodes then?

Could you tell me is manual right here or it is misprint?

Thank you!




On Wed, Aug 1, 2018 at 11:09 PM, wkmail mailto:wkm...@bneit.com>> wrote:

I see mentions of thin arbiter in the 4.x notes and I am
intrigued.

As I understand it, the thin arbiter volume is

a) receives its data on an async basis (thus it can be on a
slower link). Thus gluster isn't waiting around to verify if
it actually got the data.

b) is only consulted in situations where Gluster needs that
third vote, otherwise it is not consulted.

c) Performance should therefore be better because Gluster is
only seriously talking to 2 nodes instead of 3 nodes (as in
normal arbiter or rep 3)

Am I correct?

If so, is thin arbiter ready for production or at least use on
non-critical workloads?

How safe is it for VMs images (and/or VMs with sharding)?

How much faster is thin arbiter setup over a normal arbiter
given that the normal data only really sees the metadata?

In a degraded situation (i.e. loss of one real node), would
having a thin arbiter on a slow link be problematic until
everything is healed and returned to normal?

Sincerely,

-wk

___
Gluster-users mailing list
Gluster-users@gluster.org <mailto:Gluster-users@gluster.org>
https://lists.gluster.org/mailman/listinfo/gluster-users





-- 
Amar Tumballi (amarts)



___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users



___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users



___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] thin arbiter vs standard arbiter

2018-08-02 Thread WK Lists 


Hi WK,


There are a few patches [1]  that are still undergoing review . It 
would be good to wait for some more time until trying it out. If you 
are interested in testing, I'll be happy to inform you once they get 
merged.


[1] https://review.gluster.org/#/c/20095/, 
https://review.gluster.org/#/c/20103/, 
https://review.gluster.org/#/c/20577/


Regards,
Ravi


yes please let me know when you think the thin-arbiter is "testing" ready.

Again, I have some VM environments that can handle a storage disaster 
(though it would be annoying)

___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] thin arbiter vs standard arbiter

2018-08-02 Thread Ashish Pandey 


I think it should be rephrased a little bit - 

"When one brick is up: Fail FOP with EIO." 
should be 
"When only one brick is up out of 3 bricks: Fail FOP with EIO." 

So we have 2 data bricks and one thin arbiter brick. Out of these 3 bricks if 
only one brick is UP then we will fail IO. 

--- 
Ashish 


- Original Message -

From: "Dmitry Melekhov"  
To: gluster-users@gluster.org, atumb...@redhat.com 
Sent: Thursday, August 2, 2018 4:59:41 PM 
Subject: Re: [Gluster-users] thin arbiter vs standard arbiter 

01.08.2018 22:04, Amar Tumballi пишет: 



This recently added document talks about some of the technicalities of the 
feature: 

https://docs.gluster.org/en/latest/Administrator%20Guide/Thin-Arbiter-Volumes/ 

Please go through and see if it answers your questions. 

-Amar 



Hello! 

I have question: 

Manual says: 


"When one brick is up: Fail FOP with EIO." 

So, if we have 2 nodes with thin arbiter and only one node is up, i.e. second 
node is down for some reason, then I/O will be stopped. 
Any reasons to have two nodes then? 

Could you tell me is manual right here or it is misprint? 

Thank you! 







On Wed, Aug 1, 2018 at 11:09 PM, wkmail < wkm...@bneit.com > wrote: 


I see mentions of thin arbiter in the 4.x notes and I am intrigued. 

As I understand it, the thin arbiter volume is 

a) receives its data on an async basis (thus it can be on a slower link). Thus 
gluster isn't waiting around to verify if it actually got the data. 

b) is only consulted in situations where Gluster needs that third vote, 
otherwise it is not consulted. 

c) Performance should therefore be better because Gluster is only seriously 
talking to 2 nodes instead of 3 nodes (as in normal arbiter or rep 3) 

Am I correct? 

If so, is thin arbiter ready for production or at least use on non-critical 
workloads? 

How safe is it for VMs images (and/or VMs with sharding)? 

How much faster is thin arbiter setup over a normal arbiter given that the 
normal data only really sees the metadata? 

In a degraded situation (i.e. loss of one real node), would having a thin 
arbiter on a slow link be problematic until everything is healed and returned 
to normal? 

Sincerely, 

-wk 

___ 
Gluster-users mailing list 
Gluster-users@gluster.org 
https://lists.gluster.org/mailman/listinfo/gluster-users 








-- 
Amar Tumballi (amarts) 


___
Gluster-users mailing list Gluster-users@gluster.org 
https://lists.gluster.org/mailman/listinfo/gluster-users 






___ 
Gluster-users mailing list 
Gluster-users@gluster.org 
https://lists.gluster.org/mailman/listinfo/gluster-users 

___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] thin arbiter vs standard arbiter

2018-08-02 Thread Dmitry Melekhov 

01.08.2018 22:04, Amar Tumballi пишет:
This recently added document talks about some of the technicalities of 
the feature:


https://docs.gluster.org/en/latest/Administrator%20Guide/Thin-Arbiter-Volumes/

Please go through and see if it answers your questions.

-Amar


Hello!

I have question:

Manual says:


"When one brick is up: Fail FOP with EIO."

So, if we have 2 nodes with thin arbiter and only one node is up, i.e. 
second node is down for some reason, then I/O will be stopped.

Any reasons to have two nodes then?

Could you tell me is manual right here or it is misprint?

Thank you!





On Wed, Aug 1, 2018 at 11:09 PM, wkmail > wrote:


I see mentions of thin arbiter in the 4.x notes and I am intrigued.

As I understand it, the thin arbiter volume is

a) receives its data on an async basis (thus it can be on a slower
link). Thus gluster isn't waiting around to verify if it actually
got the data.

b) is only consulted in situations where Gluster needs that third
vote, otherwise it is not consulted.

c) Performance should therefore be better because Gluster is only
seriously talking to 2 nodes instead of 3 nodes (as in normal
arbiter or rep 3)

Am I correct?

If so, is thin arbiter ready for production or at least use on
non-critical workloads?

How safe is it for VMs images (and/or VMs with sharding)?

How much faster is thin arbiter setup over a normal arbiter given
that the normal data only really sees the metadata?

In a degraded situation (i.e. loss of one real node), would having
a thin arbiter on a slow link be problematic until everything is
healed and returned to normal?

Sincerely,

-wk

___
Gluster-users mailing list
Gluster-users@gluster.org 
https://lists.gluster.org/mailman/listinfo/gluster-users






--
Amar Tumballi (amarts)


___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users



___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] thin arbiter vs standard arbiter

2018-08-01 Thread Ravishankar N 



On 08/02/2018 06:26 AM, W Kern wrote:



On 8/1/18 11:04 AM, Amar Tumballi wrote:
This recently added document talks about some of the technicalities 
of the feature:


https://docs.gluster.org/en/latest/Administrator%20Guide/Thin-Arbiter-Volumes/

Please go through and see if it answers your questions.

-Amar




Well yes that does answer some. By skipping a lot more of the arbiter 
traffic, there may be some noticeable performance benefits especially 
in an older 1G network.

At least until you have to deal with a failure situation.

Though the "would you use it on a VM, either now or when the code is 
more seasoned?" question is still there.


I'm willing to try it out on some non-critical VMs (cloud-native 
stuff, where I always spawn from a golden image), but if it is not 
ready for production, then I don't want to bother with it at the moment.

Hi WK,

There are a few patches [1]  that are still undergoing review .  It 
would be good to wait for some more time until trying it out. If you are 
interested in testing, I'll be happy to inform you once they get merged.


[1] https://review.gluster.org/#/c/20095/, 
https://review.gluster.org/#/c/20103/, https://review.gluster.org/#/c/20577/


Regards,
Ravi




-wk



On Wed, Aug 1, 2018 at 11:09 PM, wkmail > wrote:


I see mentions of thin arbiter in the 4.x notes and I am intrigued.

As I understand it, the thin arbiter volume is

a) receives its data on an async basis (thus it can be on a
slower link). Thus gluster isn't waiting around to verify if it
actually got the data.

b) is only consulted in situations where Gluster needs that third
vote, otherwise it is not consulted.

c) Performance should therefore be better because Gluster is only
seriously talking to 2 nodes instead of 3 nodes (as in normal
arbiter or rep 3)

Am I correct?

If so, is thin arbiter ready for production or at least use on
non-critical workloads?

How safe is it for VMs images (and/or VMs with sharding)?

How much faster is thin arbiter setup over a normal arbiter given
that the normal data only really sees the metadata?

In a degraded situation (i.e. loss of one real node), would
having a thin arbiter on a slow link be problematic until
everything is healed and returned to normal?

Sincerely,

-wk

___
Gluster-users mailing list
Gluster-users@gluster.org 
https://lists.gluster.org/mailman/listinfo/gluster-users






--
Amar Tumballi (amarts)





___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users


___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] thin arbiter vs standard arbiter

2018-08-01 Thread W Kern 



On 8/1/18 11:04 AM, Amar Tumballi wrote:
This recently added document talks about some of the technicalities of 
the feature:


https://docs.gluster.org/en/latest/Administrator%20Guide/Thin-Arbiter-Volumes/

Please go through and see if it answers your questions.

-Amar




Well yes that does answer some. By skipping a lot more of the arbiter 
traffic, there may be some noticeable performance benefits especially in 
an older 1G network.

At least until you have to deal with a failure situation.

Though the "would you use it on a VM, either now or when the code is 
more seasoned?" question is still there.


I'm willing to try it out on some non-critical VMs (cloud-native stuff, 
where I always spawn from a golden image), but if it is not ready for 
production, then I don't want to bother with it at the moment.


-wk



On Wed, Aug 1, 2018 at 11:09 PM, wkmail > wrote:


I see mentions of thin arbiter in the 4.x notes and I am intrigued.

As I understand it, the thin arbiter volume is

a) receives its data on an async basis (thus it can be on a slower
link). Thus gluster isn't waiting around to verify if it actually
got the data.

b) is only consulted in situations where Gluster needs that third
vote, otherwise it is not consulted.

c) Performance should therefore be better because Gluster is only
seriously talking to 2 nodes instead of 3 nodes (as in normal
arbiter or rep 3)

Am I correct?

If so, is thin arbiter ready for production or at least use on
non-critical workloads?

How safe is it for VMs images (and/or VMs with sharding)?

How much faster is thin arbiter setup over a normal arbiter given
that the normal data only really sees the metadata?

In a degraded situation (i.e. loss of one real node), would having
a thin arbiter on a slow link be problematic until everything is
healed and returned to normal?

Sincerely,

-wk

___
Gluster-users mailing list
Gluster-users@gluster.org 
https://lists.gluster.org/mailman/listinfo/gluster-users






--
Amar Tumballi (amarts)



___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] thin arbiter vs standard arbiter

2018-08-01 Thread Amar Tumballi 
This recently added document talks about some of the technicalities of the
feature:

https://docs.gluster.org/en/latest/Administrator%20Guide/Thin-Arbiter-Volumes/

Please go through and see if it answers your questions.

-Amar


On Wed, Aug 1, 2018 at 11:09 PM, wkmail  wrote:

> I see mentions of thin arbiter in the 4.x notes and I am intrigued.
>
> As I understand it, the thin arbiter volume is
>
> a) receives its data on an async basis (thus it can be on a slower link).
> Thus gluster isn't waiting around to verify if it actually got the data.
>
> b) is only consulted in situations where Gluster needs that third vote,
> otherwise it is not consulted.
>
> c) Performance should therefore be better because Gluster is only
> seriously talking to 2 nodes instead of 3 nodes (as in normal arbiter or
> rep 3)
>
> Am I correct?
>
> If so, is thin arbiter ready for production or at least use on
> non-critical workloads?
>
> How safe is it for VMs images (and/or VMs with sharding)?
>
> How much faster is thin arbiter setup over a normal arbiter given that the
> normal data only really sees the metadata?
>
> In a degraded situation (i.e. loss of one real node), would having a thin
> arbiter on a slow link be problematic until everything is healed and
> returned to normal?
>
> Sincerely,
>
> -wk
>
> ___
> Gluster-users mailing list
> Gluster-users@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
>
>
>


-- 
Amar Tumballi (amarts)
___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users