はじめに
こんにちは、マイクロアドでインフラエンジニアをしているハダです。
今回も、マイクロアドがデータセンター移設（以下DC移設と記述）した話をします。
内容は「IP Closネットワークに作り変えた」話です。
最近は IP Closネットワーク と検索すれば、取り組み事例やJANOGでの発表資料などが公開されています。
IP Closネットワークについてより詳しく知りたい方はそちらも参考にしてください。
DC移設とネットワーク再構築に向けて
DC移設に際してさまざまなことを見直す機会があり、その1つがネットワークです。
ネットワークを見直すにあたって、今までの運用で課題になっていた点をあげて検討していくことにしました。
一言にネットワークと言っても、つながればそれでおしまい…というわけではなく、
可用性・耐障害性や運用のしやすさなど、様々な面で柔軟かつ安定した環境が必要です。
利用者側からするとネットワークはつながって当然という見方をされます。
どれだけ高可用性を担保するかという点は重要ですが、一方で費用対効果についても十分に検討する必要があります。
場合によっては割り切った設計が必要になることもあります。
L2ネットワーク
データセンターでの一般的なネットワークは、以下の図のようにコア層・ディストリビューション層・アクセス層の3層で構成されます。
アクセス層の配下にサーバが接続し、その上のディストリビューション層で集約、コア層はネットワークバックボーンとして高速で大容量の通信が行われます。
アクセス層はL2スイッチで構成され、物理的な視点ではラックのTOR 1 スイッチとして設置されたりします。
ディストリビューション層では、アクセス層のスイッチを集約ポリシーによる管理やルーティングを行うレイヤーです。
コア層は、ディストリビューション層を束ねネットワークバックボーンとして高速で大容量の通信が行われるレイヤーです。
運用していたネットワーク
L2ネットワークの概要を書いたところで、実際にマイクロアドで運用していたネットワークを説明します。
マイクロアドでは以下の図のような構成になっていました。
図の上部がInternet側（フロントエンドネットワーク）です。
コアスイッチ、ファイアウォール/ロードバランサー（以下FW/LB）レイヤー、L2 Fabricという3層で構成されていました。
L2 Fabric部分はベンダー固有の機能を利用したFabricネットワークでした。
FW/LB以下のL2 Fabric部分はフラットなL2セグメントになっていました。
また、サーバを挟んでDC内部だけに閉じたバックエンドネットワークもあり、
こちらもL2 FabricでフラットなL2セグメントを構築していました。
いずれのL2セグメントも用途による分割はしておらず、
千数百台に及ぶ物理サーバと百数十台の仮想サーバ（OpenStackで運用）がフラットに接続していました。
L2 Fabric
L2 Fabricはベンダー固有機能を使用して、L2スイッチ間をマルチパスにできる機能です。
STP/RSTPを使用しないため、ブロッキングされるポートがなく複数のパスを有効に使えるということと、
複数のパスが有効なため冗長性を高めることができるというメリットが有りました。
ただしベンダー固有機能と書いている通り、使うためには同一ベンダーの機器で構成することが必要です。
このL2 Fabricは、デメリットも有りました。
1つ目は、NOS 2バージョンが同一になっていることが必要でした。
2つ目は、NOSバージョンアップ時にネットワーク全体が瞬断するという点です。
フラットなL2ネットワークの課題
フラットなL2ネットワークは、シンプルなIPアドレス設計になるため管理しやすいです。
ただし、台数が多くなるにつれて様々な課題が発生し始めました。
無視できないBUMトラフィック
BUM 3 トラフィックは、L2ネットワークでmacアドレスを知らない通信相手に対して通信する際に発生するトラフィックで、これ自体は必要なものです。
ただし先にも触れたとおり、マイクロアドではフラットなL2セグメントに千数百台の物理サーバと百数十台の仮想マシンが動いている環境でした。 この環境でBUMトラフィックは、一部スイッチのポートに集中し輻輳するということにもつながりかねません。
マイクロアドでは、L2 Fabricのネットワークとそれ以前から使用していた旧ネットワークが接続していました。
その旧ネットワーク部分は、ホスト数の増加とともに増えるBUMトラフィックに耐えられず、たびたび輻輳が発生していました。
ループのリスク
L2ネットワークでは、ループが発生するリスクについても注意しておく必要があります。
ループが発生するのは、物理的にスイッチポート同士を接続する以外にもスイッチ自体の故障により、
不慮の事故としてループが出来上がってしまうケースもあります。
1つ目の物理的な接続によるループは、現場での作業時に十分に注意していれば発生することはありません。
2つ目の故障によるループは、使い方によって発生する可能性があります。
マイクロアドで過去にあったのは、マネージメントで使用していた安いスイッチが故障した際の障害です。
VLANで分けて管理用にしていたポートが故障して他のVLANで使用していたポートとループが発生してしまいました。
図解するとこのような感じです。
これは、もともと独立していたマネージメントネットワークを変更した際にVLANが別れているという理由から
ループになる可能性を考慮していなかったためでした。
このように、機器の故障によりループが発生することもあるため物理的な接続構成については、
VLANが別れていてもループが発生しないように設計しておく必要があります。
IP Clos Network
小規模なIP Clos Networkでの実証実験
マイクロアドでは、DC移設前からIP Closネットワークを部分的に導入した環境がありました。
ごく小規模な学習と運用テストを兼ねて、Hadoopクラスターを収容する環境でバックエンド通信のみが行われる環境でした。
その環境は、複雑なものではなくシンプルにバックエンドネットワークの一部として、既存ネットワークに接続していました。
この時の構成は、主に次のようになっていました。
- スイッチは、ホワイトボックススイッチ、NOSはCumulus Linuxを使用
- Spine-Leafは、BGPでPeering
- LeafはMLAG 4 を構成し、サーバとLeaf間は接続を冗長化
- 既存L2 Fabricへの接続Leafでは、VRRPを設定
このように構成し、それぞれが異なるASN 5を持ちBGPで経路を交換するという構成になっていました。
既存環境にIP Closネットワークを接続する際に発生した問題は、バックエンドネットワークに接続していたため
Default Gatewayを使って接続が行えない点でした。
（Default Gatewayはフロントネットワーク側で使用しているため）
そのため、既存サーバでIP Clos側のサーバと接続が必要なものには、static routeを設定する必要になり これがかなりの手間を発生させてしまいました。
DC移設まで約5年ほど運用してみて、構成をもう少しこうしたほうが良かったということや L2 Fabricと違ったメリットなどが見えてきて規模は小さいものの実証実験としては十分な環境でした。
気づき
ここでは、小規模なIP Closネットワークを運用していて得た気づきについて書いていきます。
スイッチ同士が疎結合
Spine-Leaf部分はメーカー独自のL2 Fabricと異なり、スイッチ同士はBGPでPeeringができれば問題ありません。
スイッチ本体やNOSなどが同一メーカーで構成する必要がありませんでした。 6
この点についてのメリットは非常に大きく、必要になるタイミングで最適なH/Wを選択・利用できるようになります。
MLAGの使用
サーバとスイッチの接続を冗長化するために、MLAGを使用して冗長化していました。
それまでサーバとスイッチは1対1で接続していたため、スイッチのメンテナンスが行いづらく運用上の課題を抱えていました。
特にスイッチのNOSバージョンが上がっていないと、サポートを受けられないため、
定期的にバージョンアップをする必要がありました。
MLAGでサーバとスイッチを冗長化したことにより、片方ずつメンテナンスを行え 実施タイミングについても、比較的自由に設定できるようになりました。
ただしMLAGにもデメリットが有ります。
ペアになっているスイッチのNOSが同じバージョンになっている必要があることや、ペアになるポートの設定も共通になっていることが必要になっています。
NOSが同じバージョンという点については、メジャーバージョンを上げる際に注意が必要で、
組み合わせのバージョンによっては両方を同時にアップグレードする必要がある場合もありました。
また、ポート設定についてはペアになっているポートの設定が同一でないとMLAGとして機能しなかったり、配線時に必ずサーバ同一の設定のポートペアに接続する必要がりました。
このようにSpine-Leafスイッチが疎結合になっていても、MLAGのペア同士になっているスイッチは様々な点で密結合になっていました。
またMLAGでのスイッチ冗長はL2になるため、意図的にトラフィックを迂回させることが難しく、 メンテナンスや故障時には若干のパケロスが発生してしまいます。
ネットワークの設計・構築
DC移設に伴い、ネットワークについてゼロから設計し直す機会ができました。
ここまでに触れた課題や、取り組んできたことなどを元にネットワークを再設計しました。
特にL2 Fabricを利用していくのが良いのか、IP Clos ネットワークを構築するほうが良いのかを
かなりの時間を使って検討しました。
そして、IP Clos ネットワークを採用し詳細に設計していくことにしました。
詳細設計の当初、サーバとLeafはMLAGを使用し構築することを検討していました。
ですが、最終的にサーバにもFRR 7を導入し、サーバ - Leaf間もBGPで接続するようにしました。
これは、MLAGによるデメリットを排除したかったことが主なところです。
特に、MLAGのペアになっているスイッチ同士が密結合になってしまっている点が懸念でした。
DC移設の数年後に発生するスイッチのリプレース時にサーバへの影響を抑えることが困難になってしまうことが、
容易に想像できていたためです。
IP Closネットワークにした理由
最終的にIP Clos ネットワークを採用した主な理由は以下の点です。
- ネットワークの拡張性
- BGPによるトラフィックコントロールのしやすさ
- ベンダーロックインの回避
ネットワークの拡張性
Spineを増設することで通信帯域の増速、また、Leafを増設することでサーバ収容ポートの増加がそれぞれ可能になるため、ネットワークの拡張性が向上します。
Spine、Leafとも増やすにあたってはBGP Peeringできれば増設が完了するというものになります。
BGPによるトラフィックコントロールのしやすさ
「graceful shutdown」を使うことにより、メンテナンス時トラフィックを中断せず迂回できるようになります。
また、ECMPにより複数の経路を使ってトラフィック分散させることも可能になります。
トラフィックコントロールは非常に重要で、スイッチのメンテナンス性を向上するのに役立っています。
ベンダーロックインの回避
ベンダーロックインの回避については、様々な意見があります。
単に ベンダーロックイン＝悪 という意図ではありません。
用途により最善なものを利用できる余地を残しておくための対策として、
特定ベンダーに依存しない構成を作っていくというのが必要だと考えていました。
そのため、L2 Fabricのようにベンダー独自の機能を利用することについては、見送ることにしました。
これらの理由から、L2 Fabricを使う今までの構成からIP Closネットワークへと 構成を大幅に変更していくことになりました。
困ったこと
一方でIP Closネットワークを採用したことで、困ったこともありました。
1つ目は、ファイアウォールやロードバランサーなどの配置・構成方法です。
2つ目は、BGPを利用できないサーバ以外の機器があり、問題になってしまいました。
具体的には、ストレージなどのアプライアンス製品です。
そのため、設計を進めていってもIP Closネットワークですべて丸く収まる、ということにはなりませんでした。
特にBGPが直接使えない機器については、MLAGを使うなど回避方法を用意する必要が出てきてしまいました。 そのため、一部分のみMLAG構成のスイッチを用意する必要がありました。
また、サーバもLeafとBGP接続するようにしたため、コンテナを利用する場合やOpenStackのような仮想マシンをホストするサーバについて、
さまざまな問題が発生しました。
サーバとLeafをL3で接続している環境での利用情報が少なく、トライアルアンドエラーで検証していく必要がありました。
そのため、さまざまな問題を解決するのに時間を要することになってしまいました。
さらに、IP Closネットワークにしても、IPアドレスの重複による問題が発生してしまいます。 この点については課題として現在も残ってしまっています。
まとめ
今回は、マイクロアドのDC移設でネットワークをIP Closネットワークに作り変えたことをまとめてみました。
このブログはL2ネットワークで構成することを否定しているわけではなく、
それぞれのメリット・デメリットを理解した上でIP Closネットワークを採用したという話です。
正直、今もIP Closネットワークにして良かったと思えることもあれば、
やはりL2 Fabricで構築しておいたほうが良かったかなと考えてしまうこともあります。
いずれにしても、DC移設によるネットワークの構築がゴールではなく、
これからも常に再構築を繰り返しながら、より良いネットワーク環境を目指していきたいです。
