[Freeswitch-users] Live Upgrade Techniques

[Michael Giagnocavo]

Exactly. You probably want to have something like this anyways, so that when someone accidentally unplugs the system, or the disks/CPU/RAM crash, you're not stuck.

That is, until FreeSWITCH can record its internal state to some inter-machine memory so we can have hot failover. ;)

-Michael

From: freeswitch-users-bounces at lists.freeswitch.org [mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Anthony Minessale
Sent: Thursday, June 11, 2009 10:55 AM
To: freeswitch-users at lists.freeswitch.org
Subject: Re: [Freeswitch-users] Live Upgrade Techniques

or you can put a sip proxy in front of 2 boxes where you can control the flow of traffic.
when you want to upgrade one, take all the traffic off of it by forcing all calls to the other box, upgrade it then shift the traffic to the new one.
if that goes well, upgrade the other one too.


On Thu, Jun 11, 2009 at 5:47 AM, Michal Bielicki <michal.bielicki at halo2.pl> wrote:

Am 11.06.2009 um 05:04 schrieb John Dalgliesh:


Hi,

I am slowly gaining confidence using FreeSWITCH in production, but there
is one issue that I'm still wondering about: how are people upgrading
their FreeSWITCH installation binaries without dropping all current calls?

So far I have been upgrading in the dead of night, after pausing for 5
minutes then dropping the stragglers, but this is hardly ideal.

What I would like to do is to run an upgraded instance of FreeSWITCH on
the same machine, and have it handle all new call packets, whereas the old
instance continues to handle the existing call packets, until there are no
more old calls left.

I can think of about seven ways to accomplish this, but before I dive into
the code I thought I'd better ask what everyone else has been doing :)

(The only standard way I can think of doing this is to have a SIP proxy
sitting in front of FS the whole time, just to handle these upgrade
windows. It seems like a bit of a waste.)

So how are you handling your FS software upgrades?

{P^/
John


We use freeswitch on solaris and just upgrade it to a new zfs which gets remounted to the old place and freeswitch gracefully restartet. On failure we can allways do a rollback, which takes between 2 and 10 seconds, so the dwntime is pretty acceptable.

Michal Bielicki
Leiter der Niederlassung
HaloKwadrat Sp. z o.o.
Niederlassung Kleinmachnow
Eingetragen im Handelsregister beim Amtsgericht Potsdam, HRB21422P
Ust.Id.: DE261885536
Geschaeftsfuehrer: Aleksander Wiercinski
Meiereifeld 2b, 14532 Kleinmachnow
t. +49 33203 263220
f. +49 33203 263229 sip. info at halokwadrat.de<mailto:info at halokwadrat.de>
e. michal.bielicki at halokwadrat.de<mailto:michal.bielicki at halokwadrat.de> | w. www.halokwadrat.de<http://www.halokwadrat.de>
Hauptgeschäftsstelle:
Halo Kwadrat Sp. z o.o.
ul. Polna 46/14
00-644 Warszawa, Polen
EIngetragen im HRB Warszawa, KRS 0000153539


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



--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale at hotmail.com<mailto:MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<mailto:PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net<http://irc.freenode.net> #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org<mailto:sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888<http://iax:guest@conference.freeswitch.org/888>
googletalk:conf+888 at conference.freeswitch.org<mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20090611/c0762d9d/attachment-0002.html