Khi xây dựng hệ thống SQL Server có tính sẵn sàng cao, hai lựa chọn thường được đặt lên bàn cân là Always On Availability Group (AG) và SQL Server Failover Cluster Instance (FCI), thường được gọi ngắn là “SQL Clustering”. Cả hai đều có thể tự động chuyển dịch vụ khi có sự cố, nhưng chúng bảo vệ những thành phần khác nhau, sử dụng storage khác nhau và kéo theo cách cấp phép, vận hành hoàn toàn khác nhau.
1. Trước hết, “SQL Always On” và “SQL Clustering” là gì?
Microsoft dùng “Always On” như một nhóm công nghệ tính sẵn sàng cao của SQL Server. Trong nhóm này có cả Always On Availability Groups và Always On Failover Cluster Instances. Vì vậy, cách gọi “Always On hay Clustering” khá phổ biến trong thực tế nhưng chưa hoàn toàn chính xác về thuật ngữ.
Trong bài viết này:
- Availability Group (AG): nhiều SQL Server instance giữ các bản sao của cùng một nhóm database và đồng bộ transaction log.
- Failover Cluster Instance (FCI): một SQL Server instance được cài đặt trên nhiều node Windows Server Failover Cluster và chỉ hoạt động trên một node tại một thời điểm.
- WSFC: Windows Server Failover Clustering, nền tảng cluster và quorum thường được cả hai kiến trúc sử dụng khi triển khai trên Windows.
2. Khác biệt cốt lõi: bảo vệ instance hay bảo vệ database?
| Tiêu chí | SQL Server FCI | Availability Group |
|---|---|---|
| Phạm vi bảo vệ | Toàn bộ SQL Server instance. | Một hoặc nhiều user database được đưa vào Availability Group. |
| Đơn vị failover | Instance cùng các dịch vụ/resource thuộc cluster role. | Một Availability Group và các database trong nhóm đó. |
| System databases | Được bảo vệ cùng instance nhờ sử dụng chung storage và cấu hình cluster. | Không tự đồng bộ theo AG truyền thống. Login, SQL Agent Job, linked server và cấu hình cấp instance cần quy trình riêng. |
| Điểm kết nối ứng dụng | Virtual Network Name của FCI. | Availability Group Listener. |
Đây là câu hỏi đầu tiên cần trả lời. Nếu ứng dụng phụ thuộc mạnh vào SQL Agent Job, login, linked server, credential, server-level trigger hoặc nhiều database ngoài một nhóm failover, FCI thường giúp giữ trải nghiệm instance nhất quán hơn. Với AG, đội vận hành phải đảm bảo các đối tượng ngoài database tồn tại và đồng bộ đúng trên mọi replica.
3. Storage: dùng chung hay mỗi replica một bản sao?
FCI sử dụng shared storage
Các node của FCI cùng truy cập một bộ data file và transaction log trên shared storage. Storage có thể là SAN, WSFC cluster disk, Storage Spaces Direct hoặc SMB file share theo cấu hình được hỗ trợ. Khi failover, node mới mở chính bộ dữ liệu đang được node cũ sử dụng.
- Không cần truyền transaction log giữa các node FCI để duy trì một bản sao database thứ hai.
- Dung lượng lưu trữ thường hiệu quả hơn vì chỉ có một bộ data file chính.
- Chất lượng và tính sẵn sàng của shared storage trở thành yếu tố sống còn.
- Nếu storage bị lỗi hoặc dữ liệu bị corruption, toàn bộ node có thể cùng chịu ảnh hưởng.
Availability Group sử dụng storage riêng
Mỗi replica có SQL Server instance và một bản sao database trên storage riêng. Primary gửi transaction log records tới secondary; secondary ghi log xuống đĩa và thực hiện redo để duy trì bản sao.
- Loại bỏ sự phụ thuộc vào một shared disk duy nhất giữa các replica.
- Có thể đặt replica ở site hoặc vùng địa lý khác cho mục tiêu disaster recovery.
- Cần nhiều dung lượng hơn vì mỗi secondary giữ một bản sao database.
- Hiệu năng phụ thuộc vào network, log generation rate, tốc độ harden/redo và độ trễ giữa các site.
Availability Group = nhiều SQL instance + nhiều bản sao database + đồng bộ transaction log
4. RPO và nguy cơ mất dữ liệu
RPO không nên được đánh giá chỉ bằng tên công nghệ.
| Tình huống | FCI | Availability Group |
|---|---|---|
| Node hoặc hệ điều hành lỗi | Node mới sử dụng cùng storage; giao dịch đã ghi bền vững trên shared storage không cần copy sang node khác. | Với synchronous commit và secondary ở trạng thái synchronized, failover có thể không làm mất giao dịch đã commit. |
| Storage chính lỗi | Phụ thuộc vào khả năng dự phòng của SAN/S2D/SMB. Shared storage kém thiết kế có thể là điểm lỗi chung. | Replica dùng storage riêng có thể tiếp tục nếu bản sao còn nguyên vẹn và đủ điều kiện failover. |
| Replica ở xa, asynchronous commit | Không phải mô hình đồng bộ dữ liệu điển hình của FCI. | Primary không chờ secondary harden log, do đó forced failover có thể mất phần dữ liệu chưa đồng bộ. |
| Logical corruption hoặc người dùng xóa nhầm | Cả hai không thay thế backup. Lỗi logic có thể được ghi vào storage hoặc đồng bộ sang replica khác. | |
Synchronous commit tăng bảo vệ dữ liệu nhưng làm tăng latency giao dịch vì primary phải chờ xác nhận harden log từ synchronous secondary. Asynchronous commit phù hợp hơn cho DR khoảng cách xa nhưng chấp nhận RPO lớn hơn 0 khi forced failover.
5. RTO và thời gian failover
Không có một con số failover cố định áp dụng cho mọi hệ thống. RTO phụ thuộc vào thời gian phát hiện lỗi, quorum, DNS/network, crash recovery, số lượng database, transaction đang mở, tốc độ storage và khả năng ứng dụng tự kết nối lại.
- FCI: WSFC dừng resource trên node cũ, chuyển quyền sở hữu, khởi động SQL Server services trên node mới và thực hiện recovery database. Với database lớn hoặc nhiều dirty pages, thời gian recovery có thể đáng kể.
- AG: secondary synchronized được chuyển thành primary và đưa database online. Ứng dụng kết nối lại qua listener. Recovery time vẫn phụ thuộc vào redo queue, undo và connection retry.
Dù chọn kiến trúc nào, phải chạy thử planned failover và simulated failure bằng workload đại diện. SLA chỉ có ý nghĩa khi được đo từ phía ứng dụng, không chỉ từ trạng thái “Online” trong cluster hoặc dashboard SQL Server.
6. Read-only workload và backup offload
Đây là lợi thế nổi bật của Availability Group. Tùy phiên bản, edition, cấu hình routing và giấy phép, secondary replica có thể phục vụ truy vấn read-only hoặc thực hiện một số loại backup. Điều này giúp giảm tải primary và tận dụng tài nguyên secondary.
Trong FCI, chỉ node đang sở hữu resource group chạy SQL Server services của instance. Node passive không phải một SQL Server đọc độc lập và không dùng để chạy báo cáo hay backup database như readable secondary của AG.
7. Phiên bản SQL Server Standard và Enterprise
Khả năng HA phụ thuộc edition. Theo tài liệu tính năng SQL Server 2025 của Microsoft:
| Tính năng | Standard | Enterprise |
|---|---|---|
| Failover Cluster Instance | Có, tối đa hai node. | Có, tối đa 16 node. |
| Basic Availability Group | Có; hai replica và một database cho mỗi Basic AG. | Không áp dụng vì sử dụng full Availability Groups. |
| Full Availability Group | Không. | Có; tối đa tám secondary replica, trong đó tối đa năm synchronous secondary theo tài liệu Microsoft. |
| Contained Availability Group | Không. | Có. |
Nếu doanh nghiệp dùng SQL Server 2019 hoặc 2022, hãy đối chiếu bảng tính năng đúng phiên bản thay vì mặc định mọi giới hạn đều giống SQL Server 2025.
8. So sánh vận hành
| Hạng mục | FCI | Availability Group |
|---|---|---|
| Cài đặt và patch | Các node cần cấu hình OS, SQL version, patch level và components tương thích. Có thể patch node passive rồi failover theo kế hoạch. | Mỗi replica là một SQL instance độc lập. Rolling upgrade/failover linh hoạt nhưng phải kiểm soát compatibility và data synchronization. |
| Quản lý login/job | Đơn giản hơn vì cùng một clustered instance. | Cần đồng bộ login SID, SQL Agent Job, linked server, credential và cấu hình ngoài database; contained AG có thể giảm một phần bài toán ở edition hỗ trợ. |
| Capacity | Node dự phòng phải đủ CPU/RAM để tiếp nhận toàn bộ instance sau failover. | Secondary phải đủ tài nguyên để harden/redo log và tiếp nhận workload khi thành primary. |
| Monitoring | Theo dõi WSFC, quorum, SQL health, resource group, network name và shared storage. | Theo dõi WSFC/quorum, send queue, redo queue, synchronization state, listener và replication health. |
| Backup | Backup từ active instance. | Có thể phân bổ một số backup sang secondary theo loại backup và cấu hình; vẫn cần chiến lược backup/restore độc lập. |
9. Cấp phép SQL Server cho HA/DR
Kiến trúc đúng kỹ thuật chưa chắc đã đúng giấy phép. Hướng dẫn cấp phép SQL Server 2025 hiện hành của Microsoft nêu rằng quyền chạy các failover replica thụ động cho HA/DR gắn với Software Assurance hoặc subscription license.
Với mỗi physical hoặc virtual OSE đã được cấp phép phù hợp và có SA/subscription, Microsoft mô tả quyền chạy:
- Một passive failover replica cho high availability trong một OSE riêng.
- Một passive failover replica cho disaster recovery trong một OSE riêng.
- Một passive failover replica cho disaster recovery trong một VM hoặc instance trên Azure.
Replica thụ động là replica không phục vụ dữ liệu cho client và không chạy SQL workload chủ động. Quyền này có thể áp dụng cho cả Availability Group lẫn Failover Cluster Instance, nhưng phải kiểm tra edition, số core, mô hình Per Core hay Server + CAL, phạm vi SA/subscription và hợp đồng thực tế.
| Tình huống | Ý nghĩa cấp phép cần xem xét |
|---|---|
| Node FCI chỉ chờ failover | Có thể thuộc quyền passive HA nếu license chính có SA/subscription và đáp ứng Product Terms. |
| Secondary AG chỉ đồng bộ, không phục vụ workload | Có thể thuộc quyền passive failover tương ứng nếu đủ điều kiện. |
| Secondary AG chạy báo cáo/read-only | Đây là active workload; cần cấp phép phù hợp cho secondary. |
| Secondary thực hiện backup hoặc tác vụ chủ động | Không nên tự mặc định là passive; cần đối chiếu Product Terms và hướng dẫn cấp phép hiện hành. |
| License không có SA và không phải subscription | Hướng dẫn SQL Server 2025 nêu rằng không bao gồm quyền HA/DR, kể cả use of failover clusters. |
Lưu ý: bài viết chỉ giải thích nguyên tắc, không thay thế Product Terms hoặc thỏa thuận cấp phép. Quy tắc có thể thay đổi theo phiên bản SQL Server, chương trình mua, Azure Arc, CSP, SPLA và quyền đã ký kết.
10. Khi nào nên chọn SQL Server FCI?
FCI thường phù hợp hơn khi:
- Cần bảo vệ toàn bộ instance thay vì chọn từng database.
- Ứng dụng phụ thuộc nhiều vào SQL Agent Job, login, linked server và đối tượng cấp instance.
- Doanh nghiệp đã có SAN, Storage Spaces Direct hoặc SMB storage được thiết kế HA đúng chuẩn.
- Không có nhu cầu sử dụng node passive cho read-only workload.
- Cần một tên instance/virtual server nhất quán, giảm thay đổi phía ứng dụng.
- SQL Server Standard cần bảo vệ nhiều database trong cùng instance và giới hạn một database của Basic AG không phù hợp.
FCI không tự biến shared storage thành một hệ thống DR. Nếu toàn bộ site hoặc storage gặp sự cố, cluster node thứ hai cùng site có thể không giúp được. Khi cần DR, phải bổ sung replication ở storage, multi-subnet design hoặc một công nghệ database-level khác.
11. Khi nào nên chọn Availability Group?
AG thường phù hợp hơn khi:
- Cần RPO/RTO theo từng nhóm database nghiệp vụ.
- Muốn các replica dùng storage độc lập để giảm điểm lỗi chung.
- Cần replica ở site khác hoặc khoảng cách xa cho disaster recovery.
- Cần read-only routing, reporting hoặc backup offload và đã tính đủ license.
- Cần failover một ứng dụng/database group mà không chuyển cả instance.
- Có đội DBA đủ khả năng quản lý synchronization, listener, login/job và quy trình failover phức tạp hơn.
AG không bảo vệ mọi database và mọi thành phần của instance theo mặc định. Database chưa tham gia AG, system database và nhiều đối tượng server-level vẫn cần kế hoạch HA riêng.
12. Có thể kết hợp FCI và Availability Group không?
Có. Một kiến trúc phổ biến là dùng FCI để bảo vệ instance trong data center chính, sau đó đặt database của FCI vào Availability Group để có replica DR ở site khác. Cách này cung cấp nhiều lớp bảo vệ nhưng làm tăng đáng kể độ phức tạp, chi phí storage, SQL/Windows licensing, quorum và runbook.
Microsoft lưu ý FCI không hỗ trợ automatic failover bởi Availability Group tới node khác trong AG theo cách thông thường; nếu một availability replica được host bởi FCI, các kịch bản failover giữa FCI và replica khác cần được thiết kế, kiểm thử và có thể phải thực hiện thủ công tùy kiến trúc.
13. Ma trận lựa chọn nhanh
| Nhu cầu ưu tiên | Lựa chọn thường phù hợp | Lý do |
|---|---|---|
| Bảo vệ toàn bộ instance | FCI | Failover SQL Server instance cùng resource và kết nối virtual. |
| Không muốn shared storage giữa replica | AG | Mỗi replica có storage và bản sao database riêng. |
| DR sang site khác | AG hoặc kiến trúc kết hợp | Asynchronous replica phù hợp khoảng cách xa; phải chấp nhận RPO và manual forced failover. |
| Read-only/reporting trên secondary | AG Enterprise | Readable secondary và read-only routing; cần license cho active secondary. |
| SQL Standard, nhiều database cùng instance | Thường cân nhắc FCI | Basic AG giới hạn hai replica và một database cho mỗi AG. |
| Failover độc lập theo ứng dụng | AG | Nhóm database của từng ứng dụng có thể có policy và listener riêng. |
| Đơn giản hóa server-level objects | FCI | Cùng một clustered instance, giảm nhu cầu đồng bộ login/job thủ công. |
| HA nội bộ và DR từ xa cùng lúc | FCI + AG | Phủ nhiều loại sự cố hơn nhưng chi phí và vận hành cao nhất. |
14. Checklist trước khi ra quyết định
- Xác định SLA cho từng ứng dụng: RPO, RTO và thời gian bảo trì cho phép.
- Liệt kê database cần failover cùng nhau và dependency giữa các database.
- Kiểm kê login, SQL Agent Job, linked server, credential, SSIS, replication và server-level object.
- Đo transaction log generation, network latency, bandwidth và tốc độ storage.
- Xác định phạm vi sự cố cần chịu được: process, OS, host, storage, rack, data center hay khu vực địa lý.
- Kiểm tra edition và giới hạn tính năng đúng phiên bản SQL Server đang mua.
- Tính license cho primary, passive HA, passive DR, readable secondary và Windows Server.
- Thiết kế WSFC quorum, witness, DNS, IP, subnet và connection string.
- Xây dựng backup, restore, DBCC CHECKDB và ransomware recovery độc lập với HA.
- Chạy thử planned failover, unplanned failover và failback từ góc nhìn ứng dụng.
15. Những hiểu lầm thường gặp
| Hiểu lầm | Thực tế |
|---|---|
| “Có HA thì không cần backup” | Replica và cluster không bảo vệ đầy đủ trước xóa nhầm, corruption, ransomware hoặc lỗi logic. |
| “AG luôn không mất dữ liệu” | Chỉ synchronous commit với secondary synchronized và failover đúng điều kiện mới bảo vệ giao dịch đã commit; asynchronous forced failover có thể mất dữ liệu. |
| “FCI có hai node nghĩa là có hai bản sao database” | Các node FCI thường cùng sử dụng một bộ data/log trên shared storage. |
| “Secondary không cần license” | Quyền passive phụ thuộc SA/subscription và điều kiện Product Terms; secondary chạy workload chủ động cần được cấp phép phù hợp. |
| “Failover xong là ứng dụng tự chạy” | Ứng dụng cần connection retry, timeout hợp lý, listener/VNN đúng và kiểm thử end-to-end. |
Kết luận
Không có câu trả lời “AG luôn tốt hơn FCI” hoặc ngược lại. FCI giải quyết bài toán instance availability rất tự nhiên, đặc biệt khi doanh nghiệp có shared storage tốt và nhiều thành phần cấp instance. Availability Group mang lại database availability và disaster recovery linh hoạt hơn, có storage độc lập và khả năng tận dụng secondary, nhưng đòi hỏi quản trị nhiều lớp hơn.
Quyết định cuối cùng nên bắt đầu từ failure domain, RPO/RTO và phạm vi ứng dụng, sau đó mới chọn công nghệ. Cuối cùng, hãy kiểm tra edition và giấy phép trước khi chốt cấu hình, vì một secondary được thiết kế để đọc báo cáo hoặc backup có thể làm thay đổi đáng kể chi phí SQL Server.
Nguồn tham khảo
Lưu ý cập nhật: giới hạn tính năng và quyền cấp phép trong bài được đối chiếu vào tháng 6/2026. Hãy kiểm tra Product Terms, tài liệu edition và hợp đồng mua hàng hiện hành tại thời điểm triển khai.
