Chuyển sang hosting offshore không downtime

Không ai chuyển một trang web đang chạy chỉ vì thích thú. Chuyện đó xảy ra vì nhà cung cấp hiện tại bỗng dưng đòi một tấm ảnh chụp hộ chiếu của bạn, hoặc chuyển tiếp một khiếu nại kèm thời hạn 24 giờ, hoặc vì quốc gia đặt trung tâm dữ liệu của họ không còn là nơi hợp lý để giữ dữ liệu của bạn nữa. Dù lý do là gì, bản thân việc di chuyển mới là phần nguy hiểm — đó là khoảnh khắc duy nhất trang web có thể tối đen, và cũng là khoảnh khắc duy nhất một bước bất cẩn có thể ghim máy chủ mới vào chính danh tính mà bạn đang cố gắng bỏ lại phía sau.

Cả hai rủi ro đều có chung một cách chữa, và đó không phải là một công cụ. Đó là thứ tự. Một cuộc di chuyển chạy đúng trình tự sẽ không có khoảng thời gian nào trang web không thể truy cập được, vì cả hai máy chủ cùng hoạt động song song và DNS là thứ chuyển cuối cùng. Một cuộc di chuyển chạy sai trình tự sẽ tạo ra cả sự cố gián đoạn lẫn một dấu vết cùng lúc. Phần tiếp theo chính là trình tự đó, viết cho người chuyển sang một nhà cung cấp offshore, no-KYC chứ không phải xáo trộn giữa hai nhà cung cấp phổ thông — cơ chế kỹ thuật thì giống nhau, nhưng phần dọn dẹp sau đó thì không.

"Zero downtime" thực sự nghĩa là gì

Cụm từ này thường bị dùng một cách hời hợt, và chính sự hời hợt đó là nơi người ta gặp rắc rối. Phục vụ HTTP từ hai máy cùng lúc thì dễ. Giữ cho trạng thái nhất quán trong khi hai máy cùng phục vụ mới là phần khó, và đó cũng là phần duy nhất có thể làm mất dữ liệu. Vì vậy, trước khi lên kế hoạch bất cứ điều gì, hãy xác định bạn thực sự đang vận hành loại nào trong số này, vì câu trả lời sẽ định hình toàn bộ đêm hôm đó.

Để ý rằng chỉ có dòng đầu tiên là thực sự miễn phí. Ở mọi nơi khác, "zero downtime" nghĩa là "một lần đóng băng ghi dữ liệu ngắn đến mức không ai kịp mở ticket phàn nàn". Hai phút chỉ đọc lúc 04:00 sáng chỉ là một sai số làm tròn; hai giờ ghi dữ liệu chia đôi trên hai cơ sở dữ liệu là cả một cuối tuần đối soát lại. Hãy chọn khoảng đóng băng.

Hạ TTL của DNS trước nhiều ngày, trước khi bạn định di chuyển

Đây là bước duy nhất đòi hỏi thời gian chờ, đó là lý do nó đứng đầu tiên và cũng là bước mà người ta hay bỏ qua nhất. TTL — thời gian tồn tại — cho mọi trình phân giải trên Internet biết nó được phép cache bản ghi của bạn trong bao lâu trước khi hỏi lại. Nếu bản ghi A của bạn có TTL là 86400, một trình phân giải đã tra cứu cách đây một giờ sẽ tiếp tục trả về IP cũ trong 23 giờ nữa, bất kể bạn đổi gì ở nhà đăng ký tên miền.

Chi tiết mấu chốt là: việc hạ TTL cũng bị chi phối bởi chính TTL cũ. Các trình phân giải chỉ biết đến giá trị mới, ngắn hơn khi bản cache cũ hết hạn. Vì vậy hãy hạ TTL xuống 300 giây ít nhất một chu kỳ TTL cũ trước khi cutover — với một TTL dài một ngày, nghĩa là phải làm việc này trước 24 đến 48 giờ. Khi đó cả thế giới sẽ hội tụ về bản ghi mới của bạn trong vòng năm phút sau khi thay đổi, và cutover không còn là một sự kiện hồi hộp nữa.

Hãy đưa TTL trở lại mức hợp lý vài ngày sau khi di chuyển xong. TTL 300 giây là một công cụ tốt nhưng là một cấu hình vĩnh viễn tồi: nó nhân số lượng truy vấn của bạn lên nhiều lần, và khiến nhà cung cấp DNS của bạn trở thành một điểm lỗi duy nhất còn nghiêm trọng hơn.

Kiểm kê những gì bạn đang di chuyển, không phải những gì bạn nhớ được

Mọi cuộc di chuyển thất bại đều có chung một bản mổ xẻ hậu kỳ: có thứ gì đó không ai liệt kê ra nên đã không được copy. Web root và cơ sở dữ liệu là hai thứ ai cũng nhớ; danh sách dưới đây là phần còn lại, và đáng để bạn rà từng dòng theo đúng nghĩa đen thay vì dựa vào trí nhớ.

• Công việc theo lịch. crontab -l cho từng user, cộng với các systemd timer. Các hook gia hạn và job chạy đêm thường ẩn ở đây.
• Định nghĩa dịch vụ. Các systemd unit tùy chỉnh, vhost của web server, các pool PHP-FPM, mọi cấu hình supervisor.
• Secret và biến môi trường. Các file .env, API key, mật khẩu cơ sở dữ liệu, salt của ứng dụng — và lưu ý rằng những thứ này nên được xoay vòng chứ không chỉ đơn thuần copy sang.
• Dữ liệu TLS. Chứng chỉ và, quan trọng hơn, tài khoản ACME cùng cấu hình gia hạn.
• Danh tính mail. Khóa riêng DKIM, các bản ghi SPF và DMARC. Sai lệch ở đây không làm mọi thứ sập ầm ĩ; nó chỉ âm thầm đẩy mail của bạn vào spam.
• Media đã upload. Thường nằm ngoài web root, và thường là thứ chiếm dung lượng lớn nhất bạn có.
• Mọi thứ bên ngoài tin tưởng vào IP của bạn. Allowlist của cổng thanh toán, đích webhook, tường lửa cơ sở dữ liệu, các API bên thứ ba có giới hạn theo IP. Đây là nguyên nhân số một khiến "trang web thì chạy nhưng checkout thì hỏng" lúc 03:00 sáng.
• Danh sách gói phần mềm. dpkg --get-selections hoặc lệnh tương đương, để máy mới có cùng các extension và thư viện, chứ không phải chỉ gần giống.

Hãy ghi danh sách này ra trước khi bắt đầu copy. Bản kiểm kê này sau đó cũng chính là kế hoạch kiểm thử của bạn — mỗi dòng trong đó là một thứ cần xác minh trên máy chủ mới trước khi DNS biết đến sự tồn tại của nó.

Dựng máy chủ mới trước, và gia cố nó trước khi nó chứa bất cứ thứ gì

Hãy đặt máy đích sớm và để nó chạy trống trong một hoặc hai ngày. Việc chồng lấn này không tốn kém gì — một VPS offshore nhỏ chỉ vài đô la mỗi tháng — trong khi giá trị mang lại rất lớn: bạn không phải dựng máy dưới áp lực thời gian trong khi một cơ sở dữ liệu đang bị đóng băng chờ sẵn.

Hãy cố tình khớp lại môi trường cũ: cùng bản phân phối và cùng phiên bản chính, cùng phiên bản chính của PHP, Node hay Python, cùng phiên bản chính của cơ sở dữ liệu. Sự cám dỗ muốn hiện đại hóa mọi thứ trong lúc đang làm là rất lớn, và bạn nên cưỡng lại hoàn toàn. Nếu trang web hỏng sau cutover, bạn muốn chỉ có đúng một biến số đã thay đổi. Hãy nâng cấp stack hai tuần sau đó, vào một buổi chiều nhàn nhã, với khả năng rollback nếu cần.

Hãy gia cố nó trong khi nó vẫn còn trống. SSH chỉ dùng khóa, tường lửa mặc định-từ-chối, cập nhật bảo mật tự động — danh sách gia cố giờ đầu tiên chính xác là danh sách này, và nó dễ áp dụng hơn nhiều lên một máy chưa có gì. Nếu dữ liệu đủ nhạy cảm đến mức bạn phải đổi cả thẩm quyền pháp lý vì nó, đây cũng là thời điểm thích hợp để quyết định về mã hóa dữ liệu ở trạng thái nghỉ, vì làm việc đó về sau đồng nghĩa với một cuộc di chuyển khác nữa.

Copy dữ liệu hai lần: một lượt chậm, rồi một lượt nhanh

Bản năng tự nhiên là copy mọi thứ trong lúc cửa sổ bảo trì. Hãy làm ngược lại. Chạy một lượt copy đầy đủ từ nhiều ngày trước, trong khi trang cũ vẫn đang phục vụ traffic bình thường, rồi chạy một lượt thứ hai vào lúc cutover chỉ để chuyển phần đã thay đổi. Lượt đầu có thể mất sáu tiếng mà chẳng ai để ý. Lượt thứ hai chỉ mất chín mươi giây, và đó chính là toàn bộ ngân sách downtime của bạn.

Với file, rsync -aHAX --numeric-ids giữ nguyên quyền truy cập, chủ sở hữu, hard link và các thuộc tính mở rộng; cờ --numeric-ids quan trọng vì UID hiếm khi khớp nhau giữa hai máy vừa được dựng mới. Chạy nó một lần từ sớm, rồi chạy lại ngay trước cutover với cùng các tham số — lần chạy thứ hai chỉ truyền phần chênh lệch.

Cơ sở dữ liệu cần cách xử lý hai giai đoạn tương tự nhưng dùng công cụ khác. Một lệnh mysqldump --single-transaction hoặc pg_dump cho bạn một bản snapshot sớm, nhất quán, để dựng và kiểm thử. Đến lúc cutover, hoặc là chạy dump lần hai trong khoảng đóng băng ghi ngắn ngủi của bạn, hoặc — với một cơ sở dữ liệu lớn mà ngay cả một khoảng đóng băng ngắn cũng gây đau — thiết lập máy chủ mới thành một replica của máy cũ từ nhiều ngày trước, để nó bắt kịp, rồi promote nó lên chính. Replication biến khoảng đóng băng thành vài giây. Nhưng nó cũng biến một cuộc di chuyển hai tiếng thành một dự án hai ngày, nên chỉ dùng khi quy mô thực sự đòi hỏi.

Kiểm thử máy chủ mới trước khi DNS biết đến sự tồn tại của nó

Bạn có thể phục vụ đúng hostname thật từ IP mới mà không cần đổi một bản ghi công khai nào, và bạn nên làm vậy — đây chính là điều khiến cutover diễn ra êm xuôi không biến cố. Hãy thêm một dòng vào /etc/hosts cục bộ của bạn, trỏ domain về IP mới, hoặc bỏ qua bước đó và để curl làm điều tương tự chỉ cho một request:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Giờ hãy rà lại toàn bộ bản kiểm kê. Tải trang chủ và ba trang nằm sâu trong cấu trúc site. Đăng nhập. Gửi một form. Upload một file. Kiểm tra rằng kết nối cơ sở dữ liệu đang trỏ đến bản cục bộ mới chứ không còn trỏ qua Internet về host cũ — một lỗi vẫn chạy hoàn hảo cho đến tận khi bạn hủy máy chủ cũ. Chạy tay các cron job và đọc output của chúng. Xác minh các redirect, và rằng một URL không tồn tại vẫn trả về 404 chứ không phải 200.

Hãy cấp chứng chỉ TLS ngay bây giờ, trước cutover, không phải sau. Dùng một thử thách DNS-01, thứ chứng minh quyền kiểm soát domain thông qua một bản ghi TXT, và vì vậy vẫn hoạt động trong khi bản ghi A còn đang trỏ về máy chủ cũ. Nếu bạn đợi xác thực HTTP-01 sau khi đổi DNS, mọi khách truy cập sớm sẽ gặp cảnh báo chứng chỉ trong suốt khoảng trống đó — một sự cố gián đoạn tự gây ra, ngay trong chính khoảng thời gian bạn đang cố bảo vệ.

Cutover, theo đúng thứ tự

Đến lúc này, máy chủ mới đã được dựng, gia cố, nạp đầy đủ dữ liệu, kiểm thử dưới đúng hostname thật, và đang giữ một chứng chỉ hợp lệ. Bản thân cutover giờ chỉ còn là một danh sách ngắn, nhàm chán — đúng như mục tiêu đề ra.

