Skip site navigation (1) Skip section navigation (2)

Re: Anyone using a SAN?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, Tobias Brox <tobias(at)nordicbet(dot)com>, Peter Koczan <pjkoczan(at)gmail(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Anyone using a SAN?
Date: 2008-02-14 03:23:04
Message-ID: 200802140323.m1E3N4U26014@momjian.us (view raw or flat)
Thread:
Lists: pgsql-performance
Should this be summarized somewhere in our docs; just a few lines with
the tradeoffs, direct storage = cheaper, faster, SAN = more configurable?

---------------------------------------------------------------------------

Scott Marlowe wrote:
> On Feb 13, 2008 5:02 PM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
> > On Wed, 13 Feb 2008, Tobias Brox wrote:
> >
> > > What I'm told is that the state-of-the-art SAN allows for an "insane
> > > amount" of hard disks to be installed, much more than what would fit
> > > into any decent database server.
> >
> > You can attach a surpringly large number of drives to a server nowadays,
> > but in general it's easier to manage larger numbers of them on a SAN.
> > Also, there are significant redundancy improvements using a SAN that are
> > worth quite a bit in some enterprise environments.  Being able to connect
> > all the drives, no matter how many, to two or more machines at once
> > trivially is typically easier to setup on a SAN than when you're using
> > more direct storage.
> 
> SNIP
> 
> > There's no universal advantage on either side here, just a different set
> > of trade-offs.  Certainly you'll never come close to the performance/$
> > direct storage gets you if you buy that in SAN form instead, but at higher
> > budgets or feature requirements they may make sense anyway.
> 
> I agree with everything you've said here, and you've said it far more
> clearly than I could have.
> 
> I'd like to add that it may still be feasable to have a SAN and a db
> with locally attached storage.  Talk the boss into a 4 port caching
> SAS controller and four very fast hard drives or something else on the
> server so that you can run tests to compare the performance of a
> rather limited on board RAID set to the big SAN.  For certain kinds of
> things, like loading tables, it will still be a very good idea to have
> local drives for caching and transforming data and such.
> 
> Going further, the argument for putting the db onto the SAN may be
> weakened if the amount of data on the db server can't and likely won't
> require a lot of space.  A lot of backend office dbs are running in
> the sub gigabyte range and will never grow to the size of the social
> security database.  Even with dozens of apps, an in house db server
> might be using no more than a few dozen gigabytes of storage.  Given
> the cost and performance of large SAS and SATA drives, it's not all
> unlikely that you can fit everything you need for the next five years
> on a single set of disks on a server that's twice as powerful as most
> internal db servers need.
> 
> You can hide the cost of the extra drives in the shadow of the receipt
> for the SAN.
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>        message can get through to the mailing list cleanly

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-performance by date

Next:From: Peter KoczanDate: 2008-02-14 04:17:56
Subject: Re: Anyone using a SAN?
Previous:From: Scott MarloweDate: 2008-02-14 00:55:49
Subject: Re: Anyone using a SAN?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group