第2章 RHEL 7 サーバーから RHEL 8 サーバーへの IdM 環境の移行
RHEL 7 IdM 環境を RHEL 8 にアップグレードするには、最初に新しい RHEL 8 IdM レプリカを RHEL 7 IdM 環境に追加し、RHEL 7 サーバーをリタイアさせる必要があります。
- RHEL 7 IdM サーバーおよび IdM サーバーノードの RHEL 8 へのインプレースアップグレードはサポートされていません。
RHEL 6 以前のバージョンから RHEL 8 への直接移行はサポートされていません。IdM データを適切に更新するには、増分移行を実行する必要があります。
たとえば、RHEL 6 IdM 環境を RHEL 8 に移行するには、次のコマンドを実行します。
- RHEL 6 サーバーから RHEL 7 サーバーに移行します。Red Hat Enterprise Linux 6 からバージョン 7 への Identity Management の移行については、Red Hat Enterprise Linux 6 からバージョン 7 への Identity Management の移行を 参照してください。
- 本セクションで説明されているように、RHEL 7 サーバーから RHEL 8 サーバーに移行します。
RHEL 8 は SPAKE と IdP 事前認証をサポートしていますが、RHEL 7 はサポートしていません。RHEL 7 IdM デプロイメントで SPAKE または IdP が有効になっている RHEL 8 サーバーを使用すると、ユーザーがログインできないなどの問題が発生する可能性があります。IdM デプロイメント内のすべてのサーバーをできるだけ早く移行してください。
詳細は、Red Hat ナレッジベースソリューションの Kerberos での事前認証エラー および AD 信頼ユーザー向けの 2FA/OTP 認証の使用を 参照してください。
この手順では、すべての Identity Management (IdM) のデータおよび設定を、RHEL (Red Hat Enterprise Linux) 7 サーバーから RHEL 8 サーバーへ 移行 する方法を説明します。この手順を使用して、RHEL 以外の Linux ディストリビューション上の FreeIPA サーバーから RHEL 8 サーバー上の IdM に移行することもできます。
主な移行手順は次のとおりです。
- RHEL 8 IdM サーバーを設定し、現在の RHEL 7 IdM 環境にレプリカとして追加します。詳細は、RHEL 8 レプリカのインストール を参照してください。
- RHEL 8 サーバーを認証局 (CA) 更新サーバーにする。詳細は、RHEL 8 IdM サーバーへの CA 更新サーバーロールの割り当て を参照してください。
- RHEL 7 サーバーで証明書失効リスト (CRL) の生成を停止し、CRL 要求を RHEL 8 にリダイレクトする。詳細は RHEL 7 IdM CA サーバーでの CRL 生成の停止 を参照してください。
- RHEL 8 サーバーで CRL の生成を開始する。詳細は 新しい RHEL 8 IdM CA サーバーでの CRL 生成の開始 を参照してください。
- 元の RHEL 7 CA 更新サーバーを停止して使用を中止する。詳細は RHEL 7 サーバーの停止および使用停止 を参照してください。
大規模または複雑なデプロイメントのための追加手順
大規模、地理的に分散、またはミッションクリティカルな IdM デプロイメントでは、トポロジーの健全性を確保し、サービスの中断を防ぐために、次のオプションの手順を強く推奨します。
移行を開始する前に、ストラテジーガイダンスを確認し、デプロイメントに適用されるオプションの手順を検討してください。
手順では、以下を前提としています。
-
rhel8.example.comは、新しい CA 更新サーバーとなる RHEL 8 システムです。 rhel7.example.comは、元の RHEL 7 CA 更新サーバーです。IdM デプロイメントで認証局 (CA) を使用しない場合、RHEL 7 で実行している IdM サーバーは
rhel7.example.comにすることができます。
2.1. 大規模および標準の IdM デプロイメントを移行するためのストラテジー リンクのコピーリンクがクリップボードにコピーされました!
大規模な、または地理的に分散した Identity Management (IdM) トポロジーを移行するには、サービスの継続性を確保するための追加の計画が必要です。コアとなる移行手順 (新しいレプリカのインストール、CA 更新サーバーとしての確立、古いサーバーの廃止) はすべてのデプロイメントに適用されますが、大規模な環境では、より厳格なインベントリーおよび検証プロセスのメリットが得られます。
移行ワークフローの比較
次の表は、標準的な単一サーバーまたは小規模クラスターの移行と比較した、大規模または複雑なトポロジーの場合に推奨される追加手順を示しています。
| 内容 | 標準的な移行 | 大規模/複雑な移行 |
|---|---|---|
| 1.トポロジーのインベントリー | 任意。 | 強く推奨します。レプリカの置き換え中に重要なサービス (CA、DNS、KRA、AD Trust) が失われないように、すべてのサーバーロールとレプリカ合意を文書化します。 |
| 2.DNA ID 範囲の記録 | 任意。 | 強く推奨します。割り当てられた ID 範囲を記録して、大きな範囲を保持しているサーバーが再割り当てされずに廃止された場合に枯渇するのを防ぎます。 |
| 3.サーバーホスト名の再利用 | めったに必要ありません。 | 条件付き。ホスト名を再利用する場合は、再インストールする前にレプリケーションが完全に収束するまで待機します。急速な削除と追加により、高レイテンシーのトポロジーで競合が発生する可能性があります。 |
| 4.新しいレプリカのインストール | 必須。 | 必須。新しいレプリカが、置換するレプリカと同じロールでインストールされていることを確認します。問題を早期に発見するために、検証中にヘルスチェックを実行します。 |
| 5.CA 更新ロールの割り当て | 必須 (統合 CA を使用する場合)。 | 必須 (統合 CA を使用する場合)。続行する前に、ロールの割り当てが複製されていることを確認してください。 |
| 6.CRL 生成の管理 | 必須 (統合 CA を使用する場合)。 | 必須 (統合 CA を使用する場合)。古いサーバーの CRL を停止し、リクエストをリダイレクトして、新しいサーバーで開始します。 |
| 7.クライアント設定の更新 | 自動 (ほとんど)。 |
手動での更新が必要になる場合があります。 |
| 8.古いサーバーの廃止 | 必須。 | 必須。一意のロールが失われていないことを確認し、レプリケーションが収束できるようにします。 |
大規模デプロイメントにおける戦略的考慮事項
- 冗長性の維持: レプリカを廃止する前に、少なくとも 1 台の他のサーバーが重要なサービス (CA、DNS、KRA、AD Trust) を提供していることを確認します。
- レプリケーションラグ: 地理的に分散したデプロイメントでは、レプリケーションが収束するまでにトポロジーの変更間に追加の時間を許可します。削除/追加サイクルが頻繁に発生すると、遅延の大きいリンク間で解決が困難な競合が発生する可能性があります。
- バッチ処理: 非常に大規模なトポロジーの場合は、サイトごとに移行し、各ウェーブの後に正常性を検証します。単一サイト内のすべてのサーバーを同時に廃止することは避けてください。