software defined cloud networking · software defined cloud networking...

Software Defined Cloud Networking

Aristaホワイトペーパー

1

はじめに

1980年代の登場以来、イーサネット・ネットワークは劇的な変化を続け、数世代にわたる進化を経て今日の姿に

なりました。 10Gbpsのラインレート・スイッチングが標準的となった現在では、ネットワークは桁違いに高速

となっています。また、マイクロ秒未満のスイッチ・レイテンシー、トラフィックの規模拡張、冗長インターフ

ェイスによるロード・バランシングにも対応しています。さらには、状態駆動型のアーキテクチャやオープンな

インターフェイスによって管理の複雑さも軽減されました。高度なセキュリティを備えたグローバル規模のイン

ターフェイスで数百のスイッチを管理できます。

エンタープライズ用途のスイッチングとルーティングの機能開発に投入された工数は数千人年に及びますが、各

ベンダーが独自のソフトウェア・スタックを開発したことから、パケット転送のロジックや、毎秒数百万パケッ

トのスイッチングに対応するハードウェアの内部がわからない、クローズなシステムとなりました。

Software Defined Cloud Networking（SDCN）とは、転送ロジックやスイッチ本体とは切り分けられた外部のコン

トローラを使ってネットワーク・デバイスをプログラムし、トラフィックのフローの変化や拡張を制御するとい

う形態を表すときによく使われる用語です。

SDCN は標準の API で実現でき、さまざまなハードウェアやソフトウェア・アーキテクチャでサポートが予定されています。

SDCNの必要性

SDCNが主に必要となるのは、スイッチやルーターの標準の動作では固有のトラフィック・フローやアプリケーシ

ョン独自のフローに合わせた最適化が難しい場合です。さらに、クラウドのようにサービスを大幅に抽象化して

一元管理することが必要な場面では、インフラのすべての構成要素をサブスクライバー・レベルでいくつかのプ

ログラム可能なサービスに集約できます。

図 1：コントローラを通じた SDCN



2

たとえば、データセンターやクラウド事業者の場合で考えてみましょう。データセンターでは、サーバーとスイ

ッチの物理的な構成と接続は事業者自身が把握しています。多くの場合、各サーバーのMACアドレス、物理的な

場所（フロア、列、ラックの情報など）、割り当てたIPアドレス、スイッチへの物理接続と論理接続、設定ファ

イルなどの情報を、資産管理と設定のためのデータベース・アプリケーションに取り込んで管理しています。こ

のデータベース情報は、問題点の特定や停止/修正の作業を効率よく行ううえで非常に重要です。 MACアドレス

の学習やエージング、ARPの更新などによって情報が変化したときには、運用チームがデータベースを随時更新

しなくてはなりません。ここには人間の作業が介在するため、最新かつ正確な状態に維持しておくことは非常に

困難です。

この場合、MACアドレスの学習、エージング、ARPの更新を把握したり、情報の変化をデータベースに反映した

りといったことで事業者が煩わされるのは好ましいことではありません。デバイス間の経路は事前にわかってお

り、スイッチとは別個に事業者が前もってプログラムできれば、ネットワークの構成とトラブルシューティング

が非常に楽になります。転送テーブルの変化が大幅に減り、資産管理やデータベースのアプリケーションと同期

の必要性も軽減されるからです。現状では、データセンター向けスイッチ製品の多くには、転送経路を外部か

らプログラムで制御できる機能が備わっていません。中身のわからないブラック・ボックスとしてベンダーが支

配しており、事前に設定された転送経路のソフトウェアとハードウェアのアルゴリズムを使用しています。こう

したケースでは、外部のコントローラの利用によってメリットが得られるのは明らかです。

同様の用途はほかにも考えられます。ネットワーク・タップのトラフィック・エンジニアリング、レイヤ3ネッ

トワーク上にレイヤ2トラフィックを乗せるための特別なヘッダーの付加、コンテンツに応じたトラフィックの

分類、輻輳の監視、LAG（Link Aggregation）やECMP（Equal Cost Multi-Pathing）グループでのハッシュの効率化

などです。プログラム可能なスイッチを外部のコントローラから制御すれば、こうしたケースの多くに対応でき

ます。

分散制御と一元制御

SDCNの考え方は、ネットワーク界の次なる大波との見方が支配的です。しかし、注意の目も忘れてはいけませ

ん。スイッチやルーターが現在の姿となり、コントローラの機能の多くをスイッチの各ノードに分散して組み込