1. Thông báo khoảng thời gian này nếu có ai khác phụ thuộc vào trang web, sau đó đưa trang cũ vào chế độ chỉ đọc hoặc bảo trì.
2. Tắt cron và các worker chạy nền trên host cũ. Làm việc này trước khi bật chúng trên host mới, không bao giờ làm sau.
3. Chạy lượt delta rsync cuối cùng và bản dump cơ sở dữ liệu cuối cùng, rồi import nó vào.
4. Khởi động ứng dụng trên máy chủ mới và chạy lại các smoke test của bạn thông qua --resolve, dựa trên dữ liệu cuối cùng.
5. Đổi các bản ghi A và AAAA sang IP mới. Với TTL 300 giây, cả thế giới sẽ theo kịp trong vòng năm phút.
6. Bật cron và worker trên host mới.
7. Theo dõi song song access log của cả hai máy. Traffic sẽ rút dần khỏi máy chủ cũ và xuất hiện trên máy mới; khi máy cũ im lặng hẳn, cutover đã hoàn tất.
8. Để máy chủ cũ tiếp tục chạy, phục vụ, và không đụng vào trong một tuần. Đó là phương án rollback của bạn.

Bước tám là bước người ta hay cắt bỏ nhất, và nó là khoản bảo hiểm rẻ nhất trong cả danh sách. Chỉ với giá vài đô la, bạn giữ được khả năng trỏ DNS quay lại — một cuộc khôi phục năm phút — trong suốt thời gian cần thiết để chắc chắn mọi thứ ổn.

Những gì cuộc di chuyển để lại phía sau

Đây là phần mà các hướng dẫn di chuyển chung chung thường bỏ qua, và cũng là phần quan trọng nhất nếu bạn chuyển đi vì lý do riêng tư chứ không phải vì giá cả. Chuyển một trang web đi không xóa được lịch sử của nó. Nhiều bản ghi công khai và bán công khai về cách sắp xếp cũ vẫn tồn tại vĩnh viễn sau khi di chuyển, và biết được đó là những bản ghi nào chính là ranh giới giữa một sự dứt điểm thật sự và một cảm giác dứt điểm giả tạo.

Tóm lại một cách thẳng thắn: một cuộc di chuyển không thể viết lại quá khứ — nó chỉ có thể ngừng cộng thêm vào đó. Điều đó vẫn rất đáng giá, nhưng nó làm thay đổi quyết định của bạn: nếu mô hình đe dọa của bạn đòi hỏi không một người quan sát nào có thể liên kết trang mới với trang cũ, thì việc chuyển cùng một domain sang một host mới sẽ không đạt được điều đó, và dù bạn có cẩn thận đến đâu trong lúc cutover cũng vô ích. Trường hợp đó cần một cái tên mới và một khởi đầu sạch sẽ, sẽ được bàn tới ngay sau đây. Còn nếu mục tiêu của bạn chỉ là ngừng tạo ra các bản ghi định danh kể từ hôm nay trở đi, và chuyển trọng tâm pháp lý sang một thẩm quyền pháp lý bạn tự chọn, thì cuộc di chuyển này làm được chính xác điều đó. Hướng dẫn OpSec máy chủ của chúng tôi trình bày những thói quen giữ cho mọi thứ sạch sẽ sau đó.

Câu hỏi về domain: giữ lại, hay làm lại từ đầu?

Trang web và domain là hai quyết định độc lập, và việc gộp chung chúng lại là chuyện thường gặp. Bạn có thể chuyển hosting ngay hôm nay và để yên nhà đăng ký mãi mãi; không có gì trong việc đổi máy chủ bắt buộc bạn phải động đến domain. Còn việc bạn có nên làm vậy hay không thì hoàn toàn phụ thuộc vào việc domain đó đã biết những gì về bạn.

• Giữ domain, đổi nhà đăng ký. Hợp lý khi domain đó có giá trị — liên kết, thứ hạng, một cái tên người ta hay gõ. Cách này chỉ sửa được tương lai của bản ghi WHOIS, không sửa được lịch sử của nó, nhưng giữ nguyên vẹn mọi tín hiệu xếp hạng. Đây là câu trả lời đúng cho phần lớn các trang web thương mại.
• Giữ domain, không đổi gì ngoài host. Hoàn toàn hợp lý nếu bạn chuyển đi vì lý do thẩm quyền pháp lý, uptime hay tình trạng DMCA chứ không phải vì ẩn danh. Đây là cách chuyển đơn giản nhất có thể, rủi ro SEO bằng 0.
• Domain mới, redirect domain cũ về đó. Giữ được thứ hạng, nhưng liên kết công khai và vĩnh viễn hai cái tên lại với nhau. Chỉ chọn cách này vì tính liên tục, không bao giờ vì quyền riêng tư — bản thân redirect chính là mối liên kết đó.
• Domain mới, dứt điểm hoàn toàn. Đây là lựa chọn duy nhất thực sự cắt đứt mối liên hệ, và cái giá phải trả là mọi thứ hạng cùng mọi liên kết trỏ đến bạn từng có. Hãy đăng ký nó ở chế độ riêng tư ngay từ đầu, vì một domain chỉ ẩn danh đúng bằng mức độ ẩn danh của lần đăng ký đầu tiên của nó. Hướng dẫn đăng ký domain ẩn danh bằng crypto của chúng tôi trình bày cách làm việc này cho đúng.

