この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章では、サービス レベル ハイ アベイラビリティ(HA)の Cisco NX-OS サービスの再起動性について説明します。次の項で構成されています。
Cisco NX-OS のサービス再起動機能では、スーパーバイザを再起動せずに障害の発生したサービスを再起動することによって、プロセスレベルの障害がシステムレベルの障害に拡大するのを防ぐことができます。 サービスは、現在のエラー、障害状況、サービスのハイ アベイラビリティ ポリシーに基づいて再起動できます。 サービスの再起動には、ステートフルな再起動とステートレスな再起動があります。 Cisco NX-OS では、サービスが実行時の状態情報とメッセージを保存することで、ステートフルな再起動を実現しています。 ステートフルな再起動では、サービスが保存されていた状態情報を取り出して、直前のチェックポイント サービス状態から動作を再開します。 ステートレスな再起動では、サービスは、初めて起動するときのように、初期化および実行されます。
すべてのサービスがステートフルな再起動が可能なように設計されているわけではありません。 たとえば、Cisco NX-OS は、3 層ルーティング プロトコル(Open Shortest Path First(OSPF)や Routing Information Protocol(RIP)など)の実行時の状態情報を保存しません。 これらのプロトコルは、再起動のあとも設定は維持されますが、動作状態については隣接するルータから情報を取得して再構築するように設計されています。
(注) |
この章では、プロセスとサービスは同じ意味で使用されています。 プロセスは、サービスの実行中のインスタンスと見なされます。 |
サービス レベル HA 機能にライセンスは必要ありません。 ライセンス パッケージに含まれていない機能はすべて nx-os イメージにバンドルされており、追加費用は一切発生しません。 |
Cisco NX-OS ライセンス方式の詳細については、『Cisco NX-OS Licensing Guide』を参照してください。
Cisco NX-OS では、大部分のプロセスおよびサービスのステートフルな再起動が可能です。 プラットフォーム内のプロセス、サービス、アプリケーションのバック エンド管理および調整は一連の高レベルのシステム コントロール サービスによって処理されます。
システム マネージャは、あらゆるシステム機能、サービス管理、システム ヘルス モニタリングの実行を制御し、ハイ アベイラビリティ ポリシーを実施します。 システム マネージャは、サービスの起動、停止、モニタリング、再起動を担当し、サービス状態とスーパーバイザ状態の同期を開始および管理してステートフル スイッチオーバーを実現します。
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 がレベル 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 サービスがイネーブルになっている場合は、サービスがイベント メッセージを送信します。
サービスで障害が発生すると、システムは障害の原因を判定するために使用できる情報を生成します。 次の情報ソースが使用可能です。
サービスの障害に関する生成情報を収集および使用する方法については、『Cisco Nexus 9000 Series NX-OS Troubleshooting Guide』を参照してください。
ここでは、サービスレベル ハイ アベイラビリティに関連する追加情報について説明します。
『Cisco Nexus 9000 Series NX-OS Troubleshooting Guide』 | |
『Cisco Nexus 9000 Series NX-OS Fundamentals Configuration Guide』 | |
『Cisco NX-OS Licensing Guide』 |
サポートされている MIB を検索およびダウンロードするには、次の URL にアクセスしてください。 ftp://ftp.cisco.com/pub/mibs/supportlists/nexus9000/Nexus9000MIBSupportList.html |