So to answer the previous question, and ask one: was disk the most expensive
component of the solution, Al?

  
I think if you're a small company (what's the definition of "small company"
these days?) that investing in your own email system is a tough decision
anyway you look at it.  If you require high availability, disk is likely the
least of your concerns if you can provision disk at pennies per MB for high
performance disk.  The other layers of the solution stack will cost you FAR
more than your disk subsystem and frankly, I don't see lowering the cost of
my low-cost resources a real factor to sway my decision.  As I mentioned
before, the difference in price is about 8K USD at unit one retail over the
web pricing; Casual glance. I'd be willing to bet even money that your
network, backup, training, active directory, software and people costs will
far outweigh that 8K difference.  In other words, disk is not my expensive
resource in most cases and if I get into a situation where disk is the
problem it cost me way more.  
(side story: somebody was telling me the other day about a line of business
that generates .25 of all revenue for the company and used that as the
reason we should listen to and cater to them as an IT org.  I asked the
obvious question: how much does it cost us for each of those quarters?
Moral: I'm not impressed by up front costs.  I've been doing this too long
and know that there are other factors to consider such as TCO).

Al: before jumping on the NAS bandwagon for Exchange and SQL and other db
technologies, let me ask you this: After this investment, is it worth it to
shave 8K off the overall price to get slower, commodity space-centric
positioned storage for your mission-critical database app?  

SCSI was recommended because it tends to be more mature and faster (15K RPM
drives etc) and more scalable than other technologies at the moment.  SATA
drives are primarily designed for space vs. speed while allowing for RAID
configurations.  NAS devices are the same: designed for provisioning large
quantities of space vs. high-performance IOPS.  That gap is closing, and
certainly in the low end implementations the gap is much narrower and more
academic than a high-end solution high-performance solutions would be.  It's
still there however.

I note in Al's post that he mentions Veritas clustering vs. MSCS clustering.
He's opted to go with options that Veritas could offer that Microsoft did
not in it's own offering such as on-the-fly disk expansion.  Bet it was
cheap. </sarcasm>

We all know that we can provision 6TB of "space" pretty easily in this day
and age.  Heck, I can provide that amount of space in DAS configurations if
I wanted. NAS just makes it easier "out of the box". SAN is required at the
moment if performance is an issue.   

As to the other question, if you're deploying an apathetic Exchange server
(why?) then you're going to be fine deploying logs and db's on the slower
NAS devices.  Sure, you'll get some performance hits here and there, but
it's a small price to pay for that 8K in your pocket, right (think TCO and
think what the loss in opportunity costs are if your system is unusable)?
Keep in mind that Exchange has roughly four types of I/O patterns going on
at the same time.  DB's = 70/30 random R/W, Logs= 2/98 sequential R/W
(backups and commits to DB cause the read I/O; otherwise it's sequential
write), queues = 1/7 R/W (write ratio increases with message size), and the
temp file I/O = 1:1 random for the most part. 
That's without other applications of course, which change the pattern in
unique ways.  That being the case, if you have low I/O requirements, i.e.
you have low user density you may be able to put the load on the NAS device
and receive the performance you intend just as you might put the entire
server on one 3 disk RAID five configuration in some implementations (I
don't like that, but I like more user dense servers as a rule).  Keep
physics in mind and understand that rotational latency, disk contention with
other apps, and other factors influence your performance since Exchange is
so disk dependent for performance.  As was previously mentioned, if you
decide to use iSCSI, you should also worry about network latency. General
rule: To prevent corruption in the database ensure reliable and timely disk
IOPS - two-phase commit databases don't like flaky, slow, or otherwise
unreliable IOPS.  

If your budget is so close that 8K (USD) is going to make or break you,
consider outsourcing the messaging subsystem and save the headache and
learning you'll no doubt have to go through and instead focus on your core
business.  Be sure to put in an availability clause with the ASP. And
whatever you do, define your requirements thoroughly prior to spending ANY
money or coming up with any solution.  It'll help to direct you to the
solution you want or possibly help you save enough that you can buy those
bamboo slivers you've been wanting.

My $0.02 anyway. I've already been informed I've lost my Dining Services MVP
status, so this might be my last post on this subject as I can't afford to
lose my wits. ;)
  
-Al
 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al Garrett
Sent: Thursday, July 29, 2004 2:28 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] OT: NAS and WSS

I tried to read through most of the thread before answering.

IRT Deji's comments regarding SAN-based, clustered Exchange:
We run a 6Tb SAN, fiber-attached to several UNIX and Win2K Clusters (Veritas
Clustering) The Exchange drives (databases) sit on the SAN and are presented
to the three Exchange servers, appearing to them as ordinary internal hard
drives. The servers are too dumb to know difference. Disk size can be
expanded on the fly with Enterprise Volume Manager. Need more space? Add
another 100 Gb. 
With an any-to-any clustering scenario, if an E2K server fails, the data is
gracefully removed and presented to the failover cluster in a matter of
minutes (maybe 2mins tops).

BUT....this SAN was mighty pricey and required a pretty steep learning curve
for those of us who had never driven one before.

We also have a 400Gb+ NAS (HP) that serves up basically static content
(Blackboard Learning System) and with Gb NICs it runs pretty sweet,
especially connected to a Gb Cisco switch on a fiber backbone.

This is a small form factor (5 1/2") desktop device that stores 1Tb using
Firewire or USB 2.0
http://www.ecost.com/ecost/shop/detail.asp?DPNo=356797
You HAVE to see the cost.....unbelievable.

AL



-----Original Message-----
From: Noah Eiger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 28, 2004 10:22 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] OT: NAS and WSS


You guys are too funny. If the choice were between Leno and reading some
of the posts on this list, I think I would take this list. Come to think
of it, if the choice were between getting bamboo shoved under my nails
and watching Leno, I might just choose the former. Well, needless to
say, I got lots of laughs out of this thread. But basically, I regret a
bit including the bit about Exchange. Though the discussion led me to
wonder, would you put the database on the NAS or the logs? Or both? Is
it the disk subsystem on a NAS that causes the concern or the
connectivity? I suppose finally, after dealing with all the foo, does
NAS really lower your true cost per gigabyte? Oh, just so I don't lose
site of the original question, you all seem to be in consensus that if
budget allows go DAS and go SCSI. NAS is ok for file sharing,
particularly with directories that are infrequently accessed or just
read from. (I may be summarizing some Google findings here as well). Do
I have that basically right? nme


List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info   : http://www.activedir.org/mail_list.htm
List FAQ    : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to