Cara Memindahkan Pelayan On-Premises ke AWS (Buku Panduan Ringkas)

Pengenalan

Pindahan dari on-prem ke AWS gagal kurang kerana pengiraan dan lebih kerana kekurangan perancangan: objektif pemotongan yang tidak jelas, kebergantungan yang diabaikan, dan ujian yang tergesa-gesa. Panduan ini memastikan prosesnya mudah diikuti sambil tetap beroperasi. Anda akan menentukan apa yang dimaksudkan dengan kejayaan, menyediakan zon pendaratan minimum, menjalankan pelancaran ujian AWS MGN, melakukan pemotongan dengan yakin, dan kemudian mengoptimumkan beban kerja setelah ia aktif.

Apa yang Perlu Anda Putuskan Sebelum Memindahkan Apa-apa?

Strategi migrasi manakah yang sesuai untuk pelayan ini (AWS "7 Rs")?

Cara paling cepat untuk membuang masa adalah dengan memindahkan perkara yang salah. Sebelum anda memasang sebarang ejen, tentukan strategi pemindahan yang layak untuk pelayan supaya anda tidak mengangkat dan memindahkan sesuatu yang sepatutnya dihentikan atau digantikan. Dalam amalan, banyak pasukan bermula dengan pemindahan untuk kelajuan, kemudian mengoptimumkan kemudian setelah beban kerja stabil di AWS.

Namun, itu hanya berfungsi apabila pelayan adalah calon "as-is" yang baik dan tidak akan mencipta hutang teknikal yang mahal dengan segera selepas pemindahan. Pendekatan keputusan praktikal:

• Rehost: bergerak cepat dengan perubahan minimum apabila masa terhad.
• Replatform: tetap aplikasi tetapi buat penyesuaian kecil untuk kesesuaian AWS.
• Refactor: simpan usaha untuk pembezaan kritikal perniagaan.
• Pembelian semula: ganti dengan SaaS sebaliknya daripada memindahkan pelayan.
• Pencen/Pelihara: buang sistem yang tidak digunakan atau kekalkan beban kerja terhad di premis.

Satu titik pemeriksaan dalaman yang berguna adalah untuk bertanya sama ada beban kerja mempunyai “masa depan awan.” Jika pelayan akan dipecahkan kepada perkhidmatan terurus atau dikontena, dokumenkan itu sekarang dan anggap rehosting sebagai langkah sementara dan bukannya reka bentuk tetap.

Apakah RTO/RPO, Tingkap Waktu Henti, dan Pemicu Pemulihan?

Pemindahan berjaya apabila kejayaan dapat diukur. Tentukan masa henti dan toleransi kehilangan data yang boleh diterima, kemudian tuliskan syarat yang memaksa pemulihan. Ini mengekalkan objektif migrasi dan mencegah pasukan daripada mengubahsuai semasa tingkap pemindahan. Ia juga membantu pemegang kepentingan perniagaan untuk memberikan persetujuan kerana mereka dapat melihat dengan tepat risiko yang diterima.

Tentukan dan dokumentasikan:

• RTO: masa henti maksimum yang boleh diterima.
• RPO: kerugian data maksimum yang boleh diterima.
• Tempoh waktu tidak berfungsi: apabila anda dibenarkan untuk menukar trafik pengeluaran.
• Pemicu rollback: keadaan kegagalan tertentu (gangguan pengesahan, transaksi gagal, ketidakpadanan data).
• Mekanisme pemindahan: DNS flip, suis penyeimbang beban, perubahan penghalaan/tembok api.

Untuk memastikan pelan pemulihan tetap realistik, nyatakan siapa yang memiliki setiap tindakan semasa pemindahan. Sebagai contoh, seorang individu memiliki perubahan DNS, seorang lagi memiliki pengesahan aplikasi, dan seorang lagi memiliki "keputusan pemulihan" berdasarkan pemicu di atas.

Apa yang Anda Perlu Siapkan di AWS dan On-Prem Pertama?

Asas sambungan dan firewall untuk replikasi

Replikasi hanya berfungsi jika persekitaran sumber dapat mencapai AWS secara konsisten. Penghalang yang paling biasa adalah kawalan keluar yang ketat, proksi, dan pemeriksaan TLS yang mengganggu trafik HTTPS keluar. Sahkan sambungan awal dan kekalkan laluan rangkaian yang stabil semasa replikasi awal dan pelancaran ujian. Dalam banyak persekitaran, replikasi tidak "dihalang" secara langsung; sebaliknya, penurunan yang tidak konsisten atau pemeriksaan paket menyebabkan tingkah laku yang tidak stabil yang sukar untuk didiagnosis kemudian.

Corak sambungan biasa:

• Egress internet awam (paling mudah apabila dibenarkan)
• VPN site-ke-site (biasa untuk sambungan peribadi)
• Sambungan Langsung (lebih boleh diramal untuk persekitaran yang lebih besar)

Semakan pra-penerbangan:

• Outbound HTTPS berfungsi dengan baik dari rangkaian sumber.
• Tingkah laku proksi difahami dan diuji dengan aliran migrasi
• Pasukan keselamatan meluluskan egress yang diperlukan untuk tingkap migrasi.

Jika persekitaran anda sangat terkawal, tambahkan langkah “bukti rangkaian” yang pendek ke dalam pelan gelombang anda: sahkan titik akhir dari satu pelayan perintis, kemudian salin set peraturan yang tepat itu untuk baki gelombang.

Senarai semak zon pendaratan AWS minimum

Anda tidak memerlukan zon pendaratan yang sempurna untuk memulakan, tetapi anda memerlukan sasaran yang konsisten yang tidak akan berubah di tengah-tengah gelombang. Pastikan pembinaan adalah minimal, tetapi sengaja, supaya ujian mencerminkan bagaimana pemindahan akan kelihatan. Banyak isu migrasi datang dari jalan pintas rangkaian "sementara" yang menjadi kekal kerana tiada siapa yang mempunyai masa untuk membinanya semula selepas pelancaran.

Elemen zon pendaratan minimum:

• [A] TSplus vs RDS VPC dan subnet di mana instans akan dilancarkan (sering ujian berasingan vs pengeluaran)
• Kumpulan keselamatan selaras dengan aliran aplikasi sebenar (elakkan “buka sekarang, baiki kemudian”)
• IAM sedia untuk operasi migrasi dan akses serta alat hari kedua
• Asas penandaan jadi pemilikan dan penjejakan kos adalah jelas selepas pemindahan

Ia juga membantu untuk memutuskan lebih awal bagaimana pentadbir akan mengakses instans (bastion, VPN SSM) dan bagaimana akses internet keluar akan disediakan (gerbang NAT, proksi). Pilihan ini mempengaruhi tampalan, ejen pemantauan, dan penyelesaian masalah pada hari pertama.

Senarai semak kesediaan pelayan sumber

Migrasi yang bersih bergantung pada sumber yang bersih. Sahkan beban kerja adalah serasi dengan kaedah yang anda pilih, kemudian kenal pasti apa-apa yang bergantung pada andaian tempatan yang akan berubah di AWS. Ini juga di mana anda menandakan pelayan "kes khas" yang mungkin memerlukan urutan yang berbeza. Sebagai contoh, pelayan fail dengan aktiviti tulis yang berat mungkin memerlukan tingkap pemotongan yang lebih ketat dan pengesahan yang lebih ketat untuk fail dan perkongsian yang terbuka.

Pemeriksaan kesiapsiagaan yang mencegah kejutan:

• Keserasian OS/kerja dengan pendekatan migrasi
• Cakera yang mencukupi dan I/O yang stabil untuk beban replikasi
• Kebergantungan yang dipetakan: DNS , AD/LDAP , dalaman PKI/sijil , pangkalan data, saham
• Kerapuhan tersembunyi: IP yang ditetapkan secara keras, TLS warisan, tugas terjadual yang tidak biasa
• Kes khas yang ditandakan awal: pengawal domain, kluster, peranti, pelesenan dongle

Sebelum meninggalkan langkah ini, tangkap item "harus tetap sama" seperti nama hos, keperluan alamat IP, atau pengikatan sijil, kerana ini secara langsung mempengaruhi tetapan pelancaran AWS anda dan urutan pemindahan anda.

Bagaimana Anda Memindahkan Pelayan ke AWS dengan AWS MGN?

Inisialisasi MGN dan tetapkan lalai replikasi

Inisialisasi AWS MGN di Wilayah di mana pelayan akan beroperasi, kemudian tetapkan lalai replikasi supaya pelaksanaan gelombang tetap konsisten. Templat yang stabil mengurangkan variasi setiap pelayan dan menjadikan penyelesaian masalah boleh diulang. Anggap ini sebagai prosedur operasi standard anda untuk replikasi, serupa dengan imej emas dalam persekitaran maya.

Tetapkan lalai replikasi terlebih dahulu:

• Strategi subnet sasaran dan penempatan rangkaian
• Garis dasar kumpulan keselamatan untuk instance yang dilancarkan
• Tingkah laku penyimpanan (pemetaan volume, penyulitan harapan)
• Pengawalan replikasi untuk melindungi trafik pengeluaran

Jika anda sudah tahu bahawa pengeluaran akan memerlukan tetapan yang berbeza daripada pengujian, nyatakan perbezaan tersebut secara jelas. Dengan cara itu, pelancaran ujian tetap mewakili tanpa mendedahkan rangkaian pengeluaran lebih awal.

Pasang ejen dan lengkapkan penyegerakan awal

Pasang ejen replikasi pada pelayan sumber dan sahkan ia mendaftar dengan berjaya. Penyegerakan awal adalah di mana ketidakstabilan paling merugikan anda, jadi elakkan perubahan yang tidak perlu dan pantau kesihatan replikasi dengan teliti. Ini juga di mana pasukan mendapat manfaat daripada mendokumentasikan aliran pemasangan "yang diketahui baik" supaya mereka tidak menyelesaikan isu yang sama dalam setiap gelombang.

Panduan operasi:

• Pastikan pelayan stabil semasa replikasi awal (elakkan reboot jika boleh)
• Pantau status replikasi dan tangani kesilapan dengan segera
• Dokumentasikan kaedah pemasangan supaya gelombang akan datang konsisten

Semasa penyegerakan awal, pantau bukan sahaja konsol migrasi tetapi juga prestasi pelayan. Beban replikasi boleh mendedahkan kesesakan penyimpanan atau ralat cakera yang sebelum ini tersembunyi dalam persekitaran di lokasi.

Lancarkan satu instance ujian dan sahkan

Pelancaran ujian mengubah andaian menjadi bukti. Lancarkan contoh ujian, kemudian sahkan kesihatan aplikasi dari hujung ke hujung, bukan hanya kejayaan but. Gunakan senarai semak supaya ujian boleh diulang di seluruh pelayan dan gelombang. Jika pengguna akhir akan menyambung melalui TSplus Remote Access Sertakan pemeriksaan laluan akses dalam pengesahan. Konsistensi adalah penting kerana ia membolehkan anda membandingkan hasil antara beban kerja dan mengenal pasti corak, seperti isu resolusi DNS yang mempengaruhi pelayan yang berbilang.

Senarai semak pengesahan minimum:

• Boot selesai dan perkhidmatan bermula dengan lancar
• Ujian asap aplikasi lulus untuk aliran kerja utama
• Pengesahan berfungsi (AD/LDAP/lokal)
• Jalur data berfungsi (sambungan DB, perkongsian fail, integrasi)
• Pekerjaan terjadual dan perkhidmatan latar belakang berjalan seperti yang dijangkakan
• Logs dan isyarat pemantauan muncul di tempat yang dijangkakan oleh pasukan ops anda

Tambahkan satu langkah lagi yang sering dilewati oleh pasukan: sahkan bagaimana pengguna sebenarnya akan mengakses aplikasi, termasuk penghalaan dalaman, peraturan firewall, dan sebarang sistem hulu. Sebuah pelayan boleh menjadi "sihat" tetapi tidak dapat diakses dalam praktik.

Lancarkan pemindahan dan selesaikan

Cutover adalah pertukaran yang terkawal, bukan langkah percaya. Bekukan perubahan, jika boleh, laksanakan pemindahan trafik menggunakan mekanisme yang dirancang, kemudian sahkan menggunakan senarai semak yang sama seperti pengujian. Pastikan pemilikan rollback jelas supaya keputusan dapat dibuat dengan cepat. Anggap ini sebagai buku panduan yang boleh diulang: semakin sedikit anda mengimprovisasi, semakin rendah risikonya.

Keperluan pelaksanaan pemindahan:

• Sahkan pelan pembekuan perubahan dan komunikasi
• Lancarkan instance cutover dan alihkan trafik (DNS/LB/routing)
• Jalankan semula senarai semak pengesahan dengan tumpuan tambahan pada integriti data
• Terapkan pemicu rollback jika diperlukan dan kembalikan lalu lintas dengan bersih.
• Selesaikan pemindahan dan keluarkan atau tamatkan sumber ujian

Segera selepas pemindahan, tangkap apa yang berubah dalam pengeluaran (IP baru, laluan baru, peraturan kumpulan keselamatan baru) dan dokumentasikan. Ini adalah maklumat yang diperlukan oleh pasukan operasi apabila sesuatu rosak beberapa minggu kemudian.

Apa yang Selalunya Rosak, dan Apa yang Perlu Anda Lakukan Selepas Pemindahan?

Keluar rangkaian, kebergantungan DNS/AD, dan "angkat dan alih tidak dilakukan"

Kebanyakan kegagalan adalah kegagalan kebergantungan. Replikasi cenderung terputus pada batasan keluar dan proksi, sementara tingkah laku aplikasi cenderung terputus pada identiti, resolusi nama, dan sijil. Walaupun pemindahan berjaya, pemindahan semula hanyalah pencapaian pertama, bukan keadaan akhir. Tanpa fasa kedua, anda sering berakhir dengan "legasi yang dihoskan di awan" yang lebih mahal dan lebih sukar untuk dioperasikan.

Titik putus yang paling biasa:

• Outbound HTTPS disekat atau diubah oleh proksi pemeriksaan TLS
• Perubahan resolusi DNS (masalah split-horizon, peraturan resolver yang hilang)
• Kekurangan kebolehcapaian AD/LDAP dari VPC
• Rantaian PKI dalaman hilang atau tidak dipercayai dalam persekitaran baharu
• Titik akhir yang ditetapkan secara keras dan anggapan lama tentang laluan rangkaian tempatan

Satu langkah mitigasi yang mudah adalah untuk menguji identiti dan DNS lebih awal dengan pelancaran perintis. Jika asas-asas tersebut berfungsi, pengesahan aplikasi yang lain menjadi jauh lebih boleh diramal.

Stabilisasi pasca-peralihan: keselamatan, sandaran, pemantauan, kos

48 jam pertama selepas pemindahan harus memprioritaskan kestabilan dan kawalan. Pastikan beban kerja dapat diperhatikan, dipulihkan, dan diurus dengan selamat sebelum anda meluangkan masa untuk pengoptimuman yang lebih mendalam. Ini juga di mana pemindahan anda berjaya dalam jangka panjang, kerana operasi hari kedua yang baik mencegah hasil "kami telah memindahkannya, tetapi tiada siapa yang mahu memilikinya".

Tindakan segera selepas pemotongan:

• Sahkan pemantauan/pemberitahuan sedang aktif dan dimiliki
• Pastikan sandaran diaktifkan dan lengkapkan pengesahan pemulihan
• Ketatkan kumpulan keselamatan dan terapkan hak akses minimum IAM
• Menyelaraskan pendekatan tampalan dan akses pentadbiran (laluan yang boleh diaudit)
• Mulakan penyesuaian selepas anda mengumpul data penggunaan sebenar
• Tegaskan penandaan untuk mencegah penyimpangan kos "pemilik tidak dikenali"

Setelah kestabilan terbukti, jadwalkan ulasan pengoptimuman pendek untuk setiap pelayan yang dipindahkan. Bahkan pemeriksaan ringan pada jenis penyimpanan, pilihan keluarga instans, dan strategi kapasiti yang ditempah dapat mengurangkan kos secara material.

Di manakah TSplus sesuai selepas anda memindahkan pelayan ke AWS?

Setelah beban kerja Windows berjalan di AWS, banyak pasukan masih memerlukan cara yang mudah untuk menerbitkan aplikasi dan desktop Windows kepada pengguna tanpa membina tumpukan VDI yang berat. TSplus Remote Access menyediakan penerbitan aplikasi dan akses desktop jauh untuk pelayan Windows di AWS, di premis, atau persekitaran hibrid, dengan pentadbiran yang mudah dan pelesenan yang boleh diramalkan yang sesuai untuk operasi SMB dan pasaran pertengahan.

Kesimpulan

Memindahkan pelayan di premis ke AWS adalah paling berjaya apabila ia mengikuti buku panduan yang boleh diulang: pilih strategi migrasi yang betul, sahkan kebergantungan, salin dengan selamat, uji secara realistik, dan beralih dengan pemicu rollback yang jelas. Setelah pengeluaran stabil, alihkan fokus kepada operasi hari kedua: pengukuhan keselamatan, pengesahan sandaran, pemantauan, dan penyesuaian saiz. Ini mengubah "perpindahan" menjadi platform yang boleh dipercayai dan terkawal kos.