この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章では、サービス レベル HA の Cisco NX-OS サービスの再起動性について説明します。次の項で構成されています。
Cisco NX-OS サービス再起動機能では、スーパーバイザを再起動せずに障害の発生したサービスを再起動することによって、プロセス レベルの障害がシステム レベルの障害に拡大するのを防ぐことができます。 サービスは、現在のエラー、障害状況、サービスのハイ アベイラビリティ ポリシーに基づいて再起動できます。 サービスの再起動には、ステートフルな再起動とステートレスな再起動があります。 Cisco NX-OS では、サービスが実行時の状態情報とメッセージを保存することで、ステートフルな再起動を実現しています。 ステートフルな再起動では、サービスが保存されていた状態情報を取り出して、直前のチェックポイント サービス状態から動作を再開します。 ステートレスな再起動では、サービスは、初めて起動するときのように、初期化および実行されます。
すべてのサービスがステートフルな再起動が可能なように設計されているわけではありません。 たとえば、Cisco NX-OS は、3 層ルーティング プロトコル(Open Shortest Path First(OSPF)や Routing Information Protocol(RIP)など)の実行時の状態情報を保存しません。 これらのプロトコルは、再起動のあとも設定は維持されますが、動作状態については隣接するルータから情報を取得して再構築するように設計されています。 3 層プロトコルのハイ アベイラビリティ機能の詳細は、ネットワークレベル ハイ アベイラビリティを参照してください。
VDC の詳細については、『Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide』を参照してください。
サービス レベル HA 機能にライセンスは必要ありません。 ライセンス パッケージに含まれていない機能はすべて Cisco NX-OS システム イメージにバンドルされており、追加費用は一切発生しません。 |
|
Cisco NX-OS ライセンス 方式の詳細については、『Cisco Nexus 7000 Series NX-OS Licensing Guide』を参照してください。
Cisco NX-OS は、ほとんどのプロセスおよびサービスでステートフル リスタートが可能です。 プラットフォーム内のプロセス、サービス、アプリケーションのバック エンド管理および調整は一連の高レベルのシステム コントロール サービスによって処理されます。
システム マネージャは、あらゆるシステム機能、システム管理、システム ヘルス モニタリングの実行を制御し、ハイ アベイラビリティ ポリシーを実施します。 システム マネージャは、サービスの起動、停止、モニタリング、再起動を担当し、サービス ステートとスーパーバイザ ステートの同期を管理および起動して SSO を実現します。
Cisco NX-OS サービスは、永続ストレージ サービス(PSS)を使用して、運用の実行時情報を保存および管理します。 PSS コンポーネントは、システム サービスを使用して、サービス再起動時に状態を回復します。 PSS は状態および実行時情報のデータベースとして機能します。これにより、各サービスは、必要なときにいつでも、サービス自体の状態情報のチェックポイントを作成できます。 サービスを再起動すると、障害が発生する直前の既知の動作状態を回復できるので、ステートフルな再起動が可能になります。
PSS を使用する各サービスは、保存された情報をプライベート情報(当サービスだけ読み取り可能)または共有情報(他のサービスも読み取り可能)として定義できます。 情報を共有する場合は、ローカル(同一スーパーバイザ上のサービスだけ読み取り可能)またはグローバル(スーパーバイザまたはモジュール上のサービスが読み取り可能)のどちらかを指定できます。 たとえば、アクティブなスーパーバイザ上で実行されているサービスの PSS 情報を共有かつグローバルとして定義すると、他のモジュール上のサービスは、その PSS 情報と同期することができます。
Message and Transaction Service(MTS; メッセージおよびトランザクション サービス)は、ハイ アベイラビリティ セマンティクスに特化した高パフォーマンス Interprocess Communication(IPC; プロセス間通信)メッセージ ブローカです。 MTS は、モジュール内とモジュール間、およびスーパーバイザ間でメッセージのルーティングとキューイングを行います。 また、イベント通知や同期などのメッセージ交換を容易にし、システム サービス間およびシステム コンポーネント間のメッセージ永続性を促進します。 MTS では、永続メッセージおよびログ メッセージをキュー内に保管できるため、サービスの再起動後もそれらのメッセージにアクセスできます。
Cisco NX-OS では、各サービスに、障害の発生したサービスの再起動方法を定義する一連の内部 HA ポリシーのセットを作成できます。 サービスごとに 4 つの定義済みポリシーを用意できます。つまり、スーパーバイザが 2 つの場合のプライマリ ポリシーとセカンダリ ポリシー、スーパーバイザが 1 つだけの場合のプライマリ ポリシーとセカンダリ ポリシーです。 HA ポリシーが定義されていないサービスでは、サービスの障害発生時に実行されるデフォルトの HA ポリシーは、スーパーバイザが 2 つの場合はスイッチオーバー、スーパーバイザが 1 つの場合はスーパーバイザのリセットとなります。
プロセスの再起動性により、データ プレーンやその他のサービスを中断せずに、障害の発生したサービスを回復し動作を再開することができます。 システム マネージャは、サービスの HA ポリシー、前回の再起動の失敗、同じスーパーバイザ上で実行されているその他のサービスのヘルス状態に応じて、サービスの障害発生時に実行するアクションを決定します。
さまざまな障害発生時にシステム マネージャによって実行されるアクションを次の表で説明します。
再起動可能なサービスで障害が発生すると、サービスは同じスーパーバイザ上で再起動されます。 サービスの新しいインスタンスは、以前のインスタンスがオペレーティング システムによって異常終了させられたと判断した場合、永続コンテキストがあるかどうかを確認します。 新しいインスタンスは初期化時に永続コンテキストを読み込んで、実行時コンテキストを構築します。この結果、新しいインスタンスは障害発生前のインスタンスと同じ状態になります。 初期化が完了すると、サービスは、停止したときに実行していたタスクを再開します。 新しいインスタンスが再起動および初期化されている間、他のサービスは、そのような障害が発生していることを認識していません。 他のサービスから障害が発生したサービスに送信されたメッセージは、サービスが再開された時点で MTS から取得できます。
新しいインスタンスでステートフルな初期化を完了できるかどうかは、前のインスタンスの障害の原因に依存します。 サービスで再起動を数回実行できない場合、そのサービスの再起動は失敗したと見なされます。 その場合、システム マネージャは、再起動に失敗したサービスの HA ポリシーに指定されたアクション(ステートレスな再起動、再起動しない、スーパーバイザのスイッチオーバーまたはリセットのいずれか)を実行します。
ステートフルな再起動に成功した場合、システムが矛盾のない状態に到達するまでに遅延が発生することはありません。 ステートフルな再起動により、障害発生後の回復に要する時間が短縮されます。
ステートフルな再起動の前後および最中に発生するイベントは次のとおりです。
何度か再起動してもサービスの動作が安定しない場合、システム マネージャはスーパーバイザのリセットまたはスイッチオーバーを開始します。
Cisco NX-OS はプロセス スタックとコアをデバッグ用に収集します。また、オプションでコア ファイルをリモートに転送します。
ステートフルな再起動が発生すると、Cisco NX-OS がレベル LOG_ERR の Syslog メッセージを送信します。 SNMP トラップがイネーブルになっている場合は、SNMP エージェントがトラップを送信します。 Smart Call Home サービスがイネーブルになっている場合は、サービスがイベント メッセージを送信します。
Cisco NX-OS インフラストラクチャ コンポーネントは、ステートレスな再起動を管理します。 ステートレスな再起動中、システム マネージャは、障害の発生したプロセスを特定し、新しいプロセスに置き換えます。 障害の発生したサービスは再起動時に実行時状態を保持していません。 実行中のコンフィギュレーションから実行時状態を構築するか、必要なら、他のサービスと情報を交換して実行時状態を構築します。
ステートレスな再起動が発生すると、Cisco NX-OS がレベル LOG_ERR の Syslog メッセージを送信します。 SNMP トラップがイネーブルになっている場合は、SNMP エージェントがトラップを送信します。 Smart Call Home サービスがイネーブルになっている場合は、サービスがイベント メッセージを送信します。
スタンバイ スーパーバイザが使用可能な場合で、複数の障害が同時に発生したときには、Cisco NX-OS は常に、スーパーバイザの再起動ではなくスーパーバイザのスイッチオーバーを実行します。こうしたケースは、同一スーパーバイザ上では回復不可能と見なされるからです。 たとえば、複数の HA アプリケーションで障害が発生すると、回復不可能と見なされます。 スーパーバイザのスイッチオーバーおよび再起動の詳細については、システムレベルのハイ アベイラビリティを参照してください。
スタンバイ状態のスーパーバイザ上のサービスで障害が発生した場合、システム マネージャは HA ポリシーを適用せず、30 秒待ってからサービスを再起動します。 30 秒待つことで、スタンバイ サービスの障害と同期化が繰り返されたとき、アクティブなスーパーバイザが対応しきれなくなるのを避けることができます。 再起動されるサービスをアクティブなスーパーバイザ上のサービスと同期させる必要がある場合、スタンバイ スーパーバイザは、当該サービスの再起動と同期化が完了するまでホット スタンバイ モードではなくなります。 サービスが再起動不可能な場合は、スタンバイ スーパーバイザがリセットされます。
スタンバイ サービスの再起動が発生すると、Cisco NX-OS はレベル LOG_ERR の Syslog メッセージを送信します。 SNMP トラップがイネーブルになっている場合は、SNMP エージェントがトラップを送信します。 Smart Call Home サービスがイネーブルになっている場合は、サービスがイベント メッセージを送信します。
スイッチング モジュールまたは別の非スーパーバイザ モジュール上でサービスの障害が発生した場合は、それらのサービスの HA ポリシーによって回復アクションが決まります。 非スーパーバイザ モジュール上でサービスの障害が発生した場合は、スーパーバイザのスイッチオーバーは必要ないため、回復方法は、ステートフルな再起動、ステートレスな再起動、モジュールのリセットのいずれかになります。 中断なしにアップグレード可能なモジュールは、中断なしに再起動も可能です。
モジュール サービスの中断なしの再起動が発生すると、Cisco NX-OS はレベル LOG_ERR の Syslog メッセージを送信します。 SNMP トラップがイネーブルになっている場合は、SNMP エージェントがトラップを送信します。 Smart Call Home サービスがイネーブルになっている場合は、サービスがイベント メッセージを送信します。
サービスで障害が発生し、すべての HA ポリシーでサービスの再起動が失敗に終わった場合、次に実行されるアクションは、通常、スーパーバイザの再起動またはスイッチオーバーです。しかし、VDC 内で実行されているサービスの場合は、スーパーバイザの再起動またはスイッチオーバーを実行する前に VDC の再起動を試行するよう、VDC ポリシーに指定できます。
VDC の詳細については、『Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide』を参照してください。
サービスで障害が発生すると、システムは障害の原因を判定するために使用できる情報を生成します。 次の情報ソースが使用可能です。
Smart Call Home サービスがイネーブルになっている場合は、サービスの再起動によって Smart Call Home イベントが生成されます。
SNMP トラップがイネーブルになっている場合は、サービスが再起動されると、SNMP エージェントがトラップを送信します。
サービスの障害がローカル モジュール上で発生した場合は、そのモジュール内で show processes log コマンドを入力することで、イベントのログを表示できます。 プロセスのログは、スーパーバイザのスイッチオーバーまたはリセット後も保持されます。
サービスの障害が発生すると、システムのコア イメージ ファイルが生成されます。 最新のコア イメージを表示するには、アクティブなスーパーバイザ上で show cores コマンドを使用します。 コア ファイルはスーパーバイザのスイッチオーバーまたはリセット後は削除されますが、Trivial File Transfer Protocol(TFTP; 簡易ファイル転送プロトコル)などのファイル転送ユーティリティを使用してコア ファイルを外部サーバにエクスポートするようにシステムを設定することもできます。
サービスの障害に関する情報を収集および使用する方法については、『Cisco Nexus 7000 Series NX-OS Troubleshooting Guide』を参照してください。
『Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide』 | |
システムレベルのハイ アベイラビリティ | |
『Cisco Nexus 7000 Series NX-OS Troubleshooting Guide』 | |
『Cisco Nexus 7000 Series NX-OS Fundamentals Configuration Guide』 | |
『Cisco Nexus 7000 Series NX-OS Licensing Guide』 |
MIB を検索およびダウンロードするには、次の URL にアクセスしてください。 http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml |
Technical Assistance Center(TAC)ホーム ページ:多数の技術関連の記事と、製品、テクノロジー、ソリューション、テクニカル ティップス、ツールへのリンクを提供する Web サイトです。必要な記事は検索して見つけることができます。 Cisco.com に登録済みのユーザは、このページから詳細情報にアクセスできます。 |
(注) |
この章では、プロセスとサービスは同じ意味で使用されています。 プロセスは、サービスの実行中のインスタンスと見なされます。 |
目次
- Cisco NX-OS サービスの再起動について
- ライセンス要件
- 再起動性インフラストラクチャ
- プロセスの再起動性
- スタンバイ スーパーバイザ サービスの再起動
- スイッチング モジュール サービスの再起動
- VDC 内サービスの再起動
- 再起動のトラブルシューティング
- 関連資料
- 標準
- MIB
- RFC
- テクニカル サポート
Cisco NX-OS サービスの再起動について
Cisco NX-OS サービス再起動機能では、スーパーバイザを再起動せずに障害の発生したサービスを再起動することによって、プロセス レベルの障害がシステム レベルの障害に拡大するのを防ぐことができます。 サービスは、現在のエラー、障害状況、サービスのハイ アベイラビリティ ポリシーに基づいて再起動できます。 サービスの再起動には、ステートフルな再起動とステートレスな再起動があります。 Cisco NX-OS では、サービスが実行時の状態情報とメッセージを保存することで、ステートフルな再起動を実現しています。 ステートフルな再起動では、サービスが保存されていた状態情報を取り出して、直前のチェックポイント サービス状態から動作を再開します。 ステートレスな再起動では、サービスは、初めて起動するときのように、初期化および実行されます。
すべてのサービスがステートフルな再起動が可能なように設計されているわけではありません。 たとえば、Cisco NX-OS は、3 層ルーティング プロトコル(Open Shortest Path First(OSPF)や Routing Information Protocol(RIP)など)の実行時の状態情報を保存しません。 これらのプロトコルは、再起動のあとも設定は維持されますが、動作状態については隣接するルータから情報を取得して再構築するように設計されています。 3 層プロトコルのハイ アベイラビリティ機能の詳細は、ネットワークレベル ハイ アベイラビリティを参照してください。
再起動性インフラストラクチャ
Cisco NX-OS は、ほとんどのプロセスおよびサービスでステートフル リスタートが可能です。 プラットフォーム内のプロセス、サービス、アプリケーションのバック エンド管理および調整は一連の高レベルのシステム コントロール サービスによって処理されます。
永続ストレージ サービス
Cisco NX-OS サービスは、永続ストレージ サービス(PSS)を使用して、運用の実行時情報を保存および管理します。 PSS コンポーネントは、システム サービスを使用して、サービス再起動時に状態を回復します。 PSS は状態および実行時情報のデータベースとして機能します。これにより、各サービスは、必要なときにいつでも、サービス自体の状態情報のチェックポイントを作成できます。 サービスを再起動すると、障害が発生する直前の既知の動作状態を回復できるので、ステートフルな再起動が可能になります。
PSS を使用する各サービスは、保存された情報をプライベート情報(当サービスだけ読み取り可能)または共有情報(他のサービスも読み取り可能)として定義できます。 情報を共有する場合は、ローカル(同一スーパーバイザ上のサービスだけ読み取り可能)またはグローバル(スーパーバイザまたはモジュール上のサービスが読み取り可能)のどちらかを指定できます。 たとえば、アクティブなスーパーバイザ上で実行されているサービスの PSS 情報を共有かつグローバルとして定義すると、他のモジュール上のサービスは、その PSS 情報と同期することができます。
メッセージおよびトランザクション サービス
Message and Transaction Service(MTS; メッセージおよびトランザクション サービス)は、ハイ アベイラビリティ セマンティクスに特化した高パフォーマンス Interprocess Communication(IPC; プロセス間通信)メッセージ ブローカです。 MTS は、モジュール内とモジュール間、およびスーパーバイザ間でメッセージのルーティングとキューイングを行います。 また、イベント通知や同期などのメッセージ交換を容易にし、システム サービス間およびシステム コンポーネント間のメッセージ永続性を促進します。 MTS では、永続メッセージおよびログ メッセージをキュー内に保管できるため、サービスの再起動後もそれらのメッセージにアクセスできます。
HA ポリシー
Cisco NX-OS では、各サービスに、障害の発生したサービスの再起動方法を定義する一連の内部 HA ポリシーのセットを作成できます。 サービスごとに 4 つの定義済みポリシーを用意できます。つまり、スーパーバイザが 2 つの場合のプライマリ ポリシーとセカンダリ ポリシー、スーパーバイザが 1 つだけの場合のプライマリ ポリシーとセカンダリ ポリシーです。 HA ポリシーが定義されていないサービスでは、サービスの障害発生時に実行されるデフォルトの HA ポリシーは、スーパーバイザが 2 つの場合はスイッチオーバー、スーパーバイザが 1 つの場合はスーパーバイザのリセットとなります。
プロセスの再起動性
プロセスの再起動性により、データ プレーンやその他のサービスを中断せずに、障害の発生したサービスを回復し動作を再開することができます。 システム マネージャは、サービスの HA ポリシー、前回の再起動の失敗、同じスーパーバイザ上で実行されているその他のサービスのヘルス状態に応じて、サービスの障害発生時に実行するアクションを決定します。
プロセス再起動の種類
ステートフルな再起動
再起動可能なサービスで障害が発生すると、サービスは同じスーパーバイザ上で再起動されます。 サービスの新しいインスタンスは、以前のインスタンスがオペレーティング システムによって異常終了させられたと判断した場合、永続コンテキストがあるかどうかを確認します。 新しいインスタンスは初期化時に永続コンテキストを読み込んで、実行時コンテキストを構築します。この結果、新しいインスタンスは障害発生前のインスタンスと同じ状態になります。 初期化が完了すると、サービスは、停止したときに実行していたタスクを再開します。 新しいインスタンスが再起動および初期化されている間、他のサービスは、そのような障害が発生していることを認識していません。 他のサービスから障害が発生したサービスに送信されたメッセージは、サービスが再開された時点で MTS から取得できます。
新しいインスタンスでステートフルな初期化を完了できるかどうかは、前のインスタンスの障害の原因に依存します。 サービスで再起動を数回実行できない場合、そのサービスの再起動は失敗したと見なされます。 その場合、システム マネージャは、再起動に失敗したサービスの HA ポリシーに指定されたアクション(ステートレスな再起動、再起動しない、スーパーバイザのスイッチオーバーまたはリセットのいずれか)を実行します。
ステートフルな再起動に成功した場合、システムが矛盾のない状態に到達するまでに遅延が発生することはありません。 ステートフルな再起動により、障害発生後の回復に要する時間が短縮されます。
ステートフルな再起動の前後および最中に発生するイベントは次のとおりです。
何度か再起動してもサービスの動作が安定しない場合、システム マネージャはスーパーバイザのリセットまたはスイッチオーバーを開始します。
Cisco NX-OS はプロセス スタックとコアをデバッグ用に収集します。また、オプションでコア ファイルをリモートに転送します。
ステートフルな再起動が発生すると、Cisco NX-OS がレベル LOG_ERR の Syslog メッセージを送信します。 SNMP トラップがイネーブルになっている場合は、SNMP エージェントがトラップを送信します。 Smart Call Home サービスがイネーブルになっている場合は、サービスがイベント メッセージを送信します。
ステートレスな再起動
Cisco NX-OS インフラストラクチャ コンポーネントは、ステートレスな再起動を管理します。 ステートレスな再起動中、システム マネージャは、障害の発生したプロセスを特定し、新しいプロセスに置き換えます。 障害の発生したサービスは再起動時に実行時状態を保持していません。 実行中のコンフィギュレーションから実行時状態を構築するか、必要なら、他のサービスと情報を交換して実行時状態を構築します。
ステートレスな再起動が発生すると、Cisco NX-OS がレベル LOG_ERR の Syslog メッセージを送信します。 SNMP トラップがイネーブルになっている場合は、SNMP エージェントがトラップを送信します。 Smart Call Home サービスがイネーブルになっている場合は、サービスがイベント メッセージを送信します。
スイッチオーバー
スタンバイ スーパーバイザが使用可能な場合で、複数の障害が同時に発生したときには、Cisco NX-OS は常に、スーパーバイザの再起動ではなくスーパーバイザのスイッチオーバーを実行します。こうしたケースは、同一スーパーバイザ上では回復不可能と見なされるからです。 たとえば、複数の HA アプリケーションで障害が発生すると、回復不可能と見なされます。 スーパーバイザのスイッチオーバーおよび再起動の詳細については、システムレベルのハイ アベイラビリティを参照してください。
スタンバイ スーパーバイザ サービスの再起動
スタンバイ状態のスーパーバイザ上のサービスで障害が発生した場合、システム マネージャは HA ポリシーを適用せず、30 秒待ってからサービスを再起動します。 30 秒待つことで、スタンバイ サービスの障害と同期化が繰り返されたとき、アクティブなスーパーバイザが対応しきれなくなるのを避けることができます。 再起動されるサービスをアクティブなスーパーバイザ上のサービスと同期させる必要がある場合、スタンバイ スーパーバイザは、当該サービスの再起動と同期化が完了するまでホット スタンバイ モードではなくなります。 サービスが再起動不可能な場合は、スタンバイ スーパーバイザがリセットされます。
スタンバイ サービスの再起動が発生すると、Cisco NX-OS はレベル LOG_ERR の Syslog メッセージを送信します。 SNMP トラップがイネーブルになっている場合は、SNMP エージェントがトラップを送信します。 Smart Call Home サービスがイネーブルになっている場合は、サービスがイベント メッセージを送信します。
スイッチング モジュール サービスの再起動
スイッチング モジュールまたは別の非スーパーバイザ モジュール上でサービスの障害が発生した場合は、それらのサービスの HA ポリシーによって回復アクションが決まります。 非スーパーバイザ モジュール上でサービスの障害が発生した場合は、スーパーバイザのスイッチオーバーは必要ないため、回復方法は、ステートフルな再起動、ステートレスな再起動、モジュールのリセットのいずれかになります。 中断なしにアップグレード可能なモジュールは、中断なしに再起動も可能です。
モジュール サービスの中断なしの再起動が発生すると、Cisco NX-OS はレベル LOG_ERR の Syslog メッセージを送信します。 SNMP トラップがイネーブルになっている場合は、SNMP エージェントがトラップを送信します。 Smart Call Home サービスがイネーブルになっている場合は、サービスがイベント メッセージを送信します。
再起動のトラブルシューティング
サービスで障害が発生すると、システムは障害の原因を判定するために使用できる情報を生成します。 次の情報ソースが使用可能です。
Smart Call Home サービスがイネーブルになっている場合は、サービスの再起動によって Smart Call Home イベントが生成されます。
SNMP トラップがイネーブルになっている場合は、サービスが再起動されると、SNMP エージェントがトラップを送信します。
サービスの障害がローカル モジュール上で発生した場合は、そのモジュール内で show processes log コマンドを入力することで、イベントのログを表示できます。 プロセスのログは、スーパーバイザのスイッチオーバーまたはリセット後も保持されます。
サービスの障害が発生すると、システムのコア イメージ ファイルが生成されます。 最新のコア イメージを表示するには、アクティブなスーパーバイザ上で show cores コマンドを使用します。 コア ファイルはスーパーバイザのスイッチオーバーまたはリセット後は削除されますが、Trivial File Transfer Protocol(TFTP; 簡易ファイル転送プロトコル)などのファイル転送ユーティリティを使用してコア ファイルを外部サーバにエクスポートするようにシステムを設定することもできます。
サービスの障害に関する情報を収集および使用する方法については、『Cisco Nexus 7000 Series NX-OS Troubleshooting Guide』を参照してください。
関連資料
『Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide』 システムレベルのハイ アベイラビリティ 『Cisco Nexus 7000 Series NX-OS Troubleshooting Guide』 『Cisco Nexus 7000 Series NX-OS Fundamentals Configuration Guide』 『Cisco Nexus 7000 Series NX-OS Licensing Guide』 MIB
MIB を検索およびダウンロードするには、次の URL にアクセスしてください。
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml