BGP in the Data Centerを読みました (1/6) : Chapter 1 - Introduction to Data Center Networks
BGPを採用したデータセンタ (DC) 内のIP Fabricに関して、"BGP in the Data Center" を読んだので、備忘録のためにまとめます。
書籍はCumulus Networksのサイトでダウンロードできます。
Chapter 6まであるのですが、今回はChapter 1についてまとめました。 今後Chapter 6までまとめていきたいと思います。
データセンタネットワーク全般については、”Cloud-Native Data Center Networking” を読むのがおすすめです。 筆者が同じ方で、 "BGP in the Data Center" に記載されている内容も含まれています。 この本はCumulus Networksにより無償で公開されています。 ぜひ読んでみてください。
Download your copy of latest book by Dinesh Dutt, "Cloud Native Data Center Networking." It's a 400-page must-read for all network architects, developers and operators. Don't miss out! #CumulusResources https://t.co/JwAAiOHh1f pic.twitter.com/nVJUZyw67Z
— CumulusNetworks (@CumulusNetworks) 2020年1月13日
各Chapterまとめ
- Chapter 1 - Introduction to Data Center Networks
- Chapter 2 - How BGP Has Been Adapted to the Data Center
- Chapter 3 - Building an Automatable BGP Configuration
- Chapter 4 - Reimagining BGP Configuration
- Chapter 5 - BGP Life Cycle Management
- Chapter 6 - BGP on the Host
Chapter1 - Introduction to Data Center Networks
DCネットワークでのBGP採用の背景
DCネットワークでBGPが採用されるようになった背景は、主に3つあります。
- サーバ間通信 (East-West traffic) の増加
昔はサーバとクライアントが通信するモデル (North-South traffic) が一般的でしたが、 現在はクラウド上のVM間通信やマイクロサービスアーキテクチャ等によって、サーバ間通信が増加しています。
- スケールの増大
DC内のサーバのスケールは数百台単位だったものが、現在では多いものでは数十万単位にまで増加しています。
- 障害発生時におけるサービス提供の維持 (レジリエンス)
障害発生時でもサービスを維持し続ける重要性は、ますます高まっています。 DC内で動いているモダンなアプリケーションは、サーバやネットワークの障害発生時でも動き続けるように設計されています。 そのため、障害範囲を狭めることができればサービスを維持できます。
こうした背景から、DCのネットワークトポロジが変遷してきました。
従来のネットワークトポロジ
従来のネットワークトポロジでは、North-South trafficが想定されていました。
従来のネットワークトポロジは、スケールインモデルです。ネットワーク帯域を拡張する際は、より大きくて高価な機器に交換します。 冗長性の確保には、二重化を採用します。 大きな機器ほど多くの機器と接続するため、故障した際の影響範囲が大きくなります。
図におけるaccessとaggregationの間は、ルーティング (L3) ではなくブリッジング (L2) で接続されます。
Closネットワークトポロジ
East-West trafficの増加に伴い採用されるようになってきたのが、Closネットワークトポロジです。Charles Clos氏の名前からそのように名付けられています。
図で一番上にあるのがspineノードで、その下にあるのがleafノードです。全leafが全spineに接続されます。そして、サーバはleafに接続されます。
従来のネットワークがスケールインモデルであったのに対し、Closネットワークはスケールアウトモデルです。ネットワーク帯域を拡張するときはspineノードの台数を追加します。 リンクの本数が多いので、ノード間の帯域幅は大きくなります。
従来のネットワークでは冗長性の確保に二重化を使っているため、障害発生時には帯域が半分に減ってしまいます。 それに対しClosネットワークでは、ノード数が多いほど、障害発生時の帯域幅の減少は僅かになります。
Closネットワークでは、従来のネットワークで使用していたブリッジング (L2) の代わりにルーティング (L3) を使用します。 L3を採用することで、ネットワークのスケーラビリティが高まります。 また、L2で利用されるSTPやVRRP等のプロトコルが撤廃できるため、ネットワークの安定性も高まり、トラブルシューティングのポイントが削減されます。
Closネットワークで採用するルーティングプロトコル
OSPFやIS-ISはIGPとして設計されていますが、OSPFにはマルチプロトコルサポートがなく、IPv4ではOSPFv2、IPv6ではOSPFv3がそれぞれ必要になります。 また、IS-ISはマルチプロトコルをサポートしているものの、優れた実装が少なく機器の選択肢が制限されるらしいです。
OSPFとIS-ISは、どちらもリンクステートプロトコルです。 リンクステートプロトコルは、リンクの状態が変化した場合に変更されない遠くのルータにも、リンクの状態の変化が伝搬するという特性があります。
そこで、DCのClosネットワークではBGPを採用します。 BGPは、OSSも含めて成熟した堅牢な実装が多数存在します。 また、IPv4, IPv6, MPLS, VPNといったマルチプロトコルをネイティブでサポートしています。 パラメータ等を調整することで、DC内でも効率的にBGPを利用可能です。
BGPのDC内への適用は、これまでMicrosoftのAzureチームが主導してきました。
- RFC 7938 - Use of BGP for Routing in Large-Scale
- NANOG55 - Routing Design for Large Scale Data Centers: BGP is a better IGP!
- JANOG33 - Experiences with BGP in large Scale Data Centers
Closネットワークのリンク
Closネットワークでは、ノード間は1本のリンクで構成することが推奨されます。 port-channel等により複数のリンクを使用する場合、ノード間で1本のリンク障害が発生しても、BGPのECMPと見なされ続けます。 帯域が半分になったリンクに同量のトラフィックが送信され続けるため、ECMPでもパケットドロップや遅延が増加します。
図では、leaf01からleaf02へのECMPは2つありますが、spine02とleaf02の間の帯域が障害発生時に半分になります。 また、BGPにはリンク帯域拡張コミュニティがありますが、一般的にはサポートされていません。
2層Closネットワークで収容できるサーバ台数
leafのポート数が n 、spineのポート数が m のとき、この2層のClosネットワークに収容できるサーバの台数は、 n * m / 2 台で表されます。
2で割っているのは、leafはspineとサーバの両方に接続するからです。概算なので、leafの上流と下流の帯域は1:1になっています。実際には1:2や1:3などの構成も考えられます。
同じポート数 n のスイッチだけで構成するなら、サーバ収容台数は n^2 / 2 台です。
DCにClosネットワークをデプロイする場合、サーバとleafの間は10Gbpsのような低速リンクで接続し、leafとspineの間は40Gbpsのような高速リンクで接続します。 なお今後は、サーバとleafの間で25Gbps、leafとspineの間で100Gbpsを使う構成が主流になると考えられます。
実際の値を考えてみます。 40Gbpsや100Gbpsの高速リンクのスイッチはたいてい最大32ポートです。
また、電力の制限があるので、1ラック当たりに収容できるサーバは最大で40台です。
このとき、Closネットワークに接続できるサーバ台数は、最大で 32 * 40 = 1280 台です。
現在は64ポートのスイッチが登場しており、将来的には128ポートのスイッチも出てくると考えられます。
3層Closネットワーク
2層のClosネットワークでは、サーバ1280台までのスケールアウトに留まってしまいます。そこで、1層増やした3層Closネットワークを考えます。 3層Closネットワークでは、ラック内のサーバを収容するスイッチをToR (Top of Rack) と呼びます。ToRとLeafの間の2層ネットワークはpodやクラスタと呼びます。
("BGP in the Data Center" ではSpine, Leaf, ToRと呼んでいますが、 ”Cloud-Native Data Center Networking” ではSuper-Spine, Spine, Leafと読んでいます。 また、RIFTのInternet DraftではこれらをToF (Top of Fabric), ToP (Top of Pod), ToRと呼んでいます。 3層の場合、Super-Spine, Spine, Leafの組み合わせで使われているのをよく目にする気がします。)
同じポート数 n のスイッチで3層Closネットワークを構成すると、 n^3 /4 台のサーバが接続可能です。
例えば64-portのスイッチを使うなら、 64^3 / 4 = 65536 台のサーバが接続できます。
ただ、 16 * 16 * 16 = 10240 台までのサーバを接続するというのが現実的な値です。
ポートベースでサーバの収容台数を考えていくと限界があります。そこで大規模ネットワーク事業者は、次のような手段を取ります。
- ブレークアウトケーブルを使う www.fs.com
32ポートの100Gbpsスイッチをブレークアウトして、128ポートの25Gbpsスイッチとして使うなら、
サーバは 128 * 64 * 40 = 327680 台接続可能です。
spine用に大型シャーシスイッチを導入する www.arista.com
複数のspineを導入する
このほか、規模によっては4層や6層のClosネットワークも考えられます。
Closネットワークのケーブル検証
Closネットワークでは大量のケーブルの管理が必要になります。 そこで大手のネットワーク事業者は、配線の検証に自社製の技術を採用しているとのことです。
また、Cumulus Linuxには、Presciptive Topology Manager (PTM) と呼ばれるOSSがあります。 PTMでは、配線の設計情報とLLDPから得られた実際の配線の状態を比較して、配線の状態を検証します。
Prescriptive Topology Manager - PTM | Cumulus Linux 4.1
固定フォームファクタスイッチ
固定フォームファクタスイッチのみで大規模ネットワークを構築すると、スイッチの在庫管理が容易になります。 スイッチの種類が多くとも2, 3種類に収まるので、スペアのスイッチを在庫として持ちやすく、スイッチをサーバと同じように在庫管理できるようになります。 故障時には、トラブルシューティングよりも先にスペアに交換するというアプローチを取ることもできます。
Closネットワークにおけるサーバの接続モデル
single-attach
web-scaleな企業では、各サーバは単一のleafまたはToRにのみ接続するモデルを採用します。これは、超大量のサーバがあり、1ラック全体がダウンしても許容できるからです。
dual-attach
デュアルアタッチ接続モデルでは、2台のスイッチを論理的に1台とみなすベンダー独自プロトコルを利用して、サーバは1台の論理的なスイッチと接続します。
single-attachと比較すると、必要なスイッチの台数は増えますが、ラック全体の耐障害性が高まります。 スイッチのファームウェアのアップデートなどのメンテナンス時に、ラック全体がダウンするのを避けることができます。
図に楕円で示すとおり、スイッチ間およびサーバとスイッチの間は、port channelやbondingを用いて 複数のインタフェースがそれぞれ1つの論理インタフェースとみなされます 。 サーバとスイッチの間では、LACPを使用して、複数の物理リンクを1つの論理リンクとみなします。 スイッチ側のマルチノードLACPはベンダーが独自実装しており、サーバで特別な対応は必要ありません。
なお、サーバがBGPを利用できる場合はLACPも不要です。ブリッジングを完全に撤廃できます。
DCと外部の間の接続
DCが外部とどのように接続されるか見ていきます。
中規模から大規模のネットワーク
中規模から大規模のネットワークでは、Border ToRまたはBorder Podと呼ばれるpodを介して外部と接続します。
小規模ネットワーク
外部接続用のスイッチを採用しない小規模ネットワークでは、全spineが外部と接続します。
マルチテナンシー
従来のネットワークでは、VLAN等によりテナントごとにネットワークを分離していました。 現在はVXLANやIP-in-IPトンネル等のトンネリング技術によってテナントを分離できます。 こうした技術を利用することで、Closネットワークはクラウドのバックボーンにも採用可能です。
構築の自動化
DCネットワークの規模が大きくなってくると、構築の自動化が必要になります。 自動化が容易になるようにClosネットワークを設計します。
Chapter1まとめ
- DCネットワークの傾向
- サーバ間 (East-West traffic) が増加
- サーバ台数のスケールが増大
- 障害発生時にサービスを継続して提供する重要性が高まっている
- 従来のネットワーク
- North-East traffic
- スケールインモデル
- coreとaggregationの間はL2
- 障害の影響範囲が広い
- Closネットワーク
- East-West traffic
- スケールアウトモデル
- L2を撤廃しL3を採用
- 障害範囲を限定
- ルーティングプロトコルとしてBGPを採用
- サーバ収容台数をポート数から概算可能
- スイッチをサーバと同じように在庫管理可能
- トンネリングによりマルチテナンシーをサポート
- 構築自動化を想定した設計
