I have a fairly unique scenario, and I would like to see if anyone can point
out any potential holes of difficulties with this migration plan:
What client has -- 1 SQL Server 2000 enterprise Edition running on SQL 2003
NOT clustered, and using a SCSI disk array.
What client wants -- 2 SQL Server 2005 systems, running on a 2 node cluster
(Active-Passive) using a shared FiberChannel SAN. The active system will be
new, the failover system will be current system listed above. Note that
Clustering HCL has already been verified.
Goals -- provide ability to perform a gradual, testable migration from SQL
Server 2000 to SQL Server 2005 Cluster
Plan:
1) Setup New Server and SAN. Connect Both New server and old server to SAN
2) Install MS Clustering service on both servers, keeping original
un-clustered SQL 2000 in production
3) Install new instance of SQL 2005 on cluster
4) Test and then migrate databases from SQL Server 2000 to new SQL Server
2005 cluster one at a time. This means running the non-clustered SQL 2000 on
the physical hardware as the clustered SQL 2005 failover node. I realize
that failover probably wont work well during the transition, due to a lack of
resources.
5) When transition is complete, remove SQL Server 2000 from failover node.
Any thoughts or comments would be greatly appreciated.
Thanks,
Paul
My only concern is that you are reusing the existing node as a cluster node.
For simplicity's sake, I would create a a clustered installation without
reusing any of the existing hardware. You then have the original system
completely untouched during the transition. You don't need to connect the
existing SQL server to the SAN to do a minimal down time transfer. Given
proper set up time, I can do a server cutover in less than 15 minutes,
regardless of the total database size or count. Since you are moving one DB
at a time, it even gets easier.
If you have to reuse the existing hardware, I would add it to the cluster
after migration is complete. Install the cluster to a single-node, perform
the migration/cutover, and then reload the OS and add the node to the
cluster. You won't have failover redundancy until the project is complete,
but since you don't have that now, you won't miss it.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"PMartin" <PMartin@.discussions.microsoft.com> wrote in message
news:413AB596-D87F-4EFD-93E3-5335FAC3D647@.microsoft.com...
>I have a fairly unique scenario, and I would like to see if anyone can
>point
> out any potential holes of difficulties with this migration plan:
> What client has -- 1 SQL Server 2000 enterprise Edition running on SQL
> 2003
> NOT clustered, and using a SCSI disk array.
> What client wants -- 2 SQL Server 2005 systems, running on a 2 node
> cluster
> (Active-Passive) using a shared FiberChannel SAN. The active system will
> be
> new, the failover system will be current system listed above. Note that
> Clustering HCL has already been verified.
> Goals -- provide ability to perform a gradual, testable migration from SQL
> Server 2000 to SQL Server 2005 Cluster
> Plan:
> 1) Setup New Server and SAN. Connect Both New server and old server to
> SAN
> 2) Install MS Clustering service on both servers, keeping original
> un-clustered SQL 2000 in production
> 3) Install new instance of SQL 2005 on cluster
> 4) Test and then migrate databases from SQL Server 2000 to new SQL Server
> 2005 cluster one at a time. This means running the non-clustered SQL 2000
> on
> the physical hardware as the clustered SQL 2005 failover node. I realize
> that failover probably wont work well during the transition, due to a lack
> of
> resources.
> 5) When transition is complete, remove SQL Server 2000 from failover
> node.
> Any thoughts or comments would be greatly appreciated.
> Thanks,
> Paul
>
|||Geoff,
Unfortunately, we do need to re-use the hardware, so your suggestion of
installing a single node cluster sounds like oustanding advice. The lack of
failover during the transition will not be critical.
You mentioned reloading the OS on the current (soon to be failover) server.
Is this neceessary with Windows 2003, or just wise a precaution?
Thanks again!
Paul
"Geoff N. Hiten" wrote:
> My only concern is that you are reusing the existing node as a cluster node.
> For simplicity's sake, I would create a a clustered installation without
> reusing any of the existing hardware. You then have the original system
> completely untouched during the transition. You don't need to connect the
> existing SQL server to the SAN to do a minimal down time transfer. Given
> proper set up time, I can do a server cutover in less than 15 minutes,
> regardless of the total database size or count. Since you are moving one DB
> at a time, it even gets easier.
> If you have to reuse the existing hardware, I would add it to the cluster
> after migration is complete. Install the cluster to a single-node, perform
> the migration/cutover, and then reload the OS and add the node to the
> cluster. You won't have failover redundancy until the project is complete,
> but since you don't have that now, you won't miss it.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
>
> "PMartin" <PMartin@.discussions.microsoft.com> wrote in message
> news:413AB596-D87F-4EFD-93E3-5335FAC3D647@.microsoft.com...
>
>
|||I have prefer clean OS installs over upgrades. I have never personally had
any problems with 2000-2003 upgrades, but I have had issues with earlier OS
upgrade paths. I have even go so far as to upgrade each node in a cluster
then go back and wipe and reload each node, just so I don't have any
leftover bits. Since you will be migrating a W2000/SQL 2000 standalone host
to a W2003/SQL2005 clustered host, I would definitely wipe the system and
start over. If nothing else, you can guarantee it is an exact OS match for
its peer node.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"PMartin" <PMartin@.discussions.microsoft.com> wrote in message
news:F8076304-BBFE-4447-B0D8-D7A39F0544D4@.microsoft.com...[vbcol=seagreen]
> Geoff,
> Unfortunately, we do need to re-use the hardware, so your suggestion of
> installing a single node cluster sounds like oustanding advice. The lack
> of
> failover during the transition will not be critical.
> You mentioned reloading the OS on the current (soon to be failover)
> server.
> Is this neceessary with Windows 2003, or just wise a precaution?
> Thanks again!
> Paul
> "Geoff N. Hiten" wrote:
|||I don't see anything wrong with this. It's the way that I've upgraded more
than one system already.
Mike
Mentor
Solid Quality Learning
http://www.solidqualitylearning.com
"PMartin" <PMartin@.discussions.microsoft.com> wrote in message
news:413AB596-D87F-4EFD-93E3-5335FAC3D647@.microsoft.com...
>I have a fairly unique scenario, and I would like to see if anyone can
>point
> out any potential holes of difficulties with this migration plan:
> What client has -- 1 SQL Server 2000 enterprise Edition running on SQL
> 2003
> NOT clustered, and using a SCSI disk array.
> What client wants -- 2 SQL Server 2005 systems, running on a 2 node
> cluster
> (Active-Passive) using a shared FiberChannel SAN. The active system will
> be
> new, the failover system will be current system listed above. Note that
> Clustering HCL has already been verified.
> Goals -- provide ability to perform a gradual, testable migration from SQL
> Server 2000 to SQL Server 2005 Cluster
> Plan:
> 1) Setup New Server and SAN. Connect Both New server and old server to
> SAN
> 2) Install MS Clustering service on both servers, keeping original
> un-clustered SQL 2000 in production
> 3) Install new instance of SQL 2005 on cluster
> 4) Test and then migrate databases from SQL Server 2000 to new SQL Server
> 2005 cluster one at a time. This means running the non-clustered SQL 2000
> on
> the physical hardware as the clustered SQL 2005 failover node. I realize
> that failover probably wont work well during the transition, due to a lack
> of
> resources.
> 5) When transition is complete, remove SQL Server 2000 from failover
> node.
> Any thoughts or comments would be greatly appreciated.
> Thanks,
> Paul
>
