Máy chủ dự phòng là gì? Cách hoạt động và kinh nghiệm triển khai thực tế

Máy chủ dự phòng là gì?

Máy chủ dự phòng (redundant/standby server) là máy chủ được chuẩn bị để duy trì hoặc khôi phục dịch vụ khi máy chủ chính gặp sự cố, tùy theo kiến trúc triển khai.

Hiểu đơn giản, nếu hệ thống chỉ có:

User → Server A

thì khi Server A hỏng, dịch vụ có thể dừng hoàn toàn.

Khi có máy chủ dự phòng:

User → Server A (Primary)
↓ Failover
Server B (Standby/Secondary)

Server B có thể tiếp quản workload khi Server A không còn khả năng phục vụ.

Mục tiêu quan trọng nhất của máy chủ dự phòng không đơn thuần là “có thêm một server”, mà là giảm downtime và hạn chế mất dữ liệu khi hệ thống gặp sự cố.

Tuy nhiên, để đạt được mục tiêu đó, doanh nghiệp phải thiết kế đồng thời compute, storage, network, dữ liệu và cơ chế failover. Chỉ mua thêm một máy chủ giống máy chính chưa tạo thành một hệ thống High Availability đúng nghĩa.

Máy chủ dự phòng là gì

Tại sao doanh nghiệp cần máy chủ dự phòng?

Một server vật lý dù cấu hình cao đến đâu vẫn có khả năng gặp sự cố.

Các tình huống tôi thường tính đến khi thiết kế hệ thống gồm:

• CPU hoặc mainboard lỗi;
• RAM lỗi;
• HDD/SSD/NVMe hỏng;
• RAID Controller lỗi;
• PSU lỗi;
• NIC lỗi;
• hệ điều hành gặp sự cố;
• database corruption;
• lỗi application;
• mất kết nối mạng;
• mất điện;
• lỗi cấu hình;
• ransomware;
• lỗi thao tác của administrator.

Nếu toàn bộ dịch vụ doanh nghiệp chỉ phụ thuộc vào một server, server đó trở thành Single Point of Failure – SPOF.

Ví dụ:

Internet → Firewall → Server

Nếu server ngừng hoạt động, toàn bộ ứng dụng phía sau có thể dừng theo.

Với website thương mại điện tử, ERP, CRM, database hoặc hệ thống phục vụ khách hàng 24/7, downtime vài giờ có thể gây thiệt hại đáng kể.

Máy chủ dự phòng hoạt động như thế nào?

Không có một cơ chế duy nhất cho mọi server dự phòng.

Kiến trúc phổ biến thường bao gồm:

Primary Server → Replication/Synchronization → Secondary Server

Một hệ thống monitoring hoặc cluster manager liên tục kiểm tra trạng thái của máy chủ chính.

Nếu phát hiện lỗi, hệ thống có thể thực hiện:

Failover

tức chuyển workload sang server dự phòng.

Khi server chính được khôi phục, workload có thể được chuyển trở lại thông qua quá trình:

Failback

Tùy kiến trúc, failover có thể được thực hiện tự động hoặc thủ công.

Active-Passive là gì?

Active-Passive là một trong những kiến trúc dự phòng dễ hiểu nhất.

Mô hình:

Server A – Active
Server B – Passive/Standby

Server A xử lý workload bình thường.

Server B được duy trì ở trạng thái sẵn sàng và có thể nhận dữ liệu đồng bộ từ Server A.

Nếu Server A gặp sự cố:

Server A ✕ → Failover → Server B ✓

Server B trở thành server phục vụ chính.

Ưu điểm của Active-Passive

Kiến trúc tương đối đơn giản.

Dễ kiểm soát dữ liệu hơn một số kiến trúc phân tán phức tạp.

Phù hợp với nhiều database và ứng dụng doanh nghiệp.

Nhược điểm của Active-Passive

Server dự phòng có thể không được khai thác hết tài nguyên trong trạng thái bình thường.

Ngoài ra, thời gian failover vẫn tồn tại.

Nếu failover không được tự động hóa, administrator còn phải can thiệp thủ công.

Active-Active là gì?

Với Active-Active, nhiều server cùng hoạt động và cùng phục vụ workload.

Ví dụ:

User
↓
Load Balancer
↓
Server A + Server B

Traffic được phân phối giữa nhiều server.

Nếu Server A gặp lỗi, Load Balancer có thể ngừng gửi request tới Server A và tiếp tục sử dụng Server B.

Ưu điểm của Active-Active

Tận dụng được tài nguyên của nhiều server.

Có khả năng scale-out.

Giảm phụ thuộc vào một server.

