Chuyển nhà từ DigitalOcean sang Hetzner: Giảm chi phí từ $1,432 xuống $233 với Zero Downtime

Chuyển nhà từ DigitalOcean sang Hetzner: Giảm chi phí từ $1,432 xuống $233 với Zero Downtime

Trong bối cảnh lạm phát tăng cao và tỷ giá hối đoái biến động mạnh, việc vận hành một công ty phần mềm tại Thổ Nhĩ Kỳ đang trở nên ngày càng đắt đỏ. Chi phí hạ tầng tính bằng USD đã trở thành gánh nặng tài chính lớn, buộc một đội ngũ kỹ thuật phải tìm kiếm giải pháp thay thế tối ưu hơn.

Đó là lý do họ quyết định thực hiện cuộc "di cư" lớn từ DigitalOcean sang Hetzner dedicated server. Kết quả thật ấn tượng: chi phí hàng tháng giảm từ 1.432 USD xuống còn chỉ 233 USD, tương đương việc tiết kiệm được 14.388 USD mỗi năm, đồng thời sở hữu một cấu hình máy chủ mạnh mẽ hơn gấp bội.

So sánh cấu hình và chi phí giữa DigitalOcean và Hetzner

Tại sao lại chọn Hetzner?

Trước đây, đội ngũ này trả 1.432 USD/tháng cho DigitalOcean cho một droplet có cấu hình 32 vCPU, 192GB RAM và 600GB SSD. Mặc dù dịch vụ của DigitalOcean rất ổn định và trải nghiệm nhà phát triển tuyệt vời, nhưng tỷ lệ giá trên hiệu suất (price-to-performance) không còn hợp lý khi so sánh với các giải pháp dedicated server.

Họ chuyển sang sử dụng Hetzner AX162-R với thông số kỹ thuật vượt trội hơn hẳn:

• CPU: AMD EPYC 9454P (48 nhân / 96 luồng) so với 32 vCPU cũ.
• RAM: 256 GB DDR5 so với 192 GB cũ.
• Ổ cứng: 1.92 TB NVMe Gen4 RAID1 so với SSD + Block volumes cũ.
• Chi phí: Chỉ 233 USD/tháng.

Đây không chỉ là việc tiết kiệm tiền mà còn là cơ hội để nâng cấp hệ điều hành từ CentOS 7 (đã hết hạn hỗ trợ) lên AlmaLinux 9.7.

Thách thức: Di chuyển khối lượng dữ liệu khổng lồ

Hệ thống cần di chuyển không phải là một dự án chơi bời. Nó bao gồm:

• 30 cơ sở dữ liệu MySQL với tổng dung lượng 248 GB.
• 34 virtual host Nginx trên nhiều tên miền khác nhau.
• GitLab EE, Neo4J Graph DB, và hàng chục background worker.
• Các ứng dụng di động trực tuyến phục vụ hàng trăm nghìn người dùng.

Yêu cầu đặt ra là Zero Downtime (thời gian chết bằng 0). Phương pháp thay đổi DNS và hy vọng may mắn ("change DNS, restart everything, hope for the best") hoàn toàn không được chấp nhận.

Chiến lược 6 giai đoạn để Zero Downtime

Để đạt được mục tiêu, quy trình được chia thành 6 giai đoạn chính:

1. Cài đặt đầy đủ stack trên server mới

Mọi dịch vụ từ Nginx, PHP, MySQL 8.0, Neo4J, GitLab EE đều được cài đặt và cấu hình để hoạt động giống hệt server cũ. Các chứng chỉ SSL cũng được đồng bộ từ server cũ sang mới.

2. Đồng bộ file web với rsync

Toàn bộ thư mục /var/www/html (khoảng 65 GB, 1,5 triệu file) được clone sang server mới bằng rsync. Một lệnh đồng bộ tăng thêm (incremental sync) được chạy ngay trước thời điểm chuyển đổi để bắt lấy các thay đổi cuối cùng.

3. Replication MySQL từ Master đến Slave

Đây là phần quan trọng nhất. Thay vì dump dữ liệu và gây gián đoạn, họ thiết lập replication thời gian thực. Server cũ đóng vai trò Master, server mới là Slave (chỉ đọc).

Công cụ mydumper được sử dụng thay vì mysqldump truyền thống. Nhờ tận dụng 48 nhân CPU của server mới, quá trình export và import song song giúp rút ngắn thời gian từ vài ngày xuống còn vài giờ.

mydumper \
--threads 32 \
--compress \
--trx-consistency-only \
--skip-definer \
--chunk-filesize 256 \
-v 3 \
--outputdir /root/mydumper_backup/

4. Giảm TTL DNS

Họ sử dụng script để giảm TTL (Time To Live) của các bản ghi DNS từ 3600 giây xuống còn 300 giây. Điều này đảm bảo rằng khi thay đổi DNS, toàn bộ thế giới sẽ cập nhật nhanh chóng trong vòng 5 phút.

5. Chuyển đổi Nginx cũ thành Reverse Proxy

Đây là một mẹo hay. Trước khi chuyển DNS, Nginx trên server cũ được cấu hình lại thành một reverse proxy chuyển tiếp yêu cầu sang server mới.

Sơ đồ cấu hình Reverse Proxy và DNS

Nhờ đó, trong thời gian DNS lan truyền, bất kỳ yêu cầu nào vẫn truy cập vào IP cũ đều được âm thầm chuyển sang server mới mà người dùng không hề hay biết.

6. Chuyển đổi DNS và ngắt kết nối

Khi mọi thứ đã sẵn sàng, một script Python sẽ cập nhật tất cả bản ghi DNS trên DigitalOcean để trỏ về IP mới của Hetzner. Server cũ được giữ lại một tuần như một phương án dự phòng (cold standby) trước khi bị tắt hoàn toàn.

Các vấn đề kỹ thuật phát sinh

Quá trình di chuyển không tránh khỏi những rắc rối nhỏ. Một trong số đó là vấn đề quyền SUPER trong MySQL 8.0. Khi server mới được đặt ở chế độ read_only = 1 để ngăn chặn ghi dữ liệu, các ứng dụng vẫn có thể ghi nhờ quyền SUPER.

Giải pháp là thu hồi quyền này khỏi tất cả người dùng ứng dụng:

REVOKE SUPER ON *.* FROM 'some_db_user'@'localhost';

Ngoài ra, việc nâng cấp từ MySQL 5.7 lên 8.0 cũng gặp lỗi với schema sys, nhưng đã được khắc phục bằng cách xóa và chạy lại lệnh nâng cấp.

Kết quả và Bài học kinh nghiệm

Sau khoảng 24 giờ thực hiện, cuộc di cư hoàn thành thành công tuyệt đối.

• Chi phí: Giảm từ 1.432 USD xuống 233 USD/tháng.
• Hiệu năng: Tăng vọt nhờ CPU AMD EPYC và RAM DDR5.
• Downtime: 0 phút. Không người dùng nào bị ảnh hưởng.

Kết quả sau khi di chuyển sang hạ tầng mới

Dưới đây là những bài học rút ra cho các sysadmin:

1. MySQL replication là bạn tốt nhất: Đừng ngần ngại thiết lập master-slave replication cho các lần di chuyển lớn. Nó mang lại sự an tâm tuyệt đối.
2. Kiểm tra quyền hạn người dùng: Đừng để quyền SUPER phá hỏng cấu hình read_only của bạn.
3. Tự động hóa mọi thứ: Viết script cho việc cập nhật DNS, cấu hình Nginx. Làm thủ công với 34+ trang web chỉ là mời gọi lỗi lầm.
4. Dùng mydumper/myloader: Với cơ sở dữ liệu lớn, công cụ này vượt trội hoàn toàn so với mysqldump truyền thống nhờ khả năng đa luồng.

Cuối cùng, nếu bạn đang chạy các workload ổn định (steady-state) và không cần tính năng autoscaling của cloud, hãy xem xét kỹ các giải pháp dedicated server. Bạn có thể tiết kiệm được một khoản tiền khổng lồ mà vẫn có được hiệu năng phần cứng vượt trội.