| Harper, Chris 2005-04-07, 5:45 pm |
| I actually talked to a rep at macromedia when I entered my modular
scaling idea into macromedia's wish list and I'm not feeling confident
that there is going to be as a robust scaling solution as I had hoped.
It seems to be only for broadcast video streaming type applications
which doesn't make sense to me. I can get Real or Windows Media Server
if that's all I want it for. I just want the ability, if my video chat
system starts slowing (which it is), so I can buy another license, drop
in another box and copy my applications to it.
Is there a way we could open a petition for some of these features, like
screen capture and scaling, that we like but only seem to be available
to Breeze Live?
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Stefan
Richter - Flashcomguru.com
Sent: Monday, January 24, 2005 7:55 AM
To: FlashComm Mailing List
Subject: RE: [FlashComm] Scaling with FCS
Some good info there.
However I have some concerns in regards to 'FCS 2.0 is more or less
gonna
handle that
automatically' and I would not hold my breath on that point - unless of
course Pritham has whispered you something in which case please share
the
details :-)
I have heard rumours that large scale deployment of video only
(streaming)
apps may become easier but very little on any kind of 'plug and play'
clustering a la Coldfusion.
I too need help soon on deploying a multi-server app and I already feel
the
need for more documentation. Peldi's blog posts have helped me get
started
but there are 3 or 4 different architectures for which a detailed
technote
should be issued. I have a feeling that this subject will come up time
and
time again, especially as an increasing number of developers feel
comfortable building sophisticated FCS apps.
Maybe it's just me but I feel slightly scared by the prospect of
building a
really solid yet extremely easy to scale app. A few more blueprints out
in
the open would be highly appreciated.
Stefan
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org]On Behalf Of Brajeshwar
Sent: 24 January 2005 13:26
To: FlashComm Mailing List
Subject: Re: [FlashComm] Scaling with FCS
Hi,
Me and our team recently (About 4 months ago) did a FCS clustering for
a London Client but I think FCS 2.0 is more or less gonna handle that
automatically. Below is an excerpt of what I did with perspective to
the client's requirement.
Well, thanks to Brian Lesser and Pritham Sethy for disturbing them
with many questions during the tenure of the proiject.
Flash Communication Server Nodes Clustering for effective deployment
of Multi-tier (Multi Node) Plug-Play Applications. A generalized idea
of FCS Clustering to provide scalability to FCS applications relying
on Macromedia Flash Communication Server; with more particular
targetted and detailed information on a Distributed State cluster
approach. In this approach, the flashcom cluster will consist of one
or more "root" flashcom server and "n" number of "node" flashcom
servers.
ROOT: The root server will host the RootApplication for the
application. Root is started manually on the server, once started it
should not be stopped unless no clients (Flash Apps) are connected.
Root maintains a Node Allocation Table (NAT) of all the nodes
currently present in the flashcom server cluster. The flash clients
only connect to the nodes, the Root application is only accessible to
the nodes from the server-side.
NODE: The node servers will host the NodeApplication for the
application. Nodes are also started manually on the server. The flash
clients connect to any one of these node servers only.
Load Balancing
1. Once a node comes online, (i.e. onAppStart is triggered) it
connects to the Proxied(Derived) Shared Object on the Root Server
(rsoNodes). It proceeds to create a new slot on this SharedObject with
data about itself. This data will be an array of information about
this node, like, node URI, clients currently connected, etc. This data
would be sufficient enough to determine the RTMP traffic on this
node(server).
Drawbacks:
1. By distributing the clients on different nodes, the live assets of
a client, in this case, Audio Video streams, get scattered across
nodes. Hence we have to use server-side stream proxies to relay these
streams between nodes.
2. With the above approach there is still a single point of failure,
the Root. If the root server goes down, the cluster looses its brain
itself and would no longer function. However this can only happen in
very rare scenarios (unless the server is managed by some street
junkies and not techies). The reason being, the Root is only connected
to the number of nodes we have, and not to the flash clients. It does
all its work through proxied shared object synchronization. So only
data travels back and forth between the Root and Nodes. This should
significantly reduce the load on the Root server. Moreover, the
flashcom server is known to work very reliably with just data transfer
between clients.
3. We could potentially solve the problem of a single point of
failure, by clustering together multiple Root servers as well. To
maintain uniform state across multiple Roots, we would need similar
proxied state for the speed dates sessions but in the database instead
of so's. There are 2 major technical limitations to this,
a. Lack of locking in Proxied shared objects,
b. Synchronizing timers across multiple servers.
On Thu, 20 Jan 2005 11:13:58 -0600, Harper, Chris
<Chris.Harper-OaAI/70wYEY@public.gmane.org>
wrote:
> Yeah, this is similar to other solutions I see but doing it this way
> puts a single point of failure directly on the Master Server.
>
> That's the only problem I have with the pyramid style. If you have 3
> node servers below it with a 10mb license each then you have to have
> three 10mb licenses on the Master Server to accommodate. Also, what
do
> you do when that master server starts to get burdened? I'm not sure
> there is even a quad server that could handle 30mb and 7500
connections
> by itself.
>
> I wish there was a simpler load balancing solution like how we have
with
> our web servers (we have web1, web3, web3) that just directs traffic
to
> the least burdened server. I guess the problem with the FCS server is
> getting other servers to "see" each other. If anybody knows of
anything
> let me know!
>
> Thanks 
>
> Chris
--
Regards
Brajeshwar
________________________________________
__________________________
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|