• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Disk configuration question (RAID)

spectrumbx

[H]ard|Gawd
Joined
Apr 2, 2003
Messages
1,647
I am going to be building a series of computers soon. Two of the computers will need special care for the storage (file server and database server).

The file server will be serving only images. I have divided the images into 3 categories. One of the image category will have as much traffic as the other two combined.

My current configuration idea is to have two drives on each server mirrored (4 drives in raid 1 for each of the file server and the database server).

For the file server, one image type files will be stored on one drive and the two others will be stored on the second drive.
For the database, the database files will be stored on one drive and the log files will be stored on the other drive.
Again the two drives in each server will be mirrored.

Now, some people would argue that instead of individual drives, I should go for a raid 10 (raid 0+1) configuration.
I think however that the individual drives will perform better since they will be operating asynchroniously from each other. The problem (as I understand) in the stripping part (raid 0) of the raid 10, is that all operations happen synchroniously. Plus the performance improvement of raid 0 has been argue to be none to minimal. I would also have a hard time determining the stripe depth (stripe size) as I will deal with files of all sizes.

What do you think of my choice to go with two independent drives mirrored instead of going for a raid 10 configuration?

Thanks!
 
You're on the right track. Database servers are not meant to be run on RAID0 stripes because of the decrease in random performance with stripesets. RAID1 will still slow you a little in some places, but it's far better than a RAID0 or 10. As for file serving, unless you're on gigabit or something faster it's likely the disk will outperform the network. However, if these images are accessed in a nice, sequential manner with large chunks being accessed at a time, RAID0 in some form may have its benefits.
 
raid 0 is a bad choice for databases because it requires multiple disks to perform a read if the data requested is greater than [stripesize]. so, if you're going for this anyway, make the stripe size as big as possible.

raid 1 is a good choice for webserving too because it will allow (depending on what raid) either double bandwidth output or two requests to be served at once.

however, as mentioned before, it's probably a moot point, because outgoing bandwidth is almost certainly the limiting factor. ten megabits is nothing in terms of hard disk bandwidth. unless you're webserving kernel.org ( :eek: ) you don't really need the performance of raid, just the redundancy (think raid1).
 
Thanks guys!

What type of raid card would you guys suggest given that only raid 1 will be used?
Do I have to shell out the high cost of expensive raid cards ($600+) to minimize the impact of the raid 1, or will cheap (even integrated) raid card be enougth?
 
no expensive stuff for this unless you need lots and lots and lots of disk. otherwise, anything should work. integrated makes it cheap, but this promise card should handle your purposes. if you're using linux, you could do software raid at these levels without much performance hit. basically, anything goes. i have a software raid0 array on my fileserver that gets about 60+mb/s reads and writes, on a pIII-450. not bad considering the hardware. i just used a $30 siig pci ide controller with no raid and set up a raid array in software.
 
well, it really depends on what your price range is, and what kind of server you're going with.
If you're going scsi, and can afford it, you really can't go wrong with something like this Put an array on each channel
But that is really, really high end.

I wouldn't use IDE in a production database server, but something like this could work if you're only using 2 disks in a Raid1 array. Not a true 'hardware' raid, but i use the same card with Atlas 10K IV's at home.

If you have to go IDE, a 2 channel 3Ware card would serve you better than most other vendors.
 
The servers will be production servers.
I was thinking of going SATA rator 74gb for each drive in the raids or if really needed 15000rpm SCSI 36gb x 2.

The SCSI way will double the number of drives and cost (8 drives instead of 4 in each computer), but will be the most performant.

Since my 10mbit internet bandwidth will be the bottleneck, I don't know if going SCSI will be the best.

What I am really trying to do is minimize request time and queue length.
The maximum file size on the image server for instance will be 100k and most will be 2-3k.

Given that the files will not be accessed in sequence, that will make a lof of disc platter head activities.

Will the large cache offered by some SCSI cards (128mb or 256mb) make much difference?
Would you justify $800-1000 price tag just for the cache?
 
spectrumbx said:
The SCSI way will double the number of drives and cost (8 drives instead of 4 in each computer), but will be the most performant.

This is always the battle.

Since my 10mbit internet bandwidth will be the bottleneck, I don't know if going SCSI will be the best.

Man, I've got a 6 year old Maxtor sitting here that will outrun 10Base. Perhaps you need to upgrade the network infrastructure first.

What I am really trying to do is minimize request time and queue length.
The maximum file size on the image server for instance will be 100k and most will be 2-3k.

Given that the files will not be accessed in sequence, that will make a lof of disc platter head activities.

Then you'd want something with low access/seek times. A raptor will get you there more cheaply than SCSI, but will not perform as good as SCSI.

Will the large cache offered by some SCSI cards (128mb or 256mb) make much difference?
Would you justify $800-1000 price tag just for the cache?

Depends on your load levels. RAID5 cache gets critical if you're doing a whole hell of a lot of writing. If this database is particularly intensive or is being accessed by a lot of different users, I'd be inclined to go for the higher cache level, but not before I had the machine maxed with memory.
 
Snugglebear, thanks for the excellent response. :)

I think I will go for SATA 10k raptors with the lowest cost hardware raid 1 (no software raid or half hardware/half software raid as preserving CPU power is a must).

I can always upgrade later to scsi and put the raptors to other use.

Two more questions:

1. Is a hard drive cache more for writting than for reading? (I am more interested in read caching).
2. What card would you advise as the best bang for the buck for a true hardware raid 1?

Thanks!
 
Drive cache provides more benefit for write ops than read ops. Modern filesystems are tree-based and store data in ways that require more random accesses. Hard drives use read-ahead caching, reading an arbitrary number of blocks ahead of where you tell it to in the hope data required soon will be there. However, this is on the physical level, and combined with tree-based filesystems doesn't do too well. As such OSes now also have disk caches, though they do it on the filesystem level rather than physical level. This way they can keep at least a good chunk of the top of the tree in main memory for fast access (often hundreds of MB on servers, and another reason you want to heap on the RAM).

Write ops benefit from drive caching because they're slower, requiring more think time and queue reordering than read ops. An OS can thus just issue the write to the controller, the controller issues the write to the disk, the disk receives the request, lies and says it's ready to write this instant, receives the data to write into the cache, then tells the controller and OS that it's finished. Meanwhile the drive does whatever it wants until writing is convenient or forced, and then actually writes the data. This benefits you since the OS and controller don't have to hang on and wait for the drive to do what it said it would. But then if you lose power or shut down the machine too soon, the write may not have made it onto the physical disk and you're left with an inconsistency (hence the easy ability to turn off write caching).

Now, be aware that you can tweak cache settings on the disk and OS level. ATA drives do most of their caching with firmware, so if you find a powerful SMART tool you can often set all the flags for what type of caching you want and what the limits are for it. Each manufacturer is slightly different, so do your homework. OSes can also be tuned, usually through the registry or obscure config files.

As for software/hardware raid, I don't follow SATA closely, at least not yet. I'm still seeing too many problems with the various products for me to jump in. Just be aware that database & fileservers don't use a lot of CPU power unless you're running other daemons or have some bizarre custom application. Not that RAID1 uses much power to begin with, but still, you may be fine with a driver-based card.
 
Thanks!
That made a lot of sense and clarified the few confusions I had.

I actually learned of a way to have IIS cache the content to memory. So, I will just add more memory (an extra gb) to my file server and increase the cache for IIS.

I will have 4gb of ram for a database that will be around 10gb. Because I intend to only have just one database server (which will go throught a lot of selects and updates, quite a bit of inserts, much less delete), I would rather not have anything else use the cpus.

Do you think a dual opteron 242 will be plenty?
 
It depends on the load, # concurrent users, application access patterns, which DBMS is being used, and all sorts of other factors. A dual opteron is probably overkill for most things and you may well do better with SCSI. But then there's one way to find out.
 
Back
Top