SQL Server on NAS storage (NetApp Data ONTAP)

  • Hi,

    I'm in the situation where we are suffering of poor performance on our SAN storage (VPlex) but it is mainly due to the quantity of data of different types which are on it (other applications, other I/O profile, bad storage usage...). As we plan to dedicate an ESX for SQL Server, we decide to have a new storage type. So we will go with NETAPP Clustered Data ONTAP on NAS technology.

    Storage team want to enable only NFS protocol, so I'm wondering how SQL Server will handle that ? I read that NFS wasn't optimize for SQL Server and that block level (SAN) should be preferred. Can you help and confirm this point ?

    Thanks,

    Julien

  • I tried to install SQL server 2008 on NAS before and SQL Server did not recognise the NAS as a viable storage option so could not even get past the installer. Not sure if this has changed if the later versions

  • jtheulier (10/28/2014)


    As we plan to dedicate an ESX for SQL Server, we decide to have a new storage type.

    The way i'm reading this is that you're going to dedicate a whole ESX host to a SQL server VM, is that correct??

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Yes it is correct, a whole ESX to answer to licensing needs. So Nas layer will be virtualized by VMWare. So I wanted to Know if I will suffer from performance issues with the NAS configuration.

  • jtheulier (10/28/2014)


    Yes it is correct, a whole ESX to answer to licensing needs.

    Thats what I was afraid of, if you get anywhere near giving all the host resources to a VM it probably shouldn't be a VM in the first place!!

    What licence needs? All you're actually doing is costing more money for a needless ESX host licence.

    jtheulier (10/28/2014)


    So I wanted to Know if I will suffer from performance issues with the NAS configuration.

    Yep, around 10-15%. Virtualising a server has an overhead you must understand this. You constrain cpu and disk resources in the main, dont expect physical server performance.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Having around 700 VMs hosting SQL Server (only in Europe), virtualization answers to our needs. We cannot imagine to have such number of physical servers. It will be increasing the maintenance workload, provisioning time ...

    Licensing the whole ESX is a good way to save costs on this.

    For the performance point, having a dedicated ESX let us be sure that no ressource overcommit will be made and that VM needs will be adressed. This solution is working well except on the storage side because our old SAN was undersized and data growth was under estimated.

    To answer to heavy SQL Server needs, we can have physical servers but virtualization answers to 90% of our needs.

    With the cloud technology growing everywhere, you can be sure that performance on virtual environment are better than few years ago as it is based on the same layers.

  • Wow as long as you think there's nothing wrong with it then fine, i'm glad it's not my IT budget you're spending 😉

    By Virtualising a single Vm on a single host you're simply constraining the performance of what possibly should be a physical server. The main reasons for virtualising are consolidation and hardware mitigation, single Vm single host doesnt achieve this.

    At the end of the day it's your money.

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Perry Whittle (10/29/2014)


    By Virtualising a single Vm on a single host

    I didn't mention that, I said 700 SQL Server VM on an ESX cluster (12 nodes).

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply