[cisco-voip] Standby publisher

Andrius Kislas andrius-conf at kislas.lt
Thu Jul 1 10:43:58 EDT 2010


Why would I need to involve TAC? I haven't done publisher restoration
process, but reading Desister Recovery doc I haven't noticed any notes
ragarding MAC address change. So I am guessing restoration procedure
from backups will take care of new MAC, won't it?

Also I do agree this is a already redundant system from call processing
perspective, but imagine 60K mega cluster and not being able to make any
changes for a week (that's without publisher). So I am adressing exactly
this situation.

Andrius

On 2010.07.01 16:59, Eric Butcher wrote:
> The cost / benefit analysis of this is a pretty hard sell, but if you're looking to squeeze that last bit of redundancy out of an already very redundant phone system...  It can be done.  Not as simple as plugging it in, powering it up, and loading licenses though.  There would need to be a tac case involved anyway.
> 
> 
> Eric Butcher
> Cisco Unified Communications Engineer
> CDW Professional Services
> 11711 N Meridian, Ste 225
> Carmel, IN  46032
> C 317.569.4282 - IP Phone
>   765.744.1458 - Mobile
>   eric.butcher at cdw.com
> www.cdw.com
>  
> 
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Ratliff
> Sent: Thursday, July 01, 2010 9:28 AM
> To: Bill
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Standby publisher
> 
> No you can't.  All database changes can only be made to the publisher.  This changes a bit in 6.x where the "user facing features" are written on each node, and replicated out to other nodes in realtime.  This is what lets you set and clear CFA with the pub down in later versions.
> 
> See http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/rel_notes/6_0_1/cucm-rel_note-601a.html#wp44437 for specfics.
> 
> Having a standby publisher installed and ready for restore is not a bad idea but you will be restricted by licensing (P1 TAC SR with the licensing team should get you rehosted pretty quickly I hope).  The only thing to worry about wrt to IP address is if the pub is specified in System->Server by IP address this would cause problems after the restore.   This could be avoided simply by changing the IP address to match the failed publisher before starting the restore.
> 
> -Ryan
> 
> On Jul 1, 2010, at 9:18 AM, Bill wrote:
> 
> Also, at least in the 4.x days, you can still make changes to the subscriber if the publisher is down. 
> 
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ahmed Elnagar
> Sent: Thursday, July 01, 2010 7:43 AM
> To: Andrius Kislas
> Cc: cisco-voip at puck.nether.net
> Subject: Re: [cisco-voip] Standby publisher
> 
> What about the license? The license relates to the MAC address of the server??
> 
>  Best Regards;
>   Ahmed Elnagar
>   Senior Network PS Engineer
>   Mob: +2019-0016211
>  CCIE#24697 (Voice)
>  
> 
> 
> -----Original Message-----
> From: cisco-voip-bounces at puck.nether.net
> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Andrius Kislas
> Sent: Thursday, July 01, 2010 1:17 PM
> To: Cisco Voip
> Subject: [cisco-voip] Standby publisher
> 
> Hi All.
> 
> Correct me if I am wrong, but when the publisher fails the biggest impact we have is not being able to change configuration. In large environments this might be serious impact.
> 
> My question is - does anybody use a standby/cold publisher that has the only task - sit and wait until the primary publisher fails? This standby published would ba standalone (not a member of existing cluster), would have different IP address (in the same subnet) and the same name as existing publisher, would have no licenses uploaded and would be kept in the same version as primary publisher. During primary publisher failure we would need to change IP address and perform disaster recovery. This would save us some time that we would typiacly need to get new server, install new publisher, upgrade it and finally perform recovery.
> 
> Does it sound fine or are there any caveats for such approach?
> 
> Regards,
> Andrius
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> Disclaimer: NOTICE The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately.
> The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Raya will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any malicious code or virus being passed on. Views expressed in this communication are not necessarily those of Raya.If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and return and/or destroy the original message. 
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 



More information about the cisco-voip mailing list