本日は、多数の並列セッションがある中、本セッションを調査として選んでいただき、誠にありがとうございます。本日は、マルチハイパーバイザー環境の実現に向けた構築の方の課題共有と題しまして、ひたち政策書のアグチと試しげが発表させていただきます。よろしくお願いします。まず、本日の発表の構成にはこうなっております。まず、背景とオープンスタックのマルチハイパーバイザー機能の概要と、あとは事例1に対して、私から発表を行い、事例2の方を試しげの方から発表いたします。まず、背景からです。まず、軽く弊社、ひたち政策書についてご紹介いたします。ひたち政策書は、他期にわたる分野でビジネスを展開しており、そのうち、情報通信システム部門はだいたい約20%ぐらいの売り上げ高になっています。その情報通信システム部門の中でも売り上げ構成を見ますと、金融公共産業通信社会批判等とありますが、金融が比較的多い。売り上げ構成は国内海外の内訳では、日本が約6割7割となっています。続きまして、オープンスタック関連市場についてですが、エンジニアの急事の急増とか、パッチ数の増、投稿数の増、急増、関連イベント、こういったイベントの参加数の増加という背景から、オープンスタック関連市場というのは拡大傾向にあるのではないかなと思っています。そのような状況の中、お客様の業種に問わず、弊社への問い合わせも増加傾向にあります。本セッションでは、先ほどのめたように、比較的問い合わせの金融の分野で、システムに高い信頼性・安定性が求められるのですが、そのような金融系の業種向けの取組と、あとは業種に問わずニーズの高い既存の仮想化環境からの移行の取組の2種類のプライベートクラウドの構築事例についてお話しします。続いて背景、マルチャイパーの機能についてです。まず、プライベートクラウドに関するユーザの課題ですが、例えばシステムの利用者、利用者ですね。そっちの方は、AmazonのAWSのように、すぐにVMを使いたい、スピードとか柔軟性を重視するというニーズがあります。また、システム管理者の方については、マルチベンダーのハードの運用管理を簡単にして、ベンダー6件を回避したり、自動化を推進したい。また、さらにITコストの削減、今も頑張っているのですが、さらに削減したいというコストの削減をしたいというような課題があります。一方、オープンサックの特徴ですが、そういったニーズを対応できる特徴があるのではないかなと考えています。例えば、AWSに似たクラウドを構築できて、スピードを極められるとか、マルチベンダーを意識せずに機器を管理できる。また、マルチハイパーバイザーに対応しているということで、コスト削減につながったり、あとはオープンなクラウド技術なので、ベンダー6件を回避できる。あとは多数の企業が開発に貢献しており、開発が早く新機能をどんどん使える。こういった特徴があります。今回はその中で、マルチハイパーバイザーに焦点を絞って説明します。オープンサックのマルチハイパーバイザー対応なんですが、確か、午前中のキーノートでも、VMとかドッカーとか、いろんなワークロードを一つのプラットフォームで管理していくのが重要だということだったと思うんですが、実際、マルチハイパーバイザーの機能はオープンサックのコミュニティでも活発に開発が進んでいます。例えば、これはちょっと詳細なんですが、KVMに関してはほぼ全ての機能に対応している。これはスタンダードなのでは当たり前で、そうなっています。他に関しては、VMエアとかハイパーバイゼンベアメタルドッカーというものがありまして、それは一部の機能が対応しています。そのメリット、マルチハイパーバイザーのメリットなんですが、ハイパーバイザーをコモディティ化することによって、業務のSLAや費用に応じて適切なハイパーバイザーを選択して、コースの最適が図ることができるといったことがあると思います。例えば、テスト環境とかあまりコストを掛けたくないところはKVMで十分だったり、あとは、ウェブ三回層システムを作りたいというようなときは、ウェブやアプリケーション層、KVMやVMの仮想環境に乗せて、高性能が求められるDV関連のサーバーはベアメタルで作るということがあると思います。本セッションでは、その中でもKVMとVMやベアメタルの所に商店を絞っていきます。事例1です。事例1に関しては先ほどのめたように、県有形の業種の向けたシステム構築です。そういった方は、それからのニーズなんですが、まずは仮想物理環境、今度はマルチハイパーですね。このシステムを実現して、幅広い枠に対応してコストを下げたい。また、既存のシステムに求められている高信頼とか高可用性をオープンサックを適用した後も、そういったものが維持したいと。そういった要望があるいます。例えば、対応障害によりシステムダウンタイムのダウンの回避のための高可用性だったり、障害発生時の確実な障害検知。こういった要望を満たすために、実際にシステムを作ってみました。これが雑草システムの概要なんですが、これちょっとそれぞれに書いてないんですが、Relo USB-7、キロベースのRelo USB-7で作ってみました。特徴としては、仮想物理の混在環境で運用簡単にするためのポータルサーバー。あとは、オープンスタックのみでは、検知できない障害を監視するために外から監視サーバーを立てて監視する。あとは、公開要請としては、コントローラーのエッジエとかは当たり前だと思うんですけど、そういったものも取り入れて、あとはポータルサーバーなんかもエッジエ組んだりして、ノード上調化する。あとは単一障害でシステムダウンを回避したいというのがあるのでネットワークとかFCのパスは全て上調化してシングルポイントブフェイラーを起こさないとそういったことを重視して作っています。こういったシステムを作ってみたんですが、今回はその構築するためのポイントみたいなものを簡単ですが4点紹介します。1点目はデプロイするイメージの管理とか作成方法。2つ目は仮想サーバー上のVMと物理サーバー間の通信のために柔軟なネットワーク構成をどうやって組むのかっていったこと。あとはポータルサーバーの構築のポイントとあとは監視サーバーでの監視のポイントについて説明をいたします。まず最初にKVMはほぼすべての機能ができていてベアメッタルとか他のハイパーバイザーは一部の機能が実現しているということを先ほどのチャレーターに述べたんですが、ちょっと詳細に書いてみますと例えば物理サーバーはボリュームからの起動とかスナップができなかったりあとは仮想ネットワークでもKVMはいろんな対処対応な仮想ネットワークの種類に対応していますが物理マシンはキロベースの時点ではフラットのみです。あとはそういったことに関連している歌が作成できなかったり、こういうことがあります。まず1と0に関してはまずイメージの管理作成とあとはネットワークについて述べていきます。まずはイメージの管理方法ですがイメージからの起動する場合はマルチャーバイザー環境ではイメージのメタデータにハイパーバイザータイプという属性を設定してデプロエ先が選択することが可能になります。例えばKVMにやりたかったらハイパーバイザータイプにQAを持ってつけたりベアメタルにデプロしたかったらベアメタルにつけると。そういったことはデプロはできるんですがまったく同じ種類のOS、例えばレールファイブとレールファイブとかウインドウズとウインドウズは同じ種類のOSとイメージでも仮想マシン用とベアメタルのようにそれぞれ分けて作らないといけない。そのためユーザーがイメージの選択をメディアから間違えてしまう懸念があって使い勝手が悪い。あとはイメージを確認するための要領をハイパーバイザーことに用意していけない。それだけ要領を食ってしまう。運用戦に何がある。問題が実際作ってみて分かりました。これ改善案でまだ案の段階で提案しているわけではないんですがハイパーバイザータイプって属性をグランスのメタデータではなく例えばノバとか切り離してしまってあげることで同じ種類のOSは1個です。そういうような運用ができるようになれば使い勝手が改善されてグランスのイメージの要領も節約できるのかなと私は今考えています。次はデプロイするイメージの作成なんですがこれは先ほどの構成図を仮想サーバーと物理サーバーを拡大したんですがこれはよくよく見てみるとデプロイ先はこのVMと物理サーバーなんですがよく見るとVMからはここは物理的には20化されているんですがVMから仮想的なんで1本で良いというようにネットワークの上調性に異なる点があったりFCも同様です。あとは物理サーバーにこういうデバイスが付いていてデバイスドライバーを入れなきゃいけないということがあるように仮想環境と物理環境前にデプロイ先のシステム構成が異なっている細かいですがそういうことがあります。なので構成に合わせてデプロイするイメージをカスタマイズするとかあとはクラウドイニットとかのようなエプロイ後に設定変更を加えるような仕組みでお導入する必要があります。次はネットワークの問題点です。これが繰り返しになりますがKVMだと多様な仮想ネットワークタイプに対応している一方で物理サーバーではフラットなネットワークのみに対応しているウェブとか調べたすぐキロのバージョンで出てきます。そのため仮想物理サーバーの混在環境でまるちゃいまくもっとすると普通考えるとフラットしか組めないので全部のVMと全部の物理サーバーが見え全部通信できてしまうというように柔軟なネットワークの構成が取れません。これを解決するために物理ネットワークスイッチのポートVLANの機能を使うと物理サーバーと通信可能なVLANを設定することで柔軟に仮想物理環境の混在環境でネットワーク構成を構築することが可能になります。例えばこの例ですとVMから仮想サーバーがつながっているところはVLANを2つ通すようにポートを設定してあげて物理サーバーの方は通したいVLANだけこの場合だったら10だけとか20だけというふうにやることでここのVMとここのVMを通信させたいこっちとこっちを追出させたいというようなことができるようになります。次はポータルサーバーの構築ですがこれは問題点としては仮想マシンと物理サーバーのマシンに管理機能に差があるためポータルからの操作が異なります。なのでユーザーが間違って仮想マシンしかできないような操作物理マシンで選んでしまうとかそういったことが言って使いにくい。ポータルサーバーを作る仮に作るときも争かじめ操作可能な機能のみにメニューを絞るとかそういったような工夫をするといったことが開けます。ここに監視サーバーでの監視ポイントですがこれは一般的に言われていることなんですけどオープンスタックの監視のみではプロセスの精子監視だけペースメーカーです。しか対応していないというのが一般的だと思っています。なのでその他のAPI監視とかハードウェアの故障とかいったようなものは外から監視する仕組みを作ってあげないといけないと。例えばこの例ですと特化構成を組んでいると片パスの障害が起こるとサービス自体を落ちないで本当にパスだけ切り替わるようなことがある。そういった場合でも検知はしないといけないのでオープンスタック上では正常に動いているように見える場合でもハードの監視はちゃんとしないといけない。あとはストレージの障害とかも監視しないといけないといったことがあります。あとこれはちょっとちなみになんですが物理マシンの管理機能というのをご紹介します。弊社はバタージュといってサーバーのリソースを論理分割する機構を思っているそういうサーバーがありましてそれをオープンスタックと連携して管理するということを行っています。そこでは物理マシンの制限を一部改善していて例えばスナップショット物理マシンは取れないんですけどバタージュでは取れるということがあってインスタンスのライフサイフィクル管理デプロイスナップショットでバックアップ取ってそこからあげるといったようなライフサイフ管理が用意になっています。これは弊社の展示ブースでデモを行っていますのでご興味があればぜひおとちゃい振りください。事例1は衣装になれますのでここから試し芸にバトンタッチします。ひたち制作所の試し芸です。私はひたち制作所の中のR&D研究開発本部というところに属してましてまたOSSテクノロジーラボラトリーという組織にも属していてそこでOSSの理活用というところを中心にやっています。研究開発しています。次からはVMAと連携してオープンスタックどういうふうに使っていくのというところについてお話ししたいと思っています。まず背景なんですけれども多くの企業の方々がサーバーコンソリ目的にVSphereを導入されていて基礎のオンプレミスの環境から仮想化を使ってコスト削減というのを実現されています。これによって物理サーバーの台数が圧縮されて物理サーバーの管理コストは横前になっているんですけれども仮想サーバーの台数がパッと増えちゃったので仮想サーバーの管理コストが上昇しています。この管理サーバーのコストを下げたいというところがまずモチベーションとしてあります。VMA社のVSphereを使っていろいろサーバーコンソリした結果そこにたくさん投資をされているわけです。ユーザーの方々が投資されているわけです。その資産の島がたくさんできていて仮想価からクラウド運用コストを下げたいということで仮想価からクラウドへって言った時にそこの投資したものを有効活用した上でクラウド行きたいというモチベーションが必ずあるはずだというふうに思っていてここで出てくるオープンスタック使ってみたいというお客様のニーズもありますのでそことを連携させてその資産を有効活用した上でオープンスタックを使ってクラウド環境へ持っていくというところを実現するという必要が出てくるというふうに考えています。この仮想価だけ使っている状態だとVSphereと言えせくさいとここだけなんですね。これにプラスオープンスタック隣のやつオープンスタック乗っけただけこれ何ができるかというとゆっちゃんとフラットなネットワークになるんで車内運用とかですねシングルテナントで運用するようなクラウドっていうプライベートクラウドに向いているというふうに考えています。これにプラスNSXとかっていうそのプライベートクラウドを使えることによってマルチテナント対応できるんでそれは例えばサービス側の方が使うクラウドっていうのに対応していくのかなというふうに考えています。このまず仮想価から仮想価の時期からオープンスタック使ってクラウドっていうのをどんどん行くんですけどまずオープンスタックをかぶせて移行初期というところがあってまず移行します。次にマルチハイパーバイザーの環境ということでKVMとVMウェアでオープンスタック使った環境最終的に移行完了期ということでKVMフルーKVM使ってオープンスタックの環境というふうなステップを踏んでいくというふうに考えています。このジャンプして最終の移行完了期に行くっていうのはなかなかコストが高くてVMDKからV2Vitaとか新規構築コストがなかなかかかかるのでジャンプはなかなか難しいのかなというふうに寝らんでいます。なのでステップを踏んでいくとここで注目するところとしてはここで終わる人もいるんですねここで止まる人もいるんですねだからそれぞれのソリューションを持つ必要があるというのが一つ気づきかなと思っています。これも移行初期っていうのを最初に先ほどの話したんですけどもこれってオープンスタックパッと乗っけるだけできるかとそういうわけでもなくて基礎のVMをオープンスタック環境へ取り込んであげるとかっていうところの移行のテーマがかかるとそれもどうやってやったらいいかというところのソリューション立てが必要です。そういう課題があるんですけどもここっていうのはそもそも先ほどから述べている移行初期仮想化の投資を活かしつつクラウド移行していく期間と定義していてここはオープンスタックのノウハウをお持ちでないユーザーの方々にベンダーやディストリビューターがアシストしてあげる必要があるというふうに考えています。これが先ほど来から述べているユーザー連携ということになります。次の状態として移行中期というのを定義していましたけどもこれはVMRとKVMが混在するような環境ですね。こういうマルチハイパーバイザーのサポートっていうのが必要になってきてここでは異なるハイパーバイザーっていうのが課題としてネットワークとボリュームの扱いが変わるとかやってますけどそれぞれのドライブが違ってくるのでそこをどうやって共存させるかというところが課題になってきます。今日はマルチハイパーバイザーというタイトルにあったんですけれどもさっきからベアの話だというのもしてますしこのVMRのところの字幕をどうやって連携させていくかというところについての気付きをまずお話をこの場ではさせていただこうかなと思っていますこの移行初期というところのものをまず仮想化の環境を作ってコンソリしましたでオープンスタックの環境を組んでクラウド運用活用クラウドの運用をしますこうするとここの構成デイビーに所を動機してあげない持って行ったりあげないといけないんですねVMRの情報をこちらの方に持って行ってあげないといけないという問題がありますKVMと先ほど来たKVMと比較というこのところを見てみるとハッチングしてあるところのイメージから作成ボリュームから作成といったところここで初回期同時に非常に時間がかかるというところが見えてきましたあとですねスナップショットの採取が数十本なんですね初回期同デプライの時にちょっと遅いというだけじゃなくてスナップショット取るごとに止まっちゃうんですねこれはこれで問題なんですけれどもこちらは気づきは一応こちらの方で回転する方法を使ってこちらもちょっと早くするだとか例えばこれはKVMも一緒なんですけれどもストレージ側にオフロードしてストレージ側の機能を使って早くスナップショット取るということができるとでこの話を戻しまして初回期同に10分以上かかるというところでキーストーンのトークンの有効期限を適切に設定してないとエクスパイアシャってというのがあるんでここは対策として何もやらないでする場合にはこういう対策が必要になりますで先ほど10分今日かかるというところのちょっとどういったことが僕らで行われているかというところを説明しますとでノバコンピュートがグランスからイメージを引っ張ってきてでその右から左へノバからVセンターにポイポイポイ投げていくというような流れになりますでこの流れはそうなんですけどこの1回やることに10ミリセック止まるんですね10ミリセック止まってまた64キロバイトというような作りになっていてこれ何でかというとこのVセンターとノバコンピュートに負荷をかけないここの3PUの貼り付きというのを抑える負荷が高くなっちゃってここが動かなくなると他の人に目をかかっちゃうんでここの負荷を抑えるためにいたと思われるんですけれども10ミリセックのスリップが入るようになっていますでこれが入ることによってですねこの6.4メガーキロバイトパーセックでここはさちっちゃうここのスピードがさちっちゃうということがありますでそこは遅いであとですねここVSphereの中でもあのコピーしてディスクのタイプをスパースからフラットに変換してでメタデータであのESXVSphereが超える形のイメージに変換してやるということが必要でそこのコピーがはかかっているとこの2つ1 2 3ですねここで時間がかかっているとでいうことがわかりましたでこれをこういうものがあるのでそうするとどういうことを考えられるかというとコピーのサイズをそもそも小さくしてやると小さくするさっきほどコピーやっている時間がかかるよという話をしましたのでそのコピーを小さくするイメージサイズを小さくするとまったんじに速くなるというのはありますただこれでも劇的に速くなるわけではなくて半分くらいですね時間として半分くらいなるくらいであとはですねイメージから新規ボリューム操作ホライゾンからの操作としてイメージから新規ボリュームで起動するという操作を選びますでこれはコピーするときにディスク種別がシックになる操作を選んじゃうと遅くなるちゃうのでそれを選ばないで何を言ってるかというと死んだ経由でストリームオプディバイズを使えるのでディスクタイプシーンになりますこうやって圧縮してやることでコピーを速くすることができるとあとはですねノバーの設定でリンクドクローン有効化しておくんですねそうするとキャッシュ作るときにキャッシュを作った後キャッシュを作った後次にVM作成ってやるとすぐにもうAPI2つ呼んで帰ってVM作成完了早いんですね5秒ぐらいですでこちらは提案としてさらに速くする方法として考えているのがあらかじめイメージを転送しておくということですねやれって言われたときに初回軌道のときだけ遅いんでその初回軌道に相当するイメージが作成されたときに遅くということですねあとはVセンターをバイパスするということができてそういうことをESXIに直接流し込むということもできますそうすることによって速くできるというふうに考えていますあとはですねチューニングのポイントとしてはホライゾンのコンソール表示ができないというところはちゃんとファイアウォールだとかVMインスタンスの音中のボリュームアタッチはアダプタータイプを適切に設定することでちゃんとアタッチをすることができますテラントネットワークですね先ほどちょっと触れましたけどNSXだとかあとノバンのネットワークを使うことでVLANを使えるのでそうするとVLANを使ったマルチナナンシー機能が実現できるということになります仮想化からクラウドへ移行する場合に移行機がありますVMR連携というのが必要になりますということですねあとオープンスタックのVMR連携に関して仮想化からすぐ移行できる仮想化のソリューションがすぐに移行できるものとしてフラットネットワークの社内運用というのがあるというのを話しましたあとホライゾンからの操作を利用とVMR連携の操作ではオムネ・ドートの結果を得ていますインスタンスの起動に関しては初回に10分10分です10分強化がありますがこれはイメージ転送のスループとは低いこととキャッシュを作るためがコピー操作に時間かかっているということをお話ししました最後にコピーのサイズを小さくするかあらかじめイメージ転送を完了しておくことで今回のインスタンス起動は高速ができるということをお話ししましたこうすることによってVMRを使ってオープンスタック環境でクラウドを構築ということができるようになります事例2の方は以上でしてこれで本発表を終わりますありがとうございました質問がある方がいればお答えしますバター柱と連携してお話しされていたかと思うんですけど具体的にどのような形で連携されていたかというのをもう少し教えていただけるとバター柱自体はご存知でしょうひたち様のエルパーの敵のルジそうですねエルパー1個1個オープンスタックからインスタンスとしてみてさせていてオープンスタックからのインスタンス作成という操作でバターを切り出してボリュームをくっつけてブートするというところまでをやるというノバノブートバター柱がそうですねそういったいうことをあとは消したりバックアップ撮ったりというのもライフサイクル感じで回せるというところをやっています実際に動いているデモが展示でありますので詳しいところがと思いますありがとうございます終わりたいと思いますありがとうございました