کد:
http://www.servercare.nl/Lists/Posts/Post.aspx?ID=89
If you have built your Hyper-V cluster on Windows 2008, you might want to reconsider rebuilding it on Windows 2008 R2, there are basically two reasons that really jump out to entice you to make this decision:
First of all there's the live migration everybody has been talking about, but secondly and much less visible in the mainstream media but in my opinion at least as important; Cluster Shared Volumes.
In fact I would go as far as to say that live migration is nowhere without CSV (yes it's confusing isn't it.. we used to refer to Comma Separated Values with that acronym!).
Why Cluster Shared Volumes

What's so special about CSV ? Simply put; it allows multiple nodes to access the same volume at the same time. Kind of what specialized file-systems such as used by MelioFS, NetApp or Sanbolic allow you to do.
You might have read the article I wrote some time ago about the issues I had when building my previous cluster on Windows 2008. If you didn't here's a quick recap: I bumped into the need to have several LUN's for the different machines I wanted to distribute between my nodes. Each node could only access one iSCSI lun at the time. Therefore I was basically forced to create many LUN's so that I could fail over one particular machine without having to take the other machines with me, since they were also using storage on that LUN.
Live migration and CSV's

I referred to live migration as one of the reasons to implement CSV, the reason for this is the time that a failover from one node to the other node will take. If this is done with volumes that are not CSV, then the nodes will respectively need to first dismount and then mount the volume. Once shared volumes are used the nodes will be able to fail over immediately, since they have simultaneous access to them.
If you were to do a 'ping-t' to the cluster this results in it being unresponsive for 3 or 4 pings (which as I'm sure you'll agree can feel like 'forever'!) versus 1 ping when using CSV's… Big difference!
TechNet lists a number of other advantages, but to me the above are the most important.
Creating CSV's

First we enable the shared volumes from the main page from the Failover Cluster Manager:

You'll notice that in the Failover Cluster Manager there now is a node 'Cluster Shared Volumes'.

If you right click on that it will allow you to 'add storage'. That is, if you actually have storage available. In my case I simply made an iSCSI disk available that I've created on my Windows 2008 Storage server.
To do this I used the iSCSI Target software on the Storage Server and created a new disk. As an interesting side note: Windows 2008 Storage server will create VHD's as the storage unit to tie to a target. So essentially I will be crating VHD's within VHD's when I make VM's!

For people who would like to learn more about iSCSI; take a quick look at my article about building the Hyper-V cluster .
Once we've made the new disk available to the cluster by adding the disk using the iSCSI client in the control panel on the nodes, we'll be able to put it online, initialize it, make it a simple volume, and quick format it… (this only needs to be done on one node b.t.w.)
Now we're ready to take it up in the cluster, we do this by simply adding it as a regular disk:

Once we click "Add a disk" we'll be able to select the disk we want

Notice that the disk we just added still shows up as a local disk (F in the storage overview.

Another thing you can see here is that the Cluster Shared Volume also appears to be local! In fact, it's on the system drive, in our case the C: drive. Don't worry, that's supposed to happen… More on this later.
We now have our disk available to the cluster... remember that both nodes need to be able to 'see' the iSCSI disk, I've made it easy on myself by simply adding the virtual drives in the Storage Manager to a Target that I had already added to my nodes (in my case it was called T2). If you decided to create a new target, make so that the target is accessible and initiated from both nodes.
Next step is to simply add the storage we just made available in the cluster to the shared storage:

Select "Add storage" and select the Cluster Disk we want to have shared.

Now we see the new shared disk available to the cluster:

I've taken the liberty to rename the shared disk to "Cluster Disk 2 data disk"
Once this is done, you'll also notice that the disk that formally was seen as a local F: drive, now seems to link to the earlier pointed out system (C: ) drive. This works like a mount point , where a disk is made available to the system through a folder.
If we look here, we'll see that the available volumes (we've got two in our example) are listed in that folder:

As mentioned; both nodes will be able to write there, but never use this accessibility besides for the Hyper-V cluster. Manually making changes here will lead to problems. The Technet article specifically states:

  • No files should be created or copied to a Cluster Shared Volume by an administrator, user, or application unless the files will be used by the Hyper-V role or other technologies specified by Microsoft. Failure to adhere to this instruction could result in data corruption or data loss on shared volumes. This instruction also applies to files that are created or copied to the \ClusterStorage folder, or subfolders of it, on the nodes

Now that you have shared volumes available you'll be able to create Hyper-V VM's on them.
One pointer I'd like to leave you with; make sure to change the default Hyper-V settings to point to this new location, as you'll find that creating new machines, even though pointing to the correct location during creation might result in errors. This is fixed by simply making the clusterstorage default.










موضوعات مشابه: