What is the best RAID system to use in a SAN environment.
Is it ok to use RAID 5 on everything like data, log, etc
when using a SAN shared storage.In certain cases it may make sense to use other
configuration or use different raid levels for tempdb
(raid 0), log (raid 1+0), databases (raid 5) etc. Here you
have to be sure that you will be getting excellent
cooperation from the network/hardare support departments,
or if you are responsible for SAN and sql server.
Generally I would say it is ok to use raid 5 for
everything, because thats what I decided to use when we
configured SAN for sql server.
>--Original Message--
>What is the best RAID system to use in a SAN environment.
>Is it ok to use RAID 5 on everything like data, log, etc
>when using a SAN shared storage.
>.
>|||Every system has different requirements, but one is generally true - using
RAID 5 for logs is usually a bad idea because the parity calculation
requires additional overhead to read bits (disk i/o), parity calculation
(cpu, hba etc) & then the parity writes (more disk i/o).
Generally speaking, logs are far better off on a mirror, perhaps striped as
well, but not raid 5.
Regards,
Greg Linwood
SQL Server MVP
"Aboki" <waco361@.hotmail.com> wrote in message
news:13ac01c381e7$58753290$a401280a@.phx.gbl...
> What is the best RAID system to use in a SAN environment.
> Is it ok to use RAID 5 on everything like data, log, etc
> when using a SAN shared storage.
Showing posts with label san. Show all posts
Showing posts with label san. Show all posts
Friday, March 30, 2012
Wednesday, March 28, 2012
RAID Configuration - R10 v. R5 - Spindle Count
We are in the process of procuring a new IBM SAN for our most business
critical SQL database. The database right now runs great on a 10 disk
RAID 5 set with TEMPDB and TLOGS on separate RAID1 arrays. As a part
of the new hardware implementation, we want to go to RAID10 and as per
a vendor recommendation, break the database out into file groups on
separate physical disks in order to boost performance.
I keep getting hung up on spindle count. I have always subscribed to
"the more spinning heads the better". The flaw in this theory appears
to be as the smallest disk you can buy for a given solution gets larger
and larger , where is the trade off? Do you still stripe across as
many disks as possible and end up burning a lot of disk space? Does
the large amount of cache (4GB on our new system) decrease the number
of spindles needed?
Is there an "easy" way or rule of thumb that would allow me to
translate 10 disk wide RAID5 performance into X disk wide Raid 10
performance. In a nutshell, how can I estimate what the following gets
me with regard to reducing the number of spindles necessary:
1. Going to RAID10 from RAID 5
2. New solution has 4GB of cache / old solution had 512MB
If I go with the vendor recommendations for table placement in file
groups I will end up with something in the range of four (4) - two (2)
disk wide RAID 10 sets. The RAID 10 sets will actually encompass 4
disks, but only 2 will be useable for space and my understanding is
that only two (2) will be counted for parallel I/O performance. I am
nervous about how narrow these RAID 10 sets are but maybe it does not
matter as much?
As a side note, i have no good way other than what I can get through
Profiler to load test the new solution with actual production data.
Any insight/thoughts would be appreciated.
Thanks!
PaulPaul;
4GB of cache is unlikely to significantly decrease the number of spindles
you need to stripe across to get the performance. Very large cache size does
have an tendency to mask the need for more spindles. But that really depends
on the workloads (on whether the workloads can take advantage of that cache).
> Is there an "easy" way or rule of thumb that would allow me to
> translate 10 disk wide RAID5 performance into X disk wide Raid 10
> performance.
There is commonly known RAID formula for doing this estimate. Assume that
the read:write ratio of the workload is 3:1--a very typical ratio, and assume
that you are using 15,000rpm disks, which can roughly do 180 IOs per second
(IOps).
RAID 5: Since each write needs 4 disk I/Os and eahc read needs one disk I/O,
the I/O penalty is 4/(3+4) = 0.57
RAID 10: Since each write needs two disk I/Os and each read needs one,
the I/O penalty is 4/(3+2) = 0.80
For 10-disk RAID 5, you can do 180 * 0.57 * 10 = 1026 IOps.
For the RAID 10 to do 1026 IOps, you need 1026/(180 *0.80) ~= 8 disks
Of course, this is just a theoretical rough estimate with many factors
absent. For instance, it doesn't consider the effect of the SAN cache. But
it's safe to say that the vendor suggestion of 4 disk RAID 10 is unlikely to
cut it (unless there is anyting specific to the workload of your app).
Running application-specific benechmark is important to verify whether the
disk config is adequate. However, you can also use disk performance tools
such as IOMeter or sqlio.exe to specifically examine the performance of your
disk subsystem outside of SQL Server. I would run sqlio.exe whenever I get a
new storage so that I know what storage performance to expect, and have data
for later comparison when needed.
In general, it's far better and simpler to just stripe across as many disks
as you can (within the disk subsystem limits such as controller throughput).
Linchi
"Paul" wrote:
> We are in the process of procuring a new IBM SAN for our most business
> critical SQL database. The database right now runs great on a 10 disk
> RAID 5 set with TEMPDB and TLOGS on separate RAID1 arrays. As a part
> of the new hardware implementation, we want to go to RAID10 and as per
> a vendor recommendation, break the database out into file groups on
> separate physical disks in order to boost performance.
> I keep getting hung up on spindle count. I have always subscribed to
> "the more spinning heads the better". The flaw in this theory appears
> to be as the smallest disk you can buy for a given solution gets larger
> and larger , where is the trade off? Do you still stripe across as
> many disks as possible and end up burning a lot of disk space? Does
> the large amount of cache (4GB on our new system) decrease the number
> of spindles needed?
> Is there an "easy" way or rule of thumb that would allow me to
> translate 10 disk wide RAID5 performance into X disk wide Raid 10
> performance. In a nutshell, how can I estimate what the following gets
> me with regard to reducing the number of spindles necessary:
> 1. Going to RAID10 from RAID 5
> 2. New solution has 4GB of cache / old solution had 512MB
> If I go with the vendor recommendations for table placement in file
> groups I will end up with something in the range of four (4) - two (2)
> disk wide RAID 10 sets. The RAID 10 sets will actually encompass 4
> disks, but only 2 will be useable for space and my understanding is
> that only two (2) will be counted for parallel I/O performance. I am
> nervous about how narrow these RAID 10 sets are but maybe it does not
> matter as much?
> As a side note, i have no good way other than what I can get through
> Profiler to load test the new solution with actual production data.
> Any insight/thoughts would be appreciated.
> Thanks!
> Paul
>|||Just to clarify, the vendor's recommendation would leave me with 4
separate RAID 10 sets, each of which would be two (2) disks wide. So I
would have a total of eight (8) disks with different tables assigned to
each RAID set via file groups.
I guess I am trying to determine whether it is worth my time to try and
break this thing out into file groups to separate specific tables onto
different RAID sets, therefore isolating I/O, or simply stripe across
as many disks as I can in a newly built RAID 10 array. The obvious
problem with breaking the tables out across multiple RAID sets, is that
I have no idea if the I/O generated by table X will be supported on a 2
disk wide, R10 array.
I agree that the simpler approach would be to simply stripe across as
many disks as possible. Not only would I have the benefit of R10 over
R5, but spindle count would not be an issue.
So Linchi, we could also use your formula to determine how a new 24
disk (12 useable) R10 array would compare to the existing 10 disk R5
array?
Paul|||Just to clarify, the vendor's recommendation would leave me with 4
separate RAID 10 sets, each of which would be two (2) disks wide. So I
would have a total of eight (8) disks with different tables assigned to
each RAID set via file groups.
I guess I am trying to determine whether it is worth my time to try and
break this thing out into file groups to separate specific tables onto
different RAID sets, therefore isolating I/O, or simply stripe across
as many disks as I can in a newly built RAID 10 array. The obvious
problem with breaking the tables out across multiple RAID sets, is that
I have no idea if the I/O generated by table X will be supported on a 2
disk wide, R10 array.
I agree that the simpler approach would be to simply stripe across as
many disks as possible. Not only would I have the benefit of R10 over
R5, but spindle count would not be an issue.
So Linchi, we could also use your formula to determine how a new 24
disk (12 useable) R10 array would compare to the existing 10 disk R5
array?
Paul|||If your database was running great on the Raid5 then what basis does the
vendor have to warrant splitting it up? While there are times when
splitting up tables, indexes etc. onto separate arrays will boost
performance you need to know you are doing the right thing. Have you done
any analysis that indicates this will help performance? You are probably
better off making a large RAID 10 and put all the files you now have ont he
Raid 5 on it. Keeping the Logs and Tempdb on their arrays either raid 1 or
10. If you don't know the capacity of the 4 disk Raid 10's and how much I/O
you will have for each you are more likely to make a bottleneck.
--
Andrew J. Kelly SQL MVP
"Paul" <ptimmerm@.gmail.com> wrote in message
news:1149023773.865667.104550@.g10g2000cwb.googlegroups.com...
> Just to clarify, the vendor's recommendation would leave me with 4
> separate RAID 10 sets, each of which would be two (2) disks wide. So I
> would have a total of eight (8) disks with different tables assigned to
> each RAID set via file groups.
> I guess I am trying to determine whether it is worth my time to try and
> break this thing out into file groups to separate specific tables onto
> different RAID sets, therefore isolating I/O, or simply stripe across
> as many disks as I can in a newly built RAID 10 array. The obvious
> problem with breaking the tables out across multiple RAID sets, is that
> I have no idea if the I/O generated by table X will be supported on a 2
> disk wide, R10 array.
> I agree that the simpler approach would be to simply stripe across as
> many disks as possible. Not only would I have the benefit of R10 over
> R5, but spindle count would not be an issue.
> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
> Paul
>|||Andrew,
These all are very good points. Thank you for raising them. The
recommendation for breaking the database up is based solely on their
poor design. 7 tables (including indexes) in their database make up
75% of the size of the DB. The DB is approximately 200GB. These
tables and a few others (not so large) contain 50 - 200 million records
a piece. It is not until a later release (a couple of years down the
road) that these tables are broken out into 6 or 7 "rolled up" tables.
Given the growth rate, many customers with minimum spec hardware (of
which we are not one) begin to see serious I/O problems that are
"resolved" by placing these tables, and others, on their own dedicated
RAID sets. As I continue to discuss this with others, I am leaning
more towards the large RAID10 array. I could still implement a
multiple data file structure in case we needed to make some moves down
the road, but for now stripe all of the files across the one large
RAID10. FYI... RAID 10 was my decision, not theirs. We will get a
performance bump from going to RAID10, which on top of the abundance of
cache and brand new hardware, should make for a very high performance
system. I am just looking for some way to quantify all of this.
Management likes numbers and statistics.
Another good point of your leads me to a specific question..... Is
there any way for me to measure I/O per database object? Is there any
way for me to estimate how much I/O would be hitting a given RAID set
if I know what tables will be located there?
Thoughts/ideas?
Paul|||Paul wrote:
> Andrew,
> These all are very good points. Thank you for raising them. The
> recommendation for breaking the database up is based solely on their
> poor design. 7 tables (including indexes) in their database make up
> 75% of the size of the DB. The DB is approximately 200GB. These
> tables and a few others (not so large) contain 50 - 200 million records
> a piece. It is not until a later release (a couple of years down the
> road) that these tables are broken out into 6 or 7 "rolled up" tables.
> Given the growth rate, many customers with minimum spec hardware (of
> which we are not one) begin to see serious I/O problems that are
> "resolved" by placing these tables, and others, on their own dedicated
> RAID sets. As I continue to discuss this with others, I am leaning
> more towards the large RAID10 array. I could still implement a
> multiple data file structure in case we needed to make some moves down
> the road, but for now stripe all of the files across the one large
> RAID10. FYI... RAID 10 was my decision, not theirs. We will get a
> performance bump from going to RAID10, which on top of the abundance of
> cache and brand new hardware, should make for a very high performance
> system. I am just looking for some way to quantify all of this.
> Management likes numbers and statistics.
> Another good point of your leads me to a specific question..... Is
> there any way for me to measure I/O per database object? Is there any
> way for me to estimate how much I/O would be hitting a given RAID set
> if I know what tables will be located there?
> Thoughts/ideas?
> Paul
>
Hi Paul
You don't mention anything about your READ/WRITE ratio. If you have far
more reads than writes, it could be that you'd be better off with a RAID
5 array. We have been through the same thoughts for some time ago and
ended up with a 24 disk RAID 5 array. I can't remember the exact
figures, but in our database we have something like 90 % read time so we
where really after a solution that could give a good read performance.
We talked with various storage experts and they more or less all agreed
that a RAID 5 array would give better read performance than a RAID10
assumed we used the same number of disks. That leaves us with a 1,5 TB
array where we're only using approx. 150 GB so there're a lot of "waste"
of space but that doesn't really matter.
We haven't tested the various solutions so actually we don't know if our
RAID 5 array performs better of worse than if we had a RAID 10 array
with the same number of disks.
Regards
Steen|||Linchi Shea wrote:
> Paul;
> 4GB of cache is unlikely to significantly decrease the number of spindles
> you need to stripe across to get the performance. Very large cache size does
> have an tendency to mask the need for more spindles. But that really depends
> on the workloads (on whether the workloads can take advantage of that cache).
>> Is there an "easy" way or rule of thumb that would allow me to
>> translate 10 disk wide RAID5 performance into X disk wide Raid 10
>> performance.
> There is commonly known RAID formula for doing this estimate. Assume that
> the read:write ratio of the workload is 3:1--a very typical ratio, and assume
> that you are using 15,000rpm disks, which can roughly do 180 IOs per second
> (IOps).
> RAID 5: Since each write needs 4 disk I/Os and eahc read needs one disk I/O,
> the I/O penalty is 4/(3+4) = 0.57
> RAID 10: Since each write needs two disk I/Os and each read needs one,
> the I/O penalty is 4/(3+2) = 0.80
> For 10-disk RAID 5, you can do 180 * 0.57 * 10 = 1026 IOps.
> For the RAID 10 to do 1026 IOps, you need 1026/(180 *0.80) ~= 8 disks
>
Hi Linchi
Do you have any links to this formula/calculation?
--
Regards
Steen Schlüter Persson
DBA|||There is no need to find any link to see how this formula works. Here's how.
Again assume the read:write ratio is 3:1 (or any other ratio you may fancy),
and assume that the total number of I/Os per second submitted to the RAID
device is Total_raid_iops. Hence,
The total number of writes per second = Total_raid_iops * 1/4, and
The total number of reads per second = Total_raid_iops * 3/4
For RAID 10, at the individual disk level, the total number of I/Os per
second for all the disks inside the RAID device are as follows:
The total number of writes per second = Total_raid_iops * 1/4 * 2
The total number of reads per second = Total_raid_iops *3/4 * 1
And
The grand total number of I/Os per second at the disk level
= (Total_raid_iops * 1/4 * 2 + Total_raid * 3/4 * 1)
= Total_raid_iops * (2/4 + 3/4)
= Total_raid_iops * 5/4
Given that a 15,000rmp disk can do about 180 I/Os per second, we have the
following:
Total_raid_iops * 5/4 = 180 * Number_of_disks
So if you know how many I/Os per second you want the RAID 10 device to do,
you can determine how many disks you need in this RAID 10 device, or if you
know the number of disks already in a RAID 10 device, you can determine how
many I/Os per second this device can do given the assumptions on write:read
ratio and the disk rotation speed.
Linchi
"Steen Persson (DK)" wrote:
> Linchi Shea wrote:
> > Paul;
> >
> > 4GB of cache is unlikely to significantly decrease the number of spindles
> > you need to stripe across to get the performance. Very large cache size does
> > have an tendency to mask the need for more spindles. But that really depends
> > on the workloads (on whether the workloads can take advantage of that cache).
> >
> >> Is there an "easy" way or rule of thumb that would allow me to
> >> translate 10 disk wide RAID5 performance into X disk wide Raid 10
> >> performance.
> >
> > There is commonly known RAID formula for doing this estimate. Assume that
> > the read:write ratio of the workload is 3:1--a very typical ratio, and assume
> > that you are using 15,000rpm disks, which can roughly do 180 IOs per second
> > (IOps).
> >
> > RAID 5: Since each write needs 4 disk I/Os and eahc read needs one disk I/O,
> > the I/O penalty is 4/(3+4) = 0.57
> > RAID 10: Since each write needs two disk I/Os and each read needs one,
> > the I/O penalty is 4/(3+2) = 0.80
> >
> > For 10-disk RAID 5, you can do 180 * 0.57 * 10 = 1026 IOps.
> > For the RAID 10 to do 1026 IOps, you need 1026/(180 *0.80) ~= 8 disks
> >
> Hi Linchi
> Do you have any links to this formula/calculation?
> --
> Regards
> Steen Schlüter Persson
> DBA
>|||> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
Yes, but I wouldn't want to bet my house the results. I trust the results
from controlled tests much better. As mentioned before, I'd use a tool such
as sqlio.exe or IOmeter to profile each RAID configuration. It is not an
extraordinary request to ask your SA or storage folks to give you the two
configurations for you to test. If the system is important, make a case to
your management to allow time for these tests. That would be time much better
spent than dwelling on theoretical estimates.
Once you have the solid test results, you can much better confront (okay
discuss with) your vendor with those numbers and ask them to justify their
recommendations in light of the test results.
Linchi
"Paul" wrote:
> Just to clarify, the vendor's recommendation would leave me with 4
> separate RAID 10 sets, each of which would be two (2) disks wide. So I
> would have a total of eight (8) disks with different tables assigned to
> each RAID set via file groups.
> I guess I am trying to determine whether it is worth my time to try and
> break this thing out into file groups to separate specific tables onto
> different RAID sets, therefore isolating I/O, or simply stripe across
> as many disks as I can in a newly built RAID 10 array. The obvious
> problem with breaking the tables out across multiple RAID sets, is that
> I have no idea if the I/O generated by table X will be supported on a 2
> disk wide, R10 array.
> I agree that the simpler approach would be to simply stripe across as
> many disks as possible. Not only would I have the benefit of R10 over
> R5, but spindle count would not be an issue.
> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
> Paul
>
critical SQL database. The database right now runs great on a 10 disk
RAID 5 set with TEMPDB and TLOGS on separate RAID1 arrays. As a part
of the new hardware implementation, we want to go to RAID10 and as per
a vendor recommendation, break the database out into file groups on
separate physical disks in order to boost performance.
I keep getting hung up on spindle count. I have always subscribed to
"the more spinning heads the better". The flaw in this theory appears
to be as the smallest disk you can buy for a given solution gets larger
and larger , where is the trade off? Do you still stripe across as
many disks as possible and end up burning a lot of disk space? Does
the large amount of cache (4GB on our new system) decrease the number
of spindles needed?
Is there an "easy" way or rule of thumb that would allow me to
translate 10 disk wide RAID5 performance into X disk wide Raid 10
performance. In a nutshell, how can I estimate what the following gets
me with regard to reducing the number of spindles necessary:
1. Going to RAID10 from RAID 5
2. New solution has 4GB of cache / old solution had 512MB
If I go with the vendor recommendations for table placement in file
groups I will end up with something in the range of four (4) - two (2)
disk wide RAID 10 sets. The RAID 10 sets will actually encompass 4
disks, but only 2 will be useable for space and my understanding is
that only two (2) will be counted for parallel I/O performance. I am
nervous about how narrow these RAID 10 sets are but maybe it does not
matter as much?
As a side note, i have no good way other than what I can get through
Profiler to load test the new solution with actual production data.
Any insight/thoughts would be appreciated.
Thanks!
PaulPaul;
4GB of cache is unlikely to significantly decrease the number of spindles
you need to stripe across to get the performance. Very large cache size does
have an tendency to mask the need for more spindles. But that really depends
on the workloads (on whether the workloads can take advantage of that cache).
> Is there an "easy" way or rule of thumb that would allow me to
> translate 10 disk wide RAID5 performance into X disk wide Raid 10
> performance.
There is commonly known RAID formula for doing this estimate. Assume that
the read:write ratio of the workload is 3:1--a very typical ratio, and assume
that you are using 15,000rpm disks, which can roughly do 180 IOs per second
(IOps).
RAID 5: Since each write needs 4 disk I/Os and eahc read needs one disk I/O,
the I/O penalty is 4/(3+4) = 0.57
RAID 10: Since each write needs two disk I/Os and each read needs one,
the I/O penalty is 4/(3+2) = 0.80
For 10-disk RAID 5, you can do 180 * 0.57 * 10 = 1026 IOps.
For the RAID 10 to do 1026 IOps, you need 1026/(180 *0.80) ~= 8 disks
Of course, this is just a theoretical rough estimate with many factors
absent. For instance, it doesn't consider the effect of the SAN cache. But
it's safe to say that the vendor suggestion of 4 disk RAID 10 is unlikely to
cut it (unless there is anyting specific to the workload of your app).
Running application-specific benechmark is important to verify whether the
disk config is adequate. However, you can also use disk performance tools
such as IOMeter or sqlio.exe to specifically examine the performance of your
disk subsystem outside of SQL Server. I would run sqlio.exe whenever I get a
new storage so that I know what storage performance to expect, and have data
for later comparison when needed.
In general, it's far better and simpler to just stripe across as many disks
as you can (within the disk subsystem limits such as controller throughput).
Linchi
"Paul" wrote:
> We are in the process of procuring a new IBM SAN for our most business
> critical SQL database. The database right now runs great on a 10 disk
> RAID 5 set with TEMPDB and TLOGS on separate RAID1 arrays. As a part
> of the new hardware implementation, we want to go to RAID10 and as per
> a vendor recommendation, break the database out into file groups on
> separate physical disks in order to boost performance.
> I keep getting hung up on spindle count. I have always subscribed to
> "the more spinning heads the better". The flaw in this theory appears
> to be as the smallest disk you can buy for a given solution gets larger
> and larger , where is the trade off? Do you still stripe across as
> many disks as possible and end up burning a lot of disk space? Does
> the large amount of cache (4GB on our new system) decrease the number
> of spindles needed?
> Is there an "easy" way or rule of thumb that would allow me to
> translate 10 disk wide RAID5 performance into X disk wide Raid 10
> performance. In a nutshell, how can I estimate what the following gets
> me with regard to reducing the number of spindles necessary:
> 1. Going to RAID10 from RAID 5
> 2. New solution has 4GB of cache / old solution had 512MB
> If I go with the vendor recommendations for table placement in file
> groups I will end up with something in the range of four (4) - two (2)
> disk wide RAID 10 sets. The RAID 10 sets will actually encompass 4
> disks, but only 2 will be useable for space and my understanding is
> that only two (2) will be counted for parallel I/O performance. I am
> nervous about how narrow these RAID 10 sets are but maybe it does not
> matter as much?
> As a side note, i have no good way other than what I can get through
> Profiler to load test the new solution with actual production data.
> Any insight/thoughts would be appreciated.
> Thanks!
> Paul
>|||Just to clarify, the vendor's recommendation would leave me with 4
separate RAID 10 sets, each of which would be two (2) disks wide. So I
would have a total of eight (8) disks with different tables assigned to
each RAID set via file groups.
I guess I am trying to determine whether it is worth my time to try and
break this thing out into file groups to separate specific tables onto
different RAID sets, therefore isolating I/O, or simply stripe across
as many disks as I can in a newly built RAID 10 array. The obvious
problem with breaking the tables out across multiple RAID sets, is that
I have no idea if the I/O generated by table X will be supported on a 2
disk wide, R10 array.
I agree that the simpler approach would be to simply stripe across as
many disks as possible. Not only would I have the benefit of R10 over
R5, but spindle count would not be an issue.
So Linchi, we could also use your formula to determine how a new 24
disk (12 useable) R10 array would compare to the existing 10 disk R5
array?
Paul|||Just to clarify, the vendor's recommendation would leave me with 4
separate RAID 10 sets, each of which would be two (2) disks wide. So I
would have a total of eight (8) disks with different tables assigned to
each RAID set via file groups.
I guess I am trying to determine whether it is worth my time to try and
break this thing out into file groups to separate specific tables onto
different RAID sets, therefore isolating I/O, or simply stripe across
as many disks as I can in a newly built RAID 10 array. The obvious
problem with breaking the tables out across multiple RAID sets, is that
I have no idea if the I/O generated by table X will be supported on a 2
disk wide, R10 array.
I agree that the simpler approach would be to simply stripe across as
many disks as possible. Not only would I have the benefit of R10 over
R5, but spindle count would not be an issue.
So Linchi, we could also use your formula to determine how a new 24
disk (12 useable) R10 array would compare to the existing 10 disk R5
array?
Paul|||If your database was running great on the Raid5 then what basis does the
vendor have to warrant splitting it up? While there are times when
splitting up tables, indexes etc. onto separate arrays will boost
performance you need to know you are doing the right thing. Have you done
any analysis that indicates this will help performance? You are probably
better off making a large RAID 10 and put all the files you now have ont he
Raid 5 on it. Keeping the Logs and Tempdb on their arrays either raid 1 or
10. If you don't know the capacity of the 4 disk Raid 10's and how much I/O
you will have for each you are more likely to make a bottleneck.
--
Andrew J. Kelly SQL MVP
"Paul" <ptimmerm@.gmail.com> wrote in message
news:1149023773.865667.104550@.g10g2000cwb.googlegroups.com...
> Just to clarify, the vendor's recommendation would leave me with 4
> separate RAID 10 sets, each of which would be two (2) disks wide. So I
> would have a total of eight (8) disks with different tables assigned to
> each RAID set via file groups.
> I guess I am trying to determine whether it is worth my time to try and
> break this thing out into file groups to separate specific tables onto
> different RAID sets, therefore isolating I/O, or simply stripe across
> as many disks as I can in a newly built RAID 10 array. The obvious
> problem with breaking the tables out across multiple RAID sets, is that
> I have no idea if the I/O generated by table X will be supported on a 2
> disk wide, R10 array.
> I agree that the simpler approach would be to simply stripe across as
> many disks as possible. Not only would I have the benefit of R10 over
> R5, but spindle count would not be an issue.
> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
> Paul
>|||Andrew,
These all are very good points. Thank you for raising them. The
recommendation for breaking the database up is based solely on their
poor design. 7 tables (including indexes) in their database make up
75% of the size of the DB. The DB is approximately 200GB. These
tables and a few others (not so large) contain 50 - 200 million records
a piece. It is not until a later release (a couple of years down the
road) that these tables are broken out into 6 or 7 "rolled up" tables.
Given the growth rate, many customers with minimum spec hardware (of
which we are not one) begin to see serious I/O problems that are
"resolved" by placing these tables, and others, on their own dedicated
RAID sets. As I continue to discuss this with others, I am leaning
more towards the large RAID10 array. I could still implement a
multiple data file structure in case we needed to make some moves down
the road, but for now stripe all of the files across the one large
RAID10. FYI... RAID 10 was my decision, not theirs. We will get a
performance bump from going to RAID10, which on top of the abundance of
cache and brand new hardware, should make for a very high performance
system. I am just looking for some way to quantify all of this.
Management likes numbers and statistics.
Another good point of your leads me to a specific question..... Is
there any way for me to measure I/O per database object? Is there any
way for me to estimate how much I/O would be hitting a given RAID set
if I know what tables will be located there?
Thoughts/ideas?
Paul|||Paul wrote:
> Andrew,
> These all are very good points. Thank you for raising them. The
> recommendation for breaking the database up is based solely on their
> poor design. 7 tables (including indexes) in their database make up
> 75% of the size of the DB. The DB is approximately 200GB. These
> tables and a few others (not so large) contain 50 - 200 million records
> a piece. It is not until a later release (a couple of years down the
> road) that these tables are broken out into 6 or 7 "rolled up" tables.
> Given the growth rate, many customers with minimum spec hardware (of
> which we are not one) begin to see serious I/O problems that are
> "resolved" by placing these tables, and others, on their own dedicated
> RAID sets. As I continue to discuss this with others, I am leaning
> more towards the large RAID10 array. I could still implement a
> multiple data file structure in case we needed to make some moves down
> the road, but for now stripe all of the files across the one large
> RAID10. FYI... RAID 10 was my decision, not theirs. We will get a
> performance bump from going to RAID10, which on top of the abundance of
> cache and brand new hardware, should make for a very high performance
> system. I am just looking for some way to quantify all of this.
> Management likes numbers and statistics.
> Another good point of your leads me to a specific question..... Is
> there any way for me to measure I/O per database object? Is there any
> way for me to estimate how much I/O would be hitting a given RAID set
> if I know what tables will be located there?
> Thoughts/ideas?
> Paul
>
Hi Paul
You don't mention anything about your READ/WRITE ratio. If you have far
more reads than writes, it could be that you'd be better off with a RAID
5 array. We have been through the same thoughts for some time ago and
ended up with a 24 disk RAID 5 array. I can't remember the exact
figures, but in our database we have something like 90 % read time so we
where really after a solution that could give a good read performance.
We talked with various storage experts and they more or less all agreed
that a RAID 5 array would give better read performance than a RAID10
assumed we used the same number of disks. That leaves us with a 1,5 TB
array where we're only using approx. 150 GB so there're a lot of "waste"
of space but that doesn't really matter.
We haven't tested the various solutions so actually we don't know if our
RAID 5 array performs better of worse than if we had a RAID 10 array
with the same number of disks.
Regards
Steen|||Linchi Shea wrote:
> Paul;
> 4GB of cache is unlikely to significantly decrease the number of spindles
> you need to stripe across to get the performance. Very large cache size does
> have an tendency to mask the need for more spindles. But that really depends
> on the workloads (on whether the workloads can take advantage of that cache).
>> Is there an "easy" way or rule of thumb that would allow me to
>> translate 10 disk wide RAID5 performance into X disk wide Raid 10
>> performance.
> There is commonly known RAID formula for doing this estimate. Assume that
> the read:write ratio of the workload is 3:1--a very typical ratio, and assume
> that you are using 15,000rpm disks, which can roughly do 180 IOs per second
> (IOps).
> RAID 5: Since each write needs 4 disk I/Os and eahc read needs one disk I/O,
> the I/O penalty is 4/(3+4) = 0.57
> RAID 10: Since each write needs two disk I/Os and each read needs one,
> the I/O penalty is 4/(3+2) = 0.80
> For 10-disk RAID 5, you can do 180 * 0.57 * 10 = 1026 IOps.
> For the RAID 10 to do 1026 IOps, you need 1026/(180 *0.80) ~= 8 disks
>
Hi Linchi
Do you have any links to this formula/calculation?
--
Regards
Steen Schlüter Persson
DBA|||There is no need to find any link to see how this formula works. Here's how.
Again assume the read:write ratio is 3:1 (or any other ratio you may fancy),
and assume that the total number of I/Os per second submitted to the RAID
device is Total_raid_iops. Hence,
The total number of writes per second = Total_raid_iops * 1/4, and
The total number of reads per second = Total_raid_iops * 3/4
For RAID 10, at the individual disk level, the total number of I/Os per
second for all the disks inside the RAID device are as follows:
The total number of writes per second = Total_raid_iops * 1/4 * 2
The total number of reads per second = Total_raid_iops *3/4 * 1
And
The grand total number of I/Os per second at the disk level
= (Total_raid_iops * 1/4 * 2 + Total_raid * 3/4 * 1)
= Total_raid_iops * (2/4 + 3/4)
= Total_raid_iops * 5/4
Given that a 15,000rmp disk can do about 180 I/Os per second, we have the
following:
Total_raid_iops * 5/4 = 180 * Number_of_disks
So if you know how many I/Os per second you want the RAID 10 device to do,
you can determine how many disks you need in this RAID 10 device, or if you
know the number of disks already in a RAID 10 device, you can determine how
many I/Os per second this device can do given the assumptions on write:read
ratio and the disk rotation speed.
Linchi
"Steen Persson (DK)" wrote:
> Linchi Shea wrote:
> > Paul;
> >
> > 4GB of cache is unlikely to significantly decrease the number of spindles
> > you need to stripe across to get the performance. Very large cache size does
> > have an tendency to mask the need for more spindles. But that really depends
> > on the workloads (on whether the workloads can take advantage of that cache).
> >
> >> Is there an "easy" way or rule of thumb that would allow me to
> >> translate 10 disk wide RAID5 performance into X disk wide Raid 10
> >> performance.
> >
> > There is commonly known RAID formula for doing this estimate. Assume that
> > the read:write ratio of the workload is 3:1--a very typical ratio, and assume
> > that you are using 15,000rpm disks, which can roughly do 180 IOs per second
> > (IOps).
> >
> > RAID 5: Since each write needs 4 disk I/Os and eahc read needs one disk I/O,
> > the I/O penalty is 4/(3+4) = 0.57
> > RAID 10: Since each write needs two disk I/Os and each read needs one,
> > the I/O penalty is 4/(3+2) = 0.80
> >
> > For 10-disk RAID 5, you can do 180 * 0.57 * 10 = 1026 IOps.
> > For the RAID 10 to do 1026 IOps, you need 1026/(180 *0.80) ~= 8 disks
> >
> Hi Linchi
> Do you have any links to this formula/calculation?
> --
> Regards
> Steen Schlüter Persson
> DBA
>|||> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
Yes, but I wouldn't want to bet my house the results. I trust the results
from controlled tests much better. As mentioned before, I'd use a tool such
as sqlio.exe or IOmeter to profile each RAID configuration. It is not an
extraordinary request to ask your SA or storage folks to give you the two
configurations for you to test. If the system is important, make a case to
your management to allow time for these tests. That would be time much better
spent than dwelling on theoretical estimates.
Once you have the solid test results, you can much better confront (okay
discuss with) your vendor with those numbers and ask them to justify their
recommendations in light of the test results.
Linchi
"Paul" wrote:
> Just to clarify, the vendor's recommendation would leave me with 4
> separate RAID 10 sets, each of which would be two (2) disks wide. So I
> would have a total of eight (8) disks with different tables assigned to
> each RAID set via file groups.
> I guess I am trying to determine whether it is worth my time to try and
> break this thing out into file groups to separate specific tables onto
> different RAID sets, therefore isolating I/O, or simply stripe across
> as many disks as I can in a newly built RAID 10 array. The obvious
> problem with breaking the tables out across multiple RAID sets, is that
> I have no idea if the I/O generated by table X will be supported on a 2
> disk wide, R10 array.
> I agree that the simpler approach would be to simply stripe across as
> many disks as possible. Not only would I have the benefit of R10 over
> R5, but spindle count would not be an issue.
> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
> Paul
>
RAID Configuration - R10 v. R5 - Spindle Count
We are in the process of procuring a new IBM SAN for our most business
critical SQL database. The database right now runs great on a 10 disk
RAID 5 set with TEMPDB and TLOGS on separate RAID1 arrays. As a part
of the new hardware implementation, we want to go to RAID10 and as per
a vendor recommendation, break the database out into file groups on
separate physical disks in order to boost performance.
I keep getting hung up on spindle count. I have always subscribed to
"the more spinning heads the better". The flaw in this theory appears
to be as the smallest disk you can buy for a given solution gets larger
and larger , where is the trade off? Do you still stripe across as
many disks as possible and end up burning a lot of disk space? Does
the large amount of cache (4GB on our new system) decrease the number
of spindles needed?
Is there an "easy" way or rule of thumb that would allow me to
translate 10 disk wide RAID5 performance into X disk wide Raid 10
performance. In a nutshell, how can I estimate what the following gets
me with regard to reducing the number of spindles necessary:
1. Going to RAID10 from RAID 5
2. New solution has 4GB of cache / old solution had 512MB
If I go with the vendor recommendations for table placement in file
groups I will end up with something in the range of four (4) - two (2)
disk wide RAID 10 sets. The RAID 10 sets will actually encompass 4
disks, but only 2 will be useable for space and my understanding is
that only two (2) will be counted for parallel I/O performance. I am
nervous about how narrow these RAID 10 sets are but maybe it does not
matter as much?
As a side note, i have no good way other than what I can get through
Profiler to load test the new solution with actual production data.
Any insight/thoughts would be appreciated.
Thanks!
PaulPaul;
4GB of cache is unlikely to significantly decrease the number of spindles
you need to stripe across to get the performance. Very large cache size does
have an tendency to mask the need for more spindles. But that really depends
on the workloads (on whether the workloads can take advantage of that cache)
.
> Is there an "easy" way or rule of thumb that would allow me to
> translate 10 disk wide RAID5 performance into X disk wide Raid 10
> performance.
There is commonly known RAID formula for doing this estimate. Assume that
the read:write ratio of the workload is 3:1--a very typical ratio, and assum
e
that you are using 15,000rpm disks, which can roughly do 180 IOs per second
(IOps).
RAID 5: Since each write needs 4 disk I/Os and eahc read needs one disk I/O
,
the I/O penalty is 4/(3+4) = 0.57
RAID 10: Since each write needs two disk I/Os and each read needs one,
the I/O penalty is 4/(3+2) = 0.80
For 10-disk RAID 5, you can do 180 * 0.57 * 10 = 1026 IOps.
For the RAID 10 to do 1026 IOps, you need 1026/(180 *0.80) ~= 8 disks
Of course, this is just a theoretical rough estimate with many factors
absent. For instance, it doesn't consider the effect of the SAN cache. But
it's safe to say that the vendor suggestion of 4 disk RAID 10 is unlikely to
cut it (unless there is anyting specific to the workload of your app).
Running application-specific benechmark is important to verify whether the
disk config is adequate. However, you can also use disk performance tools
such as IOMeter or sqlio.exe to specifically examine the performance of your
disk subsystem outside of SQL Server. I would run sqlio.exe whenever I get a
new storage so that I know what storage performance to expect, and have data
for later comparison when needed.
In general, it's far better and simpler to just stripe across as many disks
as you can (within the disk subsystem limits such as controller throughput).
Linchi
"Paul" wrote:
> We are in the process of procuring a new IBM SAN for our most business
> critical SQL database. The database right now runs great on a 10 disk
> RAID 5 set with TEMPDB and TLOGS on separate RAID1 arrays. As a part
> of the new hardware implementation, we want to go to RAID10 and as per
> a vendor recommendation, break the database out into file groups on
> separate physical disks in order to boost performance.
> I keep getting hung up on spindle count. I have always subscribed to
> "the more spinning heads the better". The flaw in this theory appears
> to be as the smallest disk you can buy for a given solution gets larger
> and larger , where is the trade off? Do you still stripe across as
> many disks as possible and end up burning a lot of disk space? Does
> the large amount of cache (4GB on our new system) decrease the number
> of spindles needed?
> Is there an "easy" way or rule of thumb that would allow me to
> translate 10 disk wide RAID5 performance into X disk wide Raid 10
> performance. In a nutshell, how can I estimate what the following gets
> me with regard to reducing the number of spindles necessary:
> 1. Going to RAID10 from RAID 5
> 2. New solution has 4GB of cache / old solution had 512MB
> If I go with the vendor recommendations for table placement in file
> groups I will end up with something in the range of four (4) - two (2)
> disk wide RAID 10 sets. The RAID 10 sets will actually encompass 4
> disks, but only 2 will be useable for space and my understanding is
> that only two (2) will be counted for parallel I/O performance. I am
> nervous about how narrow these RAID 10 sets are but maybe it does not
> matter as much?
> As a side note, i have no good way other than what I can get through
> Profiler to load test the new solution with actual production data.
> Any insight/thoughts would be appreciated.
> Thanks!
> Paul
>|||Just to clarify, the vendor's recommendation would leave me with 4
separate RAID 10 sets, each of which would be two (2) disks wide. So I
would have a total of eight (8) disks with different tables assigned to
each RAID set via file groups.
I guess I am trying to determine whether it is worth my time to try and
break this thing out into file groups to separate specific tables onto
different RAID sets, therefore isolating I/O, or simply stripe across
as many disks as I can in a newly built RAID 10 array. The obvious
problem with breaking the tables out across multiple RAID sets, is that
I have no idea if the I/O generated by table X will be supported on a 2
disk wide, R10 array.
I agree that the simpler approach would be to simply stripe across as
many disks as possible. Not only would I have the benefit of R10 over
R5, but spindle count would not be an issue.
So Linchi, we could also use your formula to determine how a new 24
disk (12 useable) R10 array would compare to the existing 10 disk R5
array?
Paul|||Just to clarify, the vendor's recommendation would leave me with 4
separate RAID 10 sets, each of which would be two (2) disks wide. So I
would have a total of eight (8) disks with different tables assigned to
each RAID set via file groups.
I guess I am trying to determine whether it is worth my time to try and
break this thing out into file groups to separate specific tables onto
different RAID sets, therefore isolating I/O, or simply stripe across
as many disks as I can in a newly built RAID 10 array. The obvious
problem with breaking the tables out across multiple RAID sets, is that
I have no idea if the I/O generated by table X will be supported on a 2
disk wide, R10 array.
I agree that the simpler approach would be to simply stripe across as
many disks as possible. Not only would I have the benefit of R10 over
R5, but spindle count would not be an issue.
So Linchi, we could also use your formula to determine how a new 24
disk (12 useable) R10 array would compare to the existing 10 disk R5
array?
Paul|||If your database was running great on the Raid5 then what basis does the
vendor have to warrant splitting it up? While there are times when
splitting up tables, indexes etc. onto separate arrays will boost
performance you need to know you are doing the right thing. Have you done
any analysis that indicates this will help performance? You are probably
better off making a large RAID 10 and put all the files you now have ont he
Raid 5 on it. Keeping the Logs and Tempdb on their arrays either raid 1 or
10. If you don't know the capacity of the 4 disk Raid 10's and how much I/O
you will have for each you are more likely to make a bottleneck.
Andrew J. Kelly SQL MVP
"Paul" <ptimmerm@.gmail.com> wrote in message
news:1149023773.865667.104550@.g10g2000cwb.googlegroups.com...
> Just to clarify, the vendor's recommendation would leave me with 4
> separate RAID 10 sets, each of which would be two (2) disks wide. So I
> would have a total of eight (8) disks with different tables assigned to
> each RAID set via file groups.
> I guess I am trying to determine whether it is worth my time to try and
> break this thing out into file groups to separate specific tables onto
> different RAID sets, therefore isolating I/O, or simply stripe across
> as many disks as I can in a newly built RAID 10 array. The obvious
> problem with breaking the tables out across multiple RAID sets, is that
> I have no idea if the I/O generated by table X will be supported on a 2
> disk wide, R10 array.
> I agree that the simpler approach would be to simply stripe across as
> many disks as possible. Not only would I have the benefit of R10 over
> R5, but spindle count would not be an issue.
> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
> Paul
>|||Andrew,
These all are very good points. Thank you for raising them. The
recommendation for breaking the database up is based solely on their
poor design. 7 tables (including indexes) in their database make up
75% of the size of the DB. The DB is approximately 200GB. These
tables and a few others (not so large) contain 50 - 200 million records
a piece. It is not until a later release (a couple of years down the
road) that these tables are broken out into 6 or 7 "rolled up" tables.
Given the growth rate, many customers with minimum spec hardware (of
which we are not one) begin to see serious I/O problems that are
"resolved" by placing these tables, and others, on their own dedicated
RAID sets. As I continue to discuss this with others, I am leaning
more towards the large RAID10 array. I could still implement a
multiple data file structure in case we needed to make some moves down
the road, but for now stripe all of the files across the one large
RAID10. FYI... RAID 10 was my decision, not theirs. We will get a
performance bump from going to RAID10, which on top of the abundance of
cache and brand new hardware, should make for a very high performance
system. I am just looking for some way to quantify all of this.
Management likes numbers and statistics.
Another good point of your leads me to a specific question..... Is
there any way for me to measure I/O per database object? Is there any
way for me to estimate how much I/O would be hitting a given RAID set
if I know what tables will be located there?
Thoughts/ideas?
Paul|||Paul wrote:
> Andrew,
> These all are very good points. Thank you for raising them. The
> recommendation for breaking the database up is based solely on their
> poor design. 7 tables (including indexes) in their database make up
> 75% of the size of the DB. The DB is approximately 200GB. These
> tables and a few others (not so large) contain 50 - 200 million records
> a piece. It is not until a later release (a couple of years down the
> road) that these tables are broken out into 6 or 7 "rolled up" tables.
> Given the growth rate, many customers with minimum spec hardware (of
> which we are not one) begin to see serious I/O problems that are
> "resolved" by placing these tables, and others, on their own dedicated
> RAID sets. As I continue to discuss this with others, I am leaning
> more towards the large RAID10 array. I could still implement a
> multiple data file structure in case we needed to make some moves down
> the road, but for now stripe all of the files across the one large
> RAID10. FYI... RAID 10 was my decision, not theirs. We will get a
> performance bump from going to RAID10, which on top of the abundance of
> cache and brand new hardware, should make for a very high performance
> system. I am just looking for some way to quantify all of this.
> Management likes numbers and statistics.
> Another good point of your leads me to a specific question..... Is
> there any way for me to measure I/O per database object? Is there any
> way for me to estimate how much I/O would be hitting a given RAID set
> if I know what tables will be located there?
> Thoughts/ideas?
> Paul
>
Hi Paul
You don't mention anything about your READ/WRITE ratio. If you have far
more reads than writes, it could be that you'd be better off with a RAID
5 array. We have been through the same thoughts for some time ago and
ended up with a 24 disk RAID 5 array. I can't remember the exact
figures, but in our database we have something like 90 % read time so we
where really after a solution that could give a good read performance.
We talked with various storage experts and they more or less all agreed
that a RAID 5 array would give better read performance than a RAID10
assumed we used the same number of disks. That leaves us with a 1,5 TB
array where we're only using approx. 150 GB so there're a lot of "waste"
of space but that doesn't really matter.
We haven't tested the various solutions so actually we don't know if our
RAID 5 array performs better of worse than if we had a RAID 10 array
with the same number of disks.
Regards
Steen|||Linchi Shea wrote:
> Paul;
> 4GB of cache is unlikely to significantly decrease the number of spindles
> you need to stripe across to get the performance. Very large cache size do
es
> have an tendency to mask the need for more spindles. But that really depen
ds
> on the workloads (on whether the workloads can take advantage of that cach
e).
>
> There is commonly known RAID formula for doing this estimate. Assume that
> the read:write ratio of the workload is 3:1--a very typical ratio, and XXX
ume
> that you are using 15,000rpm disks, which can roughly do 180 IOs per secon
d
> (IOps).
> RAID 5: Since each write needs 4 disk I/Os and eahc read needs one disk I
/O,
> the I/O penalty is 4/(3+4) = 0.57
> RAID 10: Since each write needs two disk I/Os and each read needs one,
> the I/O penalty is 4/(3+2) = 0.80
> For 10-disk RAID 5, you can do 180 * 0.57 * 10 = 1026 IOps.
> For the RAID 10 to do 1026 IOps, you need 1026/(180 *0.80) ~= 8 disks
>
Hi Linchi
Do you have any links to this formula/calculation?
Regards
Steen Schlüter Persson
DBA|||There is no need to find any link to see how this formula works. Here's how.
Again assume the read:write ratio is 3:1 (or any other ratio you may fancy),
and assume that the total number of I/Os per second submitted to the RAID
device is Total_raid_iops. Hence,
The total number of writes per second = Total_raid_iops * 1/4, and
The total number of reads per second = Total_raid_iops * 3/4
For RAID 10, at the individual disk level, the total number of I/Os per
second for all the disks inside the RAID device are as follows:
The total number of writes per second = Total_raid_iops * 1/4 * 2
The total number of reads per second = Total_raid_iops *3/4 * 1
And
The grand total number of I/Os per second at the disk level
= (Total_raid_iops * 1/4 * 2 + Total_raid * 3/4 * 1)
= Total_raid_iops * (2/4 + 3/4)
= Total_raid_iops * 5/4
Given that a 15,000rmp disk can do about 180 I/Os per second, we have the
following:
Total_raid_iops * 5/4 = 180 * Number_of_disks
So if you know how many I/Os per second you want the RAID 10 device to do,
you can determine how many disks you need in this RAID 10 device, or if you
know the number of disks already in a RAID 10 device, you can determine how
many I/Os per second this device can do given the assumptions on write:read
ratio and the disk rotation speed.
Linchi
"Steen Persson (DK)" wrote:
> Linchi Shea wrote:
> Hi Linchi
> Do you have any links to this formula/calculation?
> --
> Regards
> Steen Schlüter Persson
> DBA
>|||> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
Yes, but I wouldn't want to bet my house the results. I trust the results
from controlled tests much better. As mentioned before, I'd use a tool such
as sqlio.exe or IOmeter to profile each RAID configuration. It is not an
extraordinary request to ask your SA or storage folks to give you the two
configurations for you to test. If the system is important, make a case to
your management to allow time for these tests. That would be time much bette
r
spent than dwelling on theoretical estimates.
Once you have the solid test results, you can much better confront (okay
discuss with) your vendor with those numbers and ask them to justify their
recommendations in light of the test results.
Linchi
"Paul" wrote:
> Just to clarify, the vendor's recommendation would leave me with 4
> separate RAID 10 sets, each of which would be two (2) disks wide. So I
> would have a total of eight (8) disks with different tables assigned to
> each RAID set via file groups.
> I guess I am trying to determine whether it is worth my time to try and
> break this thing out into file groups to separate specific tables onto
> different RAID sets, therefore isolating I/O, or simply stripe across
> as many disks as I can in a newly built RAID 10 array. The obvious
> problem with breaking the tables out across multiple RAID sets, is that
> I have no idea if the I/O generated by table X will be supported on a 2
> disk wide, R10 array.
> I agree that the simpler approach would be to simply stripe across as
> many disks as possible. Not only would I have the benefit of R10 over
> R5, but spindle count would not be an issue.
> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
> Paul
>sql
critical SQL database. The database right now runs great on a 10 disk
RAID 5 set with TEMPDB and TLOGS on separate RAID1 arrays. As a part
of the new hardware implementation, we want to go to RAID10 and as per
a vendor recommendation, break the database out into file groups on
separate physical disks in order to boost performance.
I keep getting hung up on spindle count. I have always subscribed to
"the more spinning heads the better". The flaw in this theory appears
to be as the smallest disk you can buy for a given solution gets larger
and larger , where is the trade off? Do you still stripe across as
many disks as possible and end up burning a lot of disk space? Does
the large amount of cache (4GB on our new system) decrease the number
of spindles needed?
Is there an "easy" way or rule of thumb that would allow me to
translate 10 disk wide RAID5 performance into X disk wide Raid 10
performance. In a nutshell, how can I estimate what the following gets
me with regard to reducing the number of spindles necessary:
1. Going to RAID10 from RAID 5
2. New solution has 4GB of cache / old solution had 512MB
If I go with the vendor recommendations for table placement in file
groups I will end up with something in the range of four (4) - two (2)
disk wide RAID 10 sets. The RAID 10 sets will actually encompass 4
disks, but only 2 will be useable for space and my understanding is
that only two (2) will be counted for parallel I/O performance. I am
nervous about how narrow these RAID 10 sets are but maybe it does not
matter as much?
As a side note, i have no good way other than what I can get through
Profiler to load test the new solution with actual production data.
Any insight/thoughts would be appreciated.
Thanks!
PaulPaul;
4GB of cache is unlikely to significantly decrease the number of spindles
you need to stripe across to get the performance. Very large cache size does
have an tendency to mask the need for more spindles. But that really depends
on the workloads (on whether the workloads can take advantage of that cache)
.
> Is there an "easy" way or rule of thumb that would allow me to
> translate 10 disk wide RAID5 performance into X disk wide Raid 10
> performance.
There is commonly known RAID formula for doing this estimate. Assume that
the read:write ratio of the workload is 3:1--a very typical ratio, and assum
e
that you are using 15,000rpm disks, which can roughly do 180 IOs per second
(IOps).
RAID 5: Since each write needs 4 disk I/Os and eahc read needs one disk I/O
,
the I/O penalty is 4/(3+4) = 0.57
RAID 10: Since each write needs two disk I/Os and each read needs one,
the I/O penalty is 4/(3+2) = 0.80
For 10-disk RAID 5, you can do 180 * 0.57 * 10 = 1026 IOps.
For the RAID 10 to do 1026 IOps, you need 1026/(180 *0.80) ~= 8 disks
Of course, this is just a theoretical rough estimate with many factors
absent. For instance, it doesn't consider the effect of the SAN cache. But
it's safe to say that the vendor suggestion of 4 disk RAID 10 is unlikely to
cut it (unless there is anyting specific to the workload of your app).
Running application-specific benechmark is important to verify whether the
disk config is adequate. However, you can also use disk performance tools
such as IOMeter or sqlio.exe to specifically examine the performance of your
disk subsystem outside of SQL Server. I would run sqlio.exe whenever I get a
new storage so that I know what storage performance to expect, and have data
for later comparison when needed.
In general, it's far better and simpler to just stripe across as many disks
as you can (within the disk subsystem limits such as controller throughput).
Linchi
"Paul" wrote:
> We are in the process of procuring a new IBM SAN for our most business
> critical SQL database. The database right now runs great on a 10 disk
> RAID 5 set with TEMPDB and TLOGS on separate RAID1 arrays. As a part
> of the new hardware implementation, we want to go to RAID10 and as per
> a vendor recommendation, break the database out into file groups on
> separate physical disks in order to boost performance.
> I keep getting hung up on spindle count. I have always subscribed to
> "the more spinning heads the better". The flaw in this theory appears
> to be as the smallest disk you can buy for a given solution gets larger
> and larger , where is the trade off? Do you still stripe across as
> many disks as possible and end up burning a lot of disk space? Does
> the large amount of cache (4GB on our new system) decrease the number
> of spindles needed?
> Is there an "easy" way or rule of thumb that would allow me to
> translate 10 disk wide RAID5 performance into X disk wide Raid 10
> performance. In a nutshell, how can I estimate what the following gets
> me with regard to reducing the number of spindles necessary:
> 1. Going to RAID10 from RAID 5
> 2. New solution has 4GB of cache / old solution had 512MB
> If I go with the vendor recommendations for table placement in file
> groups I will end up with something in the range of four (4) - two (2)
> disk wide RAID 10 sets. The RAID 10 sets will actually encompass 4
> disks, but only 2 will be useable for space and my understanding is
> that only two (2) will be counted for parallel I/O performance. I am
> nervous about how narrow these RAID 10 sets are but maybe it does not
> matter as much?
> As a side note, i have no good way other than what I can get through
> Profiler to load test the new solution with actual production data.
> Any insight/thoughts would be appreciated.
> Thanks!
> Paul
>|||Just to clarify, the vendor's recommendation would leave me with 4
separate RAID 10 sets, each of which would be two (2) disks wide. So I
would have a total of eight (8) disks with different tables assigned to
each RAID set via file groups.
I guess I am trying to determine whether it is worth my time to try and
break this thing out into file groups to separate specific tables onto
different RAID sets, therefore isolating I/O, or simply stripe across
as many disks as I can in a newly built RAID 10 array. The obvious
problem with breaking the tables out across multiple RAID sets, is that
I have no idea if the I/O generated by table X will be supported on a 2
disk wide, R10 array.
I agree that the simpler approach would be to simply stripe across as
many disks as possible. Not only would I have the benefit of R10 over
R5, but spindle count would not be an issue.
So Linchi, we could also use your formula to determine how a new 24
disk (12 useable) R10 array would compare to the existing 10 disk R5
array?
Paul|||Just to clarify, the vendor's recommendation would leave me with 4
separate RAID 10 sets, each of which would be two (2) disks wide. So I
would have a total of eight (8) disks with different tables assigned to
each RAID set via file groups.
I guess I am trying to determine whether it is worth my time to try and
break this thing out into file groups to separate specific tables onto
different RAID sets, therefore isolating I/O, or simply stripe across
as many disks as I can in a newly built RAID 10 array. The obvious
problem with breaking the tables out across multiple RAID sets, is that
I have no idea if the I/O generated by table X will be supported on a 2
disk wide, R10 array.
I agree that the simpler approach would be to simply stripe across as
many disks as possible. Not only would I have the benefit of R10 over
R5, but spindle count would not be an issue.
So Linchi, we could also use your formula to determine how a new 24
disk (12 useable) R10 array would compare to the existing 10 disk R5
array?
Paul|||If your database was running great on the Raid5 then what basis does the
vendor have to warrant splitting it up? While there are times when
splitting up tables, indexes etc. onto separate arrays will boost
performance you need to know you are doing the right thing. Have you done
any analysis that indicates this will help performance? You are probably
better off making a large RAID 10 and put all the files you now have ont he
Raid 5 on it. Keeping the Logs and Tempdb on their arrays either raid 1 or
10. If you don't know the capacity of the 4 disk Raid 10's and how much I/O
you will have for each you are more likely to make a bottleneck.
Andrew J. Kelly SQL MVP
"Paul" <ptimmerm@.gmail.com> wrote in message
news:1149023773.865667.104550@.g10g2000cwb.googlegroups.com...
> Just to clarify, the vendor's recommendation would leave me with 4
> separate RAID 10 sets, each of which would be two (2) disks wide. So I
> would have a total of eight (8) disks with different tables assigned to
> each RAID set via file groups.
> I guess I am trying to determine whether it is worth my time to try and
> break this thing out into file groups to separate specific tables onto
> different RAID sets, therefore isolating I/O, or simply stripe across
> as many disks as I can in a newly built RAID 10 array. The obvious
> problem with breaking the tables out across multiple RAID sets, is that
> I have no idea if the I/O generated by table X will be supported on a 2
> disk wide, R10 array.
> I agree that the simpler approach would be to simply stripe across as
> many disks as possible. Not only would I have the benefit of R10 over
> R5, but spindle count would not be an issue.
> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
> Paul
>|||Andrew,
These all are very good points. Thank you for raising them. The
recommendation for breaking the database up is based solely on their
poor design. 7 tables (including indexes) in their database make up
75% of the size of the DB. The DB is approximately 200GB. These
tables and a few others (not so large) contain 50 - 200 million records
a piece. It is not until a later release (a couple of years down the
road) that these tables are broken out into 6 or 7 "rolled up" tables.
Given the growth rate, many customers with minimum spec hardware (of
which we are not one) begin to see serious I/O problems that are
"resolved" by placing these tables, and others, on their own dedicated
RAID sets. As I continue to discuss this with others, I am leaning
more towards the large RAID10 array. I could still implement a
multiple data file structure in case we needed to make some moves down
the road, but for now stripe all of the files across the one large
RAID10. FYI... RAID 10 was my decision, not theirs. We will get a
performance bump from going to RAID10, which on top of the abundance of
cache and brand new hardware, should make for a very high performance
system. I am just looking for some way to quantify all of this.
Management likes numbers and statistics.
Another good point of your leads me to a specific question..... Is
there any way for me to measure I/O per database object? Is there any
way for me to estimate how much I/O would be hitting a given RAID set
if I know what tables will be located there?
Thoughts/ideas?
Paul|||Paul wrote:
> Andrew,
> These all are very good points. Thank you for raising them. The
> recommendation for breaking the database up is based solely on their
> poor design. 7 tables (including indexes) in their database make up
> 75% of the size of the DB. The DB is approximately 200GB. These
> tables and a few others (not so large) contain 50 - 200 million records
> a piece. It is not until a later release (a couple of years down the
> road) that these tables are broken out into 6 or 7 "rolled up" tables.
> Given the growth rate, many customers with minimum spec hardware (of
> which we are not one) begin to see serious I/O problems that are
> "resolved" by placing these tables, and others, on their own dedicated
> RAID sets. As I continue to discuss this with others, I am leaning
> more towards the large RAID10 array. I could still implement a
> multiple data file structure in case we needed to make some moves down
> the road, but for now stripe all of the files across the one large
> RAID10. FYI... RAID 10 was my decision, not theirs. We will get a
> performance bump from going to RAID10, which on top of the abundance of
> cache and brand new hardware, should make for a very high performance
> system. I am just looking for some way to quantify all of this.
> Management likes numbers and statistics.
> Another good point of your leads me to a specific question..... Is
> there any way for me to measure I/O per database object? Is there any
> way for me to estimate how much I/O would be hitting a given RAID set
> if I know what tables will be located there?
> Thoughts/ideas?
> Paul
>
Hi Paul
You don't mention anything about your READ/WRITE ratio. If you have far
more reads than writes, it could be that you'd be better off with a RAID
5 array. We have been through the same thoughts for some time ago and
ended up with a 24 disk RAID 5 array. I can't remember the exact
figures, but in our database we have something like 90 % read time so we
where really after a solution that could give a good read performance.
We talked with various storage experts and they more or less all agreed
that a RAID 5 array would give better read performance than a RAID10
assumed we used the same number of disks. That leaves us with a 1,5 TB
array where we're only using approx. 150 GB so there're a lot of "waste"
of space but that doesn't really matter.
We haven't tested the various solutions so actually we don't know if our
RAID 5 array performs better of worse than if we had a RAID 10 array
with the same number of disks.
Regards
Steen|||Linchi Shea wrote:
> Paul;
> 4GB of cache is unlikely to significantly decrease the number of spindles
> you need to stripe across to get the performance. Very large cache size do
es
> have an tendency to mask the need for more spindles. But that really depen
ds
> on the workloads (on whether the workloads can take advantage of that cach
e).
>
> There is commonly known RAID formula for doing this estimate. Assume that
> the read:write ratio of the workload is 3:1--a very typical ratio, and XXX
ume
> that you are using 15,000rpm disks, which can roughly do 180 IOs per secon
d
> (IOps).
> RAID 5: Since each write needs 4 disk I/Os and eahc read needs one disk I
/O,
> the I/O penalty is 4/(3+4) = 0.57
> RAID 10: Since each write needs two disk I/Os and each read needs one,
> the I/O penalty is 4/(3+2) = 0.80
> For 10-disk RAID 5, you can do 180 * 0.57 * 10 = 1026 IOps.
> For the RAID 10 to do 1026 IOps, you need 1026/(180 *0.80) ~= 8 disks
>
Hi Linchi
Do you have any links to this formula/calculation?
Regards
Steen Schlüter Persson
DBA|||There is no need to find any link to see how this formula works. Here's how.
Again assume the read:write ratio is 3:1 (or any other ratio you may fancy),
and assume that the total number of I/Os per second submitted to the RAID
device is Total_raid_iops. Hence,
The total number of writes per second = Total_raid_iops * 1/4, and
The total number of reads per second = Total_raid_iops * 3/4
For RAID 10, at the individual disk level, the total number of I/Os per
second for all the disks inside the RAID device are as follows:
The total number of writes per second = Total_raid_iops * 1/4 * 2
The total number of reads per second = Total_raid_iops *3/4 * 1
And
The grand total number of I/Os per second at the disk level
= (Total_raid_iops * 1/4 * 2 + Total_raid * 3/4 * 1)
= Total_raid_iops * (2/4 + 3/4)
= Total_raid_iops * 5/4
Given that a 15,000rmp disk can do about 180 I/Os per second, we have the
following:
Total_raid_iops * 5/4 = 180 * Number_of_disks
So if you know how many I/Os per second you want the RAID 10 device to do,
you can determine how many disks you need in this RAID 10 device, or if you
know the number of disks already in a RAID 10 device, you can determine how
many I/Os per second this device can do given the assumptions on write:read
ratio and the disk rotation speed.
Linchi
"Steen Persson (DK)" wrote:
> Linchi Shea wrote:
> Hi Linchi
> Do you have any links to this formula/calculation?
> --
> Regards
> Steen Schlüter Persson
> DBA
>|||> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
Yes, but I wouldn't want to bet my house the results. I trust the results
from controlled tests much better. As mentioned before, I'd use a tool such
as sqlio.exe or IOmeter to profile each RAID configuration. It is not an
extraordinary request to ask your SA or storage folks to give you the two
configurations for you to test. If the system is important, make a case to
your management to allow time for these tests. That would be time much bette
r
spent than dwelling on theoretical estimates.
Once you have the solid test results, you can much better confront (okay
discuss with) your vendor with those numbers and ask them to justify their
recommendations in light of the test results.
Linchi
"Paul" wrote:
> Just to clarify, the vendor's recommendation would leave me with 4
> separate RAID 10 sets, each of which would be two (2) disks wide. So I
> would have a total of eight (8) disks with different tables assigned to
> each RAID set via file groups.
> I guess I am trying to determine whether it is worth my time to try and
> break this thing out into file groups to separate specific tables onto
> different RAID sets, therefore isolating I/O, or simply stripe across
> as many disks as I can in a newly built RAID 10 array. The obvious
> problem with breaking the tables out across multiple RAID sets, is that
> I have no idea if the I/O generated by table X will be supported on a 2
> disk wide, R10 array.
> I agree that the simpler approach would be to simply stripe across as
> many disks as possible. Not only would I have the benefit of R10 over
> R5, but spindle count would not be an issue.
> So Linchi, we could also use your formula to determine how a new 24
> disk (12 useable) R10 array would compare to the existing 10 disk R5
> array?
> Paul
>sql
RAID and Cluster!
Hi All, Want to seek advice and experience from all of you. What is the
recommended RAID Solution for SQL Cluster on SAN, is it RAID 1+0 or RAID-5?
We just upgraded from RAID 1+0 to RAID 5 and since then we are getting
hiccups on the Cluster. If there is any connectivity failures on the Drives
(which are recovered after few mins) the Cluster goes haywire and becomes
unavailable (for e.g. it fails to read off the Quorum Log etc...)
Thanks in adv.
Env:
Win2000 Adv Server SP4
SQL2000 SP4
"Vai2000" <nospam@.microsoft.com> wrote in message
news:%23Lb1UxbIGHA.524@.TK2MSFTNGP09.phx.gbl...
> Hi All, Want to seek advice and experience from all of you. What is the
> recommended RAID Solution for SQL Cluster on SAN, is it RAID 1+0 or
RAID-5?
> We just upgraded from RAID 1+0 to RAID 5 and since then we are getting
> hiccups on the Cluster. If there is any connectivity failures on the
Drives
> (which are recovered after few mins) the Cluster goes haywire and becomes
> unavailable (for e.g. it fails to read off the Quorum Log etc...)
>
> Thanks in adv.
>
|||First, you need to fix you SAN issues, with or without clustering SQL really
likes to have its disks online at all times.
Have you separated your Databases and Transaction Log files? RAID 1 or 10
for the Logs. Raid 5 or 10 for the Databases. Quorum & MSDTC (if required)
on its own disk subsystems of 1 GB in size.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
"Vai2000" <nospam@.microsoft.com> wrote in message
news:%23Lb1UxbIGHA.524@.TK2MSFTNGP09.phx.gbl...
> Hi All, Want to seek advice and experience from all of you. What is the
> recommended RAID Solution for SQL Cluster on SAN, is it RAID 1+0 or
> RAID-5?
> We just upgraded from RAID 1+0 to RAID 5 and since then we are getting
> hiccups on the Cluster. If there is any connectivity failures on the
> Drives
> (which are recovered after few mins) the Cluster goes haywire and becomes
> unavailable (for e.g. it fails to read off the Quorum Log etc...)
>
> Thanks in adv.
>
|||That's not an upgrade, it is a reconfiguration. They do completely
different things. By RAID 1+0 do you mean a stripe of mirrors or a mirror
of stripes?
In either case, the answer is, I don't know. RAID5 gives particular levels
of redundancy while incurring a performance impact for certain types of I/O
patterns. A mirror of stripes gives equivalent redundancy to RAID5 without
having quite a much of a performance impact on certain types of I/O
patterns. A stripe of mirrors gives much greater redundancy than the other
two and generally better performance as well. But, if you are saturating
the I/O channel or stuffing all of your data on a tiny subset of the drives
in the SAN, it really isn't going to matter very much. The recommendations
also vary depending upon whether you have an access pattern that looks like
"tradional OLTP", "traditional DW", or a mix of the two.
Regardless of the performance characteristics, neither one is going to be
more stable than the other in your case. If the SAN drives disconnect, it
doesn't matter if it is a cluster or a standalone SQL Server, it isn't going
to like it. You have to fix the errors on your SAN that are causing the
disconnects first. If those aren't fixed, there isn't anything you are
going to be able to do to make the system stable.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Vai2000" <nospam@.microsoft.com> wrote in message
news:%23Lb1UxbIGHA.524@.TK2MSFTNGP09.phx.gbl...
> Hi All, Want to seek advice and experience from all of you. What is the
> recommended RAID Solution for SQL Cluster on SAN, is it RAID 1+0 or
> RAID-5?
> We just upgraded from RAID 1+0 to RAID 5 and since then we are getting
> hiccups on the Cluster. If there is any connectivity failures on the
> Drives
> (which are recovered after few mins) the Cluster goes haywire and becomes
> unavailable (for e.g. it fails to read off the Quorum Log etc...)
>
> Thanks in adv.
>
|||Not to mention that unless you have proper host isolation in the SAN, you
are going to run into severe spindle contention, even if this particular
host's channels are not saturated.
Anthony Thomas
"Michael Hotek" <mike@.solidqualitylearning.com> wrote in message
news:%234b0uwdIGHA.676@.TK2MSFTNGP10.phx.gbl...
> That's not an upgrade, it is a reconfiguration. They do completely
> different things. By RAID 1+0 do you mean a stripe of mirrors or a mirror
> of stripes?
> In either case, the answer is, I don't know. RAID5 gives particular
levels
> of redundancy while incurring a performance impact for certain types of
I/O
> patterns. A mirror of stripes gives equivalent redundancy to RAID5
without
> having quite a much of a performance impact on certain types of I/O
> patterns. A stripe of mirrors gives much greater redundancy than the
other
> two and generally better performance as well. But, if you are saturating
> the I/O channel or stuffing all of your data on a tiny subset of the
drives
> in the SAN, it really isn't going to matter very much. The
recommendations
> also vary depending upon whether you have an access pattern that looks
like
> "tradional OLTP", "traditional DW", or a mix of the two.
> Regardless of the performance characteristics, neither one is going to be
> more stable than the other in your case. If the SAN drives disconnect, it
> doesn't matter if it is a cluster or a standalone SQL Server, it isn't
going[vbcol=seagreen]
> to like it. You have to fix the errors on your SAN that are causing the
> disconnects first. If those aren't fixed, there isn't anything you are
> going to be able to do to make the system stable.
> --
> Mike
> http://www.solidqualitylearning.com
> Disclaimer: This communication is an original work and represents my sole
> views on the subject. It does not represent the views of any other person
> or entity either by inference or direct reference.
> "Vai2000" <nospam@.microsoft.com> wrote in message
> news:%23Lb1UxbIGHA.524@.TK2MSFTNGP09.phx.gbl...
becomes
>
sql
recommended RAID Solution for SQL Cluster on SAN, is it RAID 1+0 or RAID-5?
We just upgraded from RAID 1+0 to RAID 5 and since then we are getting
hiccups on the Cluster. If there is any connectivity failures on the Drives
(which are recovered after few mins) the Cluster goes haywire and becomes
unavailable (for e.g. it fails to read off the Quorum Log etc...)
Thanks in adv.
Env:
Win2000 Adv Server SP4
SQL2000 SP4
"Vai2000" <nospam@.microsoft.com> wrote in message
news:%23Lb1UxbIGHA.524@.TK2MSFTNGP09.phx.gbl...
> Hi All, Want to seek advice and experience from all of you. What is the
> recommended RAID Solution for SQL Cluster on SAN, is it RAID 1+0 or
RAID-5?
> We just upgraded from RAID 1+0 to RAID 5 and since then we are getting
> hiccups on the Cluster. If there is any connectivity failures on the
Drives
> (which are recovered after few mins) the Cluster goes haywire and becomes
> unavailable (for e.g. it fails to read off the Quorum Log etc...)
>
> Thanks in adv.
>
|||First, you need to fix you SAN issues, with or without clustering SQL really
likes to have its disks online at all times.
Have you separated your Databases and Transaction Log files? RAID 1 or 10
for the Logs. Raid 5 or 10 for the Databases. Quorum & MSDTC (if required)
on its own disk subsystems of 1 GB in size.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
"Vai2000" <nospam@.microsoft.com> wrote in message
news:%23Lb1UxbIGHA.524@.TK2MSFTNGP09.phx.gbl...
> Hi All, Want to seek advice and experience from all of you. What is the
> recommended RAID Solution for SQL Cluster on SAN, is it RAID 1+0 or
> RAID-5?
> We just upgraded from RAID 1+0 to RAID 5 and since then we are getting
> hiccups on the Cluster. If there is any connectivity failures on the
> Drives
> (which are recovered after few mins) the Cluster goes haywire and becomes
> unavailable (for e.g. it fails to read off the Quorum Log etc...)
>
> Thanks in adv.
>
|||That's not an upgrade, it is a reconfiguration. They do completely
different things. By RAID 1+0 do you mean a stripe of mirrors or a mirror
of stripes?
In either case, the answer is, I don't know. RAID5 gives particular levels
of redundancy while incurring a performance impact for certain types of I/O
patterns. A mirror of stripes gives equivalent redundancy to RAID5 without
having quite a much of a performance impact on certain types of I/O
patterns. A stripe of mirrors gives much greater redundancy than the other
two and generally better performance as well. But, if you are saturating
the I/O channel or stuffing all of your data on a tiny subset of the drives
in the SAN, it really isn't going to matter very much. The recommendations
also vary depending upon whether you have an access pattern that looks like
"tradional OLTP", "traditional DW", or a mix of the two.
Regardless of the performance characteristics, neither one is going to be
more stable than the other in your case. If the SAN drives disconnect, it
doesn't matter if it is a cluster or a standalone SQL Server, it isn't going
to like it. You have to fix the errors on your SAN that are causing the
disconnects first. If those aren't fixed, there isn't anything you are
going to be able to do to make the system stable.
Mike
http://www.solidqualitylearning.com
Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
"Vai2000" <nospam@.microsoft.com> wrote in message
news:%23Lb1UxbIGHA.524@.TK2MSFTNGP09.phx.gbl...
> Hi All, Want to seek advice and experience from all of you. What is the
> recommended RAID Solution for SQL Cluster on SAN, is it RAID 1+0 or
> RAID-5?
> We just upgraded from RAID 1+0 to RAID 5 and since then we are getting
> hiccups on the Cluster. If there is any connectivity failures on the
> Drives
> (which are recovered after few mins) the Cluster goes haywire and becomes
> unavailable (for e.g. it fails to read off the Quorum Log etc...)
>
> Thanks in adv.
>
|||Not to mention that unless you have proper host isolation in the SAN, you
are going to run into severe spindle contention, even if this particular
host's channels are not saturated.
Anthony Thomas
"Michael Hotek" <mike@.solidqualitylearning.com> wrote in message
news:%234b0uwdIGHA.676@.TK2MSFTNGP10.phx.gbl...
> That's not an upgrade, it is a reconfiguration. They do completely
> different things. By RAID 1+0 do you mean a stripe of mirrors or a mirror
> of stripes?
> In either case, the answer is, I don't know. RAID5 gives particular
levels
> of redundancy while incurring a performance impact for certain types of
I/O
> patterns. A mirror of stripes gives equivalent redundancy to RAID5
without
> having quite a much of a performance impact on certain types of I/O
> patterns. A stripe of mirrors gives much greater redundancy than the
other
> two and generally better performance as well. But, if you are saturating
> the I/O channel or stuffing all of your data on a tiny subset of the
drives
> in the SAN, it really isn't going to matter very much. The
recommendations
> also vary depending upon whether you have an access pattern that looks
like
> "tradional OLTP", "traditional DW", or a mix of the two.
> Regardless of the performance characteristics, neither one is going to be
> more stable than the other in your case. If the SAN drives disconnect, it
> doesn't matter if it is a cluster or a standalone SQL Server, it isn't
going[vbcol=seagreen]
> to like it. You have to fix the errors on your SAN that are causing the
> disconnects first. If those aren't fixed, there isn't anything you are
> going to be able to do to make the system stable.
> --
> Mike
> http://www.solidqualitylearning.com
> Disclaimer: This communication is an original work and represents my sole
> views on the subject. It does not represent the views of any other person
> or entity either by inference or direct reference.
> "Vai2000" <nospam@.microsoft.com> wrote in message
> news:%23Lb1UxbIGHA.524@.TK2MSFTNGP09.phx.gbl...
becomes
>
sql
Monday, March 26, 2012
RAID 1 vs RAID 10
Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)? We
are wondering what to use for the log files.RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
should be faster than local disks, but that depends on what other systems
are also using the SAN.
"Shiva" <arbitsquare@.hotmail.com> wrote in message
news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
> Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)?
> We are wondering what to use for the log files.
>|||> The SAN should be faster than local disks, but that depends on
> what other systems are also using the SAN.
SAN is not necessarily faster than local disks, and it doesn't depend on
what other systems are using the SAN. Whether you get better performance with
SAN or local disks depends on how they are configured.
Conceivably, you can >almost< always configure local disks to outperform
disks presented from SAN.
Linchi
"Michael D'Angelo" wrote:
> RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
> should be faster than local disks, but that depends on what other systems
> are also using the SAN.
> "Shiva" <arbitsquare@.hotmail.com> wrote in message
> news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
> > Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)?
> > We are wondering what to use for the log files.
> >
>
>|||This is a multi-part message in MIME format.
--000104000206050106050406
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Additionally, RAID 10 is typically only faster than RAID 1 in terms of
read performance. For writes, which transactions logs consist of nearly
100%, both are pretty close in performance. Also, since transaction
logs are sequential and the heads usually stay over the same spot on the
platters, you don't get the random I/O benefit that RAID 10 normally
gives with the striping. So a RAID 10 volume would, under most
circumstances, be no better than a RAID 1 volume for logs.
Kalen Delaney wrote a good section on RAID volumes in Inside SQL Server
2000 - worth a read. Also you can get some good ideas about disk
configuration from reading the data & log layout sections in the TCP-C
benchmark full disclosure reports on www.tcp.org (section 4.2
"Distribution of Tables and Logs" in the IBM full disclosure reports or
section 4.1 "Database Layout" in the HP full disclosure reports).
Microsoft used to use RAID1 for logs from memory but I noticed the most
recent one they had (SQL 2005 1.2M benchmark) used RAID1+0 physical and
then NT striping across those logical RAID volumes. The DB2 3.2M
benchmark and the Oracle's 1.6M benchmark both used RAID5+0 as far as I
can tell (DB2 - stripes across 10 separate RAID5 volumes, each volume
consisting of 14 spindles; Oracle - stripes across 8 RAID5 volumes, each
volume consisting of 12 spindles). So all the top benchmarks tend to
use striping of some sorts, which is interesting since for write
performance it shouldn't be any faster really than straight mirroring.
--
*mike hodgson*
http://sqlnerd.blogspot.com
Linchi Shea wrote:
>>The SAN should be faster than local disks, but that depends on
>>what other systems are also using the SAN.
>>
>SAN is not necessarily faster than local disks, and it doesn't depend on
>what other systems are using the SAN. Whether you get better performance with
>SAN or local disks depends on how they are configured.
>Conceivably, you can >almost< always configure local disks to outperform
>disks presented from SAN.
>Linchi
>"Michael D'Angelo" wrote:
>
>>RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
>>should be faster than local disks, but that depends on what other systems
>>are also using the SAN.
>>"Shiva" <arbitsquare@.hotmail.com> wrote in message
>>news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
>>
>>Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)?
>>We are wondering what to use for the log files.
>>
>>
>>
--000104000206050106050406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Additionally, RAID 10 is typically only faster than RAID 1 in terms
of read performance. For writes, which transactions logs consist of
nearly 100%, both are pretty close in performance. Also, since
transaction logs are sequential and the heads usually stay over the
same spot on the platters, you don't get the random I/O benefit that
RAID 10 normally gives with the striping. So a RAID 10 volume would,
under most circumstances, be no better than a RAID 1 volume for logs.<br>
<br>
Kalen Delaney wrote a good section on RAID volumes in Inside SQL Server
2000 - worth a read. Also you can get some good ideas about disk
configuration from reading the data & log layout sections in the
TCP-C benchmark full disclosure reports on <a class="moz-txt-link-abbreviated" href="http://links.10026.com/?link=www.tcp.org</a>">http://www.tcp.org">www.tcp.org</a> (section 4.2
"Distribution of Tables and Logs" in the IBM full disclosure reports or
section 4.1 "Database Layout" in the HP full disclosure reports).Â
Microsoft used to use RAID1 for logs from memory but I noticed the most
recent one they had (SQL 2005 1.2M benchmark) used RAID1+0 physical and
then NT striping across those logical RAID volumes. The DB2 3.2M
benchmark and the </tt><tt>Oracle's 1.6M benchmark both </tt><tt>used
RAID5+0 as far as I can tell (DB2 - stripes across 10 separate RAID5
volumes, each volume consisting of 14 spindles; Oracle - stripes across
8 RAID5 volumes, each volume consisting of 12 spindles). So all the
top benchmarks tend to use striping of some sorts, which is interesting
since for write performance it shouldn't be any faster really than
straight mirroring.<br>
</tt>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2"><a href="http://links.10026.com/?link=http://sqlnerd.blogspot.com</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
Linchi Shea wrote:
<blockquote cite="mid3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com"
type="cite">
<blockquote type="cite">
<pre wrap="">The SAN should be faster than local disks, but that depends on
what other systems are also using the SAN.
</pre>
</blockquote>
<pre wrap=""><!-->
SAN is not necessarily faster than local disks, and it doesn't depend on
what other systems are using the SAN. Whether you get better performance with
SAN or local disks depends on how they are configured.
Conceivably, you can >almost< always configure local disks to outperform
disks presented from SAN.
Linchi
"Michael D'Angelo" wrote:
</pre>
<blockquote type="cite">
<pre wrap="">RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
should be faster than local disks, but that depends on what other systems
are also using the SAN.
"Shiva" <a class="moz-txt-link-rfc2396E" href="http://links.10026.com/?link=mailto:arbitsquare@.hotmail.com"><arbitsquare@.hotmail.com></a> wrote in message
<a class="moz-txt-link-freetext" href="http://links.10026.com/?link=news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl">news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)?
We are wondering what to use for the log files.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
</body>
</html>
--000104000206050106050406--|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com...
>> The SAN should be faster than local disks, but that depends on
>> what other systems are also using the SAN.
> SAN is not necessarily faster than local disks, and it doesn't depend on
> what other systems are using the SAN. Whether you get better performance
> with
> SAN or local disks depends on how they are configured.
> Conceivably, you can >almost< always configure local disks to outperform
> disks presented from SAN.
> Linchi
I'd be interested to see when that would be the case. If both cases have
the same disk configuration, but your local raid controller has, say, 128mb
of cache, but the SAN has a 2gb cache, wouldn't the SAN conceivable
outperform local disk?
Of course I can see if local disks or the SAN can provide more physical
disks than the other, then that would make a difference.
> "Michael D'Angelo" wrote:
>> RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
>> should be faster than local disks, but that depends on what other systems
>> are also using the SAN.
>> "Shiva" <arbitsquare@.hotmail.com> wrote in message
>> news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
>> > Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a
>> > SAN)?
>> > We are wondering what to use for the log files.
>> >
>>|||This is a multi-part message in MIME format.
--050308030100090101020702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
The most likely factor that would influence SAN disk performance would
be load applied by other hosts (mostly on the disks themselves, but also
the SAN cache & controllers). With the local disks they're always 100%
dedicated to the SQL host, but often (not always but often) the RAID
group on the SAN that you get your LUNs for SQL from will also be used
by other systems like email, other SQL hosts, file servers, VMs, etc.
Also, depending on how the cache on the SAN is configured it may not be
very useful for what SQL will use the LUN for (so that 2GB cache may be
useless). For example, if the cache is configured mostly for read, then
that's not going to help transaction log LUNs, which are almost
exclusively write only.
Most of the time I would think SAN LUNs ought to give better
performance, all things being equal, but I can see cases (and have
experienced them myself - sharing with Exchange can be a dog) where
local DAS disks can yield better performance.
--
*mike hodgson*
http://sqlnerd.blogspot.com
Michael D'Angelo wrote:
>"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
>news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com...
>
>>The SAN should be faster than local disks, but that depends on
>>what other systems are also using the SAN.
>>
>>SAN is not necessarily faster than local disks, and it doesn't depend on
>>what other systems are using the SAN. Whether you get better performance
>>with
>>SAN or local disks depends on how they are configured.
>>Conceivably, you can >almost< always configure local disks to outperform
>>disks presented from SAN.
>>Linchi
>>
>I'd be interested to see when that would be the case. If both cases have
>the same disk configuration, but your local raid controller has, say, 128mb
>of cache, but the SAN has a 2gb cache, wouldn't the SAN conceivable
>outperform local disk?
>Of course I can see if local disks or the SAN can provide more physical
>disks than the other, then that would make a difference.
>
>>"Michael D'Angelo" wrote:
>>
>>RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
>>should be faster than local disks, but that depends on what other systems
>>are also using the SAN.
>>"Shiva" <arbitsquare@.hotmail.com> wrote in message
>>news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
>>
>>Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a
>>SAN)?
>>We are wondering what to use for the log files.
>>
>>
>>
>
>
--050308030100090101020702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>The most likely factor that would influence SAN disk performance
would be load applied by other hosts (mostly on the disks themselves,
but also the SAN cache & controllers). With the local disks
they're always 100% dedicated to the SQL host, but often (not always
but often) the RAID group on the SAN that you get your LUNs for SQL
from will also be used by other systems like email, other SQL hosts,
file servers, VMs, etc.<br>
<br>
Also, depending on how the cache on the SAN is configured it may not be
very useful for what SQL will use the LUN for (so that 2GB cache may be
useless). For example, if the cache is configured mostly for read,
then that's not going to help transaction log LUNs, which are almost
exclusively write only.<br>
<br>
Most of the time I would think SAN LUNs ought to give better
performance, all things being equal, but I can see cases (and have
experienced them myself - sharing with Exchange can be a dog) where
local DAS disks can yield better performance.<br>
</tt>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2"><a href="http://links.10026.com/?link=http://sqlnerd.blogspot.com</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
Michael D'Angelo wrote:
<blockquote cite="miduHUeVXHdGHA.1208@.TK2MSFTNGP02.phx.gbl" type="cite">
<pre wrap="">"Linchi Shea" <a class="moz-txt-link-rfc2396E" href="http://links.10026.com/?link=mailto:LinchiShea@.discussions.microsoft.com"><LinchiShea@.discussions.microsoft.com></a> wrote in message
<a class="moz-txt-link-freetext" href="http://links.10026.com/?link=news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com">news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com</a>...
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The SAN should be faster than local disks, but that depends on
what other systems are also using the SAN.
</pre>
</blockquote>
<pre wrap="">SAN is not necessarily faster than local disks, and it doesn't depend on
what other systems are using the SAN. Whether you get better performance
with
SAN or local disks depends on how they are configured.
Conceivably, you can >almost< always configure local disks to outperform
disks presented from SAN.
Linchi
</pre>
</blockquote>
<pre wrap=""><!-->
I'd be interested to see when that would be the case. If both cases have
the same disk configuration, but your local raid controller has, say, 128mb
of cache, but the SAN has a 2gb cache, wouldn't the SAN conceivable
outperform local disk?
Of course I can see if local disks or the SAN can provide more physical
disks than the other, then that would make a difference.
</pre>
<blockquote type="cite">
<pre wrap="">"Michael D'Angelo" wrote:
</pre>
<blockquote type="cite">
<pre wrap="">RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
should be faster than local disks, but that depends on what other systems
are also using the SAN.
"Shiva" <a class="moz-txt-link-rfc2396E" href="http://links.10026.com/?link=mailto:arbitsquare@.hotmail.com"><arbitsquare@.hotmail.com></a> wrote in message
<a class="moz-txt-link-freetext" href="http://links.10026.com/?link=news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl">news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a
SAN)?
We are wondering what to use for the log files.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!-->
</pre>
</blockquote>
</body>
</html>
--050308030100090101020702--
are wondering what to use for the log files.RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
should be faster than local disks, but that depends on what other systems
are also using the SAN.
"Shiva" <arbitsquare@.hotmail.com> wrote in message
news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
> Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)?
> We are wondering what to use for the log files.
>|||> The SAN should be faster than local disks, but that depends on
> what other systems are also using the SAN.
SAN is not necessarily faster than local disks, and it doesn't depend on
what other systems are using the SAN. Whether you get better performance with
SAN or local disks depends on how they are configured.
Conceivably, you can >almost< always configure local disks to outperform
disks presented from SAN.
Linchi
"Michael D'Angelo" wrote:
> RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
> should be faster than local disks, but that depends on what other systems
> are also using the SAN.
> "Shiva" <arbitsquare@.hotmail.com> wrote in message
> news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
> > Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)?
> > We are wondering what to use for the log files.
> >
>
>|||This is a multi-part message in MIME format.
--000104000206050106050406
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Additionally, RAID 10 is typically only faster than RAID 1 in terms of
read performance. For writes, which transactions logs consist of nearly
100%, both are pretty close in performance. Also, since transaction
logs are sequential and the heads usually stay over the same spot on the
platters, you don't get the random I/O benefit that RAID 10 normally
gives with the striping. So a RAID 10 volume would, under most
circumstances, be no better than a RAID 1 volume for logs.
Kalen Delaney wrote a good section on RAID volumes in Inside SQL Server
2000 - worth a read. Also you can get some good ideas about disk
configuration from reading the data & log layout sections in the TCP-C
benchmark full disclosure reports on www.tcp.org (section 4.2
"Distribution of Tables and Logs" in the IBM full disclosure reports or
section 4.1 "Database Layout" in the HP full disclosure reports).
Microsoft used to use RAID1 for logs from memory but I noticed the most
recent one they had (SQL 2005 1.2M benchmark) used RAID1+0 physical and
then NT striping across those logical RAID volumes. The DB2 3.2M
benchmark and the Oracle's 1.6M benchmark both used RAID5+0 as far as I
can tell (DB2 - stripes across 10 separate RAID5 volumes, each volume
consisting of 14 spindles; Oracle - stripes across 8 RAID5 volumes, each
volume consisting of 12 spindles). So all the top benchmarks tend to
use striping of some sorts, which is interesting since for write
performance it shouldn't be any faster really than straight mirroring.
--
*mike hodgson*
http://sqlnerd.blogspot.com
Linchi Shea wrote:
>>The SAN should be faster than local disks, but that depends on
>>what other systems are also using the SAN.
>>
>SAN is not necessarily faster than local disks, and it doesn't depend on
>what other systems are using the SAN. Whether you get better performance with
>SAN or local disks depends on how they are configured.
>Conceivably, you can >almost< always configure local disks to outperform
>disks presented from SAN.
>Linchi
>"Michael D'Angelo" wrote:
>
>>RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
>>should be faster than local disks, but that depends on what other systems
>>are also using the SAN.
>>"Shiva" <arbitsquare@.hotmail.com> wrote in message
>>news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
>>
>>Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)?
>>We are wondering what to use for the log files.
>>
>>
>>
--000104000206050106050406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Additionally, RAID 10 is typically only faster than RAID 1 in terms
of read performance. For writes, which transactions logs consist of
nearly 100%, both are pretty close in performance. Also, since
transaction logs are sequential and the heads usually stay over the
same spot on the platters, you don't get the random I/O benefit that
RAID 10 normally gives with the striping. So a RAID 10 volume would,
under most circumstances, be no better than a RAID 1 volume for logs.<br>
<br>
Kalen Delaney wrote a good section on RAID volumes in Inside SQL Server
2000 - worth a read. Also you can get some good ideas about disk
configuration from reading the data & log layout sections in the
TCP-C benchmark full disclosure reports on <a class="moz-txt-link-abbreviated" href="http://links.10026.com/?link=www.tcp.org</a>">http://www.tcp.org">www.tcp.org</a> (section 4.2
"Distribution of Tables and Logs" in the IBM full disclosure reports or
section 4.1 "Database Layout" in the HP full disclosure reports).Â
Microsoft used to use RAID1 for logs from memory but I noticed the most
recent one they had (SQL 2005 1.2M benchmark) used RAID1+0 physical and
then NT striping across those logical RAID volumes. The DB2 3.2M
benchmark and the </tt><tt>Oracle's 1.6M benchmark both </tt><tt>used
RAID5+0 as far as I can tell (DB2 - stripes across 10 separate RAID5
volumes, each volume consisting of 14 spindles; Oracle - stripes across
8 RAID5 volumes, each volume consisting of 12 spindles). So all the
top benchmarks tend to use striping of some sorts, which is interesting
since for write performance it shouldn't be any faster really than
straight mirroring.<br>
</tt>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2"><a href="http://links.10026.com/?link=http://sqlnerd.blogspot.com</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
Linchi Shea wrote:
<blockquote cite="mid3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com"
type="cite">
<blockquote type="cite">
<pre wrap="">The SAN should be faster than local disks, but that depends on
what other systems are also using the SAN.
</pre>
</blockquote>
<pre wrap=""><!-->
SAN is not necessarily faster than local disks, and it doesn't depend on
what other systems are using the SAN. Whether you get better performance with
SAN or local disks depends on how they are configured.
Conceivably, you can >almost< always configure local disks to outperform
disks presented from SAN.
Linchi
"Michael D'Angelo" wrote:
</pre>
<blockquote type="cite">
<pre wrap="">RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
should be faster than local disks, but that depends on what other systems
are also using the SAN.
"Shiva" <a class="moz-txt-link-rfc2396E" href="http://links.10026.com/?link=mailto:arbitsquare@.hotmail.com"><arbitsquare@.hotmail.com></a> wrote in message
<a class="moz-txt-link-freetext" href="http://links.10026.com/?link=news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl">news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)?
We are wondering what to use for the log files.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
</body>
</html>
--000104000206050106050406--|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com...
>> The SAN should be faster than local disks, but that depends on
>> what other systems are also using the SAN.
> SAN is not necessarily faster than local disks, and it doesn't depend on
> what other systems are using the SAN. Whether you get better performance
> with
> SAN or local disks depends on how they are configured.
> Conceivably, you can >almost< always configure local disks to outperform
> disks presented from SAN.
> Linchi
I'd be interested to see when that would be the case. If both cases have
the same disk configuration, but your local raid controller has, say, 128mb
of cache, but the SAN has a 2gb cache, wouldn't the SAN conceivable
outperform local disk?
Of course I can see if local disks or the SAN can provide more physical
disks than the other, then that would make a difference.
> "Michael D'Angelo" wrote:
>> RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
>> should be faster than local disks, but that depends on what other systems
>> are also using the SAN.
>> "Shiva" <arbitsquare@.hotmail.com> wrote in message
>> news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
>> > Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a
>> > SAN)?
>> > We are wondering what to use for the log files.
>> >
>>|||This is a multi-part message in MIME format.
--050308030100090101020702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
The most likely factor that would influence SAN disk performance would
be load applied by other hosts (mostly on the disks themselves, but also
the SAN cache & controllers). With the local disks they're always 100%
dedicated to the SQL host, but often (not always but often) the RAID
group on the SAN that you get your LUNs for SQL from will also be used
by other systems like email, other SQL hosts, file servers, VMs, etc.
Also, depending on how the cache on the SAN is configured it may not be
very useful for what SQL will use the LUN for (so that 2GB cache may be
useless). For example, if the cache is configured mostly for read, then
that's not going to help transaction log LUNs, which are almost
exclusively write only.
Most of the time I would think SAN LUNs ought to give better
performance, all things being equal, but I can see cases (and have
experienced them myself - sharing with Exchange can be a dog) where
local DAS disks can yield better performance.
--
*mike hodgson*
http://sqlnerd.blogspot.com
Michael D'Angelo wrote:
>"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
>news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com...
>
>>The SAN should be faster than local disks, but that depends on
>>what other systems are also using the SAN.
>>
>>SAN is not necessarily faster than local disks, and it doesn't depend on
>>what other systems are using the SAN. Whether you get better performance
>>with
>>SAN or local disks depends on how they are configured.
>>Conceivably, you can >almost< always configure local disks to outperform
>>disks presented from SAN.
>>Linchi
>>
>I'd be interested to see when that would be the case. If both cases have
>the same disk configuration, but your local raid controller has, say, 128mb
>of cache, but the SAN has a 2gb cache, wouldn't the SAN conceivable
>outperform local disk?
>Of course I can see if local disks or the SAN can provide more physical
>disks than the other, then that would make a difference.
>
>>"Michael D'Angelo" wrote:
>>
>>RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
>>should be faster than local disks, but that depends on what other systems
>>are also using the SAN.
>>"Shiva" <arbitsquare@.hotmail.com> wrote in message
>>news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
>>
>>Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a
>>SAN)?
>>We are wondering what to use for the log files.
>>
>>
>>
>
>
--050308030100090101020702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>The most likely factor that would influence SAN disk performance
would be load applied by other hosts (mostly on the disks themselves,
but also the SAN cache & controllers). With the local disks
they're always 100% dedicated to the SQL host, but often (not always
but often) the RAID group on the SAN that you get your LUNs for SQL
from will also be used by other systems like email, other SQL hosts,
file servers, VMs, etc.<br>
<br>
Also, depending on how the cache on the SAN is configured it may not be
very useful for what SQL will use the LUN for (so that 2GB cache may be
useless). For example, if the cache is configured mostly for read,
then that's not going to help transaction log LUNs, which are almost
exclusively write only.<br>
<br>
Most of the time I would think SAN LUNs ought to give better
performance, all things being equal, but I can see cases (and have
experienced them myself - sharing with Exchange can be a dog) where
local DAS disks can yield better performance.<br>
</tt>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2"><a href="http://links.10026.com/?link=http://sqlnerd.blogspot.com</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
Michael D'Angelo wrote:
<blockquote cite="miduHUeVXHdGHA.1208@.TK2MSFTNGP02.phx.gbl" type="cite">
<pre wrap="">"Linchi Shea" <a class="moz-txt-link-rfc2396E" href="http://links.10026.com/?link=mailto:LinchiShea@.discussions.microsoft.com"><LinchiShea@.discussions.microsoft.com></a> wrote in message
<a class="moz-txt-link-freetext" href="http://links.10026.com/?link=news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com">news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com</a>...
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The SAN should be faster than local disks, but that depends on
what other systems are also using the SAN.
</pre>
</blockquote>
<pre wrap="">SAN is not necessarily faster than local disks, and it doesn't depend on
what other systems are using the SAN. Whether you get better performance
with
SAN or local disks depends on how they are configured.
Conceivably, you can >almost< always configure local disks to outperform
disks presented from SAN.
Linchi
</pre>
</blockquote>
<pre wrap=""><!-->
I'd be interested to see when that would be the case. If both cases have
the same disk configuration, but your local raid controller has, say, 128mb
of cache, but the SAN has a 2gb cache, wouldn't the SAN conceivable
outperform local disk?
Of course I can see if local disks or the SAN can provide more physical
disks than the other, then that would make a difference.
</pre>
<blockquote type="cite">
<pre wrap="">"Michael D'Angelo" wrote:
</pre>
<blockquote type="cite">
<pre wrap="">RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
should be faster than local disks, but that depends on what other systems
are also using the SAN.
"Shiva" <a class="moz-txt-link-rfc2396E" href="http://links.10026.com/?link=mailto:arbitsquare@.hotmail.com"><arbitsquare@.hotmail.com></a> wrote in message
<a class="moz-txt-link-freetext" href="http://links.10026.com/?link=news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl">news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a
SAN)?
We are wondering what to use for the log files.
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!-->
</pre>
</blockquote>
</body>
</html>
--050308030100090101020702--
RAID 1 vs RAID 10
Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)? We
are wondering what to use for the log files.RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
should be faster than local disks, but that depends on what other systems
are also using the SAN.
"Shiva" <arbitsquare@.hotmail.com> wrote in message
news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
> Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)?
> We are wondering what to use for the log files.
>|||> The SAN should be faster than local disks, but that depends on
> what other systems are also using the SAN.
SAN is not necessarily faster than local disks, and it doesn't depend on
what other systems are using the SAN. Whether you get better performance wit
h
SAN or local disks depends on how they are configured.
Conceivably, you can >almost< always configure local disks to outperform
disks presented from SAN.
Linchi
"Michael D'Angelo" wrote:
> RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
> should be faster than local disks, but that depends on what other systems
> are also using the SAN.
> "Shiva" <arbitsquare@.hotmail.com> wrote in message
> news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
>
>|||Additionally, RAID 10 is typically only faster than RAID 1 in terms of
read performance. For writes, which transactions logs consist of nearly
100%, both are pretty close in performance. Also, since transaction
logs are sequential and the heads usually stay over the same spot on the
platters, you don't get the random I/O benefit that RAID 10 normally
gives with the striping. So a RAID 10 volume would, under most
circumstances, be no better than a RAID 1 volume for logs.
Kalen Delaney wrote a good section on RAID volumes in Inside SQL Server
2000 - worth a read. Also you can get some good ideas about disk
configuration from reading the data & log layout sections in the TCP-C
benchmark full disclosure reports on www.tcp.org (section 4.2
"Distribution of Tables and Logs" in the IBM full disclosure reports or
section 4.1 "Database Layout" in the HP full disclosure reports).
Microsoft used to use RAID1 for logs from memory but I noticed the most
recent one they had (SQL 2005 1.2M benchmark) used RAID1+0 physical and
then NT striping across those logical RAID volumes. The DB2 3.2M
benchmark and the Oracle's 1.6M benchmark both used RAID5+0 as far as I
can tell (DB2 - stripes across 10 separate RAID5 volumes, each volume
consisting of 14 spindles; Oracle - stripes across 8 RAID5 volumes, each
volume consisting of 12 spindles). So all the top benchmarks tend to
use striping of some sorts, which is interesting since for write
performance it shouldn't be any faster really than straight mirroring.
*mike hodgson*
http://sqlnerd.blogspot.com
Linchi Shea wrote:
[vbcol=seagreen]
>SAN is not necessarily faster than local disks, and it doesn't depend on
>what other systems are using the SAN. Whether you get better performance wi
th
>SAN or local disks depends on how they are configured.
>Conceivably, you can >almost< always configure local disks to outperform
>disks presented from SAN.
>Linchi
>"Michael D'Angelo" wrote:
>
>|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com...
> SAN is not necessarily faster than local disks, and it doesn't depend on
> what other systems are using the SAN. Whether you get better performance
> with
> SAN or local disks depends on how they are configured.
> Conceivably, you can >almost< always configure local disks to outperform
> disks presented from SAN.
> Linchi
I'd be interested to see when that would be the case. If both cases have
the same disk configuration, but your local raid controller has, say, 128mb
of cache, but the SAN has a 2gb cache, wouldn't the SAN conceivable
outperform local disk?
Of course I can see if local disks or the SAN can provide more physical
disks than the other, then that would make a difference.
[vbcol=seagreen]
> "Michael D'Angelo" wrote:
>|||The most likely factor that would influence SAN disk performance would
be load applied by other hosts (mostly on the disks themselves, but also
the SAN cache & controllers). With the local disks they're always 100%
dedicated to the SQL host, but often (not always but often) the RAID
group on the SAN that you get your LUNs for SQL from will also be used
by other systems like email, other SQL hosts, file servers, VMs, etc.
Also, depending on how the cache on the SAN is configured it may not be
very useful for what SQL will use the LUN for (so that 2GB cache may be
useless). For example, if the cache is configured mostly for read, then
that's not going to help transaction log LUNs, which are almost
exclusively write only.
Most of the time I would think SAN LUNs ought to give better
performance, all things being equal, but I can see cases (and have
experienced them myself - sharing with Exchange can be a dog) where
local DAS disks can yield better performance.
*mike hodgson*
http://sqlnerd.blogspot.com
Michael D'Angelo wrote:
>"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
>news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com...
>
>I'd be interested to see when that would be the case. If both cases have
>the same disk configuration, but your local raid controller has, say, 128mb
>of cache, but the SAN has a 2gb cache, wouldn't the SAN conceivable
>outperform local disk?
>Of course I can see if local disks or the SAN can provide more physical
>disks than the other, then that would make a difference.
>
>
>
>
are wondering what to use for the log files.RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
should be faster than local disks, but that depends on what other systems
are also using the SAN.
"Shiva" <arbitsquare@.hotmail.com> wrote in message
news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
> Which one is faster RAID 1 (on local disk drives) or RAID 10 (on a SAN)?
> We are wondering what to use for the log files.
>|||> The SAN should be faster than local disks, but that depends on
> what other systems are also using the SAN.
SAN is not necessarily faster than local disks, and it doesn't depend on
what other systems are using the SAN. Whether you get better performance wit
h
SAN or local disks depends on how they are configured.
Conceivably, you can >almost< always configure local disks to outperform
disks presented from SAN.
Linchi
"Michael D'Angelo" wrote:
> RAID10 will be faster than RAID1 whether it's on the SAN or not. The SAN
> should be faster than local disks, but that depends on what other systems
> are also using the SAN.
> "Shiva" <arbitsquare@.hotmail.com> wrote in message
> news:Oj9AKs5cGHA.1208@.TK2MSFTNGP04.phx.gbl...
>
>|||Additionally, RAID 10 is typically only faster than RAID 1 in terms of
read performance. For writes, which transactions logs consist of nearly
100%, both are pretty close in performance. Also, since transaction
logs are sequential and the heads usually stay over the same spot on the
platters, you don't get the random I/O benefit that RAID 10 normally
gives with the striping. So a RAID 10 volume would, under most
circumstances, be no better than a RAID 1 volume for logs.
Kalen Delaney wrote a good section on RAID volumes in Inside SQL Server
2000 - worth a read. Also you can get some good ideas about disk
configuration from reading the data & log layout sections in the TCP-C
benchmark full disclosure reports on www.tcp.org (section 4.2
"Distribution of Tables and Logs" in the IBM full disclosure reports or
section 4.1 "Database Layout" in the HP full disclosure reports).
Microsoft used to use RAID1 for logs from memory but I noticed the most
recent one they had (SQL 2005 1.2M benchmark) used RAID1+0 physical and
then NT striping across those logical RAID volumes. The DB2 3.2M
benchmark and the Oracle's 1.6M benchmark both used RAID5+0 as far as I
can tell (DB2 - stripes across 10 separate RAID5 volumes, each volume
consisting of 14 spindles; Oracle - stripes across 8 RAID5 volumes, each
volume consisting of 12 spindles). So all the top benchmarks tend to
use striping of some sorts, which is interesting since for write
performance it shouldn't be any faster really than straight mirroring.
*mike hodgson*
http://sqlnerd.blogspot.com
Linchi Shea wrote:
[vbcol=seagreen]
>SAN is not necessarily faster than local disks, and it doesn't depend on
>what other systems are using the SAN. Whether you get better performance wi
th
>SAN or local disks depends on how they are configured.
>Conceivably, you can >almost< always configure local disks to outperform
>disks presented from SAN.
>Linchi
>"Michael D'Angelo" wrote:
>
>|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com...
> SAN is not necessarily faster than local disks, and it doesn't depend on
> what other systems are using the SAN. Whether you get better performance
> with
> SAN or local disks depends on how they are configured.
> Conceivably, you can >almost< always configure local disks to outperform
> disks presented from SAN.
> Linchi
I'd be interested to see when that would be the case. If both cases have
the same disk configuration, but your local raid controller has, say, 128mb
of cache, but the SAN has a 2gb cache, wouldn't the SAN conceivable
outperform local disk?
Of course I can see if local disks or the SAN can provide more physical
disks than the other, then that would make a difference.
[vbcol=seagreen]
> "Michael D'Angelo" wrote:
>|||The most likely factor that would influence SAN disk performance would
be load applied by other hosts (mostly on the disks themselves, but also
the SAN cache & controllers). With the local disks they're always 100%
dedicated to the SQL host, but often (not always but often) the RAID
group on the SAN that you get your LUNs for SQL from will also be used
by other systems like email, other SQL hosts, file servers, VMs, etc.
Also, depending on how the cache on the SAN is configured it may not be
very useful for what SQL will use the LUN for (so that 2GB cache may be
useless). For example, if the cache is configured mostly for read, then
that's not going to help transaction log LUNs, which are almost
exclusively write only.
Most of the time I would think SAN LUNs ought to give better
performance, all things being equal, but I can see cases (and have
experienced them myself - sharing with Exchange can be a dog) where
local DAS disks can yield better performance.
*mike hodgson*
http://sqlnerd.blogspot.com
Michael D'Angelo wrote:
>"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
>news:3EAE716E-B80B-41E8-86BD-53C672D67935@.microsoft.com...
>
>I'd be interested to see when that would be the case. If both cases have
>the same disk configuration, but your local raid controller has, say, 128mb
>of cache, but the SAN has a 2gb cache, wouldn't the SAN conceivable
>outperform local disk?
>Of course I can see if local disks or the SAN can provide more physical
>disks than the other, then that would make a difference.
>
>
>
>
Wednesday, March 21, 2012
Qurom Drive
Hello,
Is 1 GB drive setup on the Windows LDM? How do you setup your qurom drive. I have 1 GB allocated from my SAn of it. How do I make it local?
Here is a great starting place for your questions:
http://www.microsoft.com/technet/pro.../confclus.mspx
Cheers,
Rod
"Lonate Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:96B61F2C-4755-41D9-B6F0-AE7B88C14983@.microsoft.com...
> Hello,
> Is 1 GB drive setup on the Windows LDM? How do you setup your qurom
drive. I have 1 GB allocated from my SAn of it. How do I make it local?
Is 1 GB drive setup on the Windows LDM? How do you setup your qurom drive. I have 1 GB allocated from my SAn of it. How do I make it local?
Here is a great starting place for your questions:
http://www.microsoft.com/technet/pro.../confclus.mspx
Cheers,
Rod
"Lonate Jones" <anonymous@.discussions.microsoft.com> wrote in message
news:96B61F2C-4755-41D9-B6F0-AE7B88C14983@.microsoft.com...
> Hello,
> Is 1 GB drive setup on the Windows LDM? How do you setup your qurom
drive. I have 1 GB allocated from my SAn of it. How do I make it local?
Tuesday, March 20, 2012
Quorum Disk Question.
We will be setting up a Windows 2000 SQL server on a two node 2003 Cluster
connected to an HP SAN.
Reading through the whitepapers and watching the webcast on how to setup
everything says to keep the data files on a seperate disk from the quorum
drive.
This will not be a problem, however we currently run 2 two node file and
print clusters one 2000 and one 2003 where we have the quorum drive the same
as the shared data and the cluster works fine and failsover correctly.
Question:
Why is it nessary or even best practice to seperate the quroum from the
data? I have searched high and low for an ansewer but the only thing I can
find is do not do it on SQL.
That is because if the controlling node cannot access the quorum drive in a
timely fashion, it will fail over to the other node. If this happens too
often, the entire cluster will go offline. With Windows 2003, Microsoft
changed its recommendations for MSDTC from allowing it on the quorum disk to
advising it be put on a separate set of physical disks. This is after
observing some configurations where very high DTC activity created timeout
issues that did force some clusters offline.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"DRay" <DavidRay@.discussions.microsoft.com> wrote in message
news:68868872-9EF0-4317-96A0-825B6F76C387@.microsoft.com...
> We will be setting up a Windows 2000 SQL server on a two node 2003 Cluster
> connected to an HP SAN.
> Reading through the whitepapers and watching the webcast on how to setup
> everything says to keep the data files on a seperate disk from the quorum
> drive.
> This will not be a problem, however we currently run 2 two node file and
> print clusters one 2000 and one 2003 where we have the quorum drive the
> same
> as the shared data and the cluster works fine and failsover correctly.
> Question:
> Why is it nessary or even best practice to seperate the quroum from the
> data? I have searched high and low for an ansewer but the only thing I can
> find is do not do it on SQL.
|||Thank you sir that answers my question.
David Ray
Systems Administrator
"Geoff N. Hiten" wrote:
> That is because if the controlling node cannot access the quorum drive in a
> timely fashion, it will fail over to the other node. If this happens too
> often, the entire cluster will go offline. With Windows 2003, Microsoft
> changed its recommendations for MSDTC from allowing it on the quorum disk to
> advising it be put on a separate set of physical disks. This is after
> observing some configurations where very high DTC activity created timeout
> issues that did force some clusters offline.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "DRay" <DavidRay@.discussions.microsoft.com> wrote in message
> news:68868872-9EF0-4317-96A0-825B6F76C387@.microsoft.com...
>
>
connected to an HP SAN.
Reading through the whitepapers and watching the webcast on how to setup
everything says to keep the data files on a seperate disk from the quorum
drive.
This will not be a problem, however we currently run 2 two node file and
print clusters one 2000 and one 2003 where we have the quorum drive the same
as the shared data and the cluster works fine and failsover correctly.
Question:
Why is it nessary or even best practice to seperate the quroum from the
data? I have searched high and low for an ansewer but the only thing I can
find is do not do it on SQL.
That is because if the controlling node cannot access the quorum drive in a
timely fashion, it will fail over to the other node. If this happens too
often, the entire cluster will go offline. With Windows 2003, Microsoft
changed its recommendations for MSDTC from allowing it on the quorum disk to
advising it be put on a separate set of physical disks. This is after
observing some configurations where very high DTC activity created timeout
issues that did force some clusters offline.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"DRay" <DavidRay@.discussions.microsoft.com> wrote in message
news:68868872-9EF0-4317-96A0-825B6F76C387@.microsoft.com...
> We will be setting up a Windows 2000 SQL server on a two node 2003 Cluster
> connected to an HP SAN.
> Reading through the whitepapers and watching the webcast on how to setup
> everything says to keep the data files on a seperate disk from the quorum
> drive.
> This will not be a problem, however we currently run 2 two node file and
> print clusters one 2000 and one 2003 where we have the quorum drive the
> same
> as the shared data and the cluster works fine and failsover correctly.
> Question:
> Why is it nessary or even best practice to seperate the quroum from the
> data? I have searched high and low for an ansewer but the only thing I can
> find is do not do it on SQL.
|||Thank you sir that answers my question.
David Ray
Systems Administrator
"Geoff N. Hiten" wrote:
> That is because if the controlling node cannot access the quorum drive in a
> timely fashion, it will fail over to the other node. If this happens too
> often, the entire cluster will go offline. With Windows 2003, Microsoft
> changed its recommendations for MSDTC from allowing it on the quorum disk to
> advising it be put on a separate set of physical disks. This is after
> observing some configurations where very high DTC activity created timeout
> issues that did force some clusters offline.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
>
> "DRay" <DavidRay@.discussions.microsoft.com> wrote in message
> news:68868872-9EF0-4317-96A0-825B6F76C387@.microsoft.com...
>
>
Subscribe to:
Posts (Atom)