High Availability là gì? Cách xây dựng hệ thống có độ sẵn sàng cao

High Availability, thường viết tắt là HA, là khả năng một hệ thống tiếp tục cung cấp dịch vụ ngay cả khi một thành phần gặp sự cố. Thay vì để toàn bộ website hoặc ứng dụng phụ thuộc vào một máy chủ duy nhất, kiến trúc High Availability sử dụng nhiều lớp dự phòng, cơ chế health check và phương án chuyển tải để giảm thời gian gián đoạn.

Trong thực tế, một Cloud Server có thể hoạt động ổn định trong phần lớn thời gian nhưng vẫn tồn tại nhiều rủi ro: lỗi hệ điều hành, lỗi phần cứng, ứng dụng crash, database ngừng phản hồi, network gặp sự cố hoặc một đợt traffic lớn khiến máy chủ quá tải. Nếu toàn bộ hệ thống chỉ có một điểm xử lý duy nhất, một lỗi nhỏ cũng có thể khiến dịch vụ dừng hoàn toàn.

Bài viết này giải thích High Availability là gì, cách HA hoạt động, những thành phần thường xuất hiện trong kiến trúc HA, điểm khác nhau giữa HA với backup và Disaster Recovery, cùng các nguyên tắc cần lưu ý khi thiết kế hệ thống có độ sẵn sàng cao.

Tóm tắt: High Availability không có nghĩa hệ thống “không bao giờ lỗi”. Mục tiêu của HA là giảm khả năng một lỗi đơn lẻ làm toàn bộ dịch vụ dừng hoạt động, đồng thời rút ngắn thời gian gián đoạn khi sự cố xảy ra.

High Availability là gì?

High Availability là cách thiết kế hệ thống để dịch vụ duy trì khả năng hoạt động trong phần lớn thời gian, ngay cả khi một hoặc nhiều thành phần gặp lỗi.

Một hệ thống không có HA thường có dạng:

User
 |
 v
Cloud Server
 |
 |-- Web Server
 |-- Application
 `-- Database

Nếu Cloud Server này gặp sự cố:

User
 |
 v
X Cloud Server lỗi
 |
 v
Website ngừng hoạt động

Toàn bộ dịch vụ có thể bị gián đoạn.

Trong kiến trúc HA, các thành phần quan trọng được tách và có dự phòng:

User
 |
 v
Load Balancer
 |
 |-- App Server 1
 |-- App Server 2
 `-- App Server 3
       |
       v
Database HA

Nếu một application server lỗi, Load Balancer có thể ngừng gửi request tới node đó và chuyển traffic sang các node còn hoạt động.

Vì sao một máy chủ mạnh vẫn chưa phải High Availability?

Một máy chủ có nhiều CPU, RAM hoặc SSD vẫn chỉ là một máy chủ.

Ví dụ:

32 vCPU
128 GB RAM
NVMe SSD

có thể xử lý lượng tải rất lớn, nhưng nếu hệ điều hành gặp lỗi hoặc server bị mất kết nối mạng, toàn bộ ứng dụng vẫn có thể dừng.

Đây gọi là Single Point of Failure, hay điểm lỗi đơn.

User
 |
 v
Server duy nhất
 |
 X
 |
 v
Dịch vụ dừng

Tăng cấu hình chủ yếu giải quyết capacity.

High Availability giải quyết khả năng tiếp tục hoạt động khi có lỗi.

Single Point of Failure là gì?

Single Point of Failure, viết tắt là SPOF, là một thành phần mà nếu nó lỗi thì toàn bộ hệ thống hoặc một chức năng quan trọng sẽ dừng.

Các SPOF thường gặp:

• Một application server duy nhất.
• Một database duy nhất.
• Một Load Balancer duy nhất.
• Một đường mạng duy nhất.
• Một storage duy nhất.
• Một Redis instance duy nhất.
• Một message queue duy nhất.

Khi thiết kế HA, cần đặt câu hỏi:

Nếu thành phần này dừng,
dịch vụ còn hoạt động được không?

Nếu câu trả lời là “không”, thành phần đó có thể là SPOF.

High Availability hoạt động dựa trên những nguyên tắc nào?

Một kiến trúc HA thường dựa trên các nguyên tắc:

• Redundancy.
• Health Check.
• Failover.
• Distribution.

Redundancy

Redundancy là có nhiều hơn một thành phần thực hiện cùng vai trò.

Ví dụ:

App Server 1
App Server 2
App Server 3

Nếu một server lỗi, các server còn lại vẫn có thể phục vụ.

Health Check

Hệ thống cần biết node nào đang hoạt động.

Ví dụ:

GET /health

Response:

200 OK

Nếu một node không vượt qua health check, nó có thể bị loại khỏi pool.

Failover

Failover là quá trình chuyển traffic hoặc workload sang thành phần dự phòng khi thành phần chính gặp lỗi.

