VoIP Mailing List Archives

[nospam at godawa.de]

Hi everybody,

what are the current options to get an Asterisk-system high available?


Using two servers as active/passive with DRBD, Pacemaker/Corosync works
very good, there are no quality issues of the voice quality, even not on
high loaded servers and no problems with a lot of small packages.

But for this you need two systems for every Asterisk-system, what is not
"economic" in any way.


Using (para-)virtualization with Xen could be an other option, on
systems with low load this works reliable, but what happens on systems
with high load? Are there any issues known about problems with the
realtime, packet loss etc. because it runs in a VM?

The idea would be having a HA-cluster of two servers with Xen, each of
them runs one instance of an Asterisk-system in a single VM and on a
failure the VM will be restarted on the other node.

This might result in a much higher load on this node, because is runs
two VMs, but for a short period, until the other node comes back again,
it might be tolerable.


Are there other options running two Asterisk-instances parallel on one
system, each binded on it's own IP, maybe s.th. with chroot or similar?


Thanks a lot,
--

kind regards,

Thorolf

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

[mdupuis at ocg.ca]

Some food for thought:

If you use DRBD, then you will mirror corruption from one system to another. You also cannot selectively pick files in a folder to mirror (you will mirror a lot!) As well, DRBD struggles as peers are set further apart (latency) or number of changes increases.

A lot of HA tools don't look deeper into Asterisk to see if/how it has failed (they only detected catastrophic failures). What happens when the Asterisk process is alive but no longer bridging calls?

If asterisk/host processes mess up an consume huge amounts of system resources, most HA tools cannot respond.

As a biased recommendation, take a look at HAAst at www.generationd.com It takes care of moving a shared IP between hosts as well as other features.

Michelle


(I work for Generationd


________________________________________
From: asterisk-users-bounces@lists.digium.com <asterisk-users-bounces@lists.digium.com> on behalf of Thorolf Godawa <nospam@godawa.de>
Sent: Thursday, March 6, 2014 10:21 AM
To: Asterisk Users List
Subject: [asterisk-users] High Availability with Asterisk

Hi everybody,

what are the current options to get an Asterisk-system high available?


Using two servers as active/passive with DRBD, Pacemaker/Corosync works
very good, there are no quality issues of the voice quality, even not on
high loaded servers and no problems with a lot of small packages.

But for this you need two systems for every Asterisk-system, what is not
"economic" in any way.


Using (para-)virtualization with Xen could be an other option, on
systems with low load this works reliable, but what happens on systems
with high load? Are there any issues known about problems with the
realtime, packet loss etc. because it runs in a VM?

The idea would be having a HA-cluster of two servers with Xen, each of
them runs one instance of an Asterisk-system in a single VM and on a
failure the VM will be restarted on the other node.

This might result in a much higher load on this node, because is runs
two VMs, but for a short period, until the other node comes back again,
it might be tolerable.


Are there other options running two Asterisk-instances parallel on one
system, each binded on it's own IP, maybe s.th. with chroot or similar?


Thanks a lot,
--

kind regards,

Thorolf

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

[mitul at enterux.in]

Hello,
Using Single Server with multiple VMs essentially kills the purpose, coz it doesnt protect against physical hardware failures.
To save costs, use low end box as failover, to keep u in business, till primary box goes live.
Mitul On Mar 6, 2014 8:51 PM, "Thorolf Godawa" <nospam@godawa.de (nospam@godawa.de)> wrote:

[asterisk at lists.mino...]

On 6/3/14 3:21 pm, Thorolf Godawa wrote:

[universe at truemetal.org]

Hi Thorolf,

Am 06.03.2014 16:21, schrieb Thorolf Godawa:

[paul.belanger at polyb...]

On Thu, Mar 6, 2014 at 10:57 AM, Mitul Limbani <mitul@enterux.in> wrote:

[paul.belanger at polyb...]

On Thu, Mar 6, 2014 at 3:33 PM, Markus <universe@truemetal.org> wrote:

[acheraime at gmail.com]

Good post. Actually this is the architecture we  have.


On Fri, Mar 7, 2014 at 11:31 AM, Paul Belanger <paul.belanger@polybeacon.com (paul.belanger@polybeacon.com)> wrote:

[steinwendtner at gmx.net]

On 2014-03-07 17:31, Paul Belanger wrote:

[mailinglist+asterisk a...]

On 07/03/14 16:52, Johann Steinwendtner wrote:

[adamk at 3a.hu]

My approach (in theory only, so please correct me if I'm wrong) would be
to run asterisk on multiple boxes (one each). A dedicated monitoring
box (nagios? custom scripts?) would perform frequent checks against the
boxes (one of my previous projects one asterisk was using call files to
demonstrate its health to another one).

If a box fails, I would simply redirect/reroute its traffic to another
one, using network solutions. Such as shutting down the production
interface of a suspectedly failed asterisk box, having an idle one pick
up its IP address, or using load balancing / routing / NAT to redirect
the client's traffic to a standby box.

My approach is based on the experience that linux based HA tools are
often not free, or don't scale well, or engineered to circumvent an
error in a slower manner (eg. booting a second VM takes too much time).
However in the network world, there are well known protocols that were
designed to take over in a matter of miliseconds.

I do understand that this would not provide 'session' data, so failing
over to a different box would mean the need to re-register, could cause
calls to drop etc. This might be unacceptable for you. As I said in
the beginning, I haven't been building such systems, in my experience a
dropped call is not that big of a deal, if it happens because the
network cuts over to a different box. This could be handled with a pair
of frontend load balancers, where the number of asterisk boxes can be
transparent.

hope this helps
adam





--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

[binni at binni.eu]

Hi all

Thanks for an interesting discussion.

I've looked at various options for load balancing Asterisk servers and
providing fail over support.

One thing is not clear to me is: What happens to queues in a load-balancing
environment? On our server, we have various queues with up to 20 incoming
calls waiting in each, with typically 1-5 queue members. If incoming calls
get placed randomly (or according to some heuristic) on different servers,
is there any way that Asterisk can handle queue functionality?

Our client sip phones can enter or leave queues as they wish, but each sip
phone is only registered on one server at a time - so queue members could be
registered at different servers in a load balancing environment. Same goes
for incoming calls, going to different servers but eventually ending up in
the same queue.

I'm not sure if queues would ever work in a load balancing scenario, and I
haven't found any information on the net to tell me otherwise. Does anybody
have any experience/knowledge of if and how it could work?

Best regards

Binni

-----Original Message-----
From: asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of adamk@3a.hu
Sent: 8. marts 2014 21:28
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] High Availability with Asterisk

My approach (in theory only, so please correct me if I'm wrong) would be to
run asterisk on multiple boxes (one each). A dedicated monitoring box
(nagios? custom scripts?) would perform frequent checks against the boxes
(one of my previous projects one asterisk was using call files to
demonstrate its health to another one).

If a box fails, I would simply redirect/reroute its traffic to another one,
using network solutions. Such as shutting down the production interface of
a suspectedly failed asterisk box, having an idle one pick up its IP
address, or using load balancing / routing / NAT to redirect the client's
traffic to a standby box.

My approach is based on the experience that linux based HA tools are often
not free, or don't scale well, or engineered to circumvent an error in a
slower manner (eg. booting a second VM takes too much time).
However in the network world, there are well known protocols that were
designed to take over in a matter of miliseconds.

I do understand that this would not provide 'session' data, so failing over
to a different box would mean the need to re-register, could cause calls to
drop etc. This might be unacceptable for you. As I said in the beginning,
I haven't been building such systems, in my experience a dropped call is not
that big of a deal, if it happens because the network cuts over to a
different box. This could be handled with a pair of frontend load
balancers, where the number of asterisk boxes can be transparent.

hope this helps
adam





--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to
Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users


--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk at a-domani.nl]

On Sat, 2014-03-08 at 20:27 +0000, adamk@3a.hu wrote: