Penemuan lingkungan Windows

Dengan teknologi yang tersedia saat ini, seperti Layanan Migrasi Aplikasi, memindahkan Windows Server, Linux, dan sistem operasi berbasis x86 lainnya serta beban kerjanya ke AWS cukup mudah. 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 untuk migrasi skala besar yang sukses, dan Anda dapat menggunakanPenilaian Kesiapan Migrasi (MRA)untuk mengidentifikasi bidang pertimbangan yang ingin Anda fokuskan.

Arsitektur perusahaan

Semakin banyak hutang teknologi yang ada di lingkungan semakin sulit untuk bermigrasi. Organisasi 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 semakin jauh lebih sulit untuk diotomatisasi di lingkungan Windows Server daripada versi yang lebih saat ini. Lisensi juga lebih sulit untuk versi yang lebih lama dan tidak didukung.

Standardisasi dan manajemen konfigurasi

Standardisasi lingkungan adalah faktor lain yang perlu dipertimbangkan. Organisasi 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 integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) pipa.

Misalnya, ini adalah praktik terbaik untuk membangun kembali server web biasa menggunakan IAC atau CI/CD saat bermigrasi, sebagai lawan memigrasi server individual secara manual. Ini juga merupakan praktik terbaik untuk menyimpan semua data persisten dalam datastore seperti database, berbagi file, atau repositori. Jika sistem tidak dibangun kembali menggunakan IAC atau CI/CD, mereka setidaknya harus menggunakan alat manajemen konfigurasi (seperti Puppet, Chef, atau Ansible) untuk menstandarisasi 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 metadata mereka 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 CPU, jumlah memori, dan jumlah disk. Kami menyarankan Anda untuk menangkap data apa pun yang diperlukan oleh perencana gelombang untuk perencanaan atau data apa pun yang Anda rencanakan untuk digunakan sebagai bagian dari mengotomatiskan 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 atauPowerShell, memuat atau memperbarui perangkat lunak untuk AWS seperti Agen AWS Systems Manager (Agen SSM), AmazonCloudWatchagen, atau perangkat lunak pencadangan atau manajemen lain yang diperlukan untuk berjalan di 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:

• Gunakanperencanaan gelombanguntuk mengatur server menjadi gelombang sesuai dengan dependensi dan prioritas Anda.

• Gunakanperencanaan mingguan(mengarah ke cutover) untuk berkomunikasi dengan tim aplikasi dan mengidentifikasi jaringan, DNS, firewall, dan detail lainnya yang harus ditangani selama cutover.

• Gunakan rinci, hour-to-hourmerencanakan(sekitar cutover aktual) untuk menggambarkan jendela pemeliharaan cutover.

• Gunakankriteria go/no-gountuk menjelaskan dalam keadaan apa aplikasi akan dianggap dipotong ke AWS atau harus gagal kembali ke lokasi sumber.

• Gunakankegiatan pembersihansebagai tindak lanjut kegiatan yang harus diselesaikan. Kegiatan ini dapat terjadi di luar jendela pemeliharaan cutover atau setelah selesainyahipercare. Aktivitas pembersihan termasuk memverifikasi cadangan dan berbagai agen, menghapus agen Layanan Migrasi Aplikasi dari server, atau menghapus server sumber dan sumber daya terkait.

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 langsung dan mencegah kegagalan apa pun.

Tantangan migrasi dalam skala besar

Kegagalan migrasi terjadi ketika aplikasi atau aplikasi dipotong 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 dijadwal ulang.

Dependensi yang sensitif terhadap 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, sehingga 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 melakukan secara memadai.

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

Layanan bersama TI

Setelah beban kerja berada di cloud, dibutuhkan berbagai layanan untuk berfungsi dan dipelihara dengan baik dan aman. Ini termasuk zona pendaratan, perimeter jaringan dan keamanan, otentikasi, penambalan, 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:

• Aturan firewall

• Izinkan daftar

• Catatan DNS

• String koneksi

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 mungkin terjadi, 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 yang sensitif terhadap 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 langsung untuk memvalidasi bahwa aplikasi mereka berfungsi penuh dengan kinerja yang dapat diterima. Untuk menjaga jendela pemeliharaan 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 yang sensitif terhadap latensi dan item konfigurasi konektivitas. Ada beberapa alat yang tersedia di pasar untuk menemukan dependensi, sepertiLayanan Penemuan Aplikasi(agen dan alat tanpa agen) danCloudamize(alat berbasis agen).

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

• Durasi- Kami menyarankan Anda menjalankan alat penemuan cukup lama untuk menangkap peristiwa khusus aplikasi seperti puncak yang diketahui, akhir bulan, dan acara lainnya. Minimum yang disarankan adalah 30 hari.

• Aktif (berbasis agen)- Alat penemuan ketergantungan aktif sering disematkan di kernel sistem operasi dan menangkap semua transaksi. Namun, ini biasanya metode yang paling mahal dan memakan waktu.

• Pasif (tanpa agen)- Alat penemuan dependensi pasif jauh lebih murah dan lebih cepat untuk diterapkan tetapi berisiko kehilangan beberapa koneksi yang digunakan lebih rendah.

• Pengetahuan kelembagaan- Meskipun alat penemuan aplikasi memberikan informasi yang lebih rinci dan akurat, sebagian besar organisasi mengandalkan tim aplikasi mereka dan pengetahuan kelembagaan mereka untuk menemukan dependensi aplikasi. Tim aplikasi sering memiliki pengetahuan tentang dependensi yang sensitif terhadap latensi, tetapi tidak jarang mereka melewatkan beberapa detail seperti pengaturan konfigurasi konektivitas, aturan firewall, atau mengizinkan persyaratan daftar dari mitra. Anda dapat menggunakan pengetahuan kelembagaan untuk meningkatkan penemuan ketergantungan aplikasi Anda, tetapi kami menyarankan Anda juga mempertimbangkan dan mengurangi risiko yang terlibat. Misalnya, ada risiko kehilangan item konfigurasi konektivitas atau dependensi yang sensitif terhadap latensi jika Anda hanya bergantung pada pengetahuan tim aplikasi Anda. Hal ini dapat mengakibatkan pemadaman atau migrasi gagal. Untuk mengurangi risiko ini, kami sarankan Anda melakukan pengujian fungsional aplikasi terperinci.