Re: Re: [cgl_specs] Use case - Live patching

Corey,

On Mon, 28 Mar 2005, Corey Minyard wrote:

> Brian F. G. Bidulock wrote:
> 
> >Corey,
> >
> >On Mon, 28 Mar 2005, Corey Minyard wrote:
> >
> >  
> >
> >>Brian F. G. Bidulock wrote:
> >>
> >>    
> >>
> >>>Timothy,
> >>>
> >>>We would stop one of the redundant processors, patch it, and then
> >>>bring it back up and switch over from the online side.  A bounce
> >>>in the middle could be problematic but that is usually true of all
> >>>planned outages.  I don't know of any telco switches that actually
> >>>continue running call processing on the same processor that is being
> >>>patched.
> >>> 
> >>>
> >>>      
> >>>
> >>I do.  Nortel switches work this way, for instance.
> >>    
> >>
> >
> >So you patch your DMS's with both sides synced.  That would be a foolish
> >practice...
> >  
> >
> Why?  It never caused a problem in the field.  Of course, your patching 
> system has to be set up to handle this properly, but it can be done.


Lost the IOC on an NT-40 DMS-200 toll switch in Edmonton for 9 hours doing
that.  Given 10 minutes per year, that switch had to run near forever to meet
reliability requirements.  But you can take what risks you want, Nortel did
in that case.  Toll traffic more than doubled the next day, so it affected
revenue in a positive direction.  I figured we should have taken those toll
switches out of service ever so often just to drive up revenue.  Hah!


--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