Hãy chọn một cách có chủ đích, và chọn trước cutover chứ không phải trong lúc cutover. Đổi ý về domain sau khi DNS đã chuyển đồng nghĩa với việc phải làm lại phần tinh vi đó thêm một lần nữa.

Ngừng sử dụng host cũ đúng cách

Một hoặc hai tuần sau cutover, khi log của máy chủ mới đã trở nên nhàm chán còn log của máy cũ đã trống trơn, đó là lúc đóng tài khoản cũ. Hãy làm theo đúng thứ tự này, vì lối tắt hấp dẫn nhất — bấm hủy ngay — lại chính là thứ để lại dữ liệu của bạn trên ổ đĩa của người khác.

1. Xác nhận không còn gì trỏ về IP cũ nữa: kiểm tra các địa chỉ hardcode trong webhook bên thứ ba, allowlist, hệ thống giám sát, và bất kỳ bản ghi DNS nào bạn đã quên, chẳng hạn một subdomain mail hay cpanel còn sót lại.
2. Xoay vòng mọi secret từng tồn tại trên máy đó — mật khẩu cơ sở dữ liệu, API key, salt của ứng dụng, khóa DKIM, khóa SSH. Đừng copy chúng sang máy mới.
3. Gỡ bỏ khóa công khai SSH của bạn và mọi quyền truy cập hỗ trợ khỏi máy chủ cũ.
4. Xóa ứng dụng, các bản dump và bản sao lưu, rồi ghi đè lên vùng trống để một lượt đọc qua loa trên volume tái sử dụng không thu được gì.
5. Chỉ đến lúc đó mới chấm dứt dịch vụ, và gỡ bỏ mọi phương thức thanh toán đã lưu khỏi tài khoản cũ.

Toàn bộ trình tự trên một trang

Bỏ hết phần lý giải đi, một cuộc di chuyển host chỉ còn lại chín bước, trong đó chỉ có hai bước thực sự khẩn cấp:

1. Hai ngày trước: hạ TTL của DNS xuống 300 giây.
2. Hai ngày trước: đặt và gia cố máy chủ đích, khớp đúng phiên bản với stack cũ.
3. Nhiều ngày trước: viết bản kiểm kê — cron, secret, TLS, khóa mail, media, allowlist IP, gói phần mềm.
4. Nhiều ngày trước: chạy lượt copy dữ liệu đầy đủ đầu tiên, máy-đến-máy.
5. Trước cửa sổ cutover: cấp chứng chỉ bằng DNS-01 và kiểm thử mọi thứ qua --resolve.
6. Cửa sổ cutover (vài phút): đóng băng ghi dữ liệu, tắt cron cũ, chạy lượt copy delta và bản dump cuối cùng, khởi động app mới.
7. Cửa sổ cutover (vài giây): đổi bản ghi A, rồi bật cron trên host mới.
8. Tuần kế tiếp: giữ máy chủ cũ sống làm phương án rollback, theo dõi cả hai file log, rồi nâng TTL trở lại.
9. Sau đó: xoay vòng secret, xóa sạch, hủy dịch vụ — và nhớ những gì cuộc di chuyển không thể xóa bỏ được.

Không có gì trong danh sách đó khó cả. Mọi bước gây đau đầu đều là một bước bị làm sai thứ tự — một TTL bị hạ ngay trong đêm, một chứng chỉ được cấp sau khi DNS đã đổi, một cron job bị bỏ quên vẫn sẵn sàng chạy trên một máy chủ không còn có thẩm quyền. Làm đúng trình tự thì phần thú vị nhất của một cuộc di chuyển sẽ là chọn nơi đặt máy chủ, chứ không phải bản thân việc di chuyển. Nếu bạn chưa quyết được điều đó, hướng dẫn chọn thẩm quyền pháp lý là nơi nên bắt đầu.