|
|
|
date: Fri, 29 Feb 2008 09:31:01 -0800,
group: microsoft.public.exchange.clustering
back
Re: Exchange 07 - CCR Pressure
"Bharat Suneja [MVP]" wrote:
> - You you already have significant investments in storage and/or partner
> solutions, going with SCC would certainly make more sense, imo.
> - In fact, SCC makes shared storage clusters even better compared to
> Exchange Server 2003, imo again.
> - I am assuming you tested CCR and MNS quorums (or MNS quorums + FSW, the
> recommended confriguration) adequately in a lab environment before
> deploying. Did the results reveal any particular concerns?
> - What are the specific issues or flaws with MNS (or MNS + FSW)?
> - Haven't seen any "cluster kill" scenarios (post-RTM) so far - would you
> mind sharing some details?
I don't mind discussing this at all - thats the point of the newsgroup! Yes,
CCR/MNS+FSW was fully tested in a lab before both deployments.
The concern is now the reliability concerns of the FSW server. In both
deployments where CCS/MNS+FSW was deployed we experience a problem with the
"partition in time" and the ability of Exchange to recover from this logging
failure. Essentially it cannot recover from this failure and renders the
cluster unusable because both nodes believe they are the primary for the set.
Finding this problem is easiest by discussing the fix -
http://support.microsoft.com/kb/258078
net start clussvc /forcequorum is specifically designed to fix the problem.
and the requirements of this is to stop the cluster service on ALL nodes.
What does this mean for the "partition in time"? It means that if I had
pending information in that partition and I have to /forcequorum, that data
is reset and essentially lost. In theory this would be like losing the most
recent log file in Exchange 2003 and powering off the server. The changes
haven't been commited.
Also - the failover time in CCR is not nearly as fast as SCC. The "time to
fail" is sometimes 3,5,7 minutes before things realize it's broke. Trying to
acheive five 9s of availability with CCR seems impossible since even one
small outage will be 5mins+ of downtime.
It doesn't seem like CCR is really where it should be right now.
Replication/write commits of data need to happen between both servers more
quickly and potentially allow the actual Exchange data to operate in a
"Read-only" database mode, much like SQL can accomplish.
I would love to see this technology improve, but it seems too hokey in my
opinion when I can acheive better results from much less complex solutions.
iSCSI+Snapshots for example.
date: Fri, 29 Feb 2008 11:23:01 -0800
author: Josh
Re: Exchange 07 - CCR Pressure
"Josh" wrote in message
news:B208C3DF-FD5C-4DA5-A909-A7625C92B6EE@microsoft.com...
>> > MNS clusters have a flaw and I digress that Microsoft continue to
>> > recommend
>> > CCR as a high-availability solution when in fact it cannot meet the
>> > SLA's
>> > that SCC can.
>> >
>> > If I already have a significant investment in storage technologies, why
>> > would I get recommendations not to use it? I trust my storage more now
>> > than
>> > ever after using CCR.
>>
>> You can combine the two. Use CCR and use the SAN for the disk space. No
>> biggie.
>>
>> This blog might help a little, too:
>> http://msmvps.com/blogs/clusterhelp/archive/2007/10/31/which-exchange-server-2007-server-cluster-type-should-i-use-ccr-or-scc.aspx
>>
>
> I'm not sure saying combination of the two actually works. CCR relies on a
> MNS Quorum type cluster while SCC uses a physical disk Quorum. Two
> different
> ways of building a cluster and the fact the CCR/MNS Cluster requires a
> witness.
CCR will run on a standard cluster. However, let's say that you want to
stick with an MNS based quorum, that is no problem. You can still put your
physical disk resources on the SAN, they do not have to be directly attached
storage (DAS).
>
> Doing CCR on a SAN seems to be an inefficient use of SAN technology. A
> typical SAN itself provies snapshots/clones (usually as an additional
> license). So my reasoning is, why double my space requirements and
> "potentially" affect performance if I have to use the same spindles.
If you read the post, then you would have the answer. <G> However, to make
your life easier, the answer is because a snapshot clone is based on block
by block copying processes which would make a copy of any corruption as
well, whereas a CCR copy is created by using transactions, not block by
block copying, thus any corruption will not likely appear in the passive
copy. It is an extra layer of mitigation against database issues that you
can't get with SCC and/or snapshots.
> I could do CCR in a case that I don't want to use storage technologies
> available - then we merge into the political discussion on Microsoft
> replication technology vs. EMC/IBM/Hitachi/HP/VMware provided solutions.
>
> Could you clarify "combination of the two"?
Again, to be clearer, CCR with the actual disks being on the SAN.
--
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp classes are:
Mar 10- 13 in Denver
May 12-15 in New York
date: Fri, 29 Feb 2008 12:59:01 -0700
author: Russ Kaufmann [MVP]
Re: Exchange 07 - CCR Pressure
"Russ Kaufmann [MVP]" wrote:
> "Josh" wrote in message
> news:A38E58AC-0D0B-45D0-9FBB-87B6AA963644@microsoft.com...
> >
> >> >> You can combine the two. Use CCR and use the SAN for the disk space.
> >> >> No
> >> >> biggie.
> >> >>
> >> >> This blog might help a little, too:
> >> >> http://msmvps.com/blogs/clusterhelp/archive/2007/10/31/which-exchange-server-2007-server-cluster-type-should-i-use-ccr-or-scc.aspx
> >> >>
> >> >
> >> > I'm not sure saying combination of the two actually works. CCR relies
> >> > on a
> >> > MNS Quorum type cluster while SCC uses a physical disk Quorum. Two
> >> > different
> >> > ways of building a cluster and the fact the CCR/MNS Cluster requires a
> >> > witness.
> >>
> >> CCR will run on a standard cluster. However, let's say that you want to
> >> stick with an MNS based quorum, that is no problem. You can still put
> >> your
> >> physical disk resources on the SAN, they do not have to be directly
> >> attached
> >> storage (DAS).
> >>
> >
> > I've got conflicting information to that statement. CCR + SCC is not a
> > valid
> > configuration considering the MNS requirements of CCR. Per other research,
> > I
> > see other MSFT engineers agree. In particlar, this quote -
> >
> > "It is not possible to do that. You cannot have SCC and CCR in the same
> > cluster.
>
> You are mis-reading what I have written. At no time did I say you could have
> both. I said that you can use CCR with a SAN. I hope that is clearer.
>
Thanks for the clarification - the wording in the first few sentences did
make it seem like we were talking being able to do both. "CCR will run on a
standard cluster. However, let's say that you want to stick with an MNS based
quorum, that is no problem."
I have no other option than an CCR/MNS based quorum so I really didn't know
where you were coming from other than an wrong assumption you could have
both. I think that's a reasonable deduction from our conversation, not sure
about a mis-reading.
Anyways - The statement about the block by block copying process bringing
over corruption is true, but why would I copy known bad data? At some point
we do have to introduce a level of human interaction here, if my exchange
data has gone bad, I'm not going to keep making snapshots/clones of bad data.
Afterall - I do like having a job!
As I figure most of the conversation of CCR/SCC will digress into
money/politics/SLAs/expections. Will both work? Sure. Are they exactly alike,
NO. Each needs to be evaluated against the requirements of the company.
:-)
--Josh
date: Fri, 29 Feb 2008 14:23:02 -0800
author: Josh
Re: Exchange 07 - CCR Pressure
"Josh" wrote in message
news:4C234601-DD48-464B-B9A1-81ED41DC7062@microsoft.com...
>> You are mis-reading what I have written. At no time did I say you could
>> have
>> both. I said that you can use CCR with a SAN. I hope that is clearer.
>>
>
> Thanks for the clarification - the wording in the first few sentences did
> make it seem like we were talking being able to do both. "CCR will run on
> a
> standard cluster. However, let's say that you want to stick with an MNS
> based
> quorum, that is no problem."
>
> I have no other option than an CCR/MNS based quorum so I really didn't
> know
> where you were coming from other than an wrong assumption you could have
> both. I think that's a reasonable deduction from our conversation, not
> sure
> about a mis-reading.
I better clarify this more. In the RTM version of Exchange Server 2007 you
are not required to use MNS because the application doesn't know what kind
of quorum is being used. However, while this is true most of the time, SP1
for Exchange Server 2007 will block installation unless MNS is being used.
So, your point is very valid regarding the need for MNS.
> Anyways - The statement about the block by block copying process bringing
> over corruption is true, but why would I copy known bad data?
The issue is that you don't know, necessarily, that you have corruption
until you have it. Wow, did that make no sense or what? <G>
What I am really trying to say is that you usually don't find out that you
have corruption until you try to backup. So, if you find it, what do you do?
You restore from a previous backup and apply the logs? OK, if you do that,
what is your down time? Now, if you have CCR, you won't have the
requirement to restore the database from a previous version, you have a
copy.
> As I figure most of the conversation of CCR/SCC will digress into
> money/politics/SLAs/expections. Will both work? Sure. Are they exactly
> alike,
> NO. Each needs to be evaluated against the requirements of the company.
Absolutely. However, the main reason an organization implements high
availability is to mitigate against risks that can be controlled or
eliminated through the technology. CCR provides higher levels of mitigation
against database failure issues with the copy of the database, but, as has
been pointed out, there are costs associated with it.
--
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp classes are:
Mar 10- 13 in Denver
May 12-15 in New York
date: Fri, 29 Feb 2008 16:23:10 -0700
author: Russ Kaufmann [MVP]
|
|
