Red Hat Satellite のアップグレードおよびアップデート
Red Hat Satellite Server および Capsule Server のアップグレードおよびアップデート
概要
第1章 アップグレードの概要
本章では、Red Hat Satellite 6.7 の前提条件、および利用可能なアップグレードパスを説明します。現在の Red Hat Satellite 6 インストールをアップグレードする前にお読みください。
本ガイドでは、「アップデート」、「アップグレード」、「マイグレーション (移行)」を以下の意味で使用します。
- アップグレード
- y-stream を基準にして、Satellite Server および Capsule Server のインストールを次のリリースに上げるプロセスです (たとえば Satellite 6.6 から Satellite 6.7)。
- アップデート
- z-stream を基準にして、Satellite Server および Capsule Server のインストールを次のリリースに上げるプロセスです (たとえば Satellite 6.7.0 から Satellite 6.7.1)。
- マイグレーション
- 既存の Satellite インストールを、別の Red Hat Enterprise Linux サーバーに移行するプロセスです。
Red Hat カスタマーポータルの Red Hat Satellite Upgrade Helper では、対話式のアップグレード手順がご利用になれます。このアプリケーションは、現在のバージョン番号に適した手順を提供します。アップグレードパスに固有の手順や、既知の問題を回避する手順を確認できます。詳細は、カスタマーポータルの「Satellite Upgrade Helper」を参照してください。
Red Hat Satellite Server および Capsule Server y-stream バージョンが一致する必要があります。たとえば、Satellite Server 6.6 は 6.7 Capsule Server と互換性がありませんが、Satellite Server 6.7 は Capsule Server 6.6 と互換性がありません。Satellite Server と Capsule Server のバージョンが一致しないと、Capsule Server が警告なしで失敗します。ただし、z-stream を Satellite Server よりも古いバージョンを使用する Capsule Server がサポートされます。たとえば、Satellite 6.7.1 Satellite Server は 6.7.0 Capsule Server と互換性があります。
1.1. 前提条件
Satellite 6.7 へのアップグレードは、Satellite インフラストラクチャー全体に影響します。アップグレード前に以下を完了してください。
- 『 Red Hat Satellite 6.7 リリースノート』を参照してください。
- このガイドで、アップグレードプロセスとその影響について確認する。
- アップグレードパスの計画を立てる。詳細は、「アップグレードパス」 を参照してください。
- BZ#1665893 が解決されるまで、「Candlepin gets stuck during startup forever, logging huge thread dump to error.log」のナレッジベースアーティクルを読み、解決策の手順を実行してからアップグレードを開始します。
必要とされるダウンタイムを計画する。Satellite サービスはアップグレード時は停止する。アップグレードプロセスの期間は、ハードウェアの構成、ネットワークの速度、サーバーに保存されているデータ量により異なる可能性がある。
Satellite のアップグレードには約 1 〜 2 時間かかる。
Capsule のアップグレードには約 10 〜 30 分かかる。
- サーバーに十分なストレージ容量があることを確認する。詳細は、『 オンラインネットワークからの Satellite Server のインストール』の「 ストレージ要件 」および『 Capsule Server のインストール 』の「 ストレージ要件 」を参照してください。
- Satellite Server および全 Capsule Server をバックアップする。詳細は、『 Red Hat Satellite 6.6 管理 』ガイドの「Satellite Server および Capsule Server のバックアップ 」を参照してください。
- Satellite のバージョンごとに API コマンドが異なる場合があるので、使用しているスクリプトに Satellite API コマンドが含まれる場合は、アップデートの計画を立てる。API の変更点に関する情報は、Red Hat カスタマーポータルのナレッジベースアーティクル「API Changes Between Satellite Versions」を参照してください。
設定ファイルを手動で、または Hiera などのツールを使用して、カスタマイズした場合には、このカスタマイズした内容は、アップグレード時またはアップデート時にインストールスクリプトを実行すると上書きされます。satellite-installer スクリプトで --noop
オプションを使用すると、変更をテストできます。詳細は、ナレッジベースソリューションの「How to use the noop option to check for changes in Satellite config files during an upgrade」を参照してください。
1.2. アップグレードパス
Red Hat Satellite 6.6 から Red Hat Satellite 6.7 にアップグレードできます。以前のバージョンの Satellite Server と Capsule Server は、先に Satellite 6.6 にアップグレードする必要があります。詳細は、Satellite 6.6『 Red Hat Satellite のアップグレードおよびアップデート 』ガイドを参照してください。
図1.1 Satellite 6.7 アップグレードパスの概要
ベータから GA バージョンへのアップグレードはサポートされていません。
以下は、Satellite 6.7 にアップグレードする手順の概要です。
- 既存の Satellite Server をクローンします。詳細は、2章Satellite Server のクローン を参照してください。
- Satellite Server と全 Capsule Server を Satellite 6.7 にアップグレードします。詳細は、「Satellite Server のアップグレード」 を参照してください。
- すべての Satellite クライアントで、Satellite Tools 6.7 にアップグレードします。詳細は、「Satellite クライアントのアップグレード」 を参照してください。
自己登録 Satellite
自己登録の Satellite をアップグレードすることはできません。自己登録の Satellite は、Red Hat コンテンツ配信ネットワーク (CDN) に移行すればアップグレードを実行できます。自己登録の Satellite を CDN に移行する方法は、『Satellite 6.3 の Red Hat Satellite のアップグレードおよびアップデート』ガイドの「Red Hat Satellite のアップグレード」を参照してください。
1.3. アップグレードの進捗の追跡
アップグレード時間は長くなるため、通信セッションの中断と再接続を可能にする screen
などのユーティリティーを使用します。これにより、コマンドシェルに接続し続けなくてもアップグレードの進捗が確認できるようになります。screen コマンドの使用方法は、Red Hat ナレッジベース の「How do I use the screen command?」を参照してください。また、screen
の man ページでも、詳細を確認できます。
アップグレードコマンドを実行しているコマンドシェルへの接続がなくなった場合は、/var/log/foreman-installer/satellite.log
のログで、プロセスが完全に終了したかどうかを確認できます。
第2章 Satellite Server のクローン
Satellite Server のアップグレード時に、アップグレード中にデータが損失されないように、オプションで Satellite のクローンを作成することができます。アップグレードが完了したら、Satellite Server の以前のバージョンの使用を停止できます。
以下の手順を使用して、Satellite インスタンスのクローンを作成し、環境を保存してアップグレードの準備を整えます。
Satellite クローンツールは、Capsule Server から Red Hat Enterprise Linux 7 への移行をサポートしません。代わりに、既存の Capsule Server のバックアップを作成し、Red Hat Enterprise Linux 7 に Capsule Server を復元してから再設定します。
用語
次の用語を理解するようにしてください。
ソースサーバー: クローンするサーバー
ターゲットサーバー: ファイルをコピーし、ソースサーバーのクローンを作成する先の新規サーバー
2.1. クローン作成プロセスの概要
- ソースサーバーをバックアップします。
- ソースサーバーからターゲットサーバーにクローンを作成します。
- ソースサーバーの電源を切断します。
- 新規ホスト名とターゲットサーバーの IP アドレスが一致するように、ターゲットサーバー上のネットワーク設定をアップデートします。
- コンテンツホストと Capsule で goferd を再起動して、接続をリフレッシュします。
- 新規ターゲットサーバーをテストします。
2.2. 前提条件
Satellite Server のクローンを作成するには、以下のリソースが用意されていることを確認します。
- ターゲットサーバーとして使用する Red Hat Enterprise Linux 7 サーバーの最小インストール。Red Hat Enterprise Linux 7 ソフトウェアグループやサードパーティーのアプリはインストールしないでください。また、『オンラインネットワークからの Satellite Server のインストール』の「 インストールのために環境を準備 」に記載されている仕様すべてに準拠していることを 確認してください。
-
satellite-maintain backup
スクリプトを使用して作成した Satellite 6.6 のバックアップ。Pulp データありでも、なしでもバックアップを使用できます。 - ターゲットサーバーの Satellite のサブスクリプション。
クローンを開始する前に、以下の条件を満たしていることを確認してください。
- ターゲットサーバーが分離ネットワーク上にあること。これにより、Capsule Server とホスト間で必要のない通信を回避できます。
- ソースサーバーからのバックアップファイルすべてを格納できるだけの容量があるターゲットサーバー
カスタマイズした設定ファイル
satellite-installer
ツールまたは Satellite バックアッププロセスの管理対象でないソースサーバーで、設定をカスタマイズしている場合には、これらのファイルを手動でバックアップする必要があります。
2.3. Pulp データの考慮事項
Pulp データを含めずに、Satellite Server のクローンを作成できます。ただし、クローンした環境を機能させるためには、Pulp データが必要です。ターゲットサーバーに、Pulp データがない場合には、Satellite は完全に機能しません。
Pulp データをターゲットサーバーに転送するには、2 つのオプションがあります。
- Pulp データを含むバックアップを使用したクローン作成
-
Pulp データなしのバックアップを使用してクローンを作成し、ソースサーバーから手動で
/var/lib/pulp
をコピーします。
pulp_data.tar
ファイルが 500 GB 以上の場合や、pulp_data.tar
ファイルが 100 GB 以上で、NFS など、速度の遅いストレージシステムを使用している場合には、展開時にメモリーエラーが発生する可能性があるので、バックアップに pulp_data.tar
を含めないようにしてください。ソースサーバーからターゲットサーバーに pulp_data.tar
ファイルをコピーするようにしてください。
Pulp データなしでバックアップする方法
「Satellite Server のクローン」の手順の内容に従います。ただし、Pulp データが含まれるクローンを作成する手順を、以下の手順に置き換えてください。
MongoDB と PostgreSQL の両データベースをアクティブにし、Pulp データは除外してバックアップを実行します。
# satellite-maintain backup offline --skip-pulp-content \ --assumeyes /var/backup
satellite-maintain
サービスを停止して、無効にします。# satellite-maintain service stop # satellite-maintain service disable
Pulp データをターゲットサーバーにコピーします。
# rsync --archive --partial --progress --compress \ /var/lib/pulp target_server.example.com:/var/lib/pulp
「ターゲットサーバーのクローン作成」に進みます。
2.4. Satellite Server のクローン
以下の手順を使用して、Satellite Server のクローンを作成します。この手順の一部として大量のデータをコピーして転送する必要があるので、完了までにかなり時間がかかる可能性がある点に注意してください。
2.4.1. クローン作成のためのソースサーバーの準備
ソースサーバーで、以下の手順を実行します。
Satellite サブスクリプションのプール ID を確認します。
# subscription-manager list --consumed \ --matches 'Red Hat Satellite'|grep "Pool ID:"|awk '{print $3}'
後で使用できるように、プール ID をメモしてください。
Red Hat Satellite のサブスクリプションを削除します。
# subscription-manager remove --serial=$(subscription-manager list \ --consumed \ --matches 'Red Hat Satellite'|grep "Serial:"|awk '{print $2}')
Pulp データのサイズを判断します。
# du -sh /var/lib/pulp/
Pulp データが 500 GB 未満の場合は、MongoDB と PostgreSQL のデータベースをアクティブにし、Pulp データを含めてバックアップを実行します。Pulp データが 500 GB 以上の場合には、以下の手順は省略して、続行する前に「Pulp データの考慮事項」の手順を実行してください。
# satellite-maintain backup offline --assumeyes /var/backup
satellite-maintain
サービスを停止して無効にします。# satellite-maintain service stop # satellite-maintain service disable
「ターゲットサーバーのクローン作成」に進みます。
2.4.2. ターゲットサーバーのクローン作成
サーバーのクローンを作成するには、ターゲットサーバーで以下の手順を実行してください。
-
satellite-clone
ツールはデフォルトで、/backup/
をバックアップフォルダーとして使用します。別のフォルダーにコピーする場合には、/etc/satellite-clone/satellite-clone-vars.yml
ファイルのbackup_dir
変数をアップデートしてください。 -
アップデート前の Satellite のバックアップファイルを、移行先のサーバーの
/backup/
フォルダーに配置します。共有ストレージをマウントするか、移行先のサーバーの/backup/
フォルダーにバックアップファイルをコピーします。 - ソースサーバーの電源を切断します。
以下のコマンドを入力してカスタマーポータルに登録して、サブスクリプションのアタッチし、必要なサブスクリプションだけを有効化します。
# subscription-manager register your_customer_portal_credentials # subscription-manager attach --pool=pool_ID # subscription-manager repos --disable=* # subscription-manager repos \ --enable=rhel-7-server-rpms \ --enable=rhel-server-rhscl-7-rpms \ --enable=rhel-7-server-satellite-maintenance-6-rpms \ --enable=rhel-7-server-satellite-6.6-rpms
satellite-clone
パッケージをインストールします。# satellite-maintain packages install satellite-clone
satellite-clone
ツールをインストールした後に、独自のデプロイメントに合わせて/etc/satellite-clone/satellite-clone-vars.yml
ファイルで設定を調節します。satellite-clone
ツールを実行します。# satellite-clone
- DHCP、DNS、TFTP、およびリモート実行サービスを再設定します。ソースの Satellite Server と競合しないように、クローンプロセスにより、ターゲットの Satellite Server でこのサービスが無効になります。
- Satellite Web UI で DHCP、DNS、TFTP を再設定し、有効にします。詳細は、『 オンラインネットワークからの Satellite Server のインストール』の「 Satellite Server での DNS、DHCP および TFTP の設定」を参照してください。
リモート実行を有効にします。
# satellite-installer --scenario satellite \ --enable-foreman-plugin-remote-execution \ --enable-foreman-proxy-plugin-remote-execution-ssh
-
ユーザー名
admin
とパスワードchangeme
で、Satellite Web UI にログインします。すぐに、管理者パスワードを変更して認証情報のセキュリティーを確保します。 - 正しい組織が選択されていることを確認します。
- コンテンツ > サブスクリプション に移動して、マニフェストの管理をクリックします。
- リフレッシュ ボタンをクリックして 終了 をクリックし、サブスクリプションの一覧に戻ります。
- 利用可能なサブスクリプションが正しいことを確認します。
-
/usr/share/satellite-clone/logs/reassociate_capsules.txt
ファイルの説明に従い、Capsules とライフサイクル環境の間の関係を復元します。 -
ターゲットサーバーの IP アドレスと新規ホスト名が一致するように、DNS など、ネットワーク設定をアップデートします。
satellite-clone
ツールにより、ホスト名をソースサーバーのホスト名に変更します。ホスト名を別のものに変更する場合には、satellite-change-hostname
ツールを使用してください。詳細は、『 Red Hat Satellite の管理』 の「Satellite または Capsule Server の名前 変更 」を参照してください。 -
ソースサーバーが
virt-who
デーモンを使用する場合は、ターゲットサーバーにインストールして設定します。ソースサーバーのディレクトリー/etc/virt-who.d/
にあるvirt-who
設定ファイルをすべて、ターゲットサーバーにある同じディレクトリーに移動します。詳細は、『 Red Hat Satellite での仮想マシンサブスクリプション の設定』を参照してください。
以下の章を使用してアップグレードを行った後に、安全にソースサーバーの使用を停止することができます。
第3章 Red Hat Satellite のアップグレード
高可用性設定に Satellite 6 をインストールしている場合は、Satellite 6.7 にアップグレードする前に Red Hat サポートにご連絡ください。
以下の手順を使用して既存の Red Hat Satellite を Red Hat Satellite 6.7 にアップグレードします。
アップグレードを行う前に「前提条件」を参照してください。
3.1. Satellite Server のアップグレード
このセクションでは、Satellite Server を 6.6 から 6.7 にアップグレードする方法を説明します。Red Hat Satellite Server 6.6 であれば、どのマイナーバージョンからでもアップグレードできます。
はじめに
- Satellite Server をアップグレードする前に、ファイアウォールの設定を確認してアップデートしてください。詳細は、『 オンラインネットワークからの Satellite Server のインストール 』の「ポートとファイアウォール の要件」を 参照してください。
- カスタマーポータルまたは Satellite Web UI からマニフェストを削除しないでください。削除すると、コンテンツホストからエンタイトルメントがすべて削除されます。
- アップグレードする前に、全 Foreman フックのバックアップを作成して、その後フックを削除します。アップグレードが完了し、Satellite が動作しているのを確認したら、フックを復元します。
- デフォルトテンプレートを変更する場合は、そのテンプレートのクローンを作成するか、エクスポートを行って、ファイルをバックアップします。クローンを作成することで、今後のアップデートまたはアップグレードが上書きされなくなるため、推奨されるのはクローン作成です。テンプレートの変更の有無を確認するには、アップグレード前に 履歴 を確認するか、アップグレード後に監査ログで変更を表示できます。Web UI で モニター > 監査 に移動し、テンプレートを検索すると、変更履歴を確認できます。エクスポートを使用する場合は、エクスポートしたテンプレートと、デフォルトテンプレートを比較し、手動で変更を適用して変更を復元します。
Capsule に関する留意事項
- Capsule Server のベースオペレーティングシステム、または Capsule Server リポジトリーへのアップデートをコンテンツビューで管理する場合は、アップデートしたコンテンツビューを公開する必要があります。
カスタムの証明書を実装している場合は、/root/ssl-build
ディレクトリーと、カスタム証明書に関連するソースファイルを作成したディレクトリーのコンテンツを保持する必要があります。
アップグレード時にこのファイルを保持できないと、アップグレードは失敗します。ファイルを削除してしまった場合は、アップグレードを進めるためにバックアップから復元する必要があります。
BASH シェルの設定
BASH シェルには、ハッシュテーブルのバイナリーの場所が保存されます。アップグレード時に satellite-maintain
スクリプトの場所が変更されますが、BASH にはこの変更が登録されないため、変更後にこのスクリプトを呼び出すと、satellite-maintain
が失敗します。
オプション: インストーラーの完了後に
satellite-maintain
が有効になるように、アップグレードする前に、BASH シェルでcheckhash
オプションを一時的に設定できます。BASH シェルで以下のようなコマンドを実行します。# shopt -s checkhash
アップグレードに成功または失敗した後に、現在実行しているすべての BASH シェルで、以下のコマンドを実行します。
# hash -d satellite-maintain 2> /dev/null
アップグレードシナリオ
- Red Hat コンテンツ配信ネットワークに接続している Satellite Server をアップグレードする場合は、「接続している Satellite Server のアップグレード」 に進みます。
- Red Hat コンテンツ配信ネットワークに接続していない Satellite Server をアップグレードする場合は、「切断されている Satellite Server のアップグレード」 に進みます。
自己登録の Satellite をアップグレードすることはできません。自己登録の Satellite は、Red Hat コンテンツ配信ネットワーク (CDN) に移行すればアップグレードを実行できます。自己登録の Satellite を CDN に移行する方法は、『Satellite 6.3 の Red Hat Satellite のアップグレードおよびアップデート』ガイドの「自己登録 Satellite の移行」を参照してください。
FIPS モード
FIPS モードを使用していない RHEL ベースのシステムから、FIPS モードを使用する RHEL ベースのシステムに、Satellite Server をアップロードできません。
FIPS モードの RHEL ベースシステムで Satellite Server を実行するには、FIPS モードで稼働する RHEL ベースのオペレーティングシステムを新規にプロビジョニングして、Satellite をインストールする必要があります。詳細は、『 オンラインネットワークからの Satellite Server のインストール』の「 システム要件 」を 参照してください。
3.1.1. 接続している Satellite Server のアップグレード
Satellite Server を Red Hat コンテンツ配信ネットワーク (CDN) に接続している場合は、以下の手順を実行します。
設定ファイルを手動で、または Hiera などのツールを使用して、カスタマイズした場合には、この変更内容は、アップグレード時またはアップデート時にインストールスクリプトを実行すると上書きされます。satellite-installer スクリプトで --noop
オプションを使用すると、変更をテストできます。詳細は、ナレッジベースソリューションの「How to use the noop option to check for changes in Satellite config files during an upgrade」を参照してください。
Satellite Server のアップグレード
バックアップを作成します。
- 仮想マシンで、スナップショットを作成します。
物理マシンで、バックアップを作成します。
バックアップに関する詳細は、『 Red Hat Satellite 6.6 管理 』ガイドの「Satellite Server および Capsule Server のバックアップ」を参照してください。
-
オプション:
/etc/zones.conf
または/etc/dhcp/dhcpd.conf
ファイルで DNS または DHCP の設定を手動で編集した場合には、設定ファイルをバックアップしてください。インストーラーはドメインまたはサブネットを 1 つしかサポートしないので、これらのバックアップから変更を復元しなければならない場合があります。 オプション: DNS または DHCP の設定ファイルを手動で編集し、変更を上書きしない場合は、以下のコマンドを実行します。
# satellite-installer --foreman-proxy-dns-managed=false \ --foreman-proxy-dhcp-managed=false
- Satellite Web UI で、ホスト > 検出されたホスト に移動します。検出されたホストページで、検出したホストの電源を切って削除します。組織の選択 メニューで、組織を順番に選択し、検出したホストの電源を切って削除するプロセスを繰り返します。アップグレードが完了したら、検出されたホストを再起動するようにメモします。
yum のキャッシュを消去します。
# yum clean all
satellite-maintain
が含まれるrubygem-foreman_maintain
パッケージがインストールされており、最新の状態になっていることを確認します。# yum install rubygem-foreman_maintain
利用可能なバージョンを確認して、希望のバージョンが表示されていることを確認します。
# satellite-maintain upgrade list-versions
ヘルスチェックオプションを使用して、システムをアップグレードする準備が完了しているかどうかを確認します。プロンプトが表示されたら、hammer の管理者ユーザー認証情報を入力して
satellite-maintain
を設定します。この変更は、/etc/foreman-maintain/foreman-maintain-hammer.yml
ファイルに適用されます。# satellite-maintain upgrade check --target-version 6.7
結果を確認し、アップグレードを実行する前に、強調表示されているエラー状態に対応します。
アップグレード時間は長くなるため、通信セッションの中断と再接続を可能にする
screen
などのユーティリティーを使用します。これにより、コマンドシェルに接続し続けなくてもアップグレードの進捗が確認できるようになります。screen コマンドの使用方法は、Red Hat ナレッジベース の「How do I use the screen command?」を参照してください。アップグレードコマンドを実行しているコマンドシェルへの接続がなくなった場合は、
/var/log/foreman-installer/satellite.log
ファイルのログメッセージで、プロセスが完全に終了したかどうかを確認できます。アップグレードを実行します。
# satellite-maintain upgrade run --target-version 6.7
カーネルパッケージが最後にアップデートされた日時を確認します。
# rpm -qa --last | grep kernel
オプション: 最後の再起動以降にカーネルがアップデートされた場合には、
satellite-maintain
サービスを停止して、システムを再起動します。# satellite-maintain service stop # reboot
BASH シェルを使用している場合は、アップグレードに成功または失敗した後に、以下を入力します。
# hash -d satellite-maintain service 2> /dev/null
- オプション: DNS または DHCP 設定ファイルを手動で編集した場合には、作成するバックアップを使用して、DNS と DHCP の設定ファイルに必要なすべての変更を確認し、復元します。
以前の手順で変更を加えた場合には、
satellite-maintain
サービスを再起動します。# satellite-maintain service restart
OpenSCAP プラグインがインストールされているにもかかわらず、デフォルトの OpenSCAP コンテンツが利用できない場合は、以下のコマンドを実行します。
# foreman-rake foreman_openscap:bulk_upload:default
3.1.2. 切断されている Satellite Server のアップグレード
Red Hat コンテンツ配信ネットワークに接続していない Satellite Server には、この手順を使用します。
設定ファイル手動または Hiera などのツールを使用してカスタマイズする場合に、この変更内容はアップグレードまたはアップデート時に satellite-maintain
コマンドを入力すると上書きされます。satellite-installer
コマンドを --noop
オプションを指定して使用し、アップグレードまたはアップデート時に適用された変更を確認します。詳細は、ナレッジベースソリューションの「How to use the noop option to check for changes in Satellite config files during an upgrade」を参照してください。
作業開始前の準備
- Satellite Server をアップグレードする前に、ファイアウォールの設定を確認してアップデートしてください。詳細は、『 オフラインネットワークからの Satellite Server のインストール 』の「ポートとファイアウォール の要件」を 参照してください。
- カスタマーポータルまたは Satellite Web UI からマニフェストを削除しないでください。削除すると、コンテンツホストからエンタイトルメントがすべて削除されます。
- アップグレードする前に、全 Foreman フックのバックアップを作成して、その後フックを削除します。アップグレードが完了し、Satellite が動作しているのを確認できるまで、フックを元に戻さないでください。
カスタムの証明書を実装している場合は、/root/ssl-build
ディレクトリーと、カスタム証明書に関連するソースファイルを作成したディレクトリーのコンテンツを保持する必要があります。
アップグレード時にこのファイルを保持できないと、アップグレードは失敗します。ファイルを削除してしまった場合は、アップグレードを進めるためにバックアップから復元する必要があります。
切断されている Satellite Server のアップグレード
バックアップを作成します。
- 仮想マシンで、スナップショットを作成します。
- 物理マシンで、バックアップを作成します。
アップグレード前スクリプトは競合を検出し、アップグレード後に登録解除および削除できる Satellite Server の重複エントリーがあるホストをリストできます。また、組織に割り当てられていないホストを検出します。ホスト > すべてのホスト で、組織の関連付けがないホストがリストされ、同じ名前のコンテンツホストに組織がすでに関連付けられている場合、コンテンツホストは自動的に登録解除されます。これは、アップグレード前にこのようなホストを組織に関連付けることによって回避できます。
アップグレード前のチェックスクリプトを実行して、アップグレード後に削除できるホストの一覧を取得します。関連付けられていないホストが検出された場合は、アップグレードの前に組織にそれらのホストを関連付けることが推奨されます。
# foreman-rake katello:upgrade_check
アップグレードチェックで、タスクが実行中であることが原因の障害が報告された場合は、タスクが完了するまで待機することが推奨されます。一部のタスクはキャンセルできますが、Red Hat ナレッジベースソリューション「How to manage paused tasks on Red Hat Satellite 6」に目を通して、安全にキャンセルできるタスクとできないタスクについて理解する必要があります。
-
オプション:
/etc/zones.conf
または/etc/dhcp/dhcpd.conf
ファイルで DNS または DHCP の設定を手動で編集した場合には、設定ファイルをバックアップしてください。インストーラーはドメインまたはサブネットを 1 つしかサポートしないので、これらのバックアップから変更を復元しなければならない場合があります。 オプション: DNS または DHCP の設定ファイルを手動で編集し、変更を上書きしない場合は、以下のコマンドを実行します。
# satellite-installer --foreman-proxy-dns-managed=false \ --foreman-proxy-dhcp-managed=false
-
Satellite Web UI で、ホスト > 検出されたホスト に移動します。検出されたホストが利用可能な場合は無効にし、
検出されたホスト
ページにあるエントリーをすべて削除します。必要に応じて、組織設定メニューから、その他の組織を順番に選択し、すべてのエントリーを削除します。アップグレードが完了したら、検出されたホストを再起動します。 - すべての外部 Capsule Server が組織に割り当てられていることを確認します。割り当てられていない場合、これらのサーバーは、ホスト統合の変更により登録解除された可能性があります。
以前のリポジトリーを削除します。
# rm /etc/yum.repos.d/*
satellite-maintain
サービスを停止します。# satellite-maintain service stop
- 『 オフラインネットワークからの Satellite Server のインストール』ガイド の「バイナリー DVD イメージのダウンロード 」の手順に従って、最新の ISO ファイルを取得します。
-
『 オフライン ネットワークからの Satellite Server のインストール』ガイドの「オフラインリポジトリーでベースシステムの設定」の手順に従い、マウントポイントとして使用 するディレクトリーを作成し、ISO イメージをマウントして、
rhel7-server
リポジトリーを 設定します。この段階では、パッケージのインストールやアップデートはしないでください。 ISO ファイルから Satellite 6.7 リポジトリーを設定します。
Red Hat Satellite パッケージ用に ISO ファイルのリポジトリーデータファイルをコピーします。
# cp /media/sat6/media.repo /etc/yum.repos.d/sat6.repo
/etc/yum.repos.d/sat6.repo
ファイルを編集します。# vi /etc/yum.repos.d/sat6.repo
デフォルトの
InstallMedia
リポジトリー名をSatellite-6.7
に変更します。[Satellite-6.7]
baseurl
ディレクティブを追加します。baseurl=file:///media/sat6/
ISO ファイルからの Red Hat Software Collections リポジトリーを設定します。
Red Hat Software Collections パッケージ用に ISO ファイルのリポジトリーデータファイルをコピーします。
# cp /media/sat6/RHSCL/media.repo /etc/yum.repos.d/RHSCL.repo
/etc/yum.repos.d/RHSCL.repo
ファイルを編集します。# vi /etc/yum.repos.d/RHSCL.repo
デフォルトの
InstallMedia
リポジトリー名をRHSCL
に変更します。[RHSCL]
baseurl
ディレクティブを追加します。baseurl=file:///media/sat6/RHSCL/
ISO ファイルからの Red Hat Satellite Maintenance リポジトリーを設定します。
Red Hat Satellite Maintenance パッケージ用に ISO ファイルのリポジトリーデータファイルをコピーします。
# cp /media/sat6/sat-maintenance/media.repo /etc/yum.repos.d/sat-maintenance.repo
/etc/yum.repos.d/sat-maintenance.repo
ファイルを編集します。# vi /etc/yum.repos.d/sat-maintenance.repo
デフォルトの
InstallMedia
リポジトリー名をSatellite-Maintenance
に変更します。[Satellite-Maintenance]
baseurl
ディレクティブを追加します。baseurl=file:///media/sat6/sat-maintenance/
オプション: カスタムの Apache サーバー設定を適用している場合に、アップグレードを実行すると、カスタムの設定がインストール時のデフォルト設定に戻る点に注意してください。
アップグレード時に適用された変更をプレビューするには、
--noop
(操作なし) オプションを指定してsatellite-installer
コマンドを実行します。これらの変更は、以下の手順でsatellite-maintain upgrade
コマンドを入力すると適用します。次の行を
/etc/httpd/conf/httpd.conf
設定ファイルに追加します。Include /etc/httpd/conf.modules.d/*.conf
httpd
サービスを再起動します。# systemctl restart httpd
postgresql
データベースサービスおよびrh-mongodb34-mongod
データベースサービスを起動します。# systemctl start postgresql # systemctl start rh-mongodb34-mongod
--noop
オプションを指定して、satellite-installer
コマンドを入力します。# satellite-installer --scenario satellite --upgrade --verbose --noop
アップグレード時に適用された変更をプレビューするには、
/var/log/foreman-installer/satellite.log
を確認します。設定ファイルへの変更を示す+++
と---
シンボルの場所を特定します。--noop
オプションを指定してsatellite-installer
コマンドを入力しても、Satellite に変更は適用されませんが、モジュール内の Puppet リソースによっては変更が適用されることを想定している場合があり、エラーのメッセージが表示される可能性があります。satellite-maintain
サービスを停止します。# satellite-maintain service stop
アップグレード時間は長くなるため、通信セッションの中断と再接続を可能にする
screen
などのユーティリティーを使用します。これにより、コマンドシェルに接続し続けなくてもアップグレードの進捗が確認できるようになります。screen コマンドの使用方法は、Red Hat ナレッジベース の「How do I use the screen command?」を参照してください。アップグレードコマンドを実行しているコマンドシェルへの接続がなくなった場合は、
/var/log/foreman-installer/satellite.log
のログで、プロセスが完全に終了したかどうかを確認できます。yum のキャッシュを消去します。
# yum clean all
satellite-maintain
が含まれるrubygem-foreman_maintain
パッケージがインストールされており、最新の状態になっていることを確認します。# yum install rubygem-foreman_maintain
利用可能なバージョンを確認して、希望のバージョンが表示されていることを確認します。
# satellite-maintain upgrade list-versions
ヘルスチェックオプションを使用して、システムをアップグレードする準備が完了しているかどうかを確認します。プロンプトが表示されたら、hammer の管理者ユーザー認証情報を入力して
satellite-maintain
を設定します。この変更は、/etc/foreman-maintain/foreman-maintain-hammer.yml
ファイルに適用されます。# satellite-maintain upgrade check --target-version 6.7 \ --whitelist="repositories-validate,repositories-setup"
結果を確認し、アップグレードを実行する前に、強調表示されているエラー状態に対応します。
アップグレードを実行します。
# satellite-maintain upgrade run --target-version 6.7 \ --whitelist="repositories-validate,repositories-setup"
警告config サブディレクトリーを含むディレクトリーからコマンドを実行すると、以下のエラーが発生します。
ERROR: Scenario (config/satellite.yaml) was not found, can not continue.
このような場合は、root ユーザーのホームディレクトリーに移動し、コマンドを再実行します。
パッケージが古いか、足りないためにスクリプトに失敗した場合には、これらのパッケージを個別にダウンロードしてインストールする必要があります。詳細は、『 オフラインネットワークからの Satellite Server のインストール』ガイドの「 パッケージの依存関係エラーの解決 」セクションを 参照してください。
BASH シェルを使用している場合は、アップグレードに成功または失敗した後に、以下を入力します。
# hash -d satellite-maintain service 2> /dev/null
カーネルパッケージが最後にアップデートされた日時を確認します。
# rpm -qa --last | grep kernel
オプション: 最後の再起動以降にカーネルがアップデートされた場合には、
satellite-maintain
サービスを停止して、システムを再起動します。# satellite-maintain service stop # reboot
- オプション: DNS または DHCP 設定ファイルを手動で編集した場合には、作成したバックアップを使用して、DNS と DHCP の設定ファイルに必要なすべての変更を確認し、復元します。
以前の手順で変更を加えた場合には、
satellite-maintain
サービスを再起動します。# satellite-maintain service restart
OpenSCAP プラグインがインストールされているにもかかわらず、デフォルトの OpenSCAP コンテンツが利用できない場合は、以下のコマンドを実行します。
# foreman-rake foreman_openscap:bulk_upload:default
- Satellite Web UI で 設定 > 検出ルール に移動し、選択した組織および場所を検出ルールに関連付けます。
3.2. 新しいリポジトリーの同期
Capsule Server とSatellite クライアントをアップグレードする前に、新しい 6.7 リポジトリーを有効にして同期する必要があります。
手順
- Satellite Web UI で、コンテンツ > Red Hat リポジトリー に移動します。
- 推奨のリポジトリー を、オン の位置に切り替えます。
結果の一覧から、以下のリポジトリーを展開して、有効化 アイコンをクリックして、リポジトリーを有効にします。
- Satellite クライアントをアップグレードするには、クライアントが使用するすべての Red Hat Enterprise Linux バージョンで Red Hat Satellite Tools 6.7 リポジトリーを有効にします。
Capsule Server を使用している場合に、Capsule Server をアップグレードするには、以下のリポジトリーも有効にします。
Red Hat Satellite Capsule 6.7(RHEL 7 Server 用)(RPM)
Red Hat Satellite Maintenance 6 (RHEL 7 Server 用) (RPM)
Red Hat Ansible Engine 2.8 RPMs for Red Hat Enterprise Linux 7 Server
Red Hat Software Collections RPMs for Red Hat Enterprise Linux 7 Server
注記6.7 リポジトリーが利用できない場合には、サブスクリプションマニフェストをリフレッシュします。コンテンツ > サブスクリプション に移動して マニフェストの管理 をクリックし、リフレッシュ をクリックしてください。
- コンテンツ > 同期ステータス に移動します。
- 製品の横にある矢印をクリックして、利用可能なリポジトリーを表示します。
- 6.7 のリポジトリーを選択します。
今すぐ同期 をクリックします。
重要リポジトリーを同期しようとするとエラーが発生する場合に、マニフェストをリフレッシュしてください。問題が継続する場合には、サポート依頼を起票してください。カスタマーポータルまたは Satellite Web UI からマニフェストを削除しないでください。削除してしまうと、コンテンツホストのエンタイトルメントがすべて削除されてしまいます。
- コンテンツビューを使用して Capsule Server のベースオペレーティングシステムへのアップデートを制御する場合、それらのコンテンツビューを新しいリポジトリーでアップデートし、アップデート済みのバージョンを公開して、プロモートします。詳細は、『 コンテンツ管理 ガイド』の「コンテンツビュー の管理 」を参照してください。
3.3. Capsule Server のアップグレード
このセクションは、Capsule Server を 6.6 から 6.7 にアップグレードする方法を説明します。
はじめに
- Capsule Server をアプリケーションする前に Satellite Server をアップロードする必要があります。
- Red Hat Satellite Capsule 6.7 リポジトリーが Satellite Server で有効になっており、同期されていることを確認します。
- Satellite Server 上の必要なリポジトリーを必ず同期してください。詳細は、「新しいリポジトリーの同期」 を参照してください。
- コンテンツビューを使用して Capsule Server のベースオペレーティングシステムへのアップデートを制御する場合、それらのコンテンツビューを新しいリポジトリーでアップデートし、アップデート済みのバージョンを公開します。詳細は、『 コンテンツ管理 ガイド』の「コンテンツビュー の管理 」を参照してください。
- 新たにアップグレードした Satellite Server に、Capsule のベースシステムが’登録されていることを確認します。
- 新たにアップグレードした Satellite Server で、Capsule の組織と場所が正しく設定されていることを確認します。
- Capsule Server をアップグレードする前に、ファイアウォールの設定を確認してアップデートしてください。詳細は、『 Capsule Server のインストール 』 の「ポートとファイアウォールの要件 」を参照してください。
カスタムの証明書を実装している場合は、/root/ssl-build
ディレクトリーと、カスタム証明書に関連するソースファイルを作成したディレクトリーのコンテンツを保持する必要があります。
アップグレード時にこのファイルを保持できないと、アップグレードは失敗します。ファイルを削除してしまった場合は、アップグレードを進めるためにバックアップから復元する必要があります。
Capsule Server のアップグレード
バックアップを作成します。
- 仮想マシンで、スナップショットを作成します。
物理マシンで、バックアップを作成します。
バックアップに関する詳細は、『 Red Hat Satellite 6.6 管理 』ガイドの「Satellite Server および Capsule Server のバックアップ」を参照してください。
-
オプション:
/etc/zones.conf
または/etc/dhcp/dhcpd.conf
ファイルで DNS または DHCP の設定を手動で編集した場合には、設定ファイルをバックアップしてください。インストーラーはドメインまたはサブネットを 1 つしかサポートしないので、これらのバックアップから変更を復元しなければならない場合があります。 オプション: DNS または DHCP の設定ファイルを手動で編集し、変更を上書きしない場合は、以下のコマンドを実行します。
# satellite-installer --foreman-proxy-dns-managed=false \ --foreman-proxy-dhcp-managed=false
すべてのリポジトリーを無効にします。
# subscription-manager repos --disable "*"
新規リポジトリーを有効にするには、以下のコマンドを入力します。
Red Hat Software Collections リポジトリーは、リモート実行機能を含む一部の Red Hat Satellite 機能で必要な新しいバージョンの Ruby を提供します。Satellite Tools 6.7 リポジトリーには、エラータを管理するための通信サービスを提供する
katello-host-tools
およびkatello-agent
が含まれます。# subscription-manager repos \ --enable rhel-7-server-rpms \ --enable rhel-7-server-satellite-capsule-6.7-rpms \ --enable rhel-server-rhscl-7-rpms \ --enable rhel-7-server-satellite-tools-6.7-rpms \ --enable rhel-7-server-satellite-maintenance-6-rpms \ --enable rhel-7-server-ansible-2.8-rpms
-
Satellite Web UI で、ホスト > 検出されたホスト に移動します。検出されたホストがある場合は、そのホストの電源を切り、
検出されたホスト
ページに表示されているすべてのエントリーを削除します。必要に応じて、組織設定メニューから、その他の組織を順番に選択し、すべてのエントリーを削除します。アップグレードが完了したら、検出されたホストを再起動します。 リポジトリーキャッシュを削除します。
# yum clean all
satellite-maintain
サービスを停止します。# satellite-maintain service stop
BZ#1649764 が解決されるまで、
gofer
パッケージをアップデートしてください。# yum update gofer
goferd を再起動します。
# systemctl restart goferd
すべてのパッケージを更新します。
# yum update
検出されたホストのプロキシーとして Capsule Server を使用する場合は、検出プラグインをインストールします。
# yum install rubygem-smart_proxy_discovery.noarch
Capsule Server で
foreman_url
の設定が正しいことを確認します。# grep foreman_url /etc/foreman-proxy/settings.yml
Satellite Server の完全修飾ドメイン名が表示されます。
--upgrade
オプションを指定してインストーラースクリプトを実行してアップグレードを実行します。# satellite-installer --scenario capsule --upgrade
警告config サブディレクトリーを含むディレクトリーからコマンドを実行すると、以下のエラーが発生します。
ERROR: Scenario (config/capsule.yaml) was not found, can not continue.
このような場合は、root ユーザーのホームディレクトリーに移動し、コマンドを再実行します。
カーネルパッケージが最後にアップデートされた日時を確認します。
# rpm -qa --last | grep kernel
オプション: 最後の再起動以降にカーネルがアップデートされた場合には、
satellite-maintain
サービスを停止して、システムを再起動します。# satellite-maintain service stop # reboot
- 作成しておいたバックアップを使用して、DNS と DHCP の設定ファイルに必要なすべての変更を確認し、復元します。
- カスタムリポジトリーを使用する場合は、アップグレードの完了後に、これらのカスタムリポジトリーを有効化することを確認してください。
- Satellite Server で foreman-discovery パッケージをアップグレードし、アップグレード前にシャットダウンしたホストを有効にします。
3.4. Satellite クライアントのアップグレード
Satellite Tools 6.7 リポジトリーには、エラータを管理するための通信サービスを提供する katello-agent
および katello-host-tools
が含まれます。
Katello エージェントは非推奨で、今後の Satellite のバージョンで削除される点に注意してください。ワークロードを移行して、リモート実行機能を使用してクライアントをリモートでアップデートします。詳細は、『ホストの管理 』ガイドの「 Goferd および Katello エージェント を使用しないホスト管理 」を参照してください。
現時点では、Satellite Tools 6.7 リポジトリーに含まれる、Satellite 6.6 バージョンの katello-agent
などのクライアントライブラリーは、Satellite 6.7 で正式にテストされていないため、サポート対象外となります。
katello-agent
および goferd を使用したデプロイメントの場合は、すべてのクライアントを katello-agent
の新しいバージョンにアップデートします。katello-agent
および goferd を使用しないデプロイメントの場合は、すべてのクライアントを katello-host-tools
の新しいバージョンにアップデートします。お使いのクライアントが Satellite Server との互換性を完全に確保できるように、できるだけ早くこの作業を完了してください。
前提条件
- Satellite Server がアップグレードされている。
- Satellite で、新しい Satellite Tools 6.7 リポジトリーを有効にしておく。
- Satellite で、新しいリポジトリーを同期しておく。
-
以前にクライアントに
katello-agent
をインストールしたことがなく、インストールする場合は、手動の方法を使用します。詳細は、Satellite クライアントの手動アップグレード を参照してください。
カスタムの証明書を実装している場合は、/root/ssl-build
ディレクトリーと、カスタム証明書に関連するソースファイルを作成したディレクトリーのコンテンツを保持する必要があります。
アップグレード時にこのファイルを保持できないと、アップグレードは失敗します。ファイルを削除してしまった場合は、アップグレードを進めるためにバックアップから復元する必要があります。
一括リポジトリー設定 UI を使用した Satellite クライアントのアップグレード
- Satellite Web UI で、ホスト > コンテンツホスト に移動し、アップグレードするコンテンツホストを選択します。
- アクションの選択 一覧から リポジトリーセットの管理 を選択します。
- リポジトリーセットの 管理 の 一覧から、Red Hat Satellite Tools 6.6 のチェックボックスを選択します。
- アクションの選択 一覧から Override to Disabled (「無効」に上書き) を選択し、Done (完了) をクリックします。
- プロセスが完了したら、以前の手順で使用した同じホストセットの アクションの選択 一覧から、リポジトリーセットの管理 を選択します。
- リポジトリーセットの管理 の一覧から、Red Hat Satellite Tools 6.7 のチェックボックスを選択します。
- アクションの選択 一覧から Override to Enabled (「有効」に上書き) を選択し、Done (完了) をクリックします。
- プロセスが完了したら、以前の手順で使用した同じホストセットの アクションの選択 リストから、パッケージの管理 を選択します。
パッケージ 検索フィールドに、設定に応じて以下のいずれかのオプションを入力します。
-
お使いのデプロイメントで
katello-agent
および goferd を使用する場合は、katello-agent
と入力します。 -
お使いのデプロイメントで
katello-agent
および goferd を使用しない場合は、katello-host-tools
と入力します。
-
お使いのデプロイメントで
- BZ#1649764 が解決されるまで、アップデート リストで リモート実行経由 を選択する必要があります。Katello エージェントを使用してパッケージをアップデートすると、これによりクライアントと Satellite または Capsule Server 間の通信が中断され、アップデートが失敗することから、リモート実行経由の選択が必要です。詳細は、『ホスト の管理』ガイドの「 ホストでのジョブの実行 」を参照し てください。
Satellite クライアントの手動アップグレード
- クライアントシステムにログインします。
以前のバージョンの Satellite のリポジトリーを無効にします。
# subscription-manager repos \ --disable rhel-7-server-satellite-tools-6.6-rpms
このバージョンの Satellite 向け Satellite Tools 6.7 リポジトリーを有効にします。
# subscription-manager repos \ --enable=rhel-7-server-satellite-tools-6.7-rpms
お使いの設定に応じて、以下のいずれかの手順を実行します。
お使いのデプロイメントで
katello-agent
および goferd を使用する場合は、以下のコマンドを入力してkatello-agent
をインストールまたはアップグレードします。# yum install katello-agent
お使いのデプロイメントで
katello-agent
および goferd を使用しない場合は、以下のコマンドを入力してkatello-host-tools
をインストールまたはアップグレードします。# yum install katello-host-tools
第4章 アップグレード後のタスク
本セクションで紹介する手順の一部はオプションです。お使いのインストールに関連する手順のみを選択できます。
PXE ベースの検出プロセスを使用する場合には、Satellite の ホスト > 検出されたホスト ページに表示させるホストで、Satellite または Capsule Server 上で Discovery アップグレードの手順を実行する必要があります。
4.1. Discovery のアップグレード
このセクションでは、PXE ブートを使用して Satellite Server に登録するホストに渡した PXELinux テンプレートとブートイメージをアップデートする方法を説明します。
Satellite 6.4 以降、プロビジョニングテンプレートには別途サブネットが関連付けられるので、対象のサブネットに対して TFTP Capsule を使用するように初期設定しないようにしてください。アップグレード後にサブネットを作成する場合には、特に Satellite また Capsule が Discovery テンプレートにプロキシーサービスを提供できるようにしてから、テンプレート Capsule を使用するように、検出されたホストで全ホストを設定する必要があります。
アップグレード中は、TFTP プロキシーが設定された各サブネットが有効化されている場合には、テンプレート Capsule を TFTP Capsule と同じに設定してください。アップグレード後には、すべてのサブネットでこれが正しく設定されていることを確認してください。
ホストで PXE ブートを使用しない場合には、Satellite に新規ホストを検出させるために、これらの手順は、必要ありません。
4.1.1. Satellite Server での Discovery のアップグレード
Satellite Web UI で Discovery テンプレートをアップデートします。
- ホスト > プロビジョニングテンプレート に移動します。
-
PXELinux global default
行で クローン をクリックします。 -
名前 フィールドに、テンプレートの新しい名前を入力します (例:
ACME PXE global default
)。 -
テンプレートエディターフィールドで、
ONTIMEOUT local
行をONTIMEOUT discovery
に変更し、送信 をクリックします。 - 管理 > 設定 に移動します。
-
Global default PXELinux template
の 値 をクリックします。 - 新しく作成したテンプレートの名前を選択し、チェックボタンをクリックします。
- ホスト > プロビジョニングテンプレート に移動します。
- PXE デフォルトのビルド をクリックして、OK をクリックします。
- Satellite Web UI で 設定 > 検出ルール に移動し、選択した組織および場所を検出ルールに関連付けます。
4.1.2. Capsule Server での Discovery のアップグレード
Satellite Server で、Foreman Discovery パッケージが最新であることを確認します。
# yum upgrade tfm-rubygem-foreman_discovery
以前の手順でアップデートが行われた場合には、
satellite-maintain
サービスを再起動します。# satellite-maintain service restart
検出されたホストでプロビジョニングネットワークに接続した Satellite Capsule の Discovery イメージ、または検出されたホストに TFTP サービスを提供する Satellite Capsule の Discovery イメージをアップグレードします。
# yum upgrade foreman-discovery-image
同じインスタンスに、Proxy サービスを提供するパッケージをインストールして、
foreman-proxy
サービスを再起動します。# yum install rubygem-smart_proxy_discovery # service foreman-proxy restart
- Satellite Web UI で、インフラストラクチャー > Capsule に移動して、関連する Capsule の機能コラムに Discovery が表示されていることを確認します。必要に応じて、アクション ドロップダウンメニューから リフレッシュ を選択します。
インフラストラクチャー > サブネット に移動し、検出を使用する各サブネットで以下を行います。
- サブネット名をクリックします。
- Capsule タブで、上で設定した Capsule に Discovery Capsule が設定されているのを確認します。
4.1.3. サブネットにテンプレート Capsule があることの確認
検出されたホストが含まれる全サブネットに、テンプレート Capsule が設定されていることを確認します。
- Satellite Web UI で、インフラストラクチャー > Capsule に移動します。
- 確認するサブネットを選択します。
- Capsule タブで、テンプレート Capsule が、このサブネットに設定されていることを確認します。
テンプレート Capsule を使用したサブネット の設定に関する詳細は、『 Red Hat Satellite ホストの管理 』ガイドの「Discovery サブネットの設定」を参照してください。
4.2. virt-who のアップグレード
Satellite Server または Capsule Server に virt-who がインストールされている場合は、Satellite Server または Capsule Server のアップグレード時に一緒にアップグレードされるため、追加の作業は必要ありません。これ以外の作業は必要ありません。virt-who を他の場所にインストールしている場合は、手動でアップグレードする必要があります。
はじめに
Satellite Server または Capsule Server に登録しているホストに virt-who がインストールされている場合は、最初にホストを、Satellite Tools 6.7 リポジトリーで利用可能な最新パッケージにアップグレードします。ホストのアップグレードに関する詳細は、「Satellite クライアントのアップグレード」を参照してください。
virt-who の手動アップグレード
virt-who をアップグレードします。
# yum upgrade virt-who
virt-who サービスを再起動して、新しいバージョンを有効にします。
# systemctl restart virt-who.service
4.3. 以前のバージョンの Satellite Tools リポジトリーの削除
Satellite 6.7 へのアップグレードが完了したら、コンテンツビューから Red Hat Satellite Tools 6.6 リポジトリーを削除して、無効にすることができます。
バージョン 6.6 の Satellite Tools リポジトリーを無効にします。
- Satellite Web UI で、コンテンツ > Red Hat リポジトリー に移動します。
- 有効化されたリポジトリー エリアで、Red Hat Satellite Tools 6.6 for RHEL 7 Server RPMs x86_64 を探し出します。
- 右側の 無効化 アイコンをクリックします。
リポジトリーがまだコンテンツビューに含まれている場合には、無効にできません。スケジュールされているタスクにより、無効にされたリポジトリーからパッケージが自動的に削除されます。
4.4. MongoDB スペースの確保
MongoDB データベースは、特に負荷の高いデプロイメントにおいて、大容量のディスク領域を使用できます。この手順を使用して、Satellite でこのディスク領域の一部を確保します。
前提条件
- MongoDB データベースをバックアップします。Satellite の バックアップに関する詳細は、「Satellite Server および Capsule Server の バックアップ」を参照してください。
手順
Pulp サービスを停止します。
# satellite-maintain service stop --only \ pulp_celerybeat.service,pulp_resource_manager.service,pulp_streamer.service,pulp_workers.service,httpd
MongoDB シェルにアクセスします。
# mongo pulp_database
修復前の MongoDB のディスク領域の使用量を確認します。
> db.stats()
- 現在の MongoDB データベースに 2 GB を足したサイズに相当する空のディスク領域があることを確認します。MongoDB データベースを含むボリュームに十分な領域がない場合、別のボリュームをマウントし、これを修復に使用することができます。
修復コマンドを入力します。データベースのサイズによっては、修復コマンドは、その他すべての操作をブロックし、完了までに時間がかかる場合があることに注意してください。
> db.repairDatabase()
修復後の MongoDB のディスク領域の使用量を確認します。
> db.stats()
MongoDB シェルを終了します。
> exit
Pulp サービスを開始します。
# satellite-maintain service start
4.5. PostgreSQL 領域の確保
PostgreSQL データベースは、特に負荷の高いデプロイメントにおいて、大容量のディスク領域を使用できます。この手順を使用して、Satellite でこのディスク領域の一部を確保します。
手順
postgresql
サービス以外の全サービスを停止します。# satellite-maintain service stop --exclude postgresql
postgres
ユーザーに切り替えてデータベースの領域を確保します。# su - postgres -c 'vacuumdb --full --dbname=foreman'
Vacuum が完了したら、他のサービスを開始します。
# satellite-maintain service start
4.6. MongoDB ストレージエンジンのアップグレード
アップグレードを完了したら、オプションで MongoDB ストレージエンジンを WiredTiger にアップグレードできます。すでに WiredTiger を使用する場合は、アップグレード後にこの手順を実行する必要はありません。WiredTiger の使用を希望する場合は、Satellite Server と全 Capsule Server で、以下の手順を繰り返し実行する必要があります。WiredTiger ストレージエンジンに関する詳細は、MongoDB マニュアル の WiredTiger Storage Engine を参照してください。
前提条件
このストレージエンジンをアップグレードする前に、次の条件が満たされていることを確認します。
- MongoDB ストレージのバックアップが作成されている。
-
/var/tmp
ディレクトリーに最低でも/var/lib/mongodb
ディレクトリーの 2 倍の容量がある。 - オプション: トラフィックの多い Satellite 環境では、MongoDB 修復を使用してディスク領域を確保する。詳細は、KCS アーティクル「How to compact MongoDB files and/or reclaim disk space in "/var/lib/mongodb" in Satellite 6?を参照してください。
- オプション: トラフィックの多い Satellite 環境では、MongoDB コンパクトを使用して、ディスク領域を確保する。詳細は、MongoDB マニュアルの compact を参照してください。
オプション: 現在使用中の MongoDB のバージョンを確認するには、以下のコマンドを入力する。
# mongo pulp_database --eval "db.serverStatus().storageEngine"
手順
MongoDB ストレージエンジンをアップグレードするには、Satellite Server と全 Capsule Server で以下のコマンドを入力します。
# satellite-installer --upgrade-mongo-storage-engine
4.7. テンプレート、パラメーター、ルックアップキーおよび値のアップデート
アップグレードプロセスで、Satellite は Satellite 6.7 で非推奨となったマクロの場所を特定し、デフォルトの {Product} テンプレート、パラメーター、ルックアップキーおよび値の以前の構文を新しい構文に変換します。ただし、{Product} は、以前に作成したカスタムテンプレートや、クローンしたテンプレートに含まれる以前の構文は変換しません。
このプロセスは、以下のような単純なテキスト置換を使用します。
@host.params['parameter1'] -> host_param('parameter1') @host.param_true?('parameter1') -> host_param_true?('parameter1') @host.param_false?('parameter1') -> host_param_false?('parameter1') @host.info['parameters'] -> host_enc['parameters']
Satellite で複製されたテンプレートを使用する場合、複製されたテンプレートが Satellite の元のテンプレートの最新バージョンと異なるかどうかを確認します。同じテンプレートの構文は、Satellite のバージョンによって異なる場合があります。複製されたテンプレートに古い構文が含まれている場合は、テンプレートの最新バージョンに一致するように構文をアップデートします。
アップグレード中に、このテキスト置換でファイルの変数を破損したり、省略したりしないように、以前の構文のテンプレート、パラメーター、ルックアップキーおよび値のすべてを確認して、手動で置き換えます。
以下のエラーは、アップグレード後にファイル内に以前の構文が残っていることが原因で発生します。
undefined method '#params' for Host::Managed::Jail
Fixing the outdated subscription_manager_registration snippet
Satellite 6.4 以降では、subscription_manager_registration
スニペットの代わりに redhat_register
スニペットを使用します。
Satellite 6.3 以前からアップグレードする場合は、以下のようにカスタムテンプレートの subscription_manager_registration
スニペットを置き換えます。
<%= snippet "subscription_manager_registration" %> ↓ <%= snippet 'redhat_register' %>
4.8. 定義済みプロファイルを使用した Satellite Server の調整
Satellite のデプロイメントに 5000 台を超えるホストが含まれる場合には、事前定義済みのチューニングプロファイルを使用して Satellite Server のパフォーマンスを向上できます。
Capsule では tuning プロファイルを使用できない点に注意してください。
Satellite が管理するホストの数と利用可能なハードウェアリソースに応じて、プロファイルの 1 つを選択できます。tuning プロファイルは、/usr/share/foreman-installer/config/foreman.hiera/tuning/sizes
ディレクトリーにあります。
--tuning
オプションを指定して satellite-installer
コマンドを実行すると、デプロイメント設定が以下の順番で Satellite Server に適用されます。
-
/usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml
ファイルで定義したデフォルトの tuning プロファイル -
/usr/share/foreman-installer/config/foreman.hiera/tuning/sizes/
ディレクトリーで定義され、デプロイメントに適用する tuning プロファイル -
/etc/foreman-installer/custom-hiera.yaml
ファイルの設定
/etc/foreman-installer/custom-hiera.yaml
ファイルで定義した設定は、tuning プロファイルで定義した設定を上書きすることに注意してください。したがって、tuning プロファイルを適用する前に、/usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml
のデフォルトの tuning プロファイルに定義されている設定、適用する tuning プロファイル、および /etc/foreman-installer/custom-hiera.yaml
ファイルを比較して、重複する設定内容を /etc/foreman-installer/custom-hiera.yaml
ファイルから削除する必要があります。
- default
管理対象ホスト数: 0-5000
RAM: 20G
CPU コア数: 4
- medium
管理対象ホスト数: 5001-10000
RAM: 32G
CPU コア数: 8
- large
管理対象ホスト数: 10001-20000
RAM: 64G
CPU コア数: 16
- extra-large
管理対象ホスト数: 20001-60000
RAM: 128G
CPU コア数: 32
- extra-extra-large
管理対象ホスト数: 60000+
RAM: 256G
CPU コア数: 48+
手順
お使いの Satellite デプロイメントの tuning プロファイルを設定するには、以下の手順を実行します。
Satellite Server で、
/etc/foreman-installer/custom-hiera.yaml
ファイルをcustom-hiera.original
にバックアップします。/etc/foreman-installer/custom-hiera.yaml
ファイルが破損した場合には、バックアップファイルを使用して、ファイルを元の状態に戻します。# cp /etc/foreman-installer/custom-hiera.yaml \ /etc/foreman-installer/custom-hiera.original
-
/usr/share/foreman-installer/config/foreman.hiera/tuning/common.yaml
のデフォルト tuning プロファイルの定義と、/usr/share/foreman-installer/config/foreman.hiera/tuning/sizes/
に適用する tuning プロファイルの定義を確認します。/etc/foreman-installer/custom-hiera.yaml
ファイルの設定内容と比較して、/etc/foreman-installer/custom-hiera.yaml
ファイルで重複設定を削除します。 適用するプロファイルに対して、
--tuning
オプションを指定してsatellite-installer
コマンドを入力します。たとえば、medium tuning プロファイル設定を適用するには、以下のコマンドを入力します。# satellite-installer --tuning medium
第5章 Satellite Server、Capsule Server、およびコンテンツホストのアップデート
本章を使用して、既存の Satellite Server、Capsule Server おびコンテンツホストを、6.7.0 から 6.7.1 などのように、新しいマイナーバージョンに更新します。
アップデートすると、コードの発表後に検出されたセキュリティー脆弱性およびマイナーな問題が修正され、多くの場合、アップデートはすぐに終わり、稼働環境への影響はありません。
アップデート前に Satellite Server および全 Capsule Server をバックアップします。詳細は、『 Red Hat Satellite の管理 』ガイドの「 Satellite Server および Capsule Server のバックアップ 」を参照してください。
5.1. Satellite Server のアップデート
前提条件
- Satellite、Capsule、および Satellite Tools 6.7 の Satellite Server リポジトリーが同期されていることを確認する。
- アップデートしたリポジトリーを関連するすべてのコンテンツビューにプロモートして、外部 Capsule とコンテンツホストがそれぞれアップデートできるようにしておく。
設定ファイルを手動で、または Hiera などのツールを使用して、カスタマイズした場合には、このカスタマイズした内容は、アップグレード時またはアップデート時にインストールスクリプトを実行すると上書きされます。satellite-installer スクリプトで --noop
オプションを使用すると、変更をテストできます。詳細は、ナレッジベースソリューションの「How to use the noop option to check for changes in Satellite config files during an upgrade」を参照してください。
Satellite Server を次のマイナーバージョンにアップデート
Satellite Server のアップデート手順:
Satellite Maintenance リポジトリーが有効になっていることを確認します。
# subscription-manager repos --enable \ rhel-7-server-satellite-maintenance-6-rpms
yum のキャッシュを消去します。
# yum clean all
satellite-maintain
が含まれるrubygem-foreman_maintain
パッケージがインストールされており、最新の状態になっていることを確認します。# yum install rubygem-foreman_maintain
利用可能なバージョンを確認して、次のマイナーバージョンが一覧に追加されているのを確認します。
# satellite-maintain upgrade list-versions
ヘルスチェックオプションを使用して、システムをアップグレードする準備が完了しているかどうかを確認します。このコマンドを最初に使用したときに、
satellite-maintain
により hammer 管理者ユーザー認証情報を入力して、/etc/foreman-maintain/foreman-maintain-hammer.yml
ファイルに保存します。# satellite-maintain upgrade check --target-version 6.7.z
結果を確認し、アップグレードを実行する前に、強調表示されているエラー状態に対応します。
アップデート時間は長くなるため、通信セッションの中断と再接続を可能にする
screen
などのユーティリティーを使用します。これにより、コマンドシェルに接続し続けなくてもアップグレードの進捗が確認できるようになります。screen コマンドの使用方法は、Red Hat ナレッジベース の「How do I use the screen command?」を参照してください。アップグレードコマンドを実行しているコマンドシェルへの接続がなくなった場合は、
/var/log/foreman-installer/satellite.log
ファイルのログメッセージで、プロセスが完全に終了したかどうかを確認できます。アップグレードを実行します。
# satellite-maintain upgrade run --target-version 6.7.z
カーネルパッケージが最後にアップデートされた日時を確認します。
# rpm -qa --last | grep kernel
オプション: 最後の再起動以降にカーネルがアップデートされた場合には、
satellite-maintain
サービスを停止して、システムを再起動します。# satellite-maintain service stop # reboot
5.2. Capsule Server のアップデート
Capsule Server の次のマイナーバージョンへの更新
手順
Capsule Server をアップデートするには、以下の手順を実行します。
Capsule Serverで、有効なリポジトリーを表示します。
# subscription-manager repos --list-enabled
次のリポジトリーのみが有効になっていることを確認してください。
rhel-7-server-rpms rhel-7-server-satellite-capsule-6.7-rpms rhel-server-rhscl-7-rpms rhel-7-server-satellite-tools-6.7-rpms rhel-7-server-satellite-maintenance-6-rpms rhel-7-server-ansible-2.8-rpms
リポジトリーの無効化および有効 化に関する詳細は、『Capsule Server のインストール 』の 「リポジトリーの設定」を参照してください。
rhel-7-server-satellite-tools-6.7-rpms
リポジトリーでは、katello-host-tools および Katello エージェントが提供されます。詳細は、『 Capsule Server のインストール』の「Katello エージェント のインストール 」を参照してください。Red Hat Software Collections リポジトリーは任意です。これはリモート実行機能に必要です。satellite-maintain
サービスを停止します。# satellite-maintain service stop
BZ#1649764 が解決されるまで、
gofer
パッケージをアップデートしてください。# yum update gofer
goferd を再起動します。
# systemctl restart goferd
すべてのパッケージを更新します。
# yum update
カーネルの更新が発生した場合は、アップグレードの完了 後 に再起動するようにメモしてください。この時点で は再起動しない でください。
--upgrade
オプションを指定してインストーラースクリプトを実行することにより、更新を実行します。# satellite-installer --scenario capsule --upgrade
オプション:
yum
更新手順でカーネルが更新された場合には、satellite-maintain
サービスを停止して、システムを再起動します。# satellite-maintain service stop # reboot
5.3. コンテンツホストのアップデート
コンテンツホストを次のマイナーバージョンにアップデート
コンテンツホストのアップデート手順:
BZ#1649764 が解決されるまで、
gofer
パッケージをアップデートしてください。# yum update gofer
goferd を再起動します。
# systemctl restart goferd
すべてのパッケージを更新します。
# yum update
オプション: カーネルをアップデートしてから再起動していない場合には、システムを再起動します。
# reboot