"Bisakah kita meningkatkan server EL5 produksi yang ada menjadi EL6?"

Sebuah permintaan sederhana yang terdengar dari dua pelanggan dengan benar-benar lingkungan yang berbeda diminta saya biasa-praktek terbaik jawaban "ya, tapi itu akan memerlukan dikoordinasikan kembali dari semua sistem Anda " ...

Kedua klien merasa bahwa pembangunan kembali lengkap sistem mereka adalah pilihan yang tidak dapat diterima untuk alasan waktu henti dan sumber daya ... Ketika ditanya mengapa perlu menginstal ulang sistem sepenuhnya, saya tidak memiliki jawaban yang baik di luar, "begitulah adanya ... "

Saya tidak mencoba untuk mendapatkan tanggapan tentang manajemen konfigurasi ("Membentuk segalanya " tidak selalu berlaku ) atau bagaimana klien seharusnya merencanakan dengan lebih baik. Ini adalah contoh dunia nyata dari lingkungan yang telah tumbuh dan berkembang dalam kapasitas produksi, tetapi tidak melihat jalur bersih untuk pindah ke versi OS mereka berikutnya.

Lingkungan A:
Organisasi nirlaba dengan web 40 x Red Hat Enterprise Linux 5.4 dan 5.5 , server database dan server mail, menjalankan tumpukan aplikasi web Java, penyeimbang beban perangkat lunak, dan database Postgres. Semua sistem divirtualisasikan pada dua kluster VMWare vSphere di lokasi yang berbeda, masing-masing dengan HA, DRS, dll.

Lingkungan B:
Perusahaan perdagangan keuangan frekuensi tinggi dengan sistem 200 x CentOS 5.x di berbagai fasilitas co-location yang menjalankan operasi perdagangan produksi, mendukung pengembangan in-house dan fungsi back-office. Server perdagangan berjalan pada perangkat keras server komoditas bare-metal. Mereka memiliki banyak sysctl.conf,, rtctlinterrupt binding dan driver tweak di tempat untuk menurunkan latensi pesan. Beberapa memiliki kernel custom dan / atau realtime. Stasiun kerja pengembang juga menjalankan versi CentOS yang serupa.

Dalam kedua kasus, lingkungan berjalan dengan baik apa adanya. Keinginan untuk meningkatkan berasal dari kebutuhan untuk aplikasi atau fitur yang lebih baru yang tersedia di EL6.

• Untuk perusahaan nirlaba, itu terkait dengan Apache, kernel dan beberapa hal yang akan membuat para pengembang senang.
• Di perusahaan perdagangan, ini tentang beberapa peningkatan di kernel, tumpukan jaringan dan GLIBC, yang akan membuat para pengembang senang.

Keduanya adalah hal-hal yang tidak dapat dengan mudah dikemas atau diperbarui tanpa secara drastis mengubah sistem operasi .

Sebagai seorang insinyur sistem, saya menghargai bahwa Red Hat merekomendasikan pembangunan kembali penuh ketika bergerak di antara rilis versi utama. Awal yang bersih memaksa Anda untuk melakukan refactor dan memperhatikan konfigurasi di sepanjang jalan.

Menjadi peka terhadap kebutuhan bisnis klien, saya heran mengapa ini harus menjadi tugas yang berat . Sistem pengemasan RPM lebih dari mampu menangani peningkatan di tempat, tetapi ini adalah detail kecil yang membuat Anda: /bootmembutuhkan lebih banyak ruang, sistem file default baru, RPM mungkin melanggar paket tengah-upgrade, usang dan tidak aktif ...

Apa jawabannya di sini? Distribusi lain (berbasis deb, Arch dan Gentoo) tampaknya memiliki kemampuan ini atau jalur yang lebih baik. Katakanlah kita menemukan waktu henti untuk menyelesaikan tugas ini dengan cara yang benar :

• Apa yang harus dilakukan klien ini untuk menghindari masalah yang sama ketika EL7 dirilis dan distabilkan?
• Atau apakah ini kasus di mana orang perlu mengundurkan diri untuk membangun kembali secara penuh setiap beberapa tahun?
• Ini tampaknya semakin memburuk karena Enterprise Linux telah berevolusi ... Atau apakah saya hanya membayangkan itu?
• Apakah ini menghalangi siapa pun untuk menggunakan Red Hat dan sistem operasi turunan?

Saya kira ada sudut manajemen konfigurasi, tetapi kebanyakan instalasi Wayang yang saya lihat tidak diterjemahkan dengan baik ke dalam lingkungan dengan server aplikasi yang sangat disesuaikan ( Lingkungan B dapat memiliki satu server yang ifconfigoutputnya terlihat seperti ini ). Namun, saya akan tertarik mendengar saran tentang bagaimana manajemen konfigurasi dapat digunakan untuk membantu organisasi mengatasi benturan versi utama RHEL.

(Catatan Penulis: Jawaban ini merujuk pada RHEL 6 dan versi sebelumnya. RHEL 7 sekarang memiliki jalur peningkatan yang didukung penuh dari RHEL 6, yang detailnya ada di akhir.)

Untuk memulai, saya harus perhatikan bahwa ada dua cara untuk melakukan peningkatan di tempat:

1. Masukkan DVD instalasi (atau gunakan gambar DVD melalui iLO / iDRAC), boot dari itu dan pilih Upgrade, misalnya linux upgradeany.
2. Perbarui redhat-releaseRPM secara manual, jalankan yum distro-sync(ini sedikit disederhanakan) dan reboot.

Metode 1 tidak didukung. Metode 2 untuk Koboi Asli. Selain pemasangan baru yang disarankan, saya telah melakukan keduanya ...

Apakah saya memerlukan dukungan?

Dukungan memiliki dua makna yang saling melengkapi di dunia kita. Yang pertama adalah bahwa produk memiliki fitur yang diberikan (misalnya "Postfix mendukung SMTP"). Yang kedua adalah bahwa vendor akan berbicara kepada Anda tentang hal itu. Definisi mana yang dimaksudkan tidak selalu jelas dari konteks.

Untuk menyelesaikan suatu tugas, Anda jelas membutuhkan dukungan dalam arti pertama. Di mana dukungan vendor masuk adalah untuk membantu Anda dalam menyelesaikan masalah dan memberikan umpan balik vendor mengenai fitur apa yang perlu ada atau ditingkatkan. Banyak situs membayar mahal untuk dukungan vendor ketika mereka memiliki keahlian di rumah untuk menyelesaikan masalah yang mungkin timbul, lebih cepat dan bahkan lebih murah daripada yang bisa dilakukan vendor. Apakah membeli dukungan vendor pada akhirnya merupakan keputusan bisnis yang harus Anda buat (atau menyarankan manajemen untuk).

Mengapa tidak melakukan pembaruan di tempat?

Inilah yang Red Hat katakan tentang hal itu :

Red Hat tidak mendukung peningkatan di tempat antara versi utama Red Hat Enterprise Linux. Versi utama ditandai dengan perubahan versi bilangan bulat. Misalnya, Red Hat Enterprise Linux 5 dan Red Hat Enterprise Linux 6 adalah versi utama dari Red Hat Enterprise Linux.

Pembaruan di tempat di seluruh rilis utama tidak mempertahankan semua pengaturan sistem, layanan, atau konfigurasi khusus. Akibatnya, Red Hat sangat merekomendasikan instalasi baru ketika meningkatkan dari satu versi utama ke yang lain.

Mereka selanjutnya memperingatkan:

Namun, perhatikan batasan-batasan berikut sebelum Anda memilih untuk meningkatkan sistem Anda:

• File konfigurasi paket individual mungkin atau mungkin tidak berfungsi setelah melakukan peningkatan karena perubahan dalam berbagai format atau tata letak file konfigurasi.
• Jika Anda memiliki salah satu produk berlapis Red Hat (seperti Cluster Suite) yang diinstal, mungkin perlu ditingkatkan secara manual setelah pemutakhiran Red Hat Enterprise Linux telah selesai.
• Aplikasi pihak ketiga atau ISV mungkin tidak berfungsi dengan benar setelah peningkatan.

Tentu saja, mereka kemudian menjelaskan cara melakukan upgrade di tempat melalui metode 1, kalau-kalau Anda benar-benar ingin melakukannya. Fitur ada dan Red Hat menempatkan waktu pengembangan ke dalamnya, sehingga didukung dalam fitur yang ada. Tetapi jika terjadi kesalahan, Red Hat akan memberitahu Anda untuk menginstal yang baru; mereka tidak akan memberikan dukungan vendor untuk hal-hal yang rusak akibat peningkatan.

Sebagai catatan, saya tidak pernah benar-benar memiliki masalah dengan upgrade di tempat dari sistem RHEL / CentOS atau Fedora yang tidak dapat saya selesaikan sendiri. Masalah umum datang dari paket berganti nama, repositori pihak ketiga dan ketidakcocokan versi sesekali antara arsitektur i386 dan x86_64 dari sebuah paket. Penginstalnya sedikit lebih baik dalam menangani ini daripada yum, saya pikir.

Bagaimana cara saya meningkatkan?

Saya biasanya memperingatkan orang-orang bahwa mereka harus merencanakan jendela pemeliharaan setiap 3-4 tahun untuk memperbarui sistem RHEL dari satu versi utama ke versi berikutnya. Sementara pemutakhiran umumnya berjalan dengan lancar, hal yang tak terduga selalu bisa terjadi.

Untuk kedua lingkungan Anda, saya berharap pembaruan di tempat akan berfungsi, meskipun saya sangat menyarankan untuk mengujinya terlebih dahulu. P2V sampel representatif dari server dan jalankan melalui upgrade di tempat pada sistem virtual untuk melihat masalah apa yang akan Anda hadapi. Anda kemudian dapat merencanakan peningkatan produksi aktual berdasarkan pengetahuan yang lebih baik tentang apa yang akan terjadi.

