Red HatとCentOSのメジャーバージョン間でアップグレードするのがそれほど難しいのはなぜですか？
「既存の実稼働EL5サーバーをEL6にアップグレードできますか？」 環境がまったく異なる2人の顧客からのシンプルな要求により、「はい、しかしすべてのシステムを調整して再構築する必要があります」という私のベストプラクティスの答えが得られました。 両方のクライアントは、システムの完全な再構築がダウンタイムとリソースの理由から受け入れられないオプションであると感じています...システムを完全に再インストールする必要がある理由を尋ねられたとき、私はそれ以上の良い答えを持っていませんでした...」 構成管理（「すべてを人形化する」が常に当てはまるわけではありません）またはクライアントがどのように計画を立てるべきかについての応答を引き出すつもりはありません。これは、実稼働環境で成長し繁栄した環境の実例ですが、OSの次のバージョンに移行するための明確な道はありません。 環境A： 40 x Red Hat Enterprise Linux 5.4および5.5 Web、データベースサーバー、メールサーバーを備え、Java Webアプリケーションスタック、ソフトウェアロードバランサー、Postgresデータベースを実行する非営利組織。すべてのシステムは、それぞれがHA、DRSなどを備えた、異なる場所にある2つのVMWare vSphereクラスターで仮想化されます。 環境B： 生産取引業務を実行し、社内開発およびバックオフィス機能をサポートする複数のコロケーション施設に200 x CentOS 5.xシステムを備えた高周波金融取引会社。取引サーバーは、ベアメタルのコモディティサーバーハードウェアで実行されています。メッセージングレイテンシを低減するために、多数の、、割り込みバインディング、およびドライバー調整が用意されています。カスタムカーネルやリアルタイムカーネルを備えているものもあります。開発者ワークステーションも同様のバージョンのCentOSを実行しています。sysctl.confrtctl どちらの場合も、環境は現状のまま正常に動作しています。アップグレードしたいのは、EL6で利用可能な新しいアプリケーションまたは機能が必要だからです。 非営利企業にとっては、Apache、カーネル、および開発者を喜ばせるものに結びついています。 商社では、カーネル、ネットワークスタック、およびGLIBCのいくつかの機能強化について、開発者を満足させます。 どちらもオペレーティングシステムを大幅に変更せずに簡単にパッケージ化または更新できないものです。 システムエンジニアとして、Red Hatはメジャーバージョンリリース間を移動する際に完全な再構築を推奨しています。クリーンスタートでは、途中でリファクタリングを行い、構成に注意を払う必要があります。 クライアントのビジネスニーズに敏感であるため、なぜこれが面倒な作業である必要があるのでしょうか。RPMパッケージングシステムはインプレースアップグレードを処理する以上の機能を備えていますが、それ/boot以上の詳細はありません：より多くのスペース、新しいデフォルトファイルシステム、RPMが途中でアップグレード、非推奨、廃止されたパッケージを破壊する可能性があります... ここでの答えは何ですか？他のディストリビューション（.debベース、ArchおよびGentoo）には、この機能またはより良いパスがあるようです。このタスクを正しい方法で達成するためのダウンタイムを見つけたとしましょう。 EL7がリリースされて安定した場合、これらのクライアントは同じ問題を回避するために何をすべきですか？ それとも、人々は数年ごとに完全な再建に辞任する必要があるのでしょうか？ これは、Enterprise Linuxが進化するにつれて悪化しているように見えます...または、私はただそれを想像していますか？ これにより、だれかがRed Hatおよび派生オペレーティングシステムを使用することを思いとどまらせましたか？ 構成管理の角度があると思いますが、私が見るほとんどのPuppetインストールは、高度にカスタマイズされたアプリケーションサーバーのある環境にうまく変換されません（環境Bは、ifconfig出力がこのように見える単一のサーバーを持つことができます）。ただし、組織がRHELのメジャーバージョンバンプを克服するのに構成管理を使用する方法についての提案を聞くのは興味深いでしょう。