Xây dựng Kiến trúc High Availability (HA) cho Headless CMS Strapi với Cụm 3 VPS Hetzner và HAProxy

Đặt vấn đề: Thách thức về tính sẵn sàng cao của Headless CMS trong doanh nghiệp

Trong kỷ nguyên số hóa, Headless CMS đã trở thành xu hướng kiến trúc hiện đại nhờ khả năng tách biệt hoàn toàn giữa backend quản trị nội dung và frontend hiển thị. Trong số đó, Strapi nổi lên như một nền tảng mã nguồn mở mạnh mẽ, linh hoạt và được nhiều doanh nghiệp tin dùng. Tuy nhiên, khi lưu lượng truy cập tăng cao hoặc xảy ra sự cố phần cứng, một thực thể Strapi chạy đơn lẻ (Single Instance) sẽ trở thành điểm nghẽn nghiêm trọng (Single Point of Failure - SPOF).

Để đảm bảo hệ thống nội dung luôn hoạt động liên tục 24/7, việc xây dựng một kiến trúc High Availability (HA - Tính sẵn sàng cao) là yêu cầu bắt buộc. Bài viết này sẽ hướng dẫn bạn từng bước thiết kế và cấu hình hệ thống Strapi HA hoàn chỉnh trên cụm 3 VPS của nhà cung cấp Hetzner, kết hợp với bộ cân bằng tải mạnh mẽ HAProxy.

1. Mô hình tổng quan kiến trúc Strapi High Availability

Để đạt được tiêu chuẩn HA, chúng ta cần phân rã hệ thống thành các tầng độc lập và có khả năng dự phòng lẫn nhau. Với ngân sách tối ưu và hiệu năng vượt trội từ VPS Hetzner, mô hình cụm 3 Node (Node 1, Node 2, Node 3) là lựa chọn lý tưởng nhất để thiết lập cơ chế đồng thuận (Quorum).

Sơ đồ phân bổ tài nguyên trên 3 Node VPS Hetzner:

Tầng Cân bằng tải (Load Balancing Layer): Sử dụng HAProxy và Keepalived (tùy chọn Virtual IP) cài đặt trên các node để điều phối lưu lượng và kiểm tra trạng thái (Health Check) của các ứng dụng Strapi.
Tầng Ứng dụng (Application Layer): Cả 3 Node đều chạy thực thể Strapi độc lập, kết nối chung vào tầng dữ liệu và lưu trữ tập trung.
Tầng Cơ sở dữ liệu (Database Layer): Sử dụng MariaDB Galera Cluster hoặc PostgreSQL với repmgr trải đều trên 3 node để đảm bảo dữ liệu được đồng bộ đồng thời (Synchronous Replication).
Tầng Lưu trữ tệp tin (Storage Layer): Do Strapi sinh ra các tệp tin media (images, videos), chúng ta không thể lưu cục bộ trên từng VPS. Giải pháp tối ưu là sử dụng Hetzner Volumes kết hợp hệ thống tệp tin chia sẻ (NFS/GlusterFS) hoặc chuyển hướng hoàn toàn sang S3-Compatible Storage (như Amazon S3 hoặc MinIO).

2. Các bước triển khai chi tiết hệ thống

Bước 1: Cấu hình Tầng Cơ sở dữ liệu đồng bộ (Database Cluster)

Đầu tiên, chúng ta cần thiết lập một cluster database mạnh mẽ. MariaDB Galera Cluster là lựa chọn tuyệt vời cho mô hình 3 node của Hetzner vì nó cho phép ghi dữ liệu ở bất kỳ node nào và tự động đồng bộ sang các node còn lại.

# Cấu hình cơ bản cho Galera trong file /etc/mysql/my.cnf tại Node 1
[galera]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://IP_NODE_1,IP_NODE_2,IP_NODE_3"
wsrep_cluster_name="strapi_db_cluster"
wsrep_node_address="IP_NODE_1"
wsrep_node_name="node1"
wsrep_sst_method=rsync

