A failover clustered instance (FCI) is a high-availability design in which multiple cluster nodes share database storage. When the active node fails, another node takes ownership of that storage and databases automatically. It keeps one copy of the data rather than synchronizing replicas, making it a practical option when write volume makes availability groups costly or unsuitable. section 9.11 section 13.4
Do not treat an FCI as outage-free or as a universal replacement for availability groups:
- Expect a failover interruption: an FCI failover averages about 30 seconds, which can seriously disrupt a long-running ETL process even when database availability returns quickly. section 9.11
- Choose it for the workload, not fashion. High-write on-premises data warehouses may avoid the extra I/O of FULL recovery model and fully logged transactions required for availability groups. section 13.4
- Patch clustered systems on a schedule. If a short interruption is acceptable, schedule rolling updates during working hours; otherwise use a quieter weekend period. section 9.11
- Capacity-plan and test failover. Overloaded clusters can encounter problems during takeover, and DR testing should include users validating post-failover performance. section 13.6
Nightly warehouse ETL
A warehouse ETL run must finish by morning. Availability groups would require FULL recovery and substantially increase logging I/O, extending the run beyond its deadline. An FCI instead stores the data once and can move its shared storage from a failed node to a redundant node. The operational trade-off is a roughly 30-second failover, so patching and other planned interruptions must be scheduled outside the ETL window when necessary. section 9.11 section 13.4
Figure 13.4 HA with failover clustering providing automatic failover in a single site
The topology depicts single-site high availability: shared database storage moves from the failed cluster node to a redundant node for automatic failover. section 13.4
