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

Re: Anyone using a SAN?

From: "Peter Koczan" <pjkoczan(at)gmail(dot)com>
To: "Greg Stark" <stark(at)enterprisedb(dot)com>
Cc: "Tobias Brox" <tobias(at)nordicbet(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Anyone using a SAN?
Date: 2008-02-18 21:44:40
Message-ID: 4544e0330802181344q2d98560du6bd4e481a9c9439f@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
> That's true about SANs in general. You don't buy a SAN because it'll
> cost less than just buying the disks and a controller. You buy a SAN
> because it'll let you make managing it easier. The break-even point has
> more to do with how many servers you're able to put on the SAN and how
> often you need to do tricky backup and upgrade procedures than it
> doeswith the hardware.

One big reason we're really looking into a SAN option is that we have
a lot of unused disk space. A typical disk usage scheme for us is 6 GB
for a clean Linux install, and 20 GB for a Windows install. Our disks
are typically 80GB, and even after decent amounts of usage we're not
even approaching half that. We install a lot of software in AFS, our
networked file system, and users' home directories and project
directories are in AFS as well. Local disk space is relegated to the
OS and vendor software, servers that need it, and seldom-used scratch
space. There might very well be a break-even point for us in terms of
cost.

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?

Again, thanks for all your help.

Peter

In response to

Responses

pgsql-performance by date

Next:From: MatthewDate: 2008-02-19 14:48:55
Subject: Re: Disable WAL completely
Previous:From: Greg SmithDate: 2008-02-18 21:24:30
Subject: Re: shared_buffers in 8.3 w/ lots of RAM on dedicated PG machine

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