October 1, 2009 at 6:43 am
We are looking to implement a new SAN, either an EMC CX400 or an HP EVA 6400. In either case we are considering a storage pool technology. EMC calls it virtual provisioning and I believe HP calls it storage pooling. Essentially you have one or two large pools of drives and from there your SQL Server installations are presented logical chunks of disk. It's even possible to have multiple arrays on the same drives. In HPs proposal we will have a pool of (58) 146GB drives. We can then present them to SQL Server as one drive letter or multiple drive letters.
We are still trying to understand how this technology works. It clashes with the old practice of keeping your logs, data and tempdb on separate arrays in order to minimize seek time.
We would love to hear from people who are using this technology. How well does it work for you? How big is your storage pool and did you carve it up into logical drive letters? Do you still use Perfmon to monitor disk performance? What problems does this present?
Thanks, Dave
January 6, 2010 at 9:25 am
Hi Dave,
I am wondering if you ever grasped an understanding of how the storage pooling worked and how you implemented in the end.
Reason i ask is the company i work for are going for a HP EVA 6400 with over 80 disks, sounds great for the IOPS but i currently have no idea how we would be best to present this to the SQL Server.
Also, what option did you go for on the DR side of it?
Thanks in advance.
Dave
January 6, 2010 at 9:47 am
We are actually in the process of evaluating two SANs, one from EMC and one from HP. The EMC SAN utilizes metaluns, with one set of drives dedicated to data, one set to logs and one set to tempdb. Each metalun consists of a 2+2 raid 10 chained together to form the LUN. Our HP EVA is being built this week as a single pool of 54 drives. Against both SANs we will run SQLIO, Update Statistics, DBCCs and Reindexing to determine which is performing better and how much better each performs as compared with production. At some point we hope to perform some application testing against both. We also plan on repeating the same tests while adding drives to see what overhead can be expected as the drives are restriped.
After speaking with Microsoft on several occasions they indicated that storage pooling isn't necessarily a bad idea, but as with everything we do, test, test, test to make sure it fits our needs. The concern is with the overhead involved due to seek time. For example, when reindexing a 1TB database by itself it stands to reason that performance will be great since all drives would service the reindex request. However in the real world that's typically not a true test. What happens to reindexing when the server is under heavy load? That's where SQLIO and a variety of other tests come in. We have about 3-4 more weeks of testing before we determine which will work for us. One thing you need to do up front is have a good test plan. It sounds simple, but we've spent a few weeks modifying our test plan in order to find something that makes sense for our environment. Understanding how to use and interpret SQLIO can also be a bit challenging, even with Microsoft's assistance.
Hope this helps.
Dave
January 6, 2010 at 10:26 am
Dave, thanks for taking time out to reply.
When setting up your HP will you be creating seperate LUNS out of the storage pool to put the data, logs and tempdb on, or just present one LUN to the SQL Server and put them all on that?
I presume it doesn't make much difference what you do as at the end of the day it is the same disks being used.
SQLIO is a new tool I have been looking at to start testing once the SAN is delivered, do you have any links you could recommend as a beginners guide to using this?
Also it would be great to know how you get on after your testing and what solution you finally go with.
Our company were also looking at EMC but the decision was made to buy HP, we now have a very tight schedule to get the SAN implemented and an upgrade from SQL 2000 to SQL 2008 so the next cpl of months are going to be interesting.
January 6, 2010 at 10:43 am
The HP will be setup using HP's recommendation of one large pool of drives. At an OS level we will partition the drives for tempdb, data and logs, but physically there will be one large pool of 54 drives.
Here's one link to SQLIO that we found helpful.
http://sqlserverpedia.com/wiki/SAN_Performance_Tuning_with_SQLIO
Read the README.txt that comes with the tool. It will help a lot. Unfortunately a Google search won't produce much in the way of how to interpret the results. You need to know how SQL Server reads and writes data in terms of block size. Understanding proper settings for latency, threads and outstanding IO was tricky for us. We still struggle with how this information directly corresponds to SQL Server behavior, and that's after working with Microsoft's Performance team. They admitted they do not have much documentation on SQLIO and support is provided as "best effort". Understanding how much of your application processing and maintenance jobs is sequential IO vs. random is also important when configuring SQLIO.
January 7, 2010 at 7:23 am
You may want to try SQLIOSIM as the tool for testing.
http://support.microsoft.com/kb/231619
and another tool is IOMETER.
We recently completed testing on the HP LeftHand SAN and it didn't meet our needs and in our opinion wasn't good for our OLTP database. It seemed more suited for a file server. I'm not about to bash this product, some people love it. Anyway we came at these conclusions by running:
SQLIOSIM
IOMETER
SQLIO
ProfileTrace replays
Backup/Restore times
Good luck, I look forward to viewing your findings.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply