特集

最新のIT技術情報や旬な話題をお届けいたします

【ここまできた!OpenStack最新情報】
NFVとコンテナベースのデプロイツールと仮想化ベンダによるOpenStack対応の加速

【ここまできた!OpenStack最新情報】NFVとコンテナベースのデプロイツールと仮想化ベンダによるOpenStack対応の加速

OpenStackの現状

プライベートクラウドのインフラとして既にデファクトとして利用が始まっているOpenStack。グローバルではAT&T、CERN、BMW、Walmartなどでの導入事例が有名ですが、日本でもサイバーエージェント、ヤフージャパン、楽天、NTT西日本などの大手企業にて採用が進んでいます。

オープンソースとしてコミュニティでの開発が進められており、半年に1回のバージョンアップという速度で機能の追加が行われているOpenStackには様々なコンポーネントがクラウドコンピューティングの機能を実現しています。仮想マシンの起動・停止やネットワークの設定、ブロックやオブジェクトなどのストレージの提供、ユーザ認証機能などの基本的なコンポーネントを中心にマルチテナント環境でのメータリングを可能にする「Ceilometer」や、Hadoopを実現する「Sahara」、ファイルサービスを提供する「Manila」など従来のインフラから、より上位のレイヤーまで機能を拡げようとしています。

OpenStackはAmazon Web Servicesをオープンソースで実現するという当初の目的通り、「Integrated」と呼ばれる基本コンポーネントが密に統合されてクラウドインフラストラクチャーを実現していた訳ですが、近年、その発想を変えて「Big Tent」と呼ばれる概念に移行してきました。「Big Tent」は基本となる6つのコンポーネント、

  • 「Nova(仮想マシンの管理)」
  • 「Neutron(ネットワーク管理)」
  • 「Glance(仮想マシンのイメージを管理)」
  • 「Swift(オブジェクトストレージ)」
  • 「Cinder(ブロックストレージ)」
  • 「Keystone(認証管理)」

を中心に疎結合する発想で、6つを除くコンポーネントはユーザの利用形態に合わせて選択を行うことが可能になりました。もちろん、それぞれのコンポーネントはオープンソースソフトウェアとして開発されていますので、ソースコードを見ることも実際に開発に参加することも可能です。ただし、それぞれのコンポーネントとその開発コミュニティには成熟度やコミュニティの規模、それにデベロッパが所属している企業などの違いにより品質、機能追加やバグ修正の速さなどに違いがあるのは否めません。

本記事では400以上もあると言われるOpenStackで稼働するクラウドコンピューティングコンポーネントの中から、特に最近注目されているコンポーネントを2つ紹介します。

コンテナベースでOpenStackのデプロイの実現を目指している「Kolla」とは?

まずご紹介するのは、「Kolla」です。「Kolla」はシスコのエンジニアが中心となって開発を進めているプロジェクトで、コンテナベースでOpenStackのデプロイの実現を目指しています。

現在のOpenStackは、基本となるコンポーネントをある程度の規模のサーバクラスタに導入するのが難しいと言われています。単純に一つのサーバに全てのコンポーネントを入れる「devstack」と呼ばれるテスト用の環境としてまとめられたものがあるので、「devstack」を利用すれば物理サーバ1台にOpenStackを導入してテストや検証を行うことは可能です。しかし、実際にプロダクションシステムとして稼働させるためにはそれぞれのコンポーネントは複数のサーバに分散されてデプロイされるのが通常の本番環境と言えます。そのため、構成管理ツールである「Puppet」を使って複数のサーバにOpenStackを導入するツール、「PackStack」なども開発が進められています。

複数のサーバクラスタへの導入は非常に複雑で、マニュアルで進めるのはOpenStackに関する経験と知識が必要になります。「Kolla」はそのようなコンポーネントの実装をコンテナ管理ソフトウェアの「Docker」と構成管理ツールである「Ansible」を使って簡略化することを目指しています。実際には、OpenStackのコンポーネントをなるべく最小の単位でコンテナに収め、それを「Ansible」を使って導入するとされています。単なるテンプレートの応用ではなく、設定値の格納場所にKey/value Pairを使うところが新しい発想になります。

実際にデプロイに必要となる時間ですが、シスコのエンジニアによる試験的な測定では、「devstack」では14分程度、「PackStack」によるデプロイは44分程度、そして「Kolla」によるコンテナベースのデプロイでは9分程度という数値が、2015年5月に開かれたOpenStack Summit Vancouverで紹介されています。この結果を見る限り、「Docker」と「Kolla」はOpenStackのデプロイのためのツールとしては非常に有望です。「Docker」自体が若いプロジェクトで、「Kolla」そのものも非常に若いので、これからの進捗に期待したいと思います。

コンテナ関連の最近の傾向

コンテナ関連では、「Kubernates」と「Docker Swarm」によるコンテナのオーケストレーションを実現する「Magnum」、コンテナのネットワーク機能を「Neutron」に仲介する役割を果たす「Kuryr」など、今までの仮想マシンレベルで行われてきたクラウドの実装が徐々にコンテナを意識したものに変化してきています。この変化は、より軽量なクラウドアプリケーションの実装に向けた新たな動きと言えるのかもしれません。