Untuk penyebaran besar seperti yang Anda miliki di sini, pertimbangkan untuk menggunakan pendekatan "satu-beberapa-banyak" Limoncelli. Mutakhirkan satu mesin, lihat masalah apa yang terjadi, selesaikan, kemudian gunakan pelajaran yang didapat saat memutakhirkan sejumlah kecil mesin, ulangi pelajaran yang dipetik, kemudian ketika Anda yakin Anda memiliki semua kekusutan, perbarui sejumlah besar mesin.

Pada saat seperti ini, saya juga merekomendasikan untuk memperhatikan proses penyebaran aplikasi Anda. Jika itu tidak cukup otomatis sehingga Anda dapat memulai dengan satu perintah dan cukup yakin bahwa aplikasi akan digunakan dengan benar, maka mungkin para pengembang perlu mengerjakannya. Memiliki proses penyebaran seperti itu akan membuatnya lebih mudah untuk melakukan instalasi baru dari versi EL yang lebih baru dan kemudian menerapkannya.

Apakah beralih distribusi akan membantu?

Distribusi berbasis Debian memang memiliki metode peningkatan yang didukung di tempat, dan sebagian besar berfungsi, tetapi tidak kebal dari masalah. Banyak hal yang rusak untuk orang yang melakukan upgrade dari Ubuntu 10,04 LTS menjadi 12,04 LTS melalui metode yang didukung, misalnya. Tidak jelas apakah Debian atau Canonical menempatkan cukup banyak waktu pengembangan untuk "mendukung" fitur ini, yaitu, memastikan itu berfungsi. Dan Anda masih harus membeli dukungan vendor untuk distribusi ini jika Anda ingin seseorang memegang tangan Anda. Jadi saya ragu Anda akan mendapat banyak manfaat dari beralih ke distribusi seperti itu.

Anda bisa mendapatkan dengan beralih ke distribusi pelepasan bergulir seperti Gentoo atau Arch. Namun, ini juga tidak membuat Anda kebal terhadap masalah; itu hanya berarti Anda harus berurusan dengan masalah pemutakhiran secara terus-menerus selama umur server (mis. kapan pun Anda atau pengembang memutuskan untuk memperbarui sesuatu pada sistem), daripada sekaligus pada waktu peningkatan distribusi yang terencana dengan baik. Anda juga tidak memiliki vendor untuk memberikan dukungan.

Apa yang ada di masa depan?

Proyek Fedora sedang mengerjakan alat untuk meningkatkan pemutakhiran di tempat. Mereka memiliki alat yang disebut preupgradeyang ditinggalkan dan diganti dengan alat baru yang disebut fedup yang dimulai dengan Fedora 18 . Ini ditambahkan ke RHEL7 dan sekarang upgrade di tempat memiliki dukungan penuh , setidaknya dari RHEL 6 ke RHEL 7 . Dari pengalaman saya sendiri, saya dapat mengatakan bahwa sementara fedupmasih memiliki beberapa ketegaran , itu membentuk menjadi alat yang sangat berguna.

CentOS juga bereksperimen dengan jenis repositori bergulir-rilis , tetapi hanya berlaku di antara versi minor (mis. 6.3-6.4).

Pandangan saya tentang paragraf terakhir Anda:

Saya kira ada sudut manajemen konfigurasi, tetapi kebanyakan instalasi Wayang yang saya lihat tidak diterjemahkan dengan baik ke dalam lingkungan dengan server aplikasi yang sangat disesuaikan (Lingkungan B dapat memiliki satu server yang output ifconfignya terlihat seperti ini). Namun, saya akan tertarik mendengar saran tentang bagaimana manajemen konfigurasi dapat digunakan untuk membantu organisasi mengatasi benturan versi utama RHEL.

Saya pikir nilai sebenarnya dari sistem manajemen konfigurasi, terutama dalam konteks Lingkungan B, adalah bahwa mereka menyediakan alat untuk membangun layanan secara independen dari server yang menjalankannya. Jika CMS tidak digunakan untuk membuat layanan yang ada, maka mungkin tidak akan banyak membantu dalam menciptakan kembali layanan.

Saya tahu ini tidak memecahkan masalah langsung Anda, tetapi bagi saya itu berasal dari pemikiran organisasi dalam hal server daripada layanan. Dalam pemikiran yang berfokus pada layanan, kepribadian masing-masing server tidak perlu dipertahankan selama layanan terus berfungsi. Jika CMS digunakan secara disiplin untuk membangun seluruh layanan, maka memindahkan layanan itu ke sistem lain harus relatif mudah, karena semua kepribadian mesin akan dibangun oleh CMS.

PS Saya tidak yakin apa yang signifikan tentang output ifconfig dalam konteks ini - ini diproduksi oleh file konfigurasi dan beberapa skrip (jika tidak, tidak akan ada saat boot), dan itu dapat dikelola oleh CMS, jika diperlukan.