Tuesday, February 21, 2012

Running SQL database off of SAN -- is it feasible ?

Hi,
I'm trying to create a home for a database. The database will ultimately
reach approximately 200Gb in size. Usage patterns will consist of
approximately 80% read, 20% write. The vast majority of the reads will
require random access to small chunks of data (less than 64k).
Two SQL Server machines need to be connected to the same database. The
primary SQL Server will be a very powerful machine (4 CPUs). The second SQL
Server will be a machine of lesser capabilities and will only come online if
the primary data server fails. This concept, as it has been explained to me,
is known as "failover."
My job is to investigate various solutions for housing the data. I am
considering the following storage device:
http://www-1.ibm.com/servers/storag...4100/index.html
This device holds 14 drives and transmits data via a mechanism called
Fibre Channel, which as far as I can tell, supports a throughput of 2Gbps.
Here are my questions and concerns:
1) Is this device suitable for hosting a database meeting the
characteristics and requirements that I've described?
2) Assuming that I placed 14 drives in this storage device, how would I
partition it? I've read that the transaction log should be on a separate
RAID 1 volume, so perhaps I would allocate drives 1 & 2 as a RAID 1 volume
and 3-14 as RAID 1+0 ? What do you recommend?
3) I'm concerned because the Fibre Channel maxes out at 2Gbps. This
equates to only 256MBps, as opposed to SCSI which is 320MBps. Is this even a
relevant concern given that most I/O will be random, not sequential, and
therefore I may not even be hitting the 256MBps cap anyway?
I won't actually be the one installing the storage system. I'll
obviously need a professional for that. I just want to do enough research to
determine whether or not the slick salesman who sells us the solution is
giving me accurate information regarding the suitability of various storage
solutions.
Thanks for the help,
David> Two SQL Server machines need to be connected to the same database. The
> primary SQL Server will be a very powerful machine (4 CPUs). The second SQ
L
> Server will be a machine of lesser capabilities and will only come online
if
> the primary data server fails. This concept, as it has been explained to m
e,
> is known as "failover."
> My job is to investigate various solutions for housing the data. I am
> considering the following storage device:
> http://www-1.ibm.com/servers/storag...4100/index.html
We use EMC SAN devices. Pricy but well worth it.

> 1) Is this device suitable for hosting a database meeting the
> characteristics and requirements that I've described?
You probably shouldn't have any problems in that configuration.

> 2) Assuming that I placed 14 drives in this storage device, how would
I
> partition it? I've read that the transaction log should be on a separate
> RAID 1 volume, so perhaps I would allocate drives 1 & 2 as a RAID 1 volume
> and 3-14 as RAID 1+0 ? What do you recommend?
I recommend you go over this with the people who configure your SAN. They
know its specific implementations, where it is fast, where it can lag, etc.
Hopefully they have SQL Server experts on board (likely mostly DB2 people),
if not, see above... Have EMC come in and talk to you before you decide on a
specific device (and even if you don't go with them, they'll likely give you
relevant information that at worst you can use as confirmation to what the
other guys tell you).

> 3) I'm concerned because the Fibre Channel maxes out at 2Gbps. This
> equates to only 256MBps, as opposed to SCSI which is 320MBps. Is this even
a
> relevant concern given that most I/O will be random, not sequential, and
> therefore I may not even be hitting the 256MBps cap anyway?
You probably won't hit it much, and if you do, you will probably be more
constrained at that point by the network bandwidth sending it over the wire
than by reading it from disk.

> I won't actually be the one installing the storage system. I'll
> obviously need a professional for that. I just want to do enough research
to
> determine whether or not the slick salesman who sells us the solution is
> giving me accurate information regarding the suitability of various storag
e
> solutions.
I can't speak for other vendors, because I was involved too late in the
process, but EMC was very up front with us, stands by their product, and
aren't out to screw you. I would bet I speak for most SAN vendors when I
say that they want to make money but they want to do so by providing you
with the best solution for your scenario, as you present it to them.
NAS, on the other hand, is a completely different ballgame. :-)|||Those Fibre Channel maximums are also per HBA/Channel, of which you can have
several. Moreover, EMC makes a product called Power Path that allows you to
use muliple HBAs and/or channels in a teaming configuration.
Check out this site for some configuration white papers if you're
interested.
http://www.microsoft.com/sql/techin...scalability.asp
This site is full of information. Make sure you scroll through it and read
all of the subtitles.
Sincerely,
Anthony Thomas
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:BE5B9DAF.3235%ten.xoc@.dnartreb.noraa...
> Two SQL Server machines need to be connected to the same database. The
> primary SQL Server will be a very powerful machine (4 CPUs). The second
SQL
> Server will be a machine of lesser capabilities and will only come online
if
> the primary data server fails. This concept, as it has been explained to
me,
> is known as "failover."
> My job is to investigate various solutions for housing the data. I am
> considering the following storage device:
> http://www-1.ibm.com/servers/storag...4100/index.html
We use EMC SAN devices. Pricy but well worth it.

> 1) Is this device suitable for hosting a database meeting the
> characteristics and requirements that I've described?
You probably shouldn't have any problems in that configuration.

> 2) Assuming that I placed 14 drives in this storage device, how would
I
> partition it? I've read that the transaction log should be on a separate
> RAID 1 volume, so perhaps I would allocate drives 1 & 2 as a RAID 1 volume
> and 3-14 as RAID 1+0 ? What do you recommend?
I recommend you go over this with the people who configure your SAN. They
know its specific implementations, where it is fast, where it can lag, etc.
Hopefully they have SQL Server experts on board (likely mostly DB2 people),
if not, see above... Have EMC come in and talk to you before you decide on a
specific device (and even if you don't go with them, they'll likely give you
relevant information that at worst you can use as confirmation to what the
other guys tell you).

> 3) I'm concerned because the Fibre Channel maxes out at 2Gbps. This
> equates to only 256MBps, as opposed to SCSI which is 320MBps. Is this even
a
> relevant concern given that most I/O will be random, not sequential, and
> therefore I may not even be hitting the 256MBps cap anyway?
You probably won't hit it much, and if you do, you will probably be more
constrained at that point by the network bandwidth sending it over the wire
than by reading it from disk.

> I won't actually be the one installing the storage system. I'll
> obviously need a professional for that. I just want to do enough research
to
> determine whether or not the slick salesman who sells us the solution is
> giving me accurate information regarding the suitability of various
storage
> solutions.
I can't speak for other vendors, because I was involved too late in the
process, but EMC was very up front with us, stands by their product, and
aren't out to screw you. I would bet I speak for most SAN vendors when I
say that they want to make money but they want to do so by providing you
with the best solution for your scenario, as you present it to them.
NAS, on the other hand, is a completely different ballgame. :-)|||> http://www.microsoft.com/sql/techin...scalability.asp
> This site is full of information. Make sure you scroll through it and
read
> all of the subtitles.
Anthony,
That's a great link. I appreciate the tip. I'll check out those
articles.
Aaron,
I'll check out EMC. I was thinking that since we are buying our servers
from IBM, it would be a natural decision to buy the storage from them as
well... but after reading your post, I now see that EMC has an excellent
reputation. Perhaps they have a solution that's more suitable. Are there any
other vendors that you think I should investigate? Any thoughts on Hitachi
Data Systems (hds.com)?
David||| We have our main production server with four paths on two 2gb switches
to the EMC SAN. The pathing is active/active so the throughput is quite
impressive. We are also an 80/20 shop, and we have had no issues at all
with disk speed. The main production environment is:
Logs: 4x73gb15k RAID 10
Data: 6x73gb15k RAID 5
I don't know that I would use the DS4100 solution for a SQL Server
environment, especially one that's high-end, high-availability. The
multiple channels (unless it's changed since the fastT days are for failover
only per single host. I could be wrong on this though, so you need to talk
to the vendor.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:#tsMaeQKFHA.2748@.TK2MSFTNGP09.phx.gbl...
> Those Fibre Channel maximums are also per HBA/Channel, of which you can
have
> several. Moreover, EMC makes a product called Power Path that allows you
to
> use muliple HBAs and/or channels in a teaming configuration.
> Check out this site for some configuration white papers if you're
> interested.
> http://www.microsoft.com/sql/techin...scalability.asp
> This site is full of information. Make sure you scroll through it and
read
> all of the subtitles.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
> news:BE5B9DAF.3235%ten.xoc@.dnartreb.noraa...
The[vbcol=seagreen]
> SQL
online[vbcol=seagreen]
> if
> me,
am[vbcol=seagreen]
> We use EMC SAN devices. Pricy but well worth it.
>
> You probably shouldn't have any problems in that configuration.
>
would[vbcol=seagreen]
> I
volume[vbcol=seagreen]
> I recommend you go over this with the people who configure your SAN. They
> know its specific implementations, where it is fast, where it can lag,
etc.
> Hopefully they have SQL Server experts on board (likely mostly DB2
people),
> if not, see above... Have EMC come in and talk to you before you decide on
a
> specific device (and even if you don't go with them, they'll likely give
you
> relevant information that at worst you can use as confirmation to what the
> other guys tell you).
>
even[vbcol=seagreen]
> a
> You probably won't hit it much, and if you do, you will probably be more
> constrained at that point by the network bandwidth sending it over the
wire
> than by reading it from disk.
>
research[vbcol=seagreen]
> to
> storage
> I can't speak for other vendors, because I was involved too late in the
> process, but EMC was very up front with us, stands by their product, and
> aren't out to screw you. I would bet I speak for most SAN vendors when I
> say that they want to make money but they want to do so by providing you
> with the best solution for your scenario, as you present it to them.
> NAS, on the other hand, is a completely different ballgame. :-)
>|||I like EMC, Hitachi, and IBM. I would stay away from HP with all the issues
they're having right now. Make sure whatever storage you choose has a
service location and parts depot close to you. My company is in Kansas
City. The closest Hitachi service center and parts depot is 3 hours away in
St. Louis, so it makes more sense for us to go with EMC which is local.
IBM costs more, but they have great service. Hitachi gives you a lot of the
software that EMC charges you for; however, EMC has more to offer in overall
features. Hitachi tends to cost less than EMC. You really don't have to
worry about buying your storage solution from IBM because the servers are
IBM. All the major storage/server vendors have relationships with each
other to alleviate this. Again, stay away from HP. Their service and
turnaround times for the enterprise platforms have been horrible lately.
Dell is EMC rebranded in case you decide to check them out. The hardware is
the same, but they have their own service staff, support etc. Depending on
your location, they sometimes do a better job than the actual EMC people.
So, that's something to think about also.
"Larry David" <invalid@.bogus.bum> wrote in message
news:M4qdnaIn9c-gzKvfRVn-2w@.giganews.com...
http://www.microsoft.com/sql/techin...scalability.asp[vbcol=seagreen]
> read
> Anthony,
> That's a great link. I appreciate the tip. I'll check out those
> articles.
> Aaron,
> I'll check out EMC. I was thinking that since we are buying our
servers
> from IBM, it would be a natural decision to buy the storage from them as
> well... but after reading your post, I now see that EMC has an excellent
> reputation. Perhaps they have a solution that's more suitable. Are there
any
> other vendors that you think I should investigate? Any thoughts on Hitachi
> Data Systems (hds.com)?
> David
>|||I haven't heard many good things about Hitachi; quite the opposite,
actually.
As for your servers, if you haven't already committed to IBM, I strongly
recommend giving Dell a shot at your RFP. We filled a couple of racks with
Dell servers, have had absolutely no problems with them, and not only did we
get four more servers for the same price as the IBM quote, they were more
powerful AND they lumped in some other goodies.
Our transactions with IBM (and the support thereafter) have been far from
stellar. Don't tie yourself to one hardware vendor!
On 3/14/05 10:06 PM, in article M4qdnaIn9c-gzKvfRVn-2w@.giganews.com, "Larry
David" <invalid@.bogus.bum> wrote:

> read
> Anthony,
> That's a great link. I appreciate the tip. I'll check out those
> articles.
> Aaron,
> I'll check out EMC. I was thinking that since we are buying our server
s
> from IBM, it would be a natural decision to buy the storage from them as
> well... but after reading your post, I now see that EMC has an excellent
> reputation. Perhaps they have a solution that's more suitable. Are there a
ny
> other vendors that you think I should investigate? Any thoughts on Hitachi
> Data Systems (hds.com)?
> David
>|||I've had good luck with IBM. I've also had good luck with Hitachi in the
past though. A lot seems to depend on the local sales/support teams
unfortunately. I agree with not tying yourself to one hardware vendor
though. We fought switching off of HP forever. The fact is they earned our
loss of business. They fought hard to lose it. Their service is horrible.
Their turnaround time is horrendous. They don't give a damn about the SLA
agreements on the warranties you buy. We had production servers down, and
sometimes they wouldn't even call back until the next day. This was on 24x7
4 hour response time warranties. If they don't get their act together, they
won't have to worry about not being able to produce servers. /rant
I've heard a lot of good things about Dell lately at both the server and
storage levels. Sounds like they got it together.
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:BE5BBF6B.33BC%ten.xoc@.dnartreb.noraa...
> I haven't heard many good things about Hitachi; quite the opposite,
> actually.
> As for your servers, if you haven't already committed to IBM, I strongly
> recommend giving Dell a shot at your RFP. We filled a couple of racks
with
> Dell servers, have had absolutely no problems with them, and not only did
we
> get four more servers for the same price as the IBM quote, they were more
> powerful AND they lumped in some other goodies.
> Our transactions with IBM (and the support thereafter) have been far from
> stellar. Don't tie yourself to one hardware vendor!
>
> On 3/14/05 10:06 PM, in article M4qdnaIn9c-gzKvfRVn-2w@.giganews.com,
"Larry
> David" <invalid@.bogus.bum> wrote:
>
http://www.microsoft.com/sql/techin...scalability.asp[vbcol=seagreen]
servers[vbcol=seagreen]
any[vbcol=seagreen]
Hitachi[vbcol=seagreen]
>|||How is it setup? What's the pathing, array, and LUN layout? What kind of a
SAN?
"Michael C#" <xyz@.abcdef.com> wrote in message
news:tXsZd.22624$Rc7.21810@.fe09.lga...
>
> Can I ask you a few questions about EMC SAN configuration? Our EMC SAN
was
> recently set up and configured, but we're not getting nearly the
throughput
> we expected.
>|||Can you show the topology? What kind of switches are you running through?
Is it all gig fiber or is some of it bottlenecked by 100 or (gasp) 10/100?
We have observed exemplary performance at the read/write level on the SAN
since the day they were configured. The SAN itself should never be your
bottleneck in my experience, but if your app is hitting a network throttling
issue on the way to or from, it could look like slow performance from the
SAN. The only servers we noticed issues with early on were the ones that
hasn't been upgraded to fiber... they were still running 100 and my gut
feeling is that the SAN was sitting there waiting for the data.
So, long story short, if you're not on fiber through and through, go
shopping. :-)
And of course, if you have more servers in the works that are going to make
use of the SAN, make sure they come equipped with gb cards.
On 3/14/05 10:43 PM, in article tXsZd.22624$Rc7.21810@.fe09.lga, "Michael C#"
<xyz@.abcdef.com> wrote:

>
> Can I ask you a few questions about EMC SAN configuration? Our EMC SAN wa
s
> recently set up and configured, but we're not getting nearly the throughpu
t
> we expected.
>

No comments:

Post a Comment