Distribution

Traffic không nên dồn vào một node duy nhất. Load Balancer thường chịu trách nhiệm phân phối request tới nhiều application server.

Load Balancer có vai trò gì trong HA?

Load Balancer là một trong những thành phần quan trọng nhất của kiến trúc High Availability ở tầng application.

             |-- App 1
User -> LB --|-- App 2
             `-- App 3

Load Balancer thực hiện:

• Phân phối traffic.
• Health check backend.
• Loại node lỗi.
• Đưa node mới vào hệ thống.
• Hỗ trợ scale out.

Nếu App 2 bị lỗi:

             |-- App 1  OK
User -> LB --|-- App 2  FAIL
             `-- App 3  OK

Load Balancer chỉ gửi request tới App 1 và App 3.

Tuy nhiên, bản thân Load Balancer cũng có thể trở thành SPOF nếu chỉ có một instance. Vì vậy, kiến trúc HA hoàn chỉnh cần xem xét cả độ sẵn sàng của lớp Load Balancer.

Application cần stateless để dễ triển khai HA

Một application stateless không phụ thuộc vào dữ liệu session được lưu riêng trên từng server.

Ví dụ không phù hợp:

App Server 1
|
`-- Session User A

Nếu request tiếp theo được chuyển sang App Server 2:

App Server 2
|
`-- Không có Session User A

người dùng có thể bị đăng xuất hoặc mất trạng thái.

Một kiến trúc tốt hơn:

             |-- App 1
Load Balancer|-- App 2
             `-- App 3
                  |
                  v
             Redis Session

Session được lưu ở một lớp chung.

Ngoài session, application nên tránh phụ thuộc vào file upload local, cache local duy nhất, temporary file chỉ tồn tại trên một node hoặc queue chỉ nằm trong memory của một server.

File upload cũng có thể phá vỡ HA

Giả sử hệ thống có hai application server.

Người dùng upload file vào App 1:

App 1
|
`-- uploads/avatar.jpg

Request tiếp theo được chuyển sang App 2 nhưng App 2 không có file đó.

Đây là lý do các hệ thống HA thường tách file khỏi application server.

Có thể sử dụng:

App 1 ----           -> Object Storage
App 2 ----/

Khi đó mọi node cùng truy cập một lớp storage chung.

Database là phần khó nhất của High Availability

Scale application thường đơn giản hơn scale database vì database chứa trạng thái và dữ liệu cần nhất quán.

Một mô hình đơn giản:

Application
    |
    v
Primary Database
    |
    v
Replica Database

Primary xử lý ghi.

Replica có thể phục vụ đọc, làm node dự phòng hoặc nhận replication từ primary.

Nếu primary lỗi, hệ thống có thể cần promote replica. Quá trình này được gọi là database failover.

Database replication không đồng nghĩa với backup

Replication sao chép thay đổi từ database chính sang replica.

Nếu người dùng vô tình chạy:

DELETE FROM orders;

lệnh xóa có thể được replicate sang replica.

Khi đó cả primary và replica đều mất dữ liệu đó.

Backup phục vụ mục tiêu khác:

Database hiện tại
      |
      v
Backup tại thời điểm trước

HA giúp giảm downtime.

Backup giúp khôi phục dữ liệu.

Một hệ thống production thường cần cả hai.

High Availability khác Backup thế nào?

Yếu tố	High Availability	Backup
Mục tiêu	Giảm gián đoạn	Khôi phục dữ liệu
Xử lý server lỗi	Có thể	Không trực tiếp
Xử lý xóa nhầm dữ liệu	Không chắc	Có
Hoạt động realtime	Thường có	Không
Dùng node dự phòng	Có	Không bắt buộc
Restore dữ liệu cũ	Không phải mục tiêu chính	Có

Ví dụ server database chết thì HA có thể chuyển sang replica. Nhưng nếu dữ liệu bị xóa nhầm từ hôm qua, cần backup.

High Availability khác Disaster Recovery thế nào?

High Availability tập trung vào việc giữ dịch vụ hoạt động khi có lỗi cục bộ.

Disaster Recovery, hay DR, tập trung vào khả năng phục hồi sau thảm họa lớn như:

• Cả data center gặp sự cố.
• Region mất kết nối.
• Ransomware.
• Dữ liệu bị phá hủy.
• Sai cấu hình ảnh hưởng diện rộng.

Một mô hình DR có thể là:

Primary Region
     |
     | replication / backup
     v
Secondary Region

HA thường xử lý failover nhanh trong một cụm. DR có thể yêu cầu chuyển cả hệ thống sang site hoặc region khác.

Availability thường được đo như thế nào?

Availability thường được biểu diễn theo tỷ lệ thời gian hệ thống hoạt động.

Availability
=
Uptime
/
Tổng thời gian

Các mức thường được nhắc tới:

99%
99.9%
99.99%
99.999%

Mỗi chữ số 9 bổ sung làm yêu cầu kiến trúc và vận hành khó hơn đáng kể.

Không nên chỉ đặt mục tiêu availability thật cao nếu business không cần vì chi phí và độ phức tạp cũng tăng theo.

RTO và RPO liên quan gì tới HA?

RTO là Recovery Time Objective.

Nó trả lời:

Sau sự cố,
mất tối đa bao lâu để dịch vụ hoạt động lại?

Ví dụ:

RTO = 5 phút

RPO là Recovery Point Objective.

Nó trả lời:

Có thể chấp nhận mất tối đa bao nhiêu dữ liệu?

Ví dụ:

RPO = 15 phút

Nếu hệ thống yêu cầu RPO gần bằng 0, kiến trúc replication và dữ liệu cần được thiết kế chặt chẽ hơn.

Health Check cần kiểm tra gì?

Một health check quá đơn giản có thể báo server “sống” dù application đã không hoạt động đúng.

Ví dụ TCP port 80 vẫn mở không đảm bảo database vẫn truy cập được.

Có thể chia:

Liveness

Kiểm tra process có còn sống không.

GET /health/live

Readiness

Kiểm tra node có sẵn sàng nhận traffic không.

GET /health/ready

Readiness có thể kiểm tra database connection, cache, dependency quan trọng hoặc trạng thái khởi động.

Nếu node chưa ready, Load Balancer không nên gửi traffic tới nó.

Failover tự động có luôn tốt hơn không?

Không phải lúc nào cũng vậy.

Failover tự động có ưu điểm là phản ứng nhanh, giảm thao tác thủ công và rút ngắn downtime.

Nhưng failover sai có thể gây:

• Split brain.
• Hai database cùng nhận ghi.
• Data inconsistency.
• Traffic chuyển sang node chưa sẵn sàng.

Vì vậy, cơ chế failover cần được kiểm thử thực tế.

Không nên chỉ cấu hình và giả định nó sẽ hoạt động khi có sự cố thật.

High Availability cho website WordPress

Một WordPress đơn giản thường là:

User
 |
 v
Web Server
 |
 v
WordPress
 |
 v
MySQL

Để tăng HA có thể phát triển thành:

User
 |
 v
CDN
 |
 v
Load Balancer
 |
 |-- WordPress 1
 |-- WordPress 2
 `-- WordPress 3
        |
        |-- Redis
        |-- Object Storage
        `-- Database HA

Cần lưu ý:

• Upload không lưu local.
• Session không phụ thuộc một node.
• Plugin hoạt động ổn định khi chạy multi-node.
• Cronjob không chạy trùng trên mọi server.
• Cache được thiết kế phù hợp.

CDN có phải là High Availability không?

CDN có thể là một phần của kiến trúc HA nhưng không thay thế toàn bộ HA.

CDN có thể hỗ trợ cache nội dung, giảm tải origin, hạn chế một phần traffic spike và trong một số cấu hình có thể tiếp tục phục vụ bản cache khi origin gặp vấn đề.

Nhưng nếu application hoặc database phía sau dừng, request động vẫn có thể lỗi.

Kiến trúc đầy đủ hơn:

User
 |
 v
CDN
 |
 v
