altquark
Legendary Poster
RAID5 is bad. Really bad. I have an explanation of why below.
An EVA is exactly as you describe - but you carve up your drives based on multiple raid configurations, so its perfectly possible to have RAID10 and RAID5 on the same EVA. In effect, the EVA takes EVERY spindle in the physical array and spreads out your virtual array ! Very cool !
However, there are performance issues with using RAID5 - I know that JDE has a document that in their opinion states that the "difference is negligible" - but quite literally every customer operates completely different from what JDE Benchmarks - and realistically, I think JDE knows SQUAT about hardware when it comes to setting up architecture.
In a customer SQL Server configuration - I would set up the following SAN configuration :
CRPDATA - RAID5
JDECRPLOG - RAID5
JDEPRODDATA - RAID10
JDEPRODLOG - RAID10
JDESYSDATA - RAID10
JDESYSLOG - RAID10
JDETESTDATA - RAID5
JDETESTLOG - RAID5
QUORUM (for clustering) - RAID10
SQLSERVER (for TEMPDB, MASTER etc) - RAID10
I would do this so that it is easy to identify certain drive types for copying, administrating and managing. For example, I can copy the CRPDATA using a snapshot technology to TESTDTA using the above configuration.
Central objects resides in the JDESYSDATA along with OL, DD, Servermaps etc etc.
Now, as to SAN Cache size and ratios. In an EVA5000, each controller has 256Mb WRITE/512Mb READ cache sizes - and there are two controllers.
Your SQL Server buffer cache should be used at 99%, same as your procedure cache.
ok - now, there are some other numbers to be aware of as well - these came from Microsoft as recommended bottleneck analysis. The following are what each SHOULD be showing :
Physical Disk Avg Disk Sec/Read < 8ms
Physical Disk Avg Disk sec/Write < 1ms
Avg Disk Read Queue Length < 2*spindles
Avg Disk Write Queue Length < 2*spindles
Page Reads/Sec < 90
Page Writes/sec < 90
Free Pages < 640
Buffer Cache Hit Ratio > 90%
The biggest statistic - when it comes to disk performance - is going to be the disk latency number. The higher the latency, the WAAAY worse everything is going to be performance-wise.
Remember, RAID5 is always bad at writing - and the disk latency will increase because of this. Lets look at the reason why.
RAID5 is striping with distributed parity. RAID 5 comprises a logical volume, based on three or more disk drives, that generates data redundancy to avoid the loss of an entire volume in the event of disk failure. The RAID controller creates a special parity block for each stripe of information.
The parity is typically a binary exclusive OR (XOR) operation—indicated here with the ~ symbol—on all the data blocks of the stripe :
|A1|B1|C1|D1|S1|
|A2|B2|C2|S2|E2|
----------------
|A3|B3|S3|D3|E3| - Stripe
----------------
|A4|S4|C4|D4|E4|
|S5|B5|C5|D5|E5|
In the above diagram, the RAID controller calculates parity as S3 = A3 ~B3 ~D3 ~E3.
Now, when a write operation occurs on a RAID 5 volume, the controller must update parity block. Because the controller must read all the blocks in the stripe to recreate the parity block, most RAID 5 controllers will go through the following steps, in which single quotation marks and double quotation marks represent modifications:
1. Read the block that needs modification (B3).
2. Read the parity block (S3).
3. Remove the knowledge of block B3 from parity S3 (S3'=S3~B3).
4. Calculate the new parity (S3"=S3'~B3').
5. Update the data block (B3').
6. Update the parity block (S3").
In other words, one application I/O requires four disk I/Os, and these four I/Os occur on two spindles, potentially disturbing other transfer operations on those volumes.
If a RAID5 drive dies, then obviously the parity needs to be rebuilt. This extra load on the array means that the RAID5 volume will be significantly impacted.
Lastly - when it comes to a very highly utilized partition, then instead of plonking down tons of money - why not consider a Solid State Disk ? These have come down in price BIG time in recent years - I have a document on my website somewhere that shows that just by adding a solid state disk to an Oracle architecture can improve database performance by 30% ! The same can be seen with a SQL Server architecture too ! Given the fact that solid state drives are now in the sub-$1000 range for 32gb drives - everyone should be evaluating these nowadays ! Believe me, a SSD is nothing like having "cache" ! Your talking about a drive with 250 times faster access times than conventional disks ! I predict that the price will come down SO much, you'll start seeing SSD's on laptops - and we'll see database arrays just made up of SSD's. Since their manufacturers are stating reliable "225 years" before failure - trust me when I think this is the future for disk technology.
Jeff, if you're concerned - I can always help you guys out with a Performance Benchmark/Stresstest - you never know !
An EVA is exactly as you describe - but you carve up your drives based on multiple raid configurations, so its perfectly possible to have RAID10 and RAID5 on the same EVA. In effect, the EVA takes EVERY spindle in the physical array and spreads out your virtual array ! Very cool !
However, there are performance issues with using RAID5 - I know that JDE has a document that in their opinion states that the "difference is negligible" - but quite literally every customer operates completely different from what JDE Benchmarks - and realistically, I think JDE knows SQUAT about hardware when it comes to setting up architecture.
In a customer SQL Server configuration - I would set up the following SAN configuration :
CRPDATA - RAID5
JDECRPLOG - RAID5
JDEPRODDATA - RAID10
JDEPRODLOG - RAID10
JDESYSDATA - RAID10
JDESYSLOG - RAID10
JDETESTDATA - RAID5
JDETESTLOG - RAID5
QUORUM (for clustering) - RAID10
SQLSERVER (for TEMPDB, MASTER etc) - RAID10
I would do this so that it is easy to identify certain drive types for copying, administrating and managing. For example, I can copy the CRPDATA using a snapshot technology to TESTDTA using the above configuration.
Central objects resides in the JDESYSDATA along with OL, DD, Servermaps etc etc.
Now, as to SAN Cache size and ratios. In an EVA5000, each controller has 256Mb WRITE/512Mb READ cache sizes - and there are two controllers.
Your SQL Server buffer cache should be used at 99%, same as your procedure cache.
ok - now, there are some other numbers to be aware of as well - these came from Microsoft as recommended bottleneck analysis. The following are what each SHOULD be showing :
Physical Disk Avg Disk Sec/Read < 8ms
Physical Disk Avg Disk sec/Write < 1ms
Avg Disk Read Queue Length < 2*spindles
Avg Disk Write Queue Length < 2*spindles
Page Reads/Sec < 90
Page Writes/sec < 90
Free Pages < 640
Buffer Cache Hit Ratio > 90%
The biggest statistic - when it comes to disk performance - is going to be the disk latency number. The higher the latency, the WAAAY worse everything is going to be performance-wise.
Remember, RAID5 is always bad at writing - and the disk latency will increase because of this. Lets look at the reason why.
RAID5 is striping with distributed parity. RAID 5 comprises a logical volume, based on three or more disk drives, that generates data redundancy to avoid the loss of an entire volume in the event of disk failure. The RAID controller creates a special parity block for each stripe of information.
The parity is typically a binary exclusive OR (XOR) operation—indicated here with the ~ symbol—on all the data blocks of the stripe :
|A1|B1|C1|D1|S1|
|A2|B2|C2|S2|E2|
----------------
|A3|B3|S3|D3|E3| - Stripe
----------------
|A4|S4|C4|D4|E4|
|S5|B5|C5|D5|E5|
In the above diagram, the RAID controller calculates parity as S3 = A3 ~B3 ~D3 ~E3.
Now, when a write operation occurs on a RAID 5 volume, the controller must update parity block. Because the controller must read all the blocks in the stripe to recreate the parity block, most RAID 5 controllers will go through the following steps, in which single quotation marks and double quotation marks represent modifications:
1. Read the block that needs modification (B3).
2. Read the parity block (S3).
3. Remove the knowledge of block B3 from parity S3 (S3'=S3~B3).
4. Calculate the new parity (S3"=S3'~B3').
5. Update the data block (B3').
6. Update the parity block (S3").
In other words, one application I/O requires four disk I/Os, and these four I/Os occur on two spindles, potentially disturbing other transfer operations on those volumes.
If a RAID5 drive dies, then obviously the parity needs to be rebuilt. This extra load on the array means that the RAID5 volume will be significantly impacted.
Lastly - when it comes to a very highly utilized partition, then instead of plonking down tons of money - why not consider a Solid State Disk ? These have come down in price BIG time in recent years - I have a document on my website somewhere that shows that just by adding a solid state disk to an Oracle architecture can improve database performance by 30% ! The same can be seen with a SQL Server architecture too ! Given the fact that solid state drives are now in the sub-$1000 range for 32gb drives - everyone should be evaluating these nowadays ! Believe me, a SSD is nothing like having "cache" ! Your talking about a drive with 250 times faster access times than conventional disks ! I predict that the price will come down SO much, you'll start seeing SSD's on laptops - and we'll see database arrays just made up of SSD's. Since their manufacturers are stating reliable "225 years" before failure - trust me when I think this is the future for disk technology.
Jeff, if you're concerned - I can always help you guys out with a Performance Benchmark/Stresstest - you never know !
