asterisk users - May 2008 - dundi network - redundancy / fault tolerance ?

Hi list,

  I'm planning a private DUNDi network for a cross-country
  distributed PBX. Initially it will be composed of about 10
  systems, growing to about 20.

  Current requirements point to a topology of two interconnected
  "DUNDi hubs", each peering with half the PBXs... This would
  lead to two interconnected / inter-peered stars.

  Example:

  - Consider PBXs A to H
  - C and E will be hubs and peer with each other
  - A, B and D peer with C
  - F, G and H peer with E

  This leads to a maximum three hop lookup and will make
  good use of current network topology / bandwidths. Of course,
  should any of the hubs be unavailable and the lookup capability
  is severely compromised.

  Now, how to move on to acheive some kind of fault tolerance ?
  According to the docs we've studied, DUNDi does not like loops
  (which we assume one can limit with low enough TTLs).

  Our doubts are:

  - Should one use the "order" peer parameter to specify alternate
    lookup paths / peers ? Is that its purpose ? If not, what is it used
    for ?

  - Alternatively, should one create loops in the DUNDi topology and
    limit them via TTL ?

  - If both options are possible, which would be the trade-offs between
    them ? (Not clear at all to us!)

  - Assuming any of the above is possible as a means to acheive
    redundancy, which of the following topologies would your prefer ?
    (hmmm, maybe I need to refresh my graph theory...) ;-)

    #1 - Peer each PBX with both hubs
    #2 - Duplicate both hubs and peer each PBX with its hub and
          its hub dup

    For better understanding, take a look at:

    #1 - http://www.2photosharing.com/images/qhpnzycd7j7kf26j2f.png
    #2 - http://www.2photosharing.com/images/npzbwvgnr4t079laou0.png

  Thanks in advance for review and feedback.
  Cheers,
--
  exvito

I don;t have any answers for you...

But I would love to hear about the results after you get this working and what
road blocks you hit and how you overcame them.

--
Matt
________________________________________
From: asterisk-users-bounces at lists.digium.com [asterisk-users-bounces at
lists.digium.com] On Behalf Of Ex Vito [ex.vitorino at gmail.com]
Sent: Wednesday, May 07, 2008 10:08 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] dundi network - redundancy / fault tolerance ?

  Hi list,

  I'm planning a private DUNDi network for a cross-country
  distributed PBX. Initially it will be composed of about 10
  systems, growing to about 20.

  Current requirements point to a topology of two interconnected
  "DUNDi hubs", each peering with half the PBXs... This would
  lead to two interconnected / inter-peered stars.

  Example:

  - Consider PBXs A to H
  - C and E will be hubs and peer with each other
  - A, B and D peer with C
  - F, G and H peer with E

  This leads to a maximum three hop lookup and will make
  good use of current network topology / bandwidths. Of course,
  should any of the hubs be unavailable and the lookup capability
  is severely compromised.

  Now, how to move on to acheive some kind of fault tolerance ?
  According to the docs we've studied, DUNDi does not like loops
  (which we assume one can limit with low enough TTLs).

  Our doubts are:

  - Should one use the "order" peer parameter to specify alternate
    lookup paths / peers ? Is that its purpose ? If not, what is it used
    for ?

  - Alternatively, should one create loops in the DUNDi topology and
    limit them via TTL ?

  - If both options are possible, which would be the trade-offs between
    them ? (Not clear at all to us!)

  - Assuming any of the above is possible as a means to acheive
    redundancy, which of the following topologies would your prefer ?
    (hmmm, maybe I need to refresh my graph theory...) ;-)

    #1 - Peer each PBX with both hubs
    #2 - Duplicate both hubs and peer each PBX with its hub and
          its hub dup

    For better understanding, take a look at:

    #1 - http://www.2photosharing.com/images/qhpnzycd7j7kf26j2f.png
    #2 - http://www.2photosharing.com/images/npzbwvgnr4t079laou0.png

  Thanks in advance for review and feedback.
  Cheers,
--
  exvito

_______________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Ex Vito wrote:
>   Now, how to move on to acheive some kind of fault tolerance ?
>   According to the docs we've studied, DUNDi does not like loops
>   (which we assume one can limit with low enough TTLs).
Which documentation are you referring to?  You may have misunderstood something,
or there may be some false information floating around the internet (*GASP*).

The DUNDi protocol has built in handling for loops.  It keeps track of which 
nodes have already been queried, so you don't have to worry about loops in
your
network.  Every node can peer with every other node if you really wanted to.  Of
course, that's not necessarily the most efficient thing to do ...
>   Our doubts are:
> 
>   - Should one use the "order" peer parameter to specify
alternate
>     lookup paths / peers ? Is that its purpose ? If not, what is it used
>     for ?
The order parameter is really a tool.  There is not an exact situation that it 
is intended for.  It depends on your network.  Keep in mind that DUNDi caches 
results along the way.  If you use the order option to have servers send queries
through a primary server, you getter better caching performance.
>   - Alternatively, should one create loops in the DUNDi topology and
>     limit them via TTL ?
As I said before, don't worry about loops.  Set your TTL to handle a worst
case
path for a query in your DUNDi topology.
>   - If both options are possible, which would be the trade-offs between
>     them ? (Not clear at all to us!)
I'm not sure what you mean.  The best thing to do is to have multiple peers.
Have every server have at least two peers.  Setting a primary and secondary can 
be good for caching reasons.
>   - Assuming any of the above is possible as a means to acheive
>     redundancy, which of the following topologies would your prefer ?
>     (hmmm, maybe I need to refresh my graph theory...) ;-)
> 
>     #1 - Peer each PBX with both hubs
>     #2 - Duplicate both hubs and peer each PBX with its hub and
>           its hub dup
> 
>     For better understanding, take a look at:
> 
>     #1 - http://www.2photosharing.com/images/qhpnzycd7j7kf26j2f.png
>     #2 - http://www.2photosharing.com/images/npzbwvgnr4t079laou0.png
> 
>   Thanks in advance for review and feedback.
I'm not necessarily up on my graph theory, either, but I would probably go
with
something like #1.

A combination of having multiple peers and usage of the order option can give 
you good redundancy without hurting your performance.  When you set primary, 
secondary, etc. peers, the server will attempt to contact them one at a time. 
If you have multiple peers, but do not set an order, they will all be contacted 
at once, which may (probably will) increase latency for call completion, will 
increase bandwidth consumption, among other things.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.