[cisco-voip] Migrate Unity Connection 8.5 Cluster to VMware-then upgrade to 9.1

[Matthew Ballard]

AFAIK physical MAC is still used in all scenarios when deploying on physical (vs virtual) hardware, certainly in the 8.x train (and I believe the 9.x train, although things change when you move to ELM which I can't speak to).

I'm thinking the scenario you read about would be:

1.       DRS backup publisher.

2.       Take down publisher and configure network to not allow devices to talk to publisher (there may be a time after taking down the publisher and bringing up the new one that devices may try to communicate with the new one causing problems).

3.       Install/bring up new publisher on virtual.

4.       Restore publish.

5.       Link new publisher with existing subscriber and allow them to sync (which is probably where the reference you found previously comes into play).

6.       Remove prior traffic restrictions and make sure things are working on the new publisher.

7.       Repeat process with subscriber (I can't speak as to whether DRS would be required or note for the subscriber).

Hope that helps/makes sense.

Note I not speaking from experience with this type of situation, but what I believe to be a situation that should work/makes sense based on your comments.

I get the issues with hardware, I ended up doing the shadow environment I described due to a lack of hardware, but fortunately since I run the network here, I didn't need approval to do what I did. :)

Matthew Ballard
Network Manager
Otis College of Art and Design
mballard at otis.edu<mailto:mballard at otis.edu>


From: rotimm at gmail.com [mailto:rotimm at gmail.com] On Behalf Of Ted Nugent
Sent: Monday, February 24, 2014 3:03 PM
To: Matthew Ballard
Cc: Cisco VoIPoE List
Subject: Re: [cisco-voip] Migrate Unity Connection 8.5 Cluster to VMware-then upgrade to 9.1

Thanks for the feedback Matt
I haven't upgraded anything newer than 8.5 that was on MCS so I was under the impression that the licensing MAC was used exclusively on 8.5+ as opposed to the MCS MAC, if that assumption is inaccurate, so be it, we will just need to rehost, not the end of the world.

Regarding the loss of messages, this was something that I was concerned about however I thought I had read a post on the support forums (trying to find it now) where messages from the "subscriber" would be copied to the publisher after rebuilding the publisher server from DRS? This is actually less of a concern than loosing AAs and Call Tree functionality for the duration of the migration but it's definitely a concern.

I understand that building a test bed is the ideal way of handling this but unfortunately finding the hardware to handle this has been a challenge and building a shadow network on the customer VM environment has not been blessed as of yet.

Thanks again for your feedback.
Ted

On Mon, Feb 24, 2014 at 5:50 PM, Matthew Ballard <mballard at otis.edu<mailto:mballard at otis.edu>> wrote:
I can't speak to the subscriber part of the restore itself, but had a couple comments on this:

1.       The license MAC will absolutely change.  On physical boxes the license MAC is the MAC address of the NIC, on VMware, it is based on a bunch of settings, and so you will need to rehost the license.

2.       Your process will likely create a data problem, as the DRS backup will only be accurate as of when you took the backup.  Since you are intending system uptime between taking down the publisher and bring the new one online, any messages/other changes between when you take it down and bring the new one up will be lost.  This is much more of a problem for Unity Connection than it is for UCM, as for UCM you mostly need an admin freeze on any changes (plus a couple things like mobility), but any data lost is minimal and easily fixed.
For Unity Connection, you will just lose any messages left or greetings changed between backup and restore.

The official way to do what you want with minimal downtime would be to build in a separate dev environment with the same IP/other structure, so that you can build the new 8.5 VM Servers, and then do a backup and restore (bringing down the existing system immediately after the backup with a downtime window scheduled).

I ended up doing a partial method, where I used to firewall to simulate the same environment (providing the minimal services needed through a double NAT), so that the new servers saw just what they needed from the production environment, without conflicting.

Matthew Ballard
Network Manager
Otis College of Art and Design
mballard at otis.edu<mailto:mballard at otis.edu>


From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Ted Nugent
Sent: Monday, February 24, 2014 2:34 PM
To: Cisco VoIPoE List
Subject: [cisco-voip] Migrate Unity Connection 8.5 Cluster to VMware-then upgrade to 9.1

I'd like to run this by some of you that might have gone through this before or have investigated it.
I'm upgrading a Unity Connection 8.5 cluster (currently on MCS) to 9.1 on  VMware without a loss of service.
Here's the plan
Take a DRS backup of the system
reorder CUCM RLs so calls hit the subscriber node first (if needed)
take down the publisher node
rebuild the publisher node on VMware using the Cisco OVA
Install the publisher with the same settings (hopefully this won't alter the License MAC so we won't need to rehost?)
DRS restore the Publisher only
Take down the Sub
rebuild the Sub node on VMware using the Cisco OVA
Install the Sub with the same settings, joining it to the cluster

Question: (Assuming we don't need to rehost the licenses etc) is it necessary to restore the subscriber from DRS at that point? or will replication take over (only self signed certs in use)

The remaining steps seem fairly straight forward upgrading from 8.5 to 9.1

screen shots of licensing pages to send to Licensing for 9.x license etc for ELM rehost.

Thoughts? Anything I'm missing, anything way to make it easier?

Thanks in advance for any suggestions
Ted

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140224/cda43ffa/attachment.html>