clustering enquires

Hi,
I would actually want to set up 2 exactSQL SERVER on 2 different physical
machine each with their own hardwares so that if one is down , the
application could immediately switch over to the working computer as well as
part of my Diaster Recovery Procedure (DRP)
I know that clustering works on using a SHARED DISK but that's not offering
me any DRP as if the shared disk is down then nothing could work.
actually i am quite confused with the Windows clustering and database
clustering , what are they actually and how can i work towards havings my SQL
Server really "clustered" with DRP-awareness ?(i.e in the sense it'll switch
seamlessly in event of failure of 1 server yet it can offer me DRP)
i would have thought that log shipping offers even a better sort of
clustering with DRP-awareness as well as the data can be on a different
machine eslewhere !! although need to change the role etc ..
appreciate ur advise
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums...ering/200601/1
Clustering is essentially a technology that binds two pieces of hardware
together and makes them function as a single logical piece of hardware.
This occurs at a purely Windows level. You install SQL Server into a
cluster as a simple application that is controlled by the Windows cluster.
What this gets you is the ability to have the SQL Server automatically
"restart" on a second piece of hardware in the event that the original piece
of hardware fails. Yes, all of your database reside on a single shared disk
aray that you need to configure with maximum disk redundancy, because as you
noted, when the disks are down, the SQL Server is down.
In order to work around that, you have to move to what I'd generically call
data duplication technologies. These are replication, log shipping, and
database mirroring (2005 only). With replication and log shipping, you are
employing technologies to maintain one or more copies of your data.
However, neither of these technologies has the capability to detect a
failure on the primary and switch anything to the secondary. You must do
this yourself. Database mirroring, in one particular configuration, has the
ability to maintain a duplicate copy of the data on another instance as well
as automatically detecting failure and failing over.
Clustering provides hardware redundancy ONLY, but can automatically detect
and failover
Replication and log shipping provide hardware and data redundancy, but can
have loss of data as well as requiring manual detection and failover
Database mirroring configured in HA mode provides hardware and data
redundancy along with automatic detection and failover, but incurs a
performance impact to accomplish this
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.
"maxzsim via droptable.com" <u14644@.uwe> wrote in message
news:5af55f097d8c0@.uwe...
> Hi,
> I would actually want to set up 2 exactSQL SERVER on 2 different physical
> machine each with their own hardwares so that if one is down , the
> application could immediately switch over to the working computer as well
> as
> part of my Diaster Recovery Procedure (DRP)
> I know that clustering works on using a SHARED DISK but that's not
> offering
> me any DRP as if the shared disk is down then nothing could work.
> actually i am quite confused with the Windows clustering and database
> clustering , what are they actually and how can i work towards havings my
> SQL
> Server really "clustered" with DRP-awareness ?(i.e in the sense it'll
> switch
> seamlessly in event of failure of 1 server yet it can offer me DRP)
> i would have thought that log shipping offers even a better sort of
> clustering with DRP-awareness as well as the data can be on a different
> machine eslewhere !! although need to change the role etc ..
> appreciate ur advise
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums...ering/200601/1
|||And if you can spend more money (actually a lot more), you can go for disk
level 'data replication' technology such as EMC's SRDF that can give you a
synchronous copy of your data at a different site, hence your no-data-loss
disaster recovery.
Linchi
"Michael Hotek" <mike@.solidqualitylearning.com> wrote in message
news:uWmI2d2IGHA.2912@.tk2msftngp13.phx.gbl...
> Clustering is essentially a technology that binds two pieces of hardware
> together and makes them function as a single logical piece of hardware.
> This occurs at a purely Windows level. You install SQL Server into a
> cluster as a simple application that is controlled by the Windows cluster.
> What this gets you is the ability to have the SQL Server automatically
> "restart" on a second piece of hardware in the event that the original
> piece of hardware fails. Yes, all of your database reside on a single
> shared disk aray that you need to configure with maximum disk redundancy,
> because as you noted, when the disks are down, the SQL Server is down.
> In order to work around that, you have to move to what I'd generically
> call data duplication technologies. These are replication, log shipping,
> and database mirroring (2005 only). With replication and log shipping,
> you are employing technologies to maintain one or more copies of your
> data. However, neither of these technologies has the capability to detect
> a failure on the primary and switch anything to the secondary. You must
> do this yourself. Database mirroring, in one particular configuration,
> has the ability to maintain a duplicate copy of the data on another
> instance as well as automatically detecting failure and failing over.
> Clustering provides hardware redundancy ONLY, but can automatically detect
> and failover
> Replication and log shipping provide hardware and data redundancy, but can
> have loss of data as well as requiring manual detection and failover
> Database mirroring configured in HA mode provides hardware and data
> redundancy along with automatic detection and failover, but incurs a
> performance impact to accomplish this
> --
> 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.
> "maxzsim via droptable.com" <u14644@.uwe> wrote in message
> news:5af55f097d8c0@.uwe...
>
|||Hi,
What you need seems to be a "geo cluster" : you have 2 rooms, each one has 1
server + 1 disk array (at least !).
Geo cluster are usually constructor dependant, as microsoft cluster services
are only able to handle shared disk arrays (single point of failure !). For
that reason, some disk array vendors provide peace of software that drive
hardware synchronous replication between the 2 disk arrays and make MSCS
"think" that it is only volumes on a shared disk array.
I use "SRDF/CE" ("Geospan") from EMC2 (we have 2 sites with EMC2 arrays on
each site) which works fine : it monitors volume replication (srdf) and makes
the interaction to enable volumes on the right site when doing failovers or
failbacks.
One important thing : it is only available for 32 bits windows at the moment
(we are waiting since Q2 2005 for the release of IA64 version *I FEEL KINDA
PISSED OFF*).
Note that Geo cluster usually make hardware replication in 1 direction :
when you failover, volumes replication is stopped, so a failback takes longer
time : volumes on drive arrays will have to be re-synchronized (automatically
on most solutions, but during this period, the resources that are moving are
offline !).
Another solution is to acquire a third party cluster aware volume manager
(like Veritas provides) which allows you to have the same type of abstraction
from the MSCS point of view, but uses different technology : writes via the
SAN to the volumes of both side simultaneously. It is faster for I/O writes,
as synchronous hardware solutions (like SRDF) waits for the acknowledge of
the write on the replicated volume to acknowledge a write, which creates a
small delay for each write (>=1 ms, depending of the distance and the
activity of the arrays).
The last solution i know, which is cheaper, is a "Geocluster" from NSI,
which provides mirrored disks for MSCS, and manages the moves like the 2
previous solutions, but uses the network for the replication ("IP based").
The advantage is that it allows you to make a solution without SAN or
exepensive disk arrays. The "problem" is the performance if you have very I/O
consuming environments.
All these solutions have a cost, and are not totally safe (MSCS quorum
remains a single point of failure, you can have "split brain" situations, and
a clustered SQLServer instance can't easily run outside MSCS), and doesn't
handle data corruption or human errors.
So it is important to think, if you want a complete DRP, to maintain a
"standby" instance via Log shipping, or Mirroring (2005 only), or self made
scripts. Ideally on a 3rd site ("ultimate drp") !
(Sorry for my bad English)
Guillaume.
====================================
"maxzsim via droptable.com" wrote:

> Hi,
> I would actually want to set up 2 exactSQL SERVER on 2 different physical
> machine each with their own hardwares so that if one is down , the
> application could immediately switch over to the working computer as well as
> part of my Diaster Recovery Procedure (DRP)
> I know that clustering works on using a SHARED DISK but that's not offering
> me any DRP as if the shared disk is down then nothing could work.
> actually i am quite confused with the Windows clustering and database
> clustering , what are they actually and how can i work towards havings my SQL
> Server really "clustered" with DRP-awareness ?(i.e in the sense it'll switch
> seamlessly in event of failure of 1 server yet it can offer me DRP)
> i would have thought that log shipping offers even a better sort of
> clustering with DRP-awareness as well as the data can be on a different
> machine eslewhere !! although need to change the role etc ..
> appreciate ur advise
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums...ering/200601/1
>
|||Another 3rd party option is LifeKeeper Protection Suite for SQL Server from
SteelEye Technology. It works with SQL 7/2000 standard and enterprise
editions and soon SQL 2005. It is an alternative to MSCS and provides both
the clustering capabilities and data replication capabilities in one package
from one vendor.
The benefits of host based replication from LifeKeeper is that you don't
have the issues that Guillaume described with storage based replication.
Failover and failback is seemless with only 2-3 minutes downtime during the
actual switchover process. The replication is automatically reversed so
that while running SQL in the DR site the changes are automatically being
replicated back to the primary site. Another benefit with LifeKeeper is
that it is a resource driven cluster, which means LifeKeeper does not
require a quorum disk, which is a single point of failure in MSCS.
In addition, LifeKeeper can support Active/Active clustering, Cascading
failover between multiple nodes (tested up to 32 nodes) and N+1
configurations with multiple active nodes and a single passive node.
LifeKeeper can work in a purely replicated storage environment, a shared
storage environment, or a hybrid environment with 2-Nodes local attached to
shared storage replicating to a third node at a remote location.
DISCLAIMER: I am a SteelEye Engineer with years of experience implementing
HA and DR for WIndows solutions including Exchange and SQL server.
"GNocent" <GNocent@.discussions.microsoft.com> wrote in message
news:6B80A88E-B34B-4E68-A416-F2659358D425@.microsoft.com...
> Hi,
> What you need seems to be a "geo cluster" : you have 2 rooms, each one has
1
> server + 1 disk array (at least !).
> Geo cluster are usually constructor dependant, as microsoft cluster
services
> are only able to handle shared disk arrays (single point of failure !).
For
> that reason, some disk array vendors provide peace of software that drive
> hardware synchronous replication between the 2 disk arrays and make MSCS
> "think" that it is only volumes on a shared disk array.
> I use "SRDF/CE" ("Geospan") from EMC (we have 2 sites with EMC arrays on
> each site) which works fine : it monitors volume replication (srdf) and
makes
> the interaction to enable volumes on the right site when doing failovers
or
> failbacks.
> One important thing : it is only available for 32 bits windows at the
moment
> (we are waiting since Q2 2005 for the release of IA64 version *I FEEL
KINDA
> PISSED OFF*).
> Note that Geo cluster usually make hardware replication in 1 direction :
> when you failover, volumes replication is stopped, so a failback takes
longer
> time : volumes on drive arrays will have to be re-synchronized
(automatically
> on most solutions, but during this period, the resources that are moving
are
> offline !).
> Another solution is to acquire a third party cluster aware volume manager
> (like Veritas provides) which allows you to have the same type of
abstraction
> from the MSCS point of view, but uses different technology : writes via
the
> SAN to the volumes of both side simultaneously. It is faster for I/O
writes,
> as synchronous hardware solutions (like SRDF) waits for the acknowledge of
> the write on the replicated volume to acknowledge a write, which creates a
> small delay for each write (>=1 ms, depending of the distance and the
> activity of the arrays).
> The last solution i know, which is cheaper, is a "Geocluster" from NSI,
> which provides mirrored disks for MSCS, and manages the moves like the 2
> previous solutions, but uses the network for the replication ("IP
based").
> The advantage is that it allows you to make a solution without SAN or
> exepensive disk arrays. The "problem" is the performance if you have very
I/O
> consuming environments.
> All these solutions have a cost, and are not totally safe (MSCS quorum
> remains a single point of failure, you can have "split brain" situations,
and
> a clustered SQLServer instance can't easily run outside MSCS), and doesn't
> handle data corruption or human errors.
> So it is important to think, if you want a complete DRP, to maintain a
> "standby" instance via Log shipping, or Mirroring (2005 only), or self
made[vbcol=seagreen]
> scripts. Ideally on a 3rd site ("ultimate drp") !
> (Sorry for my bad English)
> Guillaume.
> ====================================
> "maxzsim via droptable.com" wrote:
physical[vbcol=seagreen]
well as[vbcol=seagreen]
offering[vbcol=seagreen]
my SQL[vbcol=seagreen]
switch[vbcol=seagreen]