RHEL インプレースアップグレードとは

Red Hat Enterprise Linux (RHEL) のお客様がアプリケーションスタックのアップデートや、最新のセキュリティアップデートの入手されたい場合、また RHEL ライフサイクルの終わりが近づいている場合 (RHEL 7 のメンテナンス終了予定日は 2024 年 6 月 30 日)、通常は最新リリースを入手することを希望されるものです。この投稿は、RHEL のアップグレードに関するシリーズ記事の第 1 弾であり、今後のアップグレードの計画に役立てば幸いです。まずは、RHEL のインプレースアップグレードについて説明します。

インプレースアップグレードで解決する問題

従来、アップグレードにはオペレーティングシステムの新規インストールと、すべてのアプリケーションスタック、データベース、および設定の再デプロイが必要でした。インプレースアップグレードは、既存のお客様のワークフローを維持しながら、この手間を解決します。まず、インプレースアップグレードが企業にとって適切な選択肢となるケースを、新規インストールの場合と比較して見てみましょう。

インプレースアップグレードとフレッシュインストール

インプレースアップグレードは、多くの場合、経験の浅いシステム管理者でも実行できます。システムの構成が複雑または特殊でない場合は、アップグレードが必要なすべてのマシンに対していくつかのコマンドを入力するだけで実行でき、アップグレード前の分析レポートを確認し、必要に応じて推奨される修正を実行できます。

設定の保持

インストールされたアプリケーションの制御を維持することは、インプレースアップグレードの最も重要な機能の 1 つです。アップグレード中に使用するカスタムリポジトリを指定することで、アップグレードプロセスを拡張できます。カスタムの Leapp アクターを記述すると、特定の設定を持つサードパーティー製アプリケーションの移行に役立ちます。環境のモダナイズを検討している組織は、カスタム・アプリケーションの要件に対応できるこの制御の恩恵を受けます。最後に、アップグレード前プロセスで示される修正手順は、 Ansible Playbookを使用して自動化できます。

高度なスキルの必要性を軽減

インプレースアップグレードでは、既存のシステム構成やインストールされているアプリケーションに関する予備知識は必要ありません。そのため、初心者レベルの管理者がアップグレードを実行できます。アップグレード前の分析を実行し、提案された修正を適用することで、アプリケーションまたは設定が誤って削除されるリスクが低減されます。管理者は、レポートの情報を理解できれば十分です。

サブスクリプションを保持する

インプレースアップグレード中に既存の RHEL サブスクリプションに関する情報は削除されないため、すべてのサブスクリプションは機能し続けます。

時間とリソースを節約

インプレースアップグレードによって時間と貴重なリソースを節約できることは明らかです。環境全体をモダナイズしながら、現在のハードウェアの寿命を延ばすのに便利な方法です。

不確実性の低減

アップグレード前の分析は、それ自体が有用なツールです。不明な点がある場合は、アップグレード前分析を実行すると、システムにインストールされているパッケージのインベントリーを、可能なアップグレードパスと修正案とともに生成できます。これは、正しいアップグレードアプローチを決定するときに役立ちます。

フレッシュインストール

RHEL の新規インストールを実行すると、アプリケーションや設定を含むすべてのシステムデータが完全に消去されます。これにより、運用コストが大幅に増加し、デプロイ時に追加の専門知識が必要になります。

既存の設定を完全に消去する

設定はインストール中に削除されるため、すべてを再適用するには時間がかかります。特に Red Hat Ansible Automation Platformなどの製品に備わっている自動化機能を使用していない場合はそうです。

時間とコストがかかる

アプリケーションスタック全体の再デプロイも含め、数百、あるいは数千ものマシンにオペレーティングシステム (OS) を再インストールする必要があります。この追加作業には、リソースと時間がかかります。

マシンの再サブスクライブが必要

ワイプされるマシンは、インストール時に既存の RHEL サブスクリプションを保持することはできません。正常に機能させるには、すべてのマシンを再サブスクライブする必要があります。

では、フレッシュインストールに利点はあるのでしょうか。

フレッシュインストールは、新しいハードウェアに移行したり、新しいアプリケーションスタックを使用したり、新しい管理機能や自動化機能が必要になったりする場合には利点があります。たとえば、新規のグリーンフィールドプロジェクト (以前の作業に依存しないプロジェクト) は、フレッシュインストールのユースケースとして適しています。 

提供状況とサポート対象バージョン

コマンドラインインターフェースからアップグレードする場合、Leapp が利用可能なすべての RHEL システムで提供される仮想パッケージの leapp-upgrade— をインストールし、必要なパッケージすべてを dnf または yum—  を使用してインストールできます。leapp コマンドはそのサブコマンドを使用してアップグレード前レポートを作成し、その後アップグレード自体が可能になります。

Red Hat Satelliteでアップグレード前の分析を実行し、マシンを管理することもできます。アップグレード前の評価を実行し、分析されたリスクを修正したら、UI ですべてのマシンを一度にアップグレードすることもできます。詳細については、Satellite での Leapp を参照してください。

RHEL の複数のバージョンがアップグレードの対象となります。サポートされているすべてのアップグレードパスの最新リストについては、 「 Supported in-place upgrade path for Red Hat Enterprise Linux」を参照してください。このリストは、新しい RHEL がリリースされるたびに更新されます。

パブリッククラウドのサポートについては、Amazon Web Services (AWS)、Microsoft Azure、および Google Cloud Platform の Red Hat Update Infrastructure (RHUI) で、オンデマンドの従量課金制 (PAYG) インスタンスのインプレースアップグレードを提供しています。また、RHEL サブスクリプションに Red Hat Subscription Manager を使用するすべてのパブリッククラウドで、BYOS (Bring Your Own Subscription) インスタンスのアップグレードもサポートしています。

複数のメジャーリリースにまたがる直接のアップグレード (RHEL 6 から RHEL 8 など) はできないことに注意してください。バージョン 6 から 8 にアップグレードするには、まず RHEL 7 にアップグレードしてから RHEL 8 にアップグレードします。

サポートされているアーキテクチャと製品の詳細、およびアップグレード方法の詳細については、以下のドキュメントをご覧ください。

• RHEL 6 から RHEL 7 へのアップグレード
• RHEL 7 から RHEL 8 へのアップグレード
• RHEL 8 から RHEL 9 へのアップグレード

キーポイント

インプレースアップグレードは、コストと時間を節約しながら、再デプロイに関するいくつかの問題を解決できます。フレッシュインストールはグリーンフィールドプロジェクトに使用できますが、既存の環境をモダナイズする場合は、インプレースアップグレードが明らかに優れています。インプレースアップグレードも RHEL エコシステムの重要な部分であるため、予定されているイノベーションに加えて、継続的なサポートが期待されます。