Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Single vs Multi Cluster 1

Status
Not open for further replies.

chrisgla

Technical User
Feb 11, 2007
10
GB
Planning a replacement of four industrial sites with two 3300 MXEIII's per site, MCD4.2. Each ICP has attached PER to split analogue phone service (95% of phones).

I'd planned to cluster each site pair to mimic the single SX2000 then just network the four clusters using ARS without PNI. Existing numbering allows a unified 4 digit number scheme with few changes.

Mitel's initial suggestion is a single 8 ICP cluster- I think this is to simplify SDS data flow.

The problem this gives me is that the logical cluster master is an existing standalone 3300 which is difficult to get upgrade time on. There's also a worry that some sites could be sold off in the future requiring downtime for them while they are removed from the cluster and rebuilt into a new local one.

Is there a reason why I can't create 4 SDS clusters then use an SDS admin group which includes the four clusters to sync directories, etc?

Is there a list of what features a fully clustered node offer vs stand alone elements which have been fully engineered in with linked numbering scheme, consistant feature codes, SDS, etc?
MWI wouldn't work, any cross site hotdesking may have to be external, networked VM may need PNI are ones I think might be issues? I think BLF works.

Finally, I've always used PNI on previous networks mainly to integrate with other PBX. Is there definately no requirement for PNI in a Mitel only network (even for networked voicemail, any route opt, etc)? Xnet does seem to have a lot of DPNSS messages to ignore it.
Has anyone found a need for PNI on Qsig/ DPNSS hybrid connections to Call Manager? (possible future link)



 
There is no such thing as a cluster master except perhaps if you have the hospitality option installed.
So you can choose any system to sync from.
If your system that you have identified as the 'master' has all the correct info you require you could lways export these forms into the new system that you choose to use as a sync master.

As for cluster I would have one cluster instead of four, as you say you can then split this down into admin groups on a per site basis.
Cluster provides a lot less programming and you can then choose where to have resilient phones, however from your post if they are mosty analogue then this is not a requirement.
It is also easy to manage regarding voicemail, BLF etc.

Share what you know - Learn what you don't
 
Does the same apply to SDS or must there be an SDS master?

My concern is the first cluster members go in on an offshore site which tend to change hands. If we use that as a "master" would we have to rebuild RDN using another node as master?

From what you say it sounds more like peer to peer so all may be well.
 
I would answer that it depends on how much common equipment is involved.

For example:

Centralized VM - 1 Cluster would be best
Each site with its own VM - 1 or 4 clusters will do

Common Telephone Directory for interoffice dialing? - 1 cluster
Interoffice Dialing manually - 1 or 4

Common answering positions - Main attendant console answers for all sites? - 1 cluster
Distributed answering - 1 or 4

Basically if each site can run on its own, 4 separate clusters is OK. The more interconnectivity there is, the more the argument goes towards 1 cluster.

**********************************************
What's most important is that you realise ... There is no spoon.
 
As stated by Supernova there is no master in a cluster and that applies to SDS as well.

The single biggest problem with communications is the illusion that it has taken place.
 
Thanks guys... partner is still indicating there's a "master", I've asked them to check with Mitel.
I really do wish Mitel would give its registered consultants some direct help to sell their systems!

I wasn't sure if you lost admin if the first system that you start sharing from was disconnected from network, sold, etc- think that was the case at some point- maybe it's just the restriction on configuring resilient IP sets if primary ICP is down.
 
When you first choose to synchronise 2 systems you must decide which system to sync from. For the purpose of initiating the sync, this creates a temporary Master Slave relationship in that the programming can be pushed and overwritten on the receiving system.

Once syncronization is complete, this relationship desolves and the controllers are equals. Either can be used to push data changes.

So technically, it can be said that a Master does exist at some point but it would be wrong to say that a Master exists on a normally functioning synchronised system.

**********************************************
What's most important is that you realise ... There is no spoon.
 
The question Yes or No an eight system cluster is depending on the following: Resiliency, Hotdesking, Networked Call Pickup and BLF across the Network. Furthermore management can be an issue as within a cluster the systems will keep remote DN's up to date, as with single units you will need to program any DN via ARS to the correct node. So the existing numberplan is important.
As per PNI, this should only be used if DN numbers are more then once within a network. If this is not the case then PNI has no added value.

Breaking down a cluster is more work then deleting a network element, so if you are sure that parts are going to be disconnected from a cluster then don't cluster them in the first place. Unless you want the previous mentioned features across the network.
 
I've been told that Xnet will not work over Qsig- only public ISDN. Anyone tried this?

Causes me a major issue as there's a Cisco "cloud" in the middle using Qsig digit routing between single E1's at each of the 4 sites.
Changing the routers means monumental levels of change control and will add months of delay.

I thought Xnet didn't care- as long as it can setup basic ISDN data/ voice calls it has lower requirements of the protocol as everything is encapsulated within the PPP.
 
The term XNET applies to IP as well as ISDN routing. I do not know the limitations with XNET and QSIG in either case.

I too would think that the PPP method would not care as long as the connection can be made. The data component of the call is communicated over a dedicated voice channel and QSIG would have no visibility.

I suspect the QSIG limitation applies only to XNET over IP trunks.

**********************************************
What's most important is that you realise ... There is no spoon.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top