Phù hợp với website, API và nhiều ứng dụng có kiến trúc stateless.

Nhược điểm của Active-Active

Kiến trúc phức tạp hơn.

Đặc biệt, bài toán khó thường không nằm ở web server mà nằm ở:

Database + Session + Storage + Data Consistency

Nếu hai application server cùng truy cập một database duy nhất:

Server A + Server B → Database X

thì Database X vẫn có thể là Single Point of Failure.

Do đó, việc có hai application server chưa đồng nghĩa toàn hệ thống đã High Availability.

Máy chủ dự phòng khác Backup Server như thế nào?

Đây là một trong những khái niệm tôi thấy người dùng nhầm nhiều nhất.

Máy chủ dự phòng và máy chủ backup không giống nhau.

Máy chủ dự phòng chủ yếu nhằm:

duy trì dịch vụ

Trong khi backup server chủ yếu nhằm:

khôi phục dữ liệu.

Ví dụ:

Server A → Server B replication

Nếu Server A lỗi, Server B tiếp quản dịch vụ.

Đó là redundancy/failover.

Trong khi:

Server A → Backup → NAS/Backup Server

Nếu dữ liệu bị xóa, administrator restore từ backup.

Đó là backup.

Hai cơ chế giải quyết hai loại rủi ro khác nhau.

Replication có thay thế Backup không?

Không.

Đây là nguyên tắc tôi đặc biệt lưu ý khi triển khai hệ thống.

Giả sử Server A replication dữ liệu realtime sang Server B.

Nếu một file trên Server A bị xóa và thao tác đó được replication sang Server B:

Delete A → Replicate → Delete B

lúc này cả hai server đều mất file.

Tương tự với ransomware.

Nếu dữ liệu bị mã hóa và thay đổi đó được đồng bộ sang hệ thống secondary, bản sao cũng có thể bị ảnh hưởng.

Vì vậy:

Replication ≠ Backup

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

HA/Replication → giảm downtime

Backup → phục hồi dữ liệu

High Availability là gì?

High Availability – HA là kiến trúc nhằm duy trì khả năng cung cấp dịch vụ với downtime thấp khi một hoặc nhiều thành phần gặp sự cố trong phạm vi thiết kế.

Một kiến trúc HA có thể gồm:

2+ Compute Nodes

Redundant Network

Redundant Storage

Cluster

Health Check

Automatic Failover

Điều quan trọng là phải loại bỏ SPOF ở nhiều lớp.

Ví dụ doanh nghiệp có:

Server A + Server B

nhưng cả hai đều kết nối tới:

Switch X

Nếu Switch X hỏng, cả hai server mất network.

Như vậy hệ thống vẫn có SPOF.

Thiết kế tốt hơn có thể sử dụng:

Server A/B → Switch A + Switch B

Tương tự với:

• power;
• storage;
• firewall;
• load balancer;
• Internet uplink.

Failover là gì?

Failover là quá trình chuyển dịch vụ từ thành phần đang gặp sự cố sang thành phần dự phòng.

Ví dụ:

Primary Database ✕

↓ Failover

Secondary Database ✓

Failover có thể là:

Manual Failover – administrator thực hiện.

hoặc:

Automatic Failover – cluster tự động phát hiện và chuyển đổi.

Automatic Failover giúp giảm downtime nhưng phải được thiết kế rất cẩn thận.

Một trong những vấn đề cần tránh là split-brain, khi hai node đều cho rằng mình là primary và cùng thực hiện thao tác ghi, gây nguy cơ xung đột hoặc mất nhất quán dữ liệu.

Do đó, các cluster nghiêm túc thường cần quorum, witness hoặc cơ chế consensus/fencing phù hợp.

Máy chủ dự phòng khác Disaster Recovery như thế nào?

HA và Disaster Recovery – DR có liên quan nhưng không giống nhau.

HA thường xử lý sự cố trong phạm vi hạ tầng production.

Ví dụ:

Server A lỗi → Server B tiếp quản

DR hướng tới các sự cố lớn hơn:

• toàn Data Center mất điện;
• cháy;
• thiên tai;
• mất kết nối kéo dài;
• ransomware diện rộng;
• sự cố khiến toàn bộ site production không hoạt động.

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

Primary Data Center – Hà Nội

↓

DR Site – địa điểm khác

Nếu toàn bộ Primary Site gặp sự cố, hệ thống có thể được phục hồi tại DR Site.

RPO và RTO – Hai chỉ số phải xác định trước khi thiết kế server dự phòng

Khi khách hàng nói:

“Tôi muốn có server dự phòng.”

Câu hỏi đầu tiên của tôi không phải là:

