Claude が書いた記事
データセンターの「Y ケーブル」って何やねん ── サーバーを賢くせずに ToR を冗長化する dual-ToR
Azure / SONiC で使われる dual-ToR の Y ケーブル (スマート mux ケーブル) を、図 4 枚で解体した学習ログ。賢さをケーブルとスイッチソフトに寄せて、サーバーは何も知らないまま ToR を冗長化する仕組み。
俺の最初の疑問
データセンターのサーバーで「Y ケーブル」というものが使われている、と聞いた。
データセンターの Y ケーブルって何やねん？
最初は給電の分岐ケーブル (1 本が二股に割れて電源を 2 つに配るやつ) かと思った。だが本題はもう片方 ── ネットワーク冗長化のためのスマート mux ケーブルで、Azure / SONiC まわりで使われているものだった。ここを解体する。
まず一言でいうと
Y ケーブルは 「サーバーの 1 本の足を、2 台の ToR スイッチに同時につなぐ、自動切替器つきのケーブル」。
サーバーは「1 本だけ刺さってる」つもりなのに、ケーブルの中の切替器 (mux) が「今どっちのスイッチに通すか」を選んでいる。片方の ToR が落ちたら、もう片方へ倒す。
肝は 賢さの置き場所。サーバーにも、スイッチ同士の密な連携にも賢さを持たせず、ケーブルの中の mux と、スイッチ側のソフト (SONiC) に寄せていると整理できる。だからサーバーは、自分が冗長化されていることすら知らないまま済む。
何と比べるとわかるか
ToR を冗長化する手は他にもある。何が違うかを並べる。
| 単一 ToR | 二枚刺し (MLAG) | Y ケーブル dual-ToR | |
|---|---|---|---|
| サーバー側 | NIC 1 本 | NIC 2 本 + bonding | NIC 1 本 (無改造) |
| スイッチ間の連携 | なし | peer-link (密結合) | なし |
| 賢さの置き場 | ── | サーバー + スイッチ両方 | ケーブル (mux) + スイッチソフト |
| split-brain | ── | 起こりうる | 構成上 起きにくい |
| 切替の単位 | ── | リンク集約 | mux の選択 |
要するに Y ケーブル dual-ToR は、冗長化の賢さを「サーバーやスイッチ間連携」から「ケーブルとスイッチソフト」へ寄せ替えた設計、と読める。
何が問題なのか
そもそも、なぜこんなものを作ったか。動機は ToR スイッチの立ち位置にある。
ToR (Top-of-Rack) スイッチは、ラックの出口だ。普通は 1 台しかなく、ここが死ぬとラックのサーバーが丸ごとネットから切れる。単一障害点になっている。
しかも SONiC のようなネットワーク OS は更新頻度が高い。dual-ToR が無いと「ToR の更新 ＝ そのラックの通信停止」になってしまう。これを無停止でやりたい、というのが大きな動機だと語られている。
従来の手段にはそれぞれ難点がある。
- 二枚刺し (MLAG): サーバーに NIC を 2 枚積んで 2 台のスイッチに束ねる。サーバー側もスイッチ側も賢くする必要があり、2 台のスイッチを密に連携させる peer-link が要る。peer-link が切れた瞬間に両方が「自分がマスターだ」と思い込む split-brain に弱い、と指摘されることが多い。
望みははっきりしている ── サーバーを触らず、peer-link も持たず、無停止で ToR を落とせる冗長化。それを Y ケーブルが担う。
図で見る
① 基本構造
1 本の足を 2 台の ToR へ。中の切替器 (mux) がアクティブ側を選び、故障時に倒す。
② ラック全体の配り方
サーバー単位では active-standby。ただし active 先はサーバーごとに振り分けるので、ラック全体では両 ToR が半分ずつ稼働する。
③ パケットの実際の流れ (上り / 下りの非対称 + IP-in-IP)
mux の挙動は上りと下りで非対称。そして spine 経由の保険がある。
④ アクティブ ToR の決め方 (LinkProber)
active / standby は静的な設定ではなく、各 ToR が「自分の心拍の反射が聞こえるか」で自己判定する。
混乱しやすいポイント
ここからが認知のズレを直すパート。順に潰す。
片方の ToR は遊んでる？
「常に片方しか使わない」はサーバー 1 台に視点を固定すると正しい。だが active 先はサーバーごとに振り分けるので、ラック全体では両 ToR が半分ずつ実トラフィックを捌いている。
各 ToR は最初から「100% を捌ける容量」で用意し、平常時は 50% で回す。空けてある半分が、片方が落ちたときに全部を引き受けるための余力になる。「遊ばせない」と「いつでも全部引き受けられる」を同時に満たす配り方、と整理すると腹落ちする。
「24/24 に分けるのは事故のダメージを半分にするため」？
直感の芯は合っているが、主目的は少しズレている。
failover が間に合えば、ToR が 1 台死んでも全サーバーが残りへ倒れて生き残る ── つまり接続のダメージはほぼ無い。24/24 に分ける主目的は 帯域だ。2 台分のアップリンクを片方だけ遊ばせるのはもったいないので、平常時から両方使う。
直感が正しく刺さるのは「故障の瞬間に切替を体験するサーバーの数が半分で済む (影響範囲が小さい)」という部分だった。
上りと下りは対称？
非対称だ。
- 下り (ToR → サーバー): mux はアクティブ側 1 本だけ通す。standby 側の下りは mux が捨てる。
- 上り (サーバー → ToR): mux は両方に複製して送り、standby 側 ToR が ACL で重複分を捨てる。
この非対称が、後述の active 判定の土台にもなっている。
ToR 同士を「渡りケーブル」で横つなぎ？
しない。ToR-A と ToR-B を直結する線 (peer-link / ICL) は、MLAG の世界の話。dual-ToR はその横つなぎを持たない。
ToR 間で通信が要るとき (standby に届いた下りをアクティブへ渡すとき) は、専用の渡り線ではなく、通常のアップリンク経由 ── つまり spine を通って隣へ回す。物理的な渡りケーブルは無い。これが peer-link 不要・split-brain に強い、という主張につながる。
standby は、なぜ spine へ折り返そうと「思える」？
その場で判断しているわけではない。ルーティングテーブル (FIB) に最初からそう書いてあるだけだ。
- ToR が active のサーバー宛て: next-hop = 自分の mux ポート (直接下ろす)
- ToR が standby のサーバー宛て: next-hop = 隣 (active) への IP-in-IP トンネル (折り返す)
standby の ToR に下りが届いたら、普通にルーティングを引くだけで「next-hop = トンネル」に当たる。mux 状態が変われば、linkmgrd の検知を受けて orchagent がこの経路を差し替える (mux ポート直結 ⇄ トンネル)。
なぜ折り返すのが正解かというと、standby 側の下りは mux が捨てるので、その ToR から直接サーバーには届かない。捨てればロスになる。だから 届けられるのは active 側経由だけで、隣へトンネルするのがパケットを救う道になる。
active / standby はどう決まる？
静的な設定ではなく、各 ToR が LinkProber で自己判定する。
各 ToR は自分の ID (MAC / 名前) を埋めた ICMP の心拍を下りに送る。下りの非対称により、アクティブ側の心拍だけがサーバーに届く。それが反射して上りになり、上りは mux が両方に複製するので、反射は両 ToR が聞ける。
- 自分の ID が返ってくる → 自分がアクティブ
- 相方の ID しか聞こえない → 自分はスタンバイ
- どちらも聞こえない → Unknown (リンク断などの異常)
重要なのは、相方の心拍は ToR 直結ではなく、サーバー側の上り複製ごしに聞こえていること。聞こえる窓口はサーバー側の 1 つだけで、これも peer-link 無し設計と整合している。
<1µs の切替って速すぎでは？
それは mux の切替 (cutover) そのものの時間で、故障に気づくまでの時間ではない。
速い理由は「つなぎ直していない」から。Y ケーブルは AEC (Active Electrical Cable) で、両側のリンクを常時張りっぱなしにしている。だから切替は「すでに生きている 2 つの入力から、どっちを通すか選ぶ」だけ ── シリコンの mux でやる選択なので、ほぼ電気速度で終わる。
一方、ToR が死んだと気づく検知時間 (linkmgrd の心拍の取りこぼし判定) は別物で、これより遅い (ミリ秒オーダーと整理しておく)。「故障 → 復旧」全体は、検知時間 + 切替時間。切替中も NIC 側のリンクは落ちないので、サーバーは link-down を見ず、無瞬断 (hitless) になる。
たとえ話
- Y ケーブル全体 ＝ 電源の自動切替スイッチ (ATS) のネットワーク版。機器 (サーバー) は「つながってる」としか思っていない。どっちの系統から取るかは別のコントローラが決める。
- 切替が速い理由 ＝ KVM / A-B スイッチ。両方の機器が電源入りっぱなしだから、ボタンを押した瞬間に映る。「ケーブルを抜いて挿し直す」とは速さが別次元。
- standby の折り返し ＝ 受付の貼り紙。「この宛先の郵便は隣の窓口へ回す」と最初から貼ってある。受付の人がその場で悩んでいるわけではない。
- MUX ＝ テレビの入力切替 (HDMI1 / HDMI2)。複数の入力から 1 つを選んで通すセレクタ。
ニュースを読むための変換表
| ニュース・資料の言葉 | つまり何の話？ |
|---|---|
| dual-ToR | サーバーを 2 台の ToR につないで ToR の単一障害点を消す構成 |
| ToR (Top-of-Rack) | ラックの出口にいるスイッチ。普通は 1 台で、そこが弱点になりがち |
| SONiC | Microsoft 発の OSS ネットワーク OS。dual-ToR の制御はこの上で動く |
| smart cable / mux cable | 中に切替器を持つ Y ケーブルの呼び方。ただの分岐ケーブルではない |
| AEC (Active Electrical Cable) | 中に PHY / リタイマ等を積んだ”能動的な”ケーブル。両側リンクを張り続けられる |
| Credo HiWire SWITCH AEC | この Y ケーブルの実物の一つ。切替は 1µs 未満を謳う |
| MLAG | 2 台のスイッチを peer-link で束ねる従来の冗長化。dual-ToR はこれを避ける |
| split-brain | peer-link が切れて両方が自分をマスターと思い込む事故。MLAG の弱点として語られる |
| linkmgrd | どの ToR をアクティブにするか判断し、mux に倒せと命令する SONiC のデーモン |
| LinkProber | ID 入りの心拍で「自分が active か standby か」を判定する仕組み |
| IP-in-IP | standby に届いた下りを、アップリンク (spine) 経由でアクティブ ToR へ回すトンネル |
| hitless | 切替時に通信が途切れないこと。NIC 側リンクを落とさないので成立する |
| ECMP | spine が複数経路に均等分散する仕組み。だから下りが standby 側に届くことがある |
この記事の続きとして、未来の自分が次に掘るといいトピック。
- active-active 版 dual-ToR ── 両 ToR を同時にフォワードする発展形。今回の active-standby の次のステップ。
- AEC (Active Electrical Cable) の中身 ── PHY / リタイマ / microcontroller。ケーブルが”賢い”中身を見る。
- LinkProber の反射経路の詳細 ── 心拍がどこで折り返るか (サーバー応答かケーブル側ループか)。判定の仕組みを底まで。
- linkmgrd のタイマ・閾値 ── Unknown から mux を倒すまでの具体値。failover の実時間を詰める。
- 大規模での mux 状態の一貫性 ── orchagent と linkmgrd の協調。スケール時の整合性管理。