スイッチのスタック構成は冗長化なのか – 管理簡素化と障害ドメインで考える

スイッチのスタック構成は、複数台のスイッチを論理的に 1 台として扱える便利な仕組みです。設定管理が簡単になり、筐体をまたいだ LAG も組みやすくなります。そのため、アクセス層や小規模ネットワークでは非常に有効です。

ただし、スタック構成を冗長化そのものとして見ると判断を誤ります。スタックの本質は、複数台のスイッチを独立した機器として残すことではなく、ひとつの論理スイッチへ一体化することです。

この記事では、スイッチスタックを管理簡素化、障害ドメイン、制御プレーン、復旧運用の観点から整理します。

まず結論

スイッチのスタック構成は、管理を簡単にする一体化技術です。冗長化の一部として使える場面はありますが、独立した冗長構成そのものではありません。

観点	スタック構成	独立した冗長構成
主な価値	管理簡素化、筐体またぎ LAG、構成単純化	障害ドメイン分離、片系運用、復旧作業の分離
論理構造	複数台を 1 台の論理装置として扱う	複数台を独立した装置として扱う
制御プレーン	共有されやすい	分離しやすい
向く場所	アクセス層、小規模拠点、同一ラック内収容	基幹、L3 境界、重要な集約ポイント

スタックを採用する時は、「冗長化されているか」ではなく、「管理簡素化の価値が、障害ドメインを一体化するリスクを上回るか」で判断するべきです。

スタック構成の本質は一体化である

スタック構成では、複数の物理スイッチを専用ケーブルやスタックポートで接続し、1 台の論理スイッチとして動作させます。管理 IP、設定、制御プレーン、インターフェース管理が一体化されるため、運用上は 1 台の大きなスイッチのように扱えます。

この構造は便利ですが、冗長化とは意味が違います。冗長化とは、片方が壊れても独立した別系統が残ることです。一方、スタックは複数台をまとめて単一の論理装置にする仕組みです。

• 設定管理は 1 つにまとまる
• 管理 IP や運用手順を単純化できる
• 筐体をまたいだ LAG を構成しやすい
• STP や FHRP の設計を簡略化できる
• 一方で、制御プレーンや管理面は一体化する

スタックが有効な場所

スタックが有効なのは、構成を単純化する価値が、独立性を失うリスクを上回る場所です。典型的にはアクセス層や小規模拠点のスイッチです。

• 同一ラック内のアクセススイッチをまとめたい
• 端末収容ポートを増やしたい
• 筐体をまたいだ LAG でサーバーや上位スイッチへ接続したい
• STP の複雑さを避けたい
• 現地作業や設定管理を単純化したい

このような用途では、スタックは合理的です。設計対象がアクセス層であり、障害時の影響範囲が許容できるなら、管理の簡素化は大きな価値になります。

スタックを冗長化と見なすと危険な理由

スタックを冗長化と誤解すると、障害ドメインを過小評価します。物理的には複数台あっても、論理的には 1 台の装置として振る舞うため、単一障害の性質を完全には消せません。

制御プレーンが一体化する

スタックにはマスターやアクティブメンバーの概念があります。マスター切り替わり自体は設計されていますが、切り替え時に管理面や制御面が揺れることがあります。L2 / L3 の中核に置くほど、この揺れは無視しにくくなります。

スタックリンクが障害点になる

スタックリンクやスタックケーブルは、複数台を 1 台にまとめるための重要な経路です。ここに障害や分断が起きると、単なる 1 ポート障害ではなく、スタック全体の整合性問題として扱う必要があります。

ソフトウェア障害を共有しやすい

スタックは同一 OS、同一設定、同一制御面で動くため、ソフトウェア不具合や設定ミスの影響を共有しやすくなります。独立した 2 台構成であれば片系に閉じる問題が、スタックでは論理装置全体の問題として現れる可能性があります。

冗長化と復旧運用は別で考える

ネットワーク設計では、冗長化していることと、安全に復旧できることを分けて考える必要があります。

スタックは物理筐体を複数にできますが、論理装置として一体化します。そのため、障害時の切り分け、ソフトウェア更新、再起動、スタックメンバーの交換、マスター切り替わりをどう扱うかまで考えなければなりません。

これは通信キャリアの大規模障害にも通じる話です。冗長化していても、復旧時の状態管理や流量の戻し方を誤ると、別の障害を引き起こすことがあります。小規模なスイッチ設計でも、同じように復旧運用まで含めて設計する必要があります。

独立した冗長化との違い

観点	スタック構成	独立した冗長構成
管理	1 台の論理装置として管理しやすい	複数台を個別に管理する必要がある
構成の単純さ	高い。STP や FHRP を省略しやすい	設計と運用はやや複雑になる
障害ドメイン	論理装置として一体化しやすい	装置単位で分離しやすい
制御プレーン	共有される	独立させやすい
向く場所	アクセス層、小規模拠点、同一ラック内収容	基幹、DC、重要な L3 境界

スタックは運用を簡単にしますが、独立性を高める仕組みではありません。独立した冗長化は運用が複雑になりますが、障害ドメインを分けやすくなります。どちらを選ぶかは、便利さではなく、どの障害を許容するかで判断する必要があります。

基幹や L3 境界では慎重に扱う

スタックを L3 コア、基幹スイッチ、重要な集約ポイントに置く場合は慎重に考えるべきです。そこでは管理の簡単さよりも、障害時に片系を残せるか、経路を独立して制御できるか、復旧手順を分離できるかが重要になります。

特に、ルーティング、VRF、重要サーバー収容、上位回線集約、閉域網接続などを担う場所では、スタックによって構成を単純化するよりも、独立した装置として冗長化する方が適している場合があります。

• 片系障害時にもう一方を明確に残したい
• 制御プレーンを分離したい
• ソフトウェア障害や設定ミスの影響範囲を限定したい
• 復旧作業を片系ずつ実施したい
• 障害時の責任境界を明確にしたい

MLAG / MC-LAG / vPC との違い

スタックと混同されやすいものに、MLAG、MC-LAG、vPC のような構成があります。これらは製品や実装によって差がありますが、基本的には複数装置を独立させたまま、対向装置からは 1 つの LAG のように見せるための技術です。

スタックのように 1 台の論理スイッチへ完全に寄せるのか、独立した装置性を残したままリンク冗長を作るのか。この違いは、障害ドメインと復旧運用に大きく影響します。

どちらが常に正しいという話ではありません。アクセス層で運用を単純化したいならスタックは有効です。基幹や重要な L3 境界で障害分離を重視するなら、独立した冗長構成や MLAG 系の設計を検討する方が自然な場合があります。

スタックを使うかどうかの判断軸

スタックを採用するかどうかは、冗長化されているかどうかではなく、管理簡素化の価値と障害ドメイン拡大のリスクを比較して判断します。

• その場所はアクセス層か、基幹か
• 障害時に論理装置全体が揺れても許容できるか
• 管理簡素化の価値が独立性低下を上回るか
• スタックリンク障害時の挙動を理解しているか
• アップグレードや再起動をどう実施するか
• 独立構成にした場合の運用負荷を許容できるか

まとめ

スイッチのスタック構成は、複数台のスイッチを管理しやすくするための一体化技術です。アクセス層や小規模ネットワークでは、構成を単純化し、運用負荷を下げる有効な選択肢になります。

しかし、スタックは冗長化そのものではありません。物理的に複数台あっても、論理的には 1 台の装置として扱われ、制御プレーン、管理面、障害ドメインを共有しやすくなります。

重要なネットワークでは、スタックによる管理簡素化よりも、独立した装置として障害ドメインを分けることの方が価値を持つ場合があります。スタックを使うべきかどうかは、便利さではなく、どの障害を許容し、どこまで独立性を確保したいかで判断するべきです。

関連する記事

• クラウド管理型ネットワークと高度設計型ネットワークの違い – 抽象化と制御責任で考える
• KDDI 大規模通信障害から考える通信インフラの設計責任 – 冗長化と復旧運用の難しさ
• 通信キャリアは土管屋なのか – ネットワーク事業者に求められる技術責任
• ネットワークに詳しいとは何か – ルーティングテーブルを読めない危うさ
• AWS VPC に L2 はあるのか – VLAN / ARP / VIP をクラウドの到達性モデルへ翻訳する
• パブリッククラウドで NFV は成立するのか – 仮想アプライアンスを置く前に考えること
• AWS EC2 のネットワーク帯域をどう読むか – baseline / burst / single-flow と NFV 設計
• VyOS VPP は本番ルーターにそのまま入れられるのか – dataplane の責務分界で考える