「既存の実稼働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のメジャーバージョンバンプを克服するのに構成管理を使用する方法についての提案を聞くのは興味深いでしょう。

（著者のメモ：この回答は、RHEL 6以前のバージョンに関するものです。RHEL7には、RHEL 6からの完全にサポートされたアップグレードパスがあり、詳細は最後にあります。）

はじめに、インプレースアップグレードを行うには2つの方法があることに注意してください。

1. インストールDVDをドロップ（または、iLO / iDRAC経由でDVDイメージを使用）し、そこから起動して、アップグレードを選択します（例：）linux upgradeany。
2. redhat-releaseRPMを手動で更新し、実行yum distro-sync（これは少し単純化しすぎています）して再起動します。

方法1はサポートされていません。方法2は本物のカウボーイ向けです。推奨される新規インストールに加えて、これらの両方を実行しました...

サポートが必要ですか？

私たちの世界では、サポートには2つの補完的な意味があります。1つは、製品に特定の機能があることです（「PostfixがSMTPをサポートする」など）。2番目は、ベンダーがそれについてあなたに話すことです。どの定義が意図されているかは、コンテキストから必ずしも明確ではありません。

タスクを達成するには、明らかに第一の意味でのサポートが必要です。ベンダーのサポートは、問題の解決を支援し、存在する機能または改善する必要がある機能についてベンダーにフィードバックすることを支援します。多くのサイトは、発生する可能性のある問題を解決するための社内の専門知識を持ち、ベンダーよりも速く、さらに安価な場合、ベンダーサポートに大金を支払います。ベンダーサポートを購入するかどうかは、最終的にはビジネス上の決定である（または経営陣に助言する）必要があります。

なぜインプレースアップグレードを行わないのですか？

これは、Red Hatがそれについて言っていることです。

Red Hatは、Red Hat Enterprise Linuxのメジャーバージョン間のインプレースアップグレードをサポートしていません。メジャーバージョンは、整数バージョン変更によって示されます。たとえば、Red Hat Enterprise Linux 5とRed Hat Enterprise Linux 6は、どちらもRed Hat Enterprise Linuxのメジャーバージョンです。

メジャーリリース全体のインプレースアップグレードでは、すべてのシステム設定、サービス、またはカスタム構成が保持されません。そのため、あるメジャーバージョンから別のメジャーバージョンにアップグレードする場合、Red Hatは新規インストールを強く推奨します。

彼らはさらに警告します：

ただし、システムのアップグレードを選択する前に、次の制限に注意してください。

• 個々のパッケージ構成ファイルは、さまざまな構成ファイル形式またはレイアウトの変更により、アップグレードの実行後に機能する場合と機能しない場合があります。
• Red Hatの階層化された製品（Cluster Suiteなど）のいずれかがインストールされている場合、Red Hat Enterprise Linuxのアップグレードが完了した後に手動でアップグレードする必要がある場合があります。
• サードパーティまたはISVアプリケーションは、アップグレード後に正しく動作しない場合があります。

もちろん、その後、方法1を使用してインプレースアップグレードを実行する方法について説明します。この機能が存在し、Red Hatが開発時間を費やしているため、機能が存在するという点でサポートされています。ただし、何か問題が発生した場合、Red Hatは新規インストールを指示します。アップグレードの結果として破損したものについては、ベンダーサポートを提供しません。

記録のために、RHEL / CentOSまたはFedoraシステムのインプレースアップグレードで、自分で解決できない問題が実際に発生したことはありません。典型的な問題は、名前が変更されたパッケージ、サードパーティのリポジトリ、およびパッケージのi386アーキテクチャとx86_64アーキテクチャ間のバージョンの不一致が原因です。インストーラーは、これらよりも少し優れているyumと思います。

どうすればアップグレードできますか？

一般的に、RHELシステムを1つのメジャーバージョンから次のバージョンに更新するために、3〜4年ごとにメンテナンスウィンドウを計画する必要があることを人々に警告します。アップグレードは通常スムーズに行われますが、予期しないことが常に発生する可能性があります。

どちらの環境でも、インプレースアップグレードが機能することを期待していますが、最初に徹底的にテストすることを強くお勧めします。P2Vはサーバーの代表的なサンプルであり、仮想システムでインプレースアップグレードを実行して、どの問題に遭遇するかを確認します。その後、何が起こるかについてのより良い知識に基づいて、実際の実稼働アップグレードを計画できます。

ここにあるような大規模な展開では、Limoncelliの「1対多」アプローチの使用を検討してください。1台のマシンをアップグレードし、発生する問題を確認して解決し、マシンの小さなバッチをアップグレードする際に学んだ教訓を使用し、学んだ教訓を繰り返し、すべてのねじれが解決したと確信したら、それらの大きなバッチをアップグレードします。

このようなときは、アプリケーションの展開プロセスを長く綿密に検討することもお勧めします。単一のコマンドで起動でき、アプリが正しく展開されることを合理的に確信できるほど十分に自動化されていない場合は、おそらく開発者がそれに取り組む必要があります。このような展開プロセスがあると、ELの新しいバージョンを新規インストールしてからその上に展開するのがはるかに簡単になります。

ディストリビューションの切り替えは役立ちますか？

Debianベースのディストリビューションには、インプレースアップグレード方式がサポートされており、ほとんどの場合機能しますが、問題の影響を受けません。たとえば、サポートされている方法でUbuntu 10.04 LTSから12.04 LTSにアップグレードする場合、多くのことが壊れました。DebianやCanonicalがこの機能を「サポート」するために十分な量の開発時間を費やしているかどうか、つまり、確実に機能するかどうかは不明です。そして、誰かに手を貸してもらいたい場合は、実際にこのディストリビューションのベンダーサポートを購入する必要があります。したがって、このようなディストリビューションに切り替えることで、多くの利益が得られるとは思いません。

GentooやArchなどのローリングリリースディストリビューションに切り替えることで利益を得ることができます。ただし、これによって問題が発生することもありません。十分に計画されたディストリビューションアップグレード時に一度にすべてを行うのではなく、サーバーの寿命（たとえば、ユーザーまたは開発者がシステムの何かを更新することを決定するたび）にわたって継続的にアップグレードの問題に対処する必要があることを意味します。また、サポートを提供するベンダーもありません。

将来はどうなりますか？

Fedoraプロジェクトは、インプレースアップグレードを改善するためのツールに取り組んでいます。彼らはFedora 18からpreupgradeは廃止され、fedupという新しいツールに置き換えられたというツールを持っていました。これはRHEL7に追加され、少なくともRHEL 6からRHEL 7へのインプレースアップグレードが完全にサポートされるようになりました。私自身の経験から言えば、まだいくつかの不具合がありますが、非常に有用なツールになりつつあります。fedup

CentOSはまた、リポジトリのローリングリリースタイプを実験していますが、マイナーバージョン（6.3-6.4など）の間でのみ適用されます。

あなたの最後の段落の私の見解：

構成管理の角度があると思いますが、私が見るほとんどのPuppetインストールは、高度にカスタマイズされたアプリケーションサーバーがある環境にはうまく変換されません（環境Bは、ifconfig出力がこのように見える単一のサーバーを持つことができます）。ただし、組織がRHELのメジャーバージョンバンプを克服するために構成管理を使用する方法についての提案を聞くのは興味深いでしょう。

構成管理システムの真の価値は、特に環境Bのコンテキストでは、それを実行するサーバーとは無関係にサービスを構築するツールを提供することだと思います。既存のサービスの作成にCMSを使用しなかった場合、おそらくサービスの再作成にはあまり役立ちません。

これはあなたの差し迫った問題を解決するものではないことは知っていますが、私にとっては、サービスではなくサーバーの観点から組織が考えていることに起因しています。サービス重視の考え方では、サービスが機能し続ける限り、個々のサーバーのパーソナリティを維持する必要はありません。CMSを統制のとれた方法で使用してサービス全体を構築する場合、マシンのパーソナリティはすべてCMSによって構築されるため、そのサービスを別のシステムに移動するのは比較的簡単です。

PSこのコンテキストでのifconfig出力の重要な点は正確にはわかりません-それは構成ファイルといくつかのスクリプトによって生成され（そうでない場合はブート時に存在しません）、必要に応じてCMSで管理できます。