|
|
|
date: 9 May 2006 12:46:44 -0700,
group: microsoft.public.exchange.clustering
back
Re: Huge Project
When you design storage, the two parameters you are most concerned with are
space and performance. For a storage subsystem in a multicluster design,
you also have to worry about the impact of comingling. Comingling is where
IO against one LUN negatively impacts IO against other LUNs that share the
same physical spindles.
Exchange and SQL are both applications where performance is the primary
factor determining spindle count, not space. You've made a statement of
required space (presumably usable space, not raw space), but have given no
indication of the performance requirement or how you would prevent
comingling.
As an example, let's use a FAS980C. If we assume 10,000 users @ 1 IOP/user
and 100% concurrency, then the IOPS requirement for the databases is 10,000,
for the logs, 1,000, and for SMTP 500. To this you add the overhead for
backup/replication and other backend processes. Assuming a 100mb mailbox
size, a 5% change delta, and a 4 hour transfer window, that's about 1000
IOPS. The total performance requirement is 12500 IOPS.
To go from raw to usable space, first you have to "right size" the drives.
This is necessary because the capacity of drives is stated in multiples of
1000 not 1024. A right sized 144GB drive is 133GB. From this you subtract
the overhead for the virtualization layer, roughly 10%. Next you chose a
raid type and assemble the drives into raid groups, subtracting the capacity
of the spindles used for parity form the total. If you will be replicating
or backing up via snapshots there are two additional considerations; the
space reservation and the snap reserve. The space reservation is used to
ensure that you can still write to the disk while a snapshot is in place.
When a snapshot is in place, all the current blocks cannot be deallocated,
so each write consumes net new space. It can be 100% or a fraction thereof
depending on the specifics of your environment. The snap reservation is
space reserved to hold the change delta between snapshots times the number
of snapshots you will retain. Generally, if you require 12TB usable, then
the RAW capacity will be on the order of 26TB. At 144G 15K FC drives,
that's about 14 - 16 shelves.
Comingling is mitigated in a couple of different ways. First, you can use
physical isolation of spindles by creating seperate aggregates for logs and
databases. The raid group is the basic unit of storage. An aggregate is a
pool of storage that consists of one or more raid groups. From the
aggregate you carve flexvols, or chunks of storage that are stiped across
all spindles in the aggregate. A flexvol can contain one or more LUNs. The
second way to mitigate comingling is though a Control of Service feature of
the virtualization layer called Flexshare. With Flexshare, you weight the
command queue for each volume, giving it a percentage of available IO.
If you wanted to put Exchange and SQL on the same SAN, you would determine
the IO requiremnt for each, and build seperate aggregates capable of
supporting each application.
"Shaheen" wrote in message
news:1147434787.613560.124140@y43g2000cwc.googlegroups.com...
> Storage is a big concern,
> I was worried untill I found this wonderful piece of information on MS
> technet site.
> Best practice configuring the storage for BE's
> http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3HighAvGuide/c1804c14-c099-4207-b6b9-de5bda972b76.mspx?mfr=true
>
> But the question is,
> Do I really need separate SAN for SQL cluster?
> am thinking about 12 TB SAN would it be enough to handle both SQL and
> BE's?
>
date: Fri, 12 May 2006 10:04:56 -0700
author: John Fullbright [MVP]
|
|
