Cisco Japan Blog
Share

ネットワークアーキテクチャ考 (8) 「Overlay と Underlay の連携」


2014年1月8日


という訳で、「SDN的な何か」の動機となる要求はネットワーク仮想化だった、ということです。また前回は、「仮想化への要請があったから SDN が活況なのか、SDN が活況だから仮想化がブームになったのか。共起関係から因果関係を帰結することはできないので、今はどちらなのかはわからない」と書きました。しかし、SDN と仮想化の共起に先立つ物として、クラウドの興隆があったことは疑いの余地はないでしょう。そしてそこに強く関係しているのが、設備投資から消費へ、という経済的動向です。

 

設備投資から消費へ

大分前のことですが、“Consumption Economics”[1]という本を読みました。英米で話題になったのでご存知の方も多いと思います。そこでは、ハイテク業界の購買モデルについて論じられています。—  これまでは購買側がリスクを取り、年月をかけて効果や効用を生み出して投資を回収していたが、これからの時代の購買者は、そのようなリスクはもう取らない。必要なときに必要な機能を、そこそこの(good enough)品質で使えれば良い。— これはしかし未来予測でも何でもなく、実際に現実に起こっていることである、と実感せざるを得ません。

必要なときに必要な機能をそこそこの品質で、という仮想化指向の傾向は、必ずしも絶対的なものではないと思います。第 3 回で述べた「アーキテクチャ変遷のパターン」でいうと、「仮想」と「物理」という対極概念間で行きつ戻りつする、「1.対極概念間の揺り戻し」に相当するものと考えられます。実際、ガートナーは「クラウド化の流れは近いうちに止まる」という発表をしました[2]。

しかし、少なくとも現時点では仮想化への要求は強く、また目的とする効果を得るために、設備投資するのではなく「必要な機能を使う」という考え方は、魅力的な発想です。技術者としては、どのようにこれを実装するか、というところに注力したいと思います。

 

How good is good enough?

「必要なときに必要なだけ」、というのは、技術的には、仮想化環境において、柔軟かつ迅速な CRUD(Create, Read, Update, Delete)を実現する、ということになるでしょう。ネットワークはそもそも、レイヤリングとパケット カプセル化という点で十分仮想的なのですが、決定的に欠如していたのは、オペレーターやアプリケーションから見たときの柔軟かつ迅速な CRUD でした。そこで現在は、CRUD の実現が我々に課された重点項目になっています。特に重要なのは、「何をどう制御するか」という抽象データモデルの定義です。

しかし「good enough」の方はさらに難しいです。どの程度 good だったらよいのしょうか。客観的な指標がない以上、提供側と使用側で期待値の乖離が生じる可能性があります。商用インターネットの初期の頃は、「Best effort(No Guarantee)」が画期的なものとして受け入れられました。しかし当時は、通信サービスは品質保証が当たり前であり、それに対するアンチテーゼだったから画期的だったのです。現代のクラウド サービスの使用形態は、然程品質を求めないものから、ミッションクリティカル性のあるものまで、多岐に渡るでしょう。「どの程度 good だったら good enough か」というのは、やはり必要や場合に応じて、都度サービスレベルを定義して合意する必要があるのだと思います。

 

Overlay と Underlay の連携

クラウド サービスで、SLA を提供できるか。まずコンピューティング リソースですが、要求されるサービス品質により、定義した閾値を越えたら新たなリソースを確保すること(Scale out)により、リソース使用率を一定以下に抑えることが可能です。これにより、平常時に比べピーク時の負荷が特に高いようなシステムに対しては、ハードウェアで構成されるシステムよりも高い SLA を提供することができると言えます。Availability に関しても、障害時のバックアップ システムを安価に準備できるという点で、ある程度は(ハードウェアを完全冗長するような厳密なレベルではないまでも、ハードウェア二重化に比べると低コストで)、可用性を向上させることができます。

しかしネットワークはどうでしょうか。仮想化環境においては Overlay Network が構成されますが、Overlay はその基盤となる Underlay Network を関知しません。Underlay Network の方も、上に流れる Overlay Traffic を関知しません。同一データセンター内、同一ファブリック内であれば、Underlay Network に一切ボトルネックをつくらないことによって、問題を回避することもできますが、一歩データセンターから外に出ると、そうはいきません。ネットワークの品質は距離、トポロジー(経由ホップ数)、使用可能帯域といったものに左右されますし、もっと重要なこととして、リソースが無限でない限り、至る所で輻輳も起こりえます。Overlay と Underlay が何らかの方法により連携できなければ、Overlay Network の SLA を提供することはできません。

そこで、「抽象データモデル定義」に続くもう一点目の重点項目は、「Overlay と Underlay の連携」です。方法としては QoS mapping、Packet Inspection なども考えられますが、より汎用的かつ無理矢理感のない(?!)方法として注目したいのがメタデータ(*)の使用です。この場合、あるメタデータを使う制御に参加するシステムは、そのメタデータを理解する必要がありますが、その条件をクリアすれば、かなり柔軟な制御を、マルチベンダー、マルチプラットフォーム、マルチプロバイダー、といった環境においても、実現可能になります。

(*)データ特性を記述するデータ(情報)。ヘッダとして表現されることが多い。

そのようななか、IETF においてもメタデータの標準化活動が始まっています。ひとつはつい先日(2013年12月21日)発足した SFC(Service Function Chaining) ワーキング グループ。ここでは Service Chain を実現する方式、および Service Chain を記述するメタデータ(Service Header)について標準化される予定です。もうひとつは、こちらはまだ BoF 状態でワーキング グループ発足には至っていませんが、AEON(Application Enabled Open Networking)。ここでは、アプリケーションのフロー特性を表現するためのメタデータについて議論されます。

先日シスコが発表した新たなデータセンター アーキテクチャである ACI(Application Centric Networking, Insieme)も、vxlan header を拡張してメタデータを運び、Overlay と Underlay の連携を実現します。先ほど、同一データセンター内であれば問題を回避できると書きましたが、そうはいっても、Overlay と Underlay が連携し、アプリケーション毎の latency 情報や、経由ホップ、リソース使用状況などが分かれば、さらに高度な Networking ができる可能性が広がります。

 

[1] “Consumption Economics : The New Rules of Tech”, J.B.Wood et al, Point B, Inc. November 2011

[2] http://itpro.nikkeibp.co.jp/article/NEWS/20130425/473703/

 

Tags:
コメントを書く