Unless you only had a single CUCM node (which BE6KS limits you to, and BE6K customers are a fit for). In which case, a truly seeamless way to "flip" it would work in all scenarios.
On Thu, Oct 27, 2016 at 3:14 PM, Justin Steinberg <jsteinb...@gmail.com> wrote: > The upgrades take too long is part of it. Especially if the upgrade is an > RU upgrade, because it means that both the patch install/upgrade and the > switch needs to take place in a maintenance mode. > > The missing piece in my opinion is a way to put CUCM into a maintenance > mode where it continues to service active calls (on ccm, cti, ipvms > processes, etc) but forces new calls/registrations to another cucm. > > Unity Connection does have a nice implementation of this (i.e. 'stop > taking calls') which makes for completely transparent reboots, etc. > > If CUCM had a maintenance mode like feature, we would be able to do these > things during the day without causing problems. > > Justin > > On Thu, Oct 27, 2016 at 1:22 PM, Ryan Ratliff (rratliff) < > rratl...@cisco.com> wrote: > >> Honest question, what exactly is it about the current implementation that >> fails to deliver on this? >> >> Is it something in the design of the upgrade process? >> >> Is it that the upgrade takes too long to be done during any reasonable >> maintenance window? >> >> Is it that you have to test the new version before you roll it into >> production? >> >> Is it <your answer goes here>> >> >> -Ryan >> >> On Oct 27, 2016, at 12:02 PM, Anthony Holloway < >> avholloway+cisco-v...@gmail.com> wrote: >> >> 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 <ryanh...@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-boun...@puck.nether.net> on behalf of >>> Matthew Loraditch <mloradi...@heliontechnologies.com> >>> *Sent:* Tuesday, October 25, 2016 3:01 PM >>> *To:* Tommy Schlotterer; Scott Voll; cisco-voip@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-boun...@puck.nether.net] *On >>> Behalf Of *Tommy Schlotterer >>> *Sent:* Tuesday, October 25, 2016 2:49 PM >>> *To:* Scott Voll <svoll.v...@gmail.com>; cisco-voip@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> | >>> **tschlotte...@presidio.com >>> <tschlotte...@presidio.com>* >>> >>> >>> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net >>> <cisco-voip-boun...@puck.nether.net>] *On Behalf Of *Scott Voll >>> *Sent:* Tuesday, October 25, 2016 2:43 PM >>> *To:* cisco-voip@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@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> >>> >> _______________________________________________ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> >> _______________________________________________ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