“Anh cần server Dell hay HPE?”

Mà là:

RPO bao nhiêu? RTO bao nhiêu?

RPO – Recovery Point Objective

RPO xác định lượng dữ liệu tối đa doanh nghiệp chấp nhận mất, được biểu diễn theo thời gian.

Ví dụ:

RPO = 1 giờ

có nghĩa doanh nghiệp thiết kế hệ thống với mục tiêu không mất quá khoảng một giờ dữ liệu trong kịch bản được xác định.

RPO càng thấp, yêu cầu replication và backup càng cao.

RTO – Recovery Time Objective

RTO xác định thời gian mục tiêu để khôi phục dịch vụ sau sự cố.

Ví dụ:

RTO = 4 giờ

có nghĩa hệ thống cần được thiết kế để mục tiêu phục hồi dịch vụ nằm trong khoảng thời gian đó đối với kịch bản đã xác định.

Nếu doanh nghiệp yêu cầu:

RTO vài phút

thì backup đơn thuần thường không đủ.

Lúc này cần xem xét HA, replication và automatic failover.

Các mô hình máy chủ dự phòng thường gặp

Tùy mức độ quan trọng của workload, có thể xây dựng nhiều cấp độ.

Mô hình 1: Server chính + Backup

Server A
↓
Backup NAS/Storage

Chi phí thấp nhưng thời gian phục hồi tương đối lâu.

Phù hợp với workload không yêu cầu HA.

Mô hình 2: Primary + Standby Server

Server A
↓ Replication
Server B

Khi A lỗi, B được kích hoạt.

Đây là mô hình Active-Passive.

Mô hình 3: HA Cluster

Node A + Node B + Shared/Distributed Storage

Cluster manager quản lý workload và failover.

Nếu một node lỗi, workload có thể được restart hoặc chuyển sang node còn lại tùy nền tảng.

Mô hình 4: Active-Active

Load Balancer
↓
Server A + Server B + Server C

Nhiều server cùng phục vụ request.

Phù hợp với các hệ thống có khả năng scale ngang.

Mô hình 5: Primary Site + DR Site

Data Center A
↓ Replication
Data Center B

Đây là kiến trúc phù hợp hơn với các hệ thống có yêu cầu Business Continuity cao.

Có hai server giống nhau đã được gọi là HA chưa?

Chưa.

Đây là lỗi tư duy khá phổ biến.

Doanh nghiệp mua:

2 × Dell PowerEdge

và nghĩ rằng đã có HA.

Nhưng nếu server thứ hai không:

• nhận dữ liệu đồng bộ;
• có application tương ứng;
• có cơ chế health check;
• có failover;
• được kiểm tra định kỳ;

thì nó chỉ là spare server, chưa phải một hệ thống HA hoàn chỉnh.

HA là kiến trúc, không phải số lượng server.

Những sai lầm thường gặp khi xây dựng máy chủ dự phòng

Chỉ dự phòng server nhưng không dự phòng storage

Ví dụ:

Server A + Server B → Storage X

Storage X hỏng thì cả hai server đều mất dữ liệu.

Storage trở thành SPOF.

Không dự phòng network

Hai server kết nối vào cùng một switch.

Switch hỏng → cả hai server offline.

Không dự phòng nguồn điện

Hai server dùng chung một UPS hoặc một power feed duy nhất.

Power system lỗi → cả hai server tắt.

Có replication nhưng không có backup

Như đã phân tích:

Replication không phải Backup.

Doanh nghiệp vẫn cần backup độc lập.

Không kiểm thử failover

Đây là lỗi tôi đánh giá rất nguy hiểm.

Một hệ thống dự phòng chưa từng failover test thì chưa thể chắc chắn rằng nó sẽ hoạt động đúng khi sự cố thật xảy ra.

Nên thực hiện định kỳ:

Failover Test → Restore Test → DR Drill

và ghi nhận thời gian thực tế để so sánh với RTO/RPO mục tiêu.

Kinh nghiệm thiết kế máy chủ dự phòng thực tế

Khi thiết kế hệ thống, tôi thường không bắt đầu từ hardware.

Thứ tự hợp lý hơn là:

Business Impact

↓

Workload

↓

RPO/RTO

↓

HA/DR Architecture

↓

Compute + Storage + Network

↓

Backup

↓

Hardware

Ví dụ, nếu doanh nghiệp chạy một ERP nội bộ và chấp nhận downtime 4 giờ, việc xây dựng một Active-Active cluster cực kỳ phức tạp có thể không cần thiết.

