I'm building a new server to replace our old one. Does anyone have any recommendations regarding RAID configuration for the volume holding the linear hash files, such as which level to use (0,1,10,3,5,6,30,50,60)?

The new server has an Areca ARC-1882ix-12 RAID adapter, which is a next generation card. While creating a new array, the adapter wants to know what strip size to use. The options include 4K, 8K, 16K, 32K, 64K, 128K, 256K, 512K and 1M. The documentation states that "a larger strip size produces better read performance, especially if your computer does mostly sequential reads. However, if you are sure that your computer performs random reads more often, select a smaller strip size." The default is 64K.

My current plan is to set up one RAID array for the OS and one for the data unless there is some good reason not to do that. The OS will be Windows Server 2008 (64-bit) with Universal Driver 4.7. I'm tempted to use RAID 6 for the OS because the RAID adapter is pretty fast. Not sure which level is best for the volume with LH files.

It's somewhat of a shock to see a RAID card with its own web interface. Not to mention the email and telnet functions. Man, how things have changed!

I've searched for threads pertaining to RAID config but didn't find any so I started a new one.

As you've started to determine the answer is, it depends on your needs. Most of the LinearHash access is random, not sequential. Moving large files is a very sequential operation. Reading and writing data LinearHash files are usual random unless you happen to be writing some type of log file to disk. Whatever you can do to optimize the number of random IOPs (I/O Operations Per Second) will improve your applications performance. This is a combination of disk speed/number of disks/and the raid controller. If you do some research on RAID IOPs you'll find more information on the subject. If you want to go for extreme performance then SSD (Solid State Disks) will be the best since they have extremely low access times and high IOPs.

Lets start with a couple general questions to get an idea of the requirement.

First question, what is the size of your data files (.LK and .OV) in gigabytes?

Second, is your data access mostly reading or writing? Generally most applications primarily read and periodically write.

How much cache memory does the RAID controller have and is it battery backed-up?

Thank you for the response, Jared. Here are my responses:

SIZE

1) Total size of LK and OV files: maybe 10 GB. Our LISTS table in Arev is about 500 MB right now. That and SYSLISTS tend to be the largest tables. We have an orders history table with frequent reading that is 500 MB that holds 22 years of data. At least half that table could be archived.

READING/WRITING

2) Lots of one-time writing to log files (linear hash). Lots of writing (record create & edit) to relatively small files (the active stuff). Lots of reading from and one-time writing to relatively large files (archives).

ON-BOARD CACHE/BBU

3) The RAID card's on-board cache is 1 GB. It can be upgraded to either 2 GB or 4 GB. It's DDR3 1333/ECC/single rank. The RAID card is so new that the battery backup card does not yet appear to be available for sale.

DRIVES

The server has eight kingston KC100 SSD drives. Four are 120 GB and four are 240 GB. These drives are rated for 1 million hour MTBF. Who knows if that claim is valid.

It sounds like I should upgrade the cache to 4 GB and install the BBU as soon as it becomes available. Our servers are protected by UPS.

Any suggestions for strip size?

Thanks again for taking a look at this, Jared!

Here are the Kingston KC100 SSD specs

Sustained Random 4k Read/Write

120 GB – 20,000/60,000 IOPS

240 GB – 40,000/60,000 IOPS

Max Random 4k Read/Write

120 GB – 90,000/70,000 IOPS

240 GB – 90,000/60,000 IOPS

Sequential Reads 6Gb/s

SATA Rev. 3.0 – 555MB/s

Sequential Writes 6Gb/s

SATA Rev. 3.0 – 510MB/s

It looks like the 240 GB drive is a lot faster for sustained random 4k reads.

