Hi

We are running SQL Server 2000 on a Windows 2003 Server. The Windows 2003 Server is connected to a RAID disk array. The Windows 2003 server is a single point of failure. We want to add a second Windows 2003 box and connect it to the RAID as a backup node.

It seems there are two ways to do this

1) Implement Windows 2003 Clustering (need to move to Windows 2003 Enterprise??) where both nodes share an IP address. If the Primary node in the cluster fails the backup node in the cluster can start the SQL server service and handle requests. Is this one way to do this? Is this a good way

2) It looks like SQL server Enterprise implements "Failover" as a feature. This is not included in the "standard" edition. The Enterprise edition is much more expensive and I am not sure what it gains us over my first solution

3) If we use Windows 2003 Enterprise can we implement SQL server failover between nodes in the cluster WITHOUT purchasing the "Enterprise" edition of SQL Server 2000? Or do we NEED the "Enterprise" edition of SQL server

Any help explaining exaclty what we need to minimize costs would be appreciated

Thanks
Tod

Comments Inline

--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com

I support the Professional Association for SQL Server
www.sqlpass.org

"Todd Harrington" <anonymous (AT) discussions (DOT) microsoft.com> wrote

single point of failure. We want to add a second Windows 2003 box and
connect it to the RAID as a backup node.
the cluster fails the backup node in the cluster can start the SQL server
service and handle requests. Is this one way to do this? Is this a good way?
simplified version of clustering.

much more expensive and I am not sure what it gains us over my first
solution.
SQL Server 2000? Or do we NEED the "Enterprise" edition of SQL server?

Windows 2003 Enterprise Edition and SQL 2000 Enterprise Edition to implement
a SQL cluster. You also need to have hardware that is Cluster HCL approved
and vendor-certified to be eligible for support. Non-approved systems may
not offer the stability that you expect in a highly-available platform.

OK, what really happens in a cluster is that both host nodes have their own
IP addresses. The Cluster service has another IP address and each Virtual
SQL Server has yet another IP address. Both the Cluster and the SQL Server
look like complete machines to the outside world, even though they are
virtual systems. It is these virtual systems that can move between hosts.
That requires Enterprise Edition of the OS and SQL. If you are running with
one node as a 'standby', you will only need to license SQL for the active
node, not both nodes.

Enterprise Edition of SQL is the only edition that has the ability to create
this virtual server in a clustered environment. Standard edition cannot.
The basic clustering logic is supplied by the OS, but it requires additional
logic from the SQL application that is only included in Enterprise Edition.

And when you move a clustered instance from one host to another, the outside
world sees that as a brief shutdown and restart of the SQL service.

--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com

I support the Professional Association for SQL Server
www.sqlpass.org

"Todd Harrington" <anonymous (AT) discussions (DOT) microsoft.com> wrote

"Standard" and still utilitize the Windows 2003 clustienr features? Could we
set up a 2003 cluster with this configuration where one node is active and
runs the SQL Server "Standard" service. The other node is the standby node
in the cluster and if the primary node fails, the standy node will take over
the IP address and startup the SQL server service. Client requests will not
be handled by the Standby node. The standby will now have the IP address
that client expects and will be managing the database that the client
expects. I may be down for a few seconds when the failover happens.

An alternative is log shipping.

Constantly restoring the transaction log of one machine on another machine.
The second machine is thus in an standby mode in case machine one fails.

This is less expensive than implementing a cluster.

The layback is that the spare machine is not used until the primairy machine
fails.

Clustering is more expensive, but if you you distribute your databases over
the two (or more) virtual SQL machines and you run each virtual machine on a
different node all hardware is used to boost performance.

In this way you have both High Availibility and best performance with the
hardwareyou buy.

"Todd Harrington" <anonymous (AT) discussions (DOT) microsoft.com> wrote

single point of failure. We want to add a second Windows 2003 box and
connect it to the RAID as a backup node.
the cluster fails the backup node in the cluster can start the SQL server
service and handle requests. Is this one way to do this? Is this a good way?
much more expensive and I am not sure what it gains us over my first
solution.
SQL Server 2000? Or do we NEED the "Enterprise" edition of SQL server?