はじめに
このドキュメントでは、フルアップグレード方式を使用して、既存のISE導入をバージョン2.7から3.1にアップグレードする方法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Identity Services Engine(ISE)
- さまざまなタイプのISE導入を説明するために使用される用語を理解する
使用するコンポーネント
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
- ISE、リリース2.7、パッチ4
- ISE、リリース3.1
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
注:手順は他のISEバージョンに類似しているか、同一です。特に記載のない限り、これらの手順を2.6で使用して3.1およびISEソフトウェアリリースにアップグレードできます。
背景説明
また、ヘルスチェック機能を使用して、導入に関する潜在的な問題を検出して修正する方法についても説明します。従来のアップグレード方式は、スプリット・アップグレードと呼ばれており、フル・アップグレード方式が望ましくない場合は、代替オプションとして使用できます。
サポートされるパス
ISE 3.1へのフルアップグレードは
- ISE 2.6パッチ10以降
- ISE 2.7パッチ4以降
- ISE 3.0パッチ3以降
ISE 3.1へのスプリットアップグレードは、ISE 2.6以降のバージョンでサポートされており、パッチが適用されていてもいなくても適用できます。
完全アップグレードと分割アップグレード方式の比較
分散導入での分割アップグレード方式によるノードのアップグレードの順序
完全分散型導入を新しいバージョンにアップグレードするには、最低5つの手順が必要です。
各ステップの合計所要時間を約240分と考えると、アップグレードプロセスの所要時間は240*5分= 20時間になります。
分散導入におけるフルアップグレード方式によるノードのアップグレードの順序
完全に分散された導入を新しいバージョンにアップグレードするには、2つの手順のみが必要です。
繰り返しになりますが、各ステップの合計所要時間を約240分と考えると、アップグレードプロセスの合計所要時間は240*2分= 8時間に短縮されます。
スプリットアップグレード方式に対するフルアップグレードの利点
- 「フルアップグレード」方式では、ノードが並行してアップグレードされるため、アクティビティ全体で消費する時間が少なくなります。これに対して、「分割アップグレード」方式では、メンテナンス期間をより長い期間に渡って適切に計画する必要があります。
- フルアップグレード方式では、アップグレードの順序が2ステップしかないため、手間がかかりません。分割アップグレード方式では、アップグレードプロセスを開始する前に、ノードを適切に順序付けする必要があります。
- フルアップグレード方式では、ロールとペルソナがアップグレード前と同じ状態に維持されます。スプリットアップグレード方式では、アップグレードされたバージョンでプライマリ管理者ロールとセカンダリ管理者ロールを切り替えます。
- フルアップグレード方式では、アップグレードプロセス中の導入に関連する変更に伴うAPIの依存関係が解消され、障害ポイントが削減されました。
- フルアップグレード方式では、プライマリ管理ノードがアップグレードのためにダウンした場合に、セカンダリ管理ノードからアップグレードステータスを追跡できます。これは、分割アップグレード方式では不可能です。
- アップグレード後のパッチインストールは自動化されており、フルアップグレード方式のオプションとして提供されます。
注意:フルアップグレードでは、すべてのPSNがアップグレードのために同時にダウンするため、完全なダウンタイムが必要です。アクティビティがスケジュールされたメンテナンス期間中に計画されていることを確認します。
完全なアップグレードフロー
このドキュメントでは、4ノード導入のアップグレードフローを示します。プロセス全体は、2ノードまたは他のマルチノード導入でも同じです。
UIのアップグレード
Administration > System > Upgradeの順に移動し、図に示すようにアクティビティを開始します。
注:ISE 2.6パッチ9以下、ISE 2.7パッチ3以下、およびISE 3.0パッチ2以下では、スプリットアップグレード方式だけがサポートされています。デフォルトでは、これらのバージョンに対して「Split Upgrade」ウィンドウが起動します。アップグレードの分割プロセスについては、ここを参照してください。Full Upgradeオプションボタンを選択し、Start Upgradeをクリックします。
ウェルカムページ
ウェルカムページウィザードで、Nextをクリックしてさらに進みます。
Checklist
先に進む前に、チェックリストを確認し、タスクが完了していることを確認します。
I have reviewed the checklistというチェックボックスをオンにし、Nextをクリックします。
アップグレードの準備
アップグレードの前に展開全体に対して事前チェックが実行され、結果がこのページに表示されます。確認とは別に、この手順ではアップグレードバンドルがすべてのノードにダウンロードされ、セカンダリ管理ノードでオフラインデータアップグレード(ODU)が実行されて(これは分割アップグレード方式のUpgrade Readiness Tool(URT)シミュレーションに似ています)、最後にアクティビティの推定所要時間も表示されます。
アップグレードバンドルは、シスコのソフトウェアダウンロードページからダウンロードできます。
アップグレード前チェックを実行するには、アップグレードバンドルが配置されているリポジトリ名を選択します。「バンドル」ドロップダウンボックスからアップグレードバンドルファイル名を選択します。
注:フルアップグレード方式では、アップグレード後にパッチが自動的にインストールされます。パッチファイルはアップグレードバンドルと同じリポジトリに配置し、自動パッチインストールが必要な場合は、ドロップダウンからパッチファイル名を選択できます。
Start Preparationをクリックして、事前チェックの実行を開始します。バンドルダウンロードおよび構成データアップグレードチェックを除くすべてのプレチェックは、システム検証を開始してから4時間後に自動的に期限切れになります。ODUに過ぎない設定データのアップグレードは、12時間後に期限切れになります。
注:アップグレード作業の前に、PANフェールオーバー設定を無効にします。手動で行わない場合、アップグレードがトリガーされると自動的に無効になります。
注:ISE 3.0以降では、スマートライセンスの使用が必須です。従来のライセンスはサポートされません。アップグレード前にスマートライセンスが有効になっていないか登録されていない場合、ISEはデフォルトでアップグレード後にスマートライセンス評価期間を開始します。ライセンス移行の参照リンク:製品 – ISEライセンス移行ガイド – シスコ ISEを2.xから3.xにアップグレードする場合、ライセンス階層の変更が含まれます。
注意:ISEでのすべてのタイプの設定変更は、設定データのアップグレードがトリガーされた後は回避する必要があります。変更を加えると、アップグレード後に失われます。
いずれかのコンポーネントの事前チェックが失敗すると、重要度に応じて赤色またはオレンジ色で表示されます。赤で強調表示されている障害は、続行する前に強制的に修正する必要があります。オレンジ色で強調表示されている警告はアップグレードプロセスを停止できませんが、ベストプラクティスとして修正し、将来の展開機能への影響を回避することをお勧めします。
エラーが修正されたら、[ステージングの開始]をクリックしてさらに先に進みます。
ステージングのアップグレード
アップグレードのステージング中に、アップグレードされたデータベースファイルが展開内のすべてのノードにコピーされ、構成ファイルが展開のすべてのノードにバックアップされます。
ダンプファイルは、ODUの一部としてセカンダリ管理ノードにすでに存在します。したがって、この手順では、セカンダリ管理ノードはCA NSS DB、スマートライセンス、およびDHCP/DNS設定のバックアップファイルのみを作成します。他のすべてのノードもこれらのファイルを作成しますが、セカンダリ管理ノードからダンプファイルを追加でコピーする必要があります。
ステージングがすべてのノードで完了したら、Nextをクリックします。
ノードのアップグレード
Startをクリックしてアップグレードを開始します。
アップグレードがトリガーされ、すべてのノードがアップグレードステータスとともにキューに表示されることを確認するポップアップメッセージが表示されます。アップグレードは最初にプライマリ管理ノードで開始されるため、システムはこのノードからログアウトし、これでセカンダリ管理ノードのGUIからアップグレードステータスを監視できるようになります。セカンダリ管理ノードのGUIでAdministration > System > Upgradeの順に移動し、ステータスの表示を続行します。
プライマリ管理ノードがアップグレードされ、サービスが起動すると、セカンダリ管理ノードのGUIからシステムがログアウトします。これで、ユーザはプライマリ管理ノードのGUIからステータスの監視に切り替えることができると同時に、導入の他のすべてのノードはアップグレードのためにダウンします。
すべてのノードが正常にアップグレードされると、ステータスが緑色に変わります。
失敗したノードがある場合は、失敗したノードに関する情報を示すポップアップウィンドウが表示されます。ポップアップウィンドウでOKをクリックし、失敗したノードを展開から登録解除します。これらは個別にアップグレードまたは再イメージ化し、導入に参加する必要があります(存在する場合)。
全体的なアップグレードサマリーレポートを表示するには、Nextをクリックします。
要約
アップグレードプロセスが完了したら、このページから導入の診断アップグレードレポートを表示およびダウンロードできます。
ヘルスチェック
アップグレード後に展開ステータスを検証するために、ヘルスチェックが自動的に実行され、展開のステータスが検証されます。このレポートは、アップグレードフローの要約ページからダウンロードできます。オンデマンドのヘルスチェックが必要な場合は、Administration > System > Health Checksの順に移動し、Start Health Checksをクリックします。
アップグレード後タスク
アップグレードの完了後にユーザがプライマリ管理ノードのGUIにログインすると、アップグレード後のタスクに関するポップアップメッセージが表示されます。
タスクの詳細を確認して完了するには、ポップアップメッセージでポストアップグレードタスクのハイパーリンクをクリックします。
問題と解決策
- プライマリ管理者ノードのアップグレードが失敗した場合は、セカンダリ管理者をプライマリ管理者に昇格させ、アップグレードを再試行します。
- プライマリ管理者以外の他のノードでアップグレードが失敗した場合、そのノードを展開から登録解除する必要があります。このノードは個別にアップグレードするか、アップグレードされたバージョンに直接イメージを変更する必要があります。また、展開に戻して参加することもできます。