Phần lớn các lần chuyển website gặp sự cố ở cùng vài chỗ: DNS mất cả ngày mới cập nhật, database bị sao chép trong lúc vẫn đang có đơn hàng mới ghi vào, hoặc một file cấu hình vẫn trỏ về máy chủ cũ. Bài này là quy trình cụ thể để chuyển website sang VPS mới mà khách truy cập chỉ bị gián đoạn vài phút. Ví dụ dùng stack Linux phổ biến (Nginx hoặc Apache, PHP hoặc Node.js, MySQL/MariaDB hoặc PostgreSQL), nhưng thứ tự các bước áp dụng được cho hầu hết website, từ WordPress đến shop tự viết.
Toàn cảnh kế hoạch chuyển website sang VPS mới
| Thời điểm | Việc cần làm | Trạng thái website |
|---|---|---|
| 1 đến 2 ngày trước | Hạ TTL DNS, dựng máy chủ mới | Máy cũ vẫn chạy |
| Ngày hôm trước | rsync file lần đầu, thử import database | Máy cũ vẫn chạy |
| Giờ chuyển đổi | Khóa ghi dữ liệu, đồng bộ lần cuối, đổi DNS | Bảo trì hoặc chỉ đọc trong thời gian ngắn |
| Sau đó | Theo dõi log, giữ máy cũ vài ngày | Máy mới chạy chính |
Bí quyết giữ thời gian gián đoạn ngắn là tách phần việc chậm (sao chép file, cài phần mềm) ra khỏi phần việc nhanh (đồng bộ lần cuối).
Bước 1: Hạ TTL DNS từ sớm
TTL quy định resolver được lưu cache bản ghi DNS của bạn trong bao lâu. Nếu bản ghi A đang có TTL 86400 giây, một số khách có thể vẫn vào máy chủ cũ suốt một ngày sau khi bạn đổi IP.
Trước ngày chuyển ít nhất bằng một chu kỳ TTL cũ, hãy hạ TTL của các bản ghi sẽ đổi (thường là @ và www) xuống 300 giây. Kiểm tra xem resolver đang thấy gì:
dig +noall +answer example.com A
dig +noall +answer www.example.com ACột thứ hai là TTL còn lại. Khi mọi nơi đều hiện 300 hoặc thấp hơn, bạn đã sẵn sàng.
Bước 2: Dựng và bảo mật máy chủ mới
Hãy chọn vị trí trước, vì chuyển thêm lần nữa sau này sẽ tốn công. Nếu khách truy cập chủ yếu ở Việt Nam, đặt máy chủ gần họ; nếu khách ở nhiều nước, cân nhắc kỹ hơn. Bài chọn vị trí VPS theo độ trễ và tổng quan các vị trí VPS sẽ giúp bạn quyết định, còn bài đo độ trễ bằng ping và mtr giúp bạn kiểm chứng bằng số liệu trước khi chốt.
Tạo máy chủ trong console Cloudj với SSH key, rồi làm theo checklist bảo mật VPS mới: tạo user thường, chỉ cho đăng nhập SSH bằng key, bật firewall và cập nhật bảo mật tự động. Cài cùng phiên bản chính của web server, runtime và database như máy cũ. Giữ phiên bản giống nhau giúp tránh lỗi với extension PHP hay định dạng file dump.
Nếu sau này cần dựng thêm máy giống hệt, bạn có thể lưu máy chủ đã cấu hình thành custom image trên Cloudj.
Bước 3: Đồng bộ file lần đầu bằng rsync
Chạy lần sao chép đầu tiên khi website cũ vẫn hoạt động bình thường. Từ máy chủ mới, kéo file qua SSH:
rsync -aHAX --numeric-ids --info=progress2 \
-e "ssh -p 22" \
deploy@OLD_SERVER_IP:/var/www/example.com/ /var/www/example.com/Vài tham số cần hiểu: -a giữ quyền và thời gian sửa file, -H giữ hard link, -A và -X giữ ACL và extended attributes. Dấu / ở cuối đường dẫn rất quan trọng: nó sao chép nội dung bên trong thư mục chứ không tạo thêm một thư mục lồng nhau.
Đừng quên những thứ nằm ngoài thư mục web:
- File virtual host của web server (
/etc/nginx/sites-available/hoặc/etc/httpd/conf.d/) - Chứng chỉ TLS, hoặc lên kế hoạch cấp chứng chỉ mới sau khi đổi DNS
- Cron job của từng user (
crontab -l) - File môi trường và cấu hình ứng dụng có chứa host và mật khẩu database
Lần đồng bộ đầu có thể mất khá lâu với website nhiều ảnh. Không sao cả, lần cuối rsync chỉ chuyển phần đã thay đổi.
Bước 4: Diễn tập chuyển database
Hãy import thử toàn bộ database vào ngày hôm trước để biết chính xác mất bao lâu.
Với MySQL hoặc MariaDB:
# trên máy chủ cũ
mysqldump --single-transaction --routines --triggers \
-u root -p app_db | gzip > /tmp/app_db.sql.gz
# trên máy chủ mới
scp deploy@OLD_SERVER_IP:/tmp/app_db.sql.gz /tmp/
mysql -u root -p -e "CREATE DATABASE app_db CHARACTER SET utf8mb4;"
gunzip < /tmp/app_db.sql.gz | mysql -u root -p app_dbVới PostgreSQL:
# trên máy chủ cũ
pg_dump -U postgres -Fc app_db > /tmp/app_db.dump
# trên máy chủ mới
createdb -U postgres app_db
pg_restore -U postgres -d app_db --no-owner /tmp/app_db.dumpTham số --single-transaction tạo bản chụp nhất quán cho các bảng InnoDB mà không khóa website. Ghi lại thời gian dump và import, vì đó gần như chính là độ dài khoảng bảo trì của bạn. Nhớ tạo lại user database và phân quyền trên máy mới, vì bản dump của một database không bao gồm chúng.
Bước 5: Thử máy chủ mới bằng file hosts
Trước khi đụng vào DNS, hãy duyệt website trên máy chủ mới như thể DNS đã trỏ sang. Thêm một dòng vào file hosts trên máy tính của bạn:
# macOS / Linux: /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts
NEW_SERVER_IP example.com www.example.comHoặc thử nhanh một request bằng dòng lệnh mà không cần sửa file nào:
curl -I --resolve example.com:443:NEW_SERVER_IP https://example.com/Kiểm tra những trang quan trọng: đăng nhập, giỏ hàng và thanh toán, form liên hệ, upload ảnh, tìm kiếm, trang quản trị. Vừa thử vừa theo dõi log lỗi (sudo tail -f /var/log/nginx/error.log). Thử xong thì xóa dòng trong file hosts để khỏi nhầm lẫn về sau.
Bước 6: Chuyển đổi chính thức
Chọn khung giờ vắng khách, chẳng hạn sau nửa đêm với website bán hàng trong nước. Sau đó làm lần lượt:
- Khóa ghi dữ liệu trên website cũ. Bật chế độ bảo trì hoặc chỉ đọc để không có đơn hàng hay bình luận mới rơi vào database cũ.
- Dump database lần cuối và import vào máy mới đúng như đã diễn tập.
- Chạy lại rsync với cùng lệnh cũ. Chỉ thêm
--deletekhi bạn chắc chắn thư mục đích phải giống hệt nguồn. - Đổi bản ghi DNS
A(vàAAAAnếu có IPv6) sang IP mới. - Cấp hoặc kiểm tra chứng chỉ TLS trên máy mới khi DNS đã trỏ về.
- Tắt chế độ bảo trì trên máy chủ mới.
Vì TTL đã là 300 giây, phần lớn khách sẽ chuyển sang máy mới trong vài phút. Một số resolver cũ không tuân theo TTL, nên máy chủ cũ cần tiếp tục hiện trang bảo trì thay vì nhận dữ liệu mới.
Bước 7: Theo dõi rồi mới xóa máy cũ
Trong ngày đầu tiên, hãy theo dõi access log, error log và các biểu đồ CPU, RAM, mạng trên trang máy chủ trong console. Bài giám sát tài nguyên VPS giải thích nên nhìn vào đâu. Kiểm tra cron job và email gửi đi, vì đây là hai thứ hay hỏng mà không báo lỗi.
Giữ máy chủ cũ vài ngày phòng khi cần lấy lại file nào đó. Sau đó nâng TTL DNS về mức bình thường và xóa máy cũ. Trên Cloudj, máy chủ tính theo giờ vẫn bị tính phí khi còn tồn tại, kể cả khi đã tắt, vì ổ đĩa và IP vẫn được giữ, nên hãy xóa khi chắc chắn không còn cần nữa.
Câu hỏi thường gặp
Website sẽ bị gián đoạn bao lâu?
Với đa số website nhỏ và vừa, thời gian gián đoạn xấp xỉ thời gian dump và import database lần cuối. Lần diễn tập ở Bước 4 cho bạn con số thực tế.
Có cách nào không gián đoạn chút nào không?
Chế độ bảo trì hoặc chỉ đọc trong lúc đồng bộ lần cuối là cách đơn giản và an toàn. Chuyển hoàn toàn không gián đoạn cần replication database và nhiều công chuẩn bị hơn, hiếm khi đáng làm với một website đơn lẻ.
Có cần chép chứng chỉ SSL sang máy mới không?
Có thể chép, nhưng thường đơn giản hơn là cấp chứng chỉ mới trên máy mới sau khi DNS đã trỏ về. Chép chứng chỉ cũ chỉ hữu ích nếu bạn muốn HTTPS hoạt động ngay trong lúc thử bằng file hosts.
Nên chọn cấu hình máy mới thế nào?
Chọn vừa với tải hiện tại và chừa một chút dư. Nếu biểu đồ cho thấy cần thêm, bạn có thể tăng CPU và RAM sau trong console.
Sẵn sàng chuyển nhà cho website
Hạ TTL sớm, diễn tập import database và thử bằng file hosts sẽ biến một lần chuyển đầy rủi ro thành việc thường ngày. Xem các cấu hình trên trang cloud server, giá cập nhật trên trang bảng giá, rồi triển khai máy chủ mới trong console khi bạn đã sẵn sàng. Khách hàng tại Việt Nam có thể nạp tiền vào tài khoản bằng chuyển khoản ngân hàng bằng VND.