W2K3 and SQL 2000 High Availability?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

dm1608 - 20 Feb 2006 16:09 GMT

Hello -- I hope this is the right group.

I have a particular ecommerce application at work that currently runs on one
IIS 6.0 and SQL Server 2000 box. The web application reads various "theme"
data for out customers to display their particualr theme when they log on.
It also stores session state information in the database as users connect to
the website. Customer transactional information is stored on our backend
mainframe.

Currently, when we do software upgrades to the website, we have to bring the
site down in order to upgrade. Downtime costs us money and also
inconveniences our customers.

For backups, we have another identical 1U server that we typically clone the
hard disk between the production and backup system using hardware RAID.
Basically, we take the mirrored disk from production and boot up on the
backup and resync the mirror on both the production and backup boxes. This
works, but is a pain and still doesn't address our issue with downtime.

I suppose I have a few options and would like to solicate your feedback on
the best choice for my environment. We do have a Dell 300CTX SAN that could
be used between the two boxes should I want to do some sort of clustering.
Not exactly sure how to do this yet, but this is an option.

Since I do not believe I can have two databases running together nor keep
them in sync., I thought I could simply use NT's NLB to load balance between
two front-end IIS and simply have one of the IIS servers pointing to the
database on the other. The only issue, in my mind, with this is that I
have a single point of failure with the database; which happens to run on
the same IIS box???

Another option would be to install a fiber card in each of my servers and
have them configured in a cluster and have the database reside on the SAN.
I assume that there needs to be some sort of failover mechanism to move over
automatically to the other server in the event the primary goes down???

Finally, I woud like some way that I could do rolling ugrades to the servers
without having any downtime. I suppose the clustering scanarious is my only
real choice here???

One the the other challenges that I face is that the web application uses
the database for everything... but also requires a bunch of information to
reside in the registry of each machine and filesystem. Therefore, in order
to have a second server, replicating my changes from one server to the next
will be a chore.

Any recommendations, online resources, etc., would be appreciated.

If needed, I could upgrade to W2K3 and possibly use SQL 2005... (not sure on
SQL, but I can't imagine why it wouldn't work.)

Reply to this Message

Ryan Sokolowski (MVP) - 20 Feb 2006 21:18 GMT

Some answers in short...please write back if you need more info...

NLB = IIS = YES
MSCS = SQL = YES

Don't mix these together - keep 'em separate.

Fiber HBAs in each server (not Fiber NICs) and connected to Fibre Channel
Switches or to the SAN directly. Put the DB on the shared storage, set up a
quorum drive, configure MSCS, etc.

Clustering is a fantastic way to maintain uptime while doing upgrades /
patches and doing rolling upgrades is the key here...

Move your IIS installations elsewhere and cluster your two SQL 2000
servers...W2K3 as the OS is easier to work with w/r/t clustering, but you
don't *have* to upgrade anything, as I read it...

Hope this helps,
--Ryan

Signature

--
Ryan Sokolowski
MVP - Windows Server - Clustering
MCSE, CCNA, CCDA, BCFP

"A troubleshooter's best tool is the Event Viewer and understanding the
events and messages contained therein."

This posting is provided "AS IS" with no warranties, and confers no rights.

> Hello -- I hope this is the right group.
>
[quoted text clipped - 48 lines]
> If needed, I could upgrade to W2K3 and possibly use SQL 2005... (not sure
> on SQL, but I can't imagine why it wouldn't work.)

Reply to this Message

Michael Hotek - 21 Feb 2006 02:31 GMT

Lots of parts in here.

You can utilize clustering for the SQL Server. You would need to ensure
that your hardware config is certified for clusterings. Put the databases
on the SAN. This does leave an exposure though, clustering protects the
hardware only, it does not protect the data. Therefore, you will still have
to maintain an additional copy of the data elsewhere utilizing either log
shipping or replication.

Separate IIS from the SQL Server. This is for many reasons. It reduces the
load on a single server as well as provides a security barrier (someone
hacking the IIS server can't necessarily reach the DB server.)

The registry stuff is handled with registry replication at a Windows level.

As far as deploying your application, there is a lot of guidance out there
on developing and deploying apps with minimal impact to users. The
interesting parts come in when you have database and application changes
which are bundled together. That poses interesting challenges, however, if
you are designing all data access to pass through stored procedures, you
have isolated yourself. (It's the same as building components. The entire
internals of the component can change without affecting your app as long as
the interfaces remain the same.) So with all access done through stored
procedures, you can make database changes without impacting your
applications. Then you can deploy the database changes first and then lay
the new application code over the new structure without "theoretically"
impacting users.

Signature

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.

Reply to this Message