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 <[email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
