Using Windows clustering requires too long a failover time for my company's
uptime requirements. While SQL 2005's mirroring decreases the failover
time, it also only allows me to mirror to one server, thus putting me in a
rough spot for DR.
Is there any Oracle RAC type equivalent functionality (i.e. shared cache)
planned for future versions of SQL 2005, or available via some 3rd party
today for use with SQL 2005 today? The net is, I need as little downtime as
possible, both within a site, and across to my DR site (and as little to no
data loss as possible to that DR site)...all the while (of course)
minimizing the perf hit all of this requires...though while perf needs to
still fall in acceptable ranges, better perf is not as important as faster
failover and no data loss.
Any help is appeciated.
Thanks
RAC is by no means a High Availability feature so I am confused as to the
subject. There is no SQL Server RAC equivalent in the current release for a
read write database. However there are several HA / DR features that SQL
Server has that people use every day to satisfy their HA / DR needs. How
fast the recovery and how little down time is usually more a factor of how
much money you wish to spend. For instance you can do mirroring to get fast
up time and use the SAN's features to do DR. This is just a simple example
and it will really depend on what you want, what you have to work with and
how much time and money youa re willing to put into it. You might want to
start here:
http://www.microsoft.com/sql/technologies/highavailability/default.mspx
Andrew J. Kelly SQL MVP
"Jim" <ilmm555@.yahoo.com> wrote in message
news:uimO$QJhHHA.4980@.TK2MSFTNGP02.phx.gbl...
> Using Windows clustering requires too long a failover time for my
> company's uptime requirements. While SQL 2005's mirroring decreases the
> failover time, it also only allows me to mirror to one server, thus
> putting me in a rough spot for DR.
> Is there any Oracle RAC type equivalent functionality (i.e. shared cache)
> planned for future versions of SQL 2005, or available via some 3rd party
> today for use with SQL 2005 today? The net is, I need as little downtime
> as possible, both within a site, and across to my DR site (and as little
> to no data loss as possible to that DR site)...all the while (of course)
> minimizing the perf hit all of this requires...though while perf needs to
> still fall in acceptable ranges, better perf is not as important as faster
> failover and no data loss.
> Any help is appeciated.
> Thanks
|||OK, while RAC's original intent is to be a scale out feature, it's also very
much an HA feature...as if a node dies, other nodes press on...there's no
notion of "failover", thus eliminating the need to failover.
I disagree with it being "a factor of how much money you wish to spend"...as
regardless of how much you spend, the best you'll get SQL to is seconds of
downtime (with mirroring, likely 10s of seconds-minutes with
clustering)...thus, if you were to patch once a month (between SQL and
Windows this is certainly not out of the realm of possibility), that's
twelve failovers per year, at (at best...10 seconds of downtime each
failover)...so you're at 120 seconds a year...99.999% availability is 52.256
seconds...so you're already down to under 5 9's availability for the year.
In this shop, there's no notion of "unplanned downtime"...we're 24x7...it's
ALL downtime.
As for mirroring with SAN replicaiton for DR...below I mention no data loss,
so you'd be talking about synchronous mirroing WITH synchronous SAN
replication...while I said perf isn't the highest priority...I wonder how
slow it would be with effectively 3 writes for each write (one to the
primary SQL, one to the secondary SQL, one to the DR site...and since this
is all synchronous...all writes have to be completed before the
transaction's commited)...plus, now you're using SQL failover functionality
and SAN failover functionality...I certainly wonder how (operationally)
feasible this all will be...I'm sure it will be feasible, but certainly not
seamless...
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:uPErZcShHHA.4064@.TK2MSFTNGP02.phx.gbl...
> RAC is by no means a High Availability feature so I am confused as to the
> subject. There is no SQL Server RAC equivalent in the current release for
> a read write database. However there are several HA / DR features that SQL
> Server has that people use every day to satisfy their HA / DR needs. How
> fast the recovery and how little down time is usually more a factor of how
> much money you wish to spend. For instance you can do mirroring to get
> fast up time and use the SAN's features to do DR. This is just a simple
> example and it will really depend on what you want, what you have to work
> with and how much time and money youa re willing to put into it. You might
> want to start here:
> http://www.microsoft.com/sql/technologies/highavailability/default.mspx
>
> --
> Andrew J. Kelly SQL MVP
> "Jim" <ilmm555@.yahoo.com> wrote in message
> news:uimO$QJhHHA.4980@.TK2MSFTNGP02.phx.gbl...
>
|||While RAC does give some flexibility in terms of a single node failure there
are still plenty of places that are close to single point of failure without
additional effort. And it does nothing for DR. Oracle or anyother rdbms has
no magic solution to guarantee 0 down time. It really boils down to the
limitations of hardware. You are not the 1st company looking for 24X7
operation. Hundreds if not thousands of companies use SQL Server every day
for 5 nines of availability. I disagree with the down time for the number
of patches. How often you patch is often up to you. I had a system running
for almost 3 years. It was secure and did what we wanted so we choose not to
patch it.
Andrew J. Kelly SQL MVP
"Jim" <ilmm555@.yahoo.com> wrote in message
news:eMz1vgVhHHA.1388@.TK2MSFTNGP05.phx.gbl...
> OK, while RAC's original intent is to be a scale out feature, it's also
> very much an HA feature...as if a node dies, other nodes press
> on...there's no notion of "failover", thus eliminating the need to
> failover.
> I disagree with it being "a factor of how much money you wish to
> spend"...as regardless of how much you spend, the best you'll get SQL to
> is seconds of downtime (with mirroring, likely 10s of seconds-minutes with
> clustering)...thus, if you were to patch once a month (between SQL and
> Windows this is certainly not out of the realm of possibility), that's
> twelve failovers per year, at (at best...10 seconds of downtime each
> failover)...so you're at 120 seconds a year...99.999% availability is
> 52.256 seconds...so you're already down to under 5 9's availability for
> the year. In this shop, there's no notion of "unplanned downtime"...we're
> 24x7...it's ALL downtime.
> As for mirroring with SAN replicaiton for DR...below I mention no data
> loss, so you'd be talking about synchronous mirroing WITH synchronous SAN
> replication...while I said perf isn't the highest priority...I wonder how
> slow it would be with effectively 3 writes for each write (one to the
> primary SQL, one to the secondary SQL, one to the DR site...and since this
> is all synchronous...all writes have to be completed before the
> transaction's commited)...plus, now you're using SQL failover
> functionality and SAN failover functionality...I certainly wonder how
> (operationally) feasible this all will be...I'm sure it will be feasible,
> but certainly not seamless...
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:uPErZcShHHA.4064@.TK2MSFTNGP02.phx.gbl...
>
|||Hello Jim,
I am interested you say that SQL clustering is to slow. I run 8 production
clusters of various sizes, one is 300 GB just for data and fail over takes
about 30 seconds. Is 30 seconds to slow? If so then using a database mirror
would be the way to go. You will need to ensure that the client is using
ADO.NET 2.0 so that your failover is supported. However, there will be no
need to handle the failover as there is when using TAF on RAC.
Having said that currently SQL server has no RAC equivalency for scaling
out. If this is a requirement I would go with a HP Itanium system such as
the 6840 this would allow you to scale up over time rather than scaling out.
Let me know if you need clarification
John Vandervliet.
"Jim" <ilmm555@.yahoo.com> wrote in message
news:uimO$QJhHHA.4980@.TK2MSFTNGP02.phx.gbl...
> Using Windows clustering requires too long a failover time for my
> company's uptime requirements. While SQL 2005's mirroring decreases the
> failover time, it also only allows me to mirror to one server, thus
> putting me in a rough spot for DR.
> Is there any Oracle RAC type equivalent functionality (i.e. shared cache)
> planned for future versions of SQL 2005, or available via some 3rd party
> today for use with SQL 2005 today? The net is, I need as little downtime
> as possible, both within a site, and across to my DR site (and as little
> to no data loss as possible to that DR site)...all the while (of course)
> minimizing the perf hit all of this requires...though while perf needs to
> still fall in acceptable ranges, better perf is not as important as faster
> failover and no data loss.
> Any help is appeciated.
> Thanks
|||Do you run 8 production clusters where all of them are single instance
cluster..i.e one active and one passive or do you have a multi instance
cluster say more than 2 active nodes with 1 passive node for any of the
active nodes to failover.
"John Vandervliet" <jvandervliet@.SJRB.AD> wrote in message
news:7FE2AB87-4B70-44A0-8400-85B209FC6626@.microsoft.com...
> Hello Jim,
> I am interested you say that SQL clustering is to slow. I run 8 production
> clusters of various sizes, one is 300 GB just for data and fail over takes
> about 30 seconds. Is 30 seconds to slow? If so then using a database
> mirror would be the way to go. You will need to ensure that the client is
> using ADO.NET 2.0 so that your failover is supported. However, there will
> be no need to handle the failover as there is when using TAF on RAC.
> Having said that currently SQL server has no RAC equivalency for scaling
> out. If this is a requirement I would go with a HP Itanium system such as
> the 6840 this would allow you to scale up over time rather than scaling
> out.
> Let me know if you need clarification
> John Vandervliet.
>
> "Jim" <ilmm555@.yahoo.com> wrote in message
> news:uimO$QJhHHA.4980@.TK2MSFTNGP02.phx.gbl...
>
|||We run a combination most the instances are active/passive setups, howerver
we have 3 clusters that each of 2 instances of SQL. the servers are exact
matches of each other and can handle the load for both instances when needed.
"Hassan" wrote:
> Do you run 8 production clusters where all of them are single instance
> cluster..i.e one active and one passive or do you have a multi instance
> cluster say more than 2 active nodes with 1 passive node for any of the
> active nodes to failover.
>
> "John Vandervliet" <jvandervliet@.SJRB.AD> wrote in message
> news:7FE2AB87-4B70-44A0-8400-85B209FC6626@.microsoft.com...
>
>
|||On Apr 26, 5:12 pm, John Vandervliet
<JohnVandervl...@.discussions.microsoft.com> wrote:
> We run a combination most the instances are active/passive setups, howerver
> we have 3 clusters that each of 2 instances of SQL. the servers are exact
> matches of each other and can handle the load for both instances when needed.
>
> "Hassan" wrote:
>
>
>
>
>
> - Show quoted text -
Hassan,
My employer SteelEye Technology has a solution called LifeKeeper for
SQL Server. With our solution we can cluster 2-nodes locally with
either shared storage or syncronous host based replication and also
support a 3rd node in the DR site with either sync or async
replication. Of course sync replication will impact performance if
done across a WAN, but it is the only way to guarantee no data loss.
Failover time is similar to MSCS, so if that is too long, you will
have to look elsewhere.
Here is some information.
www.steeleye.com/pdf/literature/lifekeeper_for_sql_server.pdf
David A. Bermingham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com
没有评论:
发表评论