Sau khi khởi tạo cluster từ Node 1, các Node 2 và Node 3 sẽ join vào để tạo thành một khối thống nhất. Lúc này, bất kỳ thay đổi dữ liệu nào từ Strapi cũng sẽ được đảm bảo an toàn tuyệt đối.Bước 2: Triển khai ứng dụng Strapi và cấu hình Hệ thống tệp tin

Để Strapi hoạt động mượt mà trong môi trường Cluster, bạn cần lưu ý hai yếu tố cốt lõi: Media Storage và Session/Plugin State.

Khuyến nghị từ chuyên gia: Thay vì cố gắng đồng bộ thư mục public/uploads bằng rsync hoặc lsyncd (vốn dễ gây trễ và xung đột), hãy sử dụng plugin @strapi/provider-upload-aws-s3 để đẩy toàn bộ media asset lên các dịch vụ lưu trữ đám mây. Điều này giúp các node Strapi hoàn toàn không lưu trạng thái (Stateless), cực kỳ dễ dàng cho việc mở rộng hoặc thay thế node.

Tiếp theo, tiến hành cài đặt Strapi trên cả 3 Node, cấu hình file .env trỏ về IP nội bộ của Database Cluster và sử dụng PM2 để quản lý quy trình, đảm bảo ứng dụng tự động khởi động lại khi có sự cố.

Bước 3: Cấu hình Bộ cân bằng tải HAProxy

HAProxy đóng vai trò là "người gác cổng", tiếp nhận mọi yêu cầu từ người dùng và phân phối đều cho 3 node Strapi phía sau dựa trên thuật toán Round Robin hoặc Least Connections.

Cấu hình file /etc/haproxy/haproxy.cfg như sau:

frontend strapi_frontend
    bind *:80
    bind *:443 ssl crt /etc/ssl/certs/strapi.pem
    mode http
    default_backend strapi_backend

backend strapi_backend
    mode http
    balance roundrobin
    option httpchk GET /_health
    http-check expect status 200
    cookie SERVERID insert indirect nocache
    server strapi_node1 IP_NODE_1:1337 check cookie node1
    server strapi_node2 IP_NODE_2:1337 check cookie node2
    server strapi_node3 IP_NODE_3:1337 check cookie node3

Trong cấu hình trên, tính năng cookie SERVERID cực kỳ quan trọng đối với trang quản trị Strapi Admin Dashboard, giúp cố định phiên làm việc của người dùng (Sticky Sessions) trên một node cụ thể, tránh hiện tượng mất session khi đang cấu hình nội dung.

3. Kiểm tra khả năng chịu lỗi và Tối ưu hóa hiệu năng (Uptime Testing)

Sau khi hoàn tất cấu hình, hệ thống cần được kiểm thử nghiêm ngặt trước khi đưa vào vận hành thực tế:

Thử nghiệm tắt Node ứng dụng: Chủ động stop dịch vụ Strapi trên Node 1. Hệ thống HAProxy phải ngay lập tức phát hiện thông qua cơ chế httpchk và chuyển hướng 100% traffic sang Node 2 và Node 3 mà người dùng không hề nhận ra sự gián đoạn.
Thử nghiệm phân rã Database: Giả lập tắt Node 3 của MariaDB. Cluster phải duy trì hoạt động bình thường nhờ cơ chế Quorum (2/3 node vẫn sống).

Bên cạnh đó, để tối ưu hiệu năng cho hạ tầng Hetzner, hãy tận dụng mạng nội bộ Hetzner vSwitch (Private Network) để các Node giao tiếp với nhau. Điều này vừa giúp tăng tốc độ truyền tải dữ liệu, vừa bảo mật tuyệt đối vì các traffic nội bộ không bị lộ ra môi trường Internet public.

Lời kết

Xây dựng kiến trúc High Availability cho Strapi trên cụm 3 VPS Hetzner kết hợp HAProxy không chỉ giúp doanh nghiệp loại bỏ hoàn toàn rủi ro sập hệ thống, mà còn tạo ra nền tảng vững chắc để sẵn sàng scale up khi lượng truy cập tăng vọt. Mặc dù chi phí và công sức triển khai ban đầu cao hơn so với mô hình Single Instance, nhưng giá trị về sự ổn định và an toàn dữ liệu mà nó mang lại cho doanh nghiệp là hoàn toàn vô giá.