ノードのアップグレードの順序
GUI、バックアップと復元、または CLI のどの方法を使用してアップグレードする場合でも、最小のダウンタイムで、最大の復元力とロールバック機能を提供しながら、展開をアップグレードするには、次の順序でアップグレードを実行することをお勧めします。
-
すべての設定とモニタリングデータをバックアップします。必要に応じて、手動で簡単にロールバックできるように、アップグレードを開始する前にこのタスクを実行する必要があります。
-
セカンダリ管理ノード
この時点では、プライマリ管理ノードは以前のバージョンのままで、アップグレードに失敗した場合はロールバックに使用できます。
-
プライマリ モニタリング ノードまたはセカンダリ モニタリング ノード
分散展開の場合、既存の Cisco ISE 展開のセカンダリ管理ノードがあるサイトで使用可能なすべてのノードをアップグレードします。
-
セカンダリ モニタリング ノードまたはプライマリ モニタリング ノード
-
ポリシーサービスノード
ポリシーサービスノードのセットをアップグレードした後、アップグレードが成功したかどうかを確認し（「アップグレードプロセスの確認」を参照）、新しい展開が期待どおりに機能していることを確認するネットワークテストを実行します。アップグレードが成功した場合は、ポリシーサービスノードの次のセットをアップグレードできます。
-
プライマリ管理ノード
プライマリ管理ノードをアップグレードした後、アップグレードの検証テストとネットワークテストを再実行します。
（注）
プライマリ管理ノード（アップグレードの必要がある古い展開からの最後のノード）で登録中にアップグレードが失敗した場合、アップグレードはロールバックされ、ノードはスタンドアロンノードになります。CLI から、スタンドアロンノードとしてノードをアップグレードします。セカンダリ管理ノードとして新しい展開にノードを登録します。
アップグレード後、セカンダリ管理ノードはプライマリ管理ノードになり、元のプライマリ管理ノードはセカンダリ管理ノードになります。必要に応じて、[ノードの編集（Edit Node）] ウィンドウで [プライマリに昇格（Promote to Primary）] をクリックして、セカンダリ管理ノードを昇格してプライマリ管理ノードにします（古い展開環境と一致させます）。
管理ノードがモニタリングペルソナも担当する場合は、次の表に示す手順に従ってください。
|
現在の展開内のノードペルソナ |
アップグレードの順序 |
|---|---|
|
セカンダリ管理/プライマリ モニタリング ノード、ポリシーサービスノード、プライマリ管理/セカンダリ モニタリング ノード |
|
|
セカンダリ管理/セカンダリ モニタリング ノード、ポリシーサービスノード、プライマリ管理/プライマリ モニタリング ノード |
|
|
セカンダリ管理ノード、プライマリ モニタリング ノード、ポリシーサービスノード、プライマリ管理/セカンダリ モニタリング ノード |
|
|
セカンダリ管理ノード、セカンダリ モニタリング ノード、ポリシーサービスノード、プライマリ管理/プライマリ モニタリング ノード |
|
|
セカンダリ管理/プライマリ モニタリング ノード、ポリシー サービス ノード、セカンダリ モニタリング ノード、プライマリ管理ノード |
|
|
セカンダリ管理/セカンダリ モニタリング ノード、ポリシーサービスノード、プライマリ モニタリング ノード、プライマリ管理ノード |
|
次の場合にエラーメッセージ「No Secondary Administration Node in the Deployment 」が表示されます。
-
展開内にセカンダリ管理ノードが存在しない。
-
セカンダリ管理ノードがダウンしている。
-
セカンダリ管理ノードはアップグレードされ、アップグレード済みの展開に移行されている。通常、セカンダリ管理ノードをアップグレードした後に、展開の詳細の [更新（Details）] オプションを使用したときに、この問題が発生する可能性があります。
この問題を解決するには、該当する次のいずれかのタスクを実行します。
-
展開にセカンダリ管理ノードがない場合は、セカンダリ管理ノードを設定して、アップグレードを再試行します。
-
セカンダリ管理ノードがダウンしている場合は、そのノードを起動し、アップグレードを再試行します。
-
セカンダリ管理ノードがアップグレードされ、アップグレード済みの展開に移行されている場合は、CLI を使用して展開内の他のノードを手動でアップグレードします。
アップグレード方法の選択
Cisco ISE のこのリリースでは、次のアップグレードプロセスがサポートされています。アップグレードの技術上の専門知識とアップグレードに割くことのできる時間に応じて、以下のアップグレードプロセスから選択できます。
-
バックアップと復元の手順を使用した Cisco ISE のアップグレード（推奨）
-
GUI からの Cisco ISE 展開環境のアップグレード
-
CLI からの Cisco ISE 展開環境のアップグレード
|
比較要素 |
バックアップと復元（推奨） |
GUI を使用したアップグレード |
CLI を使用したアップグレード |
|---|---|---|---|
|
比較の概要 |
高速だが、より多くの管理作業が必要 |
時間がかかるが、必要な管理作業は少ない |
時間がかかり、必要な管理作業も多い |
|
難しさ |
困難 |
容易 |
適度 |
|
最小バージョン |
ISE 1.3 以降 |
ISE 2.0 以降 |
ISE 1.3 以降 |
|
VM |
十分なキャパシティがある場合は、新しい VM を事前設定して、アップグレードされた PAN にそれらの VM をすぐに参加させることできる |
PSN ノードは 1 ノードずつ順次アップグレードされる |
PSN ノードは同時にアップグレードされる |
|
時刻 |
PSN は新しいバージョンでイメージ化され、アップグレードされないため、アップグレードのダウンタイムは最小 |
各 PSN は順次アップグレードされ、合計アップグレード時間が直線的に増加する |
各 PSN はアップグレードされるが、同時にアップグレードされるため、合計アップグレード時間が短縮される |
|
担当者 |
設定と運用のログをやりとりするさまざまな事業部門の複数の関係者が参加 |
手動操作の少ない自動アップグレードプロセス |
Cisco ISE に関する技術的な専門知識 |
|
ロールバック |
ノードの再イメージ化が必要 |
簡単なロールバックオプション |
簡単なロールバックオプション |
アップグレード方法の詳細な比較を以下に示します。
バックアップと復元方法を使用した Cisco ISE のアップグレード
Cisco ISE ノードの再イメージ化は、初期展開の一部としておよびトラブルシューティング時に実行されますが、新しいバージョンが展開された後、新しい展開にポリシーを復元している間に Cisco ISE ノードを再イメージ化して展開をアップグレードすることもできます。
リソースが制限されていて、新しい展開で並列の ISE ノードをスピンアップできない場合、他のノードがアップグレードされる前に、セカンダリ PAN と MnT がアップグレードされる実稼働展開から削除されます。ノードは新しい展開に移動します。設定と運用のバックアップは、1つの並列展開を作成している各ノード上の以前の展開から復元されます。これにより、手動で操作する必要なく、ポリシーセット、カスタムプロファイル、ネットワーク アクセス デバイス、およびエンドポイントを新しい展開に復元できます。
バックアップと復元プロセスを使用して Cisco ISE をアップグレードする利点は、次のとおりです。
-
以前の ISE 展開から設定と運用ログを復元できます。したがって、データ損失を防ぐことができます。
-
新しい展開で再利用する必要があるノードを手動で選択できます。
-
複数の PSN を同時にアップグレードすることで、アップグレードのダウンタイムを削減できます。
-
メンテナンス時間外にノードをステージングして、実稼働時のアップグレード時間を短縮できます。
必要なリソース：バックアップおよび復元によるアップグレードプロセスでは、リリース前に ISE 展開用に予約できる追加のリソースが必要です。既存のハードウェアを再利用する場合は、オンラインのままのノードに追加の負荷を分散させる必要があります。したがって、展開でノードあたりのユーザ数に対処できるように、展開の開始前に現在の負荷と遅延の制限を評価する必要があります。
必要な人員：アップグレードを実行するには、ネットワーク管理、セキュリティ管理、データセンター、仮想化リソースなど、複数の事業部門の参加が必要です。さらに、ノードを新しい展開に再参加させて、証明書を復元し、アクティブディレクトリに参加させて、ポリシーの動機を待機する必要があります。これにより、複数のリロードが行われ、新規展開のタイムフレームが必要になる場合があります。
ロールバックメカニズム：ノードの再イメージ化により、すべての情報と構成の設定は、以前の展開から消去されます。したがって、バックアップと復元によるアップグレードのロールバックメカニズムは、2 回目のノードの再イメージ化と同じ手順になります。
バックアップと復元によるアップグレードプロセスのベストプラクティスは次のとおりです。-
スタンドアロン環境を作成するか、または RADIUS 要求の仮想 IP アドレスを切り替える専用のロードバランサを用意します。
-
メンテナンス期間の前に余裕を持って展開プロセスを開始し、ユーザのロードバランサの切り替え先を新しい展開環境に設定できます。
バックアップと復元によるアップグレード方法の詳細については、「バックアップと復元方法を使用した Cisco ISE 展開のアップグレード」を参照してください。
GUI からの Cisco ISE 展開環境のアップグレード
また、カスタマイズ可能なオプションを使用して、GUI からワンクリックで Cisco ISE をアップグレードすることもできます。GUI によるアップグレードは、 メニューを使用して実行し、ISO イメージをダウンロードするための新しいリポジトリが必要です。
アップグレード中、セカンダリ PAN がアップグレードされた展開に自動的に移動して、最初にアップグレードされ、次にプライマリ MnT がアップグレードされます。その結果、これらのアップグレードのいずれかが失敗した場合、ノードを以前のバージョンにロールバックして、以前の ISE 展開に再参加する必要があります。後から PSN が 1 つずつ新しい展開に移動し、アップグレードされます。アップグレードに失敗した場合に、アップグレードの続行、または中止を選択することもできます。これにより、同じ Cisco ISE 展開のデュアルバージョンが作成され、アップグレードを続行する前にトラブルシューティングを行えます。すべての PSN がアップグレードされると、セカンダリ MnT とプライマリ PAN がアップグレードされて、新しい Cisco ISE 展開に参加します。
このアップグレードプロセスに必要な技術知識はわずかであるため、1 人の管理者がアップグレードを開始し、NOC または SOC エンジニアを割り当てて、アップグレードのステータスをモニタしてレポートするか、TAC ケースをオープンします。
GUI から Cisco ISE をアップグレードする利点は次のとおりです。
-
アップグレードが最小限の操作で自動化されます。
-
PSN のアップグレード順序を選択すると、特にデータセンター間で冗長性が得られる場合、可能な限り継続性を確保できます。
-
追加の人員、サードパーティ製のハイパーバイザ、またはネットワーク アクセス デバイスを使用せずに、1 人の管理者だけでアップグレードを実行できます。
失敗した場合の続行：アップグレードに失敗した場合に、アップグレードの続行、または中止を選択することもできます。これにより、同じ Cisco ISE 展開のデュアルバージョンが作成され、アップグレードを続行する前にトラブルシューティングを行えます。シスコのアップグレード準備ツールで非互換性や不良構成が示されますが、[続行（Proceed）] フィールドがオンになっている場合、アップグレード前にデューデリジェンスが機能しないと、追加のエラーが発生する可能性があります。
ロールバックメカニズム：PAN ノードまたは MnT ノードでアップグレードが失敗した場合、ノードは自動的にロールバックされます。ただし、PSN がアップグレードに失敗した場合、ノードは同じ Cisco ISE バージョンに残り、修正できますが、冗長性が低下します。この間、Cisco ISE はまだ動作しているため、再イメージ化しない限りロールバック機能は制限されます。
必要な時間：各 PSN のアップグレードには約 90 ～ 120 分かかります。したがって、PSN の数が多い場合は、それらすべてをアップグレードする時間が必要です。
GUI からのアップグレードのベストプラクティス：PSN の数が多い場合は、PSN をまとめてグループ化し、アップグレードを実行してください。
GUI からのアップグレードの詳細については、「GUI からの Cisco ISE 展開のアップグレード」を参照してください。
CLI からの Cisco ISE 展開環境のアップグレード
CLI からの Cisco ISE のアップグレードは複雑なプロセスであり、管理者がアップグレードイメージをローカルノードにダウンロードして、アップグレードを実行し、アップグレードプロセス全体を通じて各ノードを個別にモニタする必要があります。アップグレードのシーケンスは GUI によるアップグレードの場合と基本的に似ていますが、このアプローチではモニタリングと操作に手間がかかります。
CLI からのアップグレードは、必要な作業レベルが高いため、トラブルシューティング目的でのみ使用することをお勧めします。
CLI から Cisco ISE をアップグレードする利点は次のとおりです。
-
CLI では、アップグレードの実行中に管理者に追加のロギングメッセージが示されます。
-
アップグレードされるノードは、より細かな制御のうえで選択して、同時にアップグレードできます。アップグレードされていないノードは、エンドポイントが展開全体で再調整されるため、追加の負荷に対処きます。
-
CLI でのロールバックは、スクリプトで以前の変更を取り消すことができるため、はるかに簡単です。
-
イメージはノード上にローカルに存在するため、PAN と PSN の間のコピーエラー（存在する場合）は排除されます。
CLI を使用して Cisco ISE をアップグレードするには、技術的な専門知識が必要で、時間もかかります。
CLI からのアップグレードの詳細については、「CLI からの Cisco ISE 展開環境のアップグレード」を参照してください。
バックアップと復元方法を使用した Cisco ISE 展開のアップグレード（推奨）
バックアップと復元によるアップグレード方法の概要
シスコでは、バックアップと復元によるアップグレードプロセスを他のアップグレードプロセスよりも推奨しています。バックアップと復元によるアップグレードプロセスを使用すれば、現在の Cisco ISE 展開ノードの設定を復元でき、アップグレードプロセス中に障害が発生した場合にデータの損失を防ぐこともできます。この手順を開始するには、既存の Cisco ISE 展開環境の設定と運用のバックアップを作成し、新しい展開環境に適用します。
バックアップと復元によるアップグレードプロセスのベストプラクティスは次のとおりです。
-
スタンドアロン環境を作成するか、または RADIUS 要求の仮想 IP アドレスを切り替える専用のロードバランサを用意します。
-
メンテナンス期間の前に余裕を持って展開プロセスを開始し、ユーザのロードバランサの切り替え先を新しい展開環境に設定できます。
次に、バックアップと復元によるアップグレード方法で実行する手順の概要を示します。
1. ノードの登録解除
展開からノードを削除するには、ノードの登録を解除する必要があります。ノードの登録解除または削除の詳細については、『Cisco Identity Services Engine Administrator Guide, Release 2.4』の「Remove a node from Deployment」のセクションを参照してください。
2. ノードの再イメージ化
ノードを再イメージ化するには、Cisco ISE 展開にノードを新しくインストールする必要があります。Cisco ISE のインストール方法の詳細については、『Cisco Identity Services Engine Installation Guide, Release 2.4』の「Install Cisco ISE」の章を参照してください。
新しくインストールされた Cisco ISE リリースの最新のパッチを適用することを推奨します。
3. 設定または運用データベースのバックアップと復元
バックアップと復元操作の詳細については、『Cisco Identity Services Engine Administrator Guide, Release 2.4』の「Backup and Restore Operations」のセクションを参照してください。
4. ノードへのプライマリまたはセカンダリロールの割り当て
必要に応じて、ノードにプライマリまたはセカンダリのロールを割り当てることができます。
ロールをポリシー管理ノード（PAN）に割り当てる方法の詳細については、『Cisco Identity Services Engine Administrator Guide, Release 2.4 』の「Manually Promote Secondary PAN To Primary」のセクションを参照してください。
モニタリングとトラブルシューティング（MnT）ノードにロールを割り当てる方法の詳細については、『Cisco Identity Services Engine Administrator Guide, Release 2.4』の「Manually Modify MnT Role」を参照してください。
5. ポリシーサービスノードの参加
新しい展開にポリシーサービスノード（PSN）を参加させるには、ノードを PSN として登録する必要があります。PSN の登録または参加の詳細については、『Cisco Identity Services Engine Administrator Guide, Release 2.4』の「Register a Secondary Cisco ISE Node」を参照してください。
6. 証明書のインポート
Cisco ISE で新しく展開されたノードにシステム証明書をインポートする必要があります。システム証明書を Cisco ISE ノードにインポートする方法の詳細については、『Cisco Identity Services Engine Administrator Guide, Release 2.4』の「Import a System Certificate」セクションを参照してください。
バックアップと復元によるアップグレードプロセス
ここでは、推奨のバックアップと復元によるアップグレード方法を使用したアップグレードプロセスについて説明します。
現在 Cisco ISE リリース 2.0 以降を使用している場合は、Cisco ISE リリース 2.4 に直接アップグレードできます。
Cisco ise リリース 2.4 と互換性がない Cisco ISE バージョンを使用している場合は、最初に Cisco ISE リリース 2.4 と互換性のある中間バージョンにアップグレードする必要があります。その後、中間バージョンから Cisco ISE リリース 2.4 にアップグレードできます。Cisco ISE の中間バージョンにアップグレードするには、次の手順に従います。
セカンダリ PAN およびセカンダリ MnT ノードを Cisco ISE リリース 2.0、2.1、2.2、または 2.3 にアップグレードする
始める前に
既存の Cisco ISE からのバックアップを Cisco ISE 中間リリースに復元します。
手順
| ステップ 1 |
セカンダリ PAN ノードを登録解除します。 |
| ステップ 2 |
登録解除されたセカンダリ PAN ノードを、スタンドアロンノードとして、Cisco ISE 中間リリースに再イメージ化します。アップグレード後に、このノードを新しい展開でプライマリ管理ノードにします。 |
| ステップ 3 |
バックアップデータから Cisco ISE の設定を復元します。 |
| ステップ 4 |
セカンダリ MnT ノードを登録解除します。 |
| ステップ 5 |
登録解除されたセカンダリ MnT ノードを、スタンドアロンノードとして、Cisco ISE の中間リリースに再イメージ化します。 |
| ステップ 6 |
この MnT ノードにプライマリロールを割り当て、バックアップリポジトリから運用バックアップを復元します。これは省略可能な手順であり、古いログを報告する必要がある場合にのみ実行する必要があります。 |
| ステップ 7 |
元の Cisco ISE バックアップリポジトリから ise-https-admin CA 証明書をインポートします。 |
セカンダリ PAN および MnT ノードを Cisco ISE リリース 2.4 にアップグレードする
手順
| ステップ 1 |
Cisco ISE の構成設定と運用ログのバックアップを作成します。 |
| ステップ 2 |
セカンダリ PAN ノードを登録解除します。 |
| ステップ 3 |
登録解除されたセカンダリ PAN ノードを Cisco ISE リリース 2.4 に再イメージ化します。 |
| ステップ 4 |
バックアップデータから ISE 設定を復元し、このノードを新しい展開のプライマリノードとして設定します。 |
| ステップ 5 |
ワイルドカード証明書を使用していない場合は、セカンダリ PAN から ise-https-admin CA 証明書をインポートします。 |
| ステップ 6 |
セカンダリ MnT ノードを登録解除します。 |
| ステップ 7 |
登録解除されたセカンダリ MnT ノードを Cisco ISE リリース 2.4 に再イメージ化します。 |
| ステップ 8 |
現在の ISE 運用バックアップを復元し、新しい展開環境のプライマリ MnT としてノードを参加させます。これは省略可能な手順であり、古いログを報告する必要がある場合にのみ実行する必要があります。 |
ポリシーサービスノードを Cisco ISE リリース 2.4 に参加させる
Cisco ISE ノードが複数のサイトに展開されている場合は、最初に（セカンダリ PAN および MnT ノードを含む）サイトに使用可能な PSN を参加させてから、他のサイトに使用可能な PSN を参加させ、その後（既存の Cisco ISE のプライマリ PAN および MnT ノードを含む）サイトに使用可能な PSN を参加させます。
手順
| ステップ 1 |
PSN を登録解除します。 |
| ステップ 2 |
PSN を Cisco ISE リリース 2.4 の最新パッチに再イメージ化し、新しい Cisco ISE リリース 2.4 展開環境に参加させます。 |
次のタスク
この時点で、部分的にアップグレードされた展開環境をテストすることをお勧めします。これを行うには、ログが存在するかどうかを確認し、アップグレードされたノードが通常どおり機能していることを確認します。
プライマリ PAN および MnT を Cisco ISE リリース2.4 にアップグレードする
手順
| ステップ 1 |
プライマリ MnT ノードを再イメージ化し、セカンダリ MnT として新しい展開環境に参加させます。 レポート用のデータを保持する場合は、運用バックアップのコピーをセカンダリ MnT ノードに復元します。 |
| ステップ 2 |
プライマリ PAN ノードを再イメージ化し、セカンダリ PAN として新しい展開環境に参加させます。 |
GUI からの Cisco ISE 展開のアップグレード
GUI からの Cisco ISE 展開のアップグレード
Cisco ISE では、管理者ポータルから GUI ベースの一元化されたアップグレードが提供されます。アップグレードプロセスは大幅に簡素化され、アップグレードの進行状況およびノードのステータスが画面に表示されます。
[概要（Overview）] ページの メニューオプションには、展開内のすべてのノード、そのノードで有効なペルソナ、インストールされている ISE のバージョン、およびノードのステータス（ノードがアクティブか非アクティブか）がリストされます。ノードがアクティブな状態である場合にのみアップグレードを開始できます。
管理者用ポータルからの GUI ベースのアップグレードは、現在リリース 2.0 以降で、リリース 2.0.1 以上にアップグレードする場合にのみサポートされます。
リリース 2.0、2.0.1、2.1、2.2 または 2.3 からリリース 2.4 へのアップグレード
リリース 2.0 以降の管理者ポータルを使用して Cisco ISE 導入環境のすべてのノードをアップグレードすることもできます。また、Cisco ISE 2.0 以降の限定的な可用性リリースを一般的な可用性リリースにアップグレードすることもできます。
始める前に
（注） |
Cisco ISE STANDALONE ノードをアップグレードする場合、または既存の展開からノードを登録解除していて STANDALONE のアップグレードを実行する場合は、アップグレードを開始する前に、「/opt/oracle/base/admin/cpm10/dpdump」のパスにあるすべての upgradedb_*.properties ファイルを削除する必要があります。 上記のファイルを削除するにはルート権限が必要なため、Cisco TAC にお問い合わせください。詳細については CSCvi87302 を参照してください。 上記の回避策は、2018 年 4 月 13 日より前にアップグレードファイル（ise-upgradebundle-2.0.x-2.3.x-to-2.4.0.357.SPA.x86_64.tar.gz）をダウンロードした場合のみ必要です。 |
アップグレードする前に、次の作業が完了していることを確認します。
-
ISE の設定および運用データのバックアップを取得します。
-
システムログのバックアップを取得します。
-
スケジュールしたバックアップを無効にします。展開のアップグレードが完了したら、バックアップスケジュールを再設定します。
-
証明書および秘密キーをエクスポートします。
-
リポジトリを設定します。アップグレードバンドルをダウンロードし、このリポジトリに格納します。
-
Active Directory の参加クレデンシャルと RSA SecurID ノード秘密のメモを取ります（該当する場合）。この情報は、アップグレード後に Active Directory または RSA SecurID サーバに接続するために必要です。
-
アップグレードのパフォーマンスを向上させるために、運用データを消去します。
-
リポジトリとのインターネット接続が良好であることを確認します。
（注）
リポジトリからノードにアップグレードバンドルをダウンロードする場合、ダウンロードが完了するまでに 35 分以上かかるとダウンロードがタイムアウトします。この問題は、インターネットの帯域幅が不十分なために発生します。
手順
| ステップ 1 |
管理者ポータルの [アップグレード（Upgrade）] タブをクリックします。 |
||||
| ステップ 2 |
[続行（Proceed）] をクリックします。 [レビューチェックリスト（Review Checklist）] ウィンドウが表示されます。表示された手順を確認してください。 |
||||
| ステップ 3 |
[チェックリストを確認済み（I have reviewed the checklist）] チェックボックスをオンにし、[続行（Continue）] をクリックします。 [バンドルのノードへのダウンロード（Download Bundle to Nodes）] ウィンドウが表示されます。 |
||||
| ステップ 4 |
リポジトリからノードにアップグレードバンドルをダウンロードします。 |
||||
| ステップ 5 |
[続行（Continue）] をクリックします。 [ノードのアップグレード（Upgrade Nodes）] ウィンドウが表示されます。  |
||||
| ステップ 6 |
アップグレード順序を選択します。 ノードを新しい展開に移動すると、アップグレードの推定所要時間が [ノードのアップグレード（Upgrade Nodes）] ウィンドウに表示されます。この情報を使用して、アップグレードを計画し、ダウンタイムを最小化できます。管理ノードとモニタリングノードのペアおよび複数のポリシーサービスノードがある場合は、以下の手順に従います。 |
||||
| ステップ 7 |
アップグレードがアップグレード順序のいずれかのポリシーサービスノードで失敗した場合でもアップグレードを続行するには、[失敗時でもアップグレードを続行する（Continue with upgrade on failure）] チェックボックスをオンにします。 このオプションは、セカンダリ管理ノードおよびプライマリ モニタリング ノードには適用されません。これらのノードのいずれかに障害が発生すると、アップグレードプロセスはロールバックされます。ポリシーサービスノードのいずれかが失敗すると、セカンダリ モニタリング ノードおよびプライマリ管理ノードはアップグレードされず、古い展開内に残ります。 |
||||
| ステップ 8 |
[アップグレード（Upgrade）] をクリックして、展開のアップグレードを開始します。  各ノードのアップグレードの進行状況が表示されます。正常に完了すると、ノードのステータスが [アップグレード完了（Upgrade Complete）] に変わります。
警告メッセージ「The node has been reverted back to its pre-upgrade state 」が表示された場合は、[アップグレード（Upgrade）]ウィンドウに移動し、[詳細（Details）] リンクをクリックします。[アップグレードの失敗の詳細（Upgrade Failure Details）] ウィンドウに記載されている問題を解決します。すべての問題を解決した後、[アップグレード（Upgrade）] をクリックして、アップグレードを再起動します。
|
CLI からの Cisco ISE 展開のアップグレード
アップグレードプロセス
（注） |
Cisco ISE スタンドアロンノードをアップグレードする場合、または既存の展開からノードを登録解除していてスタンドアロンのアップグレードを実行する場合は、アップグレードを開始する前に、「/opt/oracle/base/admin/cpm10/dpdump」のパスにあるすべての upgradedb_*.properties ファイルを削除する必要があります。 これらのファイルを削除するにはルート権限が必要になるため、Cisco TAC に接続する必要があります。詳細については CSCvi87302 を参照してください。 この回避策は、アップグレードファイル（ise-upgradebundle-2.0.x-2.3.x-to-2.4.0.357.SPA.x86_64.tar.gz）が 2018 年 4 月 13 日よりも前にダウンロードされた場合にのみ必要です。 |
スタンドアロンノードのアップグレード
application upgrade コマンドを直接使用したり、アプリケーション アップグレード prepare および proceed コマンドを指定された順番に使用してスタンドアロンノードをアップグレードすることもできます。
管理、ポリシーサービス、pxGrid、およびモニタリングのペルソナを担当するスタンドアロンノードの CLI から application upgrade コマンドを実行できます。このコマンドを直接実行する場合は、application upgrade コマンドを実行する前にリモートリポジトリから Cisco ISE ノードのローカルディスクにアップグレードバンドルをコピーして、アップグレードの時間を短縮することを推奨します。
代わりに、application upgrade prepare コマンドと application upgrade proceed コマンドを使用することもできます。application upgrade prepare コマンドを使用すると、アップグレードバンドルがダウンロードされ、ローカルに抽出されます。このコマンドはリモートリポジトリから Cisco ISE ノードのローカルディスクにアップグレードバンドルをコピーします。ノードをアップグレードする準備ができたら、application upgrade proceed コマンドを実行してアップグレードを正常に完了します。
以下で説明する application upgrade prepare および proceed コマンドを実行することをお勧めします。
始める前に
アップグレードの準備に関する章の説明を必ず読んでください。
手順
| ステップ 1 |
ローカルディスクのリポジトリを作成します。たとえば、「upgrade」というリポジトリを作成できます。 例: |
||
| ステップ 2 |
Cisco ISE コマンドライン インターフェイス（CLI）から、 application upgrade prepare コマンドを入力します。 このコマンドは、アップグレードバンドルを前の手順で作成したローカルリポジトリ「upgrade」にコピーし、MD5 と SHA256 チェックサムを一覧表示します。 例: |
||
| ステップ 3 |
Cisco ISE CLI から、application upgrade proceed コマンドを入力します。
例:これでアップグレードは完了です。 |
次のタスク
2 ノード展開のアップグレード
application upgrade prepare コマンドおよび proceed コマンドを使用して、2 ノード展開をアップグレードします。手動でノードの登録を解除して、再登録する必要はありません。アップグレードソフトウェアは自動的にノードを登録解除し、新しい展開に移行します。2 ノード展開をアップグレードする場合、最初にセカンダリ管理ノード（ノード B）だけをアップグレードする必要があります。セカンダリノードのアップグレードを完了したら、プライマリノード（ノード A）をアップグレードします。次の図に示すような展開の設定の場合、このアップグレード手順を続けることができます。
始める前に
-
プライマリ管理ノードから設定および運用データのオンデマンドバックアップを手動で実行します。
-
管理とモニタリングのペルソナが、展開の両方のノードでイネーブルにされていることを確認します。
管理ペルソナがプライマリ管理ノードでのみイネーブルである場合、アップグレードプロセスによりセカンダリ管理ノードを最初にアップグレードすることが求められるので、セカンダリノードの管理ペルソナをイネーブルにします。
または、2 ノード展開で 1 つの管理ノードのみがある場合は、セカンダリノードの登録を解除します。両方のノードがスタンドアロンノードになります。両方のノードをスタンドアロンノードとしてアップグレードし、アップグレード後に、展開をセットアップします。
-
モニタリングペルソナが 1 つのノードのみでイネーブルの場合、次に進む前に他のノードのモニタリングペルソナをイネーブルにします。
手順
| ステップ 1 |
CLI からセカンダリノード（ノード B）をアップグレードします。 アップグレードプロセスで、自動的にノード B が展開から削除され、アップグレードされます。ノード B は再起動すると、プライマリノードにアップグレードされます。 |
| ステップ 2 |
アップグレードノード A。 アップグレードプロセスで、自動的にノード A が展開に登録され、アップグレードされた環境でセカンダリノードになります。 |
| ステップ 3 |
新規の展開で、ノード A をプライマリノードに昇格させます。 アップグレードが完了した後、ノードに古いモニタリング ログが含まれる場合、これらのノード上で application configure ise コマンドを実行し、5（データベースの統計情報の更新）を選択します。 |
次のタスク
分散展開のアップグレード
初めに、セカンダリ管理ノードを新しいリリースにアップグレードします。たとえば、次の図に示すように、1 つのプライマリ管理ノード（ノード A）、1 つのセカンダリ管理ノード（ノード B）、および 4 つのポリシーサービスノード（PSN）（ノード C、ノード D、ノード E、およびノード F）、1 つのプライマリ モニタリング ノード（ノード G）、および 1 つのセカンダリ モニタリング ノード（ノード I）を含む展開がセットアップされている場合、次のアップグレード手順に進むことができます。
（注） |
アップグレードの前にノードを手動で登録解除しないでください。application upgrade prepare コマンドおよび proceed コマンドを使用して、新しいリリースにアップグレードします。アップグレードプロセスは自動的にノードを登録解除し、新しい展開に移行します。アップグレードの前に手動でノードの登録をキャンセルする場合は、アップグレードプロセスを開始する前に、プライマリ管理ノードのライセンスファイルがあることを確認します。手元にこのファイルがない場合（たとえば、シスコパートナーベンダーによってライセンスがインストールされた場合）、Cisco Technical Assistance Center に連絡してください。 |
始める前に
-
展開にセカンダリ管理ノードがない場合は、アップグレードプロセスを開始する前に、セカンダリ管理ノードにするポリシーサービスノードを 1 つ設定します。
-
「Prepare for Upgrade」の章で説明されている手順をすでに読んで完了していることを確認します。
-
全 Cisco ISE 展開をアップグレードする場合は、ドメインネームシステム（DNS）のサーバ解決（順ルックアップおよび逆ルックアップ）が必須です。そうでない場合、アップグレードは失敗します。
手順
| ステップ 1 |
CLI からセカンダリ管理ノード（ノード B）をアップグレードします。 アップグレードプロセスで、自動的にノード B が展開から登録解除され、アップグレードされます。再起動すると、ノード B は、新しい展開のプライマリノードになります。各展開でモニタリングノードが少なくとも 1 つ必要になるため、アップグレードプロセスは古い展開の該当ノードでイネーブルになっていなくても、ノード B のモニタリングペルソナをイネーブルにします。ポリシーサービスペルソナが古い展開のノード B でイネーブルであった場合、この設定は新しい展開へのアップグレード後も維持されます。 |
| ステップ 2 |
モニタリングノードの 1 つ（ノード G）を新規展開にアップグレードします。 セカンダリ モニタリング ノードの前にプライマリ モニタリング ノードをアップグレードすることをお勧めします（古い展開でプライマリ管理ノードがプライマリ モニタリング ノードとしても動作している場合にはこれは不可能です）。プライマリ モニタリング ノードが起動し、新規展開からログを収集します。この詳細は、プライマリ管理ノードのダッシュボードから表示できます。 古い展開でモニタリングノードが 1 つだけある場合は、アップグレードする前に、古い展開のプライマリ管理ノードであるノード A のモニタリングペルソナをイネーブルにします。ノードペルソナの変更により、Cisco ISE アプリケーションが再起動します。ノード A が再起動するまで待ちます。新規展開にモニタリングノードをアップグレードすると、運用データを新しい展開に移行する必要があるために、他のノードよりも時間がかかります。 新規展開のプライマリ管理ノードであるノード B が、古い展開でイネーブルにされたモニタリングペルソナを持たない場合、モニタリングペルソナをディセーブルにします。ノードペルソナの変更により、Cisco ISE アプリケーションが再起動します。プライマリ管理ノードが起動するまで待ちます。 |
| ステップ 3 |
次にポリシーサービスノード（ノード C、D、E、F）をアップグレードします。複数の PSN を同時にアップグレードできますが、すべての PSN を同時にアップグレードした場合、ネットワークでダウンタイムが発生します。 PSN がノードグループクラスタの一部である場合、PSN を PAN から登録解除し、スタンドアロンノードとしてアップグレードし、新規展開の PAN に登録する必要があります。 アップグレード後に、新規展開のプライマリノード（ノード B）に PSN が登録され、プライマリノード（ノード B）からのデータがすべての PSN に複製されます。PSN ではそのペルソナ、ノードグループ情報、およびプローブのプロファイリング設定が維持されます。 |
| ステップ 4 |
（展開に IPN ノードがある場合）プライマリ管理ノードから IPN ノードの登録を解除します。 Cisco ISE、リリース 2.0 以降は、IPN ノードはサポートしていません。 |
| ステップ 5 |
古い展開に 2 番目のモニタリングノード（ノード I）がある場合、次のことを行う必要があります。 プライマリ管理ノード（ノード A）を除いて、他のすべてのノードが新規展開にアップグレードされている必要があります。 |
| ステップ 6 |
最後に、プライマリ管理ノード（ノード A）をアップグレードします。 このノードは、セカンダリ管理ノードとしてアップグレードされ、新規展開に追加されます。セカンダリ管理ノード（ノード A）を新規展開のプライマリ ノードに昇格させることができます。 アップグレードが完了した後、アップグレードされたモニタリングノードに古いログが含まれる場合、application configure ise コマンドを実行し、該当するモニタリングノードで 5（データベースの統計情報の更新）を選択します。 |
例
次の例は、セカンダリ管理ノードの正常なアップグレードの CLI トランスクリプトです。
ise74/admin# application upgrade proceed
Initiating Application Upgrade...
% Warning: Do not use Ctrl-C or close this terminal window until upgrade completes.
-Checking VM for minimum hardware requirements
STEP 1: Stopping ISE application...
STEP 2: Verifying files in bundle...
-Internal hash verification passed for bundle
STEP 3: Validating data before upgrade...
STEP 4: De-registering node from current deployment...
STEP 5: Taking backup of the configuration data...
STEP 6: Running ISE configuration database schema upgrade...
- Running db sanity to check and fix if any index corruption
- Auto Upgrading Schema for UPS Model
- Upgrading Schema completed for UPS Model
ISE database schema upgrade completed.
% Warning: Sanity test found some indexes missing in CEPM schema. Please recreate missing indexes after upgrade using app configure ise cli
STEP 7: Running ISE configuration data upgrade...
- Data upgrade step 1/30, UPSUpgradeHandler(2.4.0.101)... Done in 42 seconds.
- Data upgrade step 2/30, UPSUpgradeHandler(2.4.0.116)... Done in 0 seconds.
- Data upgrade step 3/30, MachineAuthenticationSettingsRegistration(2.4.0.120)... Done in 0 seconds.
- Data upgrade step 4/30, GuestAccessUpgradeService(2.4.0.126)... Done in 14 seconds.
- Data upgrade step 5/30, RegisterPostureTypes(2.4.0.127)... Done in 1 seconds.
- Data upgrade step 6/30, UPSUpgradeHandler(2.4.0.127)... Done in 0 seconds.
- Data upgrade step 7/30, UPSUpgradeHandler(2.4.0.134)... Done in 0 seconds.
- Data upgrade step 8/30, NSFUpgradeService(2.4.0.140)... Done in 0 seconds.
- Data upgrade step 9/30, NSFUpgradeService(2.4.0.155)... Done in 1 seconds.
- Data upgrade step 10/30, UPSUpgradeHandler(2.4.0.158)... Done in 1 seconds.
- Data upgrade step 11/30, NSFUpgradeService(2.4.0.160)... Done in 0 seconds.
- Data upgrade step 12/30, NSFUpgradeService(2.4.0.161)... Done in 0 seconds.
- Data upgrade step 13/30, NSFUpgradeService(2.4.0.179)... Done in 0 seconds.
- Data upgrade step 14/30, NetworkAccessUpgrade(2.4.0.182)... Done in 1 seconds.
- Data upgrade step 15/30, StorageUpgradeService(2.4.0.183)... Done in 0 seconds.
- Data upgrade step 16/30, DnsHostnameResolutionRegistration(2.4.0.190)... Done in 0 seconds.
- Data upgrade step 17/30, ProfilerUpgradeService(2.4.0.194)... ..Done in 122 seconds.
- Data upgrade step 18/30, CertMgmtUpgradeService(2.4.0.200)... ....Done in 248 seconds.
- Data upgrade step 19/30, NSFUpgradeService(2.4.0.214)... Done in 0 seconds.
- Data upgrade step 20/30, ERSDictionaryRegistration(2.4.0.215)... Done in 0 seconds.
- Data upgrade step 21/30, NetworkAccessUpgrade(2.4.0.216)... Done in 0 seconds.
- Data upgrade step 22/30, ProfilerUpgradeService(2.4.0.227)... Done in 0 seconds.
- Data upgrade step 23/30, ProfilerUpgradeService(2.4.0.228)... Done in 4 seconds.
- Data upgrade step 24/30, ProfilerUpgradeService(2.4.0.229)... Done in 0 seconds.
- Data upgrade step 25/30, NetworkAccessUpgrade(2.4.0.240)... Done in 0 seconds.
- Data upgrade step 26/30, CertMgmtUpgradeService(2.4.0.293)... Done in 7 seconds.
- Data upgrade step 27/30, ProvisioningUpgradeService(2.4.0.299)... Done in 0 seconds.
- Data upgrade step 28/30, NSFUpgradeService(2.4.0.336)... Done in 3 seconds.
- Data upgrade step 29/30, ProfilerUpgradeService(2.4.0.336)... Done in 0 seconds.
- Data upgrade step 30/30, GuestAccessUpgradeService(2.4.0.336)... Done in 23 seconds.
STEP 8: Running ISE configuration data upgrade for node specific data...
STEP 9: Making this node PRIMARY of the new deployment. When other nodes are upgraded it will be added to this deployment.
STEP 10: Running ISE M&T database upgrade...
M&T Log Processor is not running
ISE database M&T schema upgrade completed.
cat: /opt/oracle/base/admin/cpm10/dpdump/upgradedb*.properties: No such file or directory
Gathering Config schema(CEPM) stats .....
Gathering Operational schema(MNT) stats ....
% NOTICE: The appliance will reboot twice to upgrade software and ADE-OS. During this time progress of the upgrade is visible on console. It could take up to 30 minutes for this to complete.
Rebooting to do Identity Service Engine upgrade...次の例は、正常な PSN ノードのアップグレードの CLI トランスクリプトです。
ise/admin# application upgrade proceed
Initiating Application Upgrade...
% Warning: Do not use Ctrl-C or close this terminal window until upgrade completes.
-Checking VM for minimum hardware requirements
STEP 1: Stopping ISE application...
STEP 2: Verifying files in bundle...
-Internal hash verification passed for bundle
STEP 3: Validating data before upgrade...
STEP 4: De-registering node from current deployment...
STEP 5: Taking backup of the configuration data...
STEP 6: Running ISE configuration database schema upgrade...
- Running db sanity to check and fix if any index corruption
- Auto Upgrading Schema for UPS Model
- Upgrading Schema completed for UPS Model
ISE database schema upgrade completed.
% Warning: Sanity test found some indexes missing in CEPM schema. Please recreate missing indexes after upgrade using app configure ise cli
STEP 7: Running ISE configuration data upgrade...
- Data upgrade step 1/30, UPSUpgradeHandler(2.4.0.101)... Done in 42 seconds.
- Data upgrade step 2/30, UPSUpgradeHandler(2.4.0.116)... Done in 0 seconds.
- Data upgrade step 3/30, MachineAuthenticationSettingsRegistration(2.4.0.120)... Done in 0 seconds.
- Data upgrade step 4/30, GuestAccessUpgradeService(2.4.0.126)... Done in 14 seconds.
- Data upgrade step 5/30, RegisterPostureTypes(2.4.0.127)... Done in 1 seconds.
- Data upgrade step 6/30, UPSUpgradeHandler(2.4.0.127)... Done in 0 seconds.
- Data upgrade step 7/30, UPSUpgradeHandler(2.4.0.134)... Done in 0 seconds.
- Data upgrade step 8/30, NSFUpgradeService(2.4.0.140)... Done in 0 seconds.
- Data upgrade step 9/30, NSFUpgradeService(2.4.0.155)... Done in 1 seconds.
- Data upgrade step 10/30, UPSUpgradeHandler(2.4.0.158)... Done in 1 seconds.
- Data upgrade step 11/30, NSFUpgradeService(2.4.0.160)... Done in 0 seconds.
- Data upgrade step 12/30, NSFUpgradeService(2.4.0.161)... Done in 0 seconds.
- Data upgrade step 13/30, NSFUpgradeService(2.4.0.179)... Done in 0 seconds.
- Data upgrade step 14/30, NetworkAccessUpgrade(2.4.0.182)... Done in 1 seconds.
- Data upgrade step 15/30, StorageUpgradeService(2.4.0.183)... Done in 0 seconds.
- Data upgrade step 16/30, DnsHostnameResolutionRegistration(2.4.0.190)... Done in 0 seconds.
- Data upgrade step 17/30, ProfilerUpgradeService(2.4.0.194)... ..Done in 122 seconds.
- Data upgrade step 18/30, CertMgmtUpgradeService(2.4.0.200)... ....Done in 248 seconds.
- Data upgrade step 19/30, NSFUpgradeService(2.4.0.214)... Done in 0 seconds.
- Data upgrade step 20/30, ERSDictionaryRegistration(2.4.0.215)... Done in 0 seconds.
- Data upgrade step 21/30, NetworkAccessUpgrade(2.4.0.216)... Done in 0 seconds.
- Data upgrade step 22/30, ProfilerUpgradeService(2.4.0.227)... Done in 0 seconds.
- Data upgrade step 23/30, ProfilerUpgradeService(2.4.0.228)... Done in 4 seconds.
- Data upgrade step 24/30, ProfilerUpgradeService(2.4.0.229)... Done in 0 seconds.
- Data upgrade step 25/30, NetworkAccessUpgrade(2.4.0.240)... Done in 0 seconds.
- Data upgrade step 26/30, CertMgmtUpgradeService(2.4.0.293)... Done in 7 seconds.
- Data upgrade step 27/30, ProvisioningUpgradeService(2.4.0.299)... Done in 0 seconds.
- Data upgrade step 28/30, NSFUpgradeService(2.4.0.336)... Done in 3 seconds.
- Data upgrade step 29/30, ProfilerUpgradeService(2.4.0.336)... Done in 0 seconds.
- Data upgrade step 30/30, GuestAccessUpgradeService(2.4.0.336)... Done in 23 seconds.
STEP 8: Running ISE configuration data upgrade for node specific data...
STEP 9: Making this node PRIMARY of the new deployment. When other nodes are upgraded it will be added to this deployment.
STEP 10: Running ISE M&T database upgrade...
M&T Log Processor is not running
ISE database M&T schema upgrade completed.
cat: /opt/oracle/base/admin/cpm10/dpdump/upgradedb*.properties: No such file or directory
Gathering Config schema(CEPM) stats .....
Gathering Operational schema(MNT) stats ....
% NOTICE: The appliance will reboot twice to upgrade software and ADE-OS. During this time progress of the upgrade is visible on console. It could take up to 30 minutes for this to complete.
Rebooting to do Identity Service Engine upgrade...次のタスク
アップグレードプロセスの確認
展開が期待どおりに機能すること、およびユーザが認証されネットワークのリソースにアクセスできることを確認するためのネットワークテストを実行することを推奨します。
構成データベースの問題でアップグレードが失敗すると、変更された内容が自動的にロールバックされます。
手順
|
アップグレードが正常に完了したかどうかを確認するには、次のいずれかのオプションを実行します。
|
ISO イメージの以前のバージョンへのロールバック
まれに、以前のバージョンの ISO イメージを使用し、バックアップファイルからデータを復元することで、Cisco ISE アプライアンスのイメージを再作成する必要がある場合があります。データを復元した後は、古い展開を登録して、古い展開で行ったようにペルソナを有効にすることができます。したがって、アップグレードプロセスを開始する前に、Cisco ISE 設定およびモニタリングデータをバックアップすることをお勧めします。
設定およびモニタリングデータベースの問題により発生したアップグレードの障害は、自動的にロールバックされないことがあります。これが発生すると、データベースがロールバックされないことを示す通知を、アップグレードの失敗メッセージと共に受け取ります。このようなシナリオでは、手動でシステムのイメージを再作成し、Cisco ISE をインストールして、設定およびモニタリングデータを復元（モニタリングペルソナが有効な場合）する必要があります。
ロールバックまたは回復を行う前に、backup-logs コマンドを使用してサポートバンドルを生成し、そのサポートバンドルをリモートリポジトリに配置します。
フィードバック