Cách di chuyển máy chủ tại chỗ sang AWS (Sổ tay đơn giản)

Giới thiệu

Chuyển đổi từ on-prem sang AWS ít thất bại hơn do tính toán và nhiều hơn do thiếu sót trong kế hoạch: mục tiêu chuyển giao không rõ ràng, các phụ thuộc bị bỏ qua và thử nghiệm vội vàng. Hướng dẫn này giữ cho quy trình dễ theo dõi trong khi vẫn hoạt động. Bạn sẽ xác định thành công trông như thế nào, chuẩn bị một khu vực hạ cánh tối thiểu, thực hiện các buổi thử nghiệm AWS MGN, chuyển giao một cách tự tin và sau đó tối ưu hóa khối lượng công việc sau khi nó hoạt động.

Bạn nên quyết định điều gì trước khi di chuyển bất cứ thứ gì?

Chiến lược di chuyển nào phù hợp với máy chủ này (các "7 Rs" của AWS)?

Cách nhanh nhất để lãng phí thời gian là di chuyển sai thứ. Trước khi bạn cài đặt bất kỳ tác nhân nào, hãy quyết định chiến lược di chuyển nào mà máy chủ xứng đáng để bạn không nâng lên và chuyển đi thứ gì đó nên được nghỉ hưu hoặc thay thế. Trên thực tế, nhiều nhóm bắt đầu với việc tái lưu trữ để nhanh chóng, sau đó tối ưu hóa sau khi khối lượng công việc ổn định trong AWS.

Tuy nhiên, điều đó chỉ hoạt động khi máy chủ là một ứng cử viên "như hiện tại" tốt và sẽ không tạo ra nợ kỹ thuật tốn kém ngay lập tức sau khi chuyển đổi. Các lối tắt quyết định thực tiễn:

• Chuyển host: di chuyển nhanh với sự thay đổi tối thiểu khi thời gian eo hẹp.
• Chuyển nền tảng: giữ ứng dụng nhưng thực hiện một số điều chỉnh nhỏ cho phù hợp với AWS.
• Tái cấu trúc: dành nguồn lực cho những yếu tố khác biệt quan trọng đối với doanh nghiệp.
• Mua lại: thay thế bằng SaaS thay vì di chuyển máy chủ.
• Rút lui/Giữ lại: loại bỏ các hệ thống không sử dụng hoặc giữ khối lượng công việc bị hạn chế tại chỗ.

Một điểm kiểm tra nội bộ hữu ích là hỏi xem khối lượng công việc có "tương lai đám mây" hay không. Nếu máy chủ sau này sẽ được phân tách thành các dịch vụ quản lý hoặc được đóng gói, hãy ghi lại điều đó ngay bây giờ và coi việc tái lưu trữ như một bước tạm thời thay vì một thiết kế vĩnh viễn.

Các RTO/RPO là gì, Thời gian ngừng hoạt động và Các kích hoạt phục hồi?

Cắt chuyển thành công khi thành công có thể đo lường được. Định nghĩa thời gian ngừng hoạt động và mức độ chấp nhận mất dữ liệu, sau đó ghi lại các điều kiện buộc phải quay lại. Điều này giữ cho mục tiêu di chuyển rõ ràng và ngăn các nhóm tự phát trong thời gian cắt chuyển. Nó cũng giúp các bên liên quan trong doanh nghiệp phê duyệt vì họ có thể thấy chính xác rủi ro nào đang được chấp nhận.

Xác định và tài liệu hóa:

• RTO: thời gian ngừng hoạt động tối đa chấp nhận được.
• RPO: mất dữ liệu tối đa chấp nhận được.
• Thời gian ngừng hoạt động: khi bạn được phép chuyển đổi lưu lượng sản xuất.
• Kích hoạt hoàn tác: các điều kiện thất bại cụ thể (sự cố xác thực, giao dịch không thành công, không khớp dữ liệu).
• Cơ chế chuyển đổi: DNS flip, chuyển đổi bộ cân bằng tải, thay đổi định tuyến/tường lửa.

Để giữ cho kế hoạch phục hồi thực tế, hãy chỉ định ai sở hữu từng hành động trong quá trình chuyển đổi. Ví dụ, một người sở hữu các thay đổi DNS, một người sở hữu việc xác thực ứng dụng, và một người sở hữu "quyết định phục hồi" dựa trên các yếu tố kích hoạt ở trên.

Bạn cần chuẩn bị gì trong AWS và On-Prem trước tiên?

Cơ bản về kết nối và tường lửa cho việc sao chép

Sao chép chỉ hoạt động nếu môi trường nguồn có thể kết nối với AWS một cách nhất quán. Những rào cản phổ biến nhất là các kiểm soát xuất khẩu nghiêm ngặt, proxy và kiểm tra TLS gây cản trở lưu lượng HTTPS ra ngoài. Xác thực kết nối sớm và giữ cho đường truyền mạng ổn định trong quá trình sao chép ban đầu và các lần thử nghiệm. Trong nhiều môi trường, sao chép không bị "chặn" hoàn toàn; thay vào đó, các sự cố gián đoạn hoặc kiểm tra gói gây ra hành vi không ổn định mà khó chẩn đoán sau này.

Các mẫu kết nối phổ biến:

• Lưu lượng internet công cộng (đơn giản nhất khi được phép)
• VPN kết nối giữa các trang (thông dụng cho kết nối riêng)
• Kết nối trực tiếp (dễ dự đoán hơn cho các môi trường lớn hơn)

Kiểm tra trước chuyến bay:

• Outbound HTTPS hoạt động đáng tin cậy từ mạng nguồn
• Hành vi proxy được hiểu và kiểm tra với quy trình di chuyển
• Các đội ngũ bảo mật phê duyệt lối ra cần thiết cho khoảng thời gian di chuyển.

Nếu môi trường của bạn được bảo mật chặt chẽ, hãy thêm một bước “chứng minh mạng” ngắn vào kế hoạch sóng của bạn: xác thực các điểm cuối từ một máy chủ thử nghiệm, sau đó sao chép chính xác bộ quy tắc đó cho phần còn lại của sóng.

Danh sách kiểm tra khu vực hạ cánh AWS tối thiểu

Bạn không cần một khu vực hạ cánh hoàn hảo để bắt đầu, nhưng bạn cần một mục tiêu nhất quán mà sẽ không thay đổi giữa các đợt sóng. Giữ cho việc xây dựng tối giản, nhưng có chủ đích, để việc kiểm tra phản ánh những gì việc chuyển đổi sẽ trông như thế nào. Nhiều vấn đề di chuyển phát sinh từ các lối tắt mạng "tạm thời" trở thành vĩnh viễn vì không ai có thời gian để xây dựng lại chúng sau khi ra mắt.

Các yếu tố tối thiểu của khu vực hạ cánh:

• [A] Một VPC và các mạng con nơi các phiên bản sẽ khởi chạy (thường là tách biệt giữa kiểm tra và sản xuất)
• Nhóm bảo mật căn chỉnh theo quy trình ứng dụng thực tế (tránh “mở ngay, sửa sau”)
• IAM sẵn sàng cho các hoạt động di chuyển và truy cập cũng như công cụ vào ngày thứ hai
• Cơ bản gán nhãn sở hữu và theo dõi chi phí sẽ rõ ràng sau khi chuyển đổi

Nó cũng giúp quyết định sớm cách mà các quản trị viên sẽ truy cập vào các phiên bản (bastion, VPN SSM) và cách truy cập internet ra ngoài sẽ được cung cấp (cổng NAT, proxy). Những lựa chọn này ảnh hưởng đến việc vá lỗi, các tác nhân giám sát và khắc phục sự cố vào ngày đầu tiên.

Danh sách kiểm tra sẵn sàng của máy chủ nguồn

Một cuộc di chuyển sạch sẽ phụ thuộc vào một nguồn sạch. Xác nhận rằng khối lượng công việc tương thích với phương pháp bạn đã chọn, sau đó xác định bất kỳ điều gì phụ thuộc vào các giả định địa phương sẽ thay đổi trong AWS. Đây cũng là nơi bạn đánh dấu các máy chủ "trường hợp đặc biệt" có thể yêu cầu một trình tự khác. Ví dụ, một máy chủ tệp với hoạt động ghi nặng có thể cần một khoảng thời gian chuyển đổi chặt chẽ hơn và xác thực nghiêm ngặt hơn cho các tệp và chia sẻ đang mở.

Kiểm tra sự sẵn sàng để ngăn chặn những bất ngờ:

• Tính tương thích của hệ điều hành/tải công việc với phương pháp di chuyển
• Đĩa đủ và I/O ổn định cho chi phí sao chép
• Các phụ thuộc đã được ánh xạ: DNS , AD/LDAP nội bộ PKI/chứng chỉ cơ sở dữ liệu, chia sẻ
• Sự giòn ẩn: địa chỉ IP mã cứng, TLS lỗi thời, tác vụ theo lịch không phổ biến
• Các trường hợp đặc biệt được đánh dấu sớm: bộ điều khiển miền, cụm, thiết bị, cấp phép dongle

Trước khi rời khỏi bước này, hãy ghi lại các mục "phải giữ nguyên" như tên máy chủ, yêu cầu địa chỉ IP hoặc ràng buộc chứng chỉ, vì những điều này ảnh hưởng trực tiếp đến cài đặt khởi chạy AWS của bạn và trình tự chuyển đổi của bạn.

Làm thế nào để di chuyển một máy chủ đến AWS với AWS MGN?

Khởi tạo MGN và đặt mặc định sao chép

Khởi tạo AWS MGN trong khu vực mà máy chủ sẽ chạy, sau đó định nghĩa các mặc định sao chép để việc thực thi sóng giữ được tính nhất quán. Một mẫu ổn định giảm thiểu sự biến động giữa các máy chủ và làm cho việc khắc phục sự cố trở nên lặp lại. Hãy coi đây là quy trình hoạt động tiêu chuẩn của bạn cho việc sao chép, tương tự như một hình ảnh vàng trong môi trường ảo hóa.

Đặt mặc định sao chép ngay từ đầu:

• Chiến lược subnet mục tiêu và vị trí mạng
• Cơ sở dữ liệu nhóm bảo mật cho các phiên bản đã khởi chạy
• Hành vi lưu trữ (mapping ổ đĩa, mã hóa mong đợi)
• Giới hạn sao chép để bảo vệ lưu lượng sản xuất

Nếu bạn đã biết rằng sản xuất sẽ yêu cầu các cài đặt khác với thử nghiệm, hãy xác định rõ những khác biệt đó. Bằng cách đó, các lần khởi động thử nghiệm vẫn giữ được tính đại diện mà không làm lộ mạng sản xuất quá sớm.

Cài đặt tác nhân và hoàn tất đồng bộ ban đầu

Cài đặt tác nhân sao chép trên máy chủ nguồn và xác nhận rằng nó đã đăng ký thành công. Đồng bộ hóa ban đầu là nơi mà sự không ổn định khiến bạn tốn kém nhất, vì vậy hãy tránh những thay đổi không cần thiết và theo dõi tình trạng sao chép một cách chặt chẽ. Đây cũng là nơi các nhóm có lợi từ việc ghi chép quy trình cài đặt "đã biết là tốt" để họ không phải khắc phục những vấn đề giống nhau trong mỗi đợt.

Hướng dẫn vận hành:

• Giữ cho máy chủ ổn định trong quá trình sao chép ban đầu (tránh khởi động lại nếu có thể)
• Theo dõi trạng thái sao chép và xử lý lỗi ngay lập tức
• Ghi lại phương pháp cài đặt để các đợt sau nhất quán.

Trong quá trình đồng bộ ban đầu, hãy theo dõi không chỉ bảng điều khiển di chuyển mà còn cả hiệu suất máy chủ. Tải trọng sao chép có thể tiết lộ các nút thắt cổ chai lưu trữ hoặc lỗi đĩa mà trước đây đã bị che giấu trong môi trường tại chỗ.

Khởi động một phiên bản thử nghiệm và xác thực

Một lần khởi động thử nghiệm biến giả định thành bằng chứng. Khởi động phiên thử nghiệm, sau đó xác thực tình trạng ứng dụng từ đầu đến cuối, không chỉ là thành công khởi động. Sử dụng danh sách kiểm tra để việc kiểm tra có thể lặp lại trên các máy chủ và làn sóng. Nếu người dùng cuối sẽ kết nối qua TSplus Remote Access bao gồm một kiểm tra đường dẫn truy cập trong xác thực. Tính nhất quán rất quan trọng vì nó cho phép bạn so sánh kết quả giữa các khối lượng công việc và phát hiện các mẫu, chẳng hạn như các vấn đề phân giải DNS ảnh hưởng đến nhiều máy chủ.

Danh sách kiểm tra xác thực tối thiểu:

• Khởi động hoàn tất và các dịch vụ bắt đầu một cách sạch sẽ
• Kiểm tra khói ứng dụng thành công cho các quy trình làm việc chính
• Xác thực hoạt động (AD/LDAP/local)
• Đường dẫn dữ liệu hoạt động (kết nối DB, chia sẻ tệp, tích hợp)
• Các tác vụ đã lên lịch và dịch vụ nền chạy như mong đợi
• Nhật ký và tín hiệu giám sát xuất hiện nơi đội ngũ vận hành của bạn mong đợi

Thêm một bước nữa mà các nhóm thường bỏ qua: xác thực cách người dùng sẽ thực sự truy cập ứng dụng, bao gồm định tuyến nội bộ, quy tắc tường lửa và bất kỳ hệ thống upstream nào. Một máy chủ có thể "khỏe mạnh" nhưng không thể truy cập được trong thực tế.

Khởi động chuyển đổi và hoàn tất

Chuyển đổi là một sự chuyển đổi có kiểm soát, không phải là một bước nhảy của niềm tin. Đóng băng các thay đổi, khi có thể, thực hiện việc di chuyển lưu lượng sử dụng cơ chế đã lên kế hoạch, sau đó xác nhận bằng cách sử dụng cùng một danh sách kiểm tra như khi thử nghiệm. Giữ quyền sở hữu việc quay lại rõ ràng để các quyết định được nhanh chóng. Xem đây như một cuốn sách hướng dẫn có thể lặp lại: càng ít ứng biến, rủi ro càng thấp.

Cần thiết cho việc thực hiện chuyển đổi:

• Xác nhận kế hoạch đóng băng thay đổi và truyền thông
• Khởi động phiên cắt chuyển và chuyển đổi lưu lượng (DNS/LB/routing)
• Chạy lại danh sách kiểm tra xác thực với sự chú ý đặc biệt đến tính toàn vẹn của dữ liệu
• Áp dụng các kích hoạt hoàn tác nếu cần và khôi phục lưu lượng một cách sạch sẽ
• Hoàn tất chuyển đổi và loại bỏ hoặc chấm dứt các tài nguyên thử nghiệm

Ngay sau khi chuyển đổi, hãy ghi lại những gì đã thay đổi trong sản xuất (các IP mới, các tuyến đường mới, các quy tắc nhóm bảo mật mới) và tài liệu hóa nó. Đây là thông tin mà đội ngũ vận hành cần khi có sự cố xảy ra sau vài tuần.

Những gì thường bị hỏng, và bạn nên làm gì ngay sau khi chuyển đổi?

Lưu lượng mạng ra ngoài, phụ thuộc vào DNS/AD, và "nâng lên và chuyển đi không hoàn thành"

Hầu hết các lỗi là lỗi phụ thuộc. Việc sao chép thường bị hỏng do các ràng buộc ra ngoài và proxy, trong khi hành vi ứng dụng thường bị hỏng do danh tính, phân giải tên và chứng chỉ. Ngay cả khi việc chuyển đổi thành công, việc tái hosting chỉ là cột mốc đầu tiên, không phải trạng thái cuối cùng. Nếu không có giai đoạn thứ hai, bạn thường kết thúc với "di sản được lưu trữ trên đám mây" tốn kém hơn và khó vận hành hơn.

