Howto:Multiple PBX Redundancy: Difference between revisions

From innovaphone wiki
Jump to navigation Jump to search
Line 64: Line 64:


===from V9 recommended 2way redundancy without Multicast routing ===
===from V9 recommended 2way redundancy without Multicast routing ===
Starting from V9 (on the Phones) it is possible to configure additional to the Gatekeeper discovery a fixed Ip for the secondary Gatekeeper address, see [[Reference9:Configuration/Registration/Registration]].With that configuration we can make a 2 way redundancy without the physical location problem. This is the recommended way.
Starting from V9 (on the Phones) it is possible to configure additional to the Gatekeeper discovery a fixed Ip for the secondary Gatekeeper address, see [[Reference9:Phone/User/General]].With that configuration we can make a 2 way redundancy without the physical location problem. This is the recommended way.
Primary the Gatekeeper discovery will search for the local PBX, if the local PBX is down (and its Standby or Standby Slave) the Phone will use the configured Ip address of the secondary Gatekeeper address. This is the remote PBX. If the local PBX or it´s standby is up again then the remote PBX will unregister this Phone and so the Phone registers locally again.
Primary the Gatekeeper discovery will search for the local PBX, if the local PBX is down (and its Standby or Standby Slave) the Phone will use the configured Ip address of the secondary Gatekeeper address. This is the remote PBX. If the local PBX or it´s standby is up again then the remote PBX will unregister this Phone and so the Phone registers locally again.



Revision as of 09:47, 31 March 2011

This article describes a multipe PBX redundacy


Applies To

This information applies to

  • innovaphone PBX V7,V8 and later


More Information

innovaphone supports redundancy for its PBX. A Master PBX has its Standby PBX and also a Slave PBX has its Standby-Slave PBX. Even a Master PBX can act as a Standby PBX for its Slave PBX and vice versa. Now this article describes how to solve a multiple PBX redundancy.

Problem Details

For the standby scenario to work, it is essential that all affected clients (phones, gateways, etc.) are able to register with both the master PBX and the standby PBX. Apart from the fact that there must be appropriate IP routings, the clients either need to know both PBX's IP addresses or need to be able to find them dynamically.

Registration mechanism: When a slave PBX gets a registration request (e.g from a Phone) that does not belong to itself it redirects the registration request to the Master PBX. Also when a Master PBX gets a registration request (and not belonging to it) it redirects it to the according slave PBX. See also Reference:PBX_Locations#The_registration_PBX.

The following methods exist to make the PBX's IP addresses known to clients: Both for H.323 and SIP devices, a dynamic, IP multicast based discovery mechanism is available (based on IGMPv2). This is known as gatekeeper discovery in H.323 and also available in SIP. For innovaphone devices, discovery is enabled when there is no gatekeeper IP address or no SIP domain configured. If you have a Layer 2 or multicast enabled network between you PBX´s you can use the Discovery mechanism (configured Gatekeeper ID)

In an routed network (without multicast forwarding) where the standby PBX is in another Network you must work with the entries of primary and secondary Gatekeeper at your endpoint. This is often the only method available for 3rd party devices. For SIP devices, the 2 IP addresses are usually retrieved from the domain name system (DNS) based on the domain provided. The advantage here is that on the innovaphone phone you see on the display if its´s registered at it´s primary or it´s secondary PBX (this feature is not available when you work with the gatekeeper Id)

Howto-Multiple PBX Redundancy Reg.png

System Requirements

A Standby Licence is needed (must be the same size as the Port licences), this Standby Licence should be installed at the master PBX and with the floating mechanism distributed to all slave and standby PBX´s. This has the advantage that you need only one Standby Licence even if you want to have multiple redundancy. See also Reference8:Licenses#Licensing_for_Standby_operation

Scenario

Having two data center sites, the endpoints should have redundancy in-between the data center. But also if one data center is completely down the endpoints should register at the remote data center.


