IP Office Failover- Failover versus Load-balancing......

[Choakem]

Hi guys - Looking for best practise here....

I have a primary server will all users registered...

I have a secondary server for resiliency......

This is what happened - Primary server was rebooted (by me) - CentOS failed to load due to missing OS files.... (No idea why) - In the meantime - all users failed over to the secondary server but I power cycled this too (Don't ask why) (Sad look)

Now, the Primary server was uncontactable and the secondary server rebooted without issue BUT no phones could register as the primary server was offline.......

ISSUES :- What kinda company designs a failover situation that requires the primary server to be active? I was down - all phones down..........

What is best practise here? Do i split my phones 50/50 and only have 50% failover within 3 minutes and pray to the invisible man upstairs that nothing happens to the secondary server if the primary refuses to boot?

looking for any advice.

regards

Mike

 

[Westi]

Not a design problem TBH
You don't have to buy any licenses for the secondary server because the licenses fail over from the primary.
Load balancing will not work because only the IP phones can register to both servers but voicemail still has to have primary and backup.


Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[Choakem]

Surely being in a situation with a perfectly working Secondary server and having zero phones working is a design flaw?

Although - Ill grant you - its a rare occurrence that both the primary server refuses to boot and during failover the secondary reboots........

I would still expect them to be independent from a design point of view...

Question wasn't really regarding licensing issues........ It was the reboot of the secondary server during failover that screwed things up....

 

[holdmusic34]

You need
a) an Avaya BP
b) 2x server edition select for HA active/active.

Try to spend the next 10 seconds not thinking about a blue eyed polar bear.

 

[holdmusic34]

Please see the attached IP Office Resiliency document which may be of benefit to you.


Try to spend the next 10 seconds not thinking about a blue eyed polar bear.

 

[zoomatomic]

I had the same scenario happen last week and had a ticket open with Avaya who came back and said thats just how it is, they did recommend splitting the handset count between the servers which we tested and it works but your left with 50% working handsets.

We also have ACCS resilience configured but in the above scenario the CTI link stays down as it can't get a CTI license, this is still under investigation

ACSS - SME
ASPS - SME

http://www.vodafone.ie/readybusiness

 

[amriddle01]

Failback is manual, it's because only you know when the primary server/connection is finally/actually stable, then you reboot the phones/secondary and the phones go back. If it was all automatic you could easily end up with phones flapping between servers/connections.

What you accidentally simulated was the manual failback, changing the way it works would cause more issues than it solves, I'll promise you that

 

[Albus2]

It's a misunderstanding of features like Resiliency, Backup, High Availability, etc.

If you are looking for a PBX with two servers where one is active and the other is constantly in sync to seamlessly take over if the first one goes down, aka a Cluster, then IP Office is the wrong choice.
In IP Office, all options are variants from what we know as SCN or Small Community Network. Every server or IP500v2 Gateway is an independent system with own Call Server and Media Gateway. The main difference from simple SCN to Server Edition is the central management and central licensing.

User, Extension, Hunt Group will be shared with the other system. However they are not part of the configuration in this second unit, it's just learned from the first as long as they are alive. If the first goes down, a User or Phone can register as a guest on the second unit, keeping the original configuration and licensed features (without those license being part of the second unit).
Now, the second reboots when the first is still down. In this case the original config of the second is loaded. Due to the absence of the first unit, it cannot learn the users of the first one. This results in the situation that the second would we available, but your phones cannot register.
Also, system items like SIP trunk etc. must be available, configured and also licensed. They do not just come from the first one.

'Select' just adds a backup One-X-Portal in addition to the Voicemail Pro.

Select also supports VMware-HA which means, if vCenter detects the Host where our IPO is running on does fail, then it may be rebooted on another available host. This is a full boot of the same Server Edition as before. Usually this takes around 10 minutes until the system is back again. However it is the very same system as before.

Therefore, I do not recommend to consider the Primary SE as the productive one and the Secondary SE as a Backup or HA-Cluster type of system to the Primary. Sales often explain it like this to customers, but that is not true and will lead to problems if something happens.

For such a Backup requirement, I would rather go for a single system but Select and a proper VM environment.
Or another solution. Avaya Aura can do this, but with a higher price tag.

 

[sizbut]

If your response to a flat tyre, is to let all the air out of your spare tyre; then resilience, high availability, load balancing or even responsibility for the foot pump is just not for you regardless of what you think the car designers should or should not have done.

Stuck in a never ending cycle of file copying.

 

[Choakem]

Some good point lads......

I guess ultimately the Secondary Server doesn't behave the way I anticipated....

Where there is a need for HA and the sytem is already purchased - would you advise Failover or Load Balancing?

Any significant pro's and cons?

Cheers

Mike

 

[Albus2]

Choakem,
Failover. And just be aware of what happened already and why.

In this case all administration is done in the Primary. This makes it easier IMHO.
Just one thing: keep ICR in Secondary updated, so that incoming calls will find it's (guest) users. This of course is only if your trunk supports this from the provider side.

Failover Load Balancing would be similar to what the system is designed for in terms of 'one system here', 'one system there' but networked with the additional benefit of resilience - if we talk about the systems deployed over two cities or countries. I understand your systems are in the same rack for the same customer. This makes administration more complicated than necessary.
Also, some features may be not available which is not a problem if the second system serves for another office but if this phone is on the next desk.

 

[Choakem]

You are correct, same customer, same rack...

Failover looking like the better option...

 

[Albus2]

Choakem,
Sorry, there was an something wrong in my last Post.
However, you got it right.