サービスレベル高可用性

この章では、サービスレベル高可用性（HA）のための Cisco NX-OS サービスの再起動について説明します。この章の内容は次のとおりです：

Cisco NX-OS サービスの再起動について

Cisco NX-OS サービス再起動機能を使用すると、スーパーバイザを再起動せずに障害が発生したサービスを再起動して、プロセスレベルの障害がシステムレベルの障害を引き起こすのを防ぐことができます。現在のエラー、障害状況、およびサービスの高可用性ポリシーに応じて、サービスを再起動できます。サービスは、ステートフルまたはステートレスのいずれかの再起動を実行できます。Cisco NX-OS サービスは、ステートフル リスタートの実行時の状態情報とメッセージを保存できます。ステートフル リスタートでは、サービスはこの保存された状態情報を取得し、最後のチェックポイント サービス状態から動作を再開できます。ステートレス再起動では、サービスは、以前の状態なしで開始されたかのように初期化および実行できます。

すべてのサービスがステートフル リスタート用に設計されているわけではありません。たとえば、 Cisco NX-OS には、レイヤ 3 ルーティングプロトコル（Open Shortest Path First（OSPF）や Routing Information Protocol（RIP）など）の実行時の状態情報は保存されません。設定は再起動後も保持されますが、これらのプロトコルは、ネイバー ルータから取得した情報を使用して動作状態を再構築するように構成されています。


（注）  

この章では、プロセスとサービスを同じ意味で参照しています。プロセスは、サービスの実行インスタンスと見なされます。

再始動性インフラストラクチャ

Cisco NX-OS ほとんどのプロセスとサービスのステートフル リスタートを許可します。プラットフォーム内のプロセス、サービス、およびアプリケーションのバックエンド管理とオーケストレーションは、一連の高レベルのシステム制御サービスによって処理されます。

システムマネージャ

システム マネージャは、システム全体の機能、サービス管理、およびシステム ヘルス モニタリングを指示し、高可用性ポリシーを適用します。システム マネージャは、サービスの起動、停止、モニタリング、および再起動を行い、ステートフル スイッチオーバーのサービス状態とスーパーバイザ状態の同期を開始および管理します。

永続ストレージ サービス

Cisco NX-OS サービスは、永続ストレージ サービス（PSS）を使用して、運用ランタイム情報を保存および管理します。PSS コンポーネントは、システム サービスと連携して、サービスの再起動時に状態を回復します。PSS は、状態およびランタイム情報のデータベースとして機能します。これにより、サービスは必要に応じて状態情報のチェックポイントを作成できます。サービスを再起動すると、障害発生前の最後の既知の動作状態を回復できます。これにより、ステートフルな再起動が可能になります。

PSS を使用する各サービスは、保存されている情報をプライベート（そのサービスのみが読み取ることができる）または共有（他のサービスが情報を読み取ることができる）として定義できます。情報が共有されている場合、サービスはローカル（情報は同じスーパーバイザ上のサービスのみが読み取ることができる）またはグローバル（スーパーバイザまたはモジュール上のサービスが読み取ることができる）を指定できます。たとえば、サービスの PSS 情報が共有およびグローバルとして定義されている場合、他のモジュール上のサービスは、現用系スーパーバイザで実行されているサービスの PSS 情報と同期できます。

メッセージとトランザクション サービス

Message and Transaction Service（MTS）は、高可用性セマンティクスに特化した高性能なプロセス間通信（IPC）メッセージ ブローカです。MTS は、モジュール上のサービス間、およびスーパーバイザ間のメッセージ ルーティングとキューイングを処理します。MTS は、システム サービスとシステム コンポーネント間のイベント通知、同期、メッセージの永続化などのメッセージの交換を容易にします。MTS は、サービスの再起動後でもアクセスできるように、永続的なメッセージとログに記録されたメッセージをキューに保持できます。

MTS しきい値構成の構成

Cisco NX-OS リリース 10.5（2）F 以降では、サービス アクセス ポイント（SAP）または SAP の範囲に対して MTS 遅延しきい値を構成できます。NX-OS は SAP を使用してメッセージを送受信します。この機能は、ユーザがメッセージ処理の遅延を特定するのに役立ちます。この機能を使用すると、しきい値をミリ秒単位で構成できます。NX-OS は、遅延がしきい値を超えると、インスタンスをログに記録します。この機能は、すべての N9K プラットフォームでサポートされています。

手順の概要

  1. configure terminal
  2. [no] mts latency threshold {{sup | lc} [sap <range-of-sap> ] <threshold-value-in-msecs>}
  3. [no] mts latency threshold <log syslog>

手順の詳細

  コマンドまたはアクション 目的

ステップ 1

configure terminal

例:

switch# configure terminal
switch(config)#

グローバル コンフィギュレーション モードを開始します。

ステップ 2

[no] mts latency threshold {{sup | lc} [sap <range-of-sap> ] <threshold-value-in-msecs>}

例:

switch(config)# configure terminal

サービス アクセス ポイント（SAP）または SAP の範囲の MTS 遅延しきい値を構成します。範囲は 2 ～ 2047 で、SAP ごとのデフォルト値はありません。

このコマンドの no 形式を使用すると、値がグローバルなデフォルトに復元されるか、SAP 固有のしきい値が削除されます。デフォルト復元値は、300000 ミリ秒（5 分）です。

  • sup：SUP 論理ノードにしきい値を適用します。

  • lc：すべての物理スロットのラインカード論理ノードにしきい値を適用します。

ステップ 3

[no] mts latency threshold <log syslog>

例:

switch(config)# mts latency threshold log syslog

syslog への遅延のロギングを有効にします。この設定はグローバル構成であり、構成されたしきい値を超えるすべての SAP および loges 遅延に適用されます。

このコマンドの no 形式は、構成を削除します。

HA ポリシー

Cisco NX-OS 各サービスに、障害が発生したサービスの再起動方法を定義する一連の内部 HA ポリシーを関連付けることができます。各サービスには、2 つのスーパーバイザが存在する場合のプライマリ ポリシーとセカンダリ ポリシーと、スーパーバイザが 1 つだけ存在する場合のプライマリ ポリシーとセカンダリ ポリシーの 4 つの定義済みポリシーを含めることができます。サービスに対して HA ポリシーが定義されていない場合、サービス障害時に実行されるデフォルトの HA ポリシーは、2 つのスーパーバイザが存在する場合はスイッチオーバー、1 つのスーパーバイザが存在する場合はスーパーバイザのリセットです。

各 HA ポリシーは、次の 3 つのパラメータを指定します：

  • システムマネージャによって実行されるアクション：

    • ステートフル リスタート

    • ステートレス リスタート

    • スーパーバイザのスイッチオーバー（または再起動）

  • [最大再試行回数（Maximum retries）]：システム マネージャが実行する再起動の試行回数を指定します。この回数の試行後にサービスが正常に再起動しなかった場合、HA ポリシーは失敗したと見なされ、次の HA ポリシーが使用されます。他の HA ポリシーが存在しない場合は、デフォルト ポリシーが適用され、スーパーバイザのスイッチオーバーまたは再起動が行われます。

  • 最小ライフタイム：再起動の試行が成功したと見なすために、再起動の試行後にサービスを実行する必要がある時間を指定します。最小ライフタイムは 4 分以上です。

プロセス再起動可能性

プロセスの再起動性により、データプレーンやその他のサービスを中断することなく、障害が発生したサービスが回復して動作を再開できます。サービス HA ポリシー、以前の再起動の失敗、および同じスーパーバイザで実行されている他のサービスの正常性に応じて、システム マネージャは、サービスが失敗したときに実行するアクションを決定します。

次の表に、さまざまな障害状態に対して System Manager が実行するアクションを示します。

表 1. さまざまな障害ケースに対するシステム マネージャのアクション

エラー

サービス/プロセスの例外

サービスの再起動

サービス/プロセスのクラッシュ

サービスの再起動

応答しないサービス/プロセス

サービスの再起動

繰り返されるサービス障害

スーパーバイザのリセット（シングル）またはスイッチオーバー（デュアル）

応答しないシステムマネージャ

スーパーバイザのリセット（シングル）またはスイッチオーバー（デュアル）

スーパーバイザ ハードウェア障害

スーパーバイザのリセット（シングル）またはスイッチオーバー（デュアル）

カーネル障害

スーパーバイザのリセット（シングル）またはスイッチオーバー（デュアル）

ウォッチドッグタイムアウト

スーパーバイザのリセット（シングル）またはスイッチオーバー（デュアル）

プロセス リスタート

障害が発生したサービスは、サービスの HA 実装と HA ポリシーに応じて、このセクションで説明されているいずれかの方法で再起動されます。

ステートフル リスタート

再起動可能なサービスに障害が発生すると、同じスーパーバイザで再起動されます。サービスの新しいインスタンスが、前のインスタンスがオペレーティングシステムによって異常終了したと判断した場合、サービスは永続的なコンテキストが存在するかどうかを判断します。新しいインスタンスの初期化では、永続コンテキストを読み取って、新しいインスタンスを以前のインスタンスのように表示するランタイムコンテキストを構築しようとします。初期化が完了すると、サービスは停止時に実行していたタスクを再開します。新しいインスタンスの再起動および初期化中、他のサービスはサービスの障害を認識しません。他のサービスから障害が発生したサービスに送信されたメッセージは、サービスの再開時に MTS から利用できます。

新しいインスタンスがステートフル初期化後も存続するかどうかは、前のインスタンスの障害の原因によって異なります。サービスがその後数回の再起動試行に耐えられない場合、再起動は失敗したと見なされます。この場合、System Manager はサービスの HA ポリシーで指定されたアクションを実行し、ステートレス再起動、再起動なし、またはスーパーバイザのスイッチオーバーまたはリセットを強制します。

正常なステートフル リスタートでは、システムが一貫した状態に到達するまでの遅延はありません。ステートフル リスタートにより、障害発生後のシステム回復時間が短縮されます。

ステートフル リスタートの前、最中、および後のイベントは次のとおりです。

  1. 実行中のサービスは、PSS に対する実行時の状態情報のチェックポイントを作成します。

  2. システム マネージャは、ハートビートを使用する実行中のサービスの正常性をモニタします。

  3. システムマネージャは、サービスがクラッシュまたはハングするとすぐに再起動します。

  4. 再起動後、サービスは PSS から状態情報を回復し、保留中のすべてのトランザクションを再開します。

  5. 複数回の再起動後にサービスが安定した動作を再開しない場合、System Manager はスーパーバイザのリセットまたはスイッチオーバーを開始します。

  6. Cisco NX-OS は、デバッグ目的でプロセススタックとコアを収集し、コアファイルをリモートロケーションに転送するオプションを使用します。

ステートフル リスタートが発生すると、 Cisco NX-OS はレベル LOG_ERR の syslog メッセージを送信します。SNMP トラップがイネーブルになっている場合、SNMP エージェントはトラップを送信します。Smart Call Home サービスが有効になっている場合、サービスはイベント メッセージを送信します。

ステートレス リスタート

Cisco NX-OS インフラストラクチャ コンポーネントは、ステートレス再起動を管理します。ステートレス再起動中に、System Manager は失敗したプロセスを特定し、新しいプロセスに置き換えます。失敗したサービスは、再起動時に実行時の状態を維持しません。サービスは、実行構成からランタイム状態を構築するか、必要に応じて他のサービスと情報を交換してランタイム状態を構築できます。

ステートレス リスタートが発生すると、 Cisco NX-OS はレベル LOG_ERR の syslog メッセージを送信します。SNMP トラップがイネーブルになっている場合、SNMP エージェントはトラップを送信します。Smart Call Home サービスが有効になっている場合、サービスはイベント メッセージを送信します。

スイッチオーバー

スタンバイ スーパーバイザが使用可能な場合、 Cisco NX-OS は、複数の障害が同時に発生するたびに、スーパーバイザの再起動ではなくスーパーバイザのスイッチオーバーを実行します。これらのケースは同じスーパーバイザでは回復不能と見なされるためです。たとえば、複数の HA アプリケーションに障害が発生した場合、それは回復不能な障害と見なされます。

スタンバイ スーパーバイザ サービスでの再起動

スタンバイ状態のスーパーバイザでサービスに障害が発生した場合、System Manager は HA ポリシーを適用せず、30 秒の遅延の後にサービスを再起動します。この遅延により、スタンバイ サービスの障害と同期の繰り返しによってアクティブ スーパーバイザが過負荷になることがなくなります。再起動するサービスがアクティブ スーパーバイザ上のサービスと同期する必要がある場合、スタンバイ スーパーバイザは、サービスが再起動されて同期されるまで、ホット スタンバイ モードを終了します。再起動できないサービスにより、スタンバイ スーパーバイザがリセットされます。

スタンバイサービスの再起動が発生すると、 Cisco NX-OS はレベル LOG_ERR の syslog メッセージを送信します。SNMP トラップがイネーブルになっている場合、SNMP エージェントはトラップを送信します。Smart Call Home サービスが有効になっている場合、サービスはイベント メッセージを送信します。

スイッチング モジュール サービスでの再起動

スイッチング モジュールまたは別の非スーパーバイザ モジュールでサービスに障害が発生した場合、リカバリ アクションはそれらのサービスの HA ポリシーによって決定されます。非スーパーバイザ モジュール サービスでのサービス障害はスーパーバイザのスイッチオーバーを必要としないため、回復オプションはステートフル リスタート、ステートレス リスタート、またはモジュール リセットです。モジュールが中断のないアップグレードに対応している場合は、中断のない再起動も可能です。

非スーパーバイザ モジュール サービスの再起動が発生すると、 Cisco NX-OS はレベル LOG_ERR の syslog メッセージを送信します。SNMP トラップがイネーブルになっている場合、SNMP エージェントはトラップを送信します。Smart Call Home サービスが有効になっている場合、サービスはイベント メッセージを送信します。

再起動のトラブルシューティング

サービスで障害が発生すると、システムは障害の原因を判定するために使用できる情報を生成します。次の情報ソースが使用可能です。

  • サービスの再起動によって、LOG_ERR レベルの Syslog メッセージが生成されます。

  • Smart Call Home サービスがイネーブルになっている場合は、サービスの再起動によって Smart Call Home イベントが生成されます。

  • SNMP トラップがイネーブルになっている場合、サービスが再起動されると、SNMP エージェントはトラップを送信します。

  • サービスの障害がローカル モジュール上で発生した場合は、そのモジュール内で show processes log コマンドを入力することで、イベントのログを表示できます。プロセスのログは、スーパーバイザのスイッチオーバーまたはリセット後も保持されます。

  • サービスの障害が発生すると、システムのコア イメージ ファイルが生成されます。最新のコア イメージを表示するには、現用系なスーパーバイザ上でshow cores コマンドを使用します。スーパーバイザのスイッチオーバーおよびリセットが生じると、コア ファイルは保持されません。ただし、Trivial File Transfer Protocol（TFTP）のようなのファイル転送ユーティリティを使用して、コア ファイルを外部サーバへエクスポートするようシステムを構成できます。

  • CISCO-SYSTEM-EXT-MIB には、コアのテーブルが含まれています（cseSwCoresTable）。

サービス障害に関連して生成された情報の収集と使用については、『 Cisco Nexus 9000 シリーズ NX-OS トラブルシューティング ガイド』を参照してください。

サービスレベル高可用性に関する追加情報

ここでは、サービスレベルの高可用性に関連する追加情報について説明します。