On Mon, 18 Feb 2008, Peter Koczan wrote:
> One of the other things I was interested in was the "hidden costs" of
> a SAN. For instance, we'd probably have to invest in more UPS capacity
> to protect our data. Are there any other similar points that people
> don't initially consider regarding a SAN?

You may well find that the hardware required in each machine to access the
SAN (fibrechannel cards, etc) and switches are way more expensive than
just shoving a cheap hard drive in each machine. Hard drives are
mass-produced, and remarkably cheap for what they do. SAN hardware is
specialist, and expensive.

Matthew

--
Nog: Look! They've made me into an ensign!
O'Brien: I didn't know things were going so badly.
Nog: Frightening, isn't it?

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Wed, 2008-02-20 at 13:41 +0000, Matthew wrote:
> On Mon, 18 Feb 2008, Peter Koczan wrote:
> > One of the other things I was interested in was the "hidden costs" of
> > a SAN. For instance, we'd probably have to invest in more UPS capacity
> > to protect our data. Are there any other similar points that people
> > don't initially consider regarding a SAN?
>
> You may well find that the hardware required in each machine to access the
> SAN (fibrechannel cards, etc) and switches are way more expensive than
> just shoving a cheap hard drive in each machine. Hard drives are
> mass-produced, and remarkably cheap for what they do. SAN hardware is
> specialist, and expensive.

Can be, but may I point to a recent posting on Beowulf ml [1] and the
article it references [2] Showing that the per node price of SDR IB has
come down far enough to in some cases compete with GigE. ymmv, but I'm
in the planning phase for a massive storage system and it's something
we're looking into. Just thought I'd share


Success!

../C

[1]
http://www.mirrorservice.org/sites/w...ry/020538.html

[2] http://www.clustermonkey.net/content/view/222/1/




---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On Wed, Feb 20, 2008 at 02:52:42PM +0100, C. Bergström wrote:
>Can be, but may I point to a recent posting on Beowulf ml [1] and the
>article it references [2] Showing that the per node price of SDR IB has
>come down far enough to in some cases compete with GigE. ymmv, but I'm
>in the planning phase for a massive storage system and it's something
>we're looking into. Just thought I'd share

For HPC, maybe. For other sectors, it's hard to compete with the free
GBE that comes with the machine, and that low price doesn't reflect the
cost of extending an oddball network infrastructure outside of a cluster.

Mike Stone

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Hi all,

I had a few meetings with SAN vendors and I thought I'd give you some
follow-up on points of potential interest.

- Dell/EMC
The representative was like the Dell dude grown up. The sales pitch
mentioned "price point" about twenty times (to the point where it was
annoying), and the pitch ultimately boiled down to "Dude, you're
getting a SAN." My apologies in advance to bringing back repressed
memories of the Dell dude. As far as technical stuff goes, it's about
what you'd expect from a low-level SAN. The cost for a SAN was in the
$2-3 per GB range if you went with the cheap option...not terrible,
but not great either, especially since you'd have to buy lots of GB.
Performance numbers weren't bad, but they weren't great either.

- 3par
The sales pitch was more focused on technical aspects and only
mentioned "price point" twice...which is a win in my books, at least
compared to Dell. Their real place to shine was in the technical
aspect. Whereas Dell just wanted to sell you a storage system that you
put on a network, 3par wanted to sell you a storage system
specifically designed for a network, and change the very way you think
about storage. They had a bunch of cool management concepts, and very
advanced failover, power outage, and backup techniques and tools.
Performance wasn't shabby, either, for instance a RAID 5 set could get
about 90% the IOPS and transfer rate that a RAID 10 set could. How
exactly this compares to DAS they didn't say. The main stumbling block
with 3par is price. While they didn't give any specific numbers, best
estimates put a SAN in the $5-7 per GB range. The extra features just
might be worth it though.

- Lefthand
This is going to be an upcoming meeting, so I don't have as good of an
opinion. Looking at their website, they seem more to the Dell end in
terms of price and functionality. I'll keep you in touch as I have
more info. They seem good for entry-level SANs, though.

Luckily, almost everything here works with Linux (at least the major
distros), including the management tools, in case people were worried
about that. One of the key points to consider going forward is that
the competition of iSCSI and Fibre Channel techs will likely bring
price down in the future. While SANs are certainly more expensive than
their DAS counterparts, the gap appears to be closing.

However, to paraphrase a discussion between a few of my co-workers,
you can buy toilet paper or kitty litter in huge quantities because
you know you'll eventually use it...and it doesn't change in
performance or basic functionality. Storage is just something that you
don't always want to buy a lot of in one go. It will get bigger, and
cheaper, and probably faster in a relatively short amount of time. The
other thing is that you can't really get a small SAN. The minimum is
usually in the multiple TB range (and usually >10 TB). I'd love to be
able to put together a proof of concept and a test using 3par's
technology and commodity 80GB slow disks, but I really can't. You're
stuck with going all-in right away, and enough people have had
problems being married to specific techs or vendors that it's really
hard to break that uneasiness.

Thanks for reading, hopefully you found it slightly informative.

Peter

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance