VPS hay Dedicated: Khi nào là lúc nghĩ đến Hybrid Cloud cho hệ thống?

Mấy bữa nay hệ thống game của mình cứ "giật giật"

Mấy bữa nay mình cứ lăn tăn cái vụ hệ thống game cứ "lag nhẹ" vào giờ cao điểm. Lúc đầu tưởng VPS của mình yếu quá, nhưng ngó qua top với free -m thì thấy tài nguyên vẫn còn kha khá. Không lẽ lại do mạng? Mà mạng thì đâu phải chuyện dễ xử lý.

Hồi trước, cứ nghĩ đến mở rộng hạ tầng là mình chỉ loanh quanh mỗi chuyện: nên dùng VPS hay Dedicated Server. Nhưng càng làm, càng thấy có những bài toán không thể giải quyết triệt để bằng một mình "con" VPS hay "con" Dedicated được. Đây là lúc mình bắt đầu nghĩ đến cái tên nghe hơi "sang chảnh" nhưng lại rất thực dụng: Hybrid Cloud.

Vậy Hybrid Cloud là gì?

Nói đơn giản nhất, nó là cách mình kết hợp giữa cái "của riêng" (ví dụ như một dedicated server mình thuê, hoặc một cụm VPS riêng tư mà mình kiểm soát chặt) với cái "của chung" (tức là public cloud, mấy dịch vụ như AWS S3, Cloudflare, hoặc các dịch vụ đám mây khác). Hai bên được nối với nhau qua VPN hay đường truyền riêng bảo mật.

Mình sẽ rải ứng dụng và dữ liệu ra sao cho tối ưu nhất, dựa vào độ trễ, yêu cầu tuân thủ, với quan trọng nhất là chi phí mình phải bỏ ra.

Thường thì, mấy cái ứng dụng hoặc dữ liệu mà mình cần kiểm soát tuyệt đối về bảo mật hay hiệu năng ổn định, không chia sẻ với ai, mình sẽ giữ trên dedicated server hoặc colocation rack. Còn mấy cái "đông vui" hơn, kiểu như web frontend, mấy tác vụ xử lý hàng loạt mà không quá quan trọng về dữ liệu nhạy cảm hay đòi hỏi tài nguyên cực kỳ ổn định, có thể "đẩy" lên public cloud để tận dụng khả năng co giãn.

Khi nào mình nên nghĩ đến Hybrid Cloud?

Mình thấy câu hỏi này nhiều bạn hỏi lắm. Thực ra không có câu trả lời "đúng" hay "sai" tuyệt đối đâu. Quan trọng là mình đang gặp vấn đề gì, và mình muốn giải quyết nó như thế nào.

Cứ nghĩ mình có một workload "khó tính" đòi hỏi hiệu năng ổn định, không chia sẻ với ai. Ví dụ như cái database chính của game, hoặc mấy cái hệ thống cần tuân thủ bảo mật cực cao. Mấy thứ này thì mình thích giữ trên dedicated server hoặc colocation rack. Nhưng mà, mấy cái "đông vui" hơn, kiểu web frontend hay mấy tác vụ xử lý hàng loạt mà không quá quan trọng về dữ liệu nhạy cảm, có thể chạy ở public cloud.

Nói thật: nhiều khi mình thấy mọi người cứ cố gắng dồn hết lên cloud vì nghe "hiện đại", nhưng quên mất rằng có những thứ "cổ điển" lại hiệu quả hơn nhiều. Đặc biệt khi tài nguyên cần là ổn định, đoán được.

Ví dụ, những tác vụ có thể đoán trước được mức tải thì cứ dedicated resource mà triển khai. Còn mấy lúc cao điểm, cần "burst capacity" đột ngột thì lúc đó public cloud lại là cứu tinh. Mình thấy có ông lớn Gartner dự đoán là đến năm 2027, khoảng 90% tổ chức sẽ áp dụng mô hình hybrid cloud. Điều đó cho thấy nó không còn là một lựa chọn "phụ" nữa rồi.

Vài điểm khác biệt cơ bản giữa Cloud VPS và Dedicated Server:

• Tách biệt tài nguyên: Cloud VPS là chia sẻ tài nguyên trên một host vật lý, còn Dedicated Server là cả cái máy đó là của mình.
• Khả năng co giãn: Cloud VPS co giãn dễ dàng theo nhu cầu, còn Dedicated Server thì bị giới hạn bởi phần cứng.
• Chi phí: Cloud VPS có thể là biến đổi hoặc cố định hàng tháng, còn Dedicated Server thường là cố định.

Tóm lại, nếu mình cần hiệu năng "đỉnh của chóp" và độ ổn định cao cho những tác vụ như database với I/O cực kỳ quan trọng, xử lý dữ liệu lớn với độ trễ thấp, hoặc cần phần cứng đặc biệt, thì Dedicated Server vẫn là chân ái. Nhưng để linh hoạt và tối ưu chi phí cho các phần còn lại, Hybrid Cloud là một nước đi chiến lược.

Mấy cái bẫy mình hay dính (và cách mình đã từng vượt qua)

Làm vận hành, ai mà chả từng dính vài "cú lừa" của hạ tầng. Không ai nói trước được đâu.

VPS tự nhiên chậm như rùa bò? Coi chừng CPU Overcommitment!

Có khi nào mình dùng VPS, tự nhiên thấy nó ì ạch, tải trang chậm rì, Time To First Byte nhảy lung tung? Hỏi nhà cung cấp thì họ bảo "tài nguyên đầy đủ", nhưng cảm giác cứ sai sai. Mình từng dính chưởng này rồi.

Đây là lúc mình cần để ý đến cái gọi là CPU Overcommitment. Các nhà cung cấp, để tối ưu hóa tài nguyên vật lý, thường bán ra nhiều vCPU hơn số core vật lý họ có. Điều này dẫn đến cái gọi là "thời gian chờ CPU" (CPU Ready Time) hoặc "thời gian bị đánh cắp" (Steal Time) tăng cao. Nghĩa là, CPU ảo của mình phải xếp hàng chờ CPU vật lý. Mình có thể thấy điều này bằng cách quan sát chỉ số st (steal time) trong lệnh top hoặc vmstat:

%Cpu(s):  0.2 us,  0.1 sy,  0.0 ni, 97.4 id,  0.1 wa,  2.2 hi,  0.0 si,  2.2 st

Nhìn cái st (steal time) ấy. Nếu nó mà cao, là mình đang bị thằng hypervisor nó "ăn cắp" thời gian CPU của mình đó. Mình từng đọc một bài của webhosting.de, họ chỉ ra rằng nếu Steal Time cứ nhảy nhót trên 5% trong thời gian dài, thì gần như chắc chắn mình đang bị overcommitment CPU. Hồi đó mình có đọc được ở đâu đó là Red Hat khuyến nghị tỉ lệ khá là bảo thủ với vCPU, và máy ảo nhỏ với ít vCPU thì sẽ ít bị hơn. Cách fix thì có khi phải "right-sizing" lại VM, hoặc chuyển sang gói có CPU riêng biệt hơn. Nói chung, không bao giờ có chuyện "CPU 100% của mình" trên VPS đâu, họ phải chia sẻ chứ. Không tuyệt đối hoàn hảo được.

Mạng chập chờn, load balancer "nhảy dù" không lý do?

Đôi khi không phải CPU hay RAM mà là mạng. Mình từng đọc một case khá hay trên blog codecentric.de. Họ có hai load balancer chạy trên OpenStack, tự nhiên cứ "nhảy dù" địa chỉ IP loạn xạ. Nghi là do IO cao làm rớt mấy gói tin keepalive VRRP.

Hóa ra không phải IO ổ đĩa, mà là do cái driver mạng ảo. Cụ thể hơn, cái cấu hình OpenStack đang dùng driver mạng ảo vhost_net, mà thằng này lại bị disable mặc định cho qemu-kvm. Mình có thể tưởng tượng đây là một cái nút gạt nhỏ xíu mà quyết định cả hệ thống. Cái fix của họ chỉ là đổi VHOST_NET_ENABLED=0 thành VHOST_NET_ENABLED=1 trong cấu hình của Ubuntu trên tất cả các node tính toán. Một byte thôi, nhưng thay đổi cả cục diện. Sau khi khởi động lại các máy ảo, vấn đề nhảy dù biến mất. Cái này chỉ admin lâu năm, chịu khó mò vào tầng cơ chế ảo hóa mới thấy được:

# /etc/default/qemu-kvm
VHOST_NET_ENABLED=1

Các bạn dùng VPS không thể trực tiếp cấu hình được chỗ này, nhưng biết để mà "bắt bệnh" nhà cung cấp. Nếu họ cũng dùng KVM/OpenStack mà gặp vấn đề tương tự, có khi mình đã tìm ra được manh mối rồi đó.

So sánh hiệu năng kiểu gì cho chuẩn?

Mình còn nhớ có một bạn trên forum netcup.de từng kể một chuyện khá thú vị. Bạn ấy chạy server Minecraft, thấy trên Root Server (server vật lý riêng) lại chậm hơn hẳn so với VPS.

Cụ thể, thời gian khởi động của Root Server là 47-70 giây, TPS (ticks per second) chỉ khoảng 9-10. Trong khi đó, trên VPS thì khởi động chỉ mất khoảng 12 giây, TPS ổn định ở mức 20. Khác biệt một trời một vực! Để tìm ra nguyên nhân, bạn ấy được gợi ý dùng yabs (Yet Another Bench Script) để đo hiệu năng. Kết quả Geekbench 6 Single Core cho thấy VPS đạt 1104 điểm, còn Root Server chỉ có 477. Rõ ràng là thấp hơn nhiều so với kỳ vọng 1000-1100 điểm cho con Root Server đó. Thế là bạn ấy có cái để mà gửi hỗ trợ kỹ thuật.

Mình nghĩ đây là ví dụ hay cho thấy không phải cứ "dedicated" là auto mạnh hơn đâu. Quan trọng là cấu hình, tối ưu, và đôi khi là "số nhọ" nữa. Chạy benchmark thực tế là cách tốt nhất để mình có số liệu rõ ràng, không chỉ cảm tính.

Khi mình cần "dịch chuyển" hệ thống (Migration)

Việc di chuyển một hệ thống đang chạy từ VPS sang dedicated, hoặc từ đâu đó vào Hybrid Cloud, không phải chuyện một sớm một chiều. Mình luôn phải có một kế hoạch rõ ràng để tránh "mất ăn mất ngủ".

Mục tiêu tối thượng của mình luôn là "zero-downtime", hay ít nhất là downtime thấp nhất có thể. Mình từng đọc về một case study trên thecloudstandard.com của một công ty SaaS làm analytics B2B. Họ phải di chuyển từ cụm VPS sang hạ tầng dedicated vì database cứ chậm, khách hàng dọa bỏ đi hết. Đây là một bài học đắt giá về việc không đánh giá đúng nhu cầu ban đầu.

Họ đã làm thế nào? Họ dựng một dedicated server mới với PostgreSQL 14, cấu hình y hệt cái database cũ. Sau đó, họ triển khai PostgreSQL logical replication để đồng bộ dữ liệu từ database cũ sang database mới mà không cần dừng dịch vụ. Xong xuôi thì dần dần chuyển traffic sang server mới bằng cách điều chỉnh trọng số trên load balancer. Kết quả là vừa giải quyết được vấn đề database, vừa tiết kiệm được 400-600 USD/tháng.

# Một ví dụ đơn giản cho việc cấu hình logical replication trên PostgreSQL
# Trên DB nguồn (old_db_host)
CREATE PUBLICATION my_publication FOR ALL TABLES;

# Trên DB đích (new_db_host)
CREATE SUBSCRIPTION my_subscription CONNECTION 'host=old_db_host dbname=old_db user=repl_user password=repl_pass' PUBLICATION my_publication;

Với các ứng dụng container hóa, việc di chuyển có vẻ dễ thở hơn một chút, chỉ cần redeploy lại image và cập nhật cấu hình orchestration. Còn máy ảo thì có thể dùng snapshot, copy file qua mạng, hoặc các công cụ đồng bộ hóa tăng dần. Cái nào cũng cần mình kiểm tra thật kỹ và có một kế hoạch rollback dự phòng.

Chốt lại thì...

Quay lại cái vụ hệ thống game của mình bị lag nhẹ kia. Sau một hồi phân tích kỹ, mình nhận ra cái database game của mình bắt đầu quá tải, đặc biệt là mấy cái thao tác I/O. VPS hiện tại không đáp ứng nổi sự "nhảy nhót" của I/O vào giờ cao điểm, nó cứ bị "thời gian chờ" quá nhiều.

Thay vì cố gắng nhồi nhét lên một con VPS mạnh hơn (rồi có khi lại dính overcommitment CPU), mình quyết định tách cái database đó ra một dedicated server riêng. Phần game server và web frontend vẫn giữ trên cụm VPS hoặc chuyển sang public cloud như Cloudflare để dễ dàng scale-out khi cần, hay AWS S3 cho lưu trữ file. Đây chính là Hybrid Cloud trong thực tế vận hành.

Kết quả là hệ thống ổn định hẳn, không còn cảnh người chơi phàn nàn "lag quá admin ơi" nữa. Và quan trọng là mình vẫn giữ được chi phí ở mức hợp lý, không phải chi quá nhiều cho một con dedicated server full options trong khi không phải tất cả các thành phần đều cần. Một mũi tên trúng mấy đích.

Hybrid Cloud không phải là một giải pháp thần kỳ cho tất cả, nhưng nó là một hướng đi rất đáng để mình cân nhắc khi hệ thống bắt đầu có những "cơn đau đầu" mà một mình VPS hay dedicated không thể giải quyết triệt để. Đừng phức tạp hóa quá, cứ bắt đầu từ cái mình đang có và thêm vào những gì mình thật sự cần thôi.