Re: SAN vs Internal Disks

On Fri, 7 Sep 2007, Tobias Brox wrote:

> We're also considering to install postgres on SAN - that is, my boss is
> convinced this is the right way to go.
>
> Advantages:
>
> 1. Higher I/O (at least the salesman claims so)

only if you buy better disks for the SAN then for the local system (note
that this includes battery backed ram for write caching. the SAN will
include a bunch becouse it's performance would _suck_ otherwise. if you
don't put any on your stand-alone system you are comparing apples to
oranges)

> 2. Easier to upgrade the disk capacity

only if you buy a SAN with a lot of empty drive slots, but wouldn't buy a
system with empty drive slots.

> 3. Easy to set up "warm standby" functionality. (Then again, if the
> postgres server fails miserably, it's likely to be due to a disk
> crash).

and if postgres dies for some other reason the image on disk needs repair,
unless you script stopping postgres when the SAN does it's snapshots,
those snapshots are not going to be that good. the problems are useually
repairable, but that makes starting your warm spare harder.

> Also, my boss states that "all big enterprises uses SAN nowadays".

your bos would be very surprised at what the really big shops are doing
(and not doing). yes they have a SAN, they have many SANs, from many
different vendors, and they have many systems that don't use the SAN and
use local disks instead. when you get really large you can find just about
anything _somewhere_ in the company.

> Disadvantages:
>
> 1. Risky? One gets the impression that there are frequent problems
> with data integrity when reading some of the posts in this thread.

SAN's add more parts and more potential points of failure, then when you
add the SAN replication to the mix things get even more 'interesting'.
doing SAN replication across a significant distance to your DR facility
can be a LOT harder to get working right then the salesman makes it sound.
it's not uncommon to see a san replication decide that it's going to take
a week to catch up after doing a DR test for example.

> 2. Expensive

no, _extremely expensive. price one and then look at how much hardware you
could buy instead. you can probably buy much mroe storage, and a couple
complete spare systems (do replication to a local spare as well as your
remote system) and end up with even more reliability.

> 3. "Single point of failure" ... but that you have either it's a SAN or
> a local disk, one will anyway need good backup systems (and eventually
> "warm standby"-servers running from physically separated disks).

no, with local disks you can afford to have multiple systems so that you
don't have a SPOF

> 4. More complex setup?
>
> 5. If there are several hosts with write permission towards the same
> disk, I can imagine the risks being higher for data integrity
> breakages. Particularly, I can imagine that if two postgres instances
> is started up towards the same disk (due to some sysadmin mistake), it
> could be disasterous.

when you are useing a SAN for a database the SAN vendor will have you
allocate complete disks to each box, so you don't have multiple boxes
hitting the same drive, but you also don't get a lot of the anvantages the
salesman talks about.

David Lang