Cluster upgrade/migration issue advice.

Hey all,

We have a simple two-node x86 failover cluster attached to a SAN on which SQL Server 2005 runs. We recently bought two new x64 boxes to upgrade the cluster. My original plan was to just add the new nodes to the existing cluster and then remove the old nodes from the cluster, but I just found out that you can't mix architecture types in a cluster.

So far, it seems our choices are:

1) Install x86 Windows 2003 Server on the new nodes, losing performance.
2) Make a new cluster and migrate the data, possibly imposing downtime.

Anyone have any suggestions?You may be able to "swing" the LUNs from one cluster to the other, without much trouble. This depends on a number of factors, so you should contact your SAN vendor to see if it is feasible. If it is, then you build the 64-bit cluster, swing the LUNs over, attach all the DBs to the 64-bit instance of SQL Server, and then change all the applications that pointed to the old cluster. One caution, though, you should definitely take a real nice backup of all the databases, before you do the LUN switch, since you could potentially lose all of your databases to an inadvertent FORMAT command.|||Yeah, I think that's going to be the option we go with, since we can attach the new servers to the old LUNs, but that will involve some downtime.

I suppose we could replicate the dbs to a third server, update the important connections to point to the replicated server, do the move, point the connections to the new cluster.

Ugh.

Cluster and Mirroring with 2005

I am looking for some advice on the following problem.
I need a redundant SQL solution at our main location and a warm site in
a different, off site location. The warm site would only become a hot
site if we had a complete failure at the main location.
What I was thinking was to create a failover cluster at our main
location incase of simple hardware failure, the other server could take
over. At the warm site I would have a witness server and have the
database mirrored to a sql server there. I am going to be using sql
server 2005.
Is this a possible solution? If not, can you please point me in the
right direction. $$$ is not really an issue.
That is certainly a possible scenario. Remember that mirroring works at the
database level, not at the server level. You will have to do some
customization if you want to make it work for multiple databases. There are
also performance, latency, and network bandwidth costs for mirroring. The
lower your tolerance for data loss and outage time, the higher those costs.
If money really isn't an issue, you may want to look at SAN-level data
replication technologies. Since you will have a SAN for the cluster anyway,
this may be a better option. Make sure the SAN vendor can keep multiple
LUNS in synch or you may end up with mismatched data and log partitions,
causing a corrupt and unusable database.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
<dwclark@.gmail.com> wrote in message
news:1130250702.646778.85520@.g47g2000cwa.googlegro ups.com...
>I am looking for some advice on the following problem.
> I need a redundant SQL solution at our main location and a warm site in
> a different, off site location. The warm site would only become a hot
> site if we had a complete failure at the main location.
> What I was thinking was to create a failover cluster at our main
> location incase of simple hardware failure, the other server could take
> over. At the warm site I would have a witness server and have the
> database mirrored to a sql server there. I am going to be using sql
> server 2005.
> Is this a possible solution? If not, can you please point me in the
> right direction. $$$ is not really an issue.
>
|||I noticed that you said 'warm site'. By 'warm', I assume you can afford
losing some data during a site failover. If you can afford data loss of up
to 15 minutes or so, the plain old log shipping may be the simplest and
cheapest solution to consider. I'd keep it simple if a simple solution is
enough.
Linchi
<dwclark@.gmail.com> wrote in message
news:1130250702.646778.85520@.g47g2000cwa.googlegro ups.com...
>I am looking for some advice on the following problem.
> I need a redundant SQL solution at our main location and a warm site in
> a different, off site location. The warm site would only become a hot
> site if we had a complete failure at the main location.
> What I was thinking was to create a failover cluster at our main
> location incase of simple hardware failure, the other server could take
> over. At the warm site I would have a witness server and have the
> database mirrored to a sql server there. I am going to be using sql
> server 2005.
> Is this a possible solution? If not, can you please point me in the
> right direction. $$$ is not really an issue.
>
|||Database mirroring is certainly an option, but so would be log shipping,
remote mirroring, or stretch clustering.
You might want to check out the following. Although for SS2K, most of the
information still applies, with the exception of DB mirroring.
Microsoft SQL Server 2000 High Availability Series
http://www.microsoft.com/technet/pro...y/sqlhalp.mspx
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/pro...y/hasog05.mspx
SQL Server 2005 Mission Critical High Availability
http://www.microsoft.com/technet/pro...s/default.mspx
Sincerely,
Anthony Thomas

<dwclark@.gmail.com> wrote in message
news:1130250702.646778.85520@.g47g2000cwa.googlegro ups.com...
> I am looking for some advice on the following problem.
> I need a redundant SQL solution at our main location and a warm site in
> a different, off site location. The warm site would only become a hot
> site if we had a complete failure at the main location.
> What I was thinking was to create a failover cluster at our main
> location incase of simple hardware failure, the other server could take
> over. At the warm site I would have a witness server and have the
> database mirrored to a sql server there. I am going to be using sql
> server 2005.
> Is this a possible solution? If not, can you please point me in the
> right direction. $$$ is not really an issue.
>