| Groups | Blog | Home |
sql server clustering : W2K3 and SQL 2000 High Availability?
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.)
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 -- -- 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. [quoted text, click to view] "dm1608" <dm1608@spam.net> wrote in message news:ODTUAgjNGHA.344@TK2MSFTNGP11.phx.gbl... > 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.) > > >
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. -- 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. [quoted text, click to view] "dm1608" <dm1608@spam.net> wrote in message news:ODTUAgjNGHA.344@TK2MSFTNGP11.phx.gbl... > 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.) > > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |