Checklist chuyển đổi từ Single-VPS sang cụm Multi-Server

Chuyển đổi một website đang hoạt động với lượng người dùng thực tế từ mô hình máy chủ đơn lẻ (Single-VPS) sang cụm nhiều máy chủ (Multi-Server) là một mốc quan trọng trong vòng đời phát triển hệ thống. Bạn có thể đã nắm vững lộ trình kiến trúc tổng thể, hoàn tất việc tách Database sang VPS riêng qua Private VPC, thiết lập bộ cân bằng tải Nginx, chuyển đổi lưu trữ tệp phi trạng thái sang S3/R2 và chuẩn bị quy trình phát hành không gián đoạn Zero-Downtime.

Tuy nhiên, tại thời điểm cắt chuyển dữ liệu thực tế (cutover), rủi ro lớn nhất thường xuất phát từ việc thiếu sót trong quy trình kiểm soát thay vì giới hạn công nghệ.

Những sơ suất tưởng chừng nhỏ như quên hạ thời gian sống (TTL) của bản ghi DNS khiến người dùng bị phân mảnh truy cập giữa máy chủ cũ và máy chủ mới, bỏ sót một biến môi trường trỏ cứng về 127.0.0.1, hay ước tính sai thời gian sao chép dữ liệu đều có thể kéo dài thời gian bảo trì ngoài kế hoạch và làm gián đoạn trải nghiệm người dùng.

Danh mục kiểm tra an toàn dưới đây gồm 4 giai đoạn, giúp bạn rà soát các mắt xích kỹ thuật trước, trong và sau thời điểm cắt chuyển, đi kèm 4 tiêu chí định lượng để kích hoạt phương án rollback kịp thời khi phát sinh sự cố.

Nguyên tắc cốt lõi trong quy trình cắt chuyển

Trước khi đánh dấu hoàn thành các hạng mục, đội ngũ vận hành cần thống nhất ba nguyên tắc làm việc sau:

1. Xác minh dựa trên kết quả lệnh: Tránh đánh giá trạng thái dịch vụ theo cảm tính hoặc phỏng đoán. Mọi hạng mục đều cần được kiểm chứng bằng câu lệnh cụ thể với đầu ra rõ ràng trên terminal.
2. Diễn tập đo lường thời gian (dry-run): Quá trình sao lưu cơ sở dữ liệu và đồng bộ thư mục tệp tải lên cần được chạy thử nghiệm trước 24 giờ để đo đạc chính xác thời gian hoàn thành trong điều kiện thực tế.
3. Thống nhất tiêu chí rollback trước thời điểm thực hiện: Người phụ trách kỹ thuật và quản trị viên cần thống nhất sẵn ngưỡng kích hoạt phương án hủy bỏ để quay về máy chủ cũ, giúp xử lý dứt khoát khi thời gian bảo trì vượt quá giới hạn an toàn.

Giai đoạn 1: Chuẩn bị hạ tầng và rà soát mã nguồn

Giai đoạn này diễn ra trước 48 – 72 giờ khi website vẫn đang phục vụ người dùng bình thường trên máy chủ cũ, nhằm rà soát và xử lý trước các rào cản kỹ thuật.

Giai đoạn 2: Diễn tập thử nghiệm và đồng bộ tệp nền

Thực hiện trước 2 – 24 giờ nhằm rút ngắn tối đa thời gian gián đoạn dịch vụ trong thời điểm cắt chuyển chính thức.

Giai đoạn 3: Cắt chuyển trong cửa sổ bảo trì (T-0)

Khung giờ thực thi nên rơi vào thời điểm có lượng truy cập thấp nhất trong tuần, thường từ 1:00 AM đến 3:00 AM.

Bạn nên thực hiện tuần tự quy trình 7 bước dưới đây để kiểm soát rủi ro và tránh nhầm lẫn:

[ Bước 1: Khóa quyền ghi (HTTP 503) ]
                  │
                  ▼
[ Bước 2: Trích xuất bản snapshot DB cuối cùng ]
                  │
                  ▼
[ Bước 3: Truyền nén và nạp vào máy chủ DB mới ]
                  │
                  ▼
[ Bước 4: Chạy đồng bộ tệp delta (tệp phát sinh trong 24h) ]
                  │
                  ▼
[ Bước 5: Cập nhật cấu hình .env trên các web node ]
                  │
                  ▼
[ Bước 6: Kiểm thử luồng người dùng (smoke test) ]
                  │
                  ▼
[ Bước 7: Mở lại website và trỏ DNS chính thức ]

Các thao tác thực thi giờ G

Bước 1: Kích hoạt chế độ bảo trì

Tạm khóa quyền ghi của người dùng và cấu hình web server trả về mã trạng thái HTTP 503 để giữ tính toàn vẹn dữ liệu:

# Đối với Laravel
php artisan down --render="errors::503" --secret="BaoTriNoiBoPasscode123"

# Đối với WordPress (qua Nginx)
# Kích hoạt tệp cấu hình trả về trang bảo trì 503 tĩnh

Bước 2 & 3: Trích xuất và nạp dữ liệu vào cơ sở dữ liệu mới

Sử dụng đường ống nén dữ liệu trực tiếp qua SSH trên card mạng nội bộ để tăng tốc độ truyền và không tốn dung lượng lưu trữ tệp .sql trung gian:

mysqldump -u root -p --single-transaction --quick --routines --triggers --hex-blob production_db \
| gzip -c \
| ssh 10.0.0.20 "gunzip -c | mysql -u root -p production_db"

Xác nhận lại số lượng bản ghi (row count) trên các bảng quan trọng để đối chiếu dữ liệu:

SELECT table_name, table_rows 
FROM information_schema.tables 
WHERE table_schema = 'production_db' 
AND table_name IN ('users', 'orders', 'posts', 'transactions');

Bước 4: Đồng bộ phần tệp tải lên mới phát sinh (Delta Sync)

Do phần lớn tệp tĩnh đã được đồng bộ ở Giai đoạn 2, lệnh đồng bộ delta lúc này chỉ cần quét và chuyển các tệp mới tạo trong vòng 24 giờ qua:

rclone sync /var/www/html/uploads remote-r2:bucket/uploads --transfers 16 -P

Thao tác này thường chỉ mất khoảng 30 đến 60 giây.

Bước 5: Cập nhật tệp cấu hình môi trường .env

Trên từng web node mới, mở tệp .env và trỏ các kết nối sang hạ tầng mới:

DB_CONNECTION=mysql
DB_HOST=10.0.0.20
DB_PORT=3306
DB_DATABASE=production_db
DB_USERNAME=app_prod
DB_PASSWORD=MatKhauBaoMatRanDomSieuManh123!

REDIS_HOST=10.0.0.30
REDIS_PORT=6379

FILESYSTEM_DISK=s3
AWS_ENDPOINT=https://your-account-id.r2.cloudflarestorage.com
AWS_BUCKET=my-media-bucket
AWS_URL=https://media.example.com

Bước 6: Kiểm thử luồng nghiệp vụ chính (Smoke Test)

Sử dụng trình duyệt hoặc công cụ nội bộ truy cập qua đường dẫn bypass bảo trì để kiểm tra 5 tác vụ cốt lõi:

1. Đăng nhập tài khoản người dùng thành công.
2. Tải lên một hình ảnh mới (xác nhận ảnh hiển thị qua CDN và lưu vào S3/R2).
3. Đọc dữ liệu trang chủ và trang chi tiết sản phẩm.
4. Thử nghiệm tạo một đơn hàng mới (ghi nhận thành công vào cơ sở dữ liệu mới).
5. Kiểm tra log hệ thống: tail -n 50 /var/log/nginx/error.log và log ứng dụng để bảo đảm không xuất hiện exception.

Bước 7: Mở lại website và cập nhật bản ghi DNS chính thức

Tắt chế độ bảo trì và chuyển bản ghi A của tên miền chính trên Cloudflare sang địa chỉ IP public của Nginx Load Balancer (203.0.113.10). Do bạn đã hạ TTL xuống 120s từ trước, lưu lượng truy cập của người dùng sẽ chuyển dần sang cụm Multi-Server mới trong khoảng 2 đến 3 phút.

Giai đoạn 4: Nghiệm thu và theo dõi sau chuyển đổi

Trong 48 giờ đầu sau khi chuyển đổi, hệ thống bước vào giai đoạn nhạy cảm nhất. Bạn cần duy trì theo dõi liên tục các thông số vận hành sau:

• Giám sát kết nối cơ sở dữ liệu:

  mysqladmin -h 10.0.0.20 -u app_prod -p status

Quan sát hai chỉ số Threads_connected và Threads_running. Nếu Threads_running liên tục vượt quá 30, cơ sở dữ liệu có thể đang bị nghẽn do truy vấn chậm.

• Theo dõi nhật ký truy vấn chậm (Slow Query Log) trên máy chủ DB để phát hiện các câu lệnh SQL phát sinh độ trễ cao khi chạy qua mạng nội bộ.
• Theo dõi tỷ lệ lỗi HTTP 5xx trên Nginx Load Balancer:

  awk '($9 ~ /50[0-9]/)' /var/log/nginx/access.log | wc -l

Tỷ lệ này cần duy trì dưới 0.05% tổng lưu lượng truy cập.

• Đo lường thời gian phản hồi trang (TTFB): Sử dụng các công cụ giám sát bên ngoài (như Uptime Kuma hoặc Grafana) để theo dõi, bảo đảm mức TTFB trung bình không tăng quá 15% so với máy chủ cũ.

Tiêu chí kích hoạt phương án rollback

Việc xác định rõ thời điểm dừng lại và rút lui an toàn giúp hạn chế tối đa rủi ro gián đoạn dịch vụ. Khi gặp bất kỳ điều kiện nào trong bảng dưới đây, người vận hành nên chủ động kích hoạt phương án rollback:

Quy trình rollback nhanh

1. Chuyển lại bản ghi A trên Cloudflare DNS trỏ ngược về IP public của máy chủ Single-VPS cũ.
2. Trên máy chủ cũ, sửa lại tệp .env trỏ về DB_HOST=127.0.0.1 và tắt chế độ bảo trì (php artisan up).
3. Khởi động lại ứng dụng web trên máy chủ cũ.

Dữ liệu trên máy chủ cũ vẫn được giữ nguyên từ thời điểm bắt đầu bảo trì, do đó website sẽ hoạt động bình thường trở lại ngay lập tức. Đội ngũ kỹ thuật sẽ có đủ thời gian phân tích nguyên nhân lỗi trên hạ tầng mới mà không gây ảnh hưởng kéo dài đến người dùng.

Sau khi hoàn tất danh mục kiểm tra này và vận hành ổn định cụm Multi-Server, hạ tầng của bạn đã chính thức bước sang mô hình phân tán. Hãy tiếp tục chuẩn bị cho giai đoạn tiếp theo của Phase 3: xây dựng chu trình phát hành phần mềm tự động qua pipeline CI/CD tự host và thiết lập cơ chế sao lưu bất biến để bảo vệ an toàn tài sản số của hệ thống.