11-29-06 12:15 AM
Netapp does have a lot of capabilities, we especially like the
snapmanager for exchange. We have several dedicated FAS 980s for our
exchange environment. The FAS 270 is very small in terms of cache,
but very efficient in terms of write operations. The great thing is
you can move up a tier from the F270 to a larger head with little
downtime, simply the time it would take to move the data cables.
Netapp has also gotten alot better in terms of not having to take
downtime to add new fiber loops when you expand the storage array,
though for the F270 you only have one loop I believe. NetApp is a
NAS device with SAN capabilities, it's not a SAN per se, as it doesn't
have the typical N+1 availability. If you can have service times of
around 15 minutes every 3 to 6 months, I would look at NetApp. Also
remember that the more snapshots you have, the deeper you can go in
terms of recovering data. So you might have an hourly snapshot going
for 24 hours, a daily for several weeks. It's the age of the
snapshot which determines how much storage space it is going to use,
not the number, so the appliance has several advantages there.
Greg
Will Niccolls wrote:
> A vendor has proposed the Netapp 270 4TB Raw capacity for our Exchange +
> File Server data. Can someone comment on the suitability for our
> environment based on my info below?
>
> Our fileserver has about 200 GB of documents, mostly files < 100KB on it.
I
> don't have current perfmon data on it to add to the discussion. I can tel
l
> you that 10 months ago, that amount of data was about 120GB so our data
> growth over the past year has been fairly rapid.
>
> Having little experience with SAN we are impressed with the ease of
> administration, the SnapManager for Exchange, Single Mailbox Recovery
> features.
>
> Here's a message from the vendor re: Fiber vs. ISCSI interface.
>
> =========
> "For Exchange, perfmon shows about 14000 disk transfers/sec, which is less
> than a MB (a GigE link has a max capacity of 128MB/sec). Using a basic Exc
h
> formula (included below), even if we assume every IOP to be 8KB, you are
> doing about 2 MB/Sec. So I feel pretty comfortable with the idea of iSCSI,
> but again, if you want to go FCP we can do that.
> Formula: (Active User Count 113 / User Count 132 = 0.86 User Concurrency
>
> (Disk Transfers/sec 53/ User Count 132) * 0.86 User Concurrency = .35 IOPS
>
> .35 IOPS * 20% overhead for peak = .42 IOPS (rounded)"
>
> ==========
>
> Thanks,
>
> Will
[ Post a follow-up to this message ]
|