む形で進化してきたのは、さまざまな理由や経緯があってのことだからです。現在のネットワークは、LACP、

OSPF、BGPなどのプロトコルを利用して、ビジネス・クリティカル・アプリケーションの多種多様なニーズに対

応できるように設計されています。しかも、各ネットワーク・デバイスが互いに独立して動作する形態では、耐

障害性が高まり、ヒットレス・フェイルオーバーによって24時間365日の稼働を実現できます。現在のデータセ

ンターの大半は、こうした機能に大きく依存しています。コントローラを一元化するとなると、こうした耐障害

性のニーズに対応するために、さらなる進化が必要です。場合によっては、入念に設計したアクティブ/アクテ

ィブまたはアクティブ/スタンバイの外部コントローラを利用しても、分散型のネットワーク転送では可能なフェ

イルオーバーやリアルタイムの輻輳対応が困難になる可能性があります。



3

分散制御のメリット一元制御のメリット

• 耐障害性のあるネットワーク - 各デバイスが独立

• 標準プロトコルによるL2/L3対応

• ハードウェア・ベースの学習と転送

• 知識や経験が豊富なトラブルシューティング・ツールの利用

• 個別のフローの最適化

• 基盤となるインフラのプロトコルやアドレス方式からアプリケーションを切り分けて抽象化

• 新しいプロトコルを考案してタイム・ラグなしでスイッチやルーターに直接実装

• 独自の転送を排除して管理を一元化

• 超大規模な設計が可能

両方の長所の組み合わせ

大規模にせよ小規模にせよ、クラウドを構築するすべてのIT組織にとって、ネットワーク処理はきわめて重要です。

したがって、トラフィック・フローの最適化を実現するのと引き換えに耐障害性を犠牲にするという選択肢は考えら

れません。多くの企業に適しているのは、標準的なプロトコルによる各ネットワーク・レイヤでの処理を利用しつつ、

特定の用途に関してはSDCNを採用して処理を強化するという方法です。 SDCNの主な用途については後述します。

SDCN対応のスイッチと非対応のスイッチ

Linuxカーネル

PowerEdge650

コントローラ

Arista EOS API サポートと Arista EOS アーキテクチャ SDCN の基盤となるものです



4

スイッチはどれも同じというわけではありません。ローカルでの制御と、外部コントローラのプログラムによる

転送ロジックを同時にサポートするためには、理路整然としたアーキテクチャを備えたネットワーク・オペレー

ティング・システム（NOS）が必要です。多くのシステムは、こうした設計原則にのっとっていません。プロセ

スのやり取りは一般にメッセージの受け渡しによって行います。内部と外部の複数のシステムとやり取りする場

合には、多くのバグはこのやり取りの中で発生します。ここで必要なやり取りが原因となって、こうしたシステ

ムのスケーラビリティが損なわれていました。

一方、こうしたやり取りを最初から考慮に入れて設計されたオペレーティング・システムなら、必要な機能をサ

ポートできます。拡張性の高いプラットフォームを構築するためには、システムのすべての状態の読み書きに使

用するデータベースが必要です。 APIを通じたSDCNコントローラとのバインディングも含めて、すべてのプロセ

スがこのデータベースを通じてやり取りします。また、イベントごとの通知のしくみがあれば、プロセス間の依

存を排除する形でモデルを拡張できます。ネットワーク処理用に設計されたオペレーティング・システムの多く

は、メッセージ・バスを備えたデータベースがないため、SDCNの出発点としてはあまり適していません。

SDCNを支える4つの柱

Aristaでは、イーサネットを10ギガビットから40ギガビット、100ギガビット、さらにはテラビットへと拡張して

いきながら、L2/L3用の明確な標準とプロトコルを利用することが、クラウドを構築する多くの企業にとって最適

なアプローチだと考えています。この方法なら、物理および仮想のサーバー/ストレージのノード数が現時点で

10,000を超える大規模なクラウド・ネットワークを構築して、将来の100,000ノード超えへの拡張にも対応でき、

インターネットの再発明や独自タグの導入といった必要もありません。 VMWorld 2011でVMwareは、大規模なク

ラウド・ネットワーキングを実現する注目の新技術VXLANを発表しました（IETFに提出した仕様の起草者には

Aristaも名を連ねています）。VXLANは以上に述べた考え方をふまえており、 SDCNの設計原則のいくつかを具現

化しています。大事なことは、高い拡張性を備えた高密度なクラウドの構築は全体像の中の一部でしかないという認識です。ア

プリケーションのモビリティ、ストレージの可搬性、セルフサービス・プロビジョニングと自動化、動的リソー

スの最適化など、管理と運用の両面で、1990年代末にWebホスティング用として設計されたような従来のデータ

センターにはない新たな問題が生じてきます。 Aristaはこうした問題を認識し、1つずつ体系的に解決しています

。それを表したのが、Software Defined Networkingを支える4つの柱です。第1の柱：マルチパスのアクティブ/アクティブ・データパス・リーフ/スパイン・スケーリング： L2のMLAG（

Multi-chassis Link Aggregation Groups）とL3のECMP（Equal Cost Multi Pathing）を利用して、複数の物理機器にま

たがってクラウド・ネットワーキングを拡張していくやり方なら、標準に基づいたスケーラブルな方法で制約の

ないクラウド・ネットワーキングを実現できます。この方法では、使用可能なすべての帯域幅をノンブロッキン

グ・モードで効果的に利用でき、個別の物理機器やポートで障害が発生したときのフェイルオーバーと耐障害性

にも対応できます。両方の技術を組み合わせることで、マルチパスの重要な展開シナリオすべてに現実的な方法

で対応でき、独自の手法を利用する必要がありません。これらの技術では、現時点で50,000以上の物理および仮

想のコンピュータ/ストレージ・ノードに対応できます。次世代のマルチパス・サーバーCPUや、高密度な仮想マシンとストレージの登場によって、非サブスクライブの



5

キャパシティ、アップリンク、ダウンリンク、ピア・ポートに対応した、こうしたリーフ/スパイン・トポロジの

重要度が高まっています。また、トンネリング技術（MAC in IP）の登場によって、L2/L3のハイブリッド・トポ

ロジも可能となりました。こうした個別の機能は、ハードウェアとAristaのExtensible Operating System（EOS™）

で最適化するのが一番です。EOSは、先進のネットワーク処理向けに設計された最新のオープンなソフトウェア

・システムです。第2の柱：単一イメージのL2/L3コントロール・プレーン： Software Defined Networkingへの対抗策として、一部

のベンダーは、ネットワークのコントロール・プレーン・アーキテクチャ構築の30年にわたる取り組みを改めて

やり直すかのように、モジュール型でもデータベース中心型でもない、独自の基盤作りを進めています。これは

、膨大な費用をかけて何年も続くプロジェクトであり、過去の例からするとベンダー・ロックインにつながり、

IETFやIEEEで現在まで進められてきたインターネット・プロトコルの策定作業をないがしろにするものです。

Aristaでは、相互運用性のテスト作業の一環として、こうした製品を個別にデバッグすることがあります。こう

した非Arista製スイッチの多くは、プロトコルがきちんと文書化されておらず、導入も厄介なうえ、構成や管理に

も独自のツールが必要です。これでは未来への道は開けてきません。大々的に宣伝されているこうした独自の「ファブリック」によるアプローチではなく、標準にのっとったIETFの

L2/L3コントロール・プレーン仕様とOpenFlowによるアプローチなら、派手な宣伝はなくとも、オープンな手法

による確実な拡張で、将来の単一イメージのコントロール・プレーンを実現できます。今後数年間のOpenFlow

1.1の実装は、特定の用途を基盤とし、コントローラがスイッチに読み込むことのできる命令に基づくものとなり

ます。また、Aristaのゼロ・タッチ・プロビジョニング（ZTP）によるラック展開の自動化や、レイテンシー・ア

ナライザ（LANZ）によるアプリケーション由来の輻輳の検出のような、先進の運用制御も利用できます。第3の柱：ネットワーク全体の仮想化：物理インフラをアプリケーションから切り離して、ネットワーク全体を

仮想化することによって、モビリティの向上と大規模なリソース・プールを生かし、コンピューティング・リソ

ースとストレージ・リソースの完全な最適化と軽量化を拡張できます。この場合、入念に定義したセグメンテー

ションとセキュリティに基づいてネットワーク全体をプロビジョニングし、ネットワーク上の場所を問わずすべ

てのアプリケーションをシームレスに処理するのが合理的です。これによりクラウド事業者はスケールメリット

が得られます。こうしてネットワーク全体を仮想化すると、ネットワークの柔軟性を現在よりも大幅に向上させ

た状態で、外部コントローラが仮想マシンをネットワークから抽象化したり、モビリティと最適化のポリシーを

定義したりできて理想的です。この実現には、トンネリングの手法と、外部コントローラでの転送経路の定義を

可能にするための外部APIが必要です。 Aristaは、VMwareおよびMicrosoftとともに、この取り組みに積極的に参

加しています。ここから、VMwareのVXLANやMicrosoftのNV-GREなど、IETFの承認に向けたいくつかの新しいトン

ネリング手法が生まれ、Aristaもこれらにオープンに賛同しています。全体的な効果としては、ネットワーク全

体でモビリティの範囲が広がります。これは、大規模クラウドのスケーラビリティを確保するうえで重要な要件

です。簡単に言うと、物理ネットワーク・トポロジと仮想マシンのモビリティを概念的に分割できます。さま

ざまな面で、ネットワーク全体のハイパーバイザともいえる発想です。第4の柱：一元的な管理：管理の一元化については、これまではエンタープライズ向けのさまざまなスタッカブ

ル製品が問題となっていました。固有のプラットフォームを利用し、スループットにも制限があったためです。

理論上は、管理の一元化は、クラウド・ネットワークの従来のコントロール・プレーンとデータ・パスの上に階



6

層化する形で対応できます。一言で言うと、互いに独立した複数のスイッチどうしの間で構成を制御することが

肝心です。「ファブリック」技術は不要で、スイッチの1つ1つの機能を分散システムの物理的問題に結び付ける

必要はありません。 AristaのCloudVision™は、標準に準拠した管理用製品の好例です。XMPPやNETCONFによるメ

ッセージング手法を利用し、OpenstackやOpenFlowに基づく将来のAPIにも対応しています。クラウド・ネットワーキングには、明確に定義されたオープンなコントローラ APIに準拠した、Arista EOSのよう

な適切なネットワーキング・ソフトウェア基盤が必要であることは明らかです。こうした基盤を使用することで

、ネットワーク・スイッチ間の一元的な通信や外部コントローラが容易になるため、上位レイヤでのプロビジョ

ニングおよび自動化システムが可能となり、クラウド内のアプリケーションのモビリティと転送ドメインを規定

できます。クラウド仮想化とリソース最適化のツールによって、ネットワークの協調性ははるかに高まります。次の図 4はこうした原則を示しています。

さらに、このドキュメントの末尾に掲載した用語集では、イーサネット・スイッチとの通信に使用されるさまざ

まなネットワーク・インターフェイスと、それぞれのインターフェイスの主な用途や狙いについて説明していま

す。

Software Defined Networking の要件 Arista EOS の柱 - 標準の選択肢

高度なクラウド・トポロジ

IEEE/IETFの標準（独自タグは不使用） MLAG/ECMP SW ベースと TRILL で標準に基づく未来志向のツールに対応（例：Arista CloudVision）

クラウド・コントロール・プレーン

単一イメージ・バイナリの EOS で

L2/L3、ZTP、LANZ に対応将来の OpenFlow 1.X ONS APIs

一元的な管理標準ベースのツール（例：Arista

CloudVision）

ネットワーク仮想化

Arista VMTracer で現在の VMWare vCloud VXLAN に対応将来の OpenVirtualization Switch

（OVS）コントローラ

図 2： SDCN の 4 つの柱



7

SDCNの用途

VMWare VXLAN/コントローラによるネットワークの可視化仮想化データセンターでは、負荷の高いサーバーから低いサーバーへと仮想マシンが移動します。この柔軟性の

おかげで使用率を向上でき、コストの削減が可能ですが、その一方でデバッグは複雑になります。アプリケー

ションの担当チームがネットワークの担当チームに対し、アプリケーションのパフォーマンス問題に関するデバ

ッグの手助けを頼んだとしても、該当するアプリケーションを見つけるだけで一苦労となる場合があります。特

に、サーバーの仮想化管理ツールがネットワーク・チームの制御下にない場合は厄介です。こうした点への対応

として、ネットワーク備品ベンダーは、可視性を向上させるための仮想化コントローラを製品に組み込むように

なっています。たとえば、Arista EOSはVMTracer™をサポートしています。仮想化データセンター内の仮想マシン

を自動検出し、ESXサーバーおよび該当するVMのリストをインターフェイス単位で確認できるスイッチ・サービ

スです（図4を参照）。

図 3： SDCN の用途

ZTPとVMTracerによるクラウドの制御と自動化クラウド規模で効率よく運用するためには、ネットワーク構成のタスクを自動化する必要があります。たとえば

、Aristaのゼロ・タッチ・プロビジョニングを使用すると、スイッチとコンピューティング・ファーム間の配置と

