(0) exportieren Drucken
Alle erweitern

Use Cluster Shared Volumes in a Windows Server 2012 Failover Cluster

Veröffentlicht: August 2012

Letzte Aktualisierung: August 2012

Betrifft: Windows Server 2012

Cluster Shared Volumes (CSVs) in a Windows Server 2012 failover cluster allow multiple nodes in the cluster to simultaneously have read-write access to the same LUN (disk) that is provisioned as an NTFS volume. With CSVs, clustered roles can fail over quickly from one node to another node without requiring a change in drive ownership, or dismounting and remounting a volume. CSVs also help simplify managing a potentially large number of LUNs in a failover cluster.

CSVs provide a general-purpose, clustered file system in Windows Server 2012, which is layered above NTFS. They are not restricted to specific clustered workloads. (In Windows Server 2008 R2, CSVs only supported the Hyper-V workload.) CSV applications include:

  • Clustered virtual hard disk (VHD) files for clustered Hyper-V virtual machines

  • Scale-out file shares to store application data for the Scale-Out File Server role. Examples of the application data for this role include Hyper-V virtual machine files and Microsoft SQL Server data. For more information about Scale-Out File Server, see Übersicht über Dateiserver mit horizontaler Skalierung für Anwendungsdaten.

At this time, CSVs do not support the Microsoft SQL Server clustered workload.

In Windows Server 2012, CSV functionality has been significantly enhanced. For example, external authentication dependencies for CSVs have been removed, CSVs support the functional improvements in chkdsk, and CSVs interoperate with antivirus and backup applications. CSVs are also now integrated with general storage features such as:

  • BitLocker-encrypted volumes

  • Storage Spaces

For an overview of new CSV and Failover Clustering functionality in Windows Server 2012, see Neues beim Failoverclustering and the Failover Clustering and Network Load Balancing Team Blog.

If you want to configure and add a storage space as a CSV to a failover cluster, see the blog post How to Configure a Clustered Storage Space in Windows Server 2012.

In this topic

Before using CSVs in a Windows Server 2012 failover cluster, review the network, storage, and other requirements and considerations in this section.

In this section

Consider the following when you configure the networks that support CSVs.

  • Multiple networks and multiple network adapters. To enable fault tolerance in the event of a network failure, we recommend that multiple cluster networks carry CSV traffic or that you configure teamed network adapters.

    If the cluster nodes are connected to networks that should not be used by the cluster, you should disable them. For example, we recommend that you disable iSCSI networks for cluster use to prevent CSV traffic on those networks. To disable a network, in Failover Cluster Manager, click Networks, click the network, click the Properties action, and then select Do not allow cluster network communication on this network. Alternatively, you can configure the Role property of the network by using the Get-ClusterNetwork Windows PowerShell cmdlet.

  • Network adapter properties. In the properties for all adapters that carry cluster communication, make sure that the following settings are enabled:

    • Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks. These settings support Server Message Block (SMB) 3.0, which is used by default to carry CSV traffic between nodes. To enable SMB, also ensure that the Server service and the Workstation service are running and that they are configured to start automatically on each cluster node.

      SMB 3.0 includes the SMB Multichannel and SMB Direct features, which allow CSV traffic to stream across multiple networks in the cluster and to leverage network adapters that support Remote Direct Memory Access (RDMA). By default, SMB Multichannel is used for CSV traffic. For more information, see Server Message Block – Übersicht.

    • Microsoft Failover Cluster Virtual Adapter Performance Filter. This setting improves the ability of nodes to perform I/O redirection when it is required to reach CSVs, for example, when a connectivity failure prevents a node from connecting directly to the CSV disk. For more information, see About I/O synchronization and I/O redirection in CSV communication in this topic.

  • Cluster network prioritization. We generally recommend that you do not change the cluster-configured preferences for the networks.

  • IP subnet configuration. In Windows Server 2012, no specific subnet configuration is required for nodes in a network that use a CSV. CSVs can support multisubnet clusters.

  • Policy-based Quality of Service (QoS). We recommend that you configure a QoS priority policy and a minimum bandwidth policy for network traffic to each node when you use CSVs. For more information, see Quality of Service (QoS) – Übersicht.

  • Storage network. For storage network recommendations, review the guidelines that are provided by your storage vendor. For additional considerations about storage for CSVs, see Storage and disk configuration requirements, later in this topic.

For an overview of the hardware, network, and storage requirements for failover clusters in Windows Server 2012, see Failover Clustering Hardware Requirements and Storage Options.

I/O synchronization.   A CSV enables multiple nodes to have simultaneous read-write access to the same shared storage. When a node performs disk input/output (I/O) on a CSV, the node communicates directly with the storage, for example, through a storage area network (SAN). However, at any time, a single node (called the coordinator node) “owns” the physical disk resource that is associated with the LUN. The coordinator node for a CSV is displayed in Failover Cluster Manager as Owner Node under Disks. It also appears in the output of the Get-ClusterSharedVolume Windows PowerShell cmdlet.

However, when certain small changes occur in the file system on the CSV, this metadata needs to be synchronized on each of the physical nodes that access the LUN, not only on the single coordinator node. For example, when a virtual machine on a CSV is started, created, or deleted, or when a virtual machine is migrated, this information needs to be synchronized on each of the physical nodes that access the virtual machine. In Windows Server 2012, these metadata update operations occur in parallel across the cluster networks by using SMB 3.0. These operations do not require all the physical nodes to communicate with the shared storage.

I/O redirection   Storage connectivity failures and certain storage operations can prevent a given node from communicating directly with the storage. To maintain function while the node is not communicating with the storage, the node redirects the disk I/O through a cluster network to the coordinator node where the disk is currently mounted. If the current coordinator node experiences a storage connectivity failure, all disk I/O operations are queued temporarily while a new node is established as a coordinator node.

Windows Server 2012 uses one of the following I/O redirection modes, depending on the situation:

  • File level redirection   Redirection is per file—for example, when a file is opened for shared access.

  • File system redirection   Redirection is per volume—for example, when CSV snapshots are taken by a backup application when a CSV is manually placed in redirected I/O mode.

  • Block redirection   Redirection is at the file-block level—for example, when storage connectivity is lost to a volume. Block redirection is significantly faster than other redirection modes.

  • In Windows Server 2012, because of improvements in CSV design, CSVs perform more operations in direct I/O mode than occurred in Windows Server 2008 R2.

  • Because of the integration of CSVs with SMB 3.0 features such as SMB Multichannel and SMB Direct, redirected I/O traffic can stream across multiple cluster networks.

  • You should plan your cluster networks to allow for the potential increase in network traffic to the coordinator node during I/O redirection.

To use CSVs, your storage and disks must meet the following requirements:

  • NTFS format A disk or storage space for a CSV must be a basic disk that is partitioned with NTFS. A CSV has the following additional requirements:

    • You cannot use a disk for a CSV that is formatted with FAT, FAT32, or Resilient File System (ReFS).

    • If you want to use a storage space for a CSV, you can configure a simple space or a mirror space. CSVs do not support parity spaces.

    • A CSV cannot be used as a quorum witness disk. For more information about the cluster quorum, see Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster.

    • After you add a disk as a CSV, it is designated in the CSVFS format (for CSV File System). This allows the cluster and other software to differentiate the CSV storage from other NTFS storage. Generally, CSVFS supports the same functionality as NTFS. However, certain features are not supported. For example, you cannot enable data deduplication or compression on a CSV.

  • Resource type in the cluster. For a CSV, you must use the Physical Disk resource type. By default, a disk or storage space that is added to cluster storage is automatically configured in this way.

  • Choice of CSV disks or other disks in cluster storage. When choosing one or more disks for a clustered virtual machine, consider how each disk will be used. If a disk will be used to store files that are created by Hyper-V, such as VHD files or configuration files, you can choose from the CSV disks or the other available disks in cluster storage. If a disk will be a physical disk that is directly attached to the virtual machine (also called a pass-through disk), you cannot choose a CSV disk, and you must choose from the other available disks in cluster storage.

  • Path name for identifying disks. Disks in CSVs are identified with a path name. Each path appears to be on the system drive of the node as a numbered volume under the \ClusterStorage folder. This path is the same when viewed from any node in the cluster. You can rename the volumes if needed.

For storage requirements for CSVs, review the guidelines that are provided by your storage vendor. For additional storage planning considerations for CSVs, see Plan to use CSVs in a Windows Server 2012 failover cluster later in this topic.

To use CSVs, your nodes must meet the following requirements:

  • Drive letter of system disk. On all nodes, the drive letter for the system disk must be the same.

  • Authentication protocol. The NTLM protocol must be enabled on all nodes. This is enabled by default in Windows Server 2012.

This section lists planning considerations and recommendations for using CSVs in a failover cluster running Windows Server 2012.

Ask your storage vendor for recommendations about how to configure your specific storage unit for CSVs. If the recommendations from the storage vendor differ from information in this topic, use the recommendations from the storage vendor.

In this section

To make the best use of CSVs to provide storage for clustered virtual machines, it is helpful to review how you would arrange the LUNS (disks) when you configure physical servers. When you configure the corresponding virtual machines, try to arrange the VHD files in a similar way.

Consider a physical server for which you would organize the disks and files as follows:

  • System files, including a page file, on one physical disk

  • Data files on another physical disk

For an equivalent clustered virtual machine, you should organize the volumes and files in a similar way:

  • System files, including a page file, in a VHD file on one CSV

  • Data files in a VHD file on another CSV

If you add another virtual machine, where possible, you should keep the same arrangement for the VHDs on that virtual machine.

When you plan the storage configuration for a failover cluster that uses CSVs, consider the following recommendations:

  • To decide how many LUNs to configure, consult your storage vendor. For example, your storage vendor may recommend that you configure each LUN with one partition and place one CSV on it.

  • There are no limitations for the number of virtual machines that can be supported on a single CSV. However, you should consider the number of virtual machines that you plan to have in the cluster and the workload (I/O operations per second) for each virtual machine. Consider the following examples:

    • One organization is deploying virtual machines that will support a virtual desktop infrastructure (VDI), which is a relatively light workload. The cluster uses high-performance storage. The cluster administrator, after consulting with the storage vendor, decides to place a relatively large number of virtual machines per CSV.

    • Another organization is deploying a large number of virtual machines that will support a heavily used database application, which is a heavier workload. The cluster uses lower-performing storage. The cluster administrator, after consulting with the storage vendor, decides to place a relatively small number of virtual machines per CSV.

  • When you plan the storage configuration for a particular virtual machine, consider the disk requirements of the service, application, or role that the virtual machine will support. Understanding these requirements helps you avoid disk contention that can result in poor performance. The storage configuration for the virtual machine should closely resemble the storage configuration that you would use for a physical server that is running the same service, application, or role. For more information, see Arrangement of LUNs, volumes, and VHD files earlier in this topic.

    You can also mitigate disk contention by having storage with a large number of independent physical hard disks. Choose your storage hardware accordingly, and consult with your vendor to optimize the performance of your storage.

  • Depending on your cluster workloads and their need for I/O operations, you can consider configuring only a percentage of the virtual machines to access each LUN, while other virtual machines do not have connectivity and are instead dedicated to compute operations.

The CSVs feature is enabled by default in Failover Clustering in Windows Server 2012. To add a disk as a CSV, you must add a disk to the Available Storage group of the cluster (if it is not already added), and then add the disk to the CSVs of the cluster. You can use Failover Cluster Manager or the Failover Clusters Windows PowerShell cmdlets to perform these procedures.

  1. In Failover Cluster Manager, in the console tree, expand the name of the cluster, and then expand Storage.

  2. Right-click Disks, and then click Add Disk. A list appears showing the disks that can be added for use in a failover cluster.

  3. Select the disk or disks you want to add, and then click OK.

    The disks are now assigned to the Available Storage group.

PowerShell-Logo Gleichwertige Windows PowerShell-Befehle

Die folgenden Windows PowerShell-Cmdlets erfüllen dieselbe Funktion wie das vorhergehende Verfahren. Geben Sie die einzelnen Cmdlets in einer einzelnen Zeile ein, auch wenn es den Anschein hat, dass aufgrund von Formatierungseinschränkungen Zeilenumbrüche vorhanden sind.

The following example identifies the disks that are ready to be added to the cluster, and then adds them to the Available Storage group.

Get-ClusterAvailableDisk | Add-ClusterDisk

  1. In Failover Cluster Manager, in the console tree, expand the name of the cluster, expand Storage, and then click Disks.

  2. Select one or more disks that are assigned to Available Storage, right-click the selection, and then click Add to Cluster Shared Volumes.

    The disks are now assigned to the Cluster Shared Volume group in the cluster. The disks are exposed to each cluster node as numbered volumes (mount points) under the %SystemDisk%ClusterStorage folder. The volumes appear in the CSVFS file system.

