SQL Server Cluster Shared Volumes (CSV) Frequently Asked Questions and Answers (FAQ) in Interviews

You can find below, some of the Frequently Asked Interview Question and Answers on Cluster Shared Volumes (CSV) in relation with SQL Server.

What is Cluster Shared Volumes (CSV)?
Cluster Shared Volumes (CSV) provides multiple cluster instances in a failover cluster environment to have simultaneous read-write access to the same LUN (disk) that is provisioned as an NTFS volume.

Example: Two SQL Server instances installed on a failover cluster can use same disk D:\ to store its database files. You can failover one SQL instance from one node to another node and does not require the disk D:\ to be failed over to new node, rather the SQL instance will access the disk D:\ from other node, resulting in two SQL instances, each one running on different nodes can use disk D:\ for thier own database files. Refer Cluster Shared Volumes (CSV) for more information.

When was Cluster Shared Volumes (CSV) introduced?
Cluster Shared Volumes (CSV) was introduced with Windows Server 2008 R2 version, but has been completely re-architected in Windows Server 2012 version.

From Which version of SQL Server was Support to Cluster Shared Volumes (CSV) introduced?
Starting with SQL Server 2014, support for deployment of a SQL Server Failover Cluster Instance (FCI) with Cluster Shared Volumes (CSV) was introduced.

What are the advantages of Deploying SQL Server 2014 with Cluster Shared Volumes (CSV)?
Below are some of the advantages of deploying SQL Server with Cluster Shared Volumes (CSV)

Scalability – Allows multiple SQL Server instances to use or share the same LUN/Disk, which otherwise wound need separate disks for each SQL Server instance with traditional disks.

Availability – When connectivity between a cluster node and LUN/DISK fails, the connectivity will be established where Cluster Shared Volumes (CSV) routes the traffic to over the network to the LUN/DISK, thus allowing the SQL Server instance to allow connections without any failures.

Manageability – Cluster Shared Volumes (CSV) simplifies the management of multiple SQL Server instances on cluster nodes.

Performance – Cluster Shared Volumes (CSV) provide a read-only cache for unbuffered I/O to SQL databases.

Security – Cluster Shared Volumes (CSV) allows integration with BitLocker which allows to secure the deployments outside of the data-centers, such as at branch offices. Volume level encryption allows in meeting the security compliance requirements.

How does SQL Server installation procedure differs with using Cluster Shared Volumes (CSV)?
First, we need to setup Cluster Shared Volumes (CSV) instead of traditional cluster disks, this is to be done by System Administrator. Most of the SQL Server cluster instance installation steps are same even while we use Cluster Shared Volumes (CSV), only place where we change settings during the installation process is in Database Engine Configuration – Data Directories tab where we provide the Cluster Shared Volumes paths like C:\ClusterStortage\SQLServerInstance\ for data root directory and for user database data and log files.

How do I see the physical database files which are on Cluster Shared Volumes (CSV)?
We can browse to the Cluster Shared Volumes (CSV) just like we browse any other folder through windows file explorer. We need to check the path C:\ClusterStorage directory and under that the folder which we specified during the installation for the respective database files, which will have our database files.

Does Disk resource move to another node during the SQL Server instance failover process?
No, disk resource is nor part of the SQL Server group where we have our SQL instances, so disk resource will not failover when we failover a SQL Server instance.

What all cluster resources move during failover of SQL Server instance?
Below are the cluster resources which move to new node when we perform a failover of SQL Server instance from one node to another node.

SQL Server Network Name
SQL Server IP Addresses
SQL Server
SQL Server Agent
Any other resources in the group file fileshare or third party backup resources, etc.

What is the state of Cluster Shared Volumes (CSV) during the failover of SQL Server instance?
Cluster Shared Volumes (CSV) remains ONLINE and is not affected during the time when SQL Server instance is failed over from one node to another node. There is no requirement to failover the disk resources to the node where SQL Instances are running.

Receiving error during the installation of SQL Server while using the Cluster Shared Volumes (CSV)?
There are some people who received various errors while they try to specify the data directories path to Cluster Shared Volumes (CSV) and may receive errors like ” The volume that contains the SQL server Data directory does not belong to Cluster Group”.

These errors are mostly related and occurs when you try to use the Cluster Shared Volumes (CSV) with SQL Server 2012 or lower versions. Support to Cluster Shared Volumes (CSV) for SQL Server was only introduced with SQL Server 2014.

Is Cluster Shared Volumes (CSV) similar to Oracle RAC and does SQL Server allow all cluster nodes to perform Read/Write, thus allows load balancing?
Cluster Shared Volumes (CSV) provides a clustered file system which is basically a storage infrastructure for SQL Server, it is possible to allow RAC like support. Even without a Cluster Shared Volumes (CSV), you can still achieve a load balance where read workloads can be spread on primary and multiple secondary replicas.

Unable to view Cluster Shared Volumes (CSV) from SQL Server Management Studio (SSMS) while trying to perform Backup or Restore?
This ideally should work, where one should be able to view the Cluster Shared Volumes (CSV) from SQL Server Management Studio (SSMS) backup or restore wizards. This has been notified as a bug to the Microsoft Product team and most likely a fix would be released, so make sure that SQL Server 2014 instance is patched with latest updates and test the backup and restores.

 

Leave a Reply

Your email address will not be published. Required fields are marked *