Sống sót trên một VM 2GB: readiness, blue/green tính RAM gấp đôi và swap bạn phải tự thêm

Sống sót trên một VM 2GB: readiness, blue/green tính RAM gấp đôi và swap bạn phải tự thêm

Chạy production trên một VM đơn lẻ làm nhiều builder ngại, và nỗi lo khá cụ thể: app hỏng lúc deploy, traffic vẫn bị đẩy vào container chưa sẵn sàng, hoặc máy hết RAM đến mức SSH không trả lời nữa.

Trang tài liệu reliability của 2server không hứa giải quyết hết. Nó nói rõ 2server cung cấp gì (restart process, định tuyến theo sức khỏe, deploy có chốt chặn, phục hồi dữ liệu cục bộ) và không cung cấp gì (HA ở mức host). Bài này đọc lại bốn điểm trong đó áp dụng cho VM nhỏ, và tách điều 2server làm hộ khỏi điều bạn phải tự làm.

---

1. Readiness: Caddy chỉ giữ instance đã sẵn sàng nhận request

Với một web app, bạn khai báo một đường dẫn readiness (trong ví dụ của tài liệu là "healthPath": "/readyz"). Tài liệu mô tả đường đó phải trả 2xx khi instance nhận được request, nên rẻ và không ghi dữ liệu nghiệp vụ. Redirect không được tính là phản hồi readiness.

Với worker nền không nhận HTTP thì yêu cầu khác: image phải có HEALTHCHECK. Và các route proxy trực tiếp có sẵn từ trước không có đường health tự suy ra, nên đừng giả định Caddy tự đoán giúp bạn.

Khi readiness hỏng lúc đang chạy, app bị gỡ khỏi Caddy và bắn cảnh báo readiness HTTP. Ở khâu deploy, tài liệu chỉ ghi một câu: mọi candidate đều phải qua readiness. Nó không mô tả chi tiết điều gì xảy ra với bản mới khi readiness không đạt, nên bài này cũng không đoán.

---

2. Caddy cách ly upstream sau hai lần check lỗi

Con số cụ thể trong tài liệu: Caddy kiểm tra mỗi năm giây, cách ly (quarantine) sau hai lần active check thất bại, và cần hai lần thành công để được đưa trở lại. Lỗi kết nối cũng bị cách ly mười giây. Caddy thử chọn lại kết nối tối đa ba giây; sau khi đã kết nối được, chỉ request GET/HEAD mới được thử lại.

Điều đáng nhớ cho VM một replica: tài liệu ghi thẳng "a single replica has restart downtime". Nếu chỉ có một replica thì cách ly không có bản thứ hai để đỡ. Docker restart process đã thoát theo chính sách unless-stopped, nhưng một trạng thái unhealthy đơn thuần không tự kích hoạt restart.

---

3. Blue/green: hai thế hệ cùng nằm trong một VM

Trong lúc deploy blue/green, VM phải chứa cả hai thế hệ. Công thức trong tài liệu: replicas × memoryMb × 2, cộng tất cả extension, Caddy, kernel và phần dự phòng. Tài liệu viết thẳng: một VM 2GB có thể không đủ chỗ cho mọi app với hai replica cùng các extension.

Hai chi tiết dễ hiểu sai:

• Giới hạn CPU/bộ nhớ của container chỉ cô lập process, không đặt trước dung lượng vật lý. Đặt giới hạn xong không có nghĩa RAM đã được giữ chỗ.
• Bản cũ được drain trong drainSeconds sau khi Caddy chuyển sang bản mới. Request dài và websocket cần tự có cách reconnect hoặc resume. Worker thì ngược lại: dừng thế hệ cũ trước, nên job cần queue bền, đồng thời có giới hạn và giao lại được an toàn.

Nói cách khác, việc tính RAM là của bạn, trước khi bấm deploy.

---

4. Swap 1–2GB: 2server không tạo giúp

Đây là chỗ dễ nhầm nhất, nên viết nguyên ý tài liệu: 2server không tạo swap. Bạn tự thêm một swap file 1–2GB. Lý do tài liệu nêu: nếu không có swap, một VM hết bộ nhớ có thể ngừng trả lời SSH thay vì để kernel kill một container.

Tài liệu cũng đưa một số đo từ một VM thật của chính họ: máy 8GB RAM chạy với 2GB swap và dùng khoảng 3,1GB. Đó là ví dụ về cách định cỡ, không phải cam kết cho VM của bạn.

---

Giới hạn rõ ràng: không có HA ở mức host

Tài liệu nói thẳng: 2server không cung cấp HA ở mức host. Mất VM, mất disk hay mất mạng thì edge, database và monitoring cùng sập. Chạy Sentinel hay một quorum NATS trên chính VM đó cũng không gỡ được failure domain này; không có VM phụ, quorum hay cơ chế tự nâng database nào được dựng sẵn.

Hệ quả thực tế nhất nằm ở phần monitoring: Prometheus và Alertmanager chạy trên cùng VM nên không thể gửi cảnh báo khi cả VM sập. Tài liệu yêu cầu cấu hình một external uptime check (kèm chính sách cảnh báo và kênh thông báo) cho trường hợp đó. Cảnh báo ra ngoài cũng cần một receiver được bật trong cấu hình webhook của monitoring; không có receiver thì chỉ có cảnh báo cục bộ.

---

Tóm lại

Nếu bạn định chạy sản phẩm của mình trên một VM, hãy đọc bảng này như danh sách việc cần làm trước khi deploy lần đầu, thay vì học từng mục lúc hai giờ sáng.

Tài liệu đầy đủ: 2server › Reliability