接続を自動で行うことができます。また、仮想化コントローラが仮想マシンをサーバーに移行するのに合わせ

て、VMのVLANを該当するサーバーのアクセス・スイッチにプロビジョニングする必要があります。これがない

と、VMへの接続が失われることになります。 Arista EOSは自動セグメンテーションもサポートしており、VMの移

動をスイッチがコントローラから自動で把握して、そのVMのVLANをトランク・リンクに自動でプロビジョニン

グします。しかもArista EOSはオープンなため、サードパーティがスイッチにソフトウェアを追加して、コント

ロール・プレーンや管理プレーンを仮想化コントローラに統合できます（図5を参照）。



8

図 4：クラウドの制御：ネットワークの自動プロビジョニング

OpenFlowとOpen Virtual Switch（OVS）一般的なとらえ方とは違い、OpenFlowとOVSはアーキテクチャではありません。Software Defined Networkで使用

できる構成要素です。 Aristaがラボ・プロトタイプを開発したOpenFlow 1.0の仕様は、コントローラ（OpenFlow

コントローラ）と、物理スイッチ上のOpenFlowクライアント/エージェントとの間のプロトコルのやり取りにつ

いて定めています。 Open Virtual Switch（OVS）は、ハイパーバイザ内で動作する仮想スイッチで、VMwareの仮

想スイッチに似ていますが、オープンソース・ソフトウェアを基盤としています。 OVSは、OpenFlowプロトコル

を使ってOpenFlowコントローラから制御できます。 Software Defined Cloud Networkの構成要素として

注目が高まりつつあるOpenFlowとOVSは、まだ開

発の初期の段階です。 Aristaは、OpenFlowおよび

OVSのコミュニティとの共同作業で大きな役割を

果たしています。 OpenFlowとOVSの実装では、

EOSの広範なAPIを利用でき、シームレスな統合が

可能です。 Aristaは、これらの技術を基盤とした

ソリューションの提供や、オープンソース・コミ

ュニティとの連携に力を注いでいます。

OpenFlowとOVSは将来有望ながら、開発はバージ

ョン1.0の段階で、さらなる成熟が必要です。初

期の段階では、ラボ環境、ネットワーク監視（ハ

ードウェア・プローブへのOpenFlow固有のフロ

ー）、顧客の概念実証テストなどでこれらの技術

が利用されるものと考えられます。



9

OpenFlowとOVSのどちらも、カプセル化のハードウェア要件、機能の速度と範囲、OpenFlow以外のネットワーク

との互換性、トラブルシューティングのツール、信頼性とフォールト・トレランス、コントローラのスケーラビ

リティとパフォーマンスといった点に対処が必要です。 Aristaはパートナーと協力してこれらの問題の解決に努

めており、こうした重要な要件に対処したソリューションを開発しています。

図 5： OpenFlow によるネットワーク監視

まとめ

AristaのSoftware Defined Cloud Networking（SDCN）は、Software Defined Networkの理論面と設計面のさまざまな

原則を具現化したものです。ただしAristaは、クラウド・コンピューティングに固有のスケーラビリティ、仮想化

、モビリティ、自動化のニーズをふまえて、より的確なアプローチをとっています。イーサネット・スイッチは

現段階でも非常に高度化しており、大規模なスケーラビリティと耐障害性を実現するさまざまな分散転送機能を

備えています。当然ながら、クラウド技術を利用したり、クラウドによる自動化と最適化から運用面のメリット

を享受したりするためには、外部のコントローラに新たな要件が必要です。たとえば、サービスの抽象化と管理

の一元化や、高度にカスタマイズしたアプリケーションに固有の転送経路の定義などです。 Arista Networksはこ

うした原則を完全に取り入れています。 Aristaが定めた4つの柱は、高度にモジュール化されて耐障害性を備えた

、状態ベースのオープンなネットワーク・オペレーティング・システムであるEOSを基盤としています。開発者

やエンドユーザーは、すでにEOSに独自のスクリプトや管理ツールを追加できます。 Aristaは今後もEOSを基盤と

して活用していきます。EOSはSDCNの重要な構成要素です。本ドキュメントに記載の情報は、Arista Networksの製品に関連するものです。詳しくは、http://www.aristanetworks.comをご覧いただくか、[email protected]までお問い合わせください。



10

用語集

コマンド・ライン・インターフェイス（CLI）：CLIは、スイッチの設定、構成状態の取得、リアルタイムに近いパフォー

マンス・データ収集を行うための中心的存在としてよく知られています。 CLIは、スイッチのプログラミングを素早く効率的