Các điểm ngắt phổ biến nhất:

• Outbound HTTPS bị chặn hoặc thay đổi bởi proxy Kiểm tra TLS
• Thay đổi phân giải DNS (vấn đề chân trời tách biệt, thiếu quy tắc phân giải)
• Các khoảng trống khả năng tiếp cận AD/LDAP từ VPC
• Chuỗi PKI nội bộ bị thiếu hoặc không được tin cậy trong môi trường mới
• Điểm cuối cứng và giả định lỗi thời về các đường dẫn mạng cục bộ

Một biện pháp đơn giản là kiểm tra danh tính và DNS sớm với một buổi ra mắt thử nghiệm. Nếu những yếu tố cơ bản đó hoạt động, phần còn lại của việc xác thực ứng dụng trở nên dễ dự đoán hơn nhiều.

Ổn định sau chuyển đổi: bảo mật, sao lưu, giám sát, chi phí

48 giờ đầu tiên sau khi chuyển đổi nên ưu tiên sự ổn định và kiểm soát. Hãy đảm bảo rằng khối lượng công việc có thể quan sát, phục hồi và được quản lý an toàn trước khi bạn dành thời gian cho việc tối ưu hóa sâu hơn. Đây cũng là nơi mà việc di chuyển của bạn thành công lâu dài, vì các hoạt động tốt vào ngày thứ hai sẽ ngăn chặn kết quả "chúng tôi đã chuyển nó, nhưng không ai muốn sở hữu nó".

Các hành động ngay sau khi chuyển đổi:

• Xác nhận việc giám sát/cảnh báo đang hoạt động và được sở hữu
• Đảm bảo sao lưu được kích hoạt và hoàn thành xác thực phục hồi
• Thắt chặt các nhóm bảo mật và áp dụng quyền tối thiểu IAM
• Chuẩn hóa cách vá lỗi và quyền truy cập quản trị (các đường dẫn có thể kiểm toán)
• Bắt đầu điều chỉnh quy mô sau khi bạn thu thập dữ liệu sử dụng thực tế.
• Thực thi gán nhãn để ngăn chặn sự trôi chi phí "chủ sở hữu không xác định"

Khi độ ổn định được chứng minh, hãy lên lịch một cuộc đánh giá tối ưu hóa ngắn cho mỗi máy chủ đã di chuyển. Ngay cả một lần kiểm tra nhẹ về các loại lưu trữ, lựa chọn gia đình phiên bản và chiến lược công suất dự trữ cũng có thể giảm đáng kể chi phí.

TSplus phù hợp ở đâu sau khi bạn chuyển máy chủ sang AWS?

Sau khi các khối lượng công việc Windows chạy trên AWS, nhiều nhóm vẫn cần một cách đơn giản để phát hành các ứng dụng và máy tính để bàn Windows cho người dùng mà không cần xây dựng một hệ thống VDI nặng nề. TSplus Remote Access cung cấp việc phát hành ứng dụng và truy cập máy tính từ xa cho các máy chủ Windows trong AWS, tại chỗ hoặc môi trường lai, với quản lý đơn giản và cấp phép có thể dự đoán phù hợp với các hoạt động của SMB và thị trường trung.

Kết luận

Di chuyển một máy chủ tại chỗ sang AWS thành công nhất khi nó tuân theo một quy trình lặp lại: chọn chiến lược di chuyển phù hợp, xác thực các phụ thuộc, sao chép an toàn, kiểm tra thực tế và chuyển đổi với các kích hoạt quay lại rõ ràng. Khi sản xuất ổn định, chuyển trọng tâm sang các hoạt động ngày thứ hai: tăng cường bảo mật, xác thực sao lưu, giám sát và điều chỉnh kích thước. Điều này biến một "cuộc di chuyển" thành một nền tảng đáng tin cậy, kiểm soát chi phí.