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

Penemuan lingkungan Windows

Dengan teknologi yang tersedia saat ini, seperti AWS Application Migration Service, memindahkan Windows Server, Linux, dan sistem operasi berbasis x86 lainnya dan beban kerjanya cukup mudah AWS . Namun, membuat beban kerja tersebut berfungsi dengan baik dan melakukannya dalam skala besar, menghadirkan serangkaian tantangan yang berbeda. Bagian ini dimaksudkan untuk mengidentifikasi pertimbangan migrasi yang memungkinkan Anda memigrasikan beban kerja Microsoft dengan cepat, aman, dan lancar.

Menilai

Meskipun Anda dapat “brute force” migrasi yang lebih kecil (seperti yang melibatkan 100 server) dengan perencanaan dan otomatisasi minimal, Anda tidak dapat memindahkan 500 atau lebih server dengan menggunakan metodologi ini. Pertimbangan berikut adalah kontributor utama keberhasilan migrasi skala besar, dan Anda dapat menggunakan Penilaian Kesiapan Migrasi (MRA) untuk mengidentifikasi area pertimbangan yang ingin Anda fokuskan.

Arsitektur perusahaan

Semakin banyak hutang teknologi di lingkungan, semakin sulit untuk bermigrasi. Organizations yang memiliki program arsitektur perusahaan yang sehat berusaha untuk membatasi lingkungan mereka ke versi perangkat lunak dan sistem saat ini dan terbaru (sering disebut versi N dan N -1 dari rilis utama). Ini tidak hanya mengurangi jumlah skenario yang harus Anda perhitungkan, tetapi juga memanfaatkan kemajuan rilis yang lebih baru. Misalnya, Windows Server 2012, Windows Server 2008, dan versi Windows Server yang lebih lama secara progresif jauh lebih sulit untuk diotomatisasi di lingkungan Windows Server daripada versi yang lebih baru. Lisensi juga lebih sulit untuk versi yang lebih lama dan tidak didukung.

Standardisasi dan manajemen konfigurasi

Standardisasi lingkungan adalah faktor lain yang perlu dipertimbangkan. Organizations yang memiliki lingkungan yang dibangun dengan tangan dan dipelihara dianggap lebih seperti hewan peliharaan. Setiap sistem unik dan ada kombinasi konfigurasi yang jauh lebih mungkin daripada jika mereka dibangun menggunakan gambar standar, infrastruktur sebagai kode (IAc), atau pipeline integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD).

Misalnya, ini adalah praktik terbaik untuk membangun kembali server web biasa menggunakan IAC atauCI/CD when migrating, as opposed to manually migrating the individual server. It's also a best practice to store all persistent data in a datastore such as a database, file share, or repository. If systems aren't rebuilt using IaC or CI/CD, mereka setidaknya harus menggunakan alat manajemen konfigurasi (seperti Puppet, Chef, atau Ansible) untuk membakukan server yang mereka miliki.

Data yang bagus

Data yang baik juga merupakan faktor kunci untuk migrasi yang sukses. Data yang akurat mengenai server saat ini dan metadatanya sangat penting untuk otomatisasi dan perencanaan. Kurangnya data yang baik meningkatkan kesulitan saat merencanakan migrasi. Contoh data yang baik termasuk inventaris server yang akurat, aplikasi di server, perangkat lunak pada server dengan versi, jumlah CPUs, jumlah memori, dan jumlah disk. Sebaiknya Anda menangkap data apa pun yang diperlukan oleh perencana gelombang untuk perencanaan atau data apa pun yang Anda rencanakan untuk digunakan sebagai bagian dari otomatisasi proses migrasi.

Otomatisasi

Otomatisasi sangat penting untuk migrasi dalam skala besar. Contoh otomatisasi termasuk menginstal agen, memperbarui versi perangkat lunak utilitas yang diperlukan untuk otomatisasi seperti .NET atau PowerShell, memuat atau memperbarui perangkat lunak AWS seperti AWS Systems Manager Agen (Agen SSM), CloudWatch agen Amazon, atau perangkat lunak cadangan atau manajemen lain yang diperlukan untuk menjalankannya. AWS

Perencanaan terperinci

Mengembangkan dan mengelola rencana terperinci juga penting untuk migrasi dalam skala besar. Anda harus memiliki rencana yang terdefinisi dengan baik untuk memigrasi 50 server seminggu selama berminggu-minggu. Rencana yang efektif meliputi yang berikut:

Memobilisasi

