Anil, Agree to your points, that we still have to goto a remote node, once we reach the plugin side. But there are other synchronization issues in the code as well, due to several of the events landing up on different nodes, which have been fixed in many cases using EOS/CLusterSingleton(now entity owner can end up on another node as well). So, if we can get rid of such complexities for 3 node, that helps as well. But ofcourse, it will be always better if there is intelligence to make one particular end to end call(eg : boot VM1) to go through one single node ;), than making it single node for all operations for all shards. Thanks, Faseela
From: Anil Vishnoi [mailto:vishnoia...@gmail.com] Sent: Saturday, June 09, 2018 6:10 AM To: Faseela K <faseel...@ericsson.com> Cc: Tom Pantelis <tompante...@gmail.com>; Michael Vorburger <vorbur...@redhat.com>; infrautils-...@lists.opendaylight.org; controller-dev <controller-dev@lists.opendaylight.org>; genius-...@lists.opendaylight.org Subject: Re: [controller-dev] [infrautils-dev] Sharding evolution So reading the wiki page, i was able to understand that there are two main issues (1) Transaction management and rollback -- i was not able to figure out the relevance with distributed shard location. (2) Performance in cluster node -- if shard leaders are distributed, any transaction will involve network latency because transaction need to be routed to leader controller ? Let me know if there is any other reason that i missed from the wiki. I think (2) is something that you are addressing by localizing the shard on one controller? But that just solves probably 1 problem, you still have following problems if you really want to solve the problem (1) Ownership of OVSDB devices are distributed across the 3 nodes ( and they all depends on ClusteredDataChangeListeners, and that has cost as well). (2) Ownership of openflow devices are distributed across the 3 nodes. (3) Operational data replication across the three node cluster also has cost and if your business logic depends on that, that will hit the performance as well. So by locating the shards at one place, you might solve one (minor) problem in the whole end to end stack to improve the performance. Probably the quickest solution to significantly improve the end to end performance is that you force the ovsdb and openflow devices to be owned by the same controller as well. But if you do that, the only remaining purpose of cluster is to use it for data replication across two more nodes with the 2/3 performance hit in data store performance :). On Fri, Jun 8, 2018 at 5:06 PM, Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote: [Changed the subject] Anil, now you can ask ;) https://wiki.opendaylight.org/view/Genius:Sharding_evolution Thanks, Faseela From: Anil Vishnoi [mailto:vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>] Sent: Saturday, June 09, 2018 5:30 AM To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> Cc: Tom Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>>; Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>; infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>; controller-dev <controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>; genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org> Subject: Re: [controller-dev] [infrautils-dev] OK to resurrect c/64522 to first move infrautils.DiagStatus integration for datastore from genius to controller, and then improve it for GENIUS-138 ? On Fri, Jun 8, 2018 at 4:50 PM, Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote: From: Tom Pantelis [mailto:tompante...@gmail.com<mailto:tompante...@gmail.com>] Sent: Saturday, June 09, 2018 2:24 AM To: Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>> Cc: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>>; Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>; infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>; controller-dev <controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>; genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org> Subject: Re: [controller-dev] [infrautils-dev] OK to resurrect c/64522 to first move infrautils.DiagStatus integration for datastore from genius to controller, and then improve it for GENIUS-138 ? On Fri, Jun 8, 2018 at 3:11 PM, Anil Vishnoi <vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>> wrote: On Thu, Jun 7, 2018 at 11:39 AM, Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote: Not related in this context, but if we can get shard leader change notification, can we use that to derive an entity owner instead of using EOS? ;) Humble suggestion, don't use shard location/ownership status in your business logic ;-) +1. And knowledge, assumptions about shard names, member names ... :) >> Of course we all like to avoid such complex logics in the application code. >> In a 3 node cluster, for an application like netvirt which has to push a lot >> of flows, plus a set of OVSDB configuration, based on some events coming >> from neutron datastores(note that all of these are different config shards), >> I am just trying to understand what is the best way to place things. It is >> always good not to make application logic, depend on internals of infra, but >> is the only way then to collocate shards? I have few questions around what lead to the solution that putting all the shard to one node is the only solutions , but i don't want to hi-jack this thread with that topic :). Thanks, Faseela From: infrautils-dev-boun...@lists.opendaylight.org<mailto:infrautils-dev-boun...@lists.opendaylight.org> [mailto:infrautils-dev-boun...@lists.opendaylight.org<mailto:infrautils-dev-boun...@lists.opendaylight.org>] On Behalf Of Tom Pantelis Sent: Friday, June 08, 2018 12:07 AM To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>> Cc: infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>; controller-dev <controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>; genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> Subject: Re: [infrautils-dev] [controller-dev] OK to resurrect c/64522 to first move infrautils.DiagStatus integration for datastore from genius to controller, and then improve it for GENIUS-138 ? -- Thanks Anil -- Thanks Anil
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
