P ヤフーの IP CLOS ネットワーク サイトオペレーション本部 インフラ技術 3 部 村越健哉
紹介 P n 名前 u 村越健哉 ( むらこしけんや ) n 所属 u サイトオペレーション本部インフラ技術 3 部 n 仕事 u ヤフーのプロダクションネットワーク全般
アジェンダ P n Hadoopネットワーク変遷 n IP CLOS ネットワーク構成詳細 u 設計 u 構築 u 運 n Hadoopテスト結果 n 課題と今後の展望
Hadoop ネットワーク変遷 P
Hadoop ネットワーク変遷 P n Stack/Virtual Chassis 構成 u 当初のHadoop ネットワークは3 10ラック程度 u アップリンクは10Gbps Active-Standby 構成 u ToRのStack/VCで対応 n 問題点 u スケールに限界 10G l Stack/VC では 10 ラック程度 400 ノードくらいまで u 安定性に問題があった
Hadoop ネットワーク変遷 P n L2 Fabric 構成 u 全体を L2 Fabric 構成にすると 30 50 ラック程度に制限される u 2 台の L2 Fabric 構成と Channel 構成によって数の制約を向上 u ToR のアップリンクは 20G または 80G へ L2 Fabric 80G 80G 20G 20G 90 台以上 100 台以上
Hadoop ネットワーク変遷 P n L2 Fabric 構成 u BUM Traffic でコアスイッチの CPU が 騰 l Hadoop 側でチューニングしてもらう u スケールに限界 l シャーシのモジュール数に依存
Hadoop ネットワーク変遷 P n 要件 2015 年春頃 u 120 200ラック u 1ラックあたりのアップリンク 100 200G l サーバの NIC は 10G 1 ラック 20 台弱 u 場所は US DC
P IP CLOS ネットワーク構成 概要
IP CLOS ネットワークとは P n Google, Facebook, Amazon, Yahoo uott(over The Top) が採 している DC ネットワーク構成 引 Introducing data center fabric, the next-generation Facebook data center network https://code.facebook.com/posts/360346274145943/introducingdata-center-fabric-the-next-generation-facebook-data-centernetwork/
IP CLOS ネットワークとは P n East-West Traffic 増 に対応 n スケーラビリティの向上 u ボックススイッチのみであればいくらでもスケール可能 n 可 性の向上 u Spine やアップリンクなど落ちても問題ない構成に n 運 コストの低減 u OSPF,BGP など 般的な構成なので どんな会社のものでも OK
CLOS 構成概要 P n 概要 u Spine: 某 A 社シャーシ Leaf: 某 A 社と White Box 半々 Internet Spine Router Core Layer3 Layer2 OCP サーバ STD サーバ
CLOS 構成概要 P n 概要 u Spine-Leaf 間は BGP u Leaf の Uplink は 40Gx4=160G Internet Spine Router ECMP Core BGP Layer3 Layer2 160G OCP サーバ STD サーバ
P IP CLOS ネットワーク構成 設計
CLOS 設計 P n ケーブル u MPO ケーブルの取り回しが悪いので SMF 利 n アドレス u Spine-Leaf 間は /31 u Leaf 配下は /26, /27 Internet Spine Router /31 40G LR Core Layer3 Layer2 /26 /27
CLOS 設計 P n ボックスのみかシャーシを取り れるか u ボックススイッチのみでいく場合 l 40Gx32portスイッチ 40Gx4port+10Gx48portスイッチ l 200ラック程度の構成にするには3 層で形成する必要がある l 3 層にすれば スケールは充分 l スイッチの数が増 する l 配線,BGP neighbor IP 数など管理が 変
CLOS 設計 P n ボックススイッチ構成 Spine 12 台 Leaf 16 台 ToR 12 台 u Spine 12 台 Leaf 16 台の場合 l ToR 12(Spine に依存 )x 16 セット = 192 台 ( ラック )
CLOS 設計 P n シャーシ構成を取り れる場合 u 前ページのSpine-Leafをシャーシにするイメージ u シャーシSlot8 40Gx32portだと8モジュールx32=256 Leaf u シャーシだとスケールに限界がでる u 配線が少なくて済むので 管理は簡単になる
IP CLOS 設計 P n シャーシスイッチ構成 u Slot 8 モジュールの場合 l 8 x 32port = 256 台 ( ラック )
CLOS 設計 P n 3 層構造と検討結果 2 層を選択 u 管理するものが多い l IF IP アドレス BGP neighbor ケーブル u ホップ数の違い l ToR-Leaf-ToR, ToR-Leaf-Spine-Leaf-ToR u コストの変化 l 以前に較べてシャーシ型のポート単価が下がった
CLOS 設計 P n BGP か OSPF か u 検証でBGPに決定 u 制御しやすさ u 将来的にanycast 構成を検討した場合 l ホスト VM 側でQuaggaなどによりrouting protocolを動作 l OSPFでは helloのマルチキャストが定期的にすべてのvmへ u 安定性
P IP CLOS ネットワーク構成 構築
CLOS 構築 P n 実際の構成 当日公開
CLOS 構築 n 実際の構成 当日公開 P 24
CLOS 構築 P n 納品 設定 u Spine は先 構築 u Leaf はラック納品のため 順次構築 Internet u 設定は ZTP Spine Router Core Leaf OCP サーバ STD サーバ
CLOS 構築 P n 苦労した点 u 場所がUSなので2-3 週間出張 x2で構築 u ラック納品なので に構築 設定できない u ラック納品の遅延 u ケーブル接続とリンクアップ確認 l ケーブル接続は現地の業者に依頼
P IP CLOS ネットワーク構成 運
CLOS 運 P n Leaf から た経路
CLOS 運 P n Leaf から た BGP neighbor
CLOS 運 P n Spine から た BGP neighbor
CLOS 運 P n Leaf Traffic
Spine CLOS 運 P 例 ) n Spine のバージョンアップ u AS-Path prepend で孤 させる xxx.net.cc1# show ip route show ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, A - Babel, T - Table, > - selected route, * - FIB route B>* 0.0.0.0/0 [20/0] via xxx.80.130.26, swp50, 00:01:37 * via xxx.80.130.28, swp51, 00:01:37 * via xxx.80.130.30, swp52, 00:01:37 B>* xxx.80.128.8/32 [20/0] via xxx.80.130.26, swp50, 00:01:37 * via xxx.80.130.28, swp51, 00:01:37 * via xxx.80.130.30, swp52, 00:01:37 B>* xxx.80.128.9/32 [20/0] via xxx.80.130.26, swp50, 00:01:37 * via xxx.80.130.28, swp51, 00:01:37 * via xxx.80.130.30, swp52, 00:01:37 as-path prepend 65530 Leaf xxx.net.cc1# show ip bgp BGP table version is 311, local router ID is 100.80.128.43 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path * 0.0.0.0 xxx.80.130.24 0 65000 65530 65001 64550 i *= xxx.80.130.30 0 65000 65001 64550 i *= xxx.80.130.28 0 65000 65001 64550 i *> xxx.80.130.26 0 65000 65001 64550 i * xxx.80.128.8/32 xxx.80.130.24 0 65000 65530 65001 i *= xxx.80.130.30 0 65000 65001 i *= xxx.80.130.28 0 65000 65001 i *> xxx.80.130.26 0 65000 65001 i * xxx.80.128.9/32 xxx.80.130.24 0 65000 65530 65001 i *= xxx.80.130.28 0 65000 65001 i *= xxx.80.130.30 0 65000 65001 i *> xxx.80.130.26 0 65000 65001 i
CLOS 運 P n Spine のバージョンアップ u maintenance mode(a 社スイッチ ) l GSHUT community
CLOS 運 P n Spine のバージョンアップ u maintenance mode(a 社スイッチ ) l GSHUT community
P Hadoop テスト
Hadoop テスト P n 5TB Terasort
Hadoop テスト P n 40TB Distcp
P 課題と展望
MPTCP の利 P n Multi-Path TCP u セッションごとに偏りが出てしまう l MP-TCP kernel module で解消へ l Hadoop のテストで失敗中 MPTCP sub-flow flow MPTCP
これからの課題と展望 P n ACL 問題 u 社内間の通信はセグメントごとに SVI で ACL 管理 u コアスイッチで膨 な ACL 設定が必要 u Spine-Leaf の Leaf 側へ設定をもっていくか あるいはホスト単位か n 今後の展望 u Hadoopネットワークのみではなく その他のProductionへ展開 u SpineやLeafのアップリンクが落ちても深夜対応しない構成へ!
最後に P n IP CLOS ネットワークを採 u Spine-Leaf はどんなスイッチも採 可能な構成へ
P 42
P Thank you for your kind attention!