locked
Cluster Shared Storage ownership RRS feed

  • Question

  • I have a three node cluster with a Cluster Shared Storage ressource for Hyper-V hosts. When the Cluster Shared Storage is owned by one server the others have slow access to it. When I move the Cluster Shared Storage ressource in Cluster Failover Manager the new owner starts to get the good performance and the other two bad performance.

    I've tried to copy a file from the lokal server drive to the Cluster Shared Storage. On the good perfoming server it finishes in 3 seconds and on the two bad performing serveres it takes 35 seconds.

    Any ideas why it is behaving like that?

     

    Friday, September 17, 2010 2:42 PM

Answers

  • To understand how Cluster Shared Volumes (CSV) works in a failover cluster, it is helpful to review how a cluster works without CSV. Without CSV, a failover cluster allows a given disk (LUN) to be accessed by only one node at a time. Given this constraint, each Hyper-V virtual machine in the failover cluster requires its own set of LUNs in order to be migrated or fail over independently of other virtual machines. In this type of deployment, the number of LUNs must increase with the addition of each virtual machine, which makes management of LUNs and clustered virtual machines more complex.

    In contrast, on a failover cluster that uses CSV, multiple virtual machines that are distributed across multiple cluster nodes can all access their Virtual Hard Disk (VHD) files at the same time, even if the VHD files are on a single disk (LUN) in the storage. The clustered virtual machines can all fail over independently of one another.

    While all nodes in a cluster can write and read data to a CSV volume, there is one node responsible for changing the meta data. This node is called the Coordinator Node. Each CSV has one Coordinator node. If you have multiple CSV nodes available in a cluster, the Coordinator nodes for each CSV are evenly spread over the nodes. If the coordinator node fails, automatically another node will take over this role. It will probably result in a short pauze of diskaccess. Not sure if virtual machines will suffer from this. CSV volumes can only be used by Hyper-V hosts to store virtual disk files on (VHD). Do not try to store any other data on it because this could lead to corruption of the data.

    Please check

    Clustered Shared Volumes explained, design impact and best practises

    http://up2v.wordpress.com/2010/07/30/clustered-shared-volumes-explained-issues-and-best-practises/

    Friday, September 17, 2010 3:19 PM

All replies

  • To understand how Cluster Shared Volumes (CSV) works in a failover cluster, it is helpful to review how a cluster works without CSV. Without CSV, a failover cluster allows a given disk (LUN) to be accessed by only one node at a time. Given this constraint, each Hyper-V virtual machine in the failover cluster requires its own set of LUNs in order to be migrated or fail over independently of other virtual machines. In this type of deployment, the number of LUNs must increase with the addition of each virtual machine, which makes management of LUNs and clustered virtual machines more complex.

    In contrast, on a failover cluster that uses CSV, multiple virtual machines that are distributed across multiple cluster nodes can all access their Virtual Hard Disk (VHD) files at the same time, even if the VHD files are on a single disk (LUN) in the storage. The clustered virtual machines can all fail over independently of one another.

    While all nodes in a cluster can write and read data to a CSV volume, there is one node responsible for changing the meta data. This node is called the Coordinator Node. Each CSV has one Coordinator node. If you have multiple CSV nodes available in a cluster, the Coordinator nodes for each CSV are evenly spread over the nodes. If the coordinator node fails, automatically another node will take over this role. It will probably result in a short pauze of diskaccess. Not sure if virtual machines will suffer from this. CSV volumes can only be used by Hyper-V hosts to store virtual disk files on (VHD). Do not try to store any other data on it because this could lead to corruption of the data.

    Please check

    Clustered Shared Volumes explained, design impact and best practises

    http://up2v.wordpress.com/2010/07/30/clustered-shared-volumes-explained-issues-and-best-practises/

    Friday, September 17, 2010 3:19 PM
  • CSV is a solution designed and optimized for Hyper-V and VHD I/O.  Doing local file copies is not a good way to measure CSV performance, as it is not Hyper-V VHD I/O.  You are testing and drawing conclusions which do not apply to how you will actually use it...

    If you want to measure CSV I/O, you should be doing it in a way in which you will actually be doing it...   so doing a file copy to / from a VM with a VHD running on CSV is a much better test.

    Thanks!
    Elden

    Saturday, September 18, 2010 5:30 PM
  • I'm having performances issues on a CSV.  The VM performed great before I enabled the Cluster.  After I enabled the cluster and CSV, the VM boots up slower and it takes roughly 30 sec for the management console to load up as opposed to the 10sec it took before I added it to the cluster.  Seems odd to me.  Any suggestions?
    Thursday, December 30, 2010 11:43 PM
  • Please run the cluster validation wizard against your nodes
    Mohamed Fawzi | http://fawzi.wordpress.com
    Friday, December 31, 2010 7:49 AM
  • After some further tests, I believe that the performance issues I am experiencing lie elsewhere and are not due to enabling CSV.  Thanks for your response Mohamed. 
    Tuesday, January 4, 2011 5:36 PM