csaroli at isysp.com
Mon Dec 3 15:50:39 EST 2012
csaroli at isysp.com
From: spce-user-bounces at lists.sipwise.com [mailto:spce-user-bounces at lists.sipwise.com] On Behalf Of Gavin Sweet
Sent: Monday, December 03, 2012 1:22 PM
To: 'Andreas Granig'; spce-user at lists.sipwise.com
Subject: Re: [Spce-user] Clustering
Are there any databases or db tables that shouldn't be replicated in either a master-master (cluster) or master-slave setup?
I was wondering about the accounting data and what mechanisms there are for guaranteeing you only use one set of CDR's ... I guess that with rate-o-mat running on both your cluster nodes, you should be generating identical CDR files on each node? So you just decide which node you're going to process from and just pull one set of CDR's (as the accounting data would have replicated over from the other node even if that handled a specific call session)?
> -----Original Message-----
> From: spce-user-bounces at lists.sipwise.com [mailto:spce-user-
> bounces at lists.sipwise.com] On Behalf Of Andreas Granig
> Sent: 30 November 2012 20:45
> To: spce-user at lists.sipwise.com
> Subject: Re: [Spce-user] Clustering
> On 11/30/2012 09:06 PM, Christopher Saroli wrote:
> > Is there any way to setup clustering with another sipwise server to
> > provide for some sort of auto failover? Any info or suggestions
> > would be appreciated. thanks
> Well, the PRO version :)
> But seriously, there are couple of options for basic redundancy you
> can do quite easily with decent sys-admin knowledge.
> First, you need to keep your provisioning data redundant. Options for
> that are MySQL master-master replication, MySQL NDB cluster, tungsten
> replicator, and I know of people running /var/lib/mysql in a DRBD
> Second, you need to keep your config in sync, which can be achieved by
> puppet, chef, git, or just by manually copying files.
> Third, you need a cluster engine and resource manager like
> corosync/pacemaker, heartbeat etc. and mechanisms to detect certain
> failures above network level which trigger fail-overs (e.g. automated
> SIP calls, system health checks, data integrity checks for MySQL
> replication etc.), or you monitor your services externally and do a
> manual fail-over.
> Bonus points for keeping media running after a fail-over (e.g.
> ngcp-mediaproxy-ng with HA-module available in the PRO) and ensure SIP
> dialog replication for proper re-INVITE and BYE handling to prevent
> call cuts and - more importantly - overbilling on BYE (e.g. sems with
> HA-module available in PRO). I don't know about open-source
> implementations of these two features, but many people can live with
> these drawbacks (otherwise there already would be some open
> implementations for that).
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1427 / Virus Database: 2634/5432 - Release Date:
Spce-user mailing list
Spce-user at lists.sipwise.com
More information about the Spce-user