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.
On Tue, Jun 16, 2015 at 11:01 PM, Jeff Darcy <[email protected]> wrote: >> Reading through that, it sounds like a well thought out approach. > > Thanks! > >> 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, > though. > _______________________________________________ > Gluster-devel mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-devel
