[Gluster-devel] Notes on "brick multiplexing" in 4.0
vbellur at redhat.com
Wed Jun 17 12:04:46 UTC 2015
On Wednesday 17 June 2015 02:21 AM, Kaushal M wrote:
> One more question. I keep hearing about QoS for volumes as a feature.
> How will we guarantee service quality for all the bricks from a single
> server? Even if we weren't doing QoS, we make sure that operations on
> brick doesn't DOS the others. We already keep hearing from users about
> self-healing causing problems for the clients. Self-healing, rebalance
> running simultaneously on multiple volumes in a multiplexed bricks
> environment would most likely be disastrous.
Applying per tenant rules might be easier with a multiplexed brick than
on a non-multiplexed one. Each tenant would need some slice of the
overall resources and a single instance of the QoS translator loaded in
the multiplexed brick can address this requirement. Same with
management/internal operations like self-healing, rebalance etc. We
would need knobs/policies to ensure that management operations do not
steal the thunder away from user driven IO operations.
On the other hand, if we have one process per volume/tenant preventing
problems like noisy neighbors in a multi-tenant situation can be harder
to address as each tenant is unaware of the global resource usage.
> On Tue, Jun 16, 2015 at 11:01 PM, Jeff Darcy <jdarcy at redhat.com> wrote:
>>> Reading through that, it sounds like a well thought out approach.
>>> Did you consider a super-lightweight version first, which only has
>>> a process listening on one port for multiplexing traffic, and then
>>> passes the traffic to individual processes running on the server?
>>> eg similar to how common IPv4 NAT does, but for gluster traffic
>> Yes, I thought about it. Depending on how it's done, it could
>> alleviate the too-many-ports problem, but it doesn't really address
>> the uncontrolled contention for CPU, memory, and so on. In a way
>> it would make that worse, as it's one more process to keep
>> switching in and out among the others. Sure would have been nice,
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
> Gluster-devel mailing list
> Gluster-devel at gluster.org
More information about the Gluster-devel