incubator-openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "seba.wagner@gmail.com" <seba.wag...@gmail.com>
Subject Re: Updated Cluster Architecture
Date Tue, 15 Jan 2013 01:31:09 GMT
PS: Get well soon :)


2013/1/15 seba.wagner@gmail.com <seba.wagner@gmail.com>

> 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 <solomax666@gmail.com>
>
>> 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, "seba.wagner@gmail.com" <seba.wagner@gmail.com>
>> 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 <solomax666@gmail.com>
>>>
>>>> Hooray :) less components is better :)
>>>>  On Jan 15, 2013 7:39 AM, "seba.wagner@gmail.com" <
>>>> seba.wagner@gmail.com> 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
>>>>> seba.wagner@gmail.com
>>>>>
>>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message