内容

概要

前提条件

要件

使用するコンポーネント

サポートされるパス

Split Upgradeによる完全アップグレードの比較

分散導入におけるスプリット・アップグレード方式によるノード・アップグレードの順序

分散導入におけるフルアップグレード方式によるノードアップグレードのシーケンス

スプリット・アップグレード方式に対するフル・アップグレードの利点

フルアップグレードフロー

UIのアップグレード

ウェルカムページ

Checklist

アップグレードの準備

アップグレードのステージング

アップグレードノード

要約

ヘルスチェック

アップグレード後の作業

問題と解決策

概要

このドキュメントでは、フルアップグレード方式を使用して、既存のISE導入をバージョン2.7から3.1にアップグレードする方法について説明します。また、ヘルスチェック機能を使用して、導入の潜在的な問題を検出して修正する方法も含まれます。従来のアップグレード方式はSplit Upgradeと呼ばれるようになり、Full Upgrade方式が推奨されていない場合は、代替オプションとして使用できます。

前提条件

要件

次の項目に関する知識があることが推奨されます。

- Identity Services Engine（ISE）

- さまざまなタイプのISE導入を説明するために使用される用語の理解

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

- ISE、リリース2.7、パッチ4

- ISE、リリース3.1

このドキュメントの情報は、特定のラボ環境にあるデバイスから作成されたものです。このドキュメントで使用するすべてのデバイスは、クリア（デフォルト）な設定から開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

注：この手順は、他のISEバージョンと同じか、同じです。特に明記されていない限り、2.6以降では、ISEソフトウェアリリース3.1以降にアップグレードするために、これらの手順を使用できます。

サポートされるパス

ISE 3.1への完全なアップグレードは、

- ISE 2.6パッチ10以降

- ISE 2.7パッチ4以降

- ISE 3.0パッチ3以降

ISE 3.1へのスプリットアップグレードは、ISE 2.6以降のバージョンからサポートされており、パッチの有無は問いません。

Split Upgradeによる完全アップグレードの比較

分散導入におけるスプリット・アップグレード方式によるノード・アップグレードの順序

新しいバージョンにアップグレードするには、完全分散型の導入に最低5つの手順が必要です。

各ステップで約240分を考慮すると、このアップグレードプロセスの合計には240*5分= 20時間かかります。

分散導入におけるフルアップグレード方式によるノードアップグレードのシーケンス

新しいバージョンにアップグレードするには、完全分散導入に必要な手順は2つだけです。

繰り返しますが、各ステップで約240分を考慮すると、アップグレードプロセス全体が240*2分= 8時間に短縮されます。

スプリット・アップグレード方式に対するフル・アップグレードの利点

- フルアップグレード方式では、ノードが並行してアップグレードされるため、全体的なアクティビティにかかる時間が短縮されます。一方、スプリットアップグレード方式は、メンテナンス期間が長い状態で適切に計画する必要があります。

- 完全アップグレード方式は、アップグレードシーケンスの点で手間がかからないため、わずか2ステップで実行できます。Split Upgradeメソッドでは、アップグレードプロセスを開始する前に、ノードを適切に順序付ける必要があります。

- フルアップグレード方式では、アップグレード前と同じロールとペルソナが保持されます。Split Upgradeメソッドは、アップグレードされたバージョンのプライマリおよびセカンダリの管理者ロールを切り替えます。

- アップグレードプロセス中の導入関連の変更に伴うAPIの依存関係をなくすことで、フルアップグレード方式の障害ポイントが削減されました。

- フルアップグレード方式では、プライマリ管理ノードがアップグレードのためにダウンした場合に、セカンダリ管理ノードからアップグレードステータスを追跡できます。これは、Split Upgrade方式では不可能です。

- アップグレード後のパッチのインストールは自動化され、フルアップグレード方式のオプションとして提供されます。

注意：すべてのPSNが同時にダウンしてアップグレードされるため、完全なアップグレードには完全なダウンタイムが必要です。アクティビティがスケジュールされたメンテナンス時間帯に計画されていることを確認します。

フルアップグレードフロー

このドキュメントでは、4ノード展開のアップグレードフローを示します。2ノードまたは他のマルチノード展開では、プロセス全体は同じです。

UIのアップグレード

図に示すように、[Administration] > [System] > [Upgrade]に移動してアクティビティを開始します。

注：スプリットアップグレード方式だけが、ISE 2.6パッチ9以下、ISE 2.7パッチ3以下、およびISE 3.0パッチ2以下でサポートされています。デフォルトでは、これらのバージョンの[Split Upgrade]ウィンドウが開きます。スプリット・アップグレード・プロセスについては、ここから参照できます。[フルアップグレード]ラジオボタンを選択し、[アップグレードの開始]をクリックします。

ウェルカムページ

ウェルカムページウィザードで、[Next]をクリックして、次に進みます。

Checklist

さらに進む前に、チェックリストを確認し、タスクを完了してください。

チェックリストを確認したことを示すチェックボックスをオンにし、[次へ]をクリックします。

アップグレードの準備

アップグレード前の完全な導入時にプレチェックが実行され、結果がこのページに表示されます。チェック以外に、このステップでは、すべてのノードにアップグレードバンドルがダウンロードされ、オフラインデータアップグレード(ODU)がセカンダリ管理ノードで実行されます(これは、Split UpgradeメソッドのUpgrade Readiness Tool(URT)シミュレーションに類似しています)。

アップグレードバンドルは、Cisco Software Downloadページからダウンロードする予定です。

アップグレード前チェックを実行するには、アップグレードバンドルが配置されているリポジトリ名を選択します。[バンドル(Bundle)]ドロップダウンボックスから、アップグレードバンドルファイル名を選択します。

注：フルアップグレード方式では、アップグレード後の自動パッチインストールも導入されます。パッチファイルは、アップグレードバンドルと同じリポジトリに配置し、自動パッチインストールが必要な場合は、ドロップダウンからパッチファイル名を選択できます。

[Start Preparation]をクリックして、プレチェックの実行を開始します。バンドルのダウンロードと構成データのアップグレードを除くすべてのプレチェックは、システム検証を開始してから4時間後に自動的に期限切れになります。ODU以外の構成データのアップグレードは、12時間後に期限切れになります。

注：アップグレードアクティビティの前に、PANフェールオーバー設定を無効にする必要があります。手動で行わないと、アップグレードがトリガーされると自動的に無効になります。

注：ISE 3.0以降では、スマートライセンスの使用が義務付けられています。従来のライセンスはサポートされません。アップグレード前にSmart Licensingが有効になっていないか、登録されていない場合、ISEはデフォルトでアップグレード後にSmart Licensing評価期間に移行します。ライセンス移行参照リンク：製品 – ISEライセンス移行ガイド – Cisco. ISEを2.xから3.xにアップグレードする場合、ライセンス階層の変更が含まれます。詳細はこちらをご覧ください。Cisco Identity Services Engine - Cisco ISEライセンスに関するFAQ – シスコ

注意：Configuration Data Upgradeがトリガーされた後は、ISEのすべてのタイプの設定変更を回避する必要があります。アップグレード後に行われた変更は失われます。

いずれかのコンポーネントの事前チェックが失敗すると、その重要度に基づいて赤またはオレンジ色で表示されます。赤色で強調表示された障害は、先に進む前に強制的に修正する必要があります。オレンジ色で強調表示されている警告はアップグレードプロセスを停止しませんが、ベストプラクティスとして修正し、将来の導入機能への影響を回避することをお勧めします。

エラーが修正されたら、[Start Staging]をクリックして次に進みます。

アップグレードのステージング

アップグレードのステージング中に、アップグレードされたデータベースファイルが展開内のすべてのノードにコピーされ、構成ファイルが展開内のすべてのノードにバックアップされます。

ダンプファイルは、ODUの一部としてセカンダリ管理ノードにすでに存在しています。したがって、この手順では、セカンダリ管理ノードが作成するのは、CA NSS DB、Smart Licensing、およびDHCP/DNS設定のバックアップファイルだけです。他のすべてのノードもこれらのファイルを作成しますが、さらにセカンダリ管理ノードからダンプファイルをコピーする必要があります。

すべてのノードのステージングが完了したら、[Next]をクリックします。

アップグレードノード

[Start]をクリックし、アップグレードをトリガーします。

ポップアップメッセージが表示され、アップグレードがトリガーされ、すべてのノードがアップグレードステータスのキューに表示されます。最初にプライマリ管理ノードでアップグレードが開始されるため、システムはこのノードからログアウトし、セカンダリ管理ノードのGUIからアップグレードステータスを監視できます。セカンダリ管理ノードのGUIで[Administration] > [System] > [Upgrade]に移動し、ステータスの表示を続行します。

プライマリ管理ノードがアップグレードされ、サービスが起動すると、システムはセカンダリ管理ノードのGUIからログアウトします。ユーザは、プライマリ管理ノードのGUIからステータスの監視に切り替えることができますが、展開の他のすべてのノードが同時にアップグレードのためにダウンします。

すべてのノードが正常にアップグレードされると、ステータスが緑色に変わります。

障害が発生したノードがある場合は、障害が発生したノードに関する情報を含むポップアップウィンドウが表示されます。ポップアップウィンドウで[OK]をクリックし、失敗したノードを配置から登録解除します。これらのコンポーネントは、個別にアップグレード/再イメージ化し、必要に応じて導入に結合する必要があります。

[Next]をクリックして、全体的なアップグレードサマリーレポートを表示します。

要約

アップグレードプロセスが完了すると、このページから展開の診断アップグレードレポートを表示およびダウンロードできます。

ヘルスチェック

アップグレード後の展開ステータスを検証するために、ヘルスチェックが自動的に実行され、展開のステータスが確認されます。このレポートは、アップグレードフローの[Summary]ページからダウンロードできます。オンデマンドのヘルスチェックが必要な場合は、[Administration] > [System] > [Health Checks]に移動し、[Start Health Checks]をクリックします。

アップグレード後の作業

アップグレード完了後にユーザがプライマリ管理ノードのGUIにログインすると、アップグレード後の作業に関するポップアップメッセージが表示されます。

ポップアップメッセージの[アップグレード後のタスク]ハイパーリンクをクリックして、タスクの詳細を確認し、完了します。

問題と解決策

1. プライマリ管理者ノードのアップグレードが失敗した場合は、セカンダリ管理者をプライマリ管理者に昇格してから、アップグレードを再試行します。

2. プライマリ管理者を除く他のノードでアップグレードが失敗した場合は、そのノードを導入から登録解除する必要があります。このノードは、個別にアップグレードするか、アップグレードしたバージョンに直接再イメージ化する必要があり、導入に再度参加できます。