Cisco Nexus 7000 シリーズ

Cisco Nexus 7000 および NX-OS のハイアベイラビリティ アーキテクチャ

ホワイトペーパー





Cisco Nexus 7000 および NX-OS のハイアベイラビリティ アーキテクチャ


概要

Cisco Nexus 7000 プラットフォームはモジュール型の設計で、すべてのサブシステムについて、重要なコンポーネントの冗長化を重視しています。システム設計に関する高度なモジュール化とコンパートメント化というアプローチが、アーキテクチャの物理的な側面から環境、電源、システム ソフトウェアの各側面に至るまで、プラットフォームのすべての面に適用されています。さらに、コントロール プレーンの計画済みまたは計画外のイベントまたは障害の発生時に、継続的なオペレーションを実現してデータ損失を防ぐために、コントロール プレーンとフォワーディング データ プレーンの明確な機能分離が強く意識された設計になっています。このドキュメントでは、Cisco Nexus 7000 プラットフォーム アーキテクチャのハードウェアおよびソフトウェアの対障害性機能を理解していただくために、前述のすべての領域のハイアベイラビリティ機能とオプションについて詳しく説明します。

物理サブシステムの冗長性オプションおよび機能

スーパーバイザ モジュールの冗長性

Cisco Nexus 7000 プラットフォームは、デュアル スーパーバイザ モジュールをサポートしており、コントロールおよびマネジメント プレーンの 1+1 冗長性を提供します。デュアル スーパーバイザ構成は、アクティブ/スタンバイ キャパシティで動作し、常に一方のスーパーバイザ モジュールのみがアクティブで、もう一方のスーパーバイザ モジュールはスタンバイ バックアップとして機能します。2 つのスーパーバイザ モジュール間では状態と構成の同期が維持され、スーパーバイザ モジュール障害が発生すると、シームレスでステートフルな1スイッチオーバーが実行されます。復旧不可能な重大障害、サービスをリスタートする必要があるエラー、カーネル エラー、またはハードウェア エラーが検知されると、NX-OS の GOLD(Generic On-Line Diagnostics)サブシステムと、スーパーバイザ上のその他の監視プロセスにより、冗長スーパーバイザへのステートフル フェイルオーバーが実行されます。

1 ステートフルスイッチオーバーは、サービス単位で処理されます。ステートフルな方法でスイッチオーバーするように設計されていないサービスもあります。詳細については、このドキュメントの後続セクションを参照してください。

図 1 DC3 10 スロット シャーシの前面図

図 1 DC3 10 スロット シャーシの前面図

スーパーバイザ レベルで復旧不可能な障害が発生すると、現在アクティブなスーパーバイザ(障害が発生したスーパーバイザ)がスイッチオーバーを開始します。スイッチオーバーが実行されると、障害が発生したスーパーバイザはリロードされ、スタンバイ スーパーバイザが同期していた状態および構成を使用して、新しいアクティブ スーパーバイザになります。障害が発生したスーパーバイザがリロードして自己診断(Self Diagnostic)でパスすることができた場合、そのスーパーバイザは初期化されて新しいスタンバイ スーパーバイザになり、動作状態を新しいアクティブ ユニットと同期します。

スーパーバイザ スイッチオーバーのその他の詳細については、このドキュメントの「スーパーバイザ スイッチオーバー」セクションで説明します。

スイッチ ファブリックの冗長性

Cisco Nexus 7000 プラットフォームは、冗長スーパーバイザ モジュールによるコントロール プレーンおよび管理のアベイラビリティに加えて、冗長スイッチ ファブリック モジュール実装によるスイッチング ファブリックのアベイラビリティも提供します(図 2)。キャパシティと冗長性を高めるために、1 つの Cisco Nexus 7000 シャーシにファブリック モジュールを最大 5 つまで構成できます。システムに設置された各 I/O モジュールは、機能しているすべての設置済みスイッチ ファブリック モジュールに自動的に接続し、接続したファブリック モジュールを使用します。スイッチ ファブリック モジュールに障害が発生すると、残りのアクティブなスイッチ ファブリック モジュール間でトラフィックの再割り当てと調整が自動的に行われます。障害が発生したファブリック モジュールを置き換えると、この逆方向のプロセスが実行されます。置き換え用のファブリック モジュールを挿入してオンラインにすると、トラフィックはすべての設置済みファブリック モジュール間で再び再分配され、冗長性レベルが復旧します。

図 2 DC3 10 スロット シャーシの背面図(ファブリック カード)

図 2 DC3 10 スロット シャーシの背面図(ファブリック カード)

冷却システム

Cisco Nexus 7000 10 スロット シャーシには、I/O モジュール冷却用の 2 つの冗長システム ファン トレイと、スイッチ ファブリック モジュール冷却用の 2 つの追加冗長ファン トレイが含まれます(図 3)。どちらのタイプのファン トレイも、ホット スワップに対応しています。

ファン速度は可変であり、システム全体のノイズと電力消費を最少化しつつ両セクションのシステム冷却を最適化するために、16 のレベル2のいずれかに動的に調整されます。

システム ファン速度およびファブリック ファン速度は、以下を含むいくつかの要素に基づいて自動的に調整されます。

  • システムまたはファブリック セクションに設置されている、電力消費が最も大きいライン カード
  • インレット、スーパーバイザ、およびファブリック モジュールの周辺温度センサーが感知した温度値
  • エア インレット フィルタの存在

さらに、特定のトレイでファンの障害が検出されると、その障害を補うために、残りのファンの速度および流量が調整(通常は増加)されます。ファン トレイ全体が置き換えなしに取り外されたことが検出されると、3 分間の警告時間の後、システムがシャットダウンします。

2 可変ファン出力の 16 というレベル数は、現在のソフトウェアによる制限です。ソフトウェアの将来のバージョンでは、出力レベルが 256 に細分化される可能性があります。

図 3 DC3 10 スロット シャーシの背面図(ファン トレイ)

図 3 DC3 10 スロット シャーシの背面図(ファン トレイ)

電力サブシステムのアベイラビリティ機能

Cisco Nexus 7000 プラットフォームは、3 つのモジュール型の内部冗長電源から電力供給を受けます(図 4)。これらのモジュール型の電源は、独立した 2 つの内部電力ユニットで構成されます。各モジュール型電源に 2 つの電力パスを備えているため、すべての電源を装備すると、シャーシ全体で合計 6 つの電力パスを備えることになります。これらの電源は、システム コンポーネントに電力を供給する際、比例的なロードシェアリング方式によって電力を分配します。これにより、同じシャーシ内の異なるキャパシティの電源を効率的に使用することができます。そのため、設置されているすべての電源がアクティブであり、全体の負荷を共有します。さらに、電力サブシステムにより、3 つの電源を4 つの冗長モードのいずれかで構成することができます。

図 4 DC3 10 スロット シャーシの背面図(電源)

図 4 DC3 10 スロット シャーシの背面図(電源)

使用可能な電源冗長モードは以下のとおりです。

  • 非冗長結合電力:このモードでは、電源の冗長性は存在しません。使用可能なすべての電力の合計を使用可能な電力バジェットとして提供するために、設置された電源のすべての電力が結合されます。この構成では、電力ソースまたは電源に障害が発生した場合、システム全体で使用できる電力に影響が及びます。現在の電力消費が障害発生後の電力バジェットを上回る場合、システムは障害状態になります。

図 5 結合電力モデル(非冗長)

図 5 結合電力モデル(非冗長)

  • N+1 電源ユニット冗長性:このモードでは、単一の電源ユニットの障害に対する保護が提供されます。単一の電源に障害が発生すると、機能している残りの電源ユニット全体のキャパシティを使用して、負荷が再分配されます。このモードを使用した場合、シャーシで使用できる総電力は、設置されているすべての電源の合計から、最大の電源(冗長性用)を差し引いたものになります。N+1 の冗長性をサポートするには、最低 3 つの電源が設置されている必要があります。

図 6 N+1 冗長性モデル

図 6 N+1 冗長性モデル

  • 入力グリッド冗長性:このモードは、入力ソースの障害に対する保護を提供します。入力グリッド冗長性を実装するには、各電源ユニットを 2 つの独立した電力ソース(グリッド)に接続する必要があります。1 つの電力グリッドに障害が発生しても、設置されているすべての電源は、残りの電力グリッドに接続されている半分の内部電力ユニットを通じて、引き続き機能します。

