【公開】村越健哉_ヤフーのIP CLOSネットワーク

Size: px

Start display at page:

Download "【公開】村越健哉_ヤフーのIP CLOSネットワーク"

あつのおおばま
6 years ago
Views:

1 P ヤフーの IP CLOS ネットワークサイトオペレーション本部インフラ技術 3 部村越健哉

2 紹介 P n 名前 u 村越健哉 ( むらこしけんや ) n 所属 u サイトオペレーション本部インフラ技術 3 部 n 仕事 u ヤフーのプロダクションネットワーク全般

3 アジェンダ P n Hadoopネットワーク変遷 n IP CLOS ネットワーク構成詳細 u 設計 u 構築 u 運 n Hadoopテスト結果 n 課題と今後の展望

4 Hadoop ネットワーク変遷 P

5 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 安定性に問題があった

6 Hadoop ネットワーク変遷 P n L2 Fabric 構成 u 全体を L2 Fabric 構成にするとラック程度に制限される u 2 台の L2 Fabric 構成と Channel 構成によって数の制約を向上 u ToR のアップリンクは 20G または 80G へ L2 Fabric 80G 80G 20G 20G 90 台以上 100 台以上

7 Hadoop ネットワーク変遷 P n L2 Fabric 構成 u BUM Traffic でコアスイッチの CPU が騰 l Hadoop 側でチューニングしてもらう u スケールに限界 l シャーシのモジュール数に依存

8 Hadoop ネットワーク変遷 P n 要件 2015 年春頃 u ラック u 1ラックあたりのアップリンク G l サーバの NIC は 10G 1 ラック 20 台弱 u 場所は US DC

9 P IP CLOS ネットワーク構成概要

10 IP CLOS ネットワークとは P n Google, Facebook, Amazon, Yahoo uott(over The Top) が採している DC ネットワーク構成引 Introducing data center fabric, the next-generation Facebook data center network

11 IP CLOS ネットワークとは P n East-West Traffic 増に対応 n スケーラビリティの向上 u ボックススイッチのみであればいくらでもスケール可能 n 可性の向上 u Spine やアップリンクなど落ちても問題ない構成に n 運コストの低減 u OSPF,BGP など般的な構成なのでどんな会社のものでも OK

12 CLOS 構成概要 P n 概要 u Spine: 某 A 社シャーシ Leaf: 某 A 社と White Box 半々 Internet Spine Router Core Layer3 Layer2 OCP サーバ STD サーバ

13 CLOS 構成概要 P n 概要 u Spine-Leaf 間は BGP u Leaf の Uplink は 40Gx4=160G Internet Spine Router ECMP Core BGP Layer3 Layer2 160G OCP サーバ STD サーバ

14 P IP CLOS ネットワーク構成設計

15 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

16 CLOS 設計 P n ボックスのみかシャーシを取りれるか u ボックススイッチのみでいく場合 l 40Gx32portスイッチ 40Gx4port+10Gx48portスイッチ l 200ラック程度の構成にするには3 層で形成する必要がある l 3 層にすればスケールは充分 l スイッチの数が増する l 配線,BGP neighbor IP 数など管理が変

17 CLOS 設計 P n ボックススイッチ構成 Spine 12 台 Leaf 16 台 ToR 12 台 u Spine 12 台 Leaf 16 台の場合 l ToR 12(Spine に依存 )x 16 セット = 192 台 ( ラック )

18 CLOS 設計 P n シャーシ構成を取りれる場合 u 前ページのSpine-Leafをシャーシにするイメージ u シャーシSlot8 40Gx32portだと8モジュールx32=256 Leaf u シャーシだとスケールに限界がでる u 配線が少なくて済むので管理は簡単になる

19 IP CLOS 設計 P n シャーシスイッチ構成 u Slot 8 モジュールの場合 l 8 x 32port = 256 台 ( ラック )

20 CLOS 設計 P n 3 層構造と検討結果 2 層を選択 u 管理するものが多い l IF IP アドレス BGP neighbor ケーブル u ホップ数の違い l ToR-Leaf-ToR, ToR-Leaf-Spine-Leaf-ToR u コストの変化 l 以前に較べてシャーシ型のポート単価が下がった

21 CLOS 設計 P n BGP か OSPF か u 検証でBGPに決定 u 制御しやすさ u 将来的にanycast 構成を検討した場合 l ホスト VM 側でQuaggaなどによりrouting protocolを動作 l OSPFでは helloのマルチキャストが定期的にすべてのvmへ u 安定性

22 P IP CLOS ネットワーク構成構築

23 CLOS 構築 P n 実際の構成当日公開

24 CLOS 構築 n 実際の構成当日公開 P 24

25 CLOS 構築 P n 納品設定 u Spine は先構築 u Leaf はラック納品のため順次構築 Internet u 設定は ZTP Spine Router Core Leaf OCP サーバ STD サーバ

26 CLOS 構築 P n 苦労した点 u 場所がUSなので2-3 週間出張 x2で構築 u ラック納品なのでに構築設定できない u ラック納品の遅延 u ケーブル接続とリンクアップ確認 l ケーブル接続は現地の業者に依頼

27 P IP CLOS ネットワーク構成運

28 CLOS 運 P n Leaf からた経路

29 CLOS 運 P n Leaf からた BGP neighbor

30 CLOS 運 P n Spine からた BGP neighbor

31 CLOS 運 P n Leaf Traffic

32 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 [20/0] via xxx , swp50, 00:01:37 * via xxx , swp51, 00:01:37 * via xxx , swp52, 00:01:37 B>* xxx /32 [20/0] via xxx , swp50, 00:01:37 * via xxx , swp51, 00:01:37 * via xxx , swp52, 00:01:37 B>* xxx /32 [20/0] via xxx , swp50, 00:01:37 * via xxx , swp51, 00:01:37 * via xxx , swp52, 00:01:37 as-path prepend Leaf xxx.net.cc1# show ip bgp BGP table version is 311, local router ID is 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 * xxx i *= xxx i *= xxx i *> xxx i * xxx /32 xxx i *= xxx i *= xxx i *> xxx i * xxx /32 xxx i *= xxx i *= xxx i *> xxx i

33 CLOS 運 P n Spine のバージョンアップ u maintenance mode(a 社スイッチ ) l GSHUT community

34 CLOS 運 P n Spine のバージョンアップ u maintenance mode(a 社スイッチ ) l GSHUT community

35 P Hadoop テスト

36 Hadoop テスト P n 5TB Terasort

37 Hadoop テスト P n 40TB Distcp

38 P 課題と展望

39 MPTCP の利 P n Multi-Path TCP u セッションごとに偏りが出てしまう l MP-TCP kernel module で解消へ l Hadoop のテストで失敗中 MPTCP sub-flow flow MPTCP

40 これからの課題と展望 P n ACL 問題 u 社内間の通信はセグメントごとに SVI で ACL 管理 u コアスイッチで膨な ACL 設定が必要 u Spine-Leaf の Leaf 側へ設定をもっていくかあるいはホスト単位か n 今後の展望 u Hadoopネットワークのみではなくその他のProductionへ展開 u SpineやLeafのアップリンクが落ちても深夜対応しない構成へ!

41 最後に P n IP CLOS ネットワークを採 u Spine-Leaf はどんなスイッチも採可能な構成へ

42 P 42

43 P Thank you for your kind attention!

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション P ヤフー IP CLOS ネットワークその後ヤフー株式会社テクノロジーグループシステム統括本部サイトオペレーション本部深澤開自己紹介 P 2 名前深澤開 ( ふかざわかい ) 経歴 2013 4 月 ~ ヤフー新卒入社後全社 Hadoop の設計運用 2014 10 月 ~ データセンターネットワーク 2018 7 月 ~ アメリカ赴任 ( 予定 ) 業務データセンター内ネットワークの設計