NFV

2017 年のエンタープライズ ネットワークのトレンド

2016 年は特に画期的なイノベーションを経験した年でした。業界ではデジタル変革において大きな進歩を遂げ、シスコはネットワークに関するさまざまなイノベーションをリードし、多くの賞を獲得しました。

続きを読む

Cisco SDN ポータルサイトを公開しました！

今や ICT に欠かせないキーワードとなっている SDN（Software-Defined Networking）。SDN に注力する企業も多く、さまざまなソリューションが提供されています。このたび、シスコの SDN のビジョンや取り組みをまとめた SDN ポータルサイトを公開しました。 巷では、「シスコは SDN に積極的ではない」「シスコは結局ベンダーロックインだ」「他社の OpenFlow の方が進んでいる」など、シスコの取り組みにはネガティブな印象もあると聞いています。 しかし、シスコでは「SDN」はあくまで「目的」を実現するための「手段」であり、SDN を導入すること自体が目的でない、ということを改めてお伝えしたいと思っています。SDN を導入することがゴールになってしまうと、単なる機器の置き換えでしかありませんし、逆にコスト上昇にもつながりかねません。その SDN で何をするのか、何をしたいのか、どうなりたいか、をお客さまと共に考え、実績のある豊富なソリューションで実現する、それがシスコの目指すところだと思っています。

続きを読む

ネットワーク アーキテクチャ考 (17)  「分解 (De-Aggregation)!」

前回のエントリーでは「パッケージング」について書きました。これまでモジュラー性やオープン性を最重要視して来たが、ある程度の「パッケージング」概念を取り入れることにより、性能のチューニングや、組合せ発散による現実的な問題（検証工数など）に対処する、というアーキテクチャ選択肢もあり得る、という主旨でした。この方針はさらに推進され、Intel 社との NIC、NSH などにおける連携[*1]、Redhat 社、Canonical 社などとの Hypervisor、Openstack Distribution におけるの連携などが推進されて行くことになります。 今回はしかし、この「パッケージング」の対極概念である「分解（De-Aggregation）」について書きます。分解というのは大変強力な概念です。スケーラビリティ、保守性、障害箇所の特定や切り離し、継続性など、多くのことがモジュラに分解することによって解決することは、私たちも日々のエンジニアリングの現場で感じていることです。ところで「分解」の概念が明文化は、何と 17 世紀のデカルトにまで遡ります。デカルトは「方法序説」第 2 部で次の準則を挙げています[*2]。 私が明証的に真理であると認めるものでなければ、いかなる事柄でもこれを真なりとして認めないこと 検討しようとする難問をよりよく理解するために、多数の小部分に分割すること もっとも単純なものからもっとも複雑なものの認識へと至り、先後のない事物の間に秩序を仮定すること 最後に完全な列挙と、広範な再検討をすること 1 は明証・実証の重要性、2-4

続きを読む

ネットワーク アーキテクチャ考 (16) 「モジュラー性・オープン性とパッケージング、そしてダイクストラ」

これまで私は至るところで、「仮想化アーキテクチャでは、モジュラー性・オープン性が重要。垂直統合してしまったら意味が無い。」と述べてきました。 今でもその考えは変わっていません。コモディティ化した汎用ハードウェアと仮想化アーキテクチャで実現するソフトウェア中心のシステムは、新たなサービスの柔軟かつ迅速な展開、小規模スタートや実験的展開、顧客の細かい要求に応じたテーラーメイド サービスなどに、大きな価値を発揮します。これらは、これまで周到な設備計画が必要だったハードウェア中心のシステムでは実現できなかったことです。しかし、その機能の性能最適化をしたければ、目的に特化したハードウェア システムの方が、コスト、スペース、電力等、あらゆる面で適しています。既に機能が固定化されているような既存サービスの置き換えや、大容量高性能を目指すシステムには、仮想化アーキテクチャは勧められません。 しかし、しかし…。現実というものは、そんなに簡単に割り切れるものでもありません。「仮想化システムだから性能出なくても仕方ない。性能よりも重視すべきはモジュラー性とオープン性、云々かんぬん…」とか言ったら、お客様は間違いなく離れてしまいます。 では、オープン性やモジュラー性を保ちながら性能を最適化することは可能なのでしょうか。いや、すみません、無理です。現実問題到底無理です。どんなハードウェアや NIC（Network Interface Card）を使おうが、どんな HostOS/Hypervisor を使おうが、どんな Virtual Switch（OVS, Linux-bridge, VPP*1、Snabbswitch*2、DPDK-OVS*3など）を使おうが、ある一定の性能値を保証する、なんてことは、できる訳ありません。 これまでシスコとしては、まずは User Space の Virtual

