[cisco-voip] Not supported I'm sure..... but what do you think?

Thu Oct 27 16:50:51 EDT 2016

I'm going to start with, we don't have a complex deployment.

2 CM
1 UC
1 UCCX
1 CER
1 call recording server
~2000 phones over ~8 sites

our last upgrade we tried PCD (joke) spent 4 hours on it before just doing
it manually.  Will be very hard pressed to every use PCD again.

Then it was an additional 12-16 hours to upgrade.  This was just a 8 to 10
upgrade.

We don't have that kind of time.  and personally, I like my personal time a
lot.  so the more I can do during the week leading up to the switch and as
small as I can make the switch, is what I'm looking for.

Scott

On Thu, Oct 27, 2016 at 1:35 PM, Stephen Welsh <stephen.welsh at unifiedfx.com>
wrote:

> I’ve not done CUCM project work in quite a while, so may be completely
> off, but what about making this scenario supportable:
>
> Complex cluster say, 1 Pub, 6 Sub, 2 TFTP
>
> Install new software to inactive partition on all nodes, once complete
> reboot part of the cluster:
>
> 1 Pub - new version
> 3 Sub - new version (primary subs)
> 1 TFTP - new version (primary TFTP)
> 3 Sub - old version (secondary subs)
> 1 TFTP - old version (secondary TFTP)
>
> Phone registers to upgraded primary subs, once everything
> working/stable/tested, flip remaining (secondary nodes)
>
> Maybe too complex for this split version to be workable, or not really
> much different than flipping all nodes, but may allow the phones to stay
> online with minimal disruption as long as all external elements strictly
> follow the primary/secondary node configuration.
>
> Thanks
>
> Stephen Welsh
> CTO
> UnifiedFX
>
>
> On 27 Oct 2016, at 21:23, Ryan Huff <ryanhuff at outlook.com> wrote:
>
>
> You are right Anthony, this is a complex solution to avoid the reboot (and
> rolling the dice that nothing breaks in the first boot of the new version)
> in a switch-version however; if that is your goal .... as you state.
>
> -R
>
> ------------------------------
> *From:* avholloway at gmail.com <avholloway at gmail.com> on behalf of Anthony
> Holloway <avholloway+cisco-voip at gmail.com>
> *Sent:* Thursday, October 27, 2016 12:02 PM
> *To:* Ryan Huff
> *Cc:* Matthew Loraditch; Tommy Schlotterer; Scott Voll;
> cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] Not supported I'm sure..... but what do you
> think?
>
> If only there was an upgrade process wherein you install the new version
> to an inactive partition, and then could switch to the new version when
> you're ready.  /sarcasm
>
> But seriously though, everyone in this thread is essentially coming up
> with their own clever way of replicating the promise Cisco failed to
> deliver on, which is performing your upgrades during production on the
> inactive partition and then switching versions in a maintenance window.  If
> they would have only held themselves to a higher standard, we wouldn't need
> this complex of an alternate solution.
>
> On Tue, Oct 25, 2016 at 2:45 PM, Ryan Huff <ryanhuff at outlook.com> wrote:
>
>> Matthew is correct, copying is listed as "Supported with Caveats" at:
>> http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements;
>> The caveat being found at http://docwiki.cisco.com/wi
>> ki/Unified_Communications_VMware_Requirements#Copy_Virtual_Machine
>>
>> The VM needs to be powered down first and the resulting VM will have a
>> different MAC address (unless it was originally manually specified); so
>> you'll need to rehost the PLM if it is co-res to any VM that you copy.
>>
>> Where I have seen folks get into trouble with this is where a subscriber
>> is copied, and the user mistakenly thinks that by changing the IP and
>> hostname it becomes unique and can be added to the cluster as a new
>> subscriber. I have also seen users make a copy of a publisher and change
>> the network details of the copy, thinking it makes a unique cluster and
>> then wonders why things like ILS wont work between the two clusters (and it
>> isn't just because the cluster IDs are the same).
>>
>> Having said all of that, I would NEVER do this in production ... maybe
>> that is just me being cautious or old school, but that is just me. Even
>> without changing network details on the copy, I have seen this cause issues
>> with Affinity. At the very least, if you travel this path I would make sure
>> that the copy runs on the same host and even in the same datastore.
>>
>> === An alternative path ===
>>
>> Admittedly, this path is longer and there is a little more work involve
>> but is the safer path, IMO and is what I would trust for a production
>> scenario.
>>
>> 1.) Create a private port group on the host. If the cluster is on
>> multiple hosts, span the port group through a connecting network to the
>> other hosts but DO NOT create an SVI anywhere in the the topology for that
>> DOT1Q tag (remembering to add a DOT1Q tag on any networking devices between
>> the two hosts and allowing on any trunks between the two hosts).
>>
>> 2.) Upload Cisco's CSR1000V to the host. If you're not familiar with the
>> product it is at the core and unlicensed, a virtual router with three
>> interfaces by default. Out of the box, it is more than enough to replicate
>> DNS/NTP on your private network which is all you'll need. Assign the
>> private port group to the network adapters and configure DNS and NTP
>> (master 2) on this virtual router.
>>
>> 3.) Build out a replica of your production UC cluster on the private
>> network.
>>
>> 4.) Take a DRS of the production UC apps and then put your SFTP server on
>> the private network and do a DRS restore to the private UC apps.
>>
>> 5.) Upgrade the private UC apps and switch your port group labels on the
>> production/private UC apps during a maintenance window.
>>
>> Thanks,
>>
>> Ryan
>>
>>
>>
>> ------------------------------
>> *From:* cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of
>> Matthew Loraditch <MLoraditch at heliontechnologies.com>
>> *Sent:* Tuesday, October 25, 2016 3:01 PM
>> *To:* Tommy Schlotterer; Scott Voll; cisco-voip at puck.nether.net
>>
>> *Subject:* Re: [cisco-voip] Not supported I'm sure..... but what do you
>> think?
>>
>> I can’t see any reason it wouldn’t be supported honestly. Offline Cloning
>> is allowed for migration/backup purposes. I actually did the NAT thing to
>> do my BE5k to 6K conversions. Kept both systems online.
>>
>>
>> The only thing I can think to be thought of is ITLs, does an upgrade do
>> anything that you’d have to reset phones to go back to the old servers if
>> there are issues? I don’t think so, but not certain.
>>
>>
>> Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA
>> Network Engineer
>> Direct Voice: 443.541.1518
>>
>> Facebook <https://www.facebook.com/heliontech?ref=hl> | Twitter
>> <https://twitter.com/HelionTech> | LinkedIn
>> <https://www.linkedin.com/company/helion-technologies?trk=top_nav_home> |
>>  G+ <https://plus.google.com/+Heliontechnologies/posts>
>>
>>
>> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On
>> Behalf Of *Tommy Schlotterer
>> *Sent:* Tuesday, October 25, 2016 2:49 PM
>> *To:* Scott Voll <svoll.voip at gmail.com>; cisco-voip at puck.nether.net
>> *Subject:* Re: [cisco-voip] Not supported I'm sure..... but what do you
>> think?
>>
>>
>> I do a similar, but supported process. I take DRS backups and then
>> restore on servers in a sandbox VLAN. Works well. Make sure you check your
>> phone firmware and upgrade to the current version before the cutover or all
>> your phones will have to upgrade on cutover.
>>
>>
>> Also make sure you don’t change Hostname/Ip addresses in the sandbox as
>> that will cause your ITL to regenerate and cause issues with phone
>> configuration changes after cutover.
>>
>>
>> Thanks
>>
>> Tommy
>>
>>
>> *Tommy Schlotterer | Systems Engineer*
>> *Presidio | **www.presidio.com <http://www.presidio.com/>*
>> *20 N. Saint Clair, 3rd Floor, Toledo, OH 43604*
>> *D: 419.214.1415 <419.214.1415> | C: 419.706.0259 <419.706.0259> | **tschlotterer at presidio.com
>> <tschlotterer at presidio.com>*
>>
>>
>> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net
>> <cisco-voip-bounces at puck.nether.net>] *On Behalf Of *Scott Voll
>> *Sent:* Tuesday, October 25, 2016 2:43 PM
>> *To:* cisco-voip at puck.nether.net
>> *Subject:* [cisco-voip] Not supported I'm sure..... but what do you
>> think?
>>
>>
>> So my co-worker and I are thinking about upgrades.  we are currently on
>> 10.5 train and thinking about the 11.5 train.
>>
>>
>> What would be your thoughts about taking a clone of every VM.  CM, UC,
>> UCCx, CER, PLM,
>>
>>
>> placing it on another vlan with the same IP's.  NAT it as it goes onto
>> your network so it has access to NTP, DNS, AD, etc.
>>
>>
>> do your upgrade on the clones.
>>
>>
>> Then in VM ware shut down the originals,and change the Vlan (on the
>> clones)  back to the production vlan for your voice cluster.
>>
>>
>> it would be like a telco slash cut.  10 minute outage as you move from
>> one version to the other.
>>
>>
>> Thoughts?
>>
>>
>> Scott
>>
>>
>>
>>
>> *This message w/attachments (message) is intended solely for the use of
>> the intended recipient(s) and may contain information that is privileged,
>> confidential or proprietary. If you are not an intended recipient, please
>> notify the sender, and then please delete and destroy all copies and
>> attachments. Please be advised that any review or dissemination of, or the
>> taking of any action in reliance on, the information contained in or
>> attached to this message is prohibited.*
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> 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/20161027/1673d92f/attachment.html>