ハイ アベイラビリティについて
High Availability（HA; ハイ アベイラビリティ）の目的は、システム内で発生したハードウェアの障害およびソフトウェアのエラーの両方による影響を一定範囲内に抑えることです。Cisco NX-OS オペレーティング システムは、ネットワーク レベル、システム レベル、およびサービス レベルでのハイ アベイラビリティに向けて設計されています。
ハイ アベイラビリティの詳細については、『 Cisco Nexus 1000V High Availability and Redundancy Configuration Guide, Release 4.0(4)SV1(3) 』を参照してください。
次の HA 機能が、障害発生時のトラフィックの中断を防止または最小限に留めます。
•
冗長性：ソフトウェア アーキテクチャのあらゆる面での冗長性。
• プロセスの分離：1 つのプロセス内で発生したエラーで他のプロセスが中断されるのを防ぐためのソフトウェア コンポーネント間の分離。
• 再起動性：ほとんどのシステム機能およびサービスが分離されているため、エラーが発生しても、他のサービスは実行され続けている中で独立して再起動が可能。さらに、ほとんどのシステム サービスはステートフルな再起動を実行するため、その他のサービスに対して透過的に稼動を再開できます。
• スーパーバイザ ステートフルスイッチオーバー：アクティブ/スタンバイ デュアル サーパーバイザ設定。状態と設定が 2 つの仮想スーパーバイザ モジュール（VSM）の間で一貫して同期された状態が保たれ、VSM に障害が発生してもシームレスでステートフルなスイッチオーバーが実現されます。
Cisco Nexus 1000V システムは、次のコンポーネントで構成されます。
• 仮想サーバ内で実行される仮想イーサネットモジュール（VEM）。これらは、VSM 内でモジュールとして表されます。
• リモート管理コンポーネント。たとえば、VMware vCenter Server。
• 仮想マシン（VM）内で実行される 1 つまたは 2 つの VSM。
システムレベルのハイ アベイラビリティ
Cisco Nexus 1000V では、HA ペアとして実行される冗長 VSM 仮想マシン（プライマリとセカンダリ）がサポートされています。デュアル VSM は、同時にはどちらか片方の VSM しかアクティブになれず、他方はスタンバイ バックアップとして機能する、アクティブ/スタンバイ キャパシティで稼動します。状態と設定が、2 つの VSM 間で一貫して同期された状態が保たれ、アクティブな VSM に障害が発生したときにはステートフルなスイッチオーバーが実現されます。
シングルまたはデュアル スーパーバイザ
Cisco Nexus 1000V システムは、次のコンポーネントで構成されます。
• 仮想サーバ内で実行される仮想イーサネット モジュール（VEM）。これらは、VSM 内でモジュールとして表されます。
• リモート管理コンポーネント。たとえば、VMware vCenter Server。
• 仮想マシン（VM）内で実行される 1 つまたは 2 つの仮想スーパーバイザ モジュール（VSM）。
|
|
|
• ステートレス：サービスはスタートアップ コンフィギュレーションから起動されます。 • ステートフル：サービスは以前の状態で再開されます。 |
• 1 つのアクティブな VSM と 1 つのスタンバイ VSM。 • アクティブな VSM は、すべてのシステム アプリケーションを実行し、システムを制御します。 • スタンバイ VSM では、アプリケーションはスタンバイ モードで開始され、初期化されます。また、「実行準備完了」のランタイム コンテキストを維持するために、アクティブな VSM と同期化され、最新の状態に保たれます。 • スイッチオーバーでは、スタンバイ VSM がアクティブ VSM の役目を引き継ぎます。 |
ネットワーク レベルのハイ アベイラビリティ
ネットワーク レベルでの Cisco Nexus 1000V HA には、ポート チャネルと Link Aggregation Control Protocol（LACP）が含まれます。ポート チャネルは、物理リンクをまとめて 1 つのチャネル グループに入れ、最大 8 つの物理リンクの帯域幅を集約した単一の論理リンクを作ります。ポート チャネル内のメンバー ポートに障害が発生すると、障害が発生したリンクで伝送されていたトラフィックはポート チャネル内のその他のメンバー ポートに切り替わります。
さらに、LACP では最大 16 個のインターフェイスが 1 つのポート チャネルに入るように設定できます。最大 8 つのインターフェイスをアクティブにすることができ、最大 8 つのインターフェイスをスタンバイ状態に入れることができます。
ポート チャネルと LACP のその他の情報については、『 Cisco Nexus 1000V Layer 2 Switching Configuration Guide, Release 4.0 』を参照してください。
ハイ アベイラビリティでの問題
表 17-1 は、ハイ アベイラビリティに関する症状、考えられる原因、および推奨される解決方法を示しています。
表 17-1 ハイ アベイラビリティでの問題
|
|
|
|
| アクティブな VSM からスタンバイ VSM が見えない。 |
ロールが正しく設定されていない。 • primary • secondary |
ロールを確認し、間違ったロールを更新し、設定を保存します。 1. 各 VSM のロールを確認します。 show system redundancy status 2. 間違ったロールを更新します。 system redundancy role 3. 設定を保存します。 copy run start |
VSM とアップストリームおよび仮想スイッチ間でのネットワーク接続の問題。問題はコントロール VLAN または管理 VLAN で発生している可能性があります。 |
接続を復元します。 1. vSphere Client から、VSM（スタンバイ モードになっているはず）をシャットダウンします。 2. vSphere Client から、ネットワーク接続を復元させたあとに、スタンバイ VSM を UP にします。 |
| アクティブ VSM がスタンバイ VSM と完全に同期化されていない。 |
VSM 間のバージョンの不一致。 |
VSM が使用しているソフトウェア バージョンが同じであることを確認します。同じでない場合、イメージを再インストールします。 1. 両方の VSM でソフトウェア バージョンを確認します。 show version 2. プライマリで使用されているのと同じバージョンで、セカンダリ VSM を再インストールします。 |
gsync プロセス中に致命的なエラーが発生した。 • show system internal log sysmgr gsyncctrl コマンドを使用して gsyncctrl ログをチェックし、致命的なエラーを探します。 |
スタンバイ VSM を再ロードします。 reload module standby_module_number 「モジュールの再ロード」を参照してください。 |
| スタンバイ VSM が周期的に再起動される。 |
VSM が管理インターフェイスを通じてしか接続を持っていない。 VSM が管理インターフェイスを通じては通信できるけれでも、制御インターフェイスを通じては通信できない場合、2 つの VSM が HA モードになって同期が取れなくなるのを防ぐために、アクティブ VSM がスタンバイをリセットします。 |
プライマリ VSM とセカンダリ VSM の間の制御 VLAN 接続をチェックします。 show system internal redundancy info 出力では degraded_mode flag = true。 接続がない場合は、制御インターフェイスを通じて接続を復元します。 |
VSM のバージョンが異なる。 debug system internal sysmgr all コマンドを入力して、バージョンの不一致を示す active_verctrl エントリを探します。次のような出力が表示されます。 2009 May 5 08:34:15.721920 sysmgr: active_verctrl: Stdby running diff version- force download the standby sup . |
スタンバイ VSM を分離してから、起動します。 show version コマンドを使用して、両方の VSM のソフトウェア バージョンをチェックします。 アクティブ VSM と同じバージョンのイメージをスタンバイ VSM にインストールします。詳細については、『 Cisco Nexus 1000V High Availability and Redundancy Configuration Guide, Release 4.0(4)SV1(3) 』を参照してください。 |
| 両方の VSM がアクティブ モードになる。 |
ネットワーク接続の問題。 • アップストリームと仮想スイッチで、VSM 間の制御 VLAN 接続と管理 VLAN 接続を調べます。 • VSM がこの 2 つのインターフェイスのどちらを介しても通信できない場合、その両方がアクティブ VSM になろうとします。 |
ネットワークの問題が存在する場合は、次の手順を実行します。 1. vSphere Client から、VSM（スタンバイ モードになっているはず）をシャットダウンします。 2. vSphere Client から、ネットワーク接続を復元させたあとに、スタンバイ VSM を UP にします。 |
VSM のドメイン ID が異なる |
各 VSM のドメイン ID を確認し、必要に応じて間違ったドメイン ID を変更します。 1. 各 VSM のドメイン ID を確認します。 show system internal redundancy info 2. 正しいドメイン ID を持つ VSM を分離して、他方の VSM と通信できないようにします。 3. 分離した VSM でドメイン ID を変更し、設定を保存し、VSM の電源を切ります。 4. 分離した VSM を再接続して電源を入れます。 |
| アクティブ VSM とスタンバイ VSM が同期していない |
バージョンに互換性がない アクティブ VSM とスタンバイ VMS のブート変数が異なるイメージ名に設定されているか、イメージ名が同じ場合は、ファイルが間違ったファイルになっています。 アクティブ VSM とスタンバイ VSM が HA と互換性のない異なるバージョンを実行している場合、これらは同期できません。 |
ソフトウェア バージョンまたはブート変数を更新します。 1. 各 VSM（アクティブおよびスタンバイ）から、ソフトウェア バージョンを確認します。 show version 2. 次のいずれかを行って、アクティブで動作しているバージョンでスタンバイ VSM を再ロードします。 – ブート変数名の修正 – 間違ったソフトウェア ファイルの置き換え 「モジュールの再ロード」を参照してください。 |
ブロードキャスト トラフィックの問題： スタンバイ VSM からアクティブ VSM へのブロードキャスト トラフィックが、VSM の同期を妨げています。スタンバイ VSM が周期的にアクティブ VSM に接続しようとしますが、スタンバイがブートアップしているときにブロードキャスト トラフィックの問題が 1 分以上続くと、システムは同期できません。 |
トラフィックの問題を解決して、スタンバイ VSM を再ロードします。 1. スタンバイ VSM から、ブロードキャスト トラフィックの問題を確認します。 show system internal log sysmgr verctrl 問題がある場合、出力に次のメッセージが表示されます。 standby_verctrl: no response from the active System Manager 2. ネットワーク接続を修正します。 3. スタンバイ VSM を再ロードします。 reload module standby_module_number 「モジュールの再ロード」を参照してください。 |
スタンバイの不正な削除 アクティブ VSM が誤ってスタンバイとの切断を検出しています。スタンバイは削除され、再挿入されますが、同期は行われません。 |
冗長ステータスを確認し、スタンバイ VSM を再ロードします。 1. アクティブ VSM の冗長性を確認します。 show system internal redundancy status 出力 = RDN_DRV_ST_AC_NP 2. スタンバイ VSM の冗長性を確認します。 show system internal redundancy status 出力 = RDN_DRV_ST_SB_AC 3. スタンバイ VSM を再ロードします。 reload module standby_module_number 「モジュールの再ロード」を参照してください。 |
ハイ アベイラビリティのトラブルシューティング コマンド
ここでは、ハイ アベイラビリティに関する問題のトラブルシューティングに使用できるコマンドを示し、次の内容について説明します。
• 「コアの表示」
• 「冗長性の確認」
• 「システム マネージャ ステータスの確認」
• 「モジュールの再ロード」
• 「スタンバイ VSM コンソールへの接続」
コアの表示
コアのリストを表示するには、次のコマンドを使用します。
show cores
VDC No Module-num Process-name PID Core-create-time
------ ---------- ------------ --- ----------------
1 1 private-vlan 3207 Apr 28 13:29
プロセスのログの表示
プロセスのログを表示するには、次のコマンドと、 show cores コマンドの出力から PID を使用します。
show processes log [pid pid ]
n1000V# show processes log
VDC Process PID Normal-exit Stack Core Log-create-time
--- --------------- ------ ----------- ----- ----- ---------------
1 private-vlan 3207 N Y N Tue Apr 28 13:29:48 2009
n1000V# show processes log pid 3207
======================================================
Description: Private VLAN
Started at Wed Apr 22 18:41:25 2009 (235489 us)
Stopped at Tue Apr 28 13:29:48 2009 (309243 us)
Uptime: 5 days 18 hours 48 minutes 23 seconds
Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2) <-- Reason for the process abort
Last heartbeat 46.88 secs ago
System image name: nexus-1000v-mzg.4.0.4.SV1.1.bin
System image version: 4.0(4)SV1(1) S25
Exit code: signal 6 (core dumped) <-- Indicates that a cores for the process was generated.
システムの冗長性ステータスの確認
冗長性ステータスをチェックするには、次のコマンドを使用します。
show system redundancy status
N1000V# show system redundancy status
administrative: primary <-- Configured redundancy role
operational: primary <-- Current operational redundancy role
Redundancy state: Active <-- Redundancy state of this VSM
Internal state: Active with HA standby
Redundancy state: Standby <-- Redundancy state of the other VSM
Supervisor state: HA standby
Internal state: HA standby <-- The standby VSM is in HA mode and in sync
システム内部の冗長性ステータスの確認
システム内部の冗長性ステータスをチェックするには、次のコマンドを使用します。
show system internal redundancy info
n1000V# show system internal redundancy info
domain: 184 <-- Domain id used by this VSM
role: primary <-- Redundancy role of this VSM
status: RDN_ST_AC <-- Indicates redundancy state (RDN_ST) of the this VSM is Active (AC)
status: RDN_ST_SB <-- Indicates redundancy state (RDN_ST) of the other VSM is Standby (SB)
degraded_mode: false <-- When true, it indicates that communication through the control interface is faulty
Redun Device 0: <-- This device maps to the control interface
tx_set_ver_req_pkts: 11590
tx_heartbeat_req_pkts: 442571
rx_heartbeat_rsp_pkts: 442546 <-- Counter should be increasing, as this indicates that communication between VSM is working properly.
Redun Device 1: <-- This device maps to the mgmt interface
tx_set_ver_req_pkts: 11589
tx_heartbeat_req_pkts: 12
rx_heartbeat_rsp_pkts: 0 <-- When communication between VSM through the control interface is interrupted but continues through the mgmt interface, the rx_heartbeat_rsp_pkts will increase.
システム マネージャ ステータスの確認
システム内部の sysmgr ステータスをチェックするには、次のコマンドを使用します。
show system internal sysmgr state
N1000V# show system internal sysmgr state
The master System Manager has PID 1988 and UUID 0x1.
Last time System Manager was gracefully shutdown.
The state is SRV_STATE_MASTER_ACTIVE_HOTSTDBY entered at time Tue Apr 28 13:09:13 2009.
The '-b' option (disable heartbeat) is currently disabled.
The '-n' (don't use rlimit) option is currently disabled.
Hap-reset is currently enabled.
Watchdog checking is currently disabled.
Watchdog kgdb setting is currently enabled.
The trace mask is 0x00000000, the syslog priority enabled is 3.
The '-d' option is currently disabled.
The statistics generation is currently enabled.
cardstate = SYSMGR_CARDSTATE_ACTIVE .
cardstate = SYSMGR_CARDSTATE_ACTIVE (hot switchover is configured enabled).
Configured to use the real platform manager.
Configured to use the real redundancy driver.
Redundancy register: this_sup = RDN_ST_AC, other_sup = RDN_ST_SB.
Remote addresses: MTS - 0x00000201/3 IP - 127.1.1.2
Module online notification received.
Local super-state is: SYSMGR_SUPERSTATE_STABLE
Standby super-state is: SYSMGR_SUPERSTATE_STABLE
Swover Reason : SYSMGR_SUP_REMOVED_SWOVER <-- Reason for the last switchover
Total number of Switchovers: 0 <-- Number of switchovers
>> Duration of the switchover would be listed, if any.
Total latency: 0 Max latency: 0
Total exec: 0 Max exec: 0
モジュールの再ロード
モジュールを再ロードするには、次のコマンドを使用します。
reload module
（注） モジュールを指定せずに reload コマンドを使用すると、システム全体が再ロードされます。
In this Example, the secondary VSM is reloaded.
スタンバイ VSM コンソールへの接続
スタンバイ VSM コンソールには、外部からはアクセスできません。アクセスするには、アクティブ VSM から attach module module-number コマンドを使用します。
スタンバイ VSM コンソールに接続するには、次のコマンドを使用します。
attach module
次に、セカンダリ VSM のコンソールに接続する例を示します。
フィードバック