大規模DCのネットワークデザイン
- 2. 自己紹介 小林 正幸 (@markunet) 25歳 個人事業主 • 企業のネットワークインフラの設計構築、技術提供 • 新技術検証、運用自動化検討、アドバイザー • BGP, MPLS, EVPN etc その他 • Home NOC Operators‘ Group (AS59105)
- 3. 注意事項 • 本職ではありません。 • どちらかと言えば実用的なルーティングデザインについての説明です。 • 資料内の設計やモデルはあくまで一例です。 • 主にRFC7938を噛み砕いた内容となっています。 • 分かりやすく説明することを目的としているため、一部技術的に厳密 でない表現等が含まれています。
- 4. Traditional Design • North-South Traffic のための設計 • 帯域のスケールには、モジュール交換 などのアップグレードが必要 • 帯域やポート密度の物理的制約で、 East-West Trafficに対しての拡張性に 乏しい • この構成のほうが最適な場合もある Aggregation Access Core Core Aggregation Access Access North-South
- 5. 考慮するべきこと トラフィックパターン North-South & East-West トラフィック割合がどの程度か CAPEXの最小化 トラフィック量≒規模に比例して設備投資は増加する 機器の一括購入による値下げ マルチベンダによる競争圧力を利用したコストダウンと多様性確保 OPEXの最小化 障害範囲の最小化と運用自動化 トラフィックエンジニアリング 大規模DCではECMPによる負荷分散 障害時にトラフィックをすばやく迂回できることが重要
- 6. 設計要件 1. スケール可能であること 2. 機能・プロトコルのベンダロックインを避ける 3. シンプルなルーティングプロトコルを選択する 4. 障害発生時の影響範囲を最小化する 5. トラフィックエンジニアリングが行える
- 7. Large Scale Data Center Network • VM-to-VM 通信(East-West Traffic)の増加に対してスケールするNW • OPEX/CAPEXの削減に効果的なモデル • 将来的にオーバレイテクノロジの導入を考慮した設計 https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network
- 8. Multi-stage CLOS Topology 3-Stage Folded Clos Topology Spine-and-Leaf Topology Spine Leaf Leaf Leaf Leaf Spine Ingress Egress Middle Tier2 Tier1
- 9. Spine – Leaf Architecture Spine #1 Leaf #1 Leaf #2 Leaf #3 Leaf #4 • East-West 通信に特化したネットワークアーキテクチャ • Leafは必ずSpineに接続され、Spine同士、Leaf同士は接続しない • どのLeaf間の通信も同一ホップ数で到達する • それぞれのstage(段)は同種(ポート数、コンポーネント)の機器で構成される Spine #2
- 10. Spine – Leaf Architecture Spine #1 Spine #2 Leaf #1 Leaf #2 Leaf #23 Leaf #24 • Spineを増設することでFabric全体としてのスイッチング容量を増やせる • East-Westのトラフィックに対しての水平スケールが容易 • Leafが増えるにつれてP2Pリンク数が指数関数的に増加する Spine #15 Spine #16 Scaling
- 11. Routing & Switching Design • Layer2 only • ブロードキャストドメインの管理とトラブルシュートの負荷が大きい • Layer2 & Layer3 Hybrid • 複数プロトコルを同一ドメイン内で動作させると運用負荷が増大する • Layer3 only • L2ブロードキャストドメインを排除し、安定性と拡張性を向上させる
- 12. Layer2 Design • L2 Fabricでは何らかのループフリーテクノロジが必須 • Ethernet Fabricはマルチベンダの相互接続運用が難しい • TRILL • SPB • FabricPath • VCS Fabric • MC-LAGによるL2 Fabricも同様 • L2はその性質上、運用負荷が高くなりやすい
- 13. Layer3 Design • IP Fabricの主要なルーティングプロトコル • OPSF / IS-IS • OSPFは優先度の低い経路まですべて同期する • LSDBのスケーラビリティに乏しい • どちらのプロトコルも経路情報をflooding • 定期的に発生するマルチキャストパケット • BGP • 上記の問題を根本的に解決可能
- 14. BGPを採用するメリット • インターネットバックボーンで使い古されたプロトコル • Knowledgeが豊富 • イマドキのL3機器には必ず実装されている • マルチベンダでもほぼ問題なく動く • BGPは原則ベストパスしかFIBに載らない • BGP Path Huntingによって、不要なPathは無視される • OSPFで実現すると複雑で膨大なリソース消費が起きる場合がある • ECMPを行いたい場合には弱点にもなる • 細かいポリシーに基づいた制御が可能 • Import/Exportのポリシーによる細かい経路制御が可能 • 障害やメンテナンス時の通信迂回が容易
- 15. IGP vs BGP • BGPはDCネットワークではまだ発展途上らしい WANで利用するものだと広く認識されている そもそも要件に入っていない 正しく運用できる人材が限られている 一定の規模以上でなければスケールメリットが発揮しにくい 小～中規模ではリンクステートプロトコルの方が運用しやすい場合が多い BGPはNeighborの自動検出を実装していない Peerごとに設定が必要で管理コストが大きい 設定の作成と投入、オペレーションの自動化が重要
- 16. BGP設計に必要な情報 • サーバセグメントのPrefix • 各テナントの経路 • インフラセグメントのPrefix • 機器のI/Fなどに設定するアドレス • Loopback IF, P2Pなど • AS番号 • プライベートAS64512～AS65534 • BGP ポリシー • Import/Export に適用 • orlongerでPrefix filter ASN ASN ASN ASN ASN ASN /26 IPv4 /31, IPv6 /127 169.254.x.x/31 /26 /26 /26
- 17. iBGP Design • Spineがルートリフレクタとして動作する • BGPはベストパスのみ広報するためECMPには冗長パスが必要 • BGP-ADDPATH(RFC7911)などを有効にする • BGPの代替経路を広報する実装は機器によって偏りがある RR RR RRC RRC RRC RRC AS65300
- 18. eBGP Design • IGPを有効にしないeBGPのみの設計 • ToRすべてに異なるASNを設定 • P2Pのprefixを広報しなくても到達性が確保可能 • iBGP構成より比較的簡単にECMPが可能 AS65201 AS65202 AS65303 AS65304 AS65305 AS65306
- 19. eBGP 設計時の注意事項 • プライベートASNの枯渇 • 大規模環境では2byte空間のASNが枯渇することもある • 4byte空間の利用も可能だが機器の実装に依存する • プライベートASNを再利用する • 決められたルールに従ってASNをテナントで再利用する • AS-PATHのループ検知を無視するため“allowas-in”などのオプションを 利用する • ECMPによる負荷分散の実装 • 同一長で属性値の異なるAS-PATHで負荷分散を実現するため “multipath relax”または“multipath multiple-as“ オプションを利用する
- 20. eBGP 設計時の注意事項 • Point-to-Point Prefix の扱い • Fabric構成はP2P Linkが多く、それに割り当てられたprefixも増加する • P2Pの経路をすべてBGPに広報する必要が本当にあるのか確認する • BGPにP2P経路を広報する場合は可能な限り集約する • 不要な細かい経路をFIBに載せない • 外部への広報が不要であれば”169.254.x.x/16”のリンクローカルアドレ ス空間を利用することもある ※ • ただしサーバセグメントの細かい経路は集約しない ※ tracerouteで到達できない経路が出るなど運用面で困る場合も
- 21. External Connectivity • プライベートASを除去してFabric構成を隠蔽する • remove-private-asは運用の基本 • 広報する経路&受け取る経路を正しくフィルタする CSW ASW ASW ASW ASWASWASW CSW CSW CSW ERER Internet MPLS Backbone Edge Access Core
- 22. IP Fabric DC Interconnect • MPLSバックボーンで異なるIP Fabric DCを相互接続する • VPNで使い慣れた”as-override”で異なるリージョンの同一ASを接続 CSW ASW ASW ASW ASWASWASW CSW CSW CSW ERER InternetMPLS CSW ASW ASW ASW ASWASWASW CSW CSW CSW ERER MPLSInternet MPLS Core Transport DC #1 Tokyo DC #2 Osaka
- 23. 実際の設備構成 当日限り
- 24. 今後の設備構成 当日限り
- 28. IP Fabricの運用 • 監視の対象がとにかく多い • 機器, IF, BGP peer, 経路 … etc • 機種によってはSNMPをFabricでまとめて取得できるものもある • イベントやデータを可視化し効率的に管理・分析する仕組みを構築中 • TIGK Stack = Telegraf + InfluxDB + Grafana + Kapacitor • 運用の自動化が必須 • BGPのpeer設定を手動で行うのは現実的ではない • Fabricでは同一ベンダの機器で構成が揃えられていることが多いので 共通のAPIが利用できる • 最初から全て自動化は不可能、できることろから始める
- 29. DCIMのツールを導入 • Netbox • DigitalOceanが開発したオープンソースのIPAM&DCIMツール • アドレスや機器の情報に加えて、回線情報やVRFなどの管理が可能 • UIが見やすく設備管理の効率が格段にアップ！
- 30. まとめ • 大規模DCではSpine-Leaf(CLOS)構成がスケールしやすく主流になりつつある • 相互接続の安定性と制御の柔軟性に優れたBGPを選択すると運用しやすい • これからますます運用の自動化が必須になる
- 31. 参考 • RFC7938 “Use of BGP for Routing in Large-Scale Data Centers” • https://tools.ietf.org/html/rfc7938 • RFC7911 “Advertisement of Multiple Paths in BGP” • https://tools.ietf.org/html/rfc7911 • Introducing data center fabric, the next-generation Facebook data center network • https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the- next-generation-facebook-data-center-network
- 32. ご清聴ありがとうございました！