Stackvora.tech

Windows Server Failover Cluster: Cluster Shared Volumes explained

Cluster Shared Volumes (CSV) are a cornerstone technology for highly available virtualized environments and clustered applications on Windows Server…

Cluster Shared Volumes (CSV) are a cornerstone technology for highly available virtualized environments and clustered applications on Windows Server Failover Clusters. They enable multiple nodes within a cluster to concurrently access the same shared storage volume, a prerequisite for capabilities like Hyper-V Live Migration, continuously available file shares for SQL Server or Scale-Out File Server (SOFS), and facilitating rapid failover by eliminating the need to dismount and remount volumes during a node transition.

This article details the architecture, operational mechanics, and practical implementation of Cluster Shared Volumes. We'll cover their core functionality, essential prerequisites, and step-by-step guidance for configuration and verification, along with common issues and best practices.

Understanding Cluster Shared Volumes (CSV) Architecture

At its heart, CSV abstracts shared block-level storage into a single namespace accessible by all cluster nodes. While traditional clustered disks allow only one node to "own" and mount a volume at a time, CSV allows all nodes to mount the same NTFS or ReFS volume concurrently, each seeing it as C:\ClusterStorage\VolumeX.

The innovation lies in how I/O is handled:

  • Direct I/O: For most read and write operations, each node directly accesses the underlying storage (SAN LUN, iSCSI target, Storage Spaces Direct volume) through its own fabric connection. This provides optimal performance, as I/O does not traverse the cluster network.
  • Metadata Operations and Coordinator Node: One node is designated as the "coordinator" (or "owner") for each CSV. This role is dynamic and can shift between nodes. The coordinator node is responsible for handling all metadata operations on the volume (e.g., creating files, renaming directories, extending files, updating timestamps, managing file locks). These operations are serialized through the coordinator to maintain consistency across the cluster. Other nodes performing metadata operations will communicate with the coordinator node over the cluster network via Server Message Block (SMB).
  • Redirected I/O: If a node loses its direct access path to the shared storage (e.g., a Fibre Channel HBA failure, iSCSI path outage), or if the underlying storage does not support direct block access (e.g., certain iSCSI configurations where multi-pathing is not fully configured or array-level LUN masking prevents simultaneous direct access), that node will automatically redirect all its I/O requests for that CSV over the cluster's private network (SMB 3.0) to the current coordinator node. The coordinator node then performs the I/O on behalf of the redirected node. This mechanism ensures continuous availability even in the face of partial storage path failures. Performance is significantly degraded during redirected I/O, indicating a problem that needs immediate attention.

CSV leverages the SMB 3.0 protocol for inter-node communication, including metadata operations and redirected I/O. SMB 3.0's capabilities like SMB Multichannel (using multiple network paths) and SMB Direct (RDMA for low latency) enhance CSV performance and resilience.

Prerequisites for CSV Implementation

Before you can configure Cluster Shared Volumes, ensure your environment meets these fundamental requirements:

  • Windows Server Version: Windows Server 2012 or newer. For optimal performance and features (like ReFS and enhanced S2D integration), Windows Server 2019 or 2022 is recommended. All cluster nodes must run the same Windows Server version and edition (e.g., Datacenter or Standard).
  • Failover Clustering Feature: The "Failover Clustering" feature must be installed on all participating nodes.
  • Shared Storage: Block-level shared storage accessible by all cluster nodes. Common options include:
    • Fibre Channel (FC) SAN: LUNs presented to all HBAs on all nodes.
    • iSCSI SAN: LUNs presented to all iSCSI initiators on all nodes. Ensure MPIO (Multipath I/O) is configured for redundancy and performance.
    • Serial Attached SCSI (SAS): Directly attached shared storage enclosures.
    • Storage Spaces Direct (S2D): For hyperconverged infrastructure, S2D inherently creates shared volumes suitable for CSV.
    The shared storage must be initialized as GPT (GUID Partition Table) and formatted with NTFS or ReFS.
  • Network Configuration: A robust, redundant network infrastructure. At least two network adapters per node are recommended: one for client connectivity and management, and another dedicated for cluster heartbeat, internal cluster communication, and CSV redirected I/O traffic. 10 GbE or higher is recommended for the cluster network, especially with S2D or heavy CSV utilization.
  • Failover Cluster Creation: A Windows Server Failover Cluster must be already created and validated successfully.

Configuring Cluster Shared Volumes

The process of setting up CSV involves presenting the disk to the cluster and then adding it as a shared volume. We'll use PowerShell for this, as it offers precision and scripting capabilities.

Step 1: Present and Initialize the Shared Disk

Ensure the shared LUN is presented to all cluster nodes. It should appear as "Offline" (MBR) or "Unknown" in Disk Management on all nodes. For a new disk:

  1. On one cluster node, open an elevated PowerShell console.
  2. Identify the disk number of the new shared LUN. You can use Get-Disk to list available disks. Look for a disk with status 'Offline' and 'RAW' partition style, or one matching your expected size.
  3. Initialize the disk, create a partition, and format it. We'll use GPT for modern systems.
# Example: Assuming Disk 5 is your new shared LUN
# First, ensure the disk is offline and clear any existing partitions if needed
# Get-Disk -Number 5 | Set-Disk -IsOffline $true
# Clear-Disk -Number 5 -RemoveData -Confirm:$false

Initialize-Disk -Number 5 -PartitionStyle GPT
New-Partition -DiskNumber 5 -UseMaximumSize -DriveLetter V # Assign a temporary drive letter
Format-Volume -DriveLetter V -FileSystem ReFS -NewFileSystemLabel "CSV01" -AllocationUnitSize 64KB # ReFS recommended for Hyper-V or SOFS
# You can remove the drive letter if desired, it's not strictly necessary for CSV
# Get-Partition -DriveLetter V | Remove-PartitionAccessPath -AccessPath "V:"

While the example uses ReFS with a 64KB allocation unit size, which is optimized for Hyper-V virtual hard disks, NTFS is also fully supported. For general purpose file shares or older applications, NTFS might be more appropriate. Consistency in allocation unit size across all volumes hosting similar workloads is a good practice.

Step 2: Add the Disk to the Cluster and as a Cluster Shared Volume

Once the disk is formatted, it needs to be added as available storage to the cluster, and then converted into a CSV.

# Get all available storage disks and add them to the cluster
# This step might automatically find and add the disk formatted above
Get-ClusterAvailableDisk | Add-ClusterDisk

# List all current cluster disks and identify the one you want to convert
# Note the 'Name' column from the output (e.g., "Cluster Disk 1")
Get-ClusterResource -ResourceType "Physical Disk" | Format-Table Name, State, OwnerNode

# Add the identified cluster disk as a Cluster Shared Volume
Add-ClusterSharedVolume -Name "Cluster Disk 1"

Upon successful execution, the volume will now be accessible from all cluster nodes under a path similar to C:\ClusterStorage\Volume1. Subsequent CSVs will appear as Volume2, Volume3, etc., or use the name specified during creation.

Step 3: Verify CSV Status and Operation

It's crucial to verify that the CSV is operating as expected. Use the following PowerShell commands:

# Check the status of all CSVs in the cluster
Get-ClusterSharedVolume | Format-Table Name, State, OwnerNode, SharedVolumeInfo, Id

# Verify the mount point on a local node
# Replace 'Volume1' with the actual name or number if different
dir C:\ClusterStorage\Volume1

The OwnerNode column indicates the current coordinator node for that CSV. SharedVolumeInfo provides additional details like the path to the underlying physical disk. To test the coordinator role's mobility, you can manually move it:

# Move the coordinator role for "Cluster Disk 1" to NODE2
Move-ClusterSharedVolume -Name "Cluster Disk 1" -Node NODE2
# Verify the change
Get-ClusterSharedVolume | Format-Table Name, State, OwnerNode

This operation should be quick and non-disruptive, as it only transfers the metadata ownership role.

Common Pitfalls and Troubleshooting

  • Antivirus Scanning: Antivirus software scanning the C:\ClusterStorage path can severely impact performance and cause cluster instability. Always configure exclusions for C:\ClusterStorage\* on all cluster nodes.
  • Redirected I/O: Persistent redirected I/O for a node indicates an issue with its direct storage path. This can be due to:
    • Fibre Channel or iSCSI HBA failure.
    • MPIO misconfiguration or driver issues.
    • Network isolation between a node and the storage fabric.
    • Incorrect LUN masking on the SAN.
    • Lack of appropriate storage drivers or firmware.
    Monitor event logs (System, Microsoft-Windows-FailoverClustering/Diagnostic) and check Get-ClusterSharedVolume | select Name, Id, @{N='Redirected I/O';E={(Get-Counter "\Cluster CSV File System(*)\File System Redirected Reads").CounterSamples | Where-Object InstanceName -eq ($_.Name)}}, @{N='Redirected I/O';E={(Get-Counter "\Cluster CSV File System(*)\File System Redirected Writes").CounterSamples | Where-Object InstanceName -eq ($_.Name)}} (this example is simplified, direct performance counter check is more robust) to detect redirected I/O.
  • Deduplication with CSV: While possible, data deduplication on CSV is primarily designed for VDI (Virtual Desktop Infrastructure) or similar workloads with high data redundancy. It's not generally recommended for Hyper-V host volumes or high-performance SQL Server data volumes due to potential performance overhead. If using ReFS, block cloning provides similar space efficiency for VHDX files without the overhead of full deduplication.
  • Network Performance: The cluster network carries critical heartbeat signals, metadata operations, and potential redirected I/O. Insufficient bandwidth (e.g., 1 GbE for busy clusters) or network latency can lead to cluster instability, split-brain scenarios, or poor CSV performance. Dedicate high-speed (10 GbE or faster) networks for inter-node and storage communication.
  • Storage Controller Configuration: Ensure the underlying storage array is configured for appropriate multi-pathing and LUN presentation to all nodes. Check HBA drivers and firmware are up to date.
  • Volume Shadow Copy Service (VSS): VSS snapshots on CSVs are handled by the coordinator node. Ensure sufficient resources and proper configuration for VSS writers if you're using backup solutions that leverage VSS.

Back to the knowledge base · Ask the AI assistant