はい、たくさんの皆様にお集まりいただきましてありがとうございます。それではこれから、通信事業者観点からのオープンスタックベースのサーバー基盤に求める技術的要件についてと出しまして、NTTらしくちょっと固くるし大名になっていますが、セッションの方を始めさせていただきたいと思います。まずこれからのプレゼンテーションに先出しまして、今回本セッションのご参加の皆様にお願いがございます。本日、私どもが行いますプレゼンテーションにつきましては、画面に表示が通り、NTT西日本の公式発表または公式見解を示すものではございません。また、本資料に記載されている内容は、私どもNTT西日本研究開発センターにて、現在取組中の営みをご紹介するものであり、今回お話した内容や計画が、今後必ずしも実現されることを保証するものではありません。さらに、今回ご紹介するデータについては、本セッションにおける議論用に検証中のデータから一部罰税して用意したものであります。ですので、記載されたデータの確実性については、NTT西日本は保証いたしません。以上のことから本日の発表および資料の記載内容について、NTT西日本は、今後の検討や質問回答の責任を終わらないものとします。冒頭から肩苦しいお話をしてしまい、大変恐縮ではございますが、何とぞご了承のほどよろしくお願いいたします。それでは、アジェンダーの方に入ってまいります。まず、最初に私どもがオープンスタックに取り組むにきっかけになりました背景でありますとか、オープンスタックに何を期待しているのかについてご紹介いたします。次に、私どものサーバーインフラにオープンスタックを適用するにあたり、現時点において不足する機能について、本セッションの本題でもあります、技術的要件についてご紹介いたします。また、これまで私どもが取り組んできたプルーフォークコンセント、検証の構成やその結果の概要について簡単にご紹介いたします。さらに、現時点で解決できていない様々な課題について、今後どのように取り組むことをしているのかについて、現在の検討状況をご紹介いたします。最後に、プレゼンテーションを締めた後に、皆様からのご質問であるとかディスカーションに入りたいと考えております。ご案内が遅くなりましたが、本セッションは私に書くと、あとこちらにいらっしゃいます。2名のご協力の皆様と共に進めてまいります。よろしくお願いいたします。それでは、私書くから、NTT西日本のオープンスタックに取り組みに至った背景とオープンスタックに何を期待しているかについて読めさせていただきます。背景に行く前なんですけど、私たちNTT西日本の事業内容と今回対象とつるサーバーシステムの説明に移ります。NTT西日本はご存知だと嬉しいんですけども、日本の西側の事業社でありまして、固定改善を使って電話や通信のサービスを提供しております。最も有名なサービスであります。フレッツは、学様からFTTHも使って接続しているサービスとなります。通常、お客様がインターネットに接続する際は、お客様FTTHもからコアネットワークであるNGNも通してISP事業社様につなぎましてインターネットに接続します。ただ、一部のサービスにおいては、このコアネットワークから直接サーバー群に接続するものがあります。このサーバー群との接続点をSNIと私たちは呼んでおります。今回、オープンスタックを導入する対象となるシステムは、SNI上部のサーバー群になります。それでは、先ほどのSNI上部に位置するサーバーイフラの構成についてご紹介いたします。この図にありますように、ブレードサーバーを中心としたらサーバー統合の状態になっております。この図で示しましたとおり、特に通信事業者の特別な使用を持った機器を入れておらず一般的な構成になっております。システム開発においての役割分担なんですけども、このブレードサーバーのゲストOSより上がサービス開発者、それより下がインフラエンジニアが担当しております。先ほどのサーバー統合の状態は、私たちNTT2新本にとって、このオペックス、キャペックスがかなり負担となっております。そこで私たちはイヤー製の移行を見ております。これによりキャペックス、オペックスの改善を目的としています。私たちがオープンスタックに期待する最終的な目標は、SDIの実現と提供になります。私たちが理想とするSDIは、サーバー、ユーザーが自身で自由に専用のインフラをデプロイできることを望んでおります。インフラ設備とユーザー環境が完全に分離されることで、サービス開発者とインフラエンジニアの分業が完全になります。このように私たちはオープンスタックの活用で理想となるSDIの世界を実現したいと考えております。それでは、これまでが背景というところで、これからが本題でありますNTT西日本における技術的な要件ということで、具体的には私どもオープンスタックキロバージョンで検証してまいりましたが、こちらにおいても不足する要件というのがいくつかございますので、こちらをご紹介させていただきます。まず、なんと言っても私どものネットワークに一番重要なのがIPV6V4のデュアルスタック構成での動作になります。IPV6が必要ですと言いますと、皆さんいろんな機能を想像される場合があるんですが、私どもが必要とするIPV6の機能としてはここにあげましたものとなっております。デュアルスタックで動かす必要があるのは、データプレーンというオープンスタックでユーザーが実際に通信をするネットワークについてのみですので、いわゆる裏面のコントロールプレーンでありますとかメンテナンスのプレーンでありますとかは基本的にIPV4で十分ことたりる状態になっております。また、IPアドレスマネージメントにつきましては、テナント単位、あるいはセグメント単位、仮想マシン単位でそれぞれ管理をしたいという要件がございます。特に重要となってまいりますのがこの3点目、固定的なIPアドレスの割り当て方法ということで、具体的には、仮想マシンにIPV6の固定アドレスをどうやって割り付けたらいいだろうかというところが今我々にとってもまだ課題になっております。IPV4ですといわゆるフローティングIPという機能を使って実現できるんですが、IPV6の世界で納豆をかけるというのも何戦数の話ですし、かといって固定で割り付けるとうまく動かないといったのが今の課題になっております。4点目はアテナと内のルーティングですが、こちらは複雑なものが逆に必要なくてスタディックにルーティングできればいい。なので、よく皆さんに言われるのはBGPがありますか、OSPフェイルがありますかって言われるんですが、そういうのは必要ないという状態になっています。最後ですが、ファイアオーラーザーサービス、ロードバランサーザーサービスも動かしたい。今V4ではようやく実装がなされてきていますが、V6に関しては全く動作していないというのが我々の認識でございます。一方、ファイアオールに求める要件です。先ほどIPV6でファイアオールを動かしたいというお話をさせていただきましたが、それ以外にもそもそもV4の世界においてもファイアオールザーサービスという名前になっているはずなんですけど、実際にはIPテーブルの塊でこれファイアオールというのがいいのかなということで、できればステートフルなアクセスコントロールリストあるいはSPIといわれる機能が最低限欲しいなという状態です。さらにファイアオール既存のインフラで使っておりますファイアの機能の中に典型的なセキュリティ攻撃に対する対策ということで、具体的にはリードスの対策であるとか、よくある攻撃を対策についてはこのファイアオールザーサービスで実装してほしいなというのが私どもの希望です。4点目はファイアウェイラビーという情報化対応といったものになります。続きましてロードバランサーについてです。こちらもIPV6対応はもちろんのことながら、そもそもの話といいますと、オープンスタックのロードバランサーザーサービスは基本的にウェブサービスをロードバランスするために作られているものと我々は認識しています。ですので80番だ、443だというのは対応できるんですが、私ども通信事業をしたとしてはできればそもそもTCPのポート番号であるとか、UDPのプロドコルもロードバランスをしたいというニーズがありますので、ぜひレイヤーちょっと下げていただいて、いわゆるレイヤー4のレベルでのロードバランスの機能を実装してほしいなというのが私どもの要件です。あと細かいところですが、ダイレクトサーバーリターンであるとか、SSLのオフロードとまでをやらないんですが、SSLの対応だったりとか、業長家の機能が欲しいというのが私どもの要件でございます。その他逆にですね、いらないものといった後編があるんですが、一般的に、みなさんいろんなセッションお聞きになって、何万台、何十万台というサーバーをオープンサックで運用してますという話をよくお聞きになったと思いますが、私どものサーバーインフラはどうしてなったかといいますと、プライベートイヤー数で、一つ一つは規模が小さなものになっております。ただそのサーバーインフラが分割していくつも存在するといったのが、他の皆様の形とちょっと違うところであります。ですので、ここのサーバーインフラ環境は物理サーバーで言いますと、せいぜい数百台程度のものですので、オープンサックの機能に私どもスケーラビリティはそもそもそんなに重要ではない。もう一つはアジリティということで、いろんな機能がオープンサックのコンポーネントでどんどん追加されていますが、私どものサーバーインフラにおいては、一度作ったサービスやアプリケーションにそもそも機能を追加することがあまりございません。あるいはサーバーインフラにその機能を求めてくることも基本的にはあまりないということで、アジリティもそんなに重要ではない。じゃあ私どものとって何が一番重要なのかといいますと、スタビリティ安定性ですね。必要な機能が適度な性能で、高速な性能とまではないです。適度な予測可能な範囲での性能で安定して動作し続けるということが私どものとって一番重要なことでございます。で、今頭の痛い話がオープンスタック入れてしまったらこれバージュマップどうしようというのがちょっと、他の皆さんも同じように悩まれているかと思いますが、私どももこちらが今課題となっております。内容がですね、内物値だりといいますか、こういう機能が欲しいなという話だったんですが、じゃあ私ども今まで取り組んできたその検証の内容とその結果の概要についてご紹介をさせていただきたいと思います。一般的なオープンスタックでいう三大構成を模擬したものでございまして、コントローラーノード、コンピュートノード、ストレージノード、ネットワークノードはそれぞれ反応的なインテロアキテクチャーのサーバーを利用しています。コンピュートノードにちょっとCPUをですね、順卓に割り当てたりとか、ストレージノードは基本的にはハードディスクをJ-Botでたくさん進め込んだとかですね、そういうものですが、基本的にはどこかのメーカーの特殊な機能に依存しない、どこのハードウェアでも動くようなものを目指して取り組んでいます。こちらを載せてみますAはポック1つのAですが、実際にはこのポックを3つ作っておりまして、いろんなメーカーのハードウェア、ここに書いた使用を満たすいろんなメーカーのハードウェアを混ぜ込んで、比較検証を進めております。ネットワーク性能ですね。先ほどのビートアイルサンの検証データを見て、RLEにホットしたといいますか、近しいデータが出ているのかなと思っているんですが、まず内容に入る前にですね、ちょっと想定外の内容がございまして、まずこちらをご紹介させていただくと、トップワークスイッチの間に実はパケトスが発生していまして、ちょっとまだこれが原因の解析にまでいただいておりません。ですので、今からご紹介するデータが、ちょっとこの問題に引きずられている可能性があるということだけご了承いただきたいと思います。で、やった内容につきましては、コンピュートノード上のパソマシンからスイッチング、いわゆるネットワークノードを開かないで、レイヤー2でを控えす試験と、ネットワークノード上のルーティングエンジンを開いて、L3、レイヤー3の構成の試験をしたときのデータがこちらの方になっておりまして、だいたいレイヤー2で3.5ギガ程度、ルーティングでも近しい数字と話しております。結果として見ると、レイヤー2のところでそもそも遅いといったところになってまして、検証する前にはレイヤー3が遅いのかなと思っていたのですが、レイヤー3は実は遅いというよりはレイヤー2が遅いので、そもそもレイヤー3はそんなに劣化していないというのが、私どもの検証の中で得られたデータになっています。もう一個ご注意いただきたいのは、今回チューニングを施しておりません。いろんな機械を混ぜ込んでおりますので、その機械ことにチューニングというのはしてますと、ちょっと得られることになりますので、今回チューニングはしていませんので、このデータ自体はまだまだ改善の余地はあるかと思いますが、言い換えますと、買ってきたハードウェアに何も考えずにオープンスタックを入れて、ドーガスとこのようなデータが得られるといったような形で、ご認識いただければ結構かと思います。ちなみにもう一つ、先ほどのビットアイルさんのお話とちょっと違うのは、VXLANを今回使っておりません。私どもVLANでやっております。ですので、ちょっと数字が違うのはこういったところに影響しているものと考えてください。で、今後の取り組みです。先ほどお見せしました、これまでの取り組みの結果、まだまだ課題があるというふうに考えております。で、私どもの課題、まだまだやまずいでございまして、先ほどご紹介しました、従来のオープンスタックを使わないサーバーインフラをこのまま維持し続けるのは非常に困難な状態になっています。で、かといって今後のオープンスタックを安定運用させるということを考えますと、次も三沢のバージャン、LTSですね、DongTermサポートだと思いますけど、LTSで是非入れたりと。これを逃してしまうとLTSを逃してしまいますので、このタイミング残り半年で何度かしたいと思っております。ですので、オープンスタックにいろいろ期待はしたいところではあるんですが、今足らないところはオープンスタックの他の何かで補うといったことを今後早急にする必要があります。具体的には2つですね、機能面の充足と性能面の充足ということで、こちらに書いてありますようなことをやりたいと思っています。具体的には次のページからご紹介いたします。まずネットワークの面においては、まずやっぱり何を言ってもIPV6を起こさないことには、私どものサーバーインフラを新しくすることはできませんのでIPV6の対応、あるいはファイアウォール、ロードバランサーもこちらを対応させていく必要があります。2つあるんですが、オープンスタックのコミュニティが怒られるかもしれないですけど、レイヤー2の構成にして、外した機能をどうするのかといったところで、既存の箱物ですね、外部のアプライアンス機器を使うのか、あるいは外部のサードパーティのSDN製品を使うのかといったところで、今製品選定等々を進めております。次に先ほどのビッドヘルサンの話もありましたけども、ハードウェアのオフロードというのも私ども取り組みたいと考えております。具体的にはレイヤー2の性能ということで、先ほどはVXLANのオフロードがございましたが、私どもVXLANは使っていないんですが、それ以外の機能もオフロードできないかなということで、今色々も錯誤しております。あるいはレイヤー3の機能ですね。今回は図らずともボトルネックになりえなかったんですが、ネットワークノードは今後ボトルネックになる可能性が十分になりますので、このレイヤー3の機能を現時点ではまだ箱物ですね、外部アプライアンスの機器にオフロードしていくのがまだ最善かなと思っておりまして、この外部アプライアンスの機器を従来のプロプライエータリーな機器であるとか、あるいは最近入りのホワイトボックススイッチも活用していきたいと考えています。続きましてストレージですね。今回この紙一機、紙半年ですね、ストレージは実はあまり放貨されていなかったんですが、ストレージに関しては先ほどの要件もなかったと思いますが、機能的にはまだ今のところで十分に充足しているかなと思っておりますが、まだまだ活用という観点ではいろんなことができるかなと考えておりまして、新たなチャレンジをいろいろしたいと思っております。具体的には一つ目、専用機の活動、外部アプライアンスとして、従来のHPサンデルとか、メルタアップサンデルとか、外部MCサンデルとかのハードウェアをオープンスタックシンダーで使うときに、シンダードライバーでいろいろ最低限のことができるんですけど、やっぱりそれぞれの機器の良いところ、いろんな機能を使いこなそうと思うと、それぞれのハードウェアの方のマネジメントをさわる人があると。なので、オープンスタックからの管理とストレージの管理という2面性が発生してしまいます。ですので、このマネジメント、管理の面の改善を何とかしていきたい。あとは今回はファイバーチャンネルを開いて活用しなかったんですが、まだまだファイバーチャンネルと活用の余地があると思っておりますし、使うからには面倒な設計を省力化していくと、いったようなことに取り組んでいきたいと思っております。また今回ですね、ストレージノードはコモディティサーバーといいますか、汎用のインテロアキテクチャーにハードディスクをたくさん突っ込んでという使い方をしましたが、今回実はそれ以上のことができておりませんでした。するとそれをやったらですね、分散ブロックストレージ、セーフーダーとか、NTTグループですとシープドックを活用して動かすのが本来だと思いますが、今回ちょっとそこまで手が回らなかったので、次はぜひこれを使いこなしていきたいと思いますし、これも先ほどのですね、ビットアレさんの話になりましたが、40ギガのネットワークであるとか、あるいはファイバーチャンネルでも高速の32ギガであるとか、128ギガっていうのが出てきているようですので、こういうストレージネットワークの高速化をチャレンジしていきたいと考えています。さらにですね、実運用を考えたときに、そもそもまだ着手できていないのがバックアップです。既存のインフラですね、既存のサーバーインフラでは従来型のバックアップ、フルバックアップだとかサブンバックアップだとかっていうのをですね、仮想定プライブラリーを使って実現していますが、じゃあオープンスタックに書いたときにバックアップでどうしたらいいんだろうか、今までのやり方です。そのまま投手するのは何センスだと思いますので、やっぱりバックアップのあり方っていうのがそもそも考えないといけない。で、具体的にはバックアップに何を求めるのかということで、一番重要な観点としてはディザスタリカバリ、DRの観点で、コトナルメディアにバックアップを取るには、あるいは遠隔時に飛ばすにはといったところを検討してくる必要があると考えております。あとコンピュート濃度に関してはですね、これはかなりチャレンジの話だと思いますが、マイクロサーバーの活用というのを考えております。これをするにはですね、アイロニックですね、ベアメタルプロビジョニングあるいはベアメタルコントロールといったような機能が実現されていないといけないんですが、何をしたいかといいますと、今回買ったハードウェアはCPUかなり効果なものを買いましたので、サーバーの値段がやっぱり高くなっています。で、一方ですね、マイクロサーバーという、安価なCPUをそのまま使う、分割せずにそのまま使うといったような使い方も最近徐々に出てきていると思います。あるいは消費電力という観点で、使わないサーバーを別に落としていくといったようなこともできるのではないかなと考えておりますし、あるいはネットワークのところでもありました、仮想スイッチエレア2のオーバーヘッドを極端に回転するためにはもうOBS外してしまうといったのが一つの手だと思いますので、リナックス無事地に帰るという点もありますが、物理サーバーにしてしまうといったことや、それによって仮想マシン上のハイパーバイザー上のノイジーネイバーの問題もおのずと解決できるので、ちょっとこういうのはいろいろ試してみたいなと思っております。今後のロードマップとしましては、11月以降ですね、さっきほどのネットワークの案にございました、レイア2の構成でIPV6をとりあえず何としてでも動かすといった環境を作っていきたいと考えています。ただこれはあくまで現時点の一時的な大対策として、まず現時代できるところから始めるといったことを取り組んでいきたいと思いますので、今後これをずっと続けるというわけではなく、あくまで今回まずは動かすといったところになっています。先週ですかね、出ましたリバティバンの動作確認であるとか、先ほどのせましたオフロードの検証等も進めていきたいと考えております。2016年度、これは日本の会計年度になりますが、2016年4月以降、早いうちに商用の環境でオープンスタックの新しいサーバーインフラを構築していきたいと考えています。次には先ほどありました、みたかですね、LTSのバージョンが出た時点で動作確認をして、それを商用の環境に適用していきたいと考えています。そのインフラを作った上で、その上に乗るゲットシステムの皆さんに、2010年度末頃の開発予定のシステムをどんどん実用に適用していきたいと考えております。最後に、オープンスタックに対するNTT-22の参戦について、ということで進めさせていただきたいと思います。先ほどもありましたけど、オープンスタックへの期待ということで、NTT-22の本としましては、オープンスタックはユーザーに適用と思っています。NTTグループをはじめずしましたコミュニティの皆さんに、今、オープンスタックかなり開発を進められていると思いますが、私ともこれからオープンスタックに開発を入っていくというのも一つの手がたと思いますが、オープンスタックの発展というのを考えるときには、どちらかというと私とも後発ですので、実運用で使っていく実例を増やしていきたいと、そちらの方でオープンスタックの発展に企業をしていきたいと考えております。ですので、先ほどのめましたような、実運用するにあたってこんな機能が足らないんだとか、こういうのを欲しいんだという声を上げ続けて、実運用を頑張っていくということで、NTT西日本はオープンスタックの発展に企業をしていきたいと考えております。以上をお持ちまして、NTT西日本からのプレゼンテーションを終了したいと思います。ご清聴ありがとうございました。時間だいぶ余ってると思いますので、ご質問とございましたら、ご遠慮なくいただきたいと思いますが、