Re: Hardware vs Software RAID - Mailing list pgsql-performance
From | Greg Smith |
---|---|
Subject | Re: Hardware vs Software RAID |
Date | |
Msg-id | Pine.GSO.4.64.0806251051060.29204@westnet.com Whole thread Raw |
In response to | Re: Hardware vs Software RAID ("Peter T. Breuer" <ptb@inv.it.uc3m.es>) |
Responses |
Re: Hardware vs Software RAID
Re: Hardware vs Software RAID Re: Hardware vs Software RAID Re: Hardware vs Software RAID |
List | pgsql-performance |
On Wed, 25 Jun 2008, Peter T. Breuer wrote: > You can put the log/bitmap wherever you want in software raid, including > on a battery-backed local ram disk if you feel so inclined. So there is > no intrinsic advantage to be gained there at all. You are technically correct but this is irrelevant. There are zero mainstream battery-backed local RAM disk setups appropriate for database use that don't cost substantially more than the upgrade cost to just getting a good hardware RAID controller with cache integrated and using regular disks. What I often do is get a hardware RAID controller, just to accelerate disk writes, but configure it in JBOD mode and use Linux or other software RAID on that platform. Advantages of using software RAID, in general and in some cases even with a hardware disk controller: -Your CPU is inevitably faster than the one on the controller, so this can give better performance than having RAID calcuations done on the controller itself. -If the RAID controllers dies, you can move everything to another machine and know that the RAID setup will transfer. Usually hardware RAID controllers use a formatting process such that you can't read the array without such a controller, so you're stuck with having a replacement controller around if you're paranoid. As long as I've got any hardware that can read the disks, I can get a software RAID back again. -There is a transparency to having the disks directly attached to the OS you lose with most hardware RAID. Often with hardware RAID you lose the ability to do things like monitor drive status and temperature without using a special utility to read SMART and similar data. Disadvantages: -Maintenance like disk replacement rebuilds will be using up your main CPU and its resources (like I/O bus bandwidth) that might be offloaded onto the hardware RAID controller. -It's harder to setup a redundant boot volume with software RAID that works right with a typical PC BIOS. If you use hardware RAID it tends to insulate you from the BIOS quirks. -If a disk fails, I've found a full hardware RAID setup is less likely to result in an OS crash than a software RAID is. The same transparency and visibility into what the individual disks are doing can be a problem when a disk goes crazy and starts spewing junk the OS has to listen to. Hardware controllers tend to do a better job planning for that sort of failure, and some of that is lost even by putting them into JBOD mode. >> However, not all hardware RAID will have such a battery-backed-up cache, >> and those that do tend to have a hefty price tag. > > Whereas software raid and a firewire-attached log device does not. A firewire-attached log device is an extremely bad idea. First off, you're at the mercy of the firewire bridge's write guarantees, which may or may not be sensible. It's not hard to find reports of people whose disks were corrupted when the disk was accidentally disconnected, or of buggy drive controller firmware causing problems. I stopped using Firewire years ago because it seems you need to do some serious QA to figure out which combinations are reliable and which aren't, and I don't use external disks enough to spend that kind of time with them. Second, there's few if any Firewire setups where the host gets to read SMART error data from the disk. This means that you can continue to use a flaky disk long past the point where a direct connected drive would have been kicked out of an array for being unreliable. SMART doesn't detect 100% of drive failures in advance, but you'd be silly to setup a database system where you don't get to take advantage of the ~50% it does catch before you lose any data. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
pgsql-performance by date: