HPE StoreVirtual Storage / LeftHand
cancel
Showing results for 
Search instead for 
Did you mean: 

Network RAID - performance benefit to using separate volumes?

HPSupportHelp
Occasional Advisor

Network RAID - performance benefit to using separate volumes?

 

 

Hi,

 

We have an 8 node P4000 G2 multisite cluster.  Most LUNS are configured using network RAID 10.

We’re having some performance issues with one of our SQL servers and as part of the resolution we have been asked to place the TEMPDB on its own volume.  Logs and databases are already on separate volumes. This has brought a few questions to mind.

 

When data is written to a volume configured as network raid 10 or 10+2, it will be sharing the same spindles and nodes as the other volumes.

 

So even though the data has been placed on separate volumes, is there really any performance benefit to having separate volumes?

 

Thanks

    

8 REPLIES
oikjn
Honored Contributor

Re: Network RAID - performance benefit to using separate volumes?

as long as the luns are in the same cluster, they share their performance.

 

Is TempDB already on its own LUN?  One advantage for having its own LUN is that you can then more easily monitor performance to see exactly what is causing the problem.

 

If you have a multi-site cluster, I would look very closely to make sure your site-site latency is OK.  keep in mind that you must write data to both sites before a write is confirmed to the host and that can be a problem for latency with an SQL server.

 

Also make sure you have the HP DSM setup and the server and node sites setup correctly.

HPSupportHelp
Occasional Advisor

Re: Network RAID - performance benefit to using separate volumes?

 

Thank you for the response.

 

as long as the luns are in the same cluster, they share their performance

 

So no performance benefit at all then? So separating logs and databases on different volumes will have no real performance benifit?

 

From the HP lefthand SQL best practice doc I found , it mentions the following:

 

Put database logs in a separate volume from the databases as they have

distinct IO patterns

 

http://www.virtualitconsultant.co.uk/wp-content/uploads/2010/12/SQL-Best-Practices.pdf

 

Again though, even though the databases and logs are on separate volumes, because of the network raid, these volumes will share the same spindles and shelves so this won’t help with performance.

 

thanks again

 

Bart_Heungens
Honored Contributor

Re: Network RAID - performance benefit to using separate volumes?

Hi,

 

You are correct all spindles will be used by all volumes... Which is a good thing for the available amount of IOPS.

 

However by splitting up volumes the load balancing of iSCSI connections will be easier with multiple nodes available... So it is not only on IOPS but also MPIO load balancing which goes better compared to 1 single big volume...

 

This is not specific to StoreVirtual, this is a best practice with most SAN's...

 

 

Kr,

Bart

--------------------------------------------------------------------------------
If my post was useful, clik on my KUDOS! "White Star" !
My blog: http://blog.bitcon.be
oikjn
Honored Contributor

Re: Network RAID - performance benefit to using separate volumes?

++Bart.

 

Also, if you split them to their own LUNs and you have performance problems, you can more easily see WHAT is causing your performance problem as the SAN can monitor your activity at the LUN level but not any lower.  This can allow you to adjust LUN cluster sizes to tune your systems to better match their IO and also better recognise if you need to move something off the cluster to something else or another cluster so it doesn't kill the rest of the SAN.  So yes, you are correct by itself it won't isolate and solve your performance problem, but it will let you identify where your problem is and give you some key information needed to decide how to fix it.

HPSupportHelp
Occasional Advisor

Re: Network RAID - performance benefit to using separate volumes?

However by splitting up volumes the load balancing of iSCSI connections will be easier with multiple nodes available

 

Why would splitting the volumes help with the load balancing of ISCSI connections? I’m sure this is a simple reason and just me misunderstanding something trivial.

 

So it is not only on IOPS but also MPIO load balancing which goes better compared to 1 single big volume...

 

Why would IOPS be better with multiple volumes instead of a single bit volume?  One big volume is still spread across all the shelves and spindles?

 

Thanks again for your help.

oikjn
Honored Contributor

Re: Network RAID - performance benefit to using separate volumes?

MPIO and multiple LUNs will allow you to have more network traffic to the SAN so you can increase the throughput and request rate to the SAN.  Once you hit your Disk physical IO limit and cache limit, sure it won't help to add any more connections, but it will help most of the time and definitely for bursty data request.  More MPIO connections also allow for more load balancing across each node of the SAN...  again, if you are at the total physical limit of the disks, that won't really help, but it does help whenever you are under that.

HPSupportHelp
Occasional Advisor

Re: Network RAID - performance benefit to using separate volumes?

MPIO and multiple LUNs will allow you to have more network traffic to the SAN so you can increase the throughput and request rate to the SAN.

 

I’d really like to understand this properly.  Are you saying more LUNS will allow more connections, so will make better use of the available bandwidth?  Wouldn’t you still have multiple connections to a single LUN anyway though so achieve the same outcome? 

 

Thanks

oikjn
Honored Contributor

Re: Network RAID - performance benefit to using separate volumes?

The benefit is slightly less if you are using windows and the HP DSM since it will always talk to all nodes with all NICs in the most efficient manner, but perticularly with esx, the servers do MPIO to the cluster's VIP which gets assigned to a single node for each LUN, so the more LUNs you have the more nodes can be used to act as primary data path for esx.  The MPIO documentation goes over this and I think its also in the CMC help files.

 

Perticularly for esx, but also for MS, the more LUNs you have, the more ques you can have which means the more IO that can be spread across more of the nodes in the SAN.  Its not easily a black and white thing just like saying oh my SAN can produce XXXX I/O since size and read/write pattern and access path play such critical roles in that "simple" stat.