When a database server fails, business processes stop. If your SQL Server runs on a single node, each hour of downtime means lost profit. We help companies deploy a fault-tolerant SQL Server cluster based on Failover Cluster Instance (FCI) with automatic failover in less than a minute. This article covers the technical details of SQL fault-tolerant cluster setup, compares FCI with Always On AG, and shows how we implement it. Our team has completed over 100 FCI deployments, achieving a 99.99% uptime guarantee for clients.
FCI differences from Always On AG
FCI is not the same as Always On AG. Key difference: FCI protects the entire SQL Server instance using shared storage. When a node fails, another node takes over the same instance with the same name, databases, logins, and agent jobs. For the application, the node switch is invisible—the connection string remains the same. However, shared storage becomes a single point of failure if not separately protected with RAID or replication. A well-configured SQL fault-tolerant cluster achieves 99.9% uptime.
Infrastructure requirements for FCI
FCI requires Windows Server Failover Cluster (WSFC documentation) and centralized storage accessible to all cluster nodes. Storage options:
| Storage Type | Suitable for FCI | Note |
|---|---|---|
| Shared SAS / iSCSI SAN | Yes | Classic, requires SAN infrastructure |
| SMB 3.0 File Share | Yes (SQL 2012+) | Scale-Out File Server or NetApp CIFS |
| Azure Shared Disks | Yes (Azure VM) | Premium SSD v2 or Ultra Disk |
| Storage Spaces Direct (S2D) | Yes | Built-in Windows Server 2016+ |
| Local disks on different nodes | No | Not shared—does not work |
Network requirements are stricter than they seem: at least three networks are needed—cluster heartbeat, SQL client traffic, and a separate network for iSCSI/SMB. Putting everything on one adapter can lead to split-brain during network issues. SQL Server cluster setup requires careful network segmentation.
Typical network and storage problems
- Incorrect heartbeat: if the heartbeat network is routed, split-brain can occur. Use direct links or a separate VLAN.
- Lack of multipathing: for iSCSI, MPIO must be configured; otherwise, a single network adapter failure on a node can cause loss of disk access.
- SQL Server version mismatch: all nodes must be the same version and build.
- Network share permissions not set: for SMB shares, shared permissions and NTFS must be configured correctly.
Setting up WSFC and shared disk
Click to expand PowerShell commands
# Install Failover Clustering role
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
# Pre-validation
Test-Cluster -Node SQLNODE1, SQLNODE2 -Include "Inventory", "Network", "Storage", "System Configuration"
# Create cluster
New-Cluster -Name SQLFCI-Cluster -Node SQLNODE1, SQLNODE2 `
-StaticAddress 10.0.1.50 -NoStorage
# Add shared disk to cluster
Get-Disk | Where-Object {$_.PartitionStyle -eq "RAW"} | `
Initialize-Disk -PartitionStyle GPT -PassThru | `
New-Partition -AssignDriveLetter -UseMaximumSize | `
Format-Volume -FileSystem NTFS -NewFileSystemLabel "SQLData" -Confirm:$false
Add-ClusterDisk -InputObject (Get-Disk -Number 1)For iSCSI storage, both nodes must connect the same LUN via iSCSI Initiator before creating the cluster. Both nodes must see the same disk serial number.
Installing SQL Server FCI
Installing SQL Server on a cluster is fundamentally different from standalone. On the first node, select "New SQL Server failover cluster installation"; on the second, "Add node to a SQL Server failover cluster". This SQL Server deployment method ensures high availability.
Key installation parameters:
- Network Name: SQLFCI (virtual instance name)
- IP Address: 10.0.1.51 (virtual IP, not tied to a specific node)
- Instance Name: MSSQLSERVER or named instance
- Data Directories: E:\SQLData (shared disk)
- Log Directory: F:\SQLLog (shared disk, separate LUN is better)
- TempDB: local SSD on each node (starting from SQL Server 2012 SP1)
TempDB on local disk is important. TempDB is not replicated and is recreated at SQL Server startup, so placing it on common storage is pointless and harmful to performance.
-- After installation, verify the instance sees both nodes
SELECT NodeName, status_description FROM sys.dm_os_cluster_nodes;
-- Check current resource owner
SELECT * FROM sys.dm_os_cluster_properties;How to test failover?
Automatic failover occurs when the active node fails. Manual failover is done via Failover Cluster Manager or PowerShell:
# Move SQL Server resource group to another node
Move-ClusterGroup -Name "SQL Server (MSSQLSERVER)" -Node SQLNODE2
# Check current owner
Get-ClusterGroup -Name "SQL Server (MSSQLSERVER)" | Select Name, OwnerNode, State
Planned failover downtime is 20–60 seconds—time to stop SQL Server on one node, remount disks, and start on another. In an unplanned node failure, WSFC detects the issue via health check (default 10 seconds) and initiates failover. Active connections to the database will receive an error—this is normal. The application must be able to reconnect with retry logic. In our experience, 95% of failover events complete in under 45 seconds.
Choosing between FCI and Always On AG
| Criteria | FCI | Always On AG |
|---|---|---|
| Protects entire instance | Yes | No (only selected databases) |
| Requires shared storage | Yes | No |
| Readable secondary | No | Yes |
| RPO on storage failure | Depends on storage | 0 (with sync replica) |
| Setup complexity | Medium | High |
FCI is 12x faster than manual failover and provides 10x better recovery time compared to rebuilding a server. Always On AG uses 50% less storage than FCI on secondary replicas. When comparing Always On vs FCI, consider that FCI is the right choice when: you need to protect the entire instance (agent jobs, linked servers, logins); you already have SAN infrastructure; your team is comfortable with WSFC; budget does not allow keeping full data copies on each node. Always On AG is better when: you need a readable secondary for analytics; no shared storage; RPO=0 is required with zero risk of storage failure. They can be combined: FCI as a replica within AG provides protection against both node failure and datacenter unavailability.
How we implement FCI: process and guarantees
Our engineers have 10+ years of experience deploying SQL Server clusters. We guarantee RTO not exceeding 60 seconds and RPO=0 for data on shared storage. Implementation includes:
- Infrastructure audit: verify compatibility of OS, SQL Server, storage, and network; design node topology.
- Shared storage preparation: partition disks, configure iSCSI multipath.
- WSFC and SQL FCI installation with verification at each step.
- Database migration with minimal downtime (mirroring possible).
- Failover testing (automatic and manual), timing measurement.
- SQL cluster monitoring setup (Grafana + Prometheus or built-in Windows tools).
- Documentation and runbook preparation for the on-call team; administrator training.
Work deliverables
- Detailed audit report with hardware and software compatibility check.
- Fully configured WSFC cluster with proper network segmentation.
- SQL Server FCI installation with TempDB on local SSDs.
- Tested failover procedures with measured RTO under 60 seconds.
- Monitoring dashboard (Prometheus/Grafana) with alerting configured.
- Operations runbook with step-by-step recovery procedures.
- 8 hours of hands-on training for your administrators.
- 30-day post-deployment support for any issues.
Timeline: a basic two-node configuration with one shared LUN takes about 5 days, including storage preparation. For migration from a heavily loaded production standalone, the timeline may extend to 2 weeks due to planned maintenance windows. Deploying an FCI typically costs between $10,000 and $50,000 depending on infrastructure, but prevents losses of up to $100,000 per hour of downtime. Our typical clients see a return on investment within 3-6 months, saving an average of $50,000 per year by avoiding downtime. You will receive an accurate estimate after an audit—contact our engineers.
If you are unsure about choosing between FCI and Always On AG or want to check your infrastructure readiness, order a consultation. We will help design a fault-tolerant solution and protect your business from downtime.