図 7 N+1 冗長性モデル

図 7 N+1 冗長性モデル

  • 完全冗長性(電源 + 入力グリッド)(既定モード):システムの既定である完全冗長モードは、1 つの電力ソース グリッド障害と 1 つの電源ユニット障害の両方に対する保護を提供します。このモードは、N+1 モードと入力グリッド冗長性モードを論理的に組み合わせたものです。

図 8 完全冗長性モード

図 8 完全冗長性モード

それぞれの電源冗長モードは電力バジェットと割り当てモデルが相互に異なるため、使用可能な電力とキャパシティも異なります。電力バジェット、使用可能なキャパシティ、およびプランニング要件の詳細については、Cisco Nexus 7000 の環境データ シートまたはホワイト ペーパーを参照してください。

内部イーサネット アウトオブバンド チャネル

Cisco Nexus 7000 は、スーパーバイザとラインカードの間、およびスーパーバイザとファブリック モジュールの間のトラフィックの管理および制御に、スイッチド EOBC(Ethernet Out-of-band Channel)を使用します。スーパーバイザ モジュールでは、チップ化されたオンボード 24 ポート イーサネット スイッチを使用したイーサネット接続が提供されます。各スーパーバイザから各ライン カードへ、各スーパーバイザから各スイッチ ファブリック モジュール(最大 5 つ)へ、および 2 つのスーパーバイザ間で、1 つの Gbps イーサネット リンクが使用されます(図 9)。また、スーパーバイザ内のローカル CPU に接続するために、各スーパーバイザで 2 つの追加冗長 1 Gbps イーサネット リンクが使用されます。この設計により、スーパーバイザとシステム内の他のすべてのプロセッサおよびライン カードの間のトラフィックを制御および管理するための、冗長性の高いスイッチド イーサネット ベース ファブリックが実現します。

図 9 Cisco Nexus 7000 の EOBC 接続

図 9 Cisco Nexus 7000 の EOBC 接続

ライン カードでは、チップ化された 6 ポート イーサネット スイッチを使用します。そのうち 3 つのポートのみを使用することによって 3 つの 1 Gbps 接続ラインが提供されます。1 つのラインは、ライン カードのローカル CPU への接続に使用され、2 つのラインは、各スーパーバイザへの接続に使用されます。これらのイーサネット ベース チャネルは、コントロール プレーンのシグナリングのみに使用され、データ プレーン トラフィックは伝送しません。

NX-OS システム ソフトウェアの冗長性オプションおよび機能

Cisco Nexus 7000 プラットフォームでは、NX-OS オペレーティング システムが実行されます。NX-OS は、高度にモジュール化されたアーキテクチャを使用しており、コンポーネントを分割することによって冗長性、障害分離、および高いリソース効率を実現しています。機能コンポーネントは、サービスと呼ばれる独立したプロセスとして動作します。NX-OS サービスは、必要に応じて各サービスにアベイラビリティ機能を設計段階から実装しています。ほとんどのシステム サービスには、ステートフル リスタートを実行する機能があります。そのため、障害が発生しているサービスのリスタートと復元は、プラットフォーム内の他のサービスに対しては透過的に、また、ネットワーク内の隣接するデバイスに対しては完全に透過的に行うことができます。プラットフォーム内のプロセス、サービス、およびアプリケーションのバックエンドの管理およびオーケストレーションは、一連の高レベルなシステム制御サービス、すなわちシステム マネージャ、PSS(Persistent Storage Service)、MTS(Message and Transaction Service)、およびインストーラによって処理されます。

これらのハイアベイラビリティ インフラストラクチャ コンポーネントが、プラットフォームのサービス リスタート機能とスーパーバイザ スイッチオーバー機能を実現するサービス、API、監視、および制御サポートを提供します。複数レベルのサービスおよびコンポーネント監視を、さまざまなレイヤの構造化された障害シナリオ処理と組み合わせることで、NX-OS ソフトウェア アーキテクチャは、システムのアベイラビリティを保証するためのきわめて包括的なアプローチを提供します。表 1 に、さまざまな潜在的障害シナリオと、NS-OS に組み込まれている処理機能を示します。

表 1 システム マネージャによって処理されるさまざまな障害シナリオ

障害シナリオ アクション
サービス/プロセスの例外 サービスのリスタート
サービス/プロセスのクラッシュ サービスのリスタート
サービス/プロセスが応答しない サービスのリスタート
反復的なサービス障害 スーパーバイザのリセット(シングル)/スイッチオーバー(デュアル)
システム マネージャが応答しない スーパーバイザのリセット(シングル)/スイッチオーバー(デュアル)
スーパーバイザのハードウェア障害 スーパーバイザのリセット(シングル)/スイッチオーバー(デュアル)

以下のセクションでは、これらの継続的な動作および障害復旧機能を提供するコンポーネントの詳細について説明します。

システム冗長性コンポーネント

NX-OS は、全体的なハイアベイラビリティ機能を提供するために、次の 3 つの主要なコア インフラストラクチャ サービスを使用します。

  • システム マネージャ
  • Persistent Storage Service(PSS)
  • Message and Transaction Service(MTS; メッセージおよびトランザクション サービス)

デュアル スーパーバイザ モジュールが動作している場合のような冗長構成では、ミラーリングされたサービスが各スーパーバイザ モジュールで実行され、それらの間で構成および動作状態が同期されます。スーパーバイザの一方はアクティブ スーパーバイザとして機能し、もう一方は、スイッチオーバーによってアクティブ化されるまでスタンバイ設備として動作します。

図 10 NX-OS のハイアベイラビリティ コア インフラストラクチャ コンポーネント

図 10 NX-OS のハイアベイラビリティ コア インフラストラクチャ コンポーネント

システム マネージャは、全体的なシステム機能、サービス管理、およびシステム ヘルス監視を調整します。また、全体的なハイアベイラビリティ状態を維持し、ハイアベイラビリティ ポリシーを適用し、システム構成を管理する役割も持っています。システム マネージャは、サービスの起動、停止、監視、リスタートを行います。また、システム マネージャは、ステートフル スイッチオーバーに備えてサービス状態およびスーパーバイザ間状態の同期を開始および管理するためにも使用されます。さらに、現在のスーパーバイザで復旧不可能な障害が発生していると判断した場合や、主要なコア サービスでエラーが発生し、速やかにリスタートできない場合に、スーパーバイザ スイッチオーバーを開始します。全体的な制御および監視プロセスであるシステム マネージャは、スーパーバイザ上のハードウェア ベースのウォッチドッグ タイマに対するキープアライブ インジケータをトリガする役割も持っています。この定期的なハートビートが、ウォッチドッグ タイマのキープアライブ タイムアウト期間内にシステム マネージャからトリガされないと、そのシステム マネージャは応答しないものと見なされ、ハードウェア ベースのスーパーバイザ リセット(シングル スーパーバイザの場合)またはスイッチオーバー(デュアル スーパーバイザの場合)がトリガされます。

PSS は、他のプラットフォーム サービスの運用上のランタイム情報および構成の格納と管理を担う、ベース インフラストラクチャ コンポーネントです。PSS は、サービスのリスタート時に状態を復元するために、他のシステム サービスによって使用されます。PSS は、ストレージ システムとの間でデータを読み書きする管理構造化 API を提供し、実質的に状態およびランタイム情報のデータベースとして機能します。PSS インフラストラクチャを使用するサービスは、必要に応じて、定期的にチェックポイントとして状態情報を記録することができます。これにより、サービスを障害前の最新の既知(Last Known)の動作状態に復旧することができるため、ステートフルなリスタートが可能になります。この状態復旧機能は、シングル スーパーバイザ構成とデュアル スーパーバイザ構成の NX-OS サービスで使用でき、データプレーン トラフィック、隣接するデバイスなどの他の内部サービスに影響を与えることなく、サービスを透過的に動作に戻すことができます。

たとえば、シングル スーパーバイザ構成でも、PSS を使用することにより、全体的なスパニングツリー トポロジの安定性に影響を与えることなく、スパニングツリーなどのサービスのステートフル リスタートが可能です。

NX-OS のMTS は、ハイアベイラビリティ セマンティクスに特化した高パフォーマンスな IPC(Interprocess Communication)メッセージ ブローカです。MTS は、ライン カード上またはライン カードにまたがるサービス(スーパーバイザにまたがるサービスも含む)間での、メッセージのルーティングとキューイングを処理します。MTS は、システム サービスとシステム コンポーネントの間での、イベント通知などのメッセージの交換、同期、およびメッセージ永続性を促進します。また MTS は、サービス間のメッセージ キューイングを実行および管理することにより、永続メッセージとログ メッセージをサービスのリスタート後もアクセスできるようにキューに保持します。

図 11 MTS サービス間通信

図 11 MTS サービス間通信

これらの各システム インフラストラクチャ コンポーネント サービスは、システム全体のアベイラビリティを実現するうえで重要な役割を果たします。個々の機能性システム サービス(AAA [認証、許可、アカウンティング]、スパニング ツリー プロトコル、NTP [ネットワーク タイム プロトコル]、コマンド パーサーなど)は、これらのシステム レベル冗長性インフラストラクチャ コンポーネントを使用し、PSS 機能と MTS 機能を利用して、自らの状態をチェックポイントとして保存し、リスタート時に状態を復元し、スタンバイ スーパーバイザの状態を同期させます。

サービスのモジュール性とリスタート機能

NX-OS 内のサービスは、サブシステムまたはフィーチャ セットの機能または機能セットを実行する、ノンカーネル スペース(ユーザ スペース)プロセスとして設計されています。

各サービスおよび各サービス インスタンスは、独立した個別の保護プロセスとして実行されます。このアプローチにより、高度な耐障害ソフトウェア インフラストラクチャと、サービス間での障害分離が実現します。したがって、サービス インスタンス(802.1q や MST など)内の障害は、同時に実行されている他のサービス(LACP など)に影響を与えません。さらに、サービスの各インスタンスは、独立したプロセスとして実行できます。これは、ルーティング プロトコルの 2 つのインスタンス(たとえば、OSPF の 2 つのインスタンス)が独立したプロセスとして実行され、それによって同じサービスの 2 つのインスタンス間であっても障害分離が実現することを意味します。

この弾力性のある高モジュラ アーキテクチャにより、プラットフォームで実行されているすべてのサービスに最高レベルの保護と耐障害性を提供することができます。また、このアプローチは、他の重要なサービスおよびシステム全体への影響を最少化しつつ、特定の問題に対処するための迅速な障害分離、解決、およびモジュール式ソフトウェア アップグレードを可能にします。

NX-OS のサービスは、迅速にリスタートする能力も備えています。サービスのリスタートは、重大な障害が検出されたときにシステム マネージャによって自動的に開始することも、管理者が手動で開始することもできます。リスタートが開始されると、サービス プロセスは終了信号を受信してシャットダウンし、その後迅速に(通常はミリ秒単位の時間内に)リスタートします。これにより、必要に応じてエラー状態をクリアし、サービスをリセットすることが可能になります。

サービスは、タイプの異なるリスタート(ステートフルまたはステートレス)を行うことができます。サービスは、システム マネージャが現在のエラー、障害状況のほか、サービスに対して構成されたハイアベイラビリティ ポリシーに基づいてリスタートすることができます。サービスに対してステートフル リスタートが指定された場合、新しいサービス プロセスは PSS から以前のランタイム状態データを取得し、最後にチェックポイントされたサービス状態から動作を復旧します。NX-OS のサービスのほとんどは、PSS および MTS のハイアベイラビリティ インフラストラクチャ サービスを利用することにより、ステートフル リスタートをサポートするように設計されています。サービスに対してステートレス リスタートが指定された場合、サービスは初期化され、以前の状態を使用することなく、スタートしたばかりであるかのように実行されます。

すべてのサービスがステートフル リスタートに対応するように設計されているわけではありません。具体的には、現時点で、IPv4、IPv6、および IP マルチキャスト用の一連のレイヤ 3 ルーティング プロトコル(たとえば、IS-IS [Intermediate System-to-Intermediate System]、OSPF、BGP、RIP [Routing Information Protocol] など)は、NX-OS 内の PSS の状態永続性を利用するように設計されていません。代わりに、これらのプロトコルは、現時点では隣接デバイスから取得した情報を使用して動作状態を再構築するように設計されています。レイヤ 3 プロトコルのハイアベイラビリティ機能の詳細については、このドキュメントの「レイヤ 3 プロトコルのハイアベイラビリティ機能」で説明します。

図 12 サービス リスタート プロセス

図 12 サービス リスタート プロセス

スーパーバイザ スイッチオーバー

Cisco Nexus 7000 プラットフォームは、重大な障害の際に SSO(Supervisor Switchover)を実行できる、1+1 の冗長スーパーバイザ モジュールを提供します。アクティブ スーパーバイザからスタンバイ スーパーバイザへのスイッチオーバーは、フォワーディング プレーンに影響を与えないため、スーパーバイザ スイッチオーバー中にデータのノンストップ フォワーディングを提供できます。

Cisco Nexus 7000 プラットフォームのアクティブ スーパーバイザ モジュールとスタンバイ スーパーバイザ モジュールの間では、2 段階のプロセスを使用することによって常に状態および構成が同期されます。スーパーバイザは、最初に完全な動作状態になったときに、自身がアクティブ スーパーバイザであるかスタンバイ スーパーバイザであるかを判断するテストを実行します。スタンバイ ユニットである場合は、対になるユニットとの GSYNC(Global Sync)を開始して、同期の第 1 段階を実行します。これを実行するために、スタンバイ スーパーバイザはアクティブ スーパーバイザに対して GSYNC 要求を発行します。これに対してアクティブ スーパーバイザは、スタンバイ ユニットとの間で、現在の動作構成と状態の完全な交換を開始します。この第 1 段階の完全な情報交換が実行されると、スーパーバイザは SSO 同期の第 2 段階に入ります。この段階では、定期的な同期アップデートとトリガされた同期アップデートが、MTS を通じたメッセージによって送信されます。状態を更新またはチェックポイントで保存しているサービスは、MTS にメッセージを送信すると共に、PSS への書き込みを行います。MTS は、イーサネット アウトオブバンド チャネル上の MTS メッセージを通じて、スタンバイ スーパーバイザ上の対になる MTS プロセスに対してその後の同期メッセージをルーティングします。スタンバイ スーパーバイザ上の対応するプロセスが、アクティブ スーパーバイザ上の対になるプロセスの状態と一致するように状態の更新およびチェックポイント作成を行えるように、スタンバイ スーパーバイザ上の MTS プロセスはこのプロセスに通知します。

さらに、アクティブ スーパーバイザのシステム マネージャは、スタンバイ スーパーバイザの状態と、動作の準備ができているかどうかを監視します。スタンバイ スーパーバイザが予期せぬ状態になった場合、またはスタンバイへの MTS 同期が失敗した場合、スタンバイ スーパーバイザは、アクティブ スーパーバイザとスタンバイ スーパーバイザの間の有効性と安定性を維持するためにリセットされます。

復旧不可能なエラーが検出された場合、システム マネージャは、構成されたハイアベイラビリティポリシーによっては、現在のアクティブ スーパーバイザから現在のスタンバイ ユニットへのスーパーバイザ スイッチオーバーを開始することがあります。スイッチオーバーは、復旧不可能な障害の判断を左右する、以下の 1 つ以上の条件に基づいてトリガされます。

  • 「リスタート タイマ」スタビリティ ウィンドウ内での反復的なサービス リスタート
  • ハードウェア障害
  • カーネル パニック

インサービス ソフトウェア アップグレード(ISSU)

NX-OS は、In-Service Software Update(ISSU; インサービス ソフトウェア アップグレード)を実行する機能を提供します。NX-OS のモジュール式ソフトウェア アーキテクチャは、プラグイン ベースのサービスおよび機能をサポートします。このフレームワークにより、他のモジュールにほとんど影響を与えることなく、完全なイメージ アップグレードを実行したり、必要に応じてモジュールを選択的にアップグレードすることが可能です。さらに重要なことは、このモジュール式設計により、データ フォワーディング プレーンに影響を与えることなく、NX-OS をサービスの中断なしでアップグレードできるということです。これにより、フル イメージ バージョン間のアップグレード(4.0 から 4.1 など)を含むソフトウェア アップグレード中に、フォワーディングをノンストップで実行できます。

ISSU は、管理者が CLI(Command-Line Interface)を使用するか、または Datacenter Network Manager ソフトウェア プラットフォームの管理インターフェイスを通じて、手動で開始されます。開始されたインサービス ソフトウェア アップグレードは、必要に応じて、システムの以下のコンポーネントを更新します。

  • スーパーバイザ BIOS、キックスタート イメージ、システム イメージ
  • ラインカード BIOS およびイメージ
  • CMP(Connectivity Management Processor)BIOS およびイメージ

インストールされた ISSU インストーラ サービスは、ISSU サイクルを開始します。アップグレード プロセスは、データ トラフィック フォワーディングに影響を与えることなくシステム全体への影響を最少化するように設計された、複数の段階で構成されます。図 13 に、インサービス ソフトウェア アップグレード プロセスの概要を図示します。

図 13 インサービス ソフトウェア アップグレード プロセス

図 13 インサービス ソフトウェア アップグレード プロセス

重要なことは、ISSU ベースのアップグレードはシステム全体に関わるアップグレードであり、VDC(Virtual Device Context)ベースのアップグレードではないということです。したがって、ISSU ベースのアップグレードを開始すると、システム全体のすべての構成済み VDC に同じイメージとバージョンが適用されます。VDC は、基本的にはコントロール プレーンおよびユーザ インターフェイスの仮想化であり、現時点では仮想化されたリソースごとに独立したイメージ バージョンを実行することはできません。

ネットワーク全体への影響を最少化するには、ISSU はネットワーク トポロジが安定している状態で実行する必要があります。これは、トポロジ状態の変更に含める必要があるコントロール プレーン コンポーネントが、移行中にアップグレードされることを避けるためです。

レイヤ 3 プロトコルのハイアベイラビリティ機能

IPv4、IPv6、および IP マルチキャストのレイヤ 3 プロトコルは、現時点ではステートフル リスタート機能を実装していません。この機能は、将来的にはこれらのプロトコル サービスに追加される可能性があります。現時点で、レイヤ 3 プロトコルはリスタート時の動作復元のために、以下の 2 つの主要な方法を利用します。

  • グレースフル リスタート拡張
  • プロトコル ベースの定期的な更新

OSPFv2、OSPFv3、IS-IS、EIGRP(Enhanced Interior Gateway Routing Protocol)、および BGP は、ベース プロトコルへのグレースフル リスタート拡張を利用して、それらの環境に対して、ノンストップ フォワーディングおよび最も影響の少ないルーティング リカバリを提供します。グレースフル リスタート用の NX-OS ルーティング プロトコル拡張は、OSPFv2/v3、BGPv4、および IS-IS をそれぞれ規定する RFC 3623、4724、および 3847 で示されている標準に従っています。ここで注意することは、グレースフル リスタート拡張とノンストップ フォワーディングの NX-OS 標準ベースの実装は、同じ IETF 標準を利用する Cisco IOS バージョンと互換性がありますが、Cisco NSF(Non-Stop Forwarding)の先行標準実装を使用する古い IOS バージョンとは互換性がないということです。

前記のプロトコル用の標準ベースの実装に加えて、EIGRP で使用できるグレースフル リスタート拡張も開発されています。NX-OS で使用される EIGRP への拡張は、他のシスコ プラットフォームで EIGRP ノンストップ フォワーディング用に使用される拡張と互換性があります。

グレースフル リスタートにより、Cisco Nexus 7000 プラットフォームは、コントロール プレーンとデータ フォワーディング プレーンを明確に分離しているアーキテクチャの利点を最大限に活かすことができます。グレースフル動作に対応しているプロトコルをリスタートする必要がある場合、そのルーティング プロトコルは、関連するメカニズムを使用することにより、計画されたリスタートが実行中であることを隣接デバイスに通知します。この通知により、隣接デバイスは動作が通常どおり行われているかのようにリスタート エンティティへのトラフィックのフォワーディングを継続しつつ、リスタート サービスはネットワーク コントロール プレーンから自らを速やかに削除できます。ルーティング プロトコルをリスタートしているユニットは、コントロール プレーンの動作とは無関係に、最後に確立された RIB(Routing Information Base)/FIB(Forwarding Information Base)に基づいてトラフィックのフォワーディングを継続し、それによってリスタート中の継続的なデータ配信を可能にします。リスタートしたルーティング サービスが安定状態を確立すると、そのサービスは隣接デバイスに通知して隣接関係を再構築し、それによってコントロール プレーンの観点から自らをネットワークに速やかに再挿入できます。

RIPv2、PIM(Protocol Independent Multicast)、PIM6、IGMP(Internet Group Management Protocol)、MSDP、および MLD プロトコルは、グレースフル リスタート拡張を実装していません。代わりに、更新ベースのプロトコルであるこれらのプロトコルは、プロトコルに固有の隣接デバイスからの定期的な更新を利用して、状態を再確立します。

これらのルーティング プロトコル自体がリスタートからの復旧中はステートフルではないため、これらのプロトコルの RIB もステートフルではありません。ユニキャスト RIB とマルチキャスト RIB は、関連するレイヤ 3 プロトコルのリスタート後に復元された状態に基づいて再確立および再構築する必要があります。RIB と FIB は、リスタート中はフォワーディング動作を継続するために維持されますが、プロトコルが安定し、復旧状態を再確立すると、更新されます。これにより、リスタート後のネットワーク変更を含めるために、RIB および FIB に必要な更新を加えることができます。

仮想デバイス コンテキスト(VDC)

NX-OS は、デバイス レベルで論理仮想化を実装しており、デバイスの複数のインスタンスを同じ物理スイッチ上で同時に動作させることができます。これらの論理動作環境を VDC と呼びます。VDC は、個別に構成および管理することが可能な、論理的に独立したデバイス環境を提供します。この仮想デバイス間の分離により、セキュリティおよび管理上の利点に加えて、きわめて貴重な障害分離が提供されます。人的なミスや、構成を原因とする障害状態は、特定の仮想デバイス内に隔離されます。VDC は、基本的にはハイアベイラビリティ機能ではありませんが、VDC によって動作的に独立した障害ドメインが作成され、それがアベイラビリティの向上とデバイス構成に関連するサービス中断の防止につながるということを、常に考慮する必要があります。

VDC の機能や動作についての詳しい説明は、このドキュメントでは扱いません。VDC の詳細については、Cisco Nexus 7000 の仮想化機能についてのホワイト ペーパーを参照してください。

まとめ

ここに示した Cisco Nexus 7000 プラットフォームに関する詳細な検討内容から、このプラットフォーム全体が、ほとんどの状況下で高いアベイラビリティを維持する継続的なサービスを提供することを根本的な目標として設計されていることがわかります。障害分離、障害検知、および障害復旧をあらゆる領域のさまざまなレベルにおいて戦略的に取り入れている Cisco Nexus 7000 プラットフォームは、資本投資とデータ パスを保護しつつ、現在および将来のビジネス ニーズのための重要なエンタープライズ クラス サービスを提供することができます。

用語集

NX-OS:データセンター用オペレーティング システム
MTS:Message and Transaction Service
PSS:Persistent Storage Service
EOBC:Ethernet Out-of-Band Channel(イーサネット アウトオブバンド チャネル)
IETF:Internet Engineering Task Force
RFC:Request For Comment
CMP:Connectivity Management Processor
ISSU:In-Service Software Update(インサービス ソフトウェア アップグレード)
RIB:Routing Information Base
FIB:Forwarding Information Base(転送情報ベース)
VDC:Virtual Device Context(仮想デバイス コンテキスト)
NSF:Non-Stop Forwarding (ノンストップ フォワーディング)
HA:High-Availability(ハイアベイラビリティ)
API:Application Programming Interface(アプリケーション プログラミング インターフェイス)
MST:Multiple Spanning-Tree
LACP:Link Aggregation Control Protocol