July 11, 2006 at 5:07 am
Dear All,
We are implementing the NETAPP SAN that has a RAID-DP (Dual Parity - will work even if 2 disks fail) and WAFL (Write Anywhere File Layout - ie, it can write anywhere on the disks) system. According to the research I have done, and discussions I have had with the vendor, he suggests not to worry about partitioning because of the WAFL system, and then performance is way better on RAID-DP both in performance and realiability.
Has any one of you had any experience with SAN? what is your General observation?
Regards,
TK
July 11, 2006 at 5:55 am
No experience with this SAN - but - it is important to remember that the performance of a disk is not altered by a SAN, each spindle can still only support x i/o no matter what and most raids other than 10 put a restriction on writes. It depends upon your applications/databases - for high performance oltp you may find a SAN struggles. There are a number of microsoft white papers and studies available, my experience with SAN storage to date is that the vendors and managers don't understand rdbms technology and requirements so performance usually suffers. Get the SAN set up correctly, this means no shared spindles ( at all ) and enough spindles for required i/o throughput and I believe performance is adequate.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
July 12, 2006 at 8:18 am
In NetApp you can setup an aggregate (AGGR) with specific drives or by size. You should also add another AGGR for your log files. Each DB should be on a separate LUN and each LOG file should be on a separate LUN.
July 13, 2006 at 9:17 am
I'm not a SAN expert, but I don't like my data sharing spindles with other access patterns. WAFL should work, but I prefer RAID 10, separate drives and LUNs for SQL Servers.
Let the Exchange boys share their drives with the file servers.
July 17, 2006 at 3:16 am
It is the shared spindles that cause the most problems. The main issue I've encountered with SAN's is that I require say, 7 spindles for good performance, with 147Gb disks this makes my 100 Gb database look lost. SAN Vendor says cache memory means that non dedicated spindles issue doesn't apply. My 7 disks get carved into say three or four LUNs. At this point it is almost impossible to apply or find any perfmon counters to measure disk performance .. my sql server has performance issues which manifest as excessive blocking. Eventually ( after 12 months ) I'm able to prove that the shared disks are the problem , I get dedicated disks and this particular problem goes away. As I say a disk can only support a limit of i/o, when you carve the disks on your home PC ( if you do ) you do it for convenience, it certainly doesn't improve performance - I seem to have difficulty getting this simple concept over to storage people !!!
If you really want to have problems share exchange with your sql server data files , or share the tran logs from several servers with the data files of another.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
July 17, 2006 at 8:32 pm
So, that means that I should make all the efforts now, before it is implemented, to not to share the Exchange and Database data files.
Our current Exchange database is 56GB, with an expectation of 150GB in 3 years. Our Sybase databases are about 620 GB with an expected 1.2TB growth over 3 years and SQL is also about 620GB with an expected 1.3 TB growth.
Ideally I would like to have 3 separate Aggregates - 1 for Sybase, 1 for SQL and the other for Exchange and other user files. However, you know how you are left with only 60%/70% of usable disk space because of all the expansion, SMSQL data, snapshots etc on the SAN, My NETAPP vendor is saying that we have not bought enough Disks to be able to create more than 1 Aggregate.
What do you guys suggest? What should I do? I will talk to my manager today to alert her about this. I guess I would need some proof supporting these concerns, so your thoughts would be definitely beneficial.
July 18, 2006 at 5:12 am
Check out the microsoft ALWAYS ON http://www.microsoft.com/sql/alwayson/default.mspx
this might help. It's really important that people realise that a SAN doesn't give any performance benefits becuase it's a SAN. SAN's assist in storage management but 50 spindles on a SAN do not go faster than 50 spindles in DAS - the i/o's and bandwidth of a disk array don't magically improve in a SAN. Carving disks in a SAN is no different to carving disks in DAS - the principles are still the same, sure a SAN has lots of cache, but lets put this into perspective, 64Gb cache divide between read and write on say 16 LUNs - hmm not much memory compared to my 32Gb on sql server. There's also the bandwidth of the fibre that connects - make sure the fabric uses switches and not hubs - 4gb fibre might sound fast but the reality of attaching 60 or 70 servers means this is actually quite narrow.
I think people are blinded by SAN technology, and too often the dba's don't get asked. I've seen/heard some stunning claims - "our raid 5 is faster than raid 10" , " the cache means there's no latency for raid 5" , " there's no need to seperate your data, log and backup drives as the SAN is so much faster" and most commonly "you don't understand".
My intention is to take some storage training, oh and there are some good guys out there in the SAN world!!
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
June 4, 2007 at 10:19 pm
We are looking at purchasing a NetApp SAN and don't know much about the whole subject.
1. What exactly is a LUN? Can a LUN hold, say, 50% of a drive's capacity or must
it use entire drives?
2. "Each DB should be on a separate LUN and each LOG file should be on a separate LUN."
Did the author (from this set of messages) truly mean each DB should have its own LUN? Or did he mean all
databases in a given sql instance should be on a single LUN? If each database is to have
its own LUN just how many LUNs does the "typical" SAN support? (suppose 16TB entry level)
3. Assuming the comment in 2) is correct should tempdb and the OS itself be on seperate LUNs? And these LUNs
distinct from the other two?
TIA,
Barkingdog
June 6, 2007 at 12:01 am
I'm running a couple of ERPs, an EDMS (with up to 80 concurrent users on the busiest ERP and the EDMS) and a dozen or so other DBs on a Netapp. The IO issues I have encountered have all related to configuration issues and IO paths, not the SAN itself. Correctly set up the Netapp is fast and I do not do any file managment. However to acheive this situation I have had to dedicate an IO path between the SAN and the DB server (used to be that IO was on the same network as the user traffic. If the is suggested the word you need is 'No').
Oddly enough I get best speed on one server with TempDB on local disk on another I get best speed with it on the netapp. So they are set up differently. One day I'll try to work out why.
If you have a good battery backup investigate the use of the Write Cache (IMHO the use of battery backup instead of non-volatile is a weakness but It is cheaper). Writng to RAM is of course fast and if your battery backup is sound is safe.
I have not done the research on a Netapp but I have seen with an IBM Shark that we almost never used the spindles - at start up data was copied in the SAN cache and then commonly used data was in the RDBMS cache. Once the DB was in operation a couple of hours we were reading from SAN Cache (RAM) to RDBMS buffer and back again. This made the old spindle argument obsolete in this case.
We recenly bought new disks, I was able to convince managment to buy the biggest one we could for CIFS and the smallest ones we could for the iSCSI (db LUNS)
From experience with a few disk arrays (IBM, Netapp, Hitachi)
Manage your IO path.
Keep your disks small.
Don't fill your disks (free space is your friend)
Combine differnt IO patterns. (WAFL does this automatically)
Regards
Karl
June 6, 2007 at 10:37 am
I used to work for Sun Micro in their Network Storage division. I am amazed at how much I have forgotten.
A LUN is a Logical UNit. If you have only been exposed to The Wonderful World of Windows, you will not have heard of it. It comes from the Unix/Linux/Solaris/IBM OSes which have been accessing disk drives from before Bill Gates was even born.
If you are investing in SAN, then it is imperative that at least one of your staff get vendor training. If there is one area where cost should not be an issue, this is it. And make sure it is someone with at least a little Unix exposure or who is not allergic to learning it. Guaranteed the SAN itself will be running Unix/Linux. SAN is a wonderful thing but, despite what the vendor might say, it is NOT plug-n-play in a high throughput/quick response time environment. Your performance will differ!
Tomm Carr
--
Version Normal Form -- http://groups.google.com/group/vrdbms
June 7, 2007 at 7:17 am
If you want anything other than mediochre performance your luns for sql server should be on dedicated spindles - and certainly not share with anything, especially exchange.
fibre channel will be better than ip ( assuming equal setup ) as it's faster and dedicated and less prone to errors, a dropped packet might not be an issue for some but for a transactional database is not good. I'm not sure about the windows LUN stuff - think that's a bit supercilious - I'm not convinced solaris and definelty not linux were around before BG was born - but hey it has nothing to do with this post does it?
SAN's probably have the most vendor waffle of almost any subject, perhaps except virtualisation, if you thought raid 5 was bad wait until you meet raid 6 < grin >
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
June 8, 2007 at 7:00 am
Don't use a NetApp device for SQL, at least not RAID-DP! Raid-dp is very similar to RAID-6 and uses 2 parity drives, therefore writes will take twice as long as compared to RAID-5, and personally, I stay away from RAID-5 as well. If you can get RAID-10 or RAID-01 on the device, then use that, though honestly, I don't think you can, since on ours we can only do RAID-0, RAID-4 and RAID-DP. This might be licensing though.
We have a NetApp as well, and this is going to get used for disk backups and for file services, NOT SQL. If your SQL server has a lot of disk i/o especially for writes, I would recommend to stay away from deploying in a SQL environment.
Now, if you wanted, perhaps use it for backups of your SQL data, directly attached via fibre or via iSCSI. Personally, that's the most I would do.
June 10, 2007 at 3:08 pm
We're happy with SQL Server on Netapp. It uses RAID, which I usually avoid with a DB but we're seeing good results.
Karl
June 15, 2007 at 9:25 am
All of this is dependent upon your database size(s) and the throughput required of course.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply