Contenu connexe Similaire à 大規模DCのネットワークデザイン Similaire à 大規模DCのネットワークデザイン (20) 大規模DCのネットワークデザイン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による負荷分散
障害時にトラフィックをすばやく迂回できることが重要
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
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
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で到達できない経路が出るなど運用面で困る場合も
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
28. IP Fabricの運用
• 監視の対象がとにかく多い
• 機器, IF, BGP peer, 経路 … etc
• 機種によってはSNMPをFabricでまとめて取得できるものもある
• イベントやデータを可視化し効率的に管理・分析する仕組みを構築中
• TIGK Stack = Telegraf + InfluxDB + Grafana + Kapacitor
• 運用の自動化が必須
• BGPのpeer設定を手動で行うのは現実的ではない
• Fabricでは同一ベンダの機器で構成が揃えられていることが多いので
共通のAPIが利用できる
• 最初から全て自動化は不可能、できることろから始める
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