Also please remember this means every _application_ also must be "failover" 
aware. So, if you're using a little calling card or billing app to control your 
routing, that app will have to explicitly enroll its state as well as restore 
itself.

Live migration is possible via OpenVZ. OVZ does not have the same overhead of 
other virtualization techniques such as Hyper-V, ESX, Xen, etc. So you can do 
media without much worry.  OVZ can work with other virtualization, too; you can 
spin it up inside of a VMware machine.

But this is *live* migration of the container. It's "just" pausing your 
container, copying the whole memory, and resuming it on another node. This is 
not "dead" migration or failover after calls break. However, you could try 
running a very frequent sync in OVZ, so that if there was a node failure, you 
could resume from a previously saved state. But, I highly doubt performance 
would be good enough for this to work successfully on any serious deployment.

-Michael

From: freeswitch-users-boun...@lists.freeswitch.org 
[mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Raimund 
Sacherer
Sent: Saturday, August 29, 2009 12:33 PM
To: freeswitch-users@lists.freeswitch.org
Subject: Re: [Freeswitch-users] FreeSWITCH HA + Loadbalancing

Hmm, so basically 100 interested companys which each chip in 1000 bucks :-)

sounds like lots of manpower, but on the other hand, I do not know the issues 
regarding the SIP protocoll, but, basically, isn't it *just* to tell another FS 
box to listen on port x for voicetraffic, forward it to ip on port y?

ok, i understand there's a lot going on under the hood, i guess it would mean 
to setup a call, but take care to not really set up the call, just the internal 
state ...

hmm, could it theoretically be done with the event system? ok, i guess I have 
to dive further into the internals to fully understand the scope.


But a live migration, where the box is available, be possible right now? Would 
be a step i would like to implement just to be able to do work on a hardware 
node if necesary without interrupting the service ...


--
Raimund Sacherer
-
RunSolutions
    Open Source It Consulting
-

Parc Bit - Centro Empresarial Son Espanyol
Edificio Estel - Local 3D
07121 -  Palma de Mallorca
Baleares

On Aug 29, 2009, at 6:01 PM, Anthony Minessale wrote:



We have previously estimated the development of live fail over (after a box 
dies where live migration is no longer possible) to exceed 100k in development 
costs.

It requires several additions to the sofia sip library, freeswitch and a 
dependancy on some other code we would have to implement to manage it.

It may or may not be worth it to raise that kind of funding just to avoid an 
occasional disaster.

Then there is a matter of securing the time of the developers necessary to 
carry out the implementation.

On Aug 29, 2009 10:19 AM, "Brian West" 
<br...@freeswitch.org<mailto:br...@freeswitch.org>> wrote:

I was able to do this using OpenVZ, You can get away with it on
smaller instances... like if you're doing one instance per company but
don't expect live migration to work as well on large instances with
thousands of calls up at once. You need a fast network, fast disks and
to follow the howto on the wiki.

/b

On Aug 29, 2009, at 4:58 AM, Steve Kurzeja wrote: > You still have hardware 
failures and fail-over...

_______________________________________________ FreeSWITCH-users mailing list 
freeswitch-us...@lists...

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org>
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

_______________________________________________
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Reply via email to