Very Computer

Recently, our 14 GB IS was corrupted, resulting in two substantial periods
of downtime (over one day each time).  Restoring that size of a database
took about 5 hours, and repairing the database took about 7 hours.  So ....
we are very quickly investigating what options are available to improve
reliability.

If you had to plan for an Exchange environment for, say, 650 users .... and
had decided that a 50 MB limit was sufficient ..... what sort of environment
would you setup?

1.  A clustered solution ..... meaning two effectively identical servers
housing all users.
2.  Two servers .... each housing 325 users.
3.  Other?

Clustering sounds like the better solution to me to minimize downtime, and
to avoid the increased administration of maintaining users on two separate
servers.  However, I have had no experience with clustering .... so I assume
the big disadvantage would be cost?

However, it doesn't sound like Microsoft Cluster Server would "save us" in
the event of database corruption .... from what I understand, the two
servers would share the same disk.  Would something like Octopus save us in
the event of a database corruption?

Just looking for a few opinions here .... and I realize a lot depends on how
much we're willing to spend.  If you had to make a recommendation to your
boss on how it should be setup .... and assume he/she said that cost was not
as much an issue as reliability ....  what sort of setup would you
recommend?

Thanks in advance.

Randy Power
Sr. Systems Analyst, CNE, MCP

{From what I read here)

You should not repair database. You restore it and let it recover. See white
papers at
http://support.microsoft.com/support/exchange/content/whitepapers/whi...

http://support.microsoft.com/support/exchange/content/howtos/howtos.a...

Quote:

> we are very quickly investigating what options are available to improve
> reliability.

> If you had to plan for an Exchange environment for, say, 650 users .... and
> had decided that a 50 MB limit was sufficient ..... what sort of environment
> would you setup?

> 1.  A clustered solution ..... meaning two effectively identical servers
> housing all users.

This is pain.

Quote:

> 2.  Two servers .... each housing 325 users.

Can be done and considering the limit I would say this is way to go.

Quote:

> 3.  Other?

This can be preconfigured server with just databases missing.

--
Questions will not be answered via e-mail.

Hi Kirill,

Thanks for your input.

Quote:>>> > You should not repair database. You restore it and let it recover.

Actually .... we did restore .... and, in consultation with Microsoft Tech
Support, ran eseutil /g to determine if the restored database was corrupted.
It was ... so Microsoft then instructed us to repair using eseutil /p,
followed by isinteg -fix.   This did seem to correct our problems.  But I
know what you mean .... a repair is not something that should be done unless
it's a last resort.

Quote:>>>> A clustered solution .....   This is pain.

How so?    Any details you can provide would be appreciated  (e.g.  are you
referring to a specific clustering solution, or clustering in general?)

Thanks.

.... Randy Power

                                        [ snip ]

Quote:>If you had to plan for an Exchange environment for, say, 650 users .... and
>had decided that a 50 MB limit was sufficient ..... what sort of environment
>would you setup?

>1.  A clustered solution ..... meaning two effectively identical servers
>housing all users.

This will provide fail-over in case of a problem with a service or a
machine. It will not provide any protection against a damaged store
since there's only one store shared between the two machines in the
cluster. In the situation you describe it wouldn't have helped at all.
In fact, it probably would have added to the restoration time by
taking longer to figure out what caused to service to fail over!

Quote:>2.  Two servers .... each housing 325 users.

Better.

Quote:>3.  Other?

Marthon Technologies has a "fail out" solution. Two IO Processors and
two Compute Processors.

Quote:>Clustering sounds like the better solution to me to minimize downtime, and
>to avoid the increased administration of maintaining users on two separate
>servers.  However, I have had no experience with clustering .... so I assume
>the big disadvantage would be cost?

No, not really. Cost is fairly minor. you'll spend more time in
administration of the cluster than the administation of two Exchange
servers.

Quote:>However, it doesn't sound like Microsoft Cluster Server would "save us" in
>the event of database corruption .... from what I understand, the two
>servers would share the same disk.  Would something like Octopus save us in
>the event of a database corruption?

Yes, but the recovery time is far from instantaneous!

Quote:>Just looking for a few opinions here .... and I realize a lot depends on how
>much we're willing to spend.  If you had to make a recommendation to your
>boss on how it should be setup .... and assume he/she said that cost was not
>as much an issue as reliability ....  what sort of setup would you
>recommend?

If reliability is paramount and cost is no consideration then take a
look at www.marathontechnologies.com for a five-nines solution. The
cost is about $40K plus the cost of four servers. You'll need two NT
licenses and two Exchange server licenses, too.

But before doing that, I'd suggest investing in reliable hardware. You
didn't state what you're running on now, but corrupted databases are
usually caused by bad hardware or device drivers.

------------------
Rich Matheisen
MCSE, Exchange MVP

Just search messages of last week for
cluster trouble
and you will get explanation.

Quote:

> Thanks.

> .... Randy Power

--
Questions will not be answered via e-mail.

Apart from the Clustering / Multi server solutions, another way to reduce
the chances of database failures is to closely monitor the Event logs on the
servers. If a disc is beginning to fail or some hardware/software is causing
corruption of the Exchange databases, this will often show up in analysis of
the NT application log before it becomes a major problem. Especially watch
for errors following the Information Store maintenance period overnight.

In general though, its a good idea to implement good software and hardware
monitoring to catch problems before they become too critical.

Neil

On Wed, 30 Jun 1999 15:06:23 -0230, "Randy Power"
I would not recommend the Octopus product for Exchange use.  We ran
into a problem in our testing & couldn't get a straight answer from
FullTime/Legato/Whoever They Are This Week.  And that's WITH a premium
support agreement.

So, we dropped our plans to use it.

_______________________________________________________
John Tilden, MCSE
Computer Specialist
Social Security Administration, Office of Systems Requirements