IPO primary node/WebLM and live migration? 1

[scifan]

We have two IPO servers running in a vmware environment - two separate hosts. The primary serves as the license server (webLM), and is the primary voicemail server as well. Note that the only thing running on our VMware hosts are the IPO servers. (probably a waste of resources, but everything else in our environment is on Hyper-V)

I shutdown the second node to upgrade VMware and firmware on the secondary host, and started that second node back up without any significant pain. Some warning messages but no interruption of service.

When I shutdown the primary node to do the same thing on the other host, I'd expected an interruption of service, but not what I experienced.

After shutting the primary node off, All of the expansion systems started lost their ever loving minds because the license server vanished. I'd kind of figured this could happen, but I didn't expect the immediate warnings about a 15 day trial period. Also, while I'd expected an interruption of service, I never expected it would take close to 10 minutes before call's would present more than a single "buzz" and hang up, and that voicemail wouldn't actually work again until the license server was back on-line.

After about 10 minutes I received notifications from all expansion modules that the Voicemail server was back on-line and operational - however no call's would route to voicemail and when I tried calling voicemail I would receive a system alarm e-mail about "The following system resources are all in use: Voicemail Channels".

Rather than troubleshoot these issues, I focused on running the firmware updates, and VMware updates so I could get things back on-line as soon as possible - even thought this was a maintenance window.

What should I have experienced? Should the system fail in this manner if the primary node is off-line?

Is there some way to have a redundant license server for this type of environment?

Can IPO virtual machines be live migrated between hosts without any significant issue to keep this sort of outage from happening?

(We don't currently own vCenter, that could be quickly remedied for this small of a VMware environment)

 

[atcom]

Phones take at least 3 minutes to failover to the Secondary, SIP trunks are dependent on your setup. I would say the 10 minutes before calls started to succeed again would fall within normal parameters.

However, the voicemail should have worked. Maybe there's something missing in it's SMTP config, or the IPO System Voicemail settings.

The WebLM server being offline shouldn't matter because you have the 30 day grace period. Yes, you see some alarms but it shouldn't be a problem.

I would expect vMotion to work well in terms of swapping hosts live...

-----------------------------------

Calgary Cloud Phones for Business and Avaya Hosted PBX in Calgary

 

[scifan]

Thank you for your response.

We actually don't run external SIP trunks - our voice is carried on PRI trunks with SCN trunks configured between sites on leased fiber links.

I'll need to get used to the idea that 10 minutes is a reasonable amount of time - seems long to me, but I'm still getting to know this system.

I wonder why our system was barking about 15 days then if 30 days is the usual time.

I'll have to see what I can find to help with the voicemail side of this.

Perhaps I'll download/install a trial copy of vCenter and work on configuring that. I'll need to configure a vmotion network, and I think the names need to be the same for the port groups which will require a change to one host.

I know with Cisco each server must have voicemail ports/channels configured and linked to both call managers. This system's configured a bit differently where there's a cluster of phones/users defined at each 500v2 expansion module, and failover is back to the primary node...

Should NTP settings point to both primary and secondary Linux servers?

 

[derfloh]

If failover of the phones from primary to secondary works, they are able to use the PRI trunk over the connection between secondary and expansion. As long as it is well configured.

IP Office remote service

https://www.fwilke.com/home

Fixed price SIP trunk configuration:

https://www.fwilke.com/en/ip-office-sip-trunk-en/

CLI based cale blocking:

https://blog.fwilke.com/ip-office-block-calls-from-specific-cli/

SCN fallback over PSTN:

https://blog.fwilke.com/ip-office-scn-fallback/

 

[scifan]

I should mention that the was this system is built, users are created on each site's 500v2 expansion with a fail-over/fall back to the IPO primary server. All PRI's connect to one 500v2 unit, and the rest of the 500v2's establish SCN connections back to this one 500v2, and to both IPO servers.

I would have expected the phones to remain connected to their "local" 500v2 expansion module, and I did expect voicemail to have a fit. I'm pretty certain I tried calling my desk phone and also received a single buzz before the system terminated the call.

Have you tried live migrating a IPO server between hosts while it was on-line and running? My primary concern is that a live migration might do bad things to the licensing.

 

[derfloh]

Direct connection between expansions are only supported in Select. So I guess IPO doesn't know how to route the calls or the needed fallback ARS tables are missing.

IP Office remote service

https://www.fwilke.com/home

Fixed price SIP trunk configuration:

https://www.fwilke.com/en/ip-office-sip-trunk-en/

CLI based cale blocking:

https://blog.fwilke.com/ip-office-block-calls-from-specific-cli/

SCN fallback over PSTN:

https://blog.fwilke.com/ip-office-scn-fallback/

 

[scifan]

Looking at the SMTP settings for voicemail - the "SMTP Sender" configuration is set thus on the primary:

Domain: <LAN1 ip address of node1>
server: LOCALHOST
port:2525
identifier: VMPRO@LOCALHOST

Backup server is configured thus:

Domain: <LAN1 ip address of node2>
server: LOCALHOST
port:2525
identifier: VMPRO@LOCALHOST


Looking at the documentation, this doesn't seem like it's correct. The documentation stats to use a FQDN for both the Domain and Server.

I'm confused.

 

[scifan]

I see ARS entries. I see Lines. I don't know how to match up a line group with a 5 digit number to the PRI's.

(that's something I haven't yet figured out for this system).

Note I'm trying to understand because it feels like things are not quite right.

 

[snowman50]

Set smtp settings like this

but do the secondary backup first



Looking at the SMTP settings for voicemail - the "SMTP Sender" configuration is set thus on the primary:

Domain: <LAN1 IP address 192.168.42.1 primary
server: LAN 1 IP address 192.168.42.1 primary
port:25
Sender. Vmpro@192.168.42.2 backup address

Identifier. 192.168.42.1 primary


Backup server is configured thus:

Domain: <LAN1 ip address 192.168.42.2 backup address
server: lan address 192.168.42.1 primary
port:25
Sender. Vmpro@192.168.42.2 backup address

identifier: Smtp. 192.168.42.2 Secondary

Log in to the vmpro client On primary
Select Distributed voicemails
After a while you will the server backup ipaddress appear and then displays “starting”
Then you will see progress of the files transferring to backup
Then you will see update complete


Ipoffice assistant web page explains how to do this on the

https://www.ipofficeassistance.com/tips/

 

[scifan]

Sounds like having this configuration setup with "localhost" may not be right. (no, I didn't set this up)

And thank you!

 

[scifan]

When I look at the distributed voicemail screen on voicemail pro, I see something like the following:

Name IP Address Version Type Last Activity Result
10.0.0.4 10.0.0.4 11.0.4100.2 backup 23/01/2020 13:08 In Progress [100% complete]-last sync 12046 files on master, 12040 files on slave, 7 to send, 0 wanted, 0 condemned

 

[snowman50]

It should change to update complete..

Hope it goes well,

 

[scifan]

Thank you!

The "results" field changes after making those changes.

Previously, it seemed like the Results field was permanently showing some level of sync progress. After making those changes, I watched it automatically change status, and ultimately show an "Up-To-Date" result code.