The idea of splitting the users is to provide hardware failure tolerance of
some level. Clustering can do that as can two standalone servers with some
hardware redundancy in them (power supplies, memory etc). If you can
withstand more than 15 minutes of downtime on either server at a time
(basically, can you withstand how much time it may take to get you back up
and running if you get a hardware failure on one of the servers), then I say
keep it simple and go with two standalone servers. If you have to have the
higher availability and hardware is a concern, then the complexity and cost
may be worth clustering. It'll fail over much faster and you'll have them
available as long as the problem is with the machine hardware itself (mostly
;)
There are some pieces of Exchange that don't like to cluster, such as the
SRS last I checked. I haven't checked in some time however so feel free to
correct as needed.
What I'm trying badly to illustrate is that the decision to use two
machines, or to use one machine or to use a clustered pair of machines has
more to do with our service outage tolerance than any technical reason.
It's a tradeoff you have to make after weighing the different possibilities.
Whatever you do, keep it as simple as you can and you'll be much happier
down the road.
Al
> Hi Al
> First, thanks for responding. So if I was going to buy two backend
[quoted text clipped - 59 lines]
>>>
>>> Does this make sense?
maddessa - 20 Dec 2004 16:15 GMT
Al
You are the man. Thanks for your time.
> The idea of splitting the users is to provide hardware failure tolerance
> of some level. Clustering can do that as can two standalone servers with
[quoted text clipped - 87 lines]
>>>>
>>>> Does this make sense?