December 7, 2009 at 9:57 am
I just started working for a company that retrieves location information via the Internet and supplies ads based on that information. Our database is fairly small at only 30 gb but requires high availability. We are currently using a high availability mirror with local hard drives. However, we are moving to a SAN environment and two new 64 bit/32 GB RAM servers and 1 TB SAN in a few weeks along with a new version of the software and DB. So for planning purposes I am looking at moving from the Mirror to a Clustered Server. The new hardware and SAN will also be supporting an upcoming Data Warehouse application which will be based on the current data over time.
My goal is (in order of importance):
1. Quick automatic response in case of hardware failure.
2. Scalability of services as the application grows. Looking to scale out not UP.
3. Ease of Maintenance (SP upgrades, changes to DB, etc)
My background includes some SAN and clustering and hence the thoughts of going to the cluster, however, the response time of a failover may not meet the requirements of the application.
So I am looking for inputs or articles from those of you who have had to work on this type of situation.
Thanks,
Raymond Laubert
Exceptional DBA of 2009 Finalist
MCT, MCDBA, MCITP:SQL 2005 Admin,
MCSE, OCP:10g
December 7, 2009 at 10:30 am
1. Quick automatic response in case of hardware failure.
Failover Clustering will not provide HA when the hardware failure is related to your storage system.
It will only failover and provide HA only when one of the participating nodes have a internal hardware / software failure.
2. Scalability of services as the application grows. Looking to scale out not UP.
WIth the current size of 30 GB of your database, I don't think it needs a immediate scalability plans, of course there may be another issues identified by you. So without knowing those, it is difficult to give a solution.
When it comes to Scale Out, I think Peer-to-Peer Replication can be a very good solution.
3. Ease of Maintenance (SP upgrades, changes to DB, etc)
Ease of maintenance depends on what solution we choose.
My suggestion would be having a Failover Clustering together with DB Mirroring with client redirect.
Blog -- LearnSQLWithBru
Join on Facebook Page Facebook.comLearnSQLWithBru
Twitter -- BruMedishetty
December 7, 2009 at 1:18 pm
Not too concerned with drive failure as we will be on a high end SAN with lots of fault tolerance and access capabilities.
We will also be using MPIO and each server will have multiple paths to the SAN.
Availability is the major concern from the server standpoint. I am still trying to find out if we have any SLA for performance and recovery time. If we have an availability or recovery time requirement that will probably drive which why I end up going.
Still looking for additional insight from those that have had to address this kind of design issue.
Thanks
Raymond Laubert
Exceptional DBA of 2009 Finalist
MCT, MCDBA, MCITP:SQL 2005 Admin,
MCSE, OCP:10g
December 7, 2009 at 8:26 pm
Your application may need to be changed for it to work in a mirrored environment. The connection string needs to include "Failover Partner=ServerName". This was introduced with SQL 2005 as part of SNAC and is not used by/available with older methods for connecting to the databas server.
Depending on the application and how it connects to the database server, "Failover Partner" may or may not be supported. .Net applications should be OK. Older applications - maybe not.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply