First, I appreciate all of your input. >No, backups are completely unrelated to your storage type; you need them > either way. Please another post. I meant the storage would do the back ups. >redundancy, expandability What I mean by these stupid flavor words is: Redundancy : raid 5. Expandability : the ability to stick another drive in my array and get more storage and not have to turn of the db. >Do you > need the ability to do snapshots? Yes. >Do you want to share one big, expensive, reliable unit between > multiple systems? Will you be doing failover? Yes, and Yes. Really on one other system, a phone system, but it is the crux of my business and will be writing a lot of recorded phone calls. I am working with a storage company now to set up the failover, I want the db and phone systems to never no if the storage switched over. You have given me a lot to think about. The performance concerns me and I will have to find some way to test. Perhaps spending a little less on the storage system and more on the actual servers is the way to go? Then utilize some combination off pg_backup, and the archive_command directive with a periodic script. Thank You all. I will keep researching this and the more input the better. Thank You. On 4/27/06 9:24 AM, "Michael Stone" <mstone+postgres@xxxxxxxxx> wrote: > On Thu, Apr 27, 2006 at 08:57:51AM -0400, Ketema Harris wrote: >> OK. My thought process was that having non local storage as say a big raid >> 5 san ( I am talking 5 TB with expansion capability up to 10 ) > > That's two disk trays for a cheap slow array. (Versus a more expensive > solution with more spindles and better seek performance.) > >> would allow >> me to have redundancy, expandability, and hopefully still retain decent >> performance from the db. I also would hopefully then not have to do >> periodic backups from the db server to some other type of storage. > > No, backups are completely unrelated to your storage type; you need them > either way. On a SAN you can use a SAN backup solution to back multiple > systems up with a single backup unit without involving the host CPUs. > This is fairly useless if you aren't amortizing the cost over a large > environment. > >> Is this not a good idea? > > It really depends on what you're hoping to get. As described, it's not > clear. (I don't know what you mean by "redundancy, expandability" or > "decent performance".) > >> How bad of a performance hit are we talking about? > > Way too many factors for an easy answer. Consider the case of NAS vs > SCSI direct attach storage. You're probably in that case comparing a > single 125MB/s (peak) gigabit ethernet channel to (potentially several) > 320MB/s (peak) SCSI channels. With a high-end NAS you might get 120MB/s > off that GBE. With a (more realistic) mid-range unit you're more likely > to get 40-60MB/s. Getting 200MB/s off the SCSI channel isn't a stretch, > and you can fairly easily stripe across multiple SCSI channels. (You can > also bond multiple GBEs, but then your cost & complexity start going way > up, and you're never going to scale as well.) If you have an environment > where you're doing a lot of sequential scans it isn't even a contest. > You can also substitute SATA for SCSI, etc. > > For a FC SAN the peformance numbers are a lot better, but the costs & > complexity are a lot higher. An iSCSI SAN is somewhere in the middle. > >> Also, in regards to the commit data integrity, as far as the db is >> concerned once the data is sent to the san or nas isn't it "written"? >> The storage may have that write in cache, but from my reading and >> understanding of how these various storage devices work that is how >> they keep up performance. > > Depends on the configuration, but yes, most should be able to report > back a "write" once the data is in a non-volatile cache. You can do the > same with a direct-attached array and eliminate the latency inherent in > accessing the remote storage. > >> I would expect my bottleneck if any to be the actual Ethernet transfer >> to the storage, and I am going to try and compensate for that with a >> full gigabit backbone. > > see above. > > The advantages of a NAS or SAN are in things you haven't really touched > on. Is the filesystem going to be accessed by several systems? Do you > need the ability to do snapshots? (You may be able to do this with > direct-attach also, but doing it on a remote storage device tends to be > simpler.) Do you want to share one big, expensive, reliable unit between > multiple systems? Will you be doing failover? (Note that failover > requires software to go with the hardware, and can be done in a > different way with local storage also.) In some environments the answers > to those questions are yes, and the price premium & performance > implications are well worth it. For a single DB server the answer is > almost certainly "no". > > Mike Stone
