[c-nsp] Data Center switch replacement

Pavel Skovajsa pavel.skovajsa at gmail.com
Fri Dec 18 05:54:33 EST 2009


I second that,
as a rule of thumb in all migrations in production environments it is always
much better to go with the step-by-step aproach (if possible), and don't do
the tempting "big bang" implementation.

Yes it is true this will be more costly - more cabling, more rack space,
more management around it, more man hour work&more spreadsheets -> but it is
quite easy to built a businness case around it, as some servers just NEED to
be up and you cannot risk too much.

Also in case you have tight change process it provides an easy way to
explain to management that the backout procedure is straightforward - replug
the server NIC to the previous port.

While doing migrations of servers it is always better to have a
server/application personell checking each server as some
applications/OS/drivers might not like the replugging (especially when in
the middle of something) and might decide to crash/kill/destroy.....for
example we had experience with teaming NIC drivers that decided to shut the
whole "Team" as soon as something happened to one of the NICs - and found
this out only during the replugging.
Also - nobody is perfect, especially in the "inter-tower" field where the
server people think that the network guys are responsible for their NIC
settings, so we usually find misconfigured NICs - no teaming setup,
incorrect teaming modes etc. etc. - so going with step-by-step is always
better.

Hope it helps,
-pavel skovajsa







On Fri, Dec 18, 2009 at 3:42 AM, Randy McAnally <rsm at fast-serv.com> wrote:

>
> > How about you individually move each connection over to the secondary
> > switch one at a time.  This should only be a 30 second downtime
> > window per port, I'd think?  Once you've migrated everybody off of
> > the primary switch, pull it, upgrade it and then move everybody back
> > one-by-one?  This would minimize everybody's downtime and I think
> > would go over better with your clients.  Plus, you can drag out the
> > upgrade over time rather than an "all or none" scenario.
>
> Agreed.  What if something goes wrong or takes longer than expected --
> wouldn't you like to know by the time you've moved the first cable and not
> after the original switch is completely offline and de-racked?
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list