Re: SAN vs Internal Disks - Mailing list pgsql-performance
From | Joshua D. Drake |
---|---|
Subject | Re: SAN vs Internal Disks |
Date | |
Msg-id | 46E1BF7F.8080004@commandprompt.com Whole thread Raw |
In response to | Re: SAN vs Internal Disks (david@lang.hm) |
List | pgsql-performance |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 david@lang.hm wrote: > 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) > In general a SAN does not provide more I/O than direct attached storage. It is all about the BUS, Controller and drive types. > 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. Well there are SANs that have trays that can be stacked, but then again you can get the same thing with DAS too. > >> 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). > >> Also, my boss states that "all big enterprises uses SAN nowadays". > Uhmm as someone who consults with many of the big enterprises that are running PostgreSQL, that is *not* true. >> 2. Expensive > > no, _extremely expensive. price one and then look at how much hardware Let me just +1 this. The amount of DAS storage you can get for 30k is amazing compared to the amount of SAN you can get for 30k. Joshua D. Drake > 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 > - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG4b9/ATb/zqfZUUQRAnBiAJ4kdOicN3If4scLAVdaU4nS+srGHQCgnkR2 C6RvSyLcAtgQ1bJJEau8s00= =lqbw -----END PGP SIGNATURE-----
pgsql-performance by date: