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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
