こんにちは、Amebaでネットワーク エンジニアをしている篠原です。
今日は現在Amebaで取り組んでいるネットワークのSDN(Software
Defined Network)について少し解説出来ればと思っております。
かなりインフラよりで抽象的な話になりますが宜しくお願いします。
まずは今私が取り組んでおりますSDNに関してはまだ正式にメーカ
からリリースはされていないのですがC社(わかってしまうかと思いま
すが)様の新SDN製品を採用してリリースする予定です。
からリリースはされていないのですがC社(わかってしまうかと思いま
すが)様の新SDN製品を採用してリリースする予定です。
こちらは今年2月からアメリカでトレーニングを受け、ようやく現在実機
でTest段階といったところまでこぎつけた感じです。
でTest段階といったところまでこぎつけた感じです。
ところで SDNって何が出来るのって？ 良く言われます。
一言でいうと 私は なんでも出来るネットワーク かなと思っております。
SDNというと自動化とか抽象化とか 様々な表現で表されますが中身の
コンセプトの部分は単純で今までハードウェア個別で行ってきた機能、
例えばSwiting,Routing,Load Balance, Firewall 等を一つのネットワーク
機器(実際には複数の同一タイプの機器)で実装してしまおうという感じです。
ちょっと簡単ですが図を書いてみました。あくまで一例ですが
図1 今までのネットワーク
図2 SDN
SDNってシンプルですよね。
SDNではSpine(幹)とLeaf(枝)の2つのタイプのネットワーク機器で組み合わ
さったFabric構成(網目の様なネットワーク)で構築する事が一般的です。
さったFabric構成(網目の様なネットワーク)で構築する事が一般的です。
ではなぜSpineとLeafと呼ばれる2つのネットワーク機器で様々なネットワ
ーク機能が提供出来るかというとそれを実現させているのがSDN Controller
という制御機器になります。
ーク機能が提供出来るかというとそれを実現させているのがSDN Controller
という制御機器になります。
実際にSpineとLeafはこれまでのネットワークで利用してきたL3 Switchや
L2 Switchと見た目は何も変わらないただのSwitchです。
L2 Switchと見た目は何も変わらないただのSwitchです。
実際SDN Controllerがなければ一般的なSwitchとして動作する機器が大半です。
SDN ControllerはServer上に実装されたSoftwareでこちらがSpineとLeafに対して
ネットワーク系の指令 実際にはどの送信元IP(MAC)のパケットをどの宛先IP(MAC)
に転送させるにはどのSwitchのどのPortから出力させればいいかという様な制御を
行っています。一般的なルーティングですね。
ネットワーク系の指令 実際にはどの送信元IP(MAC)のパケットをどの宛先IP(MAC)
に転送させるにはどのSwitchのどのPortから出力させればいいかという様な制御を
行っています。一般的なルーティングですね。
今までのネットワーク機器ではそのような各転送パケットを制御する部分(Control Plane)、
と実際にDataを転送する部分(Data Plane)の2つの役割を各それぞれの機器が実装して
おりました。
と実際にDataを転送する部分(Data Plane)の2つの役割を各それぞれの機器が実装して
おりました。
それが一括集中制御される事により各機器のリソース消費の低減や各機器個別の設定
が必要なくなるといった大きなメリットを享受できます。
が必要なくなるといった大きなメリットを享受できます。
また今まで何階層にもなっていたネットワークが2層のネットワークになる事によりパケット
を転送する際のレイテンシ(転送遅延)の低減も期待出来ます。
を転送する際のレイテンシ(転送遅延)の低減も期待出来ます。
機器の全体的な数も減らす事が出来る為故障率の低減にも寄与出来ます。
実際にはもっと複雑な機能も提供可能です。
何千、何万のHost,VMを収容するData Centerネットワークではネットワークの機器だけ
でも数百台規模となり運用が非常に大変です。
でも数百台規模となり運用が非常に大変です。
例えば新しいTenant上にVMを1つ作成する場合ネットワーク作業としては
0. Cloud Controller上でVMの作成
1. L3 SwitchにVRF(論理パーティション)の作成
2. L3 SwitchにVlanの作成
3. L3 SwitchのVlanにIpを設定
4. L2 SwtichにVlanの設定
5. Load BalancerのPoolにVMを追加
6. FirewallにLoad balancerのVS Ipの開放
といった様に6つの作業が有ります。(あくまでも1例です)
そこでSDN Controllerを使い各機器を一括で制御した場合どうなるかというと
0. Cloud Controller上でVMの作成
1. SDN Controllerから各Spine,Leaf,LB,FWに対してVRF(論理パーティション)の作成、
Vlan作成、VlanへのIP採番、Load BalancerのPoolにVS追加、FirewallにVS IP追加
Vlan作成、VlanへのIP採番、Load BalancerのPoolにVS追加、FirewallにVS IP追加
SDN ControllerとCloud Controllerとを連携させる事でここまで作業がシンプルになります。
それはSDN Controller上ではAPIを標準で実装しているものが大半の為
OpenStackの様なCloud Controllerからネットワークの制御が容易に行える為です。
各メーカからのプラグインも多数用意されております。
各メーカからのプラグインも多数用意されております。
私はこれがSDNの最大のメリットと思っております。
実際には我々ネットワーク エンジニアの仕事ってどうなるんだろうとか思ったりしますが。。
まあそれはさておき話をCloud Controller連携に戻すと
例えばOpenStack連携ですと上述の様にOpenStack上で作成したTenant(論理的に分割
されたNetowkr,VM郡)をSDN Controller側のAPIに対してネットワークの変更をすぐに
実施させる事が可能になります。
されたNetowkr,VM郡)をSDN Controller側のAPIに対してネットワークの変更をすぐに
実施させる事が可能になります。
そうすればVM作成と同時にそのVMに対して接続可能なネットワークが提供される訳です。
これっていかに早くサービスを提供するかが命のアプリケーションエンジニアからする
とインフラを素早く提供出来る事はとっても大きなメリットだと思います。
とインフラを素早く提供出来る事はとっても大きなメリットだと思います。
ビジネスインパクトとしても大きな事でタイミングをいかに早く出来るかに
よって流行る、流行らないも左右されますのですごく大切な要素かと思っ
ております。
ております。
では逆にSDNのデメリットというと
1. まだ過渡期のネットワーク技術の為安定性に乏しい
2. 大規模なネットワークの実績が少ない
3. まだまだ足りない機能が多い
4. 標準化が進んでいない
などなど結構私が今感じているだけでも色々有ります。
どれも新しい技術、製品で有れば必ずと言っていい程あり得る話なので
この辺は覚悟を持って取り組まないといけないかと思っております。
但し後ろを向いても仕方が無いのでむしろメリットを最大限に活かす事の方が
チャレンジしがいも有りエンジニア冥利に尽きると思って取り組む様にしております。
チャレンジしがいも有りエンジニア冥利に尽きると思って取り組む様にしております。
現在もSDNのTestを色々と行っておりますが例えばIPV6等の特殊な機能に関しては
現在のSDNではまだまだ機能実装そのものがされて無かったり、一部機能が実装さ
れてなかったりと色々障壁は確かに有ります。
現在のSDNではまだまだ機能実装そのものがされて無かったり、一部機能が実装さ
れてなかったりと色々障壁は確かに有ります。
但しそのあたりもレガシーネットワークと組み合わせて使用したりして補完すればクリア
出来る課題です。後でSDNに組み込むのは大変ですが。。
出来る課題です。後でSDNに組み込むのは大変ですが。。
ここまでは少しSDNの抽象的な話を書いてきましたがここからは少し具体的に何がどう
今までのレガシーネットワークと異なるかを説明したいと思います。
今までのレガシーネットワークと異なるかを説明したいと思います。
図3 一般的なHost間(いわゆる East,Westトラフィックの流れ)
Host AからHost Bに対してパケットを送信した場合
(Host AとBは別Subnet)
通常 Host Aが接続しているTOR Switchから上流のL2 Switch
を経由してL3 SwitchでRoutingを行い再度 L2 Switchを経由してHost B
が接続されている TOR Switchへと転送されます。
一見自然な動作に見えますが Routingという機能をL3 Switchで提供している限り必ず
そこを経由する必要があります。
そこを経由する必要があります。
小規模なネットワークですとそれ程Trafficの量も気になりませんが大規模になるとこの
小さなTrafficも無視出来ません。
小さなTrafficも無視出来ません。
ネットワークの世界では DHCPやArp、その他制御Packetが常時ネットワークを流れて
いる為ですね。
いる為ですね。
ではSDNの場合のパケットの流れを見てみましょう。
図4 SDNでのRouting
図4 SDNでのRouting
1階層少ないだけでかなりすっきりしました。
更に L3 Switchの機能は各Leafで実装している為実は Host AからDefault Gatewayに
Pingを行った場合返答するのは Host Aが接続しているLeafになります。
Pingを行った場合返答するのは Host Aが接続しているLeafになります。
SDNで作ったネットワークでは無駄なパケットは他に流れないメリットが有ります。
特に大規模のネットワークの場合この恩恵は機器のサイジングに影響してくる為
コストメリットも出てきます。
コストメリットも出てきます。
SDNはそういう点でも非常に理想的と言えますね。
レガシーネットワークの場合 例えば実際の帯域が10Gbps確保されていても有効活用が
上述の様に難しい為 どうしてもTrafficの偏りが発生して 平均しても10%未満の1Gbps程度
しか利用されないネットワークが多いです。
上述の様に難しい為 どうしてもTrafficの偏りが発生して 平均しても10%未満の1Gbps程度
しか利用されないネットワークが多いです。
SDNでは交通整理が末端(Leaf)で行われる為比較的上流の帯域を有効活用出来ます。
具体的にいうと上流の帯域をそれ程用意せず複数にトラフィックを分散させて効率よく
ネットワークを運用する事が可能です。
ネットワークを運用する事が可能です。
終わりに
まだまだSDNには未成熟な部分も多いですが今後クラウドを含めたネットワークの主流
となってくる事は間違いないと思いますので今後もSDNには期待を膨らませたいと思います。
となってくる事は間違いないと思いますので今後もSDNには期待を膨らませたいと思います。
また今回は我々のSDNの機能としてはまだ実装しておりませんが Load BalancerやFirewallもSDNの機能の一部として実装して行きたいと思っております。
そこまで実装して初めて Software Defined Networkと言えるのではと思います。
AmebaとしてもネットワークをSDN化する事により大きなメリットが出ると考え今Testを行っております。
ネットワークのPortability化 を目指しロケーションを意識せずに利用出来るネットワークを目指し今後も構築を進めて行きたいと思います。
まだまだ過渡期の技術では有りますが今後標準化されていく事は間違いないと思っておりますのでSDNとネットワーク エンジニアに今後ますます注目していって頂ければと思います。