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

Thu Feb 27 02:36:11 EST 2014

Thanks for everyones feedback. The migration went fine. Migrated the sub
over first just deactivated it, rebuilt it and rejoined it to the cluster.
Then deactivated the pub, built it as it's own cluster, added the sub to
the cluster and forced a resync from the sub CLI. All outlined in the guide
posted earlier for replacing both servers as Justin mentioned. Thanks
again, all pretty straight forward and documented well.

On Tue, Feb 25, 2014 at 12:53 AM, Justin Steinberg <jsteinberg at gmail.com>wrote:

> There is no need to do a DRS restore, since you already have a cluster. In
> the link you sent there is a section for replacing both servers.
>
> In my experience, you can do this with no downtime experienced by people
> leaving voicemails.  However there are periods of time when a user will not
> be able to gain access to listen to new messages left during periods of
> time during the process.  Messages eventually get delivered after you
> restore the publisher back into the cluster.  The timestamps aren't
> accurate, they list the time when the cluster processed the queued
> messages, not when the caller actually left them.  If you could build your
> new pub in a staging environment and bring it into your production network
> just before you go to link it to your sub, you could reduce this time
> period.  I thought I recalled reading an official mention of this in the
> docs but I couldn't find tonight.
> On Feb 24, 2014 8:59 PM, "Ted Nugent" <tednugent73 at gmail.com> wrote:
>
>> After reading through those guides, does it make more sense to install
>> the sub first on VMWare, allow it to replicate from the PUB on the MCS and
>> then reinstall the Pub and do a DRS restore? Having a hard time seeing the
>> down side?
>>
>>
>> On Mon, Feb 24, 2014 at 6:34 PM, Ted Nugent <tednugent73 at gmail.com>wrote:
>>
>>> Here we go...
>>> This is what the support forum post was eluding to
>>>
>>> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/upgrade/guide/9xcucrugx/9xcucrug040.html#wp1052015
>>>
>>> and I think this answers my question about adding the sub... nuke it and
>>> readd to the cluster before you rebuild
>>>
>>>
>>> http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/9x/upgrade/guide/9xcucrugx/9xcucrug040.html#wp1087854
>>>
>>>
>>>
>>> On Mon, Feb 24, 2014 at 6:13 PM, Matthew Ballard <mballard at otis.edu>wrote:
>>>
>>>>  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. J
>>>>
>>>>
>>>>
>>>> Matthew Ballard
>>>>
>>>> Network Manager
>>>>
>>>> Otis College of Art and Design
>>>>
>>>> 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>
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* cisco-voip [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
>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140227/047033e0/attachment.html>