http://serverfault.com/questions/224771/reasons-why-in-place-upgrades-are-bad
I would be surprised if any system administrator likes in-place upgrades. The simple truth is that they are not and can never be reliable. First you have to make the huge assumption that every software package initially installed on a system was packaged 100% correctly. This is never true. There are always packages with logic errors in them or that write to files they forget to mention in their package specfile. Writing package scripts is an incredibly unglamorous job, and is always assigned to the most junior developer on any software team.
Then, you have to assume that the host was correctly managed over time. Nobody ever went in and manually modified configuration or manually installed binaries that conflict with the packaged binaries. That never happens, right?
Remember that installing all these new packages means shutting down the old versions of the packages first. Package shutdown scripts are among the most poorly tested of all software. Nobody wants to deal with the incredibly boring and unthinkable case of their precious software package being deactivated and discarded. Plus there's a huge gotcha in this - shutting down packages which contain shared libraries means doing some very clever work to shut down packages which have those libraries loaded in to memory, or swapping running libraries in memory. That is extremely hard to get right.
Finally you have to assume that the people who produced the new release for the system thoroughly tested all possible combination of upgrades and not just the simplest case of upgrading the immediately previous version to this one. You have to believe that somehow they were able to devote the essentially infinite resources necessary to deal with every possible upgrade path.
As you can see, that is one giant (steaming) heap of assumptions. In practice none of those conditions are ever true. People install their own binaries on machines all the time. Package install and removal scripts are always buggy (I could write a whole dissertation on that one issue alone). The net result is that in-place upgrades are a fool's errand.
I should also note that my team performed a major OS and software upgrade of 7500 servers at my work last year. We tried so hard to make an in-place upgrade work but ultimately it just didn't, for many of the reasons listed above. We ended up wiping all the machines and installing the OS and all software from scratch. Problem solved.
All of this leads to my joke that the software release manager's mantra is Nuke it from orbit -- it's the only way to be sure. Completely wiping and reinstalling systems is the only sure path to success. You can get by with incremental upgrades most of the time, but eventually it's time to start fresh.
This is more SQL Server focused but still a good answer:
Why I Prefer A Migration to an In-Place Upgrade
- Easier Rollback - If something goes wrong you can rollback by simple saying "we aborted the upgrade.. Please change connection strings to old server while we resolve this". With an in-place you are fixing it or you are down.
- Refresh Hardware - Hardware changes rapidly. You can easily get stuck on hardware that was right for your company 4 years ago but not right for today and the next four years with an in-place upgrade. You will likely have to do a migration at some point anyway for the new hardware.
- Feel Better - Sure... This one is subjective, but it feels good knowing you are starting with a new OS installation, a new SQL installation with no cobwebs from the person on the job before you (or you before you knew what you knew today) that could possibly cause you headaches in the future.
- New OS - A migration gives you a chance to start with a new OS version if you aren't on the latest and greatest today.
- You Can Test It - Ever want to get a set of baselines on a new machine before you install SQL and cloud it up with databases and usage? You can do that now.
- Sometimes it is easier to sneak in best practices - Maybe things have been sort of hacked together to make it work before. You can fix that all and start fresh.
- Free test environment and extra sleep - It is a great benefit to have an environment you can work in ahead of the actual cutover day when you make this new environment live. Doing a migration to a new environment means you can build it during business hours, well ahead of your actual cutover day and test it in many ways ahead of time. You can run full regression testing on all applications and systems for days and have a great peace of mind before you actually do the final set of restores/attaches and cutover all applications and access to the new environment.
- You don't have to do it all at once - A very common situation I bump into is an environment that is trying to consolidate to just a few instances. Perhaps one per version, perhaps one per "tier" and version. A lot of these projects have different timelines for various applications and databases based on testing, project plans and vendor certification timeliness. Doing the migration means you can move those databases that are ready, when they are ready and still handle requests for those databases that can't move for one reason or another.
No comments:
Post a Comment