Peter,
That's certainly the way we are headed... we're just not there yet. We
hope to in the near future have a fully survivable branch/HA solution with
many systems providing that.
At present only a few services are highly available.
Documentation is available on planning a production ready environment in the
form of a book I wrote... search for sipXecs on amazon.com or find the link
in the Wiki. The planning section is fairly thorough.
Thanks,
Mike
On Wed, Sep 15, 2010 at 8:46 AM, Tony Graziano <[email protected]
> wrote:
>
>
> On Wed, Sep 15, 2010 at 10:33 AM, Talbot, Peter <
> [email protected]> wrote:
>
>> I don’t see any documentation *readily* available, and wanted to put
>> this out to those of you most familiar with the sipXecs system.
>>
>>
>>
>> I’m looking to design a highly available *production-ready* environment
>> of sipXecs that would service a number of branch offices and number of
>> employees within each office (something around 2000 users to put a
>> hypothetical number out there, spread out over 20 offices). The system will
>> be housed in a central office that will act as a regional hub for calling
>> within (and without) the company (inbound/outbound calling will be handled
>> via ITSP or media gateways). One of the core requirements is a
>> *wholly*highly available system: this means that each role of sipXecs must be
>> redundant, and if possible, scalable. This raises the following questions:
>>
>
> For starters not all components in sipx are HA capable. You cannot have
> centralized voicemail and HA, nor can you have HA members with their own VM
> able to properly get to VM if the server they were setup on as a user (where
> their VM resides) goes. There are design discussions based around better HA
> capabilities, but these take a while to implement.
>
> I'm not sure sipxbridge is really HA capable (yet), so perhaps a normal SBC
> with failover would be better for remote users and trunks.
>
> The registration, gateways and SBC stuff is pretty straightforward to work
> out. You would have to better describe your WAN capabilities to get more
> input (MPLS connected?).
>
> I (my firm that is) has found a standalone server per branch with proper
> gateway, 911 and ITSP configuration makes a lot of things functional in the
> event of a failover, with the expectation of access to voicemail if the
> voicemail server is down or cutoff. A standby spare centrally located can be
> loaded and restored in a matter of minutes, it's just getting in place
> that's the trick, and depending on your server infrastructure there's ways
> around that too.
>
>>
>>
>> • What is the best way to split the sipXecs roles into
>> physical servers (assuming each server is equipped with 2.8GHz dual
>> processors, 4GB RAM, and HDD space determined by role)?
>>
> I am seeing indication in testing 4.3 that 4GB RAM may not be sufficient
> with heavy use. Better to go 64 bit and natively be able to add more RAM if
> needed.
>
>> • What roles are readily highly available (besides the
>> obvious SIP Router role), and by what method are they made highly available
>> (through software on the system, SRV records, etc)?
>>
> • Assuming that the role can be run in an HA mode, what kind of
>> scalability is available to a given role - for example: will it
>> load-balance, or will the ‘active’ working node be the only server available
>> for the given role? And again, how is this handled (I would assume SRV
>> records in this case)?
>>
> SRV for the proxy/registrar roles.
>
>> • Are there any roles of sipXecs that are NOT currently
>> capable of redundancy (I know voicemail was at one point but that was before
>> FreeSwitch was integrated, and I know the user interface portal is a
>> single-system only at this time)?
>>
> Correct voicemail is not HA yet, even in 4.2. sipxbridge is a question, I
> havent tried it lately. Some people want it as standalone without a proxy, a
> proxy is required on any (every) HA system. I don;t think XMPP is but thats
> so new I havent tried it.
>
>>
>>
>> On a related note – has anybody done any load testing they could share
>> with a large subset of users (> 2000), or do any of you have experience with
>> running a system that large? Thanks all.
>>
> I think if your are replicating changes to users (i.e. groups, etc.) the
> current suggestion is to be careful what time of the day you do this,
> because some basic user changes replicate 14 files, potentially per server.
> That's a lot of writing, and the current in-memory DB for registrations and
> credentials is carried in that, and it can peg your CPU's for (i'm guessing
> 6-7 minutes) while you make certain global group changes. There is a current
> design spec looking to use mongodb for this to cut the overhead
> considerably, but there is also a question of "if we change the default
> outgoing caller id for a user, why are 14 files replicated, and seeing if
> there is a way to reduce or pointedly update ONLY these files with the
> change, not all that belong to a user.
>
>>
>>
>> Peter Talbot
>>
>> [v1.0.07.109]
>>
>> _______________________________________________
>> sipx-users mailing list
>> [email protected]
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>
>
>
>
> --
> ======================
> Tony Graziano, Manager
> Telephone: 434.984.8430
> sip: [email protected]
> Fax: 434.984.8431
>
> Email: [email protected]
>
> LAN/Telephony/Security and Control Systems Helpdesk:
> Telephone: 434.984.8426
> sip: [email protected]
> 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
> [email protected]
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
--
There are 10 kinds of people in this world, those who understand binary and
those who don't.
[email protected]
blog: http://www.sipxecs.info
call: sip:[email protected] <sip%[email protected]>
_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/
