Dario IT Solutions Blog

Cluster Shared Volumes (CSV) is a new feature that was introduced in Windows 2008 R2.

If you want to read more about it, how it works, and how you can enable it. There is a lot of material out there that you can refer to:

• Windows 2008 R2 NLB & Failover Clustering
• http://technet.microsoft.com/en-us/library/dd759255.aspx
• http://technet.microsoft.com/en-us/library/dd630633(WS.10).aspx
• http://blogs.msdn.com/clustering/archive/2009/03/02/9453288.aspx
• http://blogs.msdn.com/clustering/archive/2009/02/19/9433146.aspx

Well, after you’ve setup your cluster, enabled CSV, and added clustered disks to CSV, it is now time to copy your VHD files to those CSV disk. The big question is, which cluster node should you perform this operation on?

We’ll, to make a long story short – Copy it to the node that owns the CSV disk!

The reason this is important is that if you are running the copy on the coordinator node (the node which owns the CSV volume of interest), the writes are all local writes. If you are running the copy on any other node, the writes are actually redirected over the network (because they are extending writes to the file) and not done directly to the volume.

Hope this will save you some much needed time

When trying to Live Migrate a virtual machine, the process might fail and inform you that your virtual machine is not compatible with the target node.

If you try to Move (instead of Live Migrate) the virtual machine to another node, the process will again fail and you the following event will be logged:

Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Event ID:      1205

The Cluster service failed to bring clustered service or application ‘xxxxx’ completely online or offline. One or more resources may be in a failed state. This may impact the availability of the clustered service or application.

This situation is indeed caused, as the error indicated, by different processor capabilities. Check the exact processor version of your Nodes. You can use msinfo32 to get a detailed view. Here’s, for example, the types of CPUs I see:

Node1

Node2

What happens is that when the virtual machine starts, the hypervisor exposes certain CPU capabilities to the virtual machine. When Live Migrating or Moving the VM to a different host, the VM isn’t aware of the hardware change, tries to use capabilities that it’s new CPU doesn’t support, and fails to start.

Luckily, the solution is simple. Open the VM’s settings, and under the CPU settings check the option named “Migrate to a physical computer with a different processor version".

Note that the VM has to be off in order for you to check this option.

When checking this option, the hypervisor is only exposing the VM to the features of the processor that are available on all versions of a virtualization-capable processor by the same processor manufacturer. Note that this option doesn’t allow you to migrate between AMD and Intel CPUs. Check this Microsoft Technet article for further details: http://technet.microsoft.com/en-us/library/dd446679(WS.10).aspx

It is important to read between the lines in this case. Although you will be able to migrate without errors, your VM does LOSE PERFORMANCE .

This means that when planning to build a new Hyper-V Cluster, make sure that you get exactly the same CPUs on your physical hosts. Otherwise, you will have to downgrade the CPU capabilities of your VMs.

Hope this is helpful.

Kobi

I know its a bit late, but here is the presentation I gave on November 3rd at the Microsoft convention – Let’s Talk Business-Tech that was held at Tel Aviv.

During the presentation, my co-presenter Ronen Gabay and myself talked about the new features of Failover Clustering in Windows 2008 R2.

We talked about Geo-Clusters, PowerShell 2.0 extensive support, Cluster Shared Volumes and mainly about how simple it is to create and manage complex cluster (everyone can do it! believe me! ).

We finished the presentation with a nice demo of RDS 7.0 media enhancement when we showed a 1080P HD movie (Terminators 2 Trailer) over RDP 7.0 while doing a Live Migration of the RDS Session Host virtual server that we RDPed into.. very nice!

What do you think, will we start seeing more clusters from now on? or something is still missing?

I’ll love to get your input.

Check out this nice list I found wondering on TechNet.

Mandatory reference in all Hyper-V implementation.

Check out this nice list I found wondering on TechNet. Mandatory reference in all Hyper-V implementation.

Windows 2008 R2 will feature some major DFS improvements, following is an explanation of them:

1. Support for Windows Failover Clusters

In Windows Server 2008 R2, Windows Failover clusters can be configured to be part of a replication group. Windows Failover clustering technology enables administrators to configure services and applications to be highly available.

Busy hub servers located in the datacenter that replicate with many branch office servers are perfect candidates for clustered DFS Replication. These servers are critical to the replication infrastructure and administrators expect high availability from these servers. A failure (hardware/software) on such crucial servers has the potential to bring all replication activity to a standstill.

2. Read-only Replicated Folders

Often, customers use the DFS Replication service to publish data from a central server out to many branch office servers. A typical characteristic of this data is that it is created/modified at one location (typically the hub/datacenter server) and changes aren’t expected to occur on any of the other member servers. Usually, administrators configure strict ACLs for the replicated data to ensure that changes aren’t made by end-users in branch offices.

Configuring and maintaining strict ACLs to block accidental modifications or recovering data that has been accidentally deleted entail high administrative overheads. A new feature in Windows Server 2008 R2 called ‘Read-only replicated folders’, offers an easy to manage solution to this problem.

In essence, on a read-only replica:

• Local modifications are blocked by the DFS Replication service. Changes to files/folders including creation, deletion, modification of attributes/permissions etc. are not possible. Semantically, the read-only replicated folder mimics a read-only share.

• Changes from members hosting read-write copies are replicated in. The DFS Replication service replicates in changes from other replication partners that host read-write enabled copies of the replicated folder. This ensures that the data remains up to date on the read-only replica.

3. SYSVOL on Read-only Domain Controllers

Windows Server 2008 introduced support in the DFS Replication service for Read-only Domain Controllers (RODC).

Building on this implementation, in Windows Server 2008 R2 the concept of read-only replicated folders has been extended to the SYSVOL replicated folder. This means that on read-only domain controllers running Windows Server 2008 R2 and using the DFS Replication service to synchronize the SYSVOL share, the SYSVOL share is configured as a read-only replicated folder. Therefore, there is a change in the end-user experience for the SYSVOL share exposed by a Windows Server 2008 R2 domain controller.

On Windows Server 2008 based RODC: Changes can be made to the contents of the SYSVOL share on RODCs. However, the DFS Replication service monitors these changes and then asynchronously overwrites these changes with updates from a writable domain controller. Therefore, any changes made on a Windows Server 2008 RODC will be visible for a short duration, until they are reverted by the DFS Replication service.

On Windows Server 2008 R2 based RODC: Changes cannot be made to the contents of the SYSVOL share on RODCs. Any attempts to make such modifications will encounter an ACCESS DENIED error. Therefore, the SYSVOL share on such RODCs looks like a read-only share.

4. Diagnostics Improvements

Windows Server 2008 R2 also features a set of powerful enhancements to the diagnostics capabilities of the DFS Replication service. These are in the form of new command line options to the dfsrdiag.exe command line diagnostics tool.

Dfsrdiag.exe ReplState : This command line switch provides an insight into the current working state of the DFS Replication service. This command initiates a snapshot of the internal state of the service and thereby gathers a list of the updates that are currently being processed (downloaded from or served out to replication partners) by the service.

Using this command line switch, an administrator can retrieve a snapshot of the status of replication activity across all connections on a given DFS Replication member server.

Dfsrdiag.exe IdRecord: The DFS Replication service maintains a record for each file and folder in the replicated folder in its database. These are known as ID records. This command line switch can be used to display the ID record information maintained by the DFS Replication service corresponding to a particular file/folder in its database. The ID record also contains information such as version vectors of the file/folder, timestamps etc.

Using this command line switch, an administrator can dump the ID record corresponding to a file/folder on each individual replication member server. In order to check whether a particular update has replicated to the member servers in the replication group, the version information in the ID records on these members can be compared.

Dfsrdiag.exe FileHash: This command line switch computes and displays the file hash generated by the DFS Replication service for a particular file. The file hash can be used to compare two files and determine whether they are similar.

For instance, while pre-seeding the contents of a newly added replicated folder, it is often required to verify whether the file being pre-seeded is identical (attributes, timestamps, ACLs etc.) to that on the authoritative copy being used as the source for pre-seeding. By comparing the file hash generated by this command line option for two files, it is possible to verify if the files are identical. If the data being pre-seeded is identical to that contained on the source server, the DFS Replication service will complete initial sync much faster. This is because it does not need to download the file data and merely downloads metadata.

Microsoft’s Virtualization UA team has put together some great Hyper-V clustering guidance on TechNet. 

Content includes:

1. Design for a Failover Cluster in Which All Nodes Run Hyper-V – http://go.microsoft.com/fwlink/?LinkId=129117
2. Requirements and Recommendations for Failover Clusters in Which All Nodes Run Hyper-V – http://go.microsoft.com/fwlink/?LinkId=129110
3. Checklist: Failover Cluster in Which the Servers Run Hyper-V – http://go.microsoft.com/fwlink/?LinkId=129123

Enjoy!

SCOM MVP Andy Dominey has compiled a very nice document on installing System Center Operations Manager 2007 with high availability.

Get it from here – SCOM in Highly Available and Distributed Enterprise Environments.

As promised, I’ve uploaded the presentations from the sessions I gave on December 18th at Microsoft Israel. Enjoy.

Issue:
Trend Micro OfficeScan Version 8.0 SP1 on a server 2008 Failover Cluster may cause the cluster service to fail while moving a resource group. 

Cause:
Current TDI Driver of the OfficeScan causes a loss of connectivity between the cluster nodes, and may cause the cluster service on one of the nodes to fail. The current version of  office scan doesn’t support Windows Server 2008 Clusters yet. It should be supported in the next version. 

Workaround:
Until the newer version of OfficeScan, a workaround is available for this issue.
Follow these instruction : 

Open Device Manager
Select View > Show Hidden Devices
Expand Non-Plug and play devices
Select Trend Micro TDI Driver  > Properties
Go to Driver tab
Under Current Status press the stop button
Under Startup change the type to Disabled (Uninstalling the driver didn’t work, because it was installed automatically at the next boot.) 

Repeat these steps on both nodes and restart them.