Load Balancer
 |
 |-- App 1
 `-- App 2
       |
       v
Database HA

Mỗi lớp giải quyết một loại rủi ro khác nhau.

Monitoring là bắt buộc trong hệ thống HA

HA không có monitoring thì rất khó phát hiện node dự phòng đã lỗi từ trước.

Ví dụ:

App 1: OK
App 2: FAIL

Website vẫn hoạt động nhờ App 1.

Nếu không có cảnh báo, đội ngũ có thể không biết App 2 đã lỗi.

Sau đó App 1 gặp sự cố:

App 1: FAIL
App 2: FAIL

Toàn bộ hệ thống dừng.

Do đó cần theo dõi:

• Node health.
• CPU.
• RAM.
• Disk.
• Network.
• Error rate.
• P95/P99.
• Database replication.
• Queue.
• Load Balancer backend status.

Capacity dự phòng phải đủ khi một node lỗi

Một lỗi thiết kế phổ biến là có nhiều node nhưng tất cả đều chạy gần 100% tải.

Ví dụ:

App 1: 85%
App 2: 85%
App 3: 85%

Nếu App 3 lỗi, traffic chuyển sang App 1 và App 2.

Hai node còn lại có thể quá tải ngay.

HA cần tính tới tình huống mất node.

Một cách tiếp cận là mô hình N+1:

N node cần cho tải bình thường
+
1 node dự phòng

Hoặc thiết kế để các node còn lại vẫn đủ capacity khi một node bị mất.

Deploy cũng cần High Availability

Không chỉ hardware failure mới gây downtime.

Deployment sai cũng có thể khiến toàn bộ hệ thống ngừng hoạt động.

Các chiến lược thường dùng:

• Rolling Deployment.
• Blue-Green Deployment.
• Canary Deployment.

Ví dụ rolling:

App 1 -> update
App 2 -> vẫn phục vụ
App 3 -> vẫn phục vụ

Sau khi App 1 ready mới tiếp tục update App 2.

Cách này giúp tránh dừng toàn bộ service cùng lúc.

Những lỗi thiết kế HA thường gặp

Có nhiều app server nhưng chỉ một database

Application có HA nhưng database vẫn là SPOF.

Có replica nhưng chưa từng test failover

Khi primary thật sự lỗi, replica không promote được hoặc application không kết nối sang node mới.

Lưu file local

Load Balancer phân phối request nhưng mỗi node giữ dữ liệu riêng.

Health check quá đơn giản

Node trả HTTP 200 nhưng application bên trong đã lỗi.

Không đủ capacity dự phòng

Một node lỗi kéo theo các node khác quá tải.

Không giám sát replica

Replica đã ngừng đồng bộ nhiều ngày nhưng không ai biết.

Backup nằm cùng hệ thống

Server chính lỗi có thể làm mất luôn backup.

Không có runbook

Khi sự cố xảy ra, đội ngũ không biết ai quyết định failover và thực hiện theo thứ tự nào.

Khi nào doanh nghiệp nên triển khai High Availability?

Không phải mọi website đều cần một kiến trúc HA phức tạp.

HA nên được ưu tiên hơn khi:

• Website tạo doanh thu trực tiếp.
• Hệ thống thanh toán.
• Ecommerce.
• API phục vụ khách hàng.
• SaaS.
• Hệ thống nội bộ quan trọng.
• Traffic lớn.
• Downtime gây thiệt hại đáng kể.
• Có SLA với khách hàng.

Một website giới thiệu có traffic thấp có thể chấp nhận thời gian phục hồi dài hơn.

Trong khi hệ thống đặt vé hoặc thanh toán có thể cần failover nhanh.

Mức HA phải phù hợp với mức độ quan trọng của dịch vụ.

Checklist thiết kế High Availability

Application

• Có ít nhất hai application instance nếu yêu cầu HA.
• Application có thể chạy stateless.
• Session không chỉ lưu local.
• File upload dùng storage chung.
• Có health check.
• Có restart policy.
• Có deployment không downtime nếu cần.

Load Balancer

• Có health check backend.
• Loại node lỗi tự động.
• Timeout được cấu hình phù hợp.
• Bản thân Load Balancer không trở thành SPOF.

Database

• Có replication nếu cần.
• Có monitoring replication lag.
• Có cơ chế failover.
• Đã test failover.
• Có backup độc lập.
• Đã thử restore.

Storage

• Không phụ thuộc disk local của một app server.
• Dữ liệu quan trọng có redundancy.
• Có backup.
• Có lifecycle phù hợp.
• Có kiểm tra restore.

Monitoring

• Có alert node down.
• Có alert CPU/RAM/Disk.
• Có alert error rate.
• Có alert database.
• Có dashboard.
• Có log tập trung.

Vận hành

• Có runbook.
• Có người chịu trách nhiệm xử lý.
• Có lịch test failover.
• Có postmortem sau sự cố.
• Có capacity dự phòng.
• Có kế hoạch DR nếu business yêu cầu.

Kết luận

High Availability là cách thiết kế hệ thống để giảm khả năng một lỗi đơn lẻ làm toàn bộ dịch vụ ngừng hoạt động. Thay vì phụ thuộc vào một server duy nhất, HA sử dụng redundancy, health check, Load Balancer, replication và failover để duy trì dịch vụ khi có sự cố.

Một kiến trúc HA thường không chỉ là:

Thêm một server

mà là:

Loại bỏ SPOF
+
Phân phối traffic
+
Dự phòng dữ liệu
+
Health Check
+
Failover
+
Monitoring

Application có thể có nhiều node nhưng database vẫn là SPOF. Database có replica nhưng không có backup vẫn có thể mất dữ liệu. Có failover nhưng không test thì chưa thể đảm bảo hệ thống sẽ phục hồi đúng khi sự cố thật xảy ra.

Vì vậy, High Availability cần được xem là một bài toán kiến trúc và vận hành tổng thể, không phải chỉ là bài toán mua thêm tài nguyên.

Khi thiết kế, nên bắt đầu từ yêu cầu business: downtime tối đa có thể chấp nhận, RTO, RPO và mức độ ảnh hưởng nếu một thành phần dừng hoạt động. Từ đó mới quyết định cần bao nhiêu node, Load Balancer, database replication, storage, monitoring và phương án failover.