On 08/23/2016 01:13 PM, Aravinda wrote:
regards
Aravinda
On Tuesday 23 August 2016 09:32 PM, Pranith Kumar Karampuri wrote:
On Tue, Aug 23, 2016 at 9:27 PM, Aravinda <avishwan@xxxxxxxxxx
<mailto:avishwan@xxxxxxxxxx>> wrote:
Today I discussed about the topic with Rajesh, Avra and Kotresh.
Summary as below
- Instead of exposing eventsd to external world why not expose a
Glusterd RPC for gf_event, Since Glusterd already has logic for
backup volfile server.
- Gluster Clients to Glusterd using RPC, Glusterd will send
message to local eventsd.
Any suggestions for this approach?
If I remember correctly this is something we considered before we
finalized on exposing eventsd. I think the reason was that this
approach takes two hops which we didn't like in the discussion at the
time. Did any other parameter change for reconsidering this approach?
- No extra auth required other than existing glusterd communication
- Backup volfile server for sending message to other glusterd of server
if one server is down
- Events traffic is not heavy two hops may be acceptable(?)
Depending on the number of clients connected to a glusterd and the state
of the cluster, the intensity of eventing traffic might not be
insignificant. We have come across instances where management operations
have timed out due to glusterd being overwhelmed with RPC messages. We
certainly would not want our eventing infrastructure to burden
glusterd(s) further and worsen the operational state of the cluster.
Have we considered any throttling mechanism if events are to be routed
through glusterd?
Thanks,
Vijay
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