「Kuryr」プロジェクトについては様々なOpenStack対応の3rdパーティSDNベンダからも注目が高まっています。「PLUMgrid」もその一つです。昨年は、Windows上でネイティブに動作するコンテナランタイムの「RunC」が発表されたこともあり、今後さらなる普及が予想されます。

しかしながら、一般的にコンテナでは画一的なサービスの提供が主なユースケースであり、その利用方法としてはスクラップアンドビルドを前提としたものが多いです。こういったユースケースでのSDNによるコンテナのネットワーキングには、コンテナの所在の追随など課題も多く、ベンダごとに独自の実装が進もうとしていました。「Kuryr」の登場により、より標準的かつ汎用的なSDN連携の登場に期待が高まります。

同様に、「Kolla」プロジェクトによってOpenStackコントローラーに付随するサービスのコンテナ化により、デプロイの簡易化をすることが期待されます。

サービスのコンテナ化では、リソースの軽量化によりバックアップ、マイグレーションが容易になるといったメリットもあります。こういった技術はMirrantis社の「Fuel」でも以前より利用されており、SDNでも「PLUMgrid」がコントローラーの役割であるDirectorをコンテナで実装することで、同様のメリットをユーザに提供しています。また、コンテナ化により特定のサービスのために専用のハードウェアや仮想マシンを準備する必要性をなくすことも可能です。

動画:<OpenStack Summit Vancouverでのプレゼンテーション>

動画:<OpenStack Summit Vancouverでのプレゼンテーション>

NFV(Network Functions Virtualization)のライフサイクルマネージメントツール「Tacker」

次にご紹介するのは「Tacker」です。「Tacker」はネットワーク機器メーカーのBROCADEがリードするNFV(Network Functions Virtualization)のライフサイクルマネージメントツールです。

通信事業者の世界では、これまで専用のハードウェアなどで構成されてきたデータ通信や携帯電話網の通信システムをソフトウェアで仮想化し、より柔軟でコスト競争力のあるシステムに移行する動きがあります。その際に通信インフラを標準化し、よりオープンなシステムに移行しようとしていますが、その標準化をリードするのがETSI(欧州電気通信標準化機構)と呼ばれる団体で、NFVの標準化もETSIで議論されたモデルに準拠するようにNECやHuawei、Ciscoなどが製品の開発を活発に行っています。

OpenStackでは今回紹介する「Tacker」が一歩リードする形で前回のOpenStack Summit Tokyoでもプレゼンテーションが行われました。

動画:<OpenStack Summit Tokyo 2015でのTackerのデモ>

動画:<OpenStack Summit Tokyo 2015でのTackerのデモ>

OpenStackのコミュニティでは、Teleco Workgroupという通信事業者やサービスプロバイダーなどで構成されるサブグループでもOpenStack上でのNFVの実現に向けて議論が重ねられています。Tackerのデモの動画でもわかるようにOpenStackのダッシュボードである「Horizon」やオーケストレーターである「Heat」とも連携して、GUIによるネットワーク機能の管理が可能になっています。

また、マルチベンダのネットワーク機器を管理する仕組みとして標準化が進む「NetConf/YANG」についても、対応するSDNコントローラーの管理が可能であることなどから、今後のOpenStackのNFVのプロジェクトとして期待が持てます。

さらに、将来の構想としてVNF(Virtualized Network Function、ファイヤーウォールなどのネットワーク機能をソフトウェアで仮想化したもの)のオートスケーリングや、VNFのService Function Chaining などが予定されており、これが実現するとより柔軟にネットワーク機能の実現が行えるようになると予想できます。

進化を続けるOpenStackと今後への期待

このように、今なお大きな進化を続けるOpenStackは、さらに多くの注目をあつめています。

OpenStackは異なる仮想化プラットフォームに共通のAPI、共通のインターフェイスを提供したり、マルチハイパーバイザ管理としての利用も注目されています。

また、様々な3rdパーティ製品の連携ツール提供により、ユーザは特定ベンダに依存しない多くの選択肢を得ることができます。

OpenStackといえば、オープンソースだけでKVMを用いて構成するものが一般的なイメージですが、VMWare社によるVIO(VMWare Integrated OpenStack=既存のvSphereプラットフォームをOpenStackで管理)のように、既存の環境の運用性、安定性はそのままに、OpenStackのUIやAPIによるメリットを提供するものもあります。

同様に、NutanixもOpenStack対応を近日リリースする予定(2016年2月現在)です。

NutanixのOpenStack対応により、ユーザはNutanixの安定性、運用性とスケーラビリティを担保しつつ、マルチテナント、セルフサービスを実現するUI(Horizon)を利用できるようになるほか、各コンポーネントへのアクセスで、OpenStackの汎用的なAPIを手軽に利用することが可能になります。

NutanixによるOpenStack対応概念図

図1. NutanixによるOpenStack対応概念図

仮想化プラットフォームのベンダによるOpenStack対応には、ベンダ自身にも手軽にマルチテナンシー、セルフサービスを実現できる利便性をユーザに提供できるというメリットがあります。

こういったベンダの動きがより活発化することで、グローバルスタンダードとしてのOpenStackへの注目度はさらんに高まり、より普及を加速させていくことが期待されます。

今回の記事では、クラウドコンピューティングのインフラストラクチャーであるOpenStackがコンテナやNFVの領域でも徐々に進化していることをご説明させていただきました。

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