|
|
|
date: Mon, 7 Apr 2008 09:15:00 -0700,
group: microsoft.public.exchange.clustering
back
Re: CCR failover control
"RJ" wrote in message
news:2CC7BBBD-EFE2-4204-ACF1-C6504151ABE1@microsoft.com...
>I have tried the lossless setting and it prevent automatic failover.
> However, once you power up the former active node, the cluster immediately
> fails over to the passive node. Is there some way to prevent this?
OK. To summarize, you want a high availability platform that doesn't provide
high availability. <G>
If you really are looking for something that provides a copy of the database
live on the network somewhere (local segment or remote segment), that also
requires manual intervention, then SCR is your best solution.
--
Russ Kaufmann, MCSE, MCT, MCITP, MCTS, and other stuff
Microsoft
Premier Field Engineer - Exchange
date: Thu, 10 Apr 2008 10:23:13 -0700
author: Russ Kaufmann [MSFT]
Re: CCR failover control
Russ,
That is not the direction I was headed. I believe that you can still have
high availability with controllability as well. SCR does not provide a
timely manual solution since it would require time to failover and failback.
What we are really looking for is more finite control so that we can make the
decision to failover if we should wish to.
"Russ Kaufmann [MSFT]" wrote:
> "RJ" wrote in message
> news:2CC7BBBD-EFE2-4204-ACF1-C6504151ABE1@microsoft.com...
> >I have tried the lossless setting and it prevent automatic failover.
> > However, once you power up the former active node, the cluster immediately
> > fails over to the passive node. Is there some way to prevent this?
>
> OK. To summarize, you want a high availability platform that doesn't provide
> high availability. <G>
>
> If you really are looking for something that provides a copy of the database
> live on the network somewhere (local segment or remote segment), that also
> requires manual intervention, then SCR is your best solution.
>
>
> --
> Russ Kaufmann, MCSE, MCT, MCITP, MCTS, and other stuff
> Microsoft
> Premier Field Engineer - Exchange
>
>
date: Fri, 11 Apr 2008 12:03:00 -0700
author: RJ
Re: CCR failover control
"RJ" wrote in message
news:4153D187-BE70-479F-8C5B-A45FDCD43C0E@microsoft.com...
> Russ,
>
> That is not the direction I was headed. I believe that you can still have
> high availability with controllability as well. SCR does not provide a
> timely manual solution since it would require time to failover and
> failback.
Yet, that is what you were asking for with CCR, wasn't it? Maybe I missed
something, but you said you wanted to control the failover and manage when
it goes to the other location. You don't want an automated process.
> What we are really looking for is more finite control so that we can make
> the
> decision to failover if we should wish to.
Exactly! That is what SCR can do for you. You can also write scripts that
make the process easier to manage.
--
Russ Kaufmann, MCSE, MCT, MCITP, MCTS, and other stuff
Microsoft
Premier Field Engineer - Exchange
date: Fri, 11 Apr 2008 13:21:21 -0700
author: Russ Kaufmann [MSFT]
Re: CCR failover control
SCR is not easy to fail back from is it? I thought SCR was a disaster
recovery tool.
Here is the line of thinking that we are using. If a momentary failure
occurs on Node A and it comes back online or can be brought back online in a
few minutes, then I do not want to failover to Node B. However, if it looks
like an extended outage (10 or more minutes) then I can simply failover to
Node B and carry on.
"Russ Kaufmann [MSFT]" wrote:
> "RJ" wrote in message
> news:4153D187-BE70-479F-8C5B-A45FDCD43C0E@microsoft.com...
> > Russ,
> >
> > That is not the direction I was headed. I believe that you can still have
> > high availability with controllability as well. SCR does not provide a
> > timely manual solution since it would require time to failover and
> > failback.
>
> Yet, that is what you were asking for with CCR, wasn't it? Maybe I missed
> something, but you said you wanted to control the failover and manage when
> it goes to the other location. You don't want an automated process.
>
> > What we are really looking for is more finite control so that we can make
> > the
> > decision to failover if we should wish to.
>
> Exactly! That is what SCR can do for you. You can also write scripts that
> make the process easier to manage.
>
>
> --
> Russ Kaufmann, MCSE, MCT, MCITP, MCTS, and other stuff
> Microsoft
> Premier Field Engineer - Exchange
>
date: Fri, 11 Apr 2008 13:33:00 -0700
author: RJ
Re: CCR failover control
"RJ" wrote in message
news:7CBC26CC-1865-46D1-B026-F5022D608D3B@microsoft.com...
> SCR is not easy to fail back from is it? I thought SCR was a disaster
> recovery tool.
SCR is both an HA and a DR technology. I, personally, consider it a DR
solution, but it is an HA solution, too.
> Here is the line of thinking that we are using. If a momentary failure
> occurs on Node A and it comes back online or can be brought back online in
> a
> few minutes, then I do not want to failover to Node B. However, if it
> looks
> like an extended outage (10 or more minutes) then I can simply failover to
> Node B and carry on.
OK, let me take a different view for the sake of argument.
If I am a manager, my concern is that email is available. If I have been
properly informed by my admins, I will also know that if I have a cluster,
it will automatically fail over to another node and keep email available.
Now, if my nodes are spread between different locations (geographically
dispersed, also called multisite clustering), then if there is a failure,
the failover would go to the other physical location and then all of my
transactions would have to go over the WAN.
So far so good?
OK, so, my questions are
1. Do you want automatic failover? That is a yes or no. If no, then CCR is
not going to be your answer. The answer might depend on the distance
scenario or other factors. If yes, then you should implement CCR, but I
don't recommend using it as a stretched/multisite cluster. See this link for
more info:
http://msmvps.com/blogs/clusterhelp/archive/2008/02/19/ccr-and-multi-site-environments.aspx
2. Do desire a situation where you need to actually make a decision and
declare a disaster to recover to another server? If this is yes, then SCR is
a good answer. SCR will require making a decision that it is the best choice
to move to the alternate solution. It will, generally, be pretty quick. You
can script the process to take the necessary steps. The SCR target can be in
the local subnet, or it can be in a remote subnet.
To answer your question, "SCR is not easy to fail back from is it?": It is
as easy to move back as it is to move away.
Personally, if I were you, I would use CCR, and, since I would like some
control of it, I would configure it for lossless.
What I am having trouble understanding, is why are you against an automated
failover process?
--
Russ Kaufmann, MCSE, MCT, MCITP, MCTS, and other stuff
Microsoft
Premier Field Engineer - Exchange
date: Fri, 11 Apr 2008 13:58:00 -0700
author: Russ Kaufmann [MSFT]
Re: CCR failover control
On Fri, 11 Apr 2008 13:33:00 -0700, RJ
wrote:
>SCR is not easy to fail back from is it? I thought SCR was a disaster
>recovery tool.
>
>Here is the line of thinking that we are using. If a momentary failure
>occurs on Node A and it comes back online or can be brought back online in a
>few minutes, then I do not want to failover to Node B. However, if it looks
>like an extended outage (10 or more minutes) then I can simply failover to
>Node B and carry on.
>
Why did you setup up CCR then?
The failover time with SP1 is quick and quite painless for Outlook
cached clients.
If it fails over, the user experience should be the same for both
nodes, so I dont see the requirement to try to stall the fail-over.
You can certainly fail back once the orig node is back online.
Otherwise, you spent a lot of money for nothing.
>
>
>"Russ Kaufmann [MSFT]" wrote:
>
>> "RJ" wrote in message
>> news:4153D187-BE70-479F-8C5B-A45FDCD43C0E@microsoft.com...
>> > Russ,
>> >
>> > That is not the direction I was headed. I believe that you can still have
>> > high availability with controllability as well. SCR does not provide a
>> > timely manual solution since it would require time to failover and
>> > failback.
>>
>> Yet, that is what you were asking for with CCR, wasn't it? Maybe I missed
>> something, but you said you wanted to control the failover and manage when
>> it goes to the other location. You don't want an automated process.
>>
>> > What we are really looking for is more finite control so that we can make
>> > the
>> > decision to failover if we should wish to.
>>
>> Exactly! That is what SCR can do for you. You can also write scripts that
>> make the process easier to manage.
>>
>>
>> --
>> Russ Kaufmann, MCSE, MCT, MCITP, MCTS, and other stuff
>> Microsoft
>> Premier Field Engineer - Exchange
>>
date: Sat, 12 Apr 2008 15:56:59 -0400
author: Andy David {MVP}
Re: CCR failover control
The reason we are trying to avoid instantaneous failover is that we plan to
use the Passive Node to perform backups. Once we failover to the Passive
Node the users may experience degraded performance, which we would like to
avoid if it is only going to be a short outage. This scenario does not
really seem all that illogical to me.
Our Active and Passive nodes would be located in separate data centers that
are connected by a dark fiber link. Then we would SCR the data to a DR site.
It seems that Microsoft did not have this idea in mind.
"Andy David {MVP}" wrote:
> On Fri, 11 Apr 2008 13:33:00 -0700, RJ
> wrote:
>
> >SCR is not easy to fail back from is it? I thought SCR was a disaster
> >recovery tool.
> >
> >Here is the line of thinking that we are using. If a momentary failure
> >occurs on Node A and it comes back online or can be brought back online in a
> >few minutes, then I do not want to failover to Node B. However, if it looks
> >like an extended outage (10 or more minutes) then I can simply failover to
> >Node B and carry on.
> >
>
> Why did you setup up CCR then?
> The failover time with SP1 is quick and quite painless for Outlook
> cached clients.
>
> If it fails over, the user experience should be the same for both
> nodes, so I dont see the requirement to try to stall the fail-over.
> You can certainly fail back once the orig node is back online.
> Otherwise, you spent a lot of money for nothing.
>
>
> >
> >
> >"Russ Kaufmann [MSFT]" wrote:
> >
> >> "RJ" wrote in message
> >> news:4153D187-BE70-479F-8C5B-A45FDCD43C0E@microsoft.com...
> >> > Russ,
> >> >
> >> > That is not the direction I was headed. I believe that you can still have
> >> > high availability with controllability as well. SCR does not provide a
> >> > timely manual solution since it would require time to failover and
> >> > failback.
> >>
> >> Yet, that is what you were asking for with CCR, wasn't it? Maybe I missed
> >> something, but you said you wanted to control the failover and manage when
> >> it goes to the other location. You don't want an automated process.
> >>
> >> > What we are really looking for is more finite control so that we can make
> >> > the
> >> > decision to failover if we should wish to.
> >>
> >> Exactly! That is what SCR can do for you. You can also write scripts that
> >> make the process easier to manage.
> >>
> >>
> >> --
> >> Russ Kaufmann, MCSE, MCT, MCITP, MCTS, and other stuff
> >> Microsoft
> >> Premier Field Engineer - Exchange
> >>
>
date: Mon, 14 Apr 2008 12:15:01 -0700
author: RJ
|
|
