Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Merencanakan migrasi
Merencanakan proses migrasi Anda adalah kunci untuk memastikan migrasi yang lancar dan sukses. Bagian berikut menguraikan cara merencanakan migrasi Anda, serta pertimbangan utama untuk itu.
**Topics**
+ [Memutuskan apa yang akan dimigrasikan](migration-decision-process.md)
+ [Membersihkan konfigurasi Anda](descale-configurations.md)
+ [Memilih jenis instans](instance-choice.md)
+ [Poin keputusan utama](key-decision-points.md)
+ [Ikhtisar migrasi tingkat tinggi](high-level-migration-overview.md)
# Memutuskan apa yang akan dimigrasikan
Saat Anda bermigrasi, Anda harus memutuskan beban kerja mana yang penting; beban kerja mana yang “bagus untuk dimiliki” tetapi tidak penting; dan beban kerja mana yang tidak diperlukan dan dapat [dihentikan setelah](https://docs.aws.amazon.com//prescriptive-guidance/latest/migration-retiring-applications/welcome.html) migrasi selesai.
Bagian penting dari proses pengambilan keputusan Anda akan melibatkan persyaratan individu yang Anda miliki untuk otomatisasi, API, perkakas, dan proses lainnya. Anda juga perlu mempertimbangkan persyaratan fungsional dan kinerja organisasi Anda.
Misalnya, Anda mungkin telah menggunakan platform perangkat keras bersama di pusat data yang ada dengan partisi pengguna. Namun, migrasi Anda mungkin mengharuskan layanan berjalan pada sistem yang tidak dibagikan secara luas karena keterbatasan kinerja perpindahan dari solusi yang dipercepat perangkat keras. Misalnya, transaksi Secure Sockets Layer (SSL) per detik (TPS) dapat mengharuskan layanan tertentu tidak berjalan pada sistem bersama.
Setelah Anda mengidentifikasi dan mendokumentasikan aplikasi mana yang akan bermigrasi dan persyaratannya, Anda perlu menyiapkan sistem sumber Anda dengan menggunakan praktik terbaik berikut.
+ Jalankan versi F5 TMOS yang sama yang akan Anda jalankan di Cloud. AWS [Versi 14.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-14-1-0.html) atau yang lebih baru direkomendasikan, tetapi [versi 13.1](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-ve-13-1-0.html) atau yang lebih baru juga dapat digunakan. Meskipun Anda dapat memigrasikan versi [12.1.x](https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-bigip-12-1-5.html), Anda mungkin mengalami masalah keamanan, otomatisasi, dan pemeliharaan.
+ Memiliki cadangan yang valid dari semua konfigurasi dari setiap perangkat. Karena cadangan Univention Corporate Server (UCS) berisi atribut dan objek yang khusus untuk pusat data (seperti alamat IP, node, atau anggota kumpulan), F5 merekomendasikan agar Anda membuat file perintah shell (SCF) untuk mengedit dan menggabungkan konfigurasi.
+ Miliki cadangan semua sertifikat keamanan yang relevan, dan pertimbangkan untuk mengubah dari enkripsi RSA ke ECC untuk kinerja yang lebih baik.
+ Memiliki metrik kinerja terperinci di tingkat server virtual untuk penskalaan dan perencanaan kapasitas.
+ Miliki solusi [F5 Global Server Load Balancing (GSLB)](https://www.f5.com/solutions/use-cases/global-server-load-balancing-gslb) untuk cutover dari pusat data ke Cloud. AWS
+ Memahami dampak migrasi dari model perangkat keras ke perangkat lunak dan model virtual dalam hal kinerja, skalabilitas, dan ketersediaan tinggi.
+ Memiliki persyaratan yang ditentukan tentang apa yang akan dimigrasikan ke AWS Cloud, dan perhatikan pertimbangan berikut.
+ Ketahuilah bahwa setiap migrasi ke AWS Cloud memerlukan keputusan tentang apakah seluruh atau sebagian konfigurasi akan dimigrasikan. Biasanya, satu gerakan sebagian pada satu waktu lebih efisien.
+ Pahami rute dan alamat IP mana yang akan berubah.
+ Identifikasi kolam SNAT mana yang harus diganti dengan F5 SNAT Automap.
Anda juga harus mempertimbangkan konsultasi [AWS Mitra](https://partners.amazonaws.com/partners/001E000000Rl12PIAR/F5%20Networks) atau tim Layanan Profesional F5. Ini akan membantu memastikan probabilitas tinggi migrasi yang berhasil.
# Membersihkan konfigurasi Anda
“Descale” berarti memindahkan konfigurasi F5 BIG-IP ke konfigurasi yang lebih rendah atau lebih hemat biaya, berdasarkan fitur atau metrik yang diperlukan setelah temuan penemuan awal Anda. Anda harus hati-hati mengevaluasi semua opsi ini karena mereka akan mempengaruhi arsitektur dan jumlah contoh yang diperlukan.
Diagram berikut membantu Anda menilai apakah pembersihan kerak sesuai dengan kebutuhan dan persyaratan Anda.
![\[Process flow for descaling a configuration.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-descale.png)
Migrasi juga akan menciptakan pertimbangan baru di bidang-bidang berikut.
+ **Topologi jaringan** — saat ini AWS tidak mendukung `802.1q ` tagged VLANs, sehingga jumlah antarmuka instance (minus satu untuk manajemen) menyajikan batas jumlah jaringan yang dapat didukung oleh instance. Jika Anda memerlukan topologi tertentu, Anda perlu mengevaluasinya dibandingkan dengan contoh lain yang didukung F5 di Cloud. AWS
+ **Kinerja SSL** — Peralatan dan sasis F5 memiliki kinerja SSL yang melebihi apa yang dapat dicapai. `x86` Anda harus mengevaluasi persyaratan SSL server agregat dan per-virtual.
+ **Kinerja jaringan** — Anda harus mengevaluasi karakteristik jaringan agregat, keluar, dan internal. AWS tipe instance memiliki karakteristik jaringan yang berbeda (rendah, sedang, tinggi, hingga X, atau khusus) yang harus dipertimbangkan. Ada juga batasan berapa banyak lalu lintas yang dapat dikirim oleh satu instance keluar atau melintasi koneksi langsung.
+ **Kepadatan VIP** — Jika Anda memiliki jumlah alamat IP virtual yang lebih besar (VIPs), Anda harus mempertimbangkan batas instance untuk jumlah VIPs yang dapat dipetakan ke antarmuka jaringan.
+ **Koneksi bersamaan** — Ada batas aliran ke jumlah maksimum koneksi yang dapat didukung oleh instans.
+ **Status sesi** — Aplikasi yang berbeda menggunakan berbagai jenis persistensi. Aplikasi stateful dan stateless akan mengubah metode yang digunakan untuk status bersama, dan ini dapat memengaruhi skala untuk operasi. in/out
# Memilih jenis instans
F5 mendukung beberapa jenis instance dan memilih mana yang akan digunakan dapat menjadi keputusan yang kompleks. Untuk sebagian besar migrasi, `c5n.2xl` dan `c5n.4xl` akan menjadi pilihan contoh yang paling umum karena mereka menawarkan campuran kinerja jaringan, kepadatan CPU, kepadatan antarmuka, dan jumlah IPs yang dapat didukung pada instance. Diagram berikut memberikan contoh contoh mana yang harus dipilih, berdasarkan produk F5 yang Anda gunakan.
![\[Process flow for choosing which instance type to use.\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-instance-choice.png)
# Poin keputusan utama
Ada banyak aspek migrasi yang perlu dipertimbangkan, tetapi sebelum memulai migrasi beban kerja F5 BIG-IP Anda, tanyakan pada diri Anda pertanyaan-pertanyaan berikut untuk memperjelas proses migrasi.
**Siapa pengguna aplikasi Anda?**
Menilai apakah ini adalah pengguna internal (tidak melintasi alamat IP Elastis) atau pengguna eksternal (melintasi alamat IP Elastis). Jika pengguna internal, evaluasi apakah aplikasi dapat menggunakan DNS untuk mengakomodasi kegagalan Availability Zone atau penerapan aktif. Anda juga harus memverifikasi apakah Anda perlu menggunakan pola desain alternatif yang memungkinkan subnet menjangkau beberapa Availability Zone.
**Bagian mana dari aplikasi Anda yang akan bermigrasi ke AWS Cloud?**
Menilai apakah seluruh aplikasi bergerak atau hanya tingkat presentasi. Anda juga harus mempertimbangkan dependensi tambahan seputar keamanan dan namespace DNS. Evaluasi Anda perlu menentukan apa yang diperlukan dari topologi jaringan. Selain itu, tentukan apa yang diperlukan dari perjanjian tingkat layanan (SLA) jika suatu peristiwa terjadi di tingkat Availability Zone, VPC, atau Region. AWS
**Mengapa aplikasi bermigrasi?**
Anda mungkin memigrasikan aplikasi Anda karena Anda menutup pusat data atau karena Anda ingin lebih elastisitas. Menilai apakah aplikasi bermigrasi untuk memiliki arsitektur per aplikasi, dibandingkan dengan pola monolitik bersama yang umum di banyak pusat data. Perlu juga mempertimbangkan upaya modernisasi apa yang harus dilakukan bersama dengan migrasi.
**Ke mana aplikasi bermigrasi?**
Nilai apakah aplikasi perlu pindah ke satu VPC dengan satu Availability Zone atau dua Availability Zone. Tentukan topologi VPC peer atau transit, bersama dengan kebutuhan untuk penyebaran Multi-wilayah. Ini akan berdampak pada desain pola migrasi.
# Ikhtisar migrasi tingkat tinggi
Sebelum Anda memulai migrasi, ada baiknya untuk menjabarkan seluruh proses dari tingkat tinggi. Berikut ini adalah contoh langkah-langkah yang mungkin Anda ambil untuk memigrasikan beban kerja F5 BIG-IP ke Cloud. AWS Langkah-langkah dan proses yang lebih rinci untuk migrasi F5 BIG-IP dapat ditemukan dalam pola [Migrasikan beban kerja F5 BIG-IP ke F5 BIG-IP VE](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-f5-big-ip-workload-to-f5-big-ip-ve-on-the-aws-cloud.html?did=pg_card&trk=pg_card) di Cloud. AWS
1. Terapkan jumlah yang diperlukan VPCs berdasarkan kebutuhan pribadi Anda. Ini bisa manual atau otomatis melalui alat seperti [AWS Landing Zone](https://aws.amazon.com//solutions/implementations/aws-landing-zone/).
1. Evaluasi lisensi, pemanfaatan, dan konfigurasi F5 saat ini.
1. Mengevaluasi aplikasi publik dan internal.
1. Evaluasi konfigurasi F5 saat ini.
1. Evaluasi ukuran dan persyaratan alamat IP, dan pilih nomor dan jenis F5 dan AWS instance yang diperlukan.
1. Identifikasi strategi migrasi mana yang akan diterapkan. Misalnya, angkat dan geser; angkat, geser dan modernisasi; atau hibrida.
1. Mengevaluasi dan mengidentifikasi desain DNS.
1. Evaluasi bagaimana lalu lintas akan diarahkan ke aplikasi jika ada baik di tempat maupun di AWS Cloud.
1. Lakukan penerapan awal instance F5 dengan menggunakan template. AWS CloudFormation
1. Ubah penerapan untuk memenuhi persyaratan topologi dengan antarmuka jaringan elastis tambahan dan tabel rute.
1. Sejajarkan alamat IP Elastis ke mandiri IPs atau manajemen IPs, dan rencanakan pemetaan IP Elastis ke IP virtual (VIP).
1. Buat alamat sekunder pada antarmuka jaringan elastis untuk VIPs.
1. Terapkan alamat sekunder di AWS Cloud.
1. Petakan alamat IP Elastis ke alamat sekunder untuk VIPs.
1. Tarik konfigurasi dan kompilasi daftar objek untuk dipindahkan.
1. Menyebarkan konfigurasi ke F5 BIG-IP.
1. Petakan alamat sekunder ke VIPs.
1. Uji lalu lintas.
1. Uji failover.
1. Jika Anda membangun hibrida, pastikan Anda memasukkan sistem ke dalam DNS F5.
**penting**
Akses ke titik akhir AWS API diperlukan. Alamat IP NAT atau Elastis juga diperlukan untuk ketersediaan tinggi di dalam atau di antara Availability Zones.
Diagram berikut menunjukkan aliran proses tingkat tinggi untuk migrasi F5 BIG-IP.
![\[High-level process flow for an F5 BIG-IP migration\]](http://docs.aws.amazon.com/id_id/prescriptive-guidance/latest/migration-f5-big-ip/images/F5-high-level.png)