Re: Active/Active clustering?

Your logic is very sound and your decision wise.
--
Ed Crowley
MVP - Exchange
"Protecting the world from PSTs and brick backups!"

"Phil McNeill" <philmcneill@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:ujOggqyFIHA.5328@xxxxxxxxxxxxxxxxxxxxxxx
Thanks,

We don't have a dedicated Exchange admin, so we're trying to keep the
solution as simple as possible and not have the thing that is supposed to
improve our uptime (clustering) end up being detrimental to it.
Complexity in your solution is ok if you have that dedicated person who
really understands it well, but if you're a jack of all trades it can be
the kiss of death. It's looking like Active/Active just adds wrinkles
that will make it's cons outweigh any pros (at least for us).

I think we're going to start with a front-end server and a single back-end
DB server, and look at options for DB redundancy down the line. Thanks
much for your reply.

Phil

"Bharat Suneja [MVP]" <bharat@xxxxxxxxxx> wrote in message
news:O4qgiLqFIHA.1212@xxxxxxxxxxxxxxxxxxxxxxx
You have to understand two things here:
- How clusters work in terms of ownership of resources, including the
quorum. Windows Server 2003 supports 1) (Traditional) Shared quorum 2)
Majority Node Set (MNS) and 3) MNS with File Share Witness (with hotfix
KB 921181 or SP2).
- Active/Active is only supported on 2 nodes, making quorum option #2
(MNS) irrelevant. If you add a 3rd node, it's not A/A any more.
- Not quite sure if option 3 has been tested with Exchange 2003 or if it
even works - conceptually, it should.
- Regardless, if you use a shared quorum or a FSW, it resides in one data
center.
- If and when the link between the 2 snaps, NODE1 in BLDG1 will own the
quorum. The shared storage in BLDG2 used by EVS2 on NODE2 will not be
accessible to NODE1 (believe that'll be over the fibre link as well).
EVS2 will not fail over to NODE1.
- NODE2 in BLDG2 will not be able to stake claim over the resources
(EVS2 - which it hosts) because it doesn't have quorum.

Other than that, Active/Active isn't recommended even by Microsoft - it
suffers from scalability and virtual memory fragmentation problems.

Would recommend looking at Exchange Server 2007 - the built-in
replication functionality will help you achieve higher availability, with
or without clustering.

Alternatively, look at 3rd party solution that use synchronous &
asynchronous replication to provide such functionality - with or without
clustering.
--
Bharat Suneja
MVP - Exchange
www.zenprise.com
NEW blog location:
exchangepedia.com/blog
----------------------------------------------


"Phil McNeill" <philmcneill@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:%23Ar74flFIHA.5980@xxxxxxxxxxxxxxxxxxxxxxx
So, I am reading some bad things about this kind of setup. Our network
configuration is such that we have two buildings with a single fibre
link between them. We have domain controllers at either end to service
login requests for the local users, and I thought it would make sense in
a two node cluster to have one in each building, and the database split
so during normal operations each server services clients in the same
building. In my simplistic view of things, this seems to accomplish
both high-availability and disaster recovery in the event that one
server, or one whole datacenter goes away.

Since there is only one network link between the buildings, both public
network and heartbeat travel across the same physical link. So, in the
event of a failure of that link, what happens to my mail? I am assuming
in an Active/Passive setup, the active server continues as normal, with
only the redundancy lost. Clients sitting in the passive node's
building lose access to mail (since it's all running in the node at the
other end of a broken piece of fibre). Please correct me if I'm wrong
there.

In an Active/Active setup, would all clients retain access to their
local database? This is the big advantage to going Active/Active that I
can see.

Should I give up on the idea of geoclustering altogether and just keep
the two boxes beside each other in the same datacenter and come up with
a different DR solution (standby server at remote location?)

Opinions/tips appreciated.

Thanks,

Phil






.