Yes, it is almost the same as your proposal! The other differences are:
1) The params that are needed during the "sync" (sync-whiteboard for example) are stored in the IClient. That way you don't need each RoomClient when you iterate through the connections. And in that sense the RoomClient can go into the database without affecting the performance (with some exceptions) 2) When the user enters a conference room he will be redirected to another node/server. To keep things simple I would use one "master" server. Otherwise you would need to be able to send a chat message in the dashboard-overall chat from one node to another. 3) I would not use a HTTP round-robin DNS initially. The issue is the upload complete event. The event won't work if you do handle RTMP on node2 while the HTTP upload is handled on node1. 4) Kick user from admin UI. It needs some more modifications to work with the new scenario. I am currently implementing Point No 1) Sebastian 2013/1/18 Maxim Solodovnik <[email protected]> > Just look through the new design > It seems to be very similar to the old one :) With the only major > exception: It uses OpenJPA special driver to avoid DB conflics :) > > great :) > > > On Wed, Jan 16, 2013 at 1:21 AM, [email protected] < > [email protected]> wrote: > >> Gliffy, its part of our wiki (Add => Gliffy) >> >> Sebastian >> >> >> 2013/1/16 Alexei Fedotov <[email protected]> >> >>> Sebastian, >>> which tool do you use to create such good looking pictures? >>> >>> -- >>> With best regards / с наилучшими пожеланиями, >>> Alexei Fedotov / Алексей Федотов, >>> http://dataved.ru/ >>> +7 916 562 8095 >>> >>> >>> On Tue, Jan 15, 2013 at 5:31 AM, [email protected] >>> <[email protected]> wrote: >>> > PS: Get well soon :) >>> > >>> > >>> > 2013/1/15 [email protected] <[email protected]> >>> > >>> >> I guess Wicket will use the standard Tomcat session handling. >>> >> Tomcat itself uses the same approach (in-memory, database or >>> file-based) >>> >> for clustering >>> >> as we do. But of course it has some more advanced technologies to >>> >> synchronize and configure as well as its more reliable then doing >>> something >>> >> from scratch. >>> >> >>> >> Sebastian >>> >> >>> >> >>> >> 2013/1/15 Maxim Solodovnik <[email protected]> >>> >> >>> >>> I believe Wicket supports clustering. Maybe we can use Wicket >>> session? >>> >>> >>> >>> I'll try to review design ASAP (I'm a little bit sick right now, >>> might >>> >>> take some time) >>> >>> On Jan 15, 2013 8:21 AM, "[email protected]" < >>> [email protected]> >>> >>> wrote: >>> >>> >>> >>>> Hi Maxims, >>> >>>> >>> >>>> please review again, I changed it even more. >>> >>>> >>> >>>> This SOAP/REST sync between nodes is really not good. It will be >>> much >>> >>>> too slow. >>> >>>> A lightweight session object in the database as you proposed >>> initially >>> >>>> is better. >>> >>>> That way every node in the cluster has a lightweight (but clustered) >>> >>>> session store available and can redirect the user to the correct >>> node (and >>> >>>> we have no cluster specific code in our app). >>> >>>> >>> >>>> Also that way we can use a DNS load balancing as like any other web >>> >>>> application and our HTTP traffic is clustered. Not only RTMP. >>> >>>> I think this approach more meets the real world. >>> >>>> >>> >>>> Sebastian >>> >>>> >>> >>>> >>> >>>> >>> >>>> 2013/1/15 Maxim Solodovnik <[email protected]> >>> >>>> >>> >>>>> Hooray :) less components is better :) >>> >>>>> On Jan 15, 2013 7:39 AM, "[email protected]" < >>> >>>>> [email protected]> wrote: >>> >>>>> >>> >>>>>> I have updated the graph for the cluster architecture: >>> >>>>>> >>> >>>>>> >>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/Cluster+Master-Slave+overview >>> >>>>>> >>> >>>>>> The biggest change is that master and slave have the same >>> database (or >>> >>>>>> database-cluster). That makes it a lot easier. >>> >>>>>> The master will still need to coordinate the load, so he needs to >>> ping >>> >>>>>> all slaves to collect the load and redirect to the slave that has >>> the least >>> >>>>>> traffic (or that actually already hosts the requested room) >>> >>>>>> However the slaves can handle both HTTP and RTMP traffic. There >>> is no >>> >>>>>> need to separate that anymore as the slave would use the same >>> database as >>> >>>>>> the master. >>> >>>>>> >>> >>>>>> For syncing the recordings and other files to the master HDD >>> there are >>> >>>>>> multiple solutions. One would be like Maxim proposed to do a >>> Samba mount. >>> >>>>>> The other is for example to use some RSync scripts. This can be >>> >>>>>> decided by the end user on its own. >>> >>>>>> >>> >>>>>> I think this is more suitable then the previous approach and uses >>> the >>> >>>>>> standard mechanisms for clustering. >>> >>>>>> >>> >>>>>> Let me know what you think about that. >>> >>>>>> >>> >>>>>> Thanks! >>> >>>>>> Sebastian >>> >>>>>> >>> >>>>>> -- >>> >>>>>> Sebastian Wagner >>> >>>>>> https://twitter.com/#!/dead_lock >>> >>>>>> http://www.webbase-design.de >>> >>>>>> http://www.wagner-sebastian.com >>> >>>>>> [email protected] >>> >>>>>> >>> >>>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Sebastian Wagner >>> >>>> https://twitter.com/#!/dead_lock >>> >>>> http://www.webbase-design.de >>> >>>> http://www.wagner-sebastian.com >>> >>>> [email protected] >>> >>>> >>> >>> >>> >> >>> >> >>> >> -- >>> >> Sebastian Wagner >>> >> https://twitter.com/#!/dead_lock >>> >> http://www.webbase-design.de >>> >> http://www.wagner-sebastian.com >>> >> [email protected] >>> >> >>> > >>> > >>> > >>> > -- >>> > Sebastian Wagner >>> > https://twitter.com/#!/dead_lock >>> > http://www.webbase-design.de >>> > http://www.wagner-sebastian.com >>> > [email protected] >>> >> >> >> >> -- >> Sebastian Wagner >> https://twitter.com/#!/dead_lock >> http://www.webbase-design.de >> http://www.wagner-sebastian.com >> [email protected] >> > > > > -- > WBR > Maxim aka solomax > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
