June 22, 2011 at 6:54 am
Hello,
Could anyone give me their experience using NetApp with SQL Server? Every single one of our databases have been moved onto this appliance and it seems as though we have had nothing but problems since. Not only with a complex backup/restore plan (easy if you restore everything, not always the case!), but also with general administration. We constantly have hangups on I/O, waits on log writing, etc. Infrastructure keeps telling me .bak is "old technology" and this is the newest, fastest way to go. It's great in the event of a disaster and speed of restore of everything, but beyond that it seems like one huge headache. I'm not quite buying into it. We also don't have much say-so in how the DBs are stored, which obviously presents a problem. I was also told that if the DBs were moved back to local disk, we would see a huge decrease in performance, which I'm also not buying.
Any comments would be helpful!
Frustrated
June 23, 2011 at 1:05 am
Can you describe the company estate, is it a whole VM estate, all physical tin or a mixture of both?
The first thing I would try and force your infrastructure people to do is give you a break down of the SAN.
You might have really large disks but if they are SATA disks then you don't get the performance of fiber channel disks etc.
You will want RAID levels i.e RAID 5, 6, 1+0 etc, the number of disks in each RAID group, what LUNS are within that particular RAID group, what host the particular LUN attaches to, the amount of IOP's a disk can run at.
We used a NetApp as a test SAN to test the concepts of centralized storage, to which we purchased a EMC CX4-960 to which I as a DBA had full control over the design of the disk subsystem and what got put on which LUN etc and had the freedom to move LUNS between RAID groups as performance became an issue.
If you could attach or drop an your email in a post I will endeavor to try my best to see where the NetApp bottle necks are.
As for backups, .bak is not old technology, nothing can compare to it in my opinion, the old saying backups are pointless, restores are worthless, I would tell your infrastructure team not to bother doing a LUN snapshot backup, just give you extra space, so you can do your normal bak/trn backups and then they can LUN snapshot the backup area to tape or wherever it goes.
June 23, 2011 at 1:21 am
Also if you can get the capacity of the disks on a disk by disk basis and the capacity of the RAID groups.
June 23, 2011 at 5:54 am
The shop is a mixture of both VM and tin. The disks are fiber channel to the best of my knowledge. We have an interesting culture here which I can explain more in email. I'm hesitant to go on a rant in a public forum.
June 23, 2011 at 6:04 am
vm and tin, thats even better as you may have overloaded virtual hosts which could add on to the issue
if you email me the details (disturbed.chucky@gmail.com) i will be happy to help
June 23, 2011 at 6:11 am
It is a little difficult to get your head around the new concept of not having a physical .bak file. I am assuming your company has purchased snap manager for SQL. It is quite a good tool, just like any other backup strategy you still need to put cleanups in place. This you will need to have further discussions with your storage admins.
If you can you need to get onside with your storage admins to work together. The setup of your aggregates, Lunsford inside your aggregates and files in your luns.
MCT
MCITP Database Admin 2008
MCITP Database Admin 2008
MCITP Database Dev 2008
www.jnrit.com.au/Blog.aspx
June 23, 2011 at 6:18 am
We are using SnapManager for SQL. I hate it! Since I have no say into it, I don't get to see if backups to my servers were ever done, tested, etc. And when I ask for a restore of something, I'm given looks like I just asked someone to move Mount Everest. It would be different if there were more collaboration....sadly not the case. We're working towards that though.:-D
June 23, 2011 at 6:35 am
I understand your frustration. I have been in a situation where it was forced on us to move from HDS to netapp. You should be able to run a restore yourself and just like a native backup move to a new db. If they are not storing many snapshots locally for you to restore from then yes you have the issue of them having to pull things back for you.
Good luck with your relationship building
MCT
MCITP Database Admin 2008
MCITP Database Admin 2008
MCITP Database Dev 2008
www.jnrit.com.au/Blog.aspx
June 24, 2011 at 9:46 am
Zapper (6/22/2011)
Hello,I was also told that if the DBs were moved back to local disk, we would see a huge decrease in performance, which I'm also not buying.
Any comments would be helpful!
Frustrated
The same number and type of disks locally, on a state of the art* server, should beat a SAN. If you put the same number of GB in local SSD's on a state of the art server's RAID system, it'll obliterate your SAN's performance unless you have many scores to hundreds of dedicated disks on the SAN.
Modern 4U servers can hold easily 16 2.5" disks; that can be configured as over 3 TB of raw SSD storage, plus a RAID 1 pair of spinning disks for your OS. Not cheaper than the SAN, just faster.
*Less than a few months old, with all the options for the storage subsystem.
June 24, 2011 at 3:15 pm
The other question is what chasms are your servers/vm nodes on?? are they blades with shared resources
Some things to try and get your storage/infrastructure team to try
HBA queue depth
What drivers are being used. Are they miltipath compatible
Have they lumped all the SQL Estate on the same disks? Or with other loaded systems
As the storage teMs customer you need to hammer out a relationship with them if you can. If not you need to enforce an SLA on them and in that in luxe daily reports on your backup jobs
SAN's are good but not the be all and end all that management are sold. As stated above you can't beat locally well configured Tiered storage
Also, try posting the results of Sqlio from MS. Run it out of hours if you can
June 24, 2011 at 4:16 pm
In my experience with NetApp filers all disks are usually part of the same aggregate with volumes and LUNs carved out of the aggregate and surprisingly enough this is NetApps recommendation.
Filers are Network Attached Storage not SANs, despite what the NetApp salesman tells you.
How are the ESX servers and the physical servers connecting to the filers?
As regards to snap manager, yes it's ok for snapping out to DR, but useless for a per database backup\restore strategy. You need to push back and present your own strong business case for this.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply