BoF: Private CloudにおけるNetworkingについて

目的: Private CloudのNetworkingにおける共通の課題などを話し合う+何か方向を見つけたい+何か課題について別の会を開ければ(Private Cloud meetup)

対象

• DC Network

• Clos Network
• Multi-AZ
• DR

• NFV

• LB
• DNS
• NAT
• vRouter
• Firewall

• Overlay Networking

Minute

• Closについて

• HPCなどの分野ではClosの課題を感じている

• ただ、そのSolutionは今ない状態
• Clos(IP通信自体なのだが)はそもそもNon-Blockingが出来ない

• RoCEv2とかx over Ethernetに夢が詰め込まれてるが、本当に要求した事を検証環境を超えて実現出来ているのかは難しい
• Clos自体の次というのはまだ存在しない状態

• Multi-AZsについて

• Multi-AZとDRの組み合わせはSLAやサービスによって決まる

• DRが必要なサービスなのか

• TokyoがDownしている場合に必要なサービスなのか

• 許容される通信/サービス影響はどの程度なのか

• 再送程度で問題無いサービスなのか、パケットを1パケットも落とせないのか

• Multi-AZの設計はSLAやサービスによって決まる

• Multi-AZのAZ Downとは何なのか
• Multi-AZの中でどの程度のAZのDownを許容するのか

• 3AZ中の1AZは単一のDownだが、2AZのDownは複合障害と扱う場合
• 3AZ中の2AZがDownしても通信だけは落とせせないという場合

• Multi-AZで正しく冗長化出来ているかは、Chaos Engineeringなどを行って確認するしかない
• Multi-AZやChaos Engineeringを推し進めるにはある程度のトップダウンの判断が必要

Clos Networkについて

ClosのRouting

• BGPが多め

• Full L3のメリット

• 運用が楽になる
• /32で経路広報すればなんとかなる

• とはいえ大変

• Spineやらで経路数が大変
• Fibのentryに応じてnexthopのentryが増えるよね
• コンバージェンスの時間がかかる

• [うさぎ]：

• 部屋への経路を消してしまい、LBに5秒の通信断

• [ねこ]：複数のLBから同一IP広報ECMP

• 3層CLOSで収束に秒単位で時間がかかった
• 良いチップって良いよね
• FIBのインクリメンタルなUpdate(経路の差分更新)可能ができるものを選ぶ

• 規模が大きくなればなるほど大変

• BGP喋れないNodeが居る場合にはFull L3では難しいよね

• 結局両方やらないといけないパターンがあるよ

• UnderlayでOSPFを使っているパターン

Closの次ってある？

• Closのいいところ

• 安く増やせる
• いくらでも増やせるところ

• Dragonfly Topology?
• Closを作りたい時

• 一様なコンピュートリソースをばらまきたい

• CLOS の次を考えたい理由：

• Closであるhopがない場合を考える必要がある時
• HPC

• Closだとつまる可能性がある

• 上に乗ってくる物で決まるよね
• Link Stateなどを見る話が前はあったけど、最近はあまりない？BGPで十分
• GPU用のネットワークを作ってる

• Dragonflyっぽいのを検討している
• IPのネットワークだとNon-BlockingなNetworkが出来ないよね

• ECMPで作っても同じ経路を使うとは限らない

• フルバイセクションなNWが欲しい。現在はCLOS→Adaptive Rouitng

• NVIDIA製品において、ECMP経路を使って送る時、
  フローレット単位でキューの空き具合を見てうまいリンクを使う。

• Adaptive RouingはIBでも似た概念があった。DLBの技術。

• 疑問： GPUのクラスタは既存のNWとComputing向けのNWを分けたいのか？一緒にしたいのか？

• GPU-GPUの通信はIB or RoCEv2が使われる。

• RoCEのインフラには異なるNW要件がある。RDMA+TCPとかで大変になることがある。

• 学習のクラスタと推論のクラスタは一緒のクラスタなのか？

• 学習のスペックと推論のスペックの要求が違う

Multi-AZ化とスケーラビリティ

• Multi-AZってなんぞや？

• あるDCが壊れても、他のDCに影響を及ぼさないネットワーク構成
• [いぬ]自社局舎だと都内に２個三個とは作れない。結果同じ局舎になる。部屋の単位で火災や空調の故障など（影響無いように）分電盤UPSを分けている。
• AZの設計、概念はその会社が経験してきた障害を反映していそうなのかどうか

• SDN ControllerとAZ
• AZ：リージョンの中のAZ
• DRをちゃんとやればMulti-AZは不要という考えもあり得るのか？

• SLA次第。絶対停められない災害情報などはMulti-AZ+DRでやったりもしている。

• モバイルコアはDRをちゃんとやらないといけないのでMulti-AZまで必要かどうか
• グローバルにはMulti-AZは求められることが多い
• Blast radiusを小さくした方がよいということを考えるとMulti-AZにメリットがある
• VPNをAZまたいで1面でやる場合に障害範囲が広くなるんじゃないの？

• Yes
• ただ、AZ単位でDown出来るようにControllerを設計するべきだよね

• Connected carは遅延がとても低い前提でアプリケーション側が考えている傾向がある。Multi-AZによって遅延のことを考えなくて良くなればMulti-AZを選ぶが、遅延が大きく変わるとなると車側に処理を持って行く方向になる
• カオスエンジニアリング（テスト）やっていますか？

• ４回テストして大きな障害なかったのに、５回目で15分断など影響が出た。
• 試してあるAZにだけ設定が抜けていた、などの発見はあったのえやるのは効果ある。
• ユーザ数などが増えるとAZが機能しなくなるなどがあるので注意。

• 多重障害を考える？

• 組み合わせにあるので考えていない
• ３つのうち２つおちて１つだけ落ちない、というケースは無いのでは？

喋るアイデア案達

• Clos Networkについて
• Multi-AZ化とスケーラビリティ
• DRするべきサービスとそうでないサービス
• NFVにおけるD-Plane
• 仮想ホスト内のネットワーキング