Blog Archives

Removing a Perfectly Good Cluster, Step One

Today we embark on a somewhat sad journey.  A couple of days ago, I told you a story about a vendor and the miscommunication of specifications.  Today the chickens have come home to roost.  We must replace the SQL Server 2008R2 clusters with 2008 clusters.  These were perfectly good clusters, fine tuned and ready to burst out of the starting gate and win the triple crown, well you understand what I mean.  I’ve grown attached to these clusters as they were the first ones that I have ever personally built from the purchase order to production.

Today, we will uninstall both of the SQL Server nodes and then begin the reinstallation of the previous version.  We will run the installer on the passive node first.  In the installer go to the maintenance section and choose “Remove node from a SQL Server failover cluster.”  After this is complete then we will go to the active node and go through the same process.  Tomorrow we will look at the reinstallation of SQL Server 2008 SP3.  Enjoy!

Advertisement

Vendor Rant, Starting Over

We interrupt this regularly scheduled blog series to bring you a rant.  Now wait don’t click away just yet.  There is a lesson here somewhere, I hope.

To give you some background, we have a vendor, henceforth known as XYZ, to whom we have worked with for several years on their financial package.  The package is currently in Oracle and it was decided that we could reduce costs by upgrading to the newest version of their package but migrating it to SQL Server to reduce our Oracle licenses which makes sound financial sense.  Being a predominantly Oracle shop, I have been masterminding the demise of Oracle for the year that I have been here quietly chipping away.

This project has been in the planning stages for several months.  During which time we order four identical super servers to be clustered into a production and development/acceptance active-passive clusters.  I cannot deny that I indeed was excited about this project whole heartedly because of the hardware as well as the chance to reduce the Oracle footprint and to champion SQL Server as the preferred database.  Plus, I have never built clusters from the ground up.

We took our time setting this servers up with Windows 2008 R2 Enterprise making sure that everything was well tuned.  Then we setup our SQL Server 2008 R2 Enterprise clusters on all four boxes even bringing in our Microsoft Premier Field Engineer to ensure a successful migration ensuring that best practices were in effect.  Most would view bringing in help as an insult to their pride, but I welcomed the learning opportunity and it helped with the learning of our green junior DBA who has no server or SQL experience.  In addition, whenever I can be around our PFE, I am the eager padawan and she is the jedi master especially since she has an extensive Oracle background as well.

Fast forward and these machines are ready to go and all of the specifications were discussed and communicated several times through planning meetings.  I even spoke with their DBAs during the install process to ensure that our settings were commensurate with the project.  Now on Thursday of this week, the day before we are to begin migrating some of the Oracle data to the development box, I discover on one of the documents that the only version supported is SQL Server 2008 SP3 running on Windows 2008 R2 Enterprise.  Hold the phone!

Rewind, notice I said we communicated several times that we were going to install SQL Server 2008 R2 Enterprise clusters on our new boxes and the vendor was compliant offering assistance if we needed it.  THEY NEVER MENTIONED THAT THEY DID NOT SUPPORT R2.  Now we have to uninstall R2 and install plain jane 2008 in effect putting us two versions behind and this project does not go live for another year after extensive testing.  We even offered to be a beta testing site so that they could certify and say that they supported R2 since we have a year of testing ahead of us.  DENIED!  They were not interested whatsoever since none of the third-party tools such as BOXI support R2, according to them.  Now I have to uninstall my beautiful creations and go backwards, this is progress.  😦

The moral of the story is to get the vendor to verify and sign off that the version you are installing is indeed supported before you install it.  My supervisor and I thought by telling the vendor in the meetings that this would be evident.  Next time we will force the issue before proceeding.

%d bloggers like this: