Re: upgrading sql2k cluster to sql2005

Doesn't matter if it is a new instance on the same cluster or an entirely
new cluster with an instance installed. The cluster part of this is
irrelevant to SQL Server. An new instance is a new instance no matter where
you put it and you have to do all of these dozens of manual copy and
validate processes no matter which one you have.

1. Recommended by whom? Microsoft.
2. You can not test all of your logins. Are you going to have all of your
users send you their passwords so that you can test them?
3. How do you know that a user's application is even going to work when you
install this into either a new cluster or a new instance of SQL Server,
unless you open up every single application that hits the cluster, hit every
screen in the application using each user's security credentials, and then
perform every operation against the applications.
4. Are you going to execute each DTS package to make sure that the security
for connections, linked servers, and remote servers hasn't been screwed up
when you installed a new instance

By doing this as a side-by-side, you run a VERY high risk of having
significant problems in your infrastructure. It is even worse, because not
all of the problems are going to be immediately apparent. 3 months after
the side-by-side upgrade, you could still be running into issues. Do you
want to explain to the CEO/CTO/CIO of ANY organization that the applications
running their business aren't working, because you decided to recreate
everything from scratch instead of just upgrading it? I'm speaking from
experience as well from having installed, upgraded, patched, and managed
tens of thousands of SQL Server clusters across hundreds of organizations.
There are only a small percentage of them that I would recommend a
side-by-side upgrade, because they control 100% of their logins/passwords
along with all of the linked servers, remote servers, and other external
links.

With an inplace upgrade, you ALWAYS have a fall back plan as well. If it
doesn't work, you uninstall 2005, reinstall 2000, and drop the databases
back in. (If you don't have backups, don't even think about upgrading.) I
fail to see where you no longer have a fall back plan and I fail to see how
dozens of manual copy operations, many of which are impossible for a DBA or
anyone else in IT to validate is less risky.

It might be very convenient for you to have spare hardware lying around that
allows you to build completely new clusters whether you need to upgrade
something. Very few organizations, and that includes nearly the entire
Fortune 50, have hardware lying around that you can simply install new
clusters and then manually copy stuff over.

--
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.


"Russ Kaufmann [MVP]" <russ@xxxxxxxxxxxxxxx> wrote in message
news:%23rJjyGtbGHA.3504@xxxxxxxxxxxxxxxxxxxxxxx
"Michael Hotek" <mike@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:O$jVjMnbGHA.2456@xxxxxxxxxxxxxxxxxxxxxxx
Yes, but that's coming from two people who deal with Windows clusters.

It ain't that simple for SQL Server. You have to copy all of the logins
over and make sure they are recreated in the correct order. You have to
possibly load drivers that are used by linked servers as well as making
sure
the logins and passwords for those are moved over. You have to make sure
that databases get locked off in the current cluster and then properly
brought online on the nw cluster while also ensuring that all of the
login/user linkages are correct and permissions are set properly. You
then
have to deal with DTS packages, jobs, error messages, and the list goes
on
and on and on.

Oh, I realize that there is a great deal of work involved. That doesn't
make it any less appropriate of a method when it comes to risk mitigation.
BTW, I do much more than just handle clustering. I maintain many SQL
servers as well as Exchange servers.

Doing a side-by-side upgrade is actually much riskier that upgrading SQL
Server in place, because there are dozens of things that you need to
manually extract and then apply to a new failover cluster instance.

How is it more risky when you have the ability to test each component and
_always_ have a valid fall back position? Having a fall back plan is vital
to proper change control.

You have a further issue with SQL Server if you are going to install a
2005
instance into the same cluster as the 2000 instance. If the databases on
your 2000 instance are using X drive letters, you have to add X more disk
resources to the cluster and set them up for dependencies on the new 2005
instance. Do you have that many spare disk resources just lying around
to
use?

I am recommending a new cluster, not a new instance. I am recommending
migrating databases from one cluster to another.

Installing a new instance of 2005 means that it now has a different name.
Who is going to track down all of the applications that need to have
connection strings changed in them and then retest all of those
applications
to make sure they still work?

In an HA shop, those would all be documented. Documentation is a key
component to an HA environment.

An in place upgrade is recommended, simply because you do not have to
worry
about ANY of the issues outlined above since they are all taken care of
during the upgrade process.

Recommended by whom?

Obviously, you have never done an in place upgrade and had it fail
miserably and then had to spend all weekend restoring servers and
databases to get things working again. To top it off, I bet you haven't
ever had to tell a CIO or a CEO of a fortune 500 company how you cost them
millions of dollars in down time. <G>

I am speaking from experience.

I've done 1 side-by-side upgrade and it was the most time consuming mess
that I've seen in a long time. They went through months of analysis and
testing and even then it took them 4 tries to get the thing up and
running, because they kept missing applications that were broken.

I bet that each time they were thankful that they had something to fall
back to and save their careers.

The next dozen clusters that were upgraded were done so in-place. Each
of these upgraded correctly the first time, everything worked, all
applications functioned, and we had a total outage of less than 1 minute
per failover cluster instance.

Congrats. I am glad to hear that they were successful.

What it all comes down to is this:
1. Clustering was put in place because of the importance of the data to
the company.
2. Down time for some companies can cost millions per day and even per
hour.
3. High availability is much more than just clustering.
4. Risk mitigation is a huge part of high availability.
5. Decisions regarding risk levels and mitigation costs are management
decisions. Let them put their necks on the line. Let's keep us IT'ers
employed. <G>

--
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp




.

Relevant Pages

  • Re: Server Clusters: Rolling Upgrades. Upgrading to Windows Server
    ... then join it back into the cluster? ... and proceeded to allow it to continue the boot process, ... I then had it boot from CD again and told it to continue the upgrade ... it said that the previous install had not completed and if you would ...
    (microsoft.public.windows.server.clustering)
  • Re: Installing DHCP & Print Server on a Win2K3 Enterprise server cluster
    ... I am back here after the upgrade (not successful. ... Introduced the new Win2K3 cluster tried ... additional servers if I have to implement two DHCP servers with two ... High availability is so much more than that. ...
    (microsoft.public.windows.server.clustering)
  • Re: Adding a new node to an existing cluster
    ... Make sure you install from one of the new machines. ... Make sure you have someone standing over your shoulder watching the screens ... node SQL Cluster a few months back, ... >> You will add SQL to the new servers only, ...
    (microsoft.public.sqlserver.clustering)
  • RE: New SQL 2005 Cluster Questions
    ... You have only one SQL instance in the cluster. ... So, from what I am seeing is I have no choice but to DC the servers, cluster ... Win2003 Ent and then install SQL 2005 Ent onto this cluster. ...
    (microsoft.public.sqlserver.clustering)
  • Re: Share offline
    ... with Windows Server 2008 and the feedback has been overwhelmingly positive. ... previous releases just the process to install Cluster could sometimes be ... install process requiring user input. ... as there some times is not an upgrade path. ...
    (microsoft.public.windows.server.clustering)
Loading