April 7, 2005 at 5:48 pm
The storage wars are heating up with the announcement that IBM will resell NetApp technologies and products to compete with EMC. They'll also integrate NetApp stuff with their Tivoli products, which is just one more area that IBM will have an advantage over other vendors.
With SANs and other storage technologies getting more and more mainstream, I'm hoping that we'll start to see some good price reductions, enough that the smaller businesses, those with 50 people or so, can start to implement them. But maybe not for the reasons you think.
To me, the SAN technologies and other better storage technologies, have been something of a black box and it's been hard to afford them for many companies. Which means that many people working in technology cannot gain skills that might help them. I'm thinking mostly of DBAs here, many of whom have not had the opportunity to work with a SAN, or even better, test against one.
When I was a J.D. Edwards, they were looking at a large (at the time) 10TB SAN for space consolidation. They wanted to move a bunch of my SQL Servers up there and I was told that the SAN would basically be one large disk carved up with certain slices of this large virtual disk assigned to my servers.
And that I'd just put my transaction logs and data on the same drive letter.
Color me skeptical, but that just didn't sound good to me. The same physical disks that are holding email data, file server files, every last person's Excel spreadsheets, are going to be spinning and moving heads back and forth to get my data as well as random files? And it's going to be faster because there are a lot of disks?
I never did completely pin down the SAN engineers on that and how they did the testing because Peoplesoft bought us and that was that. They used SANs, but would carve up slices of disks, like 5 or 7, and assign those specific physicals to a box. Now that sounded better to me.
Whether it would have been faster or not, I don't know. But I sure would have liked the chance to test it and learn more about how a SAN works. Now maybe with SANs becoming cheaper and more mainstream people like me will get the chance to test with them.
Steve Jones
April 8, 2005 at 7:07 am
We are running an SQL Server environment quite nicely using SAN storage for data files. In our environment, our Network Admins manage the SAN partition set up on the SAN box. The SQL Server box (a separate box) has a SAN card that connects to the SAN box and points to the data disk partition set up for my SQL Server. As far as the SQL Server is concerned, the SAN partition is simply another local disk drive in the SQL Server box.
The SAN storage solution offers us the ability to expand disk storage for far less than the cost of replacing a server. Backups (and restores) have gone much faster and smoother.
I suggest you consider letting other applications shake down the SAN system before moving critical SQL Server databases over. We ran a particular brand of SAN for 2 months and then ended up firing that vendor because they didn't deliver on their promises. We replaced that installation with a completely different SAN system where both hardward and vendor have been solid. I would never want my databases to be the guinea pigs for this type of migration.
Like anything else, you will want to run parallel for awhile to make sure everything is running normally before completing the switch over.
April 8, 2005 at 7:31 am
We are one of those 50-person companies Steve is talking about and we are running an EMC Clariion SAN (sold by Dell) with 28 drives.
Dell suggested putting all the disks in a single RAID 5 set but I nixed that idea. Instead, I created multiple RAID 10, 1 and 5 sets just as we'd done previously when we used a disk array attached directly to our SQL box. With the array, we'd seen a significant performance boost when we had switched off of a pure RAID5 configuration. No matter how much Dell & EMC said that "the caching" in the Clariion would compensate for the RAID5, I never saw any hard numbers to back that up.
Just be aware of 2 things when you use multiple RAID partitions in a SAN: a) be sure the initial size of each partition is sufficient for the filegroups/files you expect to have and b) be sure to tell the OS the patition is dynamic so more physical drives can be added later.
Obviously, we've done both a) and b). In addition, we now have mutliple filegroups for our database each mapping to a single file. Doing so allows us to assign tables to a specific filegroup which then maps (thru its file) to its own RAID set. Thus, all of our read-only tables are on one set of spindles and our must heavily written tables are on another. This configuration not only helps us with getting the most from the SAN performance-wise, it's forced us to figure out the logical partitioning of the DB as we move inexorably towards a federated DB environment.
April 11, 2005 at 8:35 am
I have been fortunate enough to have worked with SANs over the last 6 years and always with SQL Server. I have worked in a company who installed one for their new ERP system (JD Edwards OneWorld) and have worked as a consultant helping companies select, install and migrate their data to a SAN. The technology has certainly improved in that time, although the cost still seems to have remained relatively high.
They typically break down into two types, the cheaper lower end SANs which basically act as a fast headless disk system and the higer end Virtualised SANs. The controllers (Think RAID controller) for both of these are external, and you typically have a HBA (Host Bus Adapter) to connect to the SAN. The controllers are usually very fasy, with lots of cache and extra battery backup. There are also usually at least 2 controllers that are fully redundant, that is you loose one and the other just takes over with no data loss. My experience has always been that SANs of either type will outperform standalone servers.
The lower ends one are not much different from a standalone server, you have set number of disks and you create different LUNs (Disks that windows can see) choosing which RAID Level for each. Again the vendors typically make big claims about the I\O throughput and thay you only need RAID 5 as that will be quick enough. I have always insisted however that the Logs are RAID 1+0, and if I can get away with it I will put TempDB on RAID 1. The database files I typically leave as RAID 5.
The higher end Virtualised SANs are different, what happens here is you load these up with disk and create one large virtual disk. You then create your individual LUNs on this one virtual disk again choosing with RAID level for each LUN. This basically splits all I/O across all the disks in the SAN. The most recent one I worked on was 40*72Gig disks, with 4 RAID 5 LUNs for Database files, RAID 1 for TempDB and RAID 1+0 for Logs it certainly proved to be fast.
We did see performance problems, a certain database file was experiencing very high Disk Queues with Idle time around 0 for prolonged periods. Why this was I can't explain, nor could the vendor. To try and solve this I created a new RAID 1+0 Lun and created a new filegroup on it and moved the tables across which where experiencing the highest utilisation and it worked.
In summary SANs are good, very fast and give you a host of other options (replication at the controller level, snapshot a whole drive for backup, etc.) but don't believe all the hype. Insist on RAID 1+0 for the logs, and be prepared to use it at least for some filegroups if needed.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply