[ale] ATL Colocation and file server suggestions

[Jeff Lightner]

I should have read more closely.  I thought he was saying SANs were a
single point of failure.  I see now he qualified it to say non-redundant
SANs were.

While you might get some more bandwidth out of multiple paths (depending
on how you configure things) the main point of multiple paths is
redundancy for most people.

We do have one array that arrived "iSCSI" ready but we use its fibre
connections instead so I can't comment on how robust using the former
would be.

-----Original Message-----
From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of Pat
Regan
Sent: Friday, January 23, 2009 1:39 PM
To: ale at ale.org
Subject: Re: [ale] ATL Colocation and file server suggestions

Jeff Lightner wrote:
> I'll have to say I strongly disagree.

I won't disagree with him, unless I'm spending a ton on my SAN.

> First off in a SAN environment you usually have multiple paths to the
> storage using multiple HBAs in the servers as well as multiple fibre
> adapters in the storage arrays.  If you just have 2 and 2 that gives
you
> 4 paths to the data.  Lose 3 and you're STILL running.

This is wonderful, but if you lose three of those links you aren't
likely running.  You're probably walking :).  I doubt most people are
spending the money to build in 4x the bandwidth required for day to day
operations.

> Secondly most storage arrays have a fair amount of redundancy built in
> including multiple power supplies with their own batteries that even
in
> the event of a full data system power outage allow them to flush all
> cache to disks before the array itself stops operating.   In such an
> event having multiple arrays wouldn't have helped because all the
arrays
> would go down at the same time.

I've never built a real production standalone server that didn't meet
all those requirements.

> You do of course also want to have redundant fibre switches so loss of
> one switch doesn't take down the SAN.

More money :)

> It's possible to lose RAID sets but that isn't a function of SAN but
> rather a function of RAID and you'd have the same risk with RAID built
> into the server (e.g. Dell PERC).  You have even more of a risk NOT
> doing RAID because loss of a single drive is apt to destroy all your
> data.

A machine without RAID is a machine waiting to be restored from backup.

> I've been working on SANs for over 10 years now and most of the issues
> I've seen with them had more to do with misunderstanding of the way
the
> array works than anything else.

You're also talking about fibre channel, so you're talking about proper
SANs.  Earlier in this discussion they were talking about iscsi SANs,
which means SAN on a tight budget.  Which very likely means there is no
automatic failover available, or at least not being purchased.

There is a huge price difference between local attached storage and an
equally (for some value of equal) redundant SAN.  Granted, the SAN buys
you flexibility as well.  Even if you have two identical SANs, then you
"only" get two points of failure :).

But then, a SAN makes it easier to have one server pick up the work of
another when it dies.  Mount up the volume, and run.  If you need that
kind of uptime, you have to pay for it, though.

Pat
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------