Thanks for the information. The size of your database is such that the Windows 2008 System File Cache will also help speed up disk access by making use of free system memory as a read cache. The x64 version of windows can address a huge amount of memory and is more aggressive about using free system RAM as a temporary read file cache. For servers that are primarily dedicated to the LinearHash service, with enough system memory, windows automatically caches subsequent reads to the file system. This can produce SSD speeds with conventional drives. The down side to this, the system file cache is managed by the kernel and can't always be guaranteed to work for the LinearHash service. Other server processes doing a lot of I/O can cause the system file cache to hold data for non-database files.

The issue with the BBU (Battery Backup Unit) cannot be addressed by overall server power protection. If there is un-saved data in the RAID controller's write cache and the server crashes the BBU will persist the data until the server reboots. A server crash could be caused by a power fluctuation or a OS/hardware hiccup. The 1GB cache is probably sufficient for your needs since the underlying disks will be SSD.

Why are you putting so many SSD drives in the server if the database is only 10 GB?

Based on experience you're probably going to reach some other bottleneck in the database/server before you reach the IOPs limit. Most SAS Raids only do 150-500 IOPs sec for small random read/writes. I think you're splitting hairs and won't realize the speed advantage of the 240 GB drives. The 120 GB drives are already a tremendous leap above conventional drives.

Thanks for the heads up on the system file cache on x64 and the BBU.

The reason for the large number of drives is that I was thinking about creating one RAID 6 array for the OS and possibly a RAID 10 or 6 array for the linear hash file volume. Each array would require four drives in this scenario.

In September we had a file server that failed on RAID 1. It took a recovery service four weeks to retrieve files from a part of the disk that generated read errors and volume dismounts. It was not a pleasant experience. (We had replaced the drives on that system but they still failed anyway and it was hard to get any meaningful feedback on the true nature of the problem.)

Most of our Windows Servers are RAID 5, including our old database server. I figure that RAID 6 might give us some extra cushion in terms of disk failure. Not sure if I will have to worry too much because the new Areca RAID adapter can email alerts independently of the operating system. It will be so nice to get meaningful feedback on the status of the SDDs.

The new database server will have 48 GB of RAM (24 GB per CPU). I guess it will be a bit faster than the old one.

Do you run RAID 10 or 5 on your database servers, or are you mirroring only?

Most of our servers are RAID 5 because the individual drive capacity is below 146 GB. The issue with larger drives is the rebuild time for a failed drive gets longer and can put the entire array in jeopardy during the rebuild process. Smaller servers generally have mirrored drives with a enterprise level raid controller to make up for the lost spindle count.

What is your current IOPs metric and is the performance acceptable?

I've tried running Anvil Pro to measure IOPs on the 2K8 server SSD drives but it won't run. It is written to measure SSD performance. It works on Windows 7 but not on the 2K8 server.

Current configuration is RAID 6+0.

I'd like to measure IOPs on our old server and the new server and compare them. Can you suggest any software that can do this?

I've been using HD Tune for benchmark comparisons. It can't do write tests on a partition with a file system but the random read tests appear to be accurate. You can benchmark the performance of your current configuration.

Another nice feature of the HD Tune tool is the short stroke feature. For example, if you have a 1 GB raid cache then set the short stroke to 1 GB and run the test multiple times. On a conventional SAS array the performance increases with each test because the tool is always using the same 1 GB section of disk for the test. Since the raid controller caches the most often used blocks you'll see the test performance increase with each iteration. You may not notice this on a SSD array because the drives are almost as fast as the cache.

Thanks for the link. I've run a bunch of READ tests on computers with different types of disk subsystems. There is no comparison in IOPS between the old hard drives and the SSDs. My old Windows 7 workstation (with an SSD) outperforms all of our servers except for the new one that I just built with SSDs.

On the new server I failed (unplugged) four out of eight drives and it still performed about as well as it did with all eight drives functioning. It was hard to tell any difference in the statistics.

Even when I re-plugged the four drives and the controller began rebuilding the array, the performance during the array rebuild was still way better (about 30x) than a fully functioning RAID 5 array with three good hard drives.

I won't be using traditional hard drives anymore. Thanks again for your help, Jared.

View this thread on the Works forum...