Western Digital releases new VelociRaptors

[Hellhammer]

Well, as some of you may think that VelociRaptors are dead, they aren't. They were great few years ago when there were no SSDs for reasonable price but got then owned by SSDs due their fast speed.

WD has came up with two new VRs, 450GB (299$) and 600GB (329$). They are both 10 000rpm drives and improvements for last generation are 32MB cache instead of 16MB, SATA 6Gb/s, 0.4ms seek time (was 0.75ms) and transfer speed of 145MB per second (was 128MB/s). Platter size has also increased from 150GB to 200GB so they were able to keep the same form factor (3.5") and come up with larger capacities.

Still can't beat SSDs in speed but the price is five times cheaper per GB than in SSDs.

Very detailed and massive article available in AnandTech (thanks Eidorian for letting me know about that site, love it!)

 

[Topper]

Well, as some of you may think that VelociRaptors are dead, they aren't. They were great few years ago when there were no SSDs for reasonable price but got then owned by SSDs due their fast speed.
WD has came up with two new VRs, 450GB (299$) and 600GB (329$). They are both 10 000rpm drives and improvements for last generation are 32MB cache instead of 16MB, SATA 6Gb/s, 0.4ms seek time (was 0.75ms) and transfer speed of 145MB per second (was 128MB/s). Platter size has also increased from 150GB to 200GB so they were able to keep the same form factor (3.5") and come up with larger capacities.
Still can't beat SSDs in speed but the price is five times cheaper per GB than in SSDs.
Very detailed and massive article available in AnandTech

Good article, thank you.
From the same article...

Final Words:
"The problem is once you take into account solid state storage. The new VelociRaptor boasts a 4KB random write speed of 1.9MB/s. Intel's X25-M G2 is amost 20x faster. The new VelociRaptor averages 178 IOPS in our typical Bench workload, Intel's X25-M can push nearly 800 IOPS in the same test.

While you are getting much more storage for your dollar with the VelociRaptor, a higher performance alternative would be to combine a good SSD with a 1TB drive. Using the SSD for your OS and apps, and the TB drive for all of your music, photos, videos and games. It's this sort of configuration that I use in my personal desktop (except I have two 1TB drives in RAID-1).

If you can't go the SSD route but still need the performance, WD has retaken the crown with the new VelociRaptor. If you can make it work however, you may be happier with an X25-M and a WD Caviar Black instead."
.

 

[Hellhammer]

Good article, thank you.
From the same article...

Final Words:
"The problem is once you take into account solid state storage. The new VelociRaptor boasts a 4KB random write speed of 1.9MB/s. Intel's X25-M G2 is amost 20x faster. The new VelociRaptor averages 178 IOPS in our typical Bench workload, Intel's X25-M can push nearly 800 IOPS in the same test.

While you are getting much more storage for your dollar with the VelociRaptor, a higher performance alternative would be to combine a good SSD with a 1TB drive. Using the SSD for your OS and apps, and the TB drive for all of your music, photos, videos and games. It's this sort of configuration that I use in my personal desktop (except I have two 1TB drives in RAID-1).

If you can't go the SSD route but still need the performance, WD has retaken the crown with the new VelociRaptor. If you can make it work however, you may be happier with an X25-M and a WD Caviar Black instead."
.

That's true though. I think there are people who need VelociRaptors because SSDs are way too expensive per GB. For RAIDing, these drives are pretty good (there is thread about HD vs SSD RAID and I think HD was the winner). Sure, SSDs are the future but nice to see something new about hard drives!

 

[nanofrog]

That's true though. I think there are people who need VelociRaptors because SSDs are way too expensive per GB. For RAIDing, these drives are pretty good (there is thread about HD vs SSD RAID and I think HD was the winner). Sure, SSDs are the future but nice to see something new about hard drives!

Both points have their merits and limitations.

The VR's are enterprise drives, and are more reliable in high write environments than SSD's, which means they're better suited for RAID under write conditions. They've also got the cost/GB on their side.

But this is really a special case.

Overall, I'd go with SSD as a boot/applications disk (random access performance), and mechanical (i.e. cheap mechanical, not VR's) for mass storage (or RAID if needed, as the lower cost can still allow you to exceed the VR's in terms of raw speed for the same money - sustained throughputs, not random access- , with the added benefit of additional capacity).

 

[DoFoT9]

Both points have their merits and limitations.

The VR's are enterprise drives, and are more reliable in high write environments than SSD's, which means they're better suited for RAID under write conditions. They've also got the cost/GB on their side.

But this is really a special case.

Overall, I'd go with SSD as a boot/applications disk (random access performance), and mechanical (i.e. cheap mechanical, not VR's) for mass storage (or RAID if needed, as the lower cost can still allow you to exceed the VR's in terms of raw speed for the same money - sustained throughputs, not random access- , with the added benefit of additional capacity).

old thread i know, but suck it up

considering these two drives (the WD VR and Intel X24-M) -and potentially any commercially available storage device- in a Macintosh based FileMaker database environment. +100 users, fairly active access from all of them (running reports, etc).

for this type of environment, would you rather the database be kept on mechanical or solid state storage?

what is the reasoning behind this?

 

[nanofrog]

considering these two drives (the WD VR and Intel X24-M) -and potentially any commercially available storage device- in a Macintosh based FileMaker database environment. +100 users, fairly active access from all of them (running reports, etc).

for this type of environment, would you rather the database be kept on mechanical or solid state storage?

what is the reasoning behind this?

I'd use a mechanical based RAID array (i.e. 10 with a small stripe size), as it allows for higher IOPS, n = 2 redundancy, and is more durable for high write environments.

Ideally, SAS disks would be a better choice than SATA, but for a 100 users or so, SATA would be fine (I'd recommend using enterprise grade disks, as they're built for this sort of abuse).

 

[cutterman]

Here is an article which graphically helps answer your question. I thought the RAID 5 SSD performance was interesting, though they were using the more expensive X-25E SLC drives (with an order of magnitude less capacity).

 

[nanofrog]

Here is an article which graphically helps answer your question. I thought the RAID 5 SSD performance was interesting, though they were using the more expensive X-25E SLC drives (with an order of magnitude less capacity).

As mentioned, the right controller makes a big difference. The newer 6.0Gb/s RAID controllers would improve matters for both HDD's and SSD's. But SSD's do have an advantage for smaller stripe sizes (RAID card with plenty of cache will help with writes as well, significantly so in some cases <i.e. 4GB DIMM in an Areca>, no matter the disk tech used). Unfortunately, for a database, you would want an SLC based disk to handle the wear on the cells due to the write cycle load of RAID 5 with small files, and they're still quite expensive (few choices as well, even if you include SLC based Flash drives).

SAS would still be the best choice IMO for a database, as they can produce higher IOPS, have better small file performance than SATA, and can take the abuse. But they're also expensive (cost/GB) compared to SATA, though not as bad as SLC based drives.

SATA still has the cost/GB advantage, and at 100 users, should be viable (no peformance specs given).

 

[DoFoT9]

I'd use a mechanical based RAID array (i.e. 10 with a small stripe size), as it allows for higher IOPS, n = 2 redundancy, and is more durable for high write environments.

i agree that the mechanical drives do allow for good IOPS, but what about this?

However, placing your database data files on an Intel X25-E is an excellent strategy. One X25-E is 66% faster than eight (!) 15000RPM SAS drives.

it's worth mentioning that the database is an OLTP db.

Ideally, SAS disks would be a better choice than SATA, but for a 100 users or so, SATA would be fine (I'd recommend using enterprise grade disks, as they're built for this sort of abuse).

the performance of SAS is quite remarkable compared to SATA i'll agree there, the price is nearly even justified

Here is an article which graphically helps answer your question. I thought the RAID 5 SSD performance was interesting, though they were using the more expensive X-25E SLC drives (with an order of magnitude less capacity).

thank you very much for that review! i just studied and read it in-depth, and it really has helped me to understand better the scenario that we have in our organisation.

any recommendations?

As mentioned, the right (write?? ) controller makes a big difference. The newer 6.0Gb/s RAID controllers would improve matters for both HDD's and SSD's. But SSD's do have an advantage for smaller stripe sizes (RAID card with plenty of cache will help with writes as well, significantly so in some cases <i.e. 4GB DIMM in an Areca>, no matter the disk tech used). Unfortunately, for a database, you would want an SLC based disk to handle the wear on the cells due to the write cycle load of RAID 5 with small files, and they're still quite expensive (few choices as well, even if you include SLC based Flash drives).

thats true, i have recommended against using MLC based technology for our main database drive volume, myself and my boss agree on this.

SAS would still be the best choice IMO for a database, as they can produce higher IOPS, have better small file performance than SATA, and can take the abuse. But they're also expensive (cost/GB) compared to SATA, though not as bad as SLC based drives.

im trying to find a good comparison to compare these two, but am unable to find one - is it in that ananad article?

unfortunately though, i think SAS will be out of the scenario for the time being..

SATA still has the cost/GB advantage, and at 100 users, should be viable (no peformance specs given).

what would you like to know? im not really sure what information to provide. basics are
- 100+ users during the day
- FileMaker 11 running on latest 2xMacPros. database is split onto 2 MacPros because of its size, 2nd mac pro in identical config
- 2x60GB SSDs in RAID0
- hourly backups of the entire database during business hours copied onto 2x60GB SSDs (see below for another inquiry)
- network usage at any given time on both machines is 20KB/s up to 500KB/s - fluctuations of 10MB/s in busy periods.
- disk activity follows a similar structure to network activity.
- read to write ratio is roughly 80% (read)-20% (write)
- anything else?

onto my 2nd question, now that the main storage is sorted - the hourly backups are also very important for obviously backing up. the speed at which this backup runs is of utmost important, because the entire database is taken offline by Filemaker for the few minutes that it runs. currently it is 2x60GB OCZ Agility SSDs in RAID0. i have monitored performance of them, and its quite terrible. is it possible for these SLC drives to be effected by write amplification? or is that just MLC?

in the real world i observed, 155.5MB/s peak data transmission overall. fluctuates between 40MB/s and 150MB/s read. 30MB/s and 160MB/s write. average of roughly 100MB/s read/write. large fluctuations towards the end, indicates high amount of fragmentation (write overhead?). backup took 3mins and 11 seconds.

so this indicates 3minutes of downtime every hour for a daily backup. over the period of the day (11 backups) that is basically 33minutes of downtime. the backup size is roughly 40GB each. i think i require the best and most optimal sequential write speeds onto this volume. ideas?

Thanks in advance!

 

[philipma1957]

If you use a pair of intel x25-e 64gb hdds in raid0 they will be very fast. They will take 10 times longer to slowdown from overwrite. They also are very expensive.

 

[DoFoT9]

If you use a pair of intel x25-e 64gb hdds in raid0 they will be very fast. They will take 10 times longer to slowdown from overwrite. They also are very expensive.

for the main drives or the hourly backup drives?

 

[nanofrog]

it's worth mentioning that the database is an OLTP db.

It all comes down to the IOPS.

Take the following into consideration (from Wiki's IOPS page - yes, I'm being lazy tonight ):

Some hard drives will improve in performance as the number of outstanding IO's (i.e. queue depth) increases. This is usually the result of more advanced controller logic on the drive performing command queuing and reordering commonly called either Tagged Command Queuing (TCQ) or Native Command Queuing (NCQ). Most commodity (consumer grade) SATA drives either cannot do this, or their implementation is so poor that no performance benefit can be seen. Enterprise class SATA drives, ... will improve by nearly 100% with deep queues.

This is where a controller with the best drives suited for the task makes a significant difference.

Another little tidbit from the same page (specifically on the Intel X-25E):

Newer flash SSD drives such as the Intel X25-E have much higher IOPS than traditional hard disk drives. In a test done by Xssist, using IOmeter, 4KB RANDOM 70/30 RW, queue depth 4, the IOPS delivered by the Intel X25-E 64GB G1 started around 10000 IOPs, and dropped sharply after 8 minutes to 4000 IOPS, and continued to decrease gradually for the next 42 minutes. IOPS vary between 3000 to 4000 from around the 50th minutes onwards for the rest of the 8+ hours test run. Even with the drop in random IOPS after the 50th minute, the X25-E still has much higher IOPS compared to traditional hard disk drives.

This is rather nice, but you also pay for it.

Another thing to keep in mind in terms of write wear:

• Enterprise mechanical (SATA or SAS) = 1E15 bit error rating
• SLC Flash = 1E5

Granted, wear leveling can help with SLC. But if the drive's are filled, there's less additional capacity for this, and it will increase the wear (write amplification = decreases the disk's lifespan). This can be particularly important in the enterprise realm, as the typical planning cycle for storage systems is 3 years. But budgetary restrictions/trepidation over major tech expenditures can push that to 5 years or so. So SLC may not be able to make it if there's insufficient unused capacity over the disks' lifespan (means you have to make sure that there's sufficient n disks to be sure there will be unused capacity over it's entire intended lifespan, and figure on 5, even if they swear on the most precious thing to them, that it will only be 3). This is exceptionally important IMO, as data corruption is a major problem to fix. It also translates into an expensive undertaking, due to the man hours spent to recover the storage system as well as lost revenue due to a down system. Jobs tend to be lost over this sort of thing....

In the case you're asking about, OLTP or not, I've no idea what kind of load will be presented to the storage pool or how critical it is (had to make some assumptions @ 100 users). I wouldn't expect it to be that high in terms of IOPS (thinking that even though it's an OLTP, it's still more internal; users = humans on a keyboard).

But if each "user" is another server for example (think scaling up as you would with say an ATM network, each "user" being the main server for a state/province, you get the idea), the IOPS requirement will be significantly higher than if each user is an individual person entering data via a keyboard.

So I've kept to generalizations ATM.

the performance of SAS is quite remarkable compared to SATA I'll agree there, the price is nearly even justified

SAS is not only faster at IOPS, but they also tend to be more robust in terms of reliability as well (usually have better motors and servos running the mechanics than SATA models; for SATA, the increased MTBR ratings are a result of the sensors and firmware, not improved components - that is, they tend to have the same motors and servos as the consumer models of the same RPM ratings to reduce costs).

im trying to find a good comparison to compare these two, but am unable to find one - is it in that ananad article?

You can start there, but you'd also want to look up SATA and SAS enterprise disk reviews, as well as RAID card reviews (they can show what the IOPS are for those cards are for the tested configurations - gives a good idea of what the card can do, as well as the disk tech/models).

Tom's Hardware, Hardware Secrets, and Storage Review are good sites to look for this sort of information. But search out specific model numbers as well, and see if anything comes up.

what would you like to know? im not really sure what information to provide. basics are
- 100+ users during the day
- FileMaker 11 running on latest 2xMacPros. database is split onto 2 MacPros because of its size, 2nd mac pro in identical config
- 2x60GB SSDs in RAID0
- hourly backups of the entire database during business hours copied onto 2x60GB SSDs (see below for another inquiry)
- network usage at any given time on both machines is 20KB/s up to 500KB/s - fluctuations of 10MB/s in busy periods.
- disk activity follows a similar structure to network activity.
- read to write ratio is roughly 80% (read)-20% (write)
- anything else?

First off, you ought to be smacked for using a stripe set .

Get it off of those ASAP, as it's not only dangerous, it's not suited for small files (think random access performance). You'd be better off either running a level 10 or at least a RAID 5 on the right controller for your primary data (i.e. either Areca or ATTO 6.0Gb/s model). In the past, level 10 was the way to go with relational databases, but that's changing due to newer RAID cards. Now parity based levels are viable alternatives (not exactly cheap by consumer standards, but this doesn't seem to be a consumer system, and is warranted in this case).

Now given an n = 1 configuration for the servers you're working with, you really need to be running some form of redundancy for the OS as well as the data (totally stupid not to IMO, as the stripe set is an extremely weak spot as it's configured right now - backed up or not).

So use a RAID 1 for the OS/applications (attached to the ICH), and get the data on 10 if you're going to skip a RAID controller. 10 or parity based if you do get one, which I'd recommend for the IOPS performance that can be generated with higher queue depths.

I can't say this enough; I'd strongly recommend a RAID controller (see backup as to why, but it has relevance to expansion for the primary array for both capacity and IOPS load for the primary data as well).

The OCZ disks should be fine for an OS/applications array, as they're primarily read.

BTW, based on ~90 IOPS for SATA, 4x in a 10 configuration will be enough from what you've posted (consider this the bare minimum). But it will be near the limit (means you won't really be able to add users without bottlenecking). Either placing it on a RAID controller or using said controller to implement a different level (i.e. RAID 5), will improve matters. So will adding disks, which is possible this way (ICH is limited, and tops out lower). Splitting the RAID 1 to the ICH and the primary and backup duties to a RAID controller will improve dataflow as well (significantly once you go past a few disks).

• The capacity requirements seem low, but what kind of capacity growth is expected?
• How long is it to be in service?
• How many users will be added over this time frame?

This will allow you to figure out both the size of the card and disks to be used for the intended service life (allows you to handle expected growth without having to reconfigure the entire system).

onto my 2nd question, now that the main storage is sorted - the hourly backups are also very important for obviously backing up. the speed at which this backup runs is of utmost important, because the entire database is taken offline by Filemaker for the few minutes that it runs. currently it is 2x60GB OCZ Agility SSDs in RAID0. i have monitored performance of them, and its quite terrible. is it possible for these SLC drives to be effected by write amplification? or is that just MLC?

Write Amplification is relevant to SLC as well as MLC (present with any form of NAND Flash).

BTW, the OCZ Agility disks are MLC based, not SLC (I'm assuming these disks are for the primary data as well as backup use = picked up 4x and built a pair of stripe sets). Not only is this the wrong type of NAND Flash to be using for this purpose (enterprise use), they're not designed for high IOPS.

in the real world i observed, 155.5MB/s peak data transmission overall. fluctuates between 40MB/s and 150MB/s read. 30MB/s and 160MB/s write. average of roughly 100MB/s read/write. large fluctuations towards the end, indicates high amount of fragmentation (write overhead?). backup took 3mins and 11 seconds.

I looking at the 155.5MB/s as the worst case combined throughput (see above for configurations). If this isn't correct, let me know, as it will mean changing the number of disks, and perhaps the level used. It may also have bearing as to the port count on a RAID card.

so this indicates 3minutes of downtime every hour for a daily backup. over the period of the day (11 backups) that is basically 33minutes of downtime. the backup size is roughly 40GB each. i think i require the best and most optimal sequential write speeds onto this volume. ideas?

As mentioned, a stripe set isn't the best way to go about this. Given it's a database, the records are almost certainly small, so this is more along the lines of random access, not sequential (betting you've a lot of unbalanced stripes on those disks, because the files fit into one block; it also wastes space).

The idea with the RAID card, is to have a primary and backup array on the same card (they don't have to be identical, but it's not a bad idea; you want the backup as fast as the primary in this case, as it seems you need to minimize your down-time).

So you're looking at 8 ports minimum @ 2 * 4 disk level 10 arrays (i.e. ARC-1880i up to an ARC-1880ix24; 1880 page). For increased users (IOPS), capacity, or both, you'll want more ports than that (I like at least an additional 4 for expansion purposes). This will mean getting an external SAS enclosure and using the proper cable to connect it to the card.

This will get your backup at the same speed as the primary array, so backups will be as quick as possible (based on the write time of the configuration).

 

[DoFoT9]

It all comes down to the IOPS.

Take the following into consideration (from Wiki's IOPS page - yes, I'm being lazy tonight ):

​

This is where a controller with the best drives suited for the task makes a significant difference.

Another little tidbit from the same page (specifically on the Intel X-25E):

​

This is rather nice, but you also pay for it.

so, in saying all of that - 90 IOPS vs ~4,000 is a MASSIVE difference - if size wasnt the main objective here, and responsiveness was, why would you go for the mechanical hard drives? your point on data recovery/availability is duly noted though

Another thing to keep in mind in terms of write wear:

• Enterprise mechanical (SATA or SAS) = 1E15 bit error rating
• SLC Flash = 1E5

i am not familiar with write wear - is this the amount of bits that can be written totally to the drive? or the amount of errors it can handle? GOOGLE didnt really help me much.

Granted, wear leveling can help with SLC. But if the drive's are filled, there's less additional capacity for this, and it will increase the wear (write amplification = decreases the disk's lifespan). This can be particularly important in the enterprise realm, as the typical planning cycle for storage systems is 3 years. But budgetary restrictions/trepidation over major tech expenditures can push that to 5 years or so. So SLC may not be able to make it if there's insufficient unused capacity over the disks' lifespan (means you have to make sure that there's sufficient n disks to be sure there will be unused capacity over it's entire intended lifespan, and figure on 5, even if they swear on the most precious thing to them, that it will only be 3). This is exceptionally important IMO, as data corruption is a major problem to fix. It also translates into an expensive undertaking, due to the man hours spent to recover the storage system as well as lost revenue due to a down system. Jobs tend to be lost over this sort of thing....

*writes notes*

our budget is rather extravagant - its only been 1.5years since the previous upgrade and we have the go ahead to upgrade further, given how important the database is for the business and its speed even more so (redundancy being the highest thing of importance).

write amplification can happen on SLC, i forgot about that - it's because each cell must be erased before it is rewritten to again.

In the case you're asking about, OLTP or not, I've no idea what kind of load will be presented to the storage pool or how critical it is (had to make some assumptions @ 100 users). I wouldn't expect it to be that high in terms of IOPS (thinking that even though it's an OLTP, it's still more internal; users = humans on a keyboard).

im not fully certain how to get some IOPS readings for you on the actual database in terms of throughput. usage never really goes above a few MB/s even at the busiest of times, so it's not very demanding in that regard. the database is only accessed internally over the gigabit network, and all users are humans (except for the database guys which run reports).

But if each "user" is another server for example (think scaling up as you would with say an ATM network, each "user" being the main server for a state/province, you get the idea), the IOPS requirement will be significantly higher than if each user is an individual person entering data via a keyboard.

So I've kept to generalizations ATM.

ahh yeh, none of that.

You can start there, but you'd also want to look up SATA and SAS enterprise disk reviews, as well as RAID card reviews (they can show what the IOPS are for those cards are for the tested configurations - gives a good idea of what the card can do, as well as the disk tech/models).

Tom's Hardware, Hardware Secrets, and Storage Review are good sites to look for this sort of information. But search out specific model numbers as well, and see if anything comes up.

googling my ass off now thanks nano.

First off, you ought to be smacked for using a stripe set .

i didnt set it up! it was already set up when i came into the business, and unfortunately it looks like it will stay that way!

Get it off of those ASAP, as it's not only dangerous, it's not suited for small files (think random access performance). You'd be better off either running a level 10 or at least a RAID 5 on the right controller for your primary data (i.e. either Areca or ATTO 6.0Gb/s model). In the past, level 10 was the way to go with relational databases, but that's changing due to newer RAID cards. Now parity based levels are viable alternatives (not exactly cheap by consumer standards, but this doesn't seem to be a consumer system, and is warranted in this case).

in a logical and reasonable world i would go for the Areca + 3 or 4 or 5 SAS mechanical drives for this scenario, and RAID5 them. the redundancy gives the most optimal uptime and best recovery abilities. unfortunately in this reality the chances of that happening arent high. my boss is still stuck in his ways that "RAID0 gave the fastest results 2 years ago when we tried them so we will stick with that now"

Now given an n = 1 configuration for the servers you're working with, you really need to be running some form of redundancy for the OS as well as the data (totally stupid not to IMO, as the stripe set is an extremely weak spot as it's configured right now - backed up or not).

2 servers, they both roughly hold half the database each. the main server has hourly backups, and a daily backup, then weekly after that, and also a monthly. the 2nd server has daily backups, weekly then also monthly (n.b. no hourly).

stupid, right?

the OS is housed on 1 60GB SSD each, no redundancy, no backup of OS.

stupid, right?

*facepalm*

So use a RAID 1 for the OS/applications (attached to the ICH), and get the data on 10 if you're going to skip a RAID controller. 10 or parity based if you do get one, which I'd recommend for the IOPS performance that can be generated with higher queue depths.

RAID1 certainly for the OS, would RAID10 or RAID5 be more optimal in the sense of the overall schema? (redundancy, reliability, speed, responsiveness etc.)

I can't say this enough; I'd strongly recommend a RAID controller (see backup as to why, but it has relevance to expansion for the primary array for both capacity and IOPS load for the primary data as well).

RAID5 + apple RAID card = win? (kidding). it would most certainly be the best upgrade, and it allows for future expandability - even to different systems and whatnot.

The OCZ disks should be fine for an OS/applications array, as they're primarily read.

BTW, based on ~90 IOPS for SATA, 4x in a 10 configuration will be enough from what you've posted (consider this the bare minimum). But it will be near the limit (means you won't really be able to add users without bottlenecking). Either placing it on a RAID controller or using said controller to implement a different level (i.e. RAID 5), will improve matters. So will adding disks, which is possible this way (ICH is limited, and tops out lower). Splitting the RAID 1 to the ICH and the primary and backup duties to a RAID controller will improve dataflow as well (significantly once you go past a few disks).

yeh i agree there, i dont really want to use nor trust ICH in an enterprise scenario. do you think thats wise?

• The capacity requirements seem low, but what kind of capacity growth is expected?

the database is increasing roughly 1GB per month, currently around 48GB in total size.

• How long is it to be in service?

the database or the drives? database, FOREVER (). the drives, i would say 2 years maximum.

• How many users will be added over this time frame?

over 2 years, at this current rate - you would expect roughly 20 to 30.

so over the time frame, you would expect it to increase to say, 70GB. still quite small.

Write Amplification is relevant to SLC as well as MLC (present with any form of NAND Flash).

yup yup - im slowly remembering

BTW, the OCZ Agility disks are MLC based, not SLC (I'm assuming these disks are for the primary data as well as backup use = picked up 4x and built a pair of stripe sets). Not only is this the wrong type of NAND Flash to be using for this purpose (enterprise use), they're not designed for high IOPS.

correct, they are now MLC, but the models we have from 2 years ago are SLC (it says so on the box). haha.

so MLC is a bad idea... hmmmm

I looking at the 155.5MB/s as the worst case combined throughput (see above for configurations). If this isn't correct, let me know, as it will mean changing the number of disks, and perhaps the level used. It may also have bearing as to the port count on a RAID card.

this was the combined throughput for the RAID0 on an hourly backup yes, seems quite low doesnt it?

As mentioned, a stripe set isn't the best way to go about this. Given it's a database, the records are almost certainly small, so this is more along the lines of random access, not sequential (betting you've a lot of unbalanced stripes on those disks, because the files fit into one block; it also wastes space).

32K block sizes on the disks, not sure how the database reads in data in the block sense.

The idea with the RAID card, is to have a primary and backup array on the same card (they don't have to be identical, but it's not a bad idea; you want the backup as fast as the primary in this case, as it seems you need to minimize your down-time).

So you're looking at 8 ports minimum @ 2 * 4 disk level 10 arrays (i.e. ARC-1880i up to an ARC-1880ix24; 1880 page). For increased users (IOPS), capacity, or both, you'll want more ports than that (I like at least an additional 4 for expansion purposes). This will mean getting an external SAS enclosure and using the proper cable to connect it to the card.

This will get your backup at the same speed as the primary array, so backups will be as quick as possible (based on the write time of the configuration).

and SAS drives with this i presume?

so $265Aus will get a 73GB SAS Cheetah drive, $1,201Aus for the 1880i - total of $3,321.

reasonable for piece of mind, imo.

edit: RAID0 SSD looks to be going ahead, those original drives that i suggested. not much that i can do about that, im just the junior

 

[nanofrog]

so, in saying all of that - 90 IOPS vs ~4,000 is a MASSIVE difference - if size wasnt the main objective here, and responsiveness was, why would you go for the mechanical hard drives? your point on data recovery/availability is duly noted though

If high IOPS were required, and either capacity was a distant second, and/or there's more than enough funding, I'd go with SLC based SSD's, or better yet, a solution using SLC based Flash drives (unfortunately, there aren't any that work in an OS X environment AFAIK, and I checked a week or so ago).

But in most cases, you have to strike a balance between IOPS, capacity, and budget, which usually means mechanical disks (i.e. meets all the requirements, not shaving anywhere, so long as the budget is realistic).

What kills you with SLC based solutions, is the cost/GB, particularly when the capacity requirements are large.

i am not familiar with write wear - is this the amount of bits that can be written totally to the drive? or the amount of errors it can handle? GOOGLE didn't really help me much.

A NAND Flash cell has a limited number of times it can be written to. After that, it's dead.

The number published by the NAND Flash manufacturer is what the 1E5 represents (doesn't take into account things like wear leveling techniques that may be used by SSD disk makers). Another important note IMO, SSD makers determine their numbers based on the best 90% of cells, not all of them, nor are their testing methods based on real world conditions.

our budget is rather extravagant - its only been 1.5years since the previous upgrade and we have the go ahead to upgrade further, given how important the database is for the business and its speed even more so (redundancy being the highest thing of importance).

The solution above is valid (some tweaking can be done), as it will help with both the performance limitations that have been exposed, as well as provide redundancy which is critical for servers.

Whoever set this up was an idiot. RAID 0 for primary storage in a high availability server....

write amplification can happen on SLC, i forgot about that - it's because each cell must be erased before it is rewritten to again.

This is present with any form of NAND Flash, so it's not just limited to SLC. MLC is affected as well, but as the write cycle limit is lower (typically by a factor of 10), it's in even greater danger.

This is why SLC is used for enterprise storage when a NAND Flash solution is needed.

im not fully certain how to get some IOPS readings for you on the actual database in terms of throughput. usage never really goes above a few MB/s even at the busiest of times, so it's not very demanding in that regard. the database is only accessed internally over the gigabit network, and all users are humans (except for the database guys which run reports).

You could run either the sar or iostat command via the Command Line. You should also be able to access this information in the Activity Monitor. I'm not sure if there's any 3rd party software, let alone that might have a nicer GUI appearance (might be worth a look if the following doesn't work well for you).

Examples: (general, from Linux; source)

# sar -d 1 5
Linux 2.4.21-27.ELsmp (pw101) 12/04/2005

06:33:54 PM DEV tps rd_sec/s wr_sec/s
06:33:55 PM dev8-0 0.00 0.00 0.00
06:33:55 PM dev8-16 0.00 0.00 0.00
06:33:55 PM dev8-32 0.00 0.00 0.00
06:33:55 PM dev8-48 0.00 0.00 0.00
06:33:55 PM dev8-64 0.00 0.00 0.00
06:33:55 PM dev8-65 0.00 0.00 0.00
06:33:55 PM dev8-66 0.00 0.00 0.00


# iostat 1 3
Linux 2.4.21-27.ELsmp (pw101) 12/04/2005

avg-cpu: %user %nice %sys %iowait %idle
7.14 0.00 4.53 0.01 88.32

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.23 1066 2377572
sdb 0.01 0.39 0.00 3941054 118
sdc 0.00 0.23 0.00 2364386 16
sdd 0.00 0.00 0.00 24 0
sde 0.35 0.09 6.88 933722 70340208
sde1 0.35 0.09 6.88 933218 70340208
sde2 0.00 0.00 0.00 280 0
If '%idle' goes below 20%, the system maybe queuing up disk I/Os and response time suffers.
'1 5' and '1 3' parameters are intervals and iterations (e.g., 1-second interval 5 iterations).​

OS X Example can be found here (iostat -w1). Please note that this doesn't stop until you hit Control+C.

googling my ass off now thanks nano.

You're quite welcome (imagine a nice evil grin with this).

i didn't set it up! it was already set up when i came into the business, and unfortunately it looks like it will stay that way!

Then smack the person who did... You can tell them you're acting as my proxy.

Ultimately, if they're not willing to change, then there's really nothing you can do, and all of this is a waste of time. Seriously.

I presume you don't have access to a test bed system or any discretionary budget (for a decent RAID card and drives to show performance and demonstrate redundancy) to show them what's possible either (as a logical argument isn't likely to convince them, given your indication of stubbornness about changing the existing configuration).

in a logical and reasonable world i would go for the Areca + 3 or 4 or 5 SAS mechanical drives for this scenario, and RAID5 them. the redundancy gives the most optimal uptime and best recovery abilities. unfortunately in this reality the chances of that happening aren't high. my boss is still stuck in his ways that "RAID0 gave the fastest results 2 years ago when we tried them so we will stick with that now"

This type of person has to be shown, and even then, that may not work.

As per running RAID 5, you'd need to run it with a hot spare. Another alternative is RAID 6 (n = 2 failover like 10, but makes more capacity available as you scale up, and performance is increased as well). At any rate, you'd want to run a hot spare regardless of the level chosen IMO (will automatically begin a rebuild in the event of a failure, and this is beyond critical when there's no one there to fix a problem, such as overnight or a weekend).

2 servers, they both roughly hold half the database each. the main server has hourly backups, and a daily backup, then weekly after that, and also a monthly. the 2nd server has daily backups, weekly then also monthly (n.b. no hourly).

stupid, right?

Yes it is.

the OS is housed on 1 60GB SSD each, no redundancy, no backup of OS.

stupid, right?

Again, Yes.

RAID1 certainly for the OS, would RAID10 or RAID5 be more optimal in the sense of the overall schema? (redundancy, reliability, speed, responsiveness etc.)

See above.

As I mentioned before, in the past, a level 10 would have been the way to go. But with newer RAID cards, parity based levels have become a viable alternative without the capacity waste (can still get n = 2 by using RAID 6).

yeh i agree there, i dont really want to use nor trust ICH in an enterprise scenario. do you think thats wise?

Using the ICH in most cases means ICHxR, which contains a hardware RAID controller (albeit simple, inexpensive one).

In the case of a standard ICH (no RAID on a Chip), it's not ideal. But it's better than what's being done right now (compromise over a presumption of an insufficient budget for the system's use).

Assuming you can convince the person/s in charge to make changes, get the RAID 1 on a proper RAID controller (even if it means getting more ports to do it, as it's well worth it).

the database is increasing roughly 1GB per month, currently around 48GB in total size.

Quite small.

the database or the drives? database, FOREVER (). the drives, i would say 2 years maximum.

All of it will need to be replaced at some point, as it will fail (matter of when, not if).

over 2 years, at this current rate - you would expect roughly 20 to 30.

So figure out the IOPS per user, multiply the expected number of those to be added, then add that to the current IOPS figures.

That's the performance number you need to plan around.

this was the combined throughput for the RAID0 on an hourly backup yes, seems quite low doesn't it?

It is, but it's due to the fact a stripe set isn't meant for what it's being used for (meant for large sequential files, and a database isn't made up of large sequential files by any means).

You need small file performance, which other RAID levels are better at handling.

32K block sizes on the disks, not sure how the database reads in data in the block sense.

I expect 32k blocks are too big (4k is probably more along the lines of what's needed, and stripe sets suck at this, and that's before considering how dangerous it is).

Find out the avg. size of the records, and you can go from there (I'll help if needed).

and SAS drives with this i presume?

Again, given what you've described, SATA would suffice. But if you can get SAS, I'd do it (better at IOPS, as TCQ does a better job than NCQ used for SATA disks).

so $265Aus will get a 73GB SAS Cheetah drive, $1,201Aus for the 1880i - total of $3,321.

reasonable for piece of mind, imo.

It is.

edit: RAID0 SSD looks to be going ahead, those original drives that i suggested. not much that i can do about that, im just the junior

Find out what you'd need to do to change his/her mind, then go about getting it done.