Cisco Nexusスイッチにスタッキングはありますか？

Cisco Nexusスイッチに関して、私が最初に問われる質問の1つは、それらでサポートされているスタックです。 否定的な答えを聞いた後、論理的な「理由」が続きます。



答えは、スイッチスタックが単一障害点として機能できることです。 同時に、Nexusはデータセンター内のスイッチとして位置付けられており、耐障害性が最初の場所の1つです。



「しかし、あなたは自分でスタックに基づいてフォールトトレラントなインフラストラクチャを構築できると書きました（ パート1 、 パート2 、 VSS / IRF ）！ わかった、だまされた？」 いいえ、決して。 ネットワークにとって短所がそれほど重要ではない場合、各技術は適切であり、その利点は明白な利点をもたらします。 したがって、スタックでは状況は似ています。



スタッキングには2つの主な利点があります。

• すべてのスイッチの単一の管理ポイント（管理プレーン）、
• スタック内の異なるデバイスに接続されたチャネルを集約する機能（マルチシャーシリンク集約-MC-LAG）。

スタック内のすべてのスイッチは、1つの共通インターフェースを介して構成および保守されます。



MC-LAGのサポート（Ciscoの観点から-ポートチャネル）により、次のことが可能になります。

• ネットワーク上のスパニングツリープロトコル（STP）プロトコルの使用を最小限に抑える
• 集約された帯域幅を使用します（すべてのチャネルがアクティブです）。
• デバイス（スイッチ、サーバーなど）のフェイルセーフ接続を提供します。

スタックでは、共通コントロールプレーンによりMC-LAGが可能です。 スイッチの1つがメイン（マスター）になります。 他のすべてのデバイスの作業を調整するコントロールプレーンを実行します。 ところで、管理プレーンはその上でアクティブになります。 スタックには常に1つの「頭脳」があります。 スイッチのハードウェアリソースは独立しています。 それらの1つが故障しても、残りは機能し続けます。





共通のコントロールプレーンには、別の素晴らしいボーナスがあります-スタック上のトラフィックをルーティングする単一ポイント。 これは、デフォルトゲートウェイのバックアップ冗長プロトコル（First Hop Redundancy Protocol）を構成する必要がないことを意味します。



したがって、スタッキングには、共通のコントロールプレーンと管理プレーンが含まれます。 すべての利点にもかかわらず、これは失敗の可能性のあるポイントです。 また、ハードウェアスイッチは独立していますが、スタックが正常に機能しなくなる可能性のある障害（ハードウェアに関係しない）があります。 たとえば、メインスイッチのコントロールプレーンがメモリリークのために「フリーズ」した場合。 結果は異なる可能性があります。スタック制御の喪失、さまざまなプロトコル（LACPなど）の終了。 この場合、スタックは引き続きトラフィックを送信します。 結局、ASICは必要なデータで満たされ、コントロールプレーンの動作から実質的に独立しています。 ただし、LACPパケットは隣接デバイスに送信されなくなるため、すべての動的集約（MC-LAG）はバラバラになります。



別の考えられる問題は、複数のスイッチがアクティブであるとすぐに判断する状況です（「スプリットブレイン」）。 それらの構成は同一であるため、ネットワーク上に同じアドレス指定を持つ2つのデバイスがあります。 これは、制御チャネルの中断が原因で発生します。 もちろん、この現象と闘うことを目的とした技術があります。 この場合、スイッチは追加メカニズムを使用して、ネイバーのステータスを監視します。 そして、いくつかのタイプのスタックの制御チャネルは壊れにくいです。 しかし、そのような状況を軽視しないでください。



したがって、スタックは、破損が致命的ではないネットワークに適したソリューションです。 はい、完全にフェイルセーフなソリューションとは言えません。 しかし、危機的な状況の可能性はそれほど大きくありません。 そして、それはそれが提供する利点で報われる以上のものです。



Nexusスイッチは、フォールトトレランスが非常に重要な環境（主にデータセンター）のソリューションとして位置付けられています。 したがって、これらのデバイスにはスタッキングはまったくありません。 Nexusの範囲はデータセンターだけに限定されないことに注意してください。 これらは、企業ネットワークを構築するときを含めて使用できます。



しかし、スタッキングには大きな利点があります。 したがって、Nexus'yは、スイッチをスタックに結合せずにそれらを取得できる多くのテクノロジーをサポートしています。



仮想ポートチャネル（vPC）テクノロジーは、MC-LAG機能を実装するために使用されます。 各Nexusには、独自の独立した制御および管理プレーンがあります。 この場合、2つのスイッチ間で配信されるチャネルを集約できます。 もちろん、デバイスの完全な独立性は得られません。 このプロセスで、スイッチは集約に必要な情報（MACアドレス、ARPおよびIGMPレコード、ポートステータス）を相互に同期します。 ただし、フォールトトレランスの観点からは、単一の制御および管理プレーンよりも優れています。 この回路はより信頼性があります。 vPCが誤動作した場合でも、インフラストラクチャにとって致命的ではありません。



ただし、vPCは作業の特別なニュアンスをもたらします。 2つのNexusスイッチ間でのみ設定でき、両方のスイッチが同じ設定のセットを持っている必要があります。 一部の機能では、通常のスタックを使用する場合には必要のない小さな追加設定が必要です。 たとえば、2つのvPCポート間でトラフィックを正しくルーティングすることは、peer-gatewayコマンドの存在を意味します。 そうしないと、vPCを介してトラフィックを送信するときに、ループ防止メカニズムにつまずく可能性があります。 vPCを介した動的ルーティングには、「layer3 peer-router」が必要です。 些細なことのように思えますが、神経を損なう可能性があります。 すべてのテクノロジーがvPCとの作業で互換性があるわけではありません。 Nexusモデルに大きく依存します。 設定ガイドを注意深く見る必要があります。 一般的に、いつものように、すべてに長所と短所があります。











すべてのスイッチの単一の制御ポイントに関して、スタッキングの欠如は次のポイントによって補われます。

1. 外部エクステンダーNexusの使用（ファブリックエクステンダー-FEX）。 これらは、一部のデータプレーンだけでなく、コントロール/管理プレーンのすべての機能がメイン（親）スイッチに配置される特殊なスイッチです。
   
   
   
   すべてのFEXロジックは親Nexusに実装されているため、FEXと親スイッチは単一障害点です。 FEX'ahでは、ローカルスイッチングはありません。 隣接ポート間のパケットは、親デバイスを介して送信されます。 したがって、それらの間のチャネルの負荷が増加します。
   
   
   
   
   
   
   
   
2. 2つのスイッチ間で構成を同期する機能（構成の同期）。 この場合、コントロール/管理プレーンは独立したままです。

最後に。 Nexusにはスタックがありません。 これは他の技術によって部分的に相殺されます。 ただし、ネットワーク設計に特定のリスクをもたらすため、慎重に使用する必要があります。



覚えておく価値があります。ソリューションがフォールトトレラントであるためには、依存する部分を持たないようにする必要があります。 フォールトトレランスを提供するテクノロジやプロトコルも、障害を引き起こす可能性があります。 さらに、それらのおかげで、あるデバイスから別のデバイスに問題が発生する可能性があります。 何も完璧ではありません。 したがって、フォールトトレランスの問題が重要な場合は、デバイス同士の影響が最小限になるようにネットワークを構築する必要があります。



しかし、これはまったく異なる話です。



便利なリンク：

1. vPCと組み合わせてサポートされるFEXトポロジ
2. vPS作業組織のベストプラクティス（PDF、8.7 MB）