続きを読む

ネットワーク アーキテクチャ考 (15) 「SDN/NFV これまでの振り返りとこれから」

SDN/NFVは、アーキテクチャ変遷の一つの可能性です。通信事業者は、それまでのハードウェアを中心とした基盤設備的なアーキテクチャから、ソフトウェアを中心としたより柔軟で迅速なアーキテクチャにシフトしようとしています。そのため、「アーキテクチャ変遷」を大きなテーマの一つとしているこのBlogでも、SDNやNFVについてのいくつかの、総論的な話題を取り上げてきました。 しかしこの辺でそろそろ一旦振り返り、次のステップに踏み出したいと思います。そこで今回は、振り返りのきっかけになったことと、今後考察して行きたいことを書きます。 Network Programmabilityと宣言的プログラミング 対立する価値の統合 White Box SwitchとForwardingのコモディティ化 Traffic Modelの変化とこれからの可能性 1. Network Programmabilityと宣言的プログラミング 振り返りのきっかけになったことの一つは、ネットワークプログラマビリティ勉強会[1]です。ここでは、「実際にやってみたレポート」から、理論的なことまで、「ネットワークプログラマビリティ」に関するあらゆることが、ゆるやかに、そして和気あいあいと議論されています。私も若手に混じってスタッフをさせて戴いており、先日は発表の機会も戴いたので、「宣言的(Declarative) vs 命令的(Imperative)か」というプログラミングパラダイム議論を、ネットワークプログラマビリティに適用させた発表をさせて戴きました[2]。現時点ではまだ試論の域を出ていないのですが、今後もっと考察を重ねて行きたいと考えています。 プログラマビリティや自動化の必要性は論を俟たないとして、これからは、それをどう行うか、の議論に注力する必要があると感じています。システムは放っておくとどんどん複雑化します。ソフトウェア中心のシステムであれば尚更です。この状況で、制御を記述する方法もどんどん複雑化してしまったら、手に負えないシステムになりかねません。ネットワークプログラマビリティと言ってもひたすらコーディングすればよい訳ではなく、数学的、論理学的理論に基づいたコーディングスタイルが必須となると考えています。特にネットワークのような複数の要素が接続される分散システムの場合は、手許にリソースがあるシステムのプログラミングよりも、より不確定性が高いのです。 2. 対立する価値の統合 もう一つのきっかけは、先日Ciscoのセミナーで実施させて戴いたパネルディスカッション[3]です。NTTコミュニケーションズ、KDDI、Softbankという大手通信事業者から第一線のアーキテクトにご登壇戴き、NFVを中心としたアーキテクチャの現状と今後に関する考察を、率直に議論しました。この時の内容は、InSPireという弊社のWeb

続きを読む

ネットワーク アーキテクチャ考 (14) 「『仮想化』は何のため（再び）、そして変革へ」

前回、前々回と、仮想化における課題を書きました。しかし、これらはまだ初期段階の課題です。現時点での仮想化、少なくとも SP（サービスプロバイダー）領域で NFV と呼んでいるものは、従来のアーキテクチャで実装した機能をほぼそのまま VM でエミュレートしているに過ぎません。仮想化ならではの恩恵を活かすためには、現在のプロセス モジュール構成でよいのか、そのまま VM に載せるのではなくコンテナとして実装した方が良いのではないか、プログラミング パラダイムやコーディング手法自体を見直した方がよいのではないか、などのことを、じっくり吟味する必要があります。 もう一つ。「仮想化の目的はコスト削減」と言う声を多く聞きますが、これには異を唱えたい。もちろん仮想化によって、初期投資を削減することはできます。しかし、ある程度のキャパシティ、性能を実現しようとすると、仮想化だけではコスト削減にはなりません。むしろ、仮想化のオーバーヘッドがある分、電源容量なども増大する可能性があります。さらに、オープンソースを含めた、より多様で複雑なインテグレーションが必要となるため、そのままではコストは増大する傾向にあります。 これらのコスト上昇リスクを抑えるためには、入念な検討が必要です。一方、仮想化の目的や大義名分をコスト削減だけに置いてしまうと、仮想化プロジェクトの予算は削られ、限られたリソースで無理難題を強いられることになりますから、プロジェクトは成功するどころか疲弊して迷走します。せっかくの変革の契機なのに、これでは本末転倒です。既存の価値のままコスト削減を追求するのではなく、新たな価値を追求する方が良いと思います。 では仮想化の価値とは一体何でしょうか。以前「仮想化は何のため」というエントリーで、次の 2つを挙げました。 必要なときに必要なサービスやリソースを、迅速にそして自動的に提供することを可能にすること あるオブジェクトを仮想化エンティティへと断片化することにより、並列分散処理を行うこと しかし、何よりもまず重要なのは、これら仮想化アーキテクチャのメリットを十分に活かせるような、これまでの技術実装やアーキテクチャの見直し、サービスの迅速な展開を実現するアジャイル体制への変革なのではないかと、最近は痛感しています。これは言う程簡単なことではありません。現在の構造にもそれを必要として来た理由がある訳ですから。 このことを同僚と議論していたら、最近彼が出たアジャイル基礎のセミナーで、Kotter の 8つのステップが取り上げられた、と話してくれました。Kotterの『Leading

続きを読む

ネットワーク アーキテクチャ考 (13) 「仮想化：性能面の課題」

前回の投稿では、仮想化における運用面の課題を書きました。今回は、もう 1 つの大きな課題である性能面を検討します。 1)  仮想化環境における転送性能最適化について 仮想化アーキテクチャのインフラストラクチャとなるサーバは CPU に特化したハードウェアであるため、当然、NPU（Network Processing Unit）や ASIC（Application Specific Integrated Circuit）に比べると転送性能は低いです。さらに、ハードウェアで行う割り込みや I/O などの各種処理を仮想化レイヤにてエミュレーションする必要があるため、オーバヘッドが大きくなります。 これまで、データセンターの仮想化においては、転送性能よりも柔軟性やスケーリングといった効用の方が大きく上廻っていたため、あまり転送性能の最適化は問題視されてこなかったのだと思います。しかし、通信事業者の場合、ネットワークサービスの提供に必要な品質と性能を安定的に供給する必要があるため、やはり転送性能を重視することになります。 そのため、転送性能最適化の方法論が必要になる訳ですが、仮想化アーキテクチャにおいてどのように性能を最適化させるか、という問題は、仮想化アーキテクチャの理念にも関わります。 サーバ ハードウェア、ハイパーバイザ、Guest

続きを読む

ネットワーク アーキテクチャ考 (12) 「仮想化：運用面の課題」

仮想化は目的ではなく、アーキテクチャ変遷における一つの通過点と捉えています。とはいえ、ネットワーク機能の仮想化により、下記のようなメリットを実現できる可能性があります。 コスト削減と技術革新の高速化 サービス開発サイクルの短縮化 オープン性とエコシステムの促進 柔軟なスケーリング 障害の限局化とシステムとしての高可用性 一方、仮想化によるアーキテクチャ変化は、新たな課題をもたらします。今回は、運用面の課題を書きます。 1) 状態監視方式について まず、現在確立している状態監視や障害箇所特定などの運用管理方式を、仮想化アーキテクチャに適応させる必要があります。これまでは、どのネットワーク機能がどのハードウェアで動作しているかは明白でしたが、仮想化環境においては、仮想化インスタンスとハードウェアなどのインフラとの関係が分離されています。さらに、システムの負荷状況に応じて、VNF（Virtual Network Function）を構成するコンポーネントを増加させたり、または VNF 自体を増やしたりすることが考えられますが、その場合、VNF が接続されている全体のネットワークトポロジーも追随して変更される可能性がある。このため、システムに柔軟性や弾力性を与えると同時に、それをダイナミックに運用管理可能とするオーケストレーション システムが重要になります。 2) ネットワーク運用との役割分担、または融合 次に、ネットワーク運用との役割分担の問題があります。これまでは、ネットワーク運用と、サーバやアプリケーション ソフトウェア運用との間に明確な責任分解点がありましたが、仮想化環境においては、仮想化インスタンス間の通信が、同一サーバ内・同一ハイパー

続きを読む

ネットワーク アーキテクチャ考 (11) 「『NFV』- 逆説に本質が宿る」

最近の私は「仮想化」には嵌まっています。以前「SDN と仮想化」というエントリーで、「ネットワーク アーキテクチャが変遷する際には必ず仮想化を伴っている」という観測を書きました。あれから 9ヶ月が経過していますが、日々その裏付け事例が増えていると感じています。その時も書いたように、共起関係からは因果関係を帰結できないので、アーキテクチャ変遷が仮想化を要請するのか、仮想化がアーキテクチャ変遷を喚起するのかは分かりませんが、「ネットワーク サービスの仮想化」という側面から見ると、後者の様相が強いかもしれないです。 例えば、相変わらず定義が定まらない“SDN”ですが、「（VMなど）仮想インスタンス間を接続するネットワーキング手法」と考えると、非常にすっきりします。ad hoc に生成され移動する仮想インスタンスのために、いちいちコマンドラインで「機器の設定」なんてやってられないのは明らかです。勿論、ネットワークを使うのは仮想インスタンスだけではないけれども、少なくとも SDN ブームの出発点として仮想化を位置づけると、SDN の意義がクリアになります。 「仮想」という逆説 仮想化の意義については前回も書いたのですが、そもそも、なぜ仮想化がそんなにも自分をわくわくさせるのか、について考えてみました。そして思い当たったのが、「仮想とは大いなる逆説である」ということです。通常、仮想化は「非-現実」とか「非-物理的なもの」とかと捉えられますが、virtual の語源を繙くとラテン語の virtualis。何と「美徳」の virtue と同じ語源で、exellence（卓越）、 potency（力）、efficacy（有効性）を表すとのこと[1]。「現実」ではないものが、実は「力」や「有効性」を持っている、というのですから、何と言う逆説！ 確かに、He/She is

続きを読む

ネットワーク アーキテクチャ考 (10) 「『仮想化』は何のため」

仮想化アーキテクチャの周辺は日々進化していて、落ち着く暇がありません。この春 Cisco は、通信事業者向けの、仮想化環境における Orchestration Layer アーキテクチャとして、ESP（Evolved Service Platform）を発表しました。しかしこれは製品でもなくソリューションでもなく、概念的フレームワークであるため、現場は扱いに困ります。この概念的フレームワーク、深く読めば、ACI（Application Centric Infrastructure）や InterCloud などとも共通する遠大な構想に裏付けられているのですが、いざ、このフレームワークを見せられても、それだけでは何も言っていない。具体的な解を提供しないといけないときに、遠大な構想などを持ち出したら、お客様からは話をはぐらかしているように捉えられてしまいます。この辺が最近感じている難しさであり、もどかしさであります。なお、多少は具体的な解の例として、日経コミュニケーション『SDN のすべて』特集に、Segment Routing について記事を執筆させていただきました。これは SDN といっても、主に WAN（広域ネットワーク）を対象とした「シンプル化」への一つの解になりますが、ご覧いただけたら嬉しいです。 仮想化の２つの意義 仮想化の意義は、突き詰めて言えば次の２つになると考えます。まず、

続きを読む