You can rename CSVs in the %SystemDisk%ClusterStorage folder.

PowerShell-Logo Gleichwertige Windows PowerShell-Befehle

Die folgenden Windows PowerShell-Cmdlets erfüllen dieselbe Funktion wie das vorhergehende Verfahren. Geben Sie die einzelnen Cmdlets in einer einzelnen Zeile ein, auch wenn es den Anschein hat, dass aufgrund von Formatierungseinschränkungen Zeilenumbrüche vorhanden sind.

The following example adds Cluster Disk 1 in Available Storage to CSVs on the local cluster.

Add-ClusterSharedVolume –Name "Cluster Disk 1"

The CSV cache provides caching at the block level of read-only unbuffered I/O operations by allocating system memory (RAM) as a write-through cache. (Unbuffered I/O operations are not cached by the cache manager in Windows Server 2012.) This can improve performance for applications such as Hyper-V, which conducts unbuffered I/O operations when accessing a VHD. The CSV cache can boost the performance of read requests without caching write requests. By default, the CSV cache is disabled.

Two configuration settings control the CSV cache:

  1. SharedVolumeBlockCacheSizeInMB    This is a cluster common property that allows you to define how much memory (in megabytes) to reserve for the CSV cache on each node in the cluster. For example, if a value of 512 is defined, then 512 MB of system memory is reserved on each node. (In many clusters, 512 MB is a recommended value.) The default setting is 0 (for disabled).

  2. CsvEnableBlockCache    This is a private property of the cluster Physical Disk resource. It allows you to enable CSV cache on an individual disk that is added to the cluster CSVs. The default setting is 0 (for disabled). To enable CSV cache on a disk, configure a value of 1.

You can monitor the CSV cache in Performance Monitor by adding the counters under Cluster CSV Volume Cache.

  1. Start Windows PowerShell as an administrator.

  2. To define a cache of 512 MB to be reserved on each node, type the following:

    (Get-Cluster).SharedVolumeBlockCacheSizeInMB = 512
  3. To enable the CSV cache on a CSV named Cluster Disk 1, type the following:

    Get-ClusterSharedVolume "Cluster Disk 1" | Set-ClusterParameter CsvEnableBlockCache 1
  • To avoid resource contention, you should restart each node in the cluster after you modify the memory that is allocated to the CSV cache.

  • After you enable CSV cache on an individual disk, for the setting to take effect, you must take the Physical Disk resource offline and bring it back online.

There are multiple methods for backing up information that is stored on CSVs in a failover cluster running Windows Server 2012. You can use a Microsoft backup application or a non-Microsoft application. In general, CSVs in Windows Server 2012 do not impose special backup requirements beyond those for clustered storage formatted with NTFS. CSV backups in Windows Server 2012 also do not disrupt other CSV storage operations.

You should consider the following factors when you select a backup application and backup schedule for CSVs:

  • Volume-level backup of a CSV can be run from any node that connects to the CSV.

  • Your backup application can use software snapshots or hardware snapshots. Depending on the ability of your backup application to support them, backups can use application-consistent and crash-consistent Volume Shadow Copy Service (VSS) snapshots.

  • If you are backing up CSVs that have multiple running virtual machines, you should generally choose a management operating system based backup method. If your backup application supports it, multiple virtual machines can be backed up simultaneously.

  • CSVs support backup requestors that are running Windows Server 2008 R2 Backup or Windows Server 2012 Backup. However, Windows Server Backup generally provides only a basic backup solution that may not be suitable for organizations with larger clusters.

  • You may require administrative credentials when backing up a failover cluster.

Be sure to carefully review what data your backup application backs up and restores, which CSV features it supports, and the resource requirements for the application on each cluster node.

If you need to restore the backup data onto the CSV, be aware of the capabilities and limitations of the backup application to maintain and restore application-consistent data across the cluster nodes. For example, with some applications, if the CSV is restored on a node that is different from the node where the CSV was backed up, you might inadvertently overwrite important data about the application state on the node where the restore is taking place.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.


© 2014 Microsoft