Migrasi dengan Layanan Migrasi Aplikasi AWS - AWS Panduan Preskriptif
KeuntunganKekuranganSkenario paling cocok

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Migrasi dengan Layanan Migrasi Aplikasi AWS

Sebagian besar lift-and-shift migrasi besar untuk AWS digunakan AWS Application Migration Service. Layanan ini bekerja pada tingkat fisik dengan memindahkan data yang disimpan pada perangkat penyimpanan blok yang terpasang langsung (seperti hard drive atau drive SAN) ke perangkat penyimpanan Amazon Elastic Block Store (Amazon EBS) yang sesuai. AWS Ini pada dasarnya menerapkan backup/restore prosedur tradisional (dengan mengkloning hard drive), tetapi juga menyediakan tujuan titik pemulihan (RPO) mendekati detik dan tujuan waktu pemulihan (RTO) menit dengan mencapai mode sinkronisasi perlindungan data berkelanjutan (CDP) antara sistem sumber dan perangkat penyimpanan target di area pementasan.

Metode replikasi tingkat blok ini tidak mendukung penyimpanan terpasang jaringan (NAS), drive bersama seperti berbagi Sistem File Jaringan (NFS), atau berbagi Common Internet File System (CIFS) /Server Message Block (SMB). Ini hanya mendukung penyimpanan tingkat blok yang terhubung langsung ke sistem yang dimigrasi pada saat migrasi. (Untuk informasi selengkapnya, lihat FAQ Layanan Migrasi Aplikasi tentang dukungan SAN/NAS.) Ini membatasi penerapan replikasi melalui Layanan Migrasi Aplikasi untuk sebagian besar sistem yang dikelompokkan, karena sebagian besar cluster bergantung pada penyimpanan bersama dari berbagai implementasi. Untuk informasi selengkapnya, lihat bagian Keuntungan dan Kerugian di halaman ini.

Metode replikasi tingkat blok mengharuskan Anda menginstal Agen AWS Replikasi di tingkat sistem operasi (OS), dan agen tersebut hanya mendukung platform x86 yang didasarkan pada sistem operasi Windows atau Linux (lihat Sistem operasi yang didukung oleh Layanan Migrasi Aplikasi). Platform non-X86 berada di luar cakupan metode migrasi ini. Ini termasuk ARM, RISC/CISC sistem, variasi PowerPC, sistem IBM seperti PSeries, iSeries, ZSeries, dan sistem operasi masing-masing seperti AIX, HP-UX, Solaris, Linux untuk PowerPC, ZLinux pada mainframe, dan arsitektur non-x86 lainnya.

Agen AWS Replikasi bekerja pada tingkat driver perangkat sistem file virtual* di tumpukan OS, menangkap blok data apa pun yang akan ditulis ke perangkat tingkat blok yang mendasarinya (termasuk drive, hard drive, dan perangkat SAN yang terpasang langsung), seperti yang dijelaskan pada halaman FAQ Layanan Migrasi Aplikasi di bawah pertanyaan ini:

* Lihat definisi sistem file, sistem file virtual, dan driver perangkat di Wikipedia.

Keuntungan

Untuk lift-and-shift migrasi dalam skala apa pun, Layanan Migrasi Aplikasi memiliki banyak manfaat:

  • Replikasi mudah diatur (tidak memerlukan kurva belajar yang curam).

  • Ini cepat untuk skala, dengan meluncurkan agen pada mesin sumber.

  • Anda dapat menggunakan Cloud Migration Factory untuk mengotomatiskan sebagian besar tugas manual, mengelola beberapa mesin, dan mengatur gelombang migrasi.

  • Ini mendukung berbagai arsitektur sistem operasi x86.

  • Ini mendukung semua jenis lingkungan sumber (pusat data lokal, cloud lainnya, atau lainnya Wilayah AWS).

  • Ini aplikasi-agnostik, sehingga mendukung aplikasi apa pun yang berjalan di server sumber.

  • Tidak diperlukan lisensi atau pembelian. AWS menawarkan pay-as-you-go harga, sehingga Anda membayar untuk layanan hanya selama Anda menggunakannya, tanpa kontrak jangka panjang atau lisensi yang rumit. Layanan Migrasi Aplikasi menyediakan periode 90 hari gratis per server, yang cukup untuk sebagian besar migrasi. Untuk detailnya, lihat AWS Application Migration Service harga di AWS situs web.

Kekurangan

Saat Anda menggunakan alat replikasi tingkat blok seperti Layanan Migrasi Aplikasi, Anda mungkin menemukan kasus sudut dan faktor berikut yang perlu dipertimbangkan:

  • Layanan Migrasi Aplikasi tidak mendukung sistem file bersama yang dipasang atau perangkat penyimpanan bersama seperti NAS, termasuk CIFS/SMB dan sistem file NFS. Untuk informasi selengkapnya tentang metode replikasi untuk NAS atau sistem file bersama, lihat agen replikasi MGN untuk memigrasi NFS Share (artikel AWS re:Post) dan Migrasi sistem file bersama dalam migrasi besar (Pola Panduan Preskriptif). AWS AWS

  • Layanan Migrasi Aplikasi tidak mendukung sebagian besar server file berkerumun atau konfigurasi cluster database dengan penyimpanan bersama karena keterbatasan bagaimana penyimpanan bersama tersebut direpresentasikan ke tingkat OS melalui lapisan driver perangkat. Misalnya, cluster Microsoft SQL Server dengan opsi Storage Space Direct (S2D) tidak didukung. Namun, Anda masih dapat menggunakan Layanan Migrasi Aplikasi untuk mereplikasi jenis sistem berkerumun lainnya dengan penyimpanan blok bersama, seperti penyimpanan bersama dalam konfigurasi Failover Cluster Instance (FCI) di Windows Server Failover Cluster (WSFC), seperti yang dijelaskan dalam posting blog Memigrasi cluster Microsoft Windows Anda untuk AWS menggunakan Migrasi, penyimpanan yang diekspos dari array SAN eksternal (koneksi iSCSI) CloudEndure, dan beberapa Microsoft SQL Server Selalu Aktif kelompok ketersediaan (AAG) cluster dalam kasus sudut tertentu. Secara umum, Layanan Migrasi Aplikasi mendukung replikasi perangkat tingkat blok dari server tempat perangkat penyimpanan sepenuhnya hadir di server selama migrasi. (Agen AWS Replikasi harus diinstal pada server, dan perangkat harus terlihat oleh agen untuk replikasi.) Namun, semua skenario ini memerlukan prosedur yang sangat spesifik dan menghasilkan jendela cutover yang lebih panjang. 

  • Sistem yang memiliki tingkat perubahan data yang tinggi (seperti database OLTP) mungkin memiliki kinerja atau persyaratan jaringan yang lebih tinggi, yang mempersulit upaya migrasi.

  • Bandwidth jaringan harus cukup untuk jumlah data yang akan ditransfer dalam migrasi yang direncanakan dan jendela waktu cutover. Ini karena Layanan Migrasi Aplikasi tidak menyediakan opsi pengiriman offline, tidak seperti AWS Snowball. 

  • Migrasi membutuhkan jendela downtime kecil, dalam RTO beberapa menit. Layanan Migrasi Aplikasi menggunakan snapshot EBS sebagai bagian dari proses migrasi, dan disk EBS baru yang dibuat dari snapshot tersebut awalnya memiliki kinerja yang lebih buruk. Dengan beberapa pola baca database, ini mungkin meningkatkan jendela cutover efektif hingga database yang dimigrasi berada pada kinerja penuh. 

Skenario paling cocok

Layanan Migrasi Aplikasi mencakup hampir semua lift-and-shift migrasi sepenuhnya, dengan sedikit kelemahan, seperti yang dibahas dalam dua bagian sebelumnya. Alat ini dapat menangani sebagian besar kasus sudut, seperti kluster basis data, selama jendela cutover yang lebih panjang yang diperlukan untuk sistem ini memenuhi persyaratan migrasi Anda. 

Bagian berikut mencakup dua skenario secara lebih mendalam:

  • Migrasi skala besar dengan beberapa gelombang migrasi

  • Migrasi aplikasi tunggal yang membutuhkan waktu henti minimal 

Migrasi skala besar dengan beberapa gelombang migrasi

Contoh migrasi skala besar adalah pintu keluar pusat data yang ditandai dengan persyaratan ukuran dan kecepatan. Ini juga biasanya melibatkan batasan waktu tertentu, seperti akhir kontrak sewa untuk pusat data. Dalam hal ini, skala menentukan pendekatan. Gelombang migrasi ditentukan dan dikelompokkan berdasarkan aplikasi, termasuk database, dan setiap gelombang memiliki persiapan yang direncanakan, migrasi, dan fase pemotongan akhir dengan persyaratan waktu henti tertentu. 

Di dalam setiap gelombang migrasi, server database sebaiknya dipindahkan dalam skala besar dengan menggunakan replikasi tingkat blok Layanan Migrasi Aplikasi, kecuali untuk beberapa pengecualian untuk kasus khusus berikut yang mungkin memerlukan pendekatan migrasi terpisah:

  • Sebagian besar sistem basis data berkerumun

  • Sistem database di mana tingkat perubahan melebihi throughput jaringan yang tersedia (yang dapat mengakibatkan kelambatan replikasi) 

Untuk setiap kasus khusus, pertimbangkan tradeoff antara persyaratan downtime Anda dan tingkat upaya yang terlibat dalam menggunakan alat migrasi lain. Dalam beberapa kasus, jauh lebih mudah untuk menggunakan pendekatan migrasi yang sama untuk semua sistem daripada menggunakan alat terpisah dan membuat proses yang berbeda untuk sistem tertentu. Jika Layanan Migrasi Aplikasi tidak mendukung persyaratan waktu henti untuk sistem tertentu, sebaiknya gunakan salah satu metode yang dijelaskan di bagian Migrasi dengan alat database asli.

Migrasi aplikasi tunggal

Skenario aplikasi tunggal mewakili pendekatan terperinci untuk memigrasikan satu aplikasi bisnis penting yang memerlukan waktu henti minimum atau mendekati nol selama migrasi, atau beberapa aplikasi semacam itu. Ruang lingkup migrasi dapat bervariasi, tergantung pada kekritisan bisnis dan persyaratan waktu henti, berbeda dengan persyaratan kecepatan dan skala skenario sebelumnya (migrasi skala besar). Jika aplikasi memungkinkan downtime dalam RTO Layanan Migrasi Aplikasi, itu harus ditangani dengan cara yang sama seperti migrasi skala besar yang dijelaskan sebelumnya. 

Namun, dalam kasus di mana waktu cutover harus sedekat mungkin dengan minimum ― misalnya, ketika database yang dimigrasi memiliki pola baca yang memerlukan waktu lama untuk beroperasi pada kinerja penuh dan jendela cutover harus tetap kecil ― Anda harus mempertimbangkan pendekatan yang lebih rinci dan terperinci. Secara umum, pendekatan itu melibatkan langkah-langkah dan persyaratan tambahan, yang membutuhkan lebih banyak usaha dan waktu. Salah satu langkahnya adalah memisahkan migrasi database dari migrasi server aplikasi dan menggunakan alat migrasi database yang dijelaskan di bagian berikutnya untuk menjaga sumber dan database target tetap sinkron. Anda dapat menggunakan berbagai metode untuk mencapai sinkronisasi. Setiap metode memiliki kelebihan dan kekurangan, dan melibatkan pengorbanan yang berbeda antara jumlah downtime dan kompleksitas sinkronisasi. Namun demikian, menjaga database tetap sinkron antara lingkungan sumber dan target memungkinkan Anda untuk memutuskan tautan lapisan database dari lapisan aplikasi. Dengan asumsi bahwa server aplikasi tidak menyimpan data persisten secara lokal tetapi meneruskan semuanya ke lapisan database, sinkronisasi juga menghilangkan batasan waktu henti dari lapisan aplikasi. 

Memisahkan basis data dan lapisan aplikasi memungkinkan Anda untuk memigrasi server aplikasi dengan menggunakan Layanan Migrasi Aplikasi seperti pada skenario sebelumnya. Server aplikasi target dapat dimulai di lingkungan target sementara sistem sumber masih bekerja, memproses data, dan menyimpannya di lapisan database. Karena lapisan database sudah sinkron dengan target, waktu cutover minimal―itu hanya melibatkan switching jaringan dan mengarahkan permintaan pelanggan dari sistem sumber lama ke lingkungan target. Anda dapat menggunakan beberapa metode untuk melakukannya, mengikuti panduan untuk penerapan biru/hijau, biasanya dengan mengalihkan titik akhir DNS, menggunakan zona DNS tertimbang, menggunakan AWS Global Acceleratoruntuk mengurangi penundaan propagasi DNS Time to Live (TTL), dan metode serupa.