Selama fase mobilisasi, penting untuk menemukan sebanyak mungkin kompleksitas dan variasi organisasi Anda sehingga dapat dipertanggungjawabkan selama perencanaan migrasi. Idealnya, Anda dapat menghindari berurusan dengan kompleksitas dan variasi seperti itu selama jendela pemeliharaan cutover dan mencegah kegagalan.

Tantangan migrasi dalam skala

Kegagalan migrasi terjadi ketika aplikasi atau aplikasi telah dipindahkan ke lingkungan baru mereka dan kinerja atau persyaratan fungsional tidak dapat dipenuhi dalam jendela pemeliharaan migrasi. Ini memaksa aplikasi atau aplikasi gagal kembali ke lokasi semula. Selain itu, semua aplikasi lain yang bergantung pada aplikasi atau aplikasi itu juga perlu gagal kembali. Migrasi yang gagal cenderung berdampak tidak hanya pada gelombang saat ini tetapi gelombang masa depan karena aplikasi harus dijadwalkan ulang.

Dependensi sensitif latensi

Alasan utama migrasi gagal adalah dependensi yang sensitif terhadap latensi. Gagal mengidentifikasi dependensi yang sensitif terhadap latensi dapat menimbulkan masalah kinerja yang mengakibatkan waktu respons atau waktu transaksi yang tidak dapat diterima.

Misalnya, biasanya aplikasi memindahkan database dan server aplikasinya ke cloud pada saat yang sama karena mereka sering berkomunikasi satu sama lain dan membutuhkan waktu respons sub-milidetik yang mereka miliki ketika keduanya berada di pusat data yang sama. Memindahkan hanya database ke cloud kemungkinan akan memperkenalkan latensi beberapa detik ke dalam transaksi tersebut, menghasilkan dampak kinerja yang signifikan terhadap aplikasi. Ini juga berlaku untuk aplikasi yang sangat bergantung satu sama lain dan harus berada di pusat data yang sama untuk bekerja secara memadai.

Oleh karena itu, memahami dan menangani dependensi aplikasi sangat penting ketika merencanakan migrasi. Aplikasi dan layanan yang bergantung satu sama lain harus diidentifikasi sehingga dapat dimigrasikan bersama.

Layanan bersama TI

Setelah beban kerja berada di cloud, dibutuhkan berbagai layanan agar berfungsi dan dipelihara dengan baik dan aman. Ini termasuk landing zone, perimeter jaringan dan keamanan, otentikasi, patching, pemindai keamanan, alat manajemen layanan TI, cadangan, host benteng, dan sumber daya lainnya. Tanpa layanan ini, beban kerja mungkin tidak beroperasi dengan baik dan akan dipaksa untuk gagal kembali ke lokasi semula.

Pembaruan konfigurasi

Dalam kebanyakan kasus, Anda harus membuat beberapa perubahan konfigurasi agar beban kerja berfungsi dengan baik setelah beban kerja dipindahkan ke cloud. Perubahan konfigurasi ini sering dikaitkan dengan dependensi beban kerja berikut:

Jika Anda tidak membuat pembaruan konfigurasi yang tepat, maka beban kerja, penggunanya, dan sistem dependennya mungkin gagal berkomunikasi satu sama lain. Menyelesaikan masalah ini dalam jendela pemadaman dapat dimungkinkan, tetapi perubahan saat ini dapat memakan waktu atau memerlukan catatan perubahan yang tidak dapat dipenuhi tepat waktu.

Pengujian fungsional aplikasi

Tantangan lain untuk migrasi dalam skala besar adalah perlunya pengujian fungsional aplikasi. Ini sangat penting karena banyak organisasi mengandalkan tim aplikasi untuk mengidentifikasi dependensi sensitif latensi, layanan bersama TI, atau pembaruan konfigurasi yang diperlukan. Idealnya, tim aplikasi menyediakan rencana pengujian tertulis atau otomatis yang dapat mereka jalankan selama jendela pemeliharaan cutover untuk memvalidasi bahwa aplikasi mereka berfungsi penuh dengan kinerja yang dapat diterima. Untuk menjaga jendela perawatan cutover seminimal mungkin, pengujian harus dapat diselesaikan dalam waktu 30 menit.

Alat untuk penemuan ketergantungan aplikasi

Menentukan dependensi antar aplikasi sangat penting untuk migrasi yang berhasil—baik untuk mendeteksi dependensi sensitif latensi maupun item konfigurasi konektivitas. Ada beberapa alat yang tersedia di pasar untuk menemukan dependensi, seperti AWS Application Discovery Service(agen dan alat tanpa agen) dan Cloudamize (alat berbasis agen).

Saat Anda memilih alat untuk penemuan ketergantungan aplikasi, pertimbangkan hal berikut: