migrating a SQL Cluster to new hardware

I need your advise on migrating a two node SQL 2000 cluster to new hardware
including servers and disks.
thanks.
Amila
Create a new cluster with the new hardware, install a SQL instance, and then
migrate the databases over to the new instance (e.g. following steps in
http://vyaskn.tripod.com/moving_sql_server.htm and its referenced articles).
If the shared drives are presented from a SAN, you can remove the drives
from the cluster, create a new cluster, install a SQL instance in exactly the
same way as the existing SQL instance, and present the shared drives to the
new cluster.
If you can afford the downtime, and want to keep the server names, you can
remove the shared drives (LUNs), deactivate the cluster nodes, create a new
cluster with the same node names, cluster names, and virtual server names,
install a SQL instance, and present the same LUNs to the new cluster. The new
SQL instance can come up exactly the same as the previous one.
You may also try to perform the so-called rolling upgrade, i.e. upgrade one
node to new hardware a time.
Which method to choose depends on your upgrade requirements.
Linchi
"Amila chandrasekera" wrote:

> I need your advise on migrating a two node SQL 2000 cluster to new hardware
> including servers and disks.
>
> thanks.
> Amila
>
>
|||We have done both of what Linchi suggested: new system build/disk migration
versus node rebuild/upgrade.
The new cluster build is cleaner/easier, but then your applications have to
be migrated to the new host name (unless you can incur the long outage).
The node rebuild/upgrade is not quite as clean, but it minimizes the impact
to your end users.
Check out the maintenance and troubleshooting sections of the following
guide. There is also a link at the top that directs you to the 2005 doc as
well. Read both.
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/failclus.mspx#E14AG
The short sequence is:
Uninstall passive node from the sql server setup.
Evict passive node from cluster administrator.
Rebuild passive node.
Join rebuilt node through cluster administrator.
Install rebuilt node to sql server setup.
Patch sql server rebuilt node to current patch + hotfix as active node.
Move over resources and repeat for each cluster node.
Sincerely,
Anthony Thomas

"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
> I need your advise on migrating a two node SQL 2000 cluster to new
hardware
> including servers and disks.
>
> thanks.
> Amila
>
|||Run upgrade advisor to detect upgrade issues, run checkdb on the databases
on the clusters, detach them, copy them (do not move them) to the new
cluster, attach them, run checkdb, update statistics, back them up. Migrate
all dependencies (logins, jobs, extended stored procedures, com objects and
file paths).
Check all functionality on the new cluster. Roll back if you have to by
reattaching the existing database on the old cluster.
repoint the client applications.
You might want to review all methods to do this in the
http://download.microsoft.com/download/1/6/c/16c0ec7a-bb53-4aea-9020-cb2f80424322/SQL2005UpgradeTechRef.doc
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
>I need your advise on migrating a two node SQL 2000 cluster to new hardware
>including servers and disks.
>
> thanks.
> Amila
>
|||Thanks for the replies so far. This migration is from SQL 2000 to SQL 2000
(both source and target are running on Windows 2003 Advanced server). I am
not planning to do a SQL 2005 upgrade with this migration. It is purely a
hardware upgrade only.
Here is what I am thinking of doing.
Asume Node1 and Node2 are the current production SQL cluster nodes.
Node3 and Node4 are the new servers.
1. Move all cluster roles to Node1
2. Evict node2 from the cluster
3. Conect Node3 and join it to the cluster
4. Move all cluster roles to Node3
5. Evict Node1 from cluster
6. Connect Node4 and join it to the cluster
7. Connect Node3 and Node4 to the new SAN (while connected to the old SAN )
8. Setup Quorum and data stores in the new SAN
9. Move Quorum to the new SAN
10. Shutdown the SQL Server
11. Copy SQL DBs from old SAN to the new SAN. Change Drive letter mappings
to maintain the paths.
12. Disconnect old SAN connection completely.
13. Start SQL Server
Is this feasible ? Am I missing anything here ?
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
>I need your advise on migrating a two node SQL 2000 cluster to new hardware
>including servers and disks.
>
> thanks.
> Amila
>
|||Before eviting the nodes, you have to run the SQL installer to remove the
node from the SQL cluster configuration. You cn run it afterwards and force
it out, but that takes longer. You also have to run the installer and
install SQL to the new nodes. You then need to re-apply any service packs.
GNH
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:OGAFgGFUHHA.1212@.TK2MSFTNGP03.phx.gbl...
> Thanks for the replies so far. This migration is from SQL 2000 to SQL 2000
> (both source and target are running on Windows 2003 Advanced server). I am
> not planning to do a SQL 2005 upgrade with this migration. It is purely a
> hardware upgrade only.
> Here is what I am thinking of doing.
> Asume Node1 and Node2 are the current production SQL cluster nodes.
> Node3 and Node4 are the new servers.
> 1. Move all cluster roles to Node1
> 2. Evict node2 from the cluster
> 3. Conect Node3 and join it to the cluster
> 4. Move all cluster roles to Node3
> 5. Evict Node1 from cluster
> 6. Connect Node4 and join it to the cluster
> 7. Connect Node3 and Node4 to the new SAN (while connected to the old
> SAN )
> 8. Setup Quorum and data stores in the new SAN
> 9. Move Quorum to the new SAN
> 10. Shutdown the SQL Server
> 11. Copy SQL DBs from old SAN to the new SAN. Change Drive letter mappings
> to maintain the paths.
> 12. Disconnect old SAN connection completely.
> 13. Start SQL Server
> Is this feasible ? Am I missing anything here ?
>
> "Amila chandrasekera" <achandra@.insight.com> wrote in message
> news:%23h6t5u7SHHA.412@.TK2MSFTNGP02.phx.gbl...
>
|||How Can I remove SQL after evicting the node ?
"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:OQ5q9KFUHHA.1180@.TK2MSFTNGP05.phx.gbl...
> Before eviting the nodes, you have to run the SQL installer to remove the
> node from the SQL cluster configuration. You cn run it afterwards and
> force it out, but that takes longer. You also have to run the installer
> and install SQL to the new nodes. You then need to re-apply any service
> packs.
> GNH
>
> "Amila chandrasekera" <achandra@.insight.com> wrote in message
> news:OGAFgGFUHHA.1212@.TK2MSFTNGP03.phx.gbl...
>
|||Go ahead and run the installer on the remaining node. When you remove the
evicted node from SQL the installer will time out and isue a warning, but it
will remove it from the SQL configuration.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Amila chandrasekera" <achandra@.insight.com> wrote in message
news:e9erf1pVHHA.3568@.TK2MSFTNGP06.phx.gbl...
> How Can I remove SQL after evicting the node ?
> "Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
> news:OQ5q9KFUHHA.1180@.TK2MSFTNGP05.phx.gbl...
>
|||You can also remove it manually, but the Best Practice is to use the SQL
Server setup instead.
http://support.microsoft.com/kb/290991/en-us
Sincerely,
Anthony Thomas

"Geoff N. Hiten" <SQLCraftsman@.gmail.com> wrote in message
news:O84Iu3qVHHA.4964@.TK2MSFTNGP06.phx.gbl...
> Go ahead and run the installer on the remaining node. When you remove the
> evicted node from SQL the installer will time out and isue a warning, but
it[vbcol=seagreen]
> will remove it from the SQL configuration.
>
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "Amila chandrasekera" <achandra@.insight.com> wrote in message
> news:e9erf1pVHHA.3568@.TK2MSFTNGP06.phx.gbl...
the[vbcol=seagreen]
installer[vbcol=seagreen]
service[vbcol=seagreen]
migration.
>