Tony, What would you suggest for the proxy role in a case like this? I would like to do a similar project and I still can't get any semblance of failover to work when the Primary server is taken offline. I am looking for this solution, whether it is in sipXecs, another hardware unit, or software solution.
Mark Theis Southern California Telephone and Energy Office (951) 693-1880 Ext. 212 Fax (951) 693-1550 Cell (951) 545-1013 or (949) 682-VOIP 27515 Enterprise Circle West Temecula, CA. 92590 mth...@socaltelephone.com<mailto:mth...@socaltelephone.com?subject=reply%20from%20email%20footer> From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Tony Graziano Sent: Wednesday, September 22, 2010 4:42 PM To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] SIP Server Questions (Virtual vs Physical) Ok, noone said anything on this yet, don't take this in any way except free advice or just a perspective on what I've seen and done. In reading on some of the other lists (like FreeSwitch users), there is no "guarantee" that FS will operate properly in a Virtual environment. Resource planning is very important though, because good access to disk (low latency) and network (again latency) as well as RAM are very important. So allocation of these, and whether or not the resources (like RAM) are dedicated or not begin to creep up after prolonged uptime. I would suggest you look at this http://wiki.freeswitch.org/wiki/Enterprise_deployment_Xen and also realize that while their (FS) wiki says one thing, I also hear them say "running in a virtual environment" is not always as reliable as a physical one, and even more so (favoring phyisical) in a cloud deployment (i.e. Amazon). The type of storage network and other items factor in of course. I run VMWARE in the lab with sipx all the time, and its fine for that, and in certain production environments it has been fine too for limited use. I think the key in resources in RAM and planning though. With vmware you can over allocate RAM, which is fine, but when the "actual" ram usage (which does get high in sipx) starts to occur, it becomes important to not have memory allocation issues in your host environment, and once SWAP usage starts occurring you need to plan a reboot as you might experience a noticed degradation in services. Separately, I believe the PROXY role must be chosen (even if not actively desired) on any node in a HA environment at the present method HA is written. I do not believe the sipXbridge role is capable of being redundant in HA at the present time. Gateway failover as a result might need to be addressed if this is correct. On Wed, Sep 22, 2010 at 4:43 PM, Talbot, Peter <peter.tal...@nrtnortheast.com<mailto:peter.tal...@nrtnortheast.com>> wrote: Hi all. In further pursuing a 'Production Rollout' ready implementation of sipXecs, I had some final questions, mostly in regards to what can and cannot be Virtualized. Currently it is looking like anything that actually handles voice traffic (whether recorded messages or ongoing conversations) should remain physical due to timing constraints, but other Roles can be Virtualized. What I am loosely looking at then, in a server layout fashion, would be something along the lines of: SIPX1 - Physical Server (Internal network) - Management/Primary SIP Router SIPX2 - Physical Server (Internal Network) - Redundant SIP Router SBC1 - Virtual Server (DMZ) - Primary ITSP Gateway (SBC) SBC2 - Virtual Server (DMZ) - Redundant ITSP Gateway (SBC) SIPCN1 - Physical Server (Internal Network) - Conferencing SIPWM1 - Physical Server (Internal Network) - Voicemail SIPX3 - Virtual Server (Internal Network) - ACD/Instant Messaging Physical and Virtual Servers would all be 64bit, running a minimum of 8GB of RAM, the VM1 machine having extra storage space, and all with a good processors (well above the recommended listed in Michael's book) and GB Ethernet. Virtual Machines would have slightly less power, but the Roles are slightly less power hungry anyway. In this instance, Remote Workers would be connected via VPN to our internal network, so Remote Worker traffic would act just like 'inside user' traffic. Does the above seem like a plausible solution? As a secondary necessity - in regards to load testing - what tools of those available (like WinSIP) would any of you recommend? Peter Talbot [v1.0.07.109] _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org<mailto:sipx-users@list.sipfoundry.org> List Archive: http://list.sipfoundry.org/archive/sipx-users/ -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: tgrazi...@voice.myitdepartment.net<mailto:tgrazi...@voice.myitdepartment.net> Fax: 434.984.8431 Email: tgrazi...@myitdepartment.net<mailto:tgrazi...@myitdepartment.net> LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net<mailto:helpd...@voice.myitdepartment.net> Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
