One or multiple storage groups

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Mick - 27 Jul 2005 00:47 GMT

We have made the decision to move to Exchange2003, mainly for remote device
support and while I'm waiting for my new server to arrive I'm researching
how best to layout the storage groups.

Currently I have about 45GB of mailbox (all in one store), 5GB of pubfld,
but I want allow for this to tripple on the 2003 server. The server I've
ordered will have 3 logical disks, OS, Logs, and DB (all RAID-1 via Direct
Attached Storage), 2 x 3.2 Xeon, 4GB RAM. All disks are 73GB 15K, 2 for OS,
2 for Logs, 10 for DB.

I'd like to allow for the mailbox storage to tripple (eg 150GB), but don't
want a store more than 50GB. I'm looking at having 3-4 mailbox stores. Most
likely scenario is that I create a store for each of our 4 departments (1
will be smaller). My decision is whether to create 1 storage group with 4
stores, or 4 storage groups each with 1 store. Restores would currently be
via an LTO tape drive connected to another server.

Some of the factors I have read (but not verified)
o Each Storage group takes up extra memory, some say don't create extra
storage groups until you have created 5 stores
o Each Storage group uses a common set of log files, so restores could be
longer if only one storage group
o Keep users in same department together to benefit from Single Instance
Storage (eg only one copy of the message if in the same store).
o Mailbox limits are per Store.

I don't like the idea of each of these logs/db to be on their own drive
letter as then you end up with slack space on each drive letter. I'd rather
have a drive letter for the 4 logs areas (if using multiple storage groups),
and a drive letter for the 4 db areas.

So I'm debating between

Option 1 (one Storage Group) (good = possibly reduced memory, bad = only one
set of logs, restore time ?)
Storage Group 1 (logs = E:\MDBLogs\Storage Group 1)
Dept 1 (data = F:\MDBData\Storage Group 1\priv1)
Dept 2 (data = F:\MDBData\Storage Group 1\priv2)
Dept 3 (data = F:\MDBData\Storage Group 1\priv3)
Dept 4 (data = F:\MDBData\Storage Group 1\priv4)
PubFld (data = F:\MDBData\Storage Group 1\pub1)

or

Option 2 (multiple Storage Groups) (good = multiple logs, bad = increased
memory usage ?)
Storage Group 1 (logs = E:\MDBLogs\Storage Group 1)
Dept 1 (data = F:\MDBData\Storage Group 1\priv1)
PubFld (data = F:\MDBData\Storage Group 1\pub)
Storage Group 2 (logs = E:\MDBLogs\Storage Group 2)
Dept 2 (data = F:\MDBData\Storage Group 2\priv1)
Storage Group 3 (logs = E:\MDBLogs\Storage Group 3)
Dept 3 (data = F:\MDBData\Storage Group 3\priv1)
Storage Group 4 (logs = E:\MDBLogs\Storage Group 4)
Dept 4 (data = F:\MDBData\Storage Group 4\priv1)

Option 3
Split users on something other than department
mailbox size = give different storage limits
alphabetically = better distribution between stores

Thanks in advance

Reply to this Message

Al Mulnick - 27 Jul 2005 13:38 GMT

Option 1 would be my pick, but not for the reasons you mention exactly.
Log files have an I/O signature that is almost completely sequential write.
Other services have a more random r/w signature. While others tend to be
more read heavy while also being random with some write.

If you mix and match I/O types, you thrash the disks. If you thrash the
disks, you may run into performance problems that only hardware can fix.

As a general rule, because the stores usually exhibit random r/w
characteristics, it's generally efficient to place multiple stores on fast
RAID 10 drives. RAID 5 often yields good enough performance for the same
reason. A typical ratio would be 3r/1w for stores. Across several db's (in
your case 6 files right?) this would likely yield the efficiency you're
after. Because the log files are sequential however, traditional DAS
doesn't often yield the performance you may want if you mix log files on the
same physical spindles. Better to continue the long standing tradition of
one disk (mirrored or otherwise striped because they're very important), one
log file set.

There's plenty of controversy about whether to use one SG and multiple
stores or multiple SG's and one store each. The extra memory is often
countered by other factors, so I usually discard it early in the process as
a concern.

My $0.04 anyway.

P.S. get over the left over space on a disk. There are times you'll use it
and sizing Exchange by space requirements should be the last step prior to
testing/deployment. Not the first :)

> We have made the decision to move to Exchange2003, mainly for remote
> device
[quoted text clipped - 64 lines]
>
> Thanks in advance

Reply to this Message