ソリューション

マクニカネットワークスが取り扱う製品で、皆様の課題を解決します

活性化し続けるOpenStack コミュニティ OpenStack のネットワークを実現するNeutron とは

SDxとは

SDxシリーズの掲載を開始するにあたり、初回となる今回は、最初に言葉の定義、考え方を記載します。

SDxとは、Software Defined ~~の総称を指す言葉として利用されています。最初にお断りすると、SDxによってハードウェアが不要になるわけではありません。ソフトウェアが動くPlatformとなるハードウェアは常に必要です。ただ、ハードウェアの設置場所や仕様などの制約は大幅に削減され、ハードウェアは汎用的かつ安価なものへシフトしてきています。

ソフトウェアでこれらのハードウェアを制御することにより、多彩なサービスを抽象化レイヤ上でフレキシブルに実現することが可能になってきているためだと考えられます。Software Defined ~~は、まさにこういった環境を指します。

VMWareでは、過去数年にわたりSDDC – Software Defined Datacenterというキーワードを提唱し、データセンタ全体のソフトウェア制御化を推進しています。また、昨年のOpenStack Summitでは Software Defined Economyというキーワードが話題になりました。ソフトウェア制御によってユーザは自由な選択肢を得て、迅速にそのサービスの恩恵に与ることができる仕組みが出来上がってきたということです。

代表的なSDx

SDxと呼ばれるものの、代表的な2つを以下に紹介します。

SDN/ Software Defined Network:

文字通り、ネットワークの経路やパケット処理をソフトウェアでフレキシブルに行う考え方を指します。Open Networking Foundationは、SDNの定義を次のように定めています。(原文は、www.opennetworking.orgを参照されたい)

  • 直接プログラム可能:
    転送機能からの分離により、ネットワーク制御に直接プログラム可能である
  • 機敏性:
    転送機能の制御部分を抽象化することにより、管理者は需要に応じてネットワーク全体のトラフィックフローを動的に変更できる
  • 集中管理:
    ネットワークインテリジェンスは(論理的に)ソフトウェアベースのSDNコントローラに集中し、単一の論理スイッチよりアプリケーションやポリシーエンジンを含むネットワーク全体像でメンテナンスする
  • 動的な設定:
    SDNは、特定のソフトウェアに依存せずに、自分自身でプログラムできる動的かつ自動化されたSDNプログラムによって、ネットワーク管理者は迅速に設定・管理・セキュリティ性の確保及び最適化を実現する
  • オープンスタンダード且つ、メーカー中立的:
    オープンスタンダードで実装されたSDNでは、SDNコントローラが命令を発行することにより、メーカー特有の複数デバイスやプロトコル管理とは異なり、ネットワーク設計と運用をシンプルにする

ここ1年から2年の間に多くのメーカーがSDN製品またはそれに関連する製品を発表し、大いに注目を集めています。しかしながら、一口にSDNといってもOpen-flowに代表される通信経路上のハードウェアに制御機能を持たせるホップバイホップ型と呼ばれる方式や、データセンタ内にVXLANなどのトンネル技術を利用して通信制御を行うオーバーレイ型には、技術面における統一性は殆ど無いに等しいです。同じオーバーレイ型でも制御のアーキテクチャや機能は殆どが独自のもので、互換性のあるものは極一部にとどまります。

こういった背景もあり、SDNが爆発的な普及にまだ至っていないのも事実です。多くのユーザは、何がスタンダードになるのかを見極めるタイミングを待ちながら、この新しい技術の動向を見守っています。

一方で、日々膨大なネットワークの運用管理と構築が必要なパブリッククラウドのような業種では、運用管理コスト削減や迅速なサービス提供を行うための仕組みを構築することに大きな期待が寄せられ、多くで導入または導入のための調査が進み始めています。

SDS/ Software defined Storage:

SDSはStorage Virtualizationと混同されることが多いですが、一般的な考え方としては、ハードウェアのストレージ容量やサービスをソフトウェアで定義・分割して提供する仕組みとされています。サービスとして代表的なものは、データのシングルインスタンス化・レプリケーション・Thin ProvisioningやSnapshotなどが挙げられます。また、ポリシーベースでIOPSをフレキシブルにコントロールする仕組みも一部のメーカーによって製品化され、提供が始まっています。

Software Defined ~~に共通して言えるのは、ハードウェアの制限から抽象化レイヤを分離し、フレキシブルにコントロールできるというコンセプトを持つことです。

OpenStack Neutron

様々な技術によって実現されるSDxですが、昨今は制御のためのAPIに汎用的なものを採用する動きが見え始めています。それがOpenStackです。

ユーザや開発メーカーがOpenStackをグローバルスタンダードと捉え始めているためです。OpenStackは、言葉通りオープンソースソフトウェアの集合体で、クラウドのオーケストレーションを提供します。 OpenStackは、オープンソースでありながらもSDNとSDSの提供を実現します。

今回の掲載ではOpenStack Neutron機能について、少しだけ掘り下げて解説します。 OpenStack Neutronは、現在最も気軽に試せるSDNのひとつかもしれません。

OpenStack:

OpenStackはNASAのComputeソフトウェアNebula (Nova)とRack SpaceがCloud Files ソフトウェア (Swift)を 2010年にオープンソース化し、これらをベースとしたクラウドソフトウェアの開発プロジェクトとして同年6月にOpenStack Foundationが設立された。
現在も年に2回の間隔で新リリースを発表しながら発展を続けている。
2013年のHavanaリリースではリソース利用を計測するCeilometerが追加され、それまでのOpenStackによる流量計算の仕組みに課題を感じていた多くのクラウド事業者もさらに関心を強めた。
また、昨今日本でも数社のパイオニア的企業がプロダクション環境にOpenStackを採用し始めていることで、俄然注目度が上がっている。
特に今年10月にはOpenStack Summitが日本国内で開催される予定で、国内市場への影響に期待が高まる。

OpenStack Neutronは、OpenStackクラウドインフラストラクチャの構成要素のひとつで、Networkingを提供します。NeutronはOpenStack Networkingプロジェクトのコードネームで、以前はQuantumと呼ばれていました。2013年リリースのHavana以降よりNeutronに名称変更しています。(「Quantum」はTrademark conflictがあったため)

OpenStackではテナントがUI上で簡単に複雑なトポロジを含むネットワークを構築することができます。この仕組みをバックエンドで実現するのがNeutronです。

OpenStackのトポロジ

Neutron(旧Quantum)は、当時唯一のOpenStack Networkingであったnova-networkの以下2つの欠点を補うものとして、2011年4月のOpenStack Summit(Folsom)よりプロジェクトが発足しました。

1. ネットワークテクノロジの制限
  • 基本的なLinux bridgingによるインプリメンテーション
  • 実現可能な機能の制限 (ACL, QoS, …といった機能は持てない)
  • マルチテナントアイソレーション は 802.1q VLAN tagsの利用前提

2. ユーザ/テナントによるネットワーク設定の制限
  • テナントは自分自身のネットワークトポロジを作成することができない
  • テナントは他のネットワーク仮想化テクノロジの恩恵を受けることができない

Neutronで実現出来ることとして、主に次のものが挙げられます。
  • ネットワーク・ポート・サブネットの完全なコントロール
  • ユーザやテナントによる複雑なネットワークトポロジの作成
  • テナント別のネットワークアイソレーション
  • Plug-inの利用(一度に一つまで)
  • L3 アドバンスサービスを含む、仮想ネットワーク内全般のネットワークサービス制御

L3アドバンスサービス:

Neutronが提供するL3のアドバンスサービスは、以下のようなものがある。
  • Load Balancer as a Service (LBaaS):
    HA-Proxy (オープンソースソフトウェアを利用)
  • Virtual Private Network as a Service (VPNaaS):
    IPsecサポートおよび、1対1/1対N拠点間接続
  • Firewall as a Service (FWaaS):
    ホストのiptablesを利用したフィルタリング

Neutron は REST API レイヤであり、他の OpenStack サービスによって管理されるリソース間のネットワーク接続を管理します。(仮想マシン間のネットワーク接続提供など) Neutron は、完全にテクノロジ非依存のフレームワークで、Plug-inアーキテクチャとして構築されています。各メーカーが同じ API レイヤを通じてソリューションを公開できるため、顧客やエンドユーザはさまざまなメーカーのテクノロジを利用できます。

Neutronのレイヤ

様々なNeutron plug-in:

Neutron plug-inは、多くの3rdパーティメーカーを含め、多数が提供されている。 以下、openstack.orgに掲載されたPlug-inを抜粋する。
  • Open vSwitch Plugin
  • Cisco UCS/Nexus Plugin
  • Cisco Nexus1000v Plugin
  • Linux Bridge Plugin
  • Modular Layer 2 Plugin
  • Nicira Network Virtualization Platform (NVP) Plugin
  • Ryu OpenFlow Controller Plugin
  • NEC OpenFlow Plugin
  • Big Switch Controller Plugin
  • Cloudbase Hyper-V Plugin
  • MidoNet Plugin
  • Brocade Neutron Plugin
  • PLUMgrid Plugin
  • Mellanox Neutron Plugin
  • Embrane Neutron Plugin
  • IBM SDN-VE Plugin
  • CPLANE NETWORKS
  • Nuage Networks Plugin
  • OpenContrail Plugin

Neutronの課題

複雑なトポロジを実現するNeutronですが、まだまだ課題があります。
メーカーのPlug-inを利用することによって解決できるものもありますが、以下は代表的な課題の例です。

  • 別のネットワーク管理システムとの連携(Neutron Plug-in経由での3rd パーティ製品による実現は可能)
  • アグリゲーションレイヤまたはエッジレイヤの設定管理
  • 以下の図に示すスケール/パフォーマンスの課題
Neutronの課題

成長を続けるOpenStackコミュニティ

まだ課題が指摘されるNeutronですが、先に触れたように、既に一部の3rd パーティメーカー製品にこれらの問題の解決策を提示しているものもあります。こういった3rdパーティのテクノロジについては、別の機会にて解説の場を設けます。
OpenStackのコミュニティは現在も急激な成長を続けています。
開発者数でみても、昨年11月時点では世界130か国2700でしたが、現在では3500を超え、日々ソースコードは更新されています。この勢いは、他のオープンソースIaaSプロジェクトを大きく引き離している状況です。

OpenStackのコミュニティ

This figure is part of Qingye Jiang's  "CY15-Q1 Community Analysis --
OpenStack vs OpenNebula vs Eucalyptus vs CloudStack"
(http://www.qyjohn.net/?p=3801)

Neutronの課題として、かつては物理ネットワークとの連携機能も挙げられていましたが、こういったものもIronic (OpenStackのベアメタルプロビジョニングプロジェクト)の登場により状況が変わってきました。 先に挙げた課題の他にも、改善のためのプロジェクトが動き出しているもの、あるいは、既に改善されたものがあるかもしれません。それほど活発に開発が進んでいる状況です。こうした背景より、ここで解説した機能や課題もリリースを重ねるごとに大きく、より便利に変わってゆく可能性に期待が高まります。

いつか見た景色 from Staff's Albums