3 way redundancy with layer 2 or Multicast routing enabled networks

  • When having a Layer 2 network between the data centers you can work with the Gatekeeper ID. Take care about the physical location (see Knowm Problems below), so that local PBX getting first the registration request of their local phones. In an Layer2 Network you can not control what PBX gets the Gatekeeper discovery first.


  • In an Multicast enabled Wan network it is also possible to work with the Gatekeeper ID (as the endpoint makes a Gatekeeper discovery via the Multicast address 224.0.1.41).Be aware that multicast enabled wan networks requires deep network know how specialists to get it work right. We recommend to use [|Protocol Independent Multicast (PIM)] solution. Be in mind that you have to take care about the physical location (like in the layer 2 network).

You only need to work with the Gatekeeper ID (Gatekeeper discovery) at the endpoints. First the registration is always at the local PBX, if the local PBX is down the corresponding Standby will take over, if both PBX´s fails the PBX of the remote side will take over. If the remote PBX also fails the remote Standby will take over. You need to replicate all Objects between those two data centers have redundancy between them. Be in mind that a Standby PBX if its idle (so its corresponding PBX is active) never accepts or forwards any registration requests/gatekeeper discovery's. The Standby PBX only gets active when it´s PBX is down.


Howto-Multiple PBX Redundancy Layer2.png

3 way redundancy without Multicast routing networks

When having no Multicast routing enabled Network, Gatekeeper discovery via different sites is not possible. So here we describe the recommended configuration for 3 way redundancy.

  • Note if the local Datacenter fails at all (Master & Standby or Slave &Slave Standby )- the remote Datacenter will NOT take over

You can still work with Gatekeeper discovery, to have 3 way redundancy you must register the local Phones at the remote location, see the picture below. With that configuration you do not have problems with the Physical-location.

Howto-Multiple PBX Redundancy Layer3.png


Alternative

You can configure also a redundancy when the local Datacenter is completely down, but then you only have a 2 way redundancy and a problem with the physical -location. The phones having fixed Ip addresses configured (primary & secondary gatekeeper). Primary Gatekeeper is the remote PBX, this PBX redirects to the local PBX. If the local PBX fails the registration request will be redirected to the local standby (or standby slave). If the remote Datacenter fails at all, you configure as secondary gatekeeper the local PBX.

With that solution you have redundancy between the Datacenters but only 2 way redundancy.

from V9 recommended 2way redundancy without Multicast routing

Starting from V9 (on the Phones) it is possible to configure additional to the Gatekeeper discovery a fixed Ip for the secondary Gatekeeper address, see Reference9:Phone/User/General.With that configuration we can make a 2 way redundancy without the physical location problem. This is the recommended way. Primary the Gatekeeper discovery will search for the local PBX, if the local PBX is down (and its Standby or Standby Slave) the Phone will use the configured Ip address of the secondary Gatekeeper address. This is the remote PBX. If the local PBX or it´s standby is up again then the remote PBX will unregister this Phone and so the Phone registers locally again.


Howto-Multiple PBX Redundancy No multicast V9 1.png

Known Problems

Physical location

The physical-location is not configured but determined for each device on runtime depending on the PBX the original registration was sent to. This physical-location is not necessarily identical to the registration PBX since if the registration is sent first to a PBX which is not the registration PBX for this object, it will be the physical-location anyway, but the registration is redirected to the registration PBX. The callers physical location is determined, if there is a matching local object defined in the numbering node that is the physical location of the caller, then this object will hide any other object that would normally be found in the callers scope. This is often used for locations with local trunk lines. The trunk line object is put into the numbering node of the PBX serving the location and the local flag is turned on. This way, all calls from users who are located in this location will use the local trunk when dialing the trunk prefix, regardless of their node. So you need to be sure that local Ip Phones that need to get the Local Trunk Object - having its local PBX as physical location.

Standby PBX

A Standby (or Slave-Standby) PBX only gets active (accept and/or forward gatekeeper discovery as registrationr requests) when its associated PBX is down. As long as it´s associated PBX is up the Standby PBX is inactive (and so even does not forward gatekeeper discovery's).


Related Articles

Howto:How to tweak the RAS and TCP Keepalive timers