Linux telah ada selama beberapa waktu sekarang. Awalnya dibuat oleh Linus Torvalds pada tahun 1991, ia telah berkembang menjadi pemain utama dalam lanskap sistem operasi server (OS), bersama Windows dan distribusi Unix utama. Meskipun pada dasarnya tidak ada yang salah dengan Unix, Unix sudah agak "lama di gigi", dan ada tren yang berkembang untuk bermigrasi dari Unix ke Linux.
Jadi mengapa bermigrasi?
Jika Anda adalah administrator dari pusat data yang ada (baik di tempat atau di fasilitas lokasi bersama), terutama yang telah ada sejak lama, kemungkinan besar Anda memiliki cita rasa komersial menjalankan Unix. Ini biasanya memerlukan perangkat keras berpemilik, dan meskipun ini mungkin berjalan tanpa masalah, ada tantangan untuk mempertahankan lingkungan warisan tersebut. Tantangan terbesar yang mungkin dilihat oleh manajemen tingkat atas adalah biaya dukungan untuk perangkat keras dan OS itu sendiri. Selain itu, ekspansi bisa semakin sulit dilakukan, karena perangkat keras lama sudah usang dan suku cadangnya sulit ditemukan dan, ketika ditemukan, bisa mahal (oh, penawaran dan permintaan, Anda adalah nyonya yang kejam!).
Sesuatu yang dapat muncul selama transisi ini adalah kemungkinan Anda menemukan aplikasi yang tidak dapat dimigrasikan. Mungkin vendornya gulung tikar atau belum mem-porting aplikasi ke Linux. Mungkin mereka punya, tapi itu akan membutuhkan keterlibatan vendor langsung dalam keterlibatan profesional yang membawa biaya terlalu tinggi. Jika ini muncul, Anda mungkin harus melihat apakah Anda dapat memigrasikan beban kerja ke aplikasi baru yang didukung di Linux atau melihat harus mempertahankan server lama tertentu.
Masalah lain dengan tetap menggunakan sistem Unix lama adalah ketidakmampuan untuk melakukan virtualisasi. Meskipun ada beberapa virtualisasi di beberapa lingkungan Unix, hypervisor modern menyediakan lebih banyak fungsionalitas dan fleksibilitas, jika Anda dapat pindah ke OS yang didukung oleh hypervisor pilihan Anda.
Oke, jadi saya akan bermigrasi, bagaimana cara memulainya?
Keberhasilan migrasi dari Unix ke Linux akan dimulai dengan penyelidikan yang solid. Ada beberapa hal yang menjadi fokus. Ada dua cara untuk mendekati ini, dan saya telah menemukan hibrida dari keduanya dapat menghasilkan hasil terbaik. Dua pendekatan, seperti yang saya lihat, adalah "bottom up" dan "top down". Frasa ini umum dan cukup mudah diterapkan di sini.
Untuk pendekatan bottom-up, Anda mulai dari level OS. Mulailah dengan memeriksa OS dan versi saat ini. Identifikasi paket, modul, atau perangkat lunak tambahan yang diinstal dari vendor OS. Selanjutnya, periksa perangkat lunak pihak ketiga, tangkap vendor dan versi yang Anda jalankan. Hal terakhir adalah perangkat lunak buatan sendiri yang mungkin Anda miliki, termasuk tidak hanya program yang ditulis dalam bahasa formal seperti C (atau turunannya) atau Java , tetapi juga skrip yang ditulis dalam salah satu bahasa shell umum (sh , ksh , csh ) atau bahasa yang ditafsirkan seperti PERL , Python , dan sejenisnya.
Satu tempat lain untuk dilihat adalah cron penjadwal. Apa pun yang dijadwalkan di sana, apakah itu dipasok oleh vendor atau dibuat sendiri, adalah sesuatu yang ingin Anda habiskan untuk mengujinya.
Pendekatan top-down bisa lebih sulit, karena dimulai dengan pengguna akhir dan mencari tahu dari mereka apa yang mereka jalankan di sistem. Pendekatan ini bisa menjadi pengalaman yang mencoba, karena pengguna tidak selalu mengerti bagaimana sesuatu bekerja, hanya bagaimana mereka menggunakannya. Misalnya, pengguna mungkin tahu bahwa mereka menggunakan situs web, tetapi tidak menyadari bahwa "di balik layar" adalah Apache atau Tomcat , apakah memiliki CGI atau tidak skrip dan jika demikian, bahasa apa yang digunakan. Namun, informasi tambahan dapat diperoleh, seperti mengetahui bahwa server yang Anda pikir kurang lebih mandiri terkait erat dengan yang lain, dan bahwa Anda perlu memigrasikan keduanya di waktu yang sama.
Preferensi saya adalah melakukan keduanya... Saya akan mencoba mencari tahu siapa yang memimpin pengguna bisnis dari sistem tertentu dan bertemu dengan mereka untuk mengetahui untuk apa mereka menggunakannya. Saya juga akan mencoba mencocokkan fungsionalitas yang mereka gunakan dengan komponen sistem yang dapat diidentifikasi. Salah satu contohnya adalah server web. Apakah itu server statis, atau dinamis? Anda mungkin tidak melihatnya dari meninjau paket yang diinstal di server. Namun, wawancara pengguna mungkin memberi tahu Anda bahwa situs tersebut didasarkan pada WordPress , yang berarti Anda perlu menemukan database yang menggerakkannya, apakah itu di server yang sama atau mungkin server lain yang mungkin perlu dimigrasikan pada waktu yang sama.
Oke, jadi sekarang saya tahu apa yang sedang berjalan, apa selanjutnya?
Anda perlu memutuskan distribusi Linux apa yang akan Anda pindahkan. Banyak hal yang menjadi faktor dalam keputusan ini, yang sejujurnya harus menjadi posting blognya sendiri. Untuk saat ini, yang akan saya soroti adalah Anda perlu melihat fitur yang dimainkan di server, dan mencari tahu distribusi apa yang mendukung fitur yang sama. Jika, misalnya, servernya adalah server web atau FTP sederhana, hampir semua Linux sudah cukup. Jika Anda menjalankan beberapa perangkat lunak pihak ketiga, vendor mungkin hanya mendukung distribusi tertentu, jadi Anda mungkin ingin memulai dengan perangkat lunak tersebut, lalu mempersempit dari sana.
Setelah Anda memilih distribusi Anda, buat sendiri lingkungan pengembangan, instal OS dasar dan paket yang dibutuhkan, perangkat lunak pihak ketiga, dan sejenisnya. Siapkan pengguna untuk pengujian, dan salin program dan skrip mereka, atau pastikan mereka dapat melakukannya.
Semuanya akan berjalan begitu saja, kan?
Di dunia yang sempurna, itu benar. Namun, kita semua tahu dunia ini tidak sempurna. Fitur-fitur yang disediakan OS umumnya bekerja di luar kotak seperti yang Anda harapkan. Jika Anda melompat ke versi untuk sesuatu seperti Apache, mungkin ada perbedaan dalam cara mengonfigurasinya agar situs web Anda berjalan dengan cara yang sama. Dokumentasi biasanya membantu Anda sampai di sana. Perangkat lunak pihak ketiga terkadang dapat memiliki lebih banyak masalah. Jika Anda harus menghadapinya, pastikan Anda telah mengonfirmasi level versi OS. Satu vendor yang pernah saya tangani mendukung RHEL 6, tetapi bukan RHEL 7. Kadang-kadang mereka mungkin hanya menguji rilis titik tertentu, dan mendukung hingga itu tetapi tidak lebih dari itu, seperti mendukung RHEL 6.4 tetapi tidak RHEL 6.10. Mungkin juga ada masalah jika Anda menginstal OS versi 64-bit, tetapi vendor pihak ketiga hanya mengujinya pada penginstalan 32-bit.
Perangkat lunak dan skrip yang dikembangkan sendiri adalah masalah lain. Anda hampir dijamin memiliki masalah di sana, sangat tergantung pada siapa yang menulis kode dan seberapa rumitnya. Bahasa formal dapat ditransfer dengan lebih mudah, selama OS Linux memiliki pustaka yang tepat untuk mendukung kompilasi.
Mungkin ada masalah jika Anda menggunakan versi Unix yang lebih lama, karena beberapa hal mungkin telah berubah dalam bahasa tersebut. Default tertentu mungkin telah berubah, dan opsi untuk memfungsikan panggilan, terutama panggilan sistem, mungkin berbeda. Rekomendasinya adalah melakukan kompilasi kode pertama dengan jumlah debug tertinggi yang dapat Anda aktifkan, lalu setelah Anda mengatasi masalah tersebut, kompilasi ulang dengan debug yang dimatikan untuk menghemat beban server di masa mendatang.
Untuk skrip, hal yang sama berlaku, tetapi dengan peluang perubahan aneh yang lebih besar. Pengalaman pribadi telah menunjukkan bahwa shell standar (alias sh ) skrip biasanya dijalankan di bawah Bourne Again Shell (alias bash ). Namun, mungkin ada gotcha tersembunyi yang sebenarnya tidak menimbulkan kesalahan, tetapi tidak memberikan hasil yang diharapkan. Salah satu contoh utama adalah cuplikan kode ini yang sering saya gunakan di masa HPUX saya:
cat datafile.txt | while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done
echo “$saved_value”
Di bawah HPUX, ini berfungsi dengan baik. Di bawah bash di RHEL, variabel $saved_value akan kosong, karena bagaimana shell itu melakukan pelingkupan versus bagaimana HPUX melakukannya. Saya harus mengubah di atas menjadi seperti ini:
while read line ; do
set - $line
var1 = $1
if [ $var1 = “yes” ] ; then saved_value = “$2”
done < datafile.txt
echo “$saved_value” Jadi, penting untuk melakukan eksekusi berdampingan antara sistem lama dan sistem baru untuk memverifikasi bahwa input yang sama ke dalam skrip menghasilkan output yang sama di kedua sistem.
Oke, kami menguji semua hal, sekarang apa?
Langkah sebenarnya dalam melakukan peralihan dari sistem lama ke yang baru dapat sangat bervariasi dalam kerumitannya, tergantung pada lingkungan Anda. Agar topik benar-benar ditangani dengan benar, topik tersebut harus memiliki blog sendiri. Setelah Anda melakukan migrasi, pemeriksaan mayat akan berguna, terutama jika Anda memiliki migrasi tambahan yang harus dilakukan. Tinjauan yang solid tentang apa yang berhasil dan apa yang tidak berjalan dengan baik dapat menghasilkan "pelajaran yang dipetik" untuk diterapkan pada proyek migrasi Anda berikutnya.
Penutup
Saya harap artikel ini telah membantu menyoroti jenis hal yang harus dicari, percakapan yang harus dilakukan, rencana untuk dibuat, dan memberi Anda langkah awal dalam perjalanan Anda ke migrasi Unix ke Linux. Mudah-mudahan, dengan hal-hal yang Anda ambil dari artikel ini, dan sedikit keberuntungan, transisi Anda akan relatif mulus.
[ Ingin mencoba Red Hat Enterprise Linux? Unduh sekarang secara gratis. ]