[cisco-voip] Plan for Failure

[Jason Burns]

If a part in a CUCM server died (RAM, mobo, HD, CPU) you could theoretically
have that part replaced within 4 hours. Then you'd have to perform an
install and DRS restore if it was a catastrophic HD/RAID failure (otherwise
when the part was replaced you'd be good to go). If you do a good job this
could probably all be done during the course of one business day.

SRST could certainly handle the PRI for you while the CUCM server was down.
You'd have to look at the sizing though for how many phones a 2801 can
handle in SRST.

Which looks like 24 phones in table 4

http://www.cisco.com/en/US/prod/collateral/routers/ps5854/product_data_sheet0900aecd80169812_ps5855_Products_Data_Sheet.html


On Fri, Jan 22, 2010 at 2:13 PM, David Zhars <dzhars at gmail.com> wrote:

> I am trying to create a "what if" scenario, and how we would react.
> Obviously, with SmartNet and all that, you can minimize some issues, but if
> a CM box were to die (and we only have one), getting a new one could be
> quick, but getting it all installed and everything else could be lengthy.
>
> So I am  wondering what you would recommend:
>
> We have an ISDN coming in to a 2801 in H323 mode.  Most calls come in on
> this and most go out this line as well.
> At a remote site, connected by fiber, we have a 2801 with SRST and two POTS
> lines plugged into FXOs.
> Now if my CM were to die, could users still go out the ISDN, or does CM
> handle that?  Could I route calls in from the ISDN somehow, or again, is
> that something CM handles?
>
> I am just trying to plan for the worst and hope for the best!
>
> Thank you for any suggestions (and setting up a Pub/Sub is an option, but
> not one in the current budget picture).
>
> _______________________________________________
> 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/20100122/67917e24/attachment.html>