Re: Anyone using a SAN?

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. +