に行うための手段です。技術知識のあるシステム管理者は CLIを活用しています。こうした管理者はスイッチの機能に深く精通しています。

Simple Network Management Protocol（SNMP）：SNMPは 1980年代末に登場したプロトコルで、スイッチやルーターを管理するためのインターフェイスとしては CLIよりも高レベルで抽象化されています。 GUIベースの管理アプリケーションの多

くでは、SNMPが事実上の標準インターフェイスです。 SNMPを利用するためには、スイッチのデバイス上にエージェント（SNMPエージェント）が必要です。エージェントは読み取りのみの処理と読み書き両方の処理に対応できます。 SNMPエージ

ェントは、管理情報領域（MIB）に保持されている管理データを公開します。

Network Configuration Protocol（NETCONF）：NETCONFは IETFで定められたプロトコルで、その名が示すとおり、スイッ

チの設定の構成、変更、削除を行うためのものです。また監視にも使用できます。 NETCONFはテキスト形式のデータを使用

するため、変更が簡単です。データのエンコードには、広く普及している XML（Extensible Markup Language）を使用します。 NETCONFの狙いは、スイッチやルーターの設定の構成、監視、変更に関して、CLIと SNMPの手法に代わる、両者の長所を

組み合わせた手法を実現することにあります。

Extensible Messaging and Presence Protocol（XMPP）：XMPPは、IETF認定の標準規格で、インスタント・メッセージング

とプレゼンス技術について定めたものです。スイッチから一元的な制御ポイント（コントローラ）に状態情報を伝えるための正式なプロトコルとして注目を集めています。 XMPPはクライアント・サーバー・アーキテクチャを利用しています。ス

イッチは中央の 1台または複数のコントローラと通信しますが、スイッチどうしがピアとして通信することはありません。

集権的な（サーバー）コントローラがないため、さまざまな実装が可能で、クラウド・アプリケーションに適しています。 XMPPは複数スイッチのメッセージ・バスの手法に対応しており、コントローラから、対象のスイッチまたはスイッチ・グル

ープに対して CLIコマンドを送信できます。

OpenFlowプロトコル：OpenFlowプロトコルは、スイッチと中央のコントローラの間の通信手段を提供するものです。こ

こまでのプロトコルと同様に TCP/IPベースで、セキュリティと暗号化の定義も備えています。コントローラとの通信にはウェルノウン TCPポート（6633）を使用します。スイッチとコントローラは、サイト固有の秘密鍵で署名した証明書を交換す

ることで相互に認証を行います。スイッチとフローの情報の交換には、明確に定義されたヘッダー・フィールドとタグを使

用します。詳細については、OpenFlowスイッチの仕様を参照してください。

OpenStack： OpenStackは広範なプログラム・レベルの話であり、中央のコントローラと通信するための通信インターフェイ

スや標準規格の定義といったものではありません。 OpenStackは 135社を超える企業から積極的な支援を集めており、サーバー、ストレージ、ネットワーク、データベース、仮想化、アプリケーションの各分野の代表的な企業が名を連ねています。

OpenStackが目指すのは、公的か私的かを問わず、あらゆる企業や組織が標準的なハードウェア上でクラウド・コンピューティング・サービスを提供できるようになることです。 Rackspace Hostingと NASAが正式に OpenStackのプロジェクトに着手

したのは 2010年です。OpenStackはフリーでモジュール型のオープンソース・ソフトウェアで、パブリック・クラウドやプ

ライベート・クラウドのためのファブリック、コントローラ、自動化、オーケストレーション、クラウド・アプリケーション

などを開発できます。

仮想化 API：ハイパーバイザやハイパーバイザ管理ツールの中からイーサネット・スイッチや中央のコントローラと通信するには、いくつかの APIを利用できます。こうした APIやツールでは、アフィニティのルール、リソース・プール、テナント

・グループ、サービス・レベル・アグリーメントのためのビジネス・ルールを定義します。また、こうしたツールでは、低レベルなサーバー、ネットワーク、ストレージの設定をビジネス・ポリシーやサービスのレベルで自動化できるため、管理の



11

対象を減らし、新しい仮想マシンを追加したりクラウド内で運用中の仮想マシンを変更したりするたびに発生する運用コスト

を削減できます。

本ドキュメントに記載の情報は、Arista Networksの製品に関連するものです。詳しくは、http://www.aristanetworks.comをご覧いただくか、[email protected]までお問い合わせください。

software defined cloud networking · software defined cloud networking...

Documents