What if we replace "site" with "room"? Both sites are expected to be on the same network. Thanks, Chris
-----Original Message----- From: Picher, Michael [mailto:[email protected]] Sent: Thursday, May 06, 2010 1:57 PM To: Krisztian Ganyai; [email protected] Subject: RE: [sipX-dev] Fully redundant sipxecs Would site really be the proper terminology here? To me a site has a different IP addressing space. I'm not sure how this would work seamlessly having a pbx at a remote site. > -----Original Message----- > From: [email protected] [mailto:sipx-dev- > [email protected]] On Behalf Of Krisztian Ganyai > Sent: Thursday, May 06, 2010 7:56 AM > To: [email protected] > Subject: [sipX-dev] Fully redundant sipxecs > > Hi, > > There are some services in sipXecs, which are SPOF even in redundant > sipXecs deployments. These are: the mediaservices(ACD, conferencing, > VM) > and the config(admin and user portal). > > Our goal is to build a fully HA system. We have come up with multiple > ideas and some of them we discussed briefly with the sipx developers > already. The most promising idea we have to date looks like this: > > .------------------------. > .---------------------------------------------. > | Site 1 | | Site 2 > | > | | | > | > | .--------------------. | | .-------------------. > .-------------------. | > | | Node 1 | | | | Node 2 | | Node 3(cs) > | | > | | (service IP) | | | | | | > | | > | | | | | | | | > | | > | | .---------------. | | | | .---------------. | | .--------------- > . > | | > | | | Proxy(pri.) |----------->| Proxy(sec.) | | | | Proxy(pri.) > | > | | > | | '---------------' | | | | '---------------' | | '--------------- > ' > | | > | | .---------------. | | | | | | .--------------- > . > | | > | | | Config | | | | | | | | Config > | > | | > | | '---------------' | | | | | | '--------------- > ' > | | > | | .---------------. | | | | | | .--------------- > . > | | > | | | Mediaservices | | | | | | | | Mediaservices > | > | | > | | '---------------' | | | | | | '--------------- > ' > | | > | | | | | | | | > | | > | '--------------------' | | '-------------------' > '-------------------' | > | | | | | > | > '-----------|------------' > '---------------------------------|-----------' > | .------------------------. | > | | Replicated config | | > '----------->| (using DRBD) |<-----------' > '------------------------' > Figure 1: Before failover > > The idea behind is to extend the basic redundant configuration > sipfoundry suggests(Node 1 on Site 1 and Node 2 on Site 2) with a 3rd > node(Node 3) on Site 2. The Node 3 acts as a cold standby primary node > and has all configuration files synced to/from the primary server. > > The configuration directories(/etc/sipxpbx and the /var/sipxdata) > between the primary Node 1 and the cold standby Node 3 would be > replicated using DRBD, which is a filesystem replication facility > available in CentOS. > > Since the configuration is shared, the Node 1 and Node 3 has to have > same IP address as we don't want to mess around with the config files. > To avoid IP conflicts, there would be 3 IP addresses for the Node 1 and > Node 2. From the three, one would be the "service IP", for which > sipXecs > is configured. When both primary nodes start, they come up with one of > the non-service IP address and with some mechanism they decide who > should be active. The active one takes over the service IP(using > ifconfig eth0 for eg) and starts the sipxecs services. When failover > happens(previous active goes down), the other node takes over the > service IP and starts sipXecs service. > > .------------------------. > .---------------------------------------------. > | Site 1 | | Site 2 > | > | (DOWN) | | > | > | .--------------------. | | .-------------------. > .-------------------. | > | | Node 1 | | | | Node 2 | | Node 3 > | | > | | (DOWN) | | | | | | (service IP) > | | > | | | | | | | | > | | > | | .---------------. | | | | .---------------. | | .--------------- > . > | | > | | | Proxy(pri.) | | | | | | Proxy(sec.) |<----| Proxy(pri.) > | > | | > | | '---------------' | | | | '---------------' | | '--------------- > ' > | | > | | .---------------. | | | | | | .--------------- > . > | | > | | | Config | | | | | | | | Config > | > | | > | | '---------------' | | | | | | '--------------- > ' > | | > | | .---------------. | | | | | | .--------------- > . > | | > | | | Mediaservices | | | | | | | | Mediaservices > | > | | > | | '---------------' | | | | | | '--------------- > ' > | | > | | | | | | | | > | | > | '--------------------' | | '-------------------' > '-------------------' | > | | | | | > | > '-----------|------------' > '---------------------------------|-----------' > | .------------------------. | > | | Replicated config | | > '----------->| (using DRBD) |<-----------' > '------------------------' > Figure 2: After failover > > Since it's probably not only us who'd like to have a fully redundant > sipXecs we decided not to do it undercover, but share our ides/progress > with the community. I hope we can come up with something usable. > > Looking forward for your comments, > Chris > > _______________________________________________ > sipx-dev mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
