Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ホワイトボックス伝送の動向と商用利用について

Avatar for Mabuchin Mabuchin
January 24, 2020

 ホワイトボックス伝送の動向と商用利用について

at JANOG45

Avatar for Mabuchin

Mabuchin

January 24, 2020
Tweet

More Decks by Mabuchin

Other Decks in Technology

Transcript

  1. WhiteBox伝送装置? ホワイトボックス伝送 ≒ White Box Switch + Transponder 2 Software

    Hardware ASICに加えてDSPが加わったWBS Open Transponder ASIC DSP
  2. mixiのDCI事情 Database Router Router Router Router Cache Data center#2 Data

    center#1 10GE*n キャリア専用線 例 : App増加--->DB/Cache間通信増加 ---> Cloud DX経由の通信が増加-- -> 回線増速 Externals App (on-premise) App (clouds) Database Cache Externals App (on-premise) App (clouds)
  3. DWDMの運⽤上における懸念 DWDMオペレーション経験 : 無し 管理対象機器 : 増加 ベンダーの既存機器 : ⾼価

    Server like Operation : Kernel以降は⾃由に構成 Cost Optimization : 安価&柔軟(ロックフリー) Migrative for reduction : 機器削減を⾒込める 懸念事項 達成したい要件
  4. Cassini + GoldStone検証 l 安定性 l サービスと同等の状況でリソースが安定し、ロスなく伝送するか l Monitoring l

    Memory leak/ CPU load / Temperature / DiskIO / DSP fec,rms l Fowarding test l 商⽤を想定したパケットを流し続ける l Loss / Error check l 運⽤フロー l デプロイフローの整備 l SONiCとDSP Metrics監視⽤Prometheus Exporter実装&整備
  5. テスト時の構成図 T-rex Eth Eth Eth Eth T-rex Eth Eth 15km

    Cassini packet count check Cassini Generate Profile • IMIX • L2 Frame • UDP/TCP • Jumbo Frame… 40Gbps x2 40Gbps x2 Line Fail test Over 6month 200G / 16QAM
  6. 課題1: Goldstone ≠ Transponder •リンクダウン転送がない • CassiniはDSPを搭載できるASIC搭載のスイッチ • LINE側にもASICを持つ •

    Clientポートが落ちてもLINEは落ちない • つまり、ポートのdown転送は⾏われない P2P DWDMとして使うには、そのままでは適さない CoreのIGPのdown検知がdown-timer依存になる
  7. 解決策 : BFDによる断時間の削減 Router Goldstone Router OSFP BFD (1sec *

    3) 現状 : 両端のルータでBFD 100msec*3 今後 : より⾼速&低負荷に検知するための “transponderd”を開発&デプロイ Router Router GoldStone Eth Eth Eth GoldStone Eth transponderd • Subscribe link state by netlink • Create fail detection groupSend • Down request to member by Frame Down notify subscribe Goldstone transponderd
  8. •SONiCの⼿動のオペレーションは相当厳しい • Not Day2 config operation • Typoが混ざるとSyncd(ASIC controller)等down •

    Configに対してのValidationが⽢い 課題2: SONiC synd is delicate 2019-09-12.06:37:27.491030|s|SAI_OBJECT_TYPE_PORT:oid:0x1000000000013|SAI_PORT_ATTR_ADMIN_STATE=false 2019-09-12.06:37:27.491149|s|SAI_OBJECT_TYPE_PORT:oid:0x1000000000013|SAI_PORT_ATTR_SPEED=400000 2019-09-12.06:37:27.491252|s|SAI_OBJECT_TYPE_PORT:oid:0x1000000000013|SAI_PORT_ATTR_ADMIN_STATE=true 2019-09-12.06:37:27.493167|n|switch_shutdown_request|| Typo in configuration Syncd is down….
  9. • Day1 Config(初期投⼊)で全て完結させる • 伝送⽤途なら必要⼗分 • AnsibleでConfig / Tool群を投⼊ •

    コアでL3を任せる場合には、Validationは流⽯にほしい • ConfigのValidationを⾏うPRがMerged!! 今後は改善されるかも 解決策: Day1 Configで完結 DWDM Config.json Exporter Initial data Tools
  10. 課題3 : 様々な起因でOSクラッシュ • 温度管理ミスによるCrash • CassiniはBMCが⾮搭載 • OS上でFANコントロールが必要 •

    SNMP等,マネジメント関連のリソースのメモリリーク • SONiCは枯れていないOSS • 仕様変更に伴ったバグも多く出る • マネジメント系であっても 相応の検証は必須 Leaked…
  11. 解決策: リソース監視を徹底 • リークや不具合は起こり得る前提 • サービスの担保は全体で⾏う • 原因をはっきりさせるためにMonitoring項⽬を強化 • Metricsをコード上で抽出する⼿段が⽤意は多くあるので、

    そこまでキツくはない • Prometheus expoterでまとめて取得 • 基本リソース : node_exporter • TAI特有Metrics : gRPC経由で取得 • SONiC固有Metrics : Redis経由で取得 • 各センサ温度管理 : ONLP lib経由で取得
  12. Ex. 相互接続性検証 •CFP2-ACOの相互接続性試験 • A社 / B社の2メーカーで試験 • 光レベル,FEC,確⽴後のパケット伝送、全て問題無し •

    TAIがマルチベンダーもカバー A社 CFP2ACO libtai WDM1 B社 CFP2ACO libtai WDM2 libtai WDM3 B社 CFP2ACO A社 CFP2ACO T-REX T-REX Bidirirectional Packet Fowarding
  13. Current Cassini + Goldstone use case •PointToPoint DWDM • BFDによって断時間を保証

    Site1 (external connection site) Site2 (Beremetal Application Server site 1) P/PE Core Cloud App servers Cassini Transit Cassini Databases Peers P/PE Core P/PE Core Cloud Goldstone Goldstone P/PE Core P/PE Core P/PE Core IGP bfd Production
  14. WIP: Migrate include Layer3 Routing • 特定拠点のルータ機能吸収 • GoldStoneだけで完結させれる点はルータとして扱う •

    管理対象を削減し、運用の最適化を実施 P/PE Core Cloud App servers Transit Goldstone(as L3) Databases Peers P/PE Core P/PE Core Cloud Goldstone(as L3) W IP SONiC FRR tai SONiC FRR tai SONiC FRR tai SONiC FRR tai Reduce! Site1 (external connection site) Site2 (Beremetal Application Server site 1)
  15. WhiteBox DWDM + OSS NOSのメリット • コスト 特にCFP2ACO等の単価 • 機器のポテンシャル

    伝送装置の役割だけで終わららない その後のL2/L3 Migrationも可能にしていける構造 • 共通技術の活⽤ WDM / Server / Switch 全てで共通の技術を活⽤ Core Component - ONL, SONiC, FRR, Zebra, SAI, TAI etc… Automation/Monitoring - Prometheus, Ansible, gNMI, Go/Python tools... DWDM Core Leaf/Spine Server Core Leaf/Spine Server DWDM → Network特有の運⽤を削減
  16. WhiteBox DWDM + OSS NOSのデメリット • 導⼊のナレッジ蓄積に時間がかかる • SONiCを初めから⼊れてる企業ならOK •

    DWDMのためだけにSONiCを運⽤まで持っていくのは⾟い • エンジニアリングリソース • 特にトラブル解析時に多く必要となる • 「⼿作業でオペレーション」は厳しい • 初めからある程度の作業不要にする取り組みは必要
  17. Summary • Cassini + GoldStoneをプロダクションに導⼊ - Point-to-PointのDWDM - SONiCをDWDMから運⽤開始して他機器に展開するアプローチ -

    コスト⾯では専⽤線より優位 - サーバーライクなオペレーション • SONiCをより上位レイヤーで活⽤するための試験を実施中 - SONiCのL3 Routingを本格的に利⽤して機能統合 Copyright © 2019 mixi, Inc.
  18. 議論したいこと • そもそも、ダークファイバ運⽤していますか︖ • してない⽅は、どのようにDCIを実現していますか︖ • 伝送のオープン化について • ホワイトボックス伝送装置に興味ありますか︖ •

    安価に便利に伝送する他⼿法との⽐較 (10G-DWDM , 100G-PAM4-DWDM , 400G-ZR, CFP2DCO on Switch) • ルータから伝送を吸収するアプローチ • 光伝送の運⽤で課題だと感じている点 • コスト • 取り回し • 運⽤的知⾒の不⾜ • SONiCのようなOSSのNOSを商⽤網で利⽤することについて • 成⻑途中なOSSとの付き合い⽅ • 商⽤サポートvs取り回し,拡張性 • 使いたいけど、実装まで⼿は出せない︖