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-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Thursday, June 11, 2009 10:55 AM To: freeswitch-users@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.bieli...@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. i...@halokwadrat.de<mailto:i...@halokwadrat.de> e. michal.bieli...@halokwadrat.de<mailto:michal.bieli...@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@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 -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_miness...@hotmail.com<mailto:msn%3aanthony_miness...@hotmail.com> GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com<mailto:paypal%3aanthony.miness...@gmail.com> IRC: irc.freenode.net<http://irc.freenode.net> #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org<mailto:sip%3a...@conference.freeswitch.org> iax:gu...@conference.freeswitch.org/888<http://iax:gu...@conference.freeswitch.org/888> googletalk:conf+...@conference.freeswitch.org<mailto:googletalk%3aconf%2b...@conference.freeswitch.org> pstn:213-799-1400
_______________________________________________ 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