Ngược lại, nếu hệ thống xử lý giao dịch 24/7 và downtime chỉ được tính bằng phút, một server dự phòng tắt sẵn trong kho gần như không giải quyết được yêu cầu.

Kiến trúc dự phòng phải được quyết định bởi yêu cầu kinh doanh, không phải bởi số lượng server doanh nghiệp đang sở hữu.

Máy chủ dự phòng cần cấu hình giống máy chủ chính không?

Không bắt buộc trong mọi trường hợp.

Điều quan trọng là server dự phòng phải đủ tài nguyên để xử lý workload khi failover.

Ví dụ server chính có:

32 Core + 256 GB RAM

nhưng bình thường chỉ sử dụng:

12 Core + 80 GB RAM

thì về lý thuyết secondary không nhất thiết phải giống hoàn toàn server chính nếu kiến trúc, phần mềm, licensing và workload cho phép.

Tuy nhiên, sử dụng hardware đồng nhất thường giúp đơn giản hóa:

• compatibility;
• driver;
• performance;
• maintenance;
• spare parts;
• capacity planning.

Đối với cluster virtualization, tính tương thích CPU và nền tảng cũng cần được xem xét kỹ.

Máy chủ dự phòng có cần Backup không?

Có.

Máy chủ dự phòng giúp duy trì Availability.

Backup giúp bảo vệ Data Recoverability.

Hai mục tiêu khác nhau.

Một kiến trúc tốt có thể là:

Primary Server
↕
Secondary Server / HA Cluster
↓
Backup Storage
↓
Offsite/Cloud Backup

Như vậy doanh nghiệp có nhiều lớp bảo vệ:

Hardware Failure → HA

Data Loss → Backup

Site Failure → Offsite/DR

Câu hỏi thường gặp về máy chủ dự phòng

Máy chủ dự phòng có tự động chạy khi server chính hỏng không?

Có thể, nếu hệ thống được thiết kế với automatic failover. Nếu chỉ có một standby server đơn giản, quá trình chuyển đổi có thể cần administrator thực hiện thủ công.

Có máy chủ dự phòng rồi có cần Backup không?

Có. Server dự phòng không thay thế backup.

Hai server chạy song song có phải Active-Active không?

Chỉ khi cả hai thực sự cùng xử lý workload. Hai server cùng bật nhưng một server chỉ chờ failover thường là Active-Passive.

NAS có phải máy chủ dự phòng không?

Không nhất thiết. NAS thường cung cấp storage. Nó có thể là một thành phần của hệ thống backup hoặc HA nhưng không tự động trở thành server dự phòng.

Doanh nghiệp nhỏ có cần máy chủ dự phòng không?

Điều này phụ thuộc vào mức độ quan trọng của dịch vụ và chi phí downtime. Nếu doanh nghiệp có thể chấp nhận vài giờ phục hồi, backup tốt có thể kinh tế hơn HA phức tạp. Nếu downtime gây gián đoạn hoạt động nghiêm trọng, cần xem xét server dự phòng hoặc HA.

Kết luận

Máy chủ dự phòng là một thành phần được chuẩn bị để duy trì hoặc khôi phục dịch vụ khi máy chủ chính gặp sự cố. Tuy nhiên, một hệ thống dự phòng đúng nghĩa không đơn giản là mua thêm một server.

Cần xem xét toàn bộ:

Server + Storage + Network + Power + Replication + Failover + Backup + DR

Đặc biệt, cần phân biệt rõ:

HA/Failover → giảm downtime

Backup → khôi phục dữ liệu

Disaster Recovery → phục hồi sau sự cố quy mô site/hệ thống

Từ kinh nghiệm thiết kế hạ tầng, hai thông số nên được xác định trước khi lựa chọn server là:

RPO – doanh nghiệp chấp nhận mất bao nhiêu dữ liệu?

RTO – doanh nghiệp chấp nhận hệ thống dừng bao lâu?

Khi hai câu hỏi này có câu trả lời rõ ràng, việc lựa chọn Active-Passive, Active-Active, HA Cluster, Backup hay DR Site sẽ chính xác hơn rất nhiều.

Nếu doanh nghiệp cần tư vấn máy chủ dự phòng, Server Cluster, High Availability, Backup, Disaster Recovery, thuê máy chủ hoặc thuê chỗ đặt máy chủ, có thể liên hệ VDO – Hotline 1900 0366 để được tư vấn kiến trúc và cấu hình dựa trên workload, RPO/RTO và yêu cầu vận hành thực tế.

Từ khóa liên quan: máy chủ dự phòng, server dự phòng, backup server, failover server, High Availability, HA Server, Disaster Recovery, Active-Active, Active-Passive, server cluster, RPO, RTO.