2016/08/30

VMworld 2016 Day1 General Session 国内最速レポート

皆さん こんにちは
5年連続5回目のVMworldに参加中の工藤です。
今年は私から現在開催中のVMworld 2016の初日のGeneral Sessionの速報をお送りします。

Image_2

このままクラウドの普及が続くと2021年に漸くトラディショナルなインフラが50%になる予測を披露しました。

Image

そんなクラウドとオンプレミスが共存するIT基盤においてFreedom とControlの両立を実現するHybrid Cloudを提供するのがVMwareのミッションであると発表されました。

そんなHybrid Cloudを実現するCross Cloud Archtectureとして以下のような発表がありました。

  • 統合基盤ソフトウェア「Cloud Foundation」の発表
  • マルチクラウド管理のSaaS「Cross-Cloud Services」の発表

今回は統合基盤ソフトウェア「Cloud Foundation」について紹介してみたいと思います。

■「Cloud Foundation」の発表
ITmediaの三木さんが既にこちらで紹介されていますが、最近のトレンドであるHyper Coverged Infrastructureの新しいモデルとして「Cloud Foundation」が発表されました。既にこちらに製品ページから発表された内容を確認することができます。

■「Cloud Foundation」って何?

「Cloud Foundation」は一言でいうと、vSphere + Virtual SAN + NSX + SDDC Managerで構成されたソフトウェア群の名称です。従来「EVO SDDC」として提供されていたものを置き換えるものとなります。以前のEVO:RAIL、現在のVSAN Ready NodeやEMC VxRAILのようなアプライアンスはvSphere + VSANだけの統合でしたが、NSXまで統合されることによってネットワークまで含めた提供のなっている点が異なります。Hyper Converged Infrastructure業界のリーダーであるNutanix社の掲げる「Enterprise Cloud」のビジョンとも似ていて、パブリッククラウドのようにシンプルにするにはオンプレミスのインフラもシンプルにする必要があり、それをソフトウェアで実現するVMware社のソリューションともいえるのはないでしょうか。

■「Cloud Foundation」ってソフトウェア単体で構築するのと何が違うの?

「Cloud Foundation」で追加された「SDDC Manager」は現在のところ物理リソースを管理して、サーバ仮想化の基盤(VI)と仮想デスクトップの基盤(VDI)を裏で展開を自動化し用途に応じて払いだすことができるそうです。そして展開されたソフトウェアコンポーネントを含むソフトウェア群のアップデートのライフサイクル管理が提供されます。

Sddcmanager_2

また今後Cloud FoundationがvRealize AutomationやvRealize Business、Integrated OpenStackに対応してDevOPSの基盤やvCloud Foundationのコスト管理などの機能追加がされる予定です。

Sddc

■「Cloud Foundation」はどうやって提供されるの?

今までのHyper Converged Infrastructureに対するVMware社のアプローチ同様VMware社からはソフトウェアだけを提供し、エコパートナーからHyper Converged Infrastructureとして提供される形をとっています。現在3つの提供形態が予定されています。

  1. 統合アプライアンスとしての提供
  2. Ready Nodeの提供
  3. パブリッククラウドとの連携

統合アプライアンスとしてはEMC社よりVCE VxRack1000 SDDCとして提供がされる予定です。Ready NodeとしてDELL社、HPE社、Quanta社より提供がされる予定です。そして最後のパブリッククラウドとの連携ではIBM Softlayer上で提供された後、vCloud Air、vCloud Air Networkが追加されていく予定です。

■まとめ

Cloud Foundationを実現することで、オンプレミスとパブリッククラウドをまたいだハイブリッドクラウドを実現することができるようになります。今回のGeneral Sessionで発表されたCross Cloud Serviceもこうした基盤がある前提になるような気がしています。オンプレミスのインフラをシンプルにするCloud Foundationに皆様ご注目ください。

また9/14,18にVMworldの内容をまとめてわかりやすく解説するフィードバックセミナーを予定しております。興味のある方は是非こちらにいらっしゃってください。

VMworld 2016 フィードバックセミナーhttps://networld.smartseminar.jp/public/seminar/view/668

次回はこのCross Cloud Serviceについて紹介していきたいと思います。

2016/08/22

[最新鋭、IBM FlashSystem A9000大解剖!]

IBMの最新鋭の超高速フラッシュストレージ FlashSystem A9000をお借りしちゃいましたっ。

実際に動かしてみようっ♪


いきなりですが、「実際に動かした結果を速く視たいんだけどなぁ♪」 とボスから指令がっ!!
ということで簡単な環境をつくって少しだけ試してみましたっ♪

さっそく、サクッと図のような環境をセットアップ~っ♪

A9000test1

で、何をしようか・・・・・♪

とりあえず、代表的な機能のテストをやってみようかなっ。実機でっ♪


重複排除って本当に効くの!?

**A9000上、単一ボリューム内で複製をした場合**

1個のデータストア内でVMを複製してみましたっ♪

1:ESXiのデータストア用にA9000上に約1TBのボリュームを1個作成
2:このボリューム内に1台目の仮想マシンを作成
3:同じボリューム内に1台目の仮想マシンのクローンを作成して2台目を作成
4:同じボリューム内に、残りの仮想マシンのクローンを作成して合計10台を展開
*(仮想マシンには、WindowsServer2012R2をインストールしました。)

Ffx417

その結果がこちらっ♪

姐さんっ!重複排除、効いてますぜっ!!
(約98パーセントの排除率を確認できました。)

Clonevm


続いてぇ~っ♪

**A9000上、複数のボリューム上に同じデータを複製した場合**

10台のVMそれぞれにRDM(ローデバイスマッピング)の領域を追加してデータをコピーしてみたっ♪

1:A9000上に50GBのボリュームを10個追加作成する。
2:先ほど作成した10台のVMそれぞれに1個づつRDM領域としてDiskを追加する。
3:10台中1台目のVMのRDM領域にダミーデータを書き込む。
4:他のVMにもそのダミーデータをコピーする。
*(ダミーデータは合計約10GBの、pdfやpptなど単体では圧縮の利き辛いアトランダムなドキュメントファイル群です。)

Ffx418

兄貴っ、やはり重複排除、効いてますぜっ!!
(2台目以降の重複排除率が9個平均で約88.4パーセントという結果になりましたっ♪)
おやおや~っ、これってVDI用途なんかには超絶効果が期待できそうじゃなイカっ!!(マジで期待していいと思うっ♪)

Qq

★この「重複排除」はA9000/A9000R上の単一ボリューム内だけでなく複数のボリューム間であってもその効果を実感できるんですっ!



あっ!、そういえば!!圧縮はどうなのよっ?

ということで、実際にデータベースを動かして試してみましたっ♪。
1:今度はサーバーのローカルに3台のVMを作成するっ
2:A9000上に10TBのボリューム3個を作成するっ
3:3台のVMそれぞれに1個ずつRDMでディスクを追加っ
4:RDMの領域にサンプルDBをロードするっ♪
*(各DBの最終的なファイルサイズは平均約1.7TB)

Dbb

ボスっ!重複排除の効きにくいDBのようなファイルでも圧縮効いてますぜっ!!
ファイルサイズ平均1.7TBの状態
(圧縮率3台平均で約47パーセント)

Final01


今回は短時間で行ったほんの一例ですが、どおやらデータ削減の効果は大いに期待できそうであるっ♪

他にも「マルチテナンシーのQoSの効果っ♪」や、「超絶IO負荷地獄」、「帯域の鉄人」、「パターン排除の飽くなき削減」
など、やってみたい事はいっぱいあるので、今後少しづつでもご報告できればと思いますっ♪

次回は、「筆者もびっくり!何があってもデータは守りきるっ!究極の電源機構っ!!」


by:まいけル

2016/08/18

サンドボックス化された完全なマネージドOpenStackのテストドライブ(Platform9を体験してみたい方!お待たせ致しました!)

本記事の原文:Test-drive Fully Managed OpenStack in a Sandboxの公開は2016年の8月5日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

Platform9製品詳細についてはこちら

Platform9はSaaSベースのマネージドサービスを利用して、OpenStackによるプライベートクラウドの展開、稼働、管理そして拡張をご提供しています。展開は数分で済みます。Platform9はSaaSレイヤーにOpenStackのコントロールプレーンを稼働させ、皆様にやっていただくことはKVMホストへエージェントをインストールするか、vSphere環境に(仮想)アプライアンスを動作させるだけです。

展開は非常に簡単で数分で終わりますが、我々はそれをもっとシンプルにし、Platform9をご自身の環境でインストールする前に試してみていただきたいと思っていました。今回、自由に探検いただけるOpenStackのサンドボックス環境をアナウンスできることを誇りに大変喜ばしく思います!

サンドボックスへのアクセスはhttp://www.platform9.comへアクセスし、サインアップしてください。

ログインを終えると、多くはありませんが組み込みのGlanceイメージと仮想マシンのフレイバーにアクセスできるテナントのロールが割り振られます。ここから簡単に仮想マシンを展開し、コンソールにアクセスしたりや起動、シャットダウン、仮想マシンの構成変更などのデイ2(展開が終わった翌日)の運用を試してみていただくことが可能です。ユーザーインターフェイスから殆どのワークフローを実行することが可能となっています。これはサンドボックス環境ですから、ホストの追加やルーターの追加、新しいGlanceイメージのアップロードなどの特定の運用は行えません。我々はサンドボックス環境へ随時新しい機能を加えていきます。

サンドボックスは最初のログインから4時間だけ利用することが可能です。もし、もっと時間をかけてPlatform9 Managed OpenStackインフラストラクチャを試してみたいと言う場合にはいつでもフリートライアルへアクセスいただくことが可能です。

さぁ、まずhttp://www.platform9.comまでアクセスを!

冒険を楽しんでください!

訳注: リソース上の都合で国内ではフリートライアルへのお申し込みを制限しておりました。今回利用可能になったテストドライブ(http://www.platform9.com)はこの制限を受けません。誰でも、いつでも、Platform9 Managed OpenStack環境を4時間好きなように利用することが可能です。上の記事でも述べられている通り、テナントロールでのアクセスを想定しているため、完全な管理者アクセスにて評価を行いたいという場合には以下のWebセミナーへお申し込みください。

【Webセミナー】Platform9 Managed OpenStack Web&デモセミナー
話題!日本上陸直後のPlatform9 Managed OpenStackを徹底解説 & デモを実施

昨年、OpenStack Summit 東京での開催、先日開催OpenStack Summit Days Tokyo 2016の大成功、大規模な導入事例発表など、OpenStackの熱気はいよいよ日本国内へも押し寄せてきています。
しかし、OpenStackはオープンソースプロジェクトでそのものはフリーで提供されていますが、そもそもインストールが難しい、運用管理していく手間とコストが膨大になる、アップグレードがうまくいかないなど、一般的な企業のお客さまにとっては多くのハードルを抱えています。

本セミナーではOpenStackの5つの展開方法とそのメリット・デメリットを上げた上で、
Platform9社が提供するユニークなOpenStack-as-a-serviceについてご紹介致します。
これまでになかったアプローチでのOpenStackの利用開始、運用、そしてその効果についてあますところなくお伝え致します。
本セミナーへご参加方にのみ、Platform9 Managed OpenStackのフリートライアルアカウントをお渡し致します。是非奮ってご参加ください。

さらにここまで読んでくださった方向けのオトク情報!!

@Networld_pf9 アカウントをフォローした上で、本セミナーの登録ページへのツイートをリツイートしてくださった方にはセミナー実施前にも優先的にフリートライアルの割当を行っております。

記事責任者 マーケティング本部 三好哲生 (@Networld_pf9)

2016/08/10

HyperFlexのバックアップはVeeamにお任せ!

先月、弊社ではCisco HyperFlexとVeeamの共同セミナーを全国4拠点で開催し、ニュースサイトでも紹介されました!
http://biz.bcnranking.jp/article/news/1607/160711_142672.html

そこで、セミナーにご参加いただいた方には重複する内容になりますが、今回はVeeam Backup & Replicationを使用したHyperFlex環境のバックアップについてご紹介させていただきます。


①  HyperFlexとは?

こちらでご存じの方もいるかもしれませんが、今年3月に発表されたCiscoのハイパーコンバージドインフラ製品で、Fabric Interconnect + UCSサーバのハードウェアで構成され、SDS(Software Defined Storage)+管理ツールが含まれます。SDSはSpringpathのものを使用しており、重複排除と圧縮が標準機能になっています。

Hxveeam1

②  何故、HyperFlex+Veeam?

HyperFlexはVMwareの仮想環境に特化したハイパーコンバージドインフラ製品であり、Veeamも仮想環境に特化したバックアップ製品で相性ピッタリの組み合わせです。また、HyperFlexはUCSのノードを追加することでスケールアウトに対応できますが、Veeamもバックアップ処理を行うプロキシサーバやバックアップ保存先となるリポジトリを追加することでHyperFlexにあわせてスケールアウトに対応できます。

Hxveeam2_2これは弊社の勝手な思いつきの組み合わせではなく、Cisco社とVeeam社はアライアンスが組まれており、既に海外ではHyperFlexとVeeamがセットになったアプライアンス製品も販売されています。

https://www.cisco.com/c/dam/en/us/products/collateral/servers-unified-computing/ucs-c-series-rack-servers/whitepaper-CiscoVeeam.pdf

Hxveeam3_2

③  VeeamでHyperFlexをバックアップしてみよう!

物理のVeeamサーバを用意して、NBDモード(10Gネットワーク経由)で、1つのバックアップジョブで仮想マシン(Windows 2012 R2/100GBのVMDK)を1台/2台/3台/6台/9台/12台と台数を変えて、HyperFlex上の仮想マシンをバックアップしてみました。

【検証構成】

Hxveeam4_6

Hxveeam4a_5 

その結果が下の表です。

Hxveeam5

注:

※バックアップ時間は3回実行しての平均値になります。

※仮想マシンはHyperFlexのクローン機能を使用して用意しました。

※仮想マシンは起動した状態であるため、バックアップ容量はログなどにより差異があります。

※仮想マシンは各ESXiホストに均等に配置しております。(例)12VMの場合は、1ESXiホストに4VM配置

※プロキシサーバの同時タスク数(デフォルト:2)、リポジトリの同時タスク数(デフォルト:4)、データストア毎のスナップショット数(デフォルト:4)の制限は解除しております。

※弊社の検証環境での値であり、全ての環境で同等の数値が出ることを保証するものではありません。

 

1台だけでバックアップした時間(4分弱)も十分早いですが、台数を増やしていくことで、1VMあたりの時間が一層短くなっていきました。6台以上の場合は、なんと!1VMあたり、1分を切る高速バックアップです!!Thin DiskとThick Diskも数秒程度の違いしかありません。

SpringpathのSDSが重複排除・圧縮が標準機能ということで、バックアップ(読み取り)に時間がかかるのでは?と心配した方もいるかもしれませんが、安心してください。こんなに高速にバックアップすることができます!! 

あまりのバックアップの速さに信じられない方は、下記の無償の製品評価版で試して、第3者の厳しい目で判断してください。

Veeam Backup & Replication製品

Veeam製品評価版入手手順

評価ガイド(日本語版)

HyperFlex+Veeamは安心・確実な組み合わせです。日本でHyperFlexとVeeamの両方を販売できるのはネットワールドだけですので、HyperFlexのバックアップを検討している方は、お気軽に弊社までご相談ください。HyperFlexに限らず、ハイパーコンバージドインフラ環境のバックアップにお悩みの方からのご相談もお待ちしております。

担当:臼井

Platform9上にPlatform9を動作させる

本記事の原文:Running Platform9 on Platform9の公開は2015年の2月3日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

Platform9製品詳細についてはこちら

僕らも自分のケーキを食べてもいい? 数ヶ月のコンセプトから本稼働環境での利用に至るまでの開発を終えた我々が、自分自身と我々のプライベートなPlatform9 Managed OpenStackのインスタンスに問い続けた質問です。我々はこれを親しみの意味を込めて「ドッグフード」と呼び、日々のビジネス ー継続的な統合と検証ー の大部分で活用しています。

少し前置きを。ご存じの方もおられると思いますが、Platform9はエンタープライズの顧客がご自身のインフラストラクチャのリソースを集約し、柔軟なプールへと変えるようなビジネスをしています。プール化されたインフラは最新鋭のオープンソース・ソフトウェアを利用してPlatform9によって稼働、管理されおり、サービスとして提供されています。マネージドOpenStack、これが我々の最初の製品はこのモデルです。そして、顧客に社内のサーバ、ストレージ、そしてネットワークを利用しながら、完全なOpenStackで構成されたプライベートクラウドを提供します。しかも、複雑なソフトウェアのインストール、構成、拡張、バックアップ、アップグレードは顧客からは見えません。これをどうやって実現する? クラウドのメタデータとコントロールソフトウェアを展開ユニット(Deployment Unit - DU)と呼ばれる要素の集合としてホスティングします。セキュリティのために、それぞれの顧客は自分自身の、完全に隔離されたDUを割当て、それをPlatform9が管理します。

最も単純な形では、DUはデータベースとGlanceとNovaの管理要素(API、スケジューラー、コンダクター、ネットワーク)のOpenStackコントローラーサービス群からなります。顧客のニーズが大きくなるにつれ、DUは複数のサーバーへと拡張することが出来、さらには地理的にも広がっていくことが出来ます。これによってパフォーマンスと可用性を上げていくことが出来ます。簡単のため、この記事では1サーバで構成されたDUにフォーカスします。我々はDUがほとんどあらゆるコンピューティングインフラストラクチャ上で動作するように設計しました。例えばパブリッククラウドや自分自身のデータセンタで動作します。若いソフトウェアカンパニーと同様、我々も必要なコンピューティングを得るためにAmazon Web Services(AWS)を利用することにしました。


  +------------------------------------------------------------------+
  |               展開ユニット (Deployment Unit - DU)                | 
  | +-----------------+ +-------------------------+ +--------------+ | 
  | | PF9コントローラ | | OpenStackコントローラ群 | | データベース | | 
  | +-----------------+ +-------------------------+ +--------------+ | 
  +------------------------------------------------------------------+
            /                              
           /                                
          /          インターネット              
- - - - -/- - - - - - - - - - - - - - - - - -  - - - - - - - - - - - - - -
        /          顧客のイントラネット           
       /                                        
+--------------------------------------------------------+    +----------+
| +------------------------+ +-------------------------+ |    |          |
| | PF9 ホストエージェント | | OpenStackエージェント群 | |    |          |
| +------------------------+ +-------------------------+ |....|          |
|                         ホスト 1                       |    | ホスト N |
+--------------------------------------------------------+    +----------+

多くの近年のクラウドソフトウェアの設計に習い、OpenStackはコントローラ/スレーブのアーキテクチャを採用し、インフラストラクチャの要素を管理・監視します。例えば、コンピューティングホストの管理のため、OpenStack Novaはnova-computeと呼ばえるスレーブエージェントを各管理対象ホストに配置します。最初のManaged OpenStackのリリースでは、ホストはサポートされているLinuxディストリビューション(現在はUbuntu 12とCentOS6 ※訳注原文記事執筆当時の情報です)が動作していればどんなホストでも構いません。コンピューティングキャパシティをプライベートクラウドに追加する際には、顧客はまず、それぞれのホストにゼロコンフィグレーションのPlatform9のホストエージェントを展開します。それぞれのホストエージェントは自身がインストールされているホストをセキュアなアウトバウンド接続を利用して顧客の展開ユニットに登録します。承認(authorization)と呼ばれるステップを通じて承認されると、エージェントはDUに対してホストにとって適切なソフトウェアや構成を問い合わせ、自動的にダウンロードしてインストールし、それらのソフトウェアの構成を行います。特定のホストに適切なソフトウェアの分配を決定する際にはホストにアサインされた役割(role)によって決定します。例えば、普通はコンピューティングホストはnova-computeエージェントを受け取ります。一方で、イメージライブラリホストはPlatform9が特別にパッケージしたソフトウェアを受け取り、それをイメージキャッシングサーバとして利用します。一つのホストが複数のロールを持つことも可能です。まとめると、図1になります。これが通常の顧客の目線から見たManaged OpenStackの展開の様子です。

継続的な統合と検証

Platform9のトッププライオリティは製品を高い品質に保つことです。Managed OpenStack(MO)を検証するため、我々は継続的なビルド&統合サーバ(Teamcity)を用いて、要素/機能検証と統合テストを組み合わせて実施しています。我々は大抵は1つのgitリポジトリを機能コンポーネントごとにメンテナンスしています。Managed OpenStackのリリースのために必要なバイナリを生成する際に、全体で12ほどのリポジトリからのコードのビルドと検証が必要です。リポジトリのうち、いくつかはPlatform9ヴァージョンのOpenStackコンポーネントですし、残りは完全なPlatform9だけのソースコードです。標準のOpenStackのコードは広範な機能検証が含まれており、OpenStackのリポジトリにコードがチェックインする度に検証コードが動作します。

統合テストはもっと複雑で、製品全体を検証し、さらにコンポーネントの展開や接続までを最終形として実施する工程までを含むため、完了までに長い時間がかかります。Managed OpenStackの展開トポロジは通常のOpenStackとは異なっていますので、Platform9固有のシナリオー例えば、ユーザーの認証、ホストの認証、イメージライブラリからのインスタンスの展開、ネットワーク機能、NFSのサポートーでの検証のために多くの統合検証コードをスクラッチから書き起こしました。これを書いている最中にも、17の大きな統合テストが成功に終わることをまっています。上手く行けばManaged OpenStackのビルドがうまくいくということです。それぞれの検証は自分自身で1~15ホストー平均的には大体3ホストーの展開ユニットを作成し、多くの項目に渡る、小さな検証を実施しています。標準では検証用の展開ユニットは1台のコンピューティングインスタンスからなっています。大抵の1つのMOで17の展開ユニットを展開しますので 3 x 17 ~= 50ホストのインスタンスが稼働することになります。ピークの時期になると、CI(継続的な統合)サーバは1日に10回はMOの作成を行います。つまり、170の展開ユニットで500ホストインスタンスを稼働させているということになります。

仮想化環境上に作られた検証インフラストラクチャ

上で述べてきた検証の負荷の推測はあくまで本日(訳注:記事執筆当時)のスナップショットです。もちろん、初期には負荷はずっと軽かったです。他の若い会社と同様に、我々のニーズは最初の一年間で劇的に成長しました、そして、幾つもの失敗の中から多くの教訓を学んだのです。我々の検証のニーズに適合するために、今日我々が検証インスタンスを動作させているインフラストラクチャとその検証を自動化している方法は以下のテーブルにまとめてあるように進化してきました。興味を引くポイントは我々がどのように仮想化を活用し、ソフトウェアのレイヤーを積み上げているかです。

Fig008

フェーズ 1

当初、当然のように我々は検証環境を実際に利用される環境にできるだけ近い形で作成しました。つまり、展開ユニットはAWS上で、Platform9のささやかなデータセンタ内におかれた実際のサーバをコンピューティングホストとして利用します。これはたいていのお客様が経験するであろうセットアップの環境を再現するためでした。このアプローチで我々は2つの問題に突き当たります。一つ目はホストが実際のCentOSまたはUbuntuが動作しているLinuxコンピュータですから、それぞれの結合テストの前に初期状態に復元するためのスクリプトを開発しなくてはならなかったことです。「bit rot(訳注:長時間にわたってコンピュータを使うことでメモリやデータに小さな変化が積み重なり、不安定になること)」と呼ばれる概念をご存知の方もおられると思いますが、これは言うほど簡単なことではありません。様々な努力にもかかわらず、何度もサーバはコントロール不能になり、検証の結果は一環したものにならず、バグを診断するのが難しくなってしまいました。もっと大きな問題は拡張性です : 単純に、我々は増え続ける検証の負荷に見合うだけの十分なハードウェアを購入できない状況になったのです。


   +----------------------------------------------------------+
 2 | 統合検証中に Nova インスタンスが作成される               |
   +----------------------------------------------------------+
 1 | 物理サーバ上の Linux KVM ホスト上のPF9 compute/imagelib  |
   +————————————————————————————————--------------------------+

フェーズ 2

これらの問題を解決するため、我々は以下の表に表したとおり、PF9ホストが動作する検証インフラストラクチャをハイパーバイザー上(最初はESX、そしてその後KVMが動作するネイティブのLinuxへ変更)の仮想マシンへと変更しました。これによって、入れ子になった仮想化が追加されることになります。つまり仮想ハイパーバイザー(2層目)が仮想マシンとして実際のハイパーバイザー(1層目)の上で動作するということです。ESXとKVMはいずれも入れ子の仮想化をある程度の信頼性を持ってサポートしています。(我々はESXがやっぱり素晴らしいということと、ですが、非常にパフォーマンスが限られている場合、KVMのほうが高速で、やっぱりバグや不可解な動きがあることを発見しました。これはこれだけでもう一つ記事が書けそうです。)


   +----------------------------------------------------------------+
 3 | 統合検証中に Nova インスタンスが作成される                     |
   +----------------------------------------------------------------+
 2 | それぞれの検証毎に PF9 compute/imagelib Linux KVM ホストを作成 |
   +————————————————————————————————--------------------------------+
 1 | 物理サーバ上の ESX または Linux KVM                            |
   +—————————————————————————————————-------------------------------+

我々はPlatform9 Managed OpenStackホスト(2層目)で保持されている仮想マシンの作成や廃棄を担当する機能ライブラリを開発しました。ちょうどこの頃、我々は最初のエンドツーエンドの統合テストの開発を終えました、さらにPythonベースの検証フレームワークの最初のヴァージョンも完成します。社内のTeamcityの統合サーバはコードの変更イベントが発生すればビルドと検証をすべて行ってくれるようになっています。これはコード、ビルド、検証に至るまでエンドツーエンドで自動化統合が完成した時でした。これによって我々はManaged OpenStackの能力を確信もしましたし、品質の期待値を劇的に改善することになります。

フェーズ 3: 「ドッグフード」の誕生

コンポーネントの成熟し、さらに全体がしっかりと結合してくるにつれ、いよいよエンタープライズプロダクトらしくなってきました。我々は適切な機能についてや、適切なユーザーエクスペリエンス、どれだけの信頼性が必要とされるか、セキュリティ、パフォーマンス、拡張性など、数多くの議論を交わしました。終わりのないホワイトボード、ワイヤフレーム、プロトタイプの末に我々は自分たち自身がユーザーにならなければ多くの問題に答えを出すことは出来ないという結論に達しました。言い換えれば、我々の業務(もしくはその大部分)をPlatform9 Managed OpenStack上で行うということです。アメとムチでいうと、これはムチです。

幸運なことに、我々の継続的なビルド、統合、検証にはアメとなりました。我々のごちゃごちゃしているベアメタルのハイパーバイザー(1層目)の上で動作する仮想PF9ホスト(2層目)を管理するためのbashスクリプトやPythonコード群はどんどん複雑化し、維持していくのはまさに悪夢になってきました。我々はテンプレートイメージやホスト間の論理配置、ハイパーバイザーの違い(ESX、CentOS Linux、Ubuntu Linux)に対処出来るだけの綺麗な抽象化を実現していませんでした。こうした問題を解決するためにOpenStackが優れていることは明らかでした。一貫したAPI、CLI、リソースの抽象化、自動配置のアルゴリズムなどが搭載されているからです。

「ドッグフード」プロジェクトはこうして生まれました、そしてこれは今日までに当社がとったエンジニアリングの決断の中で最も大きなものの一つになります。ドッグフードは単にPlatform9 Managed OpenStackの単一のインスタンスです。その展開ユニットは「クラウド」(今はAWS)で動作しており、公開DNSのアドレスでSaaSとして公開されています。全てのコンピューティング、ストレージ、ネットワークリソースはすべてPlatform9のプライベートデータセンタに配置されています。

最初の実装では、我々はPlatform9ハイパーバイザーホストを仮想化していました。会社においてあるハイパーバイザー上で仮想マシンとして動作させていたのです。これは更にスタックに仮想化レイヤを追加することになります。結果は下の図のとおりです。我々はこの追加のレイヤをハードウェアの仮想化サポート機能を完全に利用できるうまい方法を見つけ出すことが出来なかったため、我々は仮想マシン上でQEMUエミュレーションを動作させるしかありませんでした。これはものすごく遅いのです。我々はパフォーマンスが犠牲になるのはわかっていましたが、幾つかの理由でこれを選択しました。まず、仮想(物理の反対という意味で)ドッグフードのハイパーバイザーホストは簡単に作成、管理、廃棄することが出来、それによって必要に応じてホスト数をスケールアップするような操作を簡単に行なえます。2つ目は、このやり方であればすでに持っている稼働率の低いハードウェアを利用できるので、それによって更に物理サーバを追加する際の選択肢も広くなるということです。3つ目は、この時点ではインスタンスを大量に起動する大部分の検証は単にインスタンスがアクティブ状態に到達することを確認するだけのものがほとんどでした。こうした際には検証は早々に終了させることが出来、インスタンスのゲスト内部のスピードはさほど重要ではなかったのです。


   +----------------------------------------------------------------+
 4 | 統合検証中に Nova インスタンスが作成される                     |
   +----------------------------------------------------------------+
 3 | それぞれの検証毎に PF9 compute/imagelib Linux KVM ホストを作成 |
   +----------------------------------------------------------------+
 2 | ドッグフード PF9で管理された仮想の Linux KVM                   |
   +————————————————————————————————--------------------------------+
 1 | 物理サーバで動作する ESX または Linux KVM                      |
   +—————————————————————————————————-------------------------------+

予定通り、我々は自動化のコードを変更してOpenStack Nova APIやCLIを活用できるようにしました。Bashスクリプトは大抵はCLI(nova utilityなど)を利用するために利用されています。そしてPythonコードはRESTをコールする際に利用しています。テンプレートイメージやコンピューティングインスタンスのライフサイクルは一貫した方法で管理できるようになりました。例えば、我々は「刈り込み」というスクリプトを利用して、ビルドの前や、検証の後の時間に古いテンプレートやインスタンスを削除します。様々な理由から、特定のテンプレートやインスタンスを削除せずに保持しておく必要性が出てきます。この機能を実装するため、我々はNovaとGlanceのオブジェクトメタデータにタグを追加し、テンプレートとインスタンスを同じ方法で取り扱うことを実現しました。メタデータのキーに「dont_delete」を追加しておけばよいのです。

フェーズ 4 : ドッグフード 2世代目

ドッグフードの最初の実装はちょっとした統合テストを行えば良いような、会社が小さいタイミングでは充分によく動いてくれました。これはその後の数ヶ月で多くの新しい開発者がチームに入り、多くの機能が追加され、製品の品質を強化するために動作させるビルドや検証の数が爆発的に増えていくにつれ、変わってしまいました。それだけではなく、レイヤ上で動作するQEMUのエミュレーションのパフォーマンスも、もはやインスタンス内のゲストOで動作する興味深い検証などが新しく生まれてきたため、受け入れられなくなってきました。例えば、ほとんどの我々のネットワーク関連の検証はゲストと他のゲスト、または外部システムとの接続を検証します。結果としてOSとして完全にブートが終わるまで待つ必要があります。こうした問題が重なると、ランダムに操作がタイムアウトし、検証に失敗します。これによって我々のエンジニアリングの生産性は地に落ちてしまいました。

我々はパフォーマンスの問題を解決するために、ドッグフードのための専用のハードウェアを購入しました。これによって以下の図のように1つ仮想化レイヤーを削減できました。Linux/KVMをベアメタル(1層目)にインストール、構成しないといけないという柔軟性の喪失は当然のトレードオフです。それを埋め合わせるために、我々はできうる限りのプロセスの自動化を進めました。例えば最初のOSのインストールにはPXEを利用し、Ansibleの構成管理ツールで各ノードに必要なソフトウェア構成を送り込みました。


   +------------------------------------------------------------------+
 3 | 検証中に Nova インスタンスが作成される                           |
   +------------------------------------------------------------------+
 2 | それぞれの検証ごとに PF9 compute/imagelib Linux KVM ホストを作成 |
   +------------------------------------------------------------------+
 1 | ドッグフード PF9 で管理された 物理 Linux KVM サーバ              |
   +————————————————————————————————----------------------------------+

フェーズ 5: ドッグフード 第3世代

ここに至るまで、すべての統合検証環境の展開ユニットは常にパブリッククラウド(AWS)上に展開されています。最初に述べたように、これは実際に利用される環境に可能なかぎり近づけたいという理由からでした。しかし、日々多くの検証のための展開ユニットが生成されるアプローチで、それが100を超えてくると、我々のAWSからの請求書は快適というレベルをあっという間に超えてきました。インスタンスを動作させているというコストからだけでなく、補助的に利用しているEBSストレージ、ネットワーク帯域、RDSデータベースなどからのコストも含まれている結果です。

我々はそれぞれの統合検証が何をしようとしているのかを見直し、殆どの我々の検証はDUが我々のプライベートなインフラストラクチャで動作していたとしてもその価値を失わないという結論に至ります。ですから、我々は検証をAWSではなく、ドッグフード上に展開ユニットを作成するように変換しました。念のためですが、我々はAWSとドッグフードの両方で様々な検証を行っています。我々は徐々に本日我々が利用している構成にシフトしてきました。ドッグフードでは様々な形で我々の日々の継続的なインテグレーションが動作しており、全てのコードのチェックインの度に実行されています。AWSでは定期的に、もっと小規模に実施しています。我々のAWSのためのコストは劇的に下がり、安定しました。しかしながら、ドッグフードを動作させ、適切なハードウェアのリソースを提供し続けるのも時間とお金がかかります。ですから、正確なコスト比較については詳細の分析を待たなければなりません。これが大きな削減になったようなら、またブログの記事を投稿します。

頻繁な更新

ドッグフードは頻繁にアップグレードやアップデートされます。我々のポリシーは実際に顧客のDUへ提供開始する数週間から数ヶ月すべてのコードの変更と昨日の追加を全て展開するというものです。我々はこうした更新を手動で行っています。今後は夜間に自動でアップグレードされるように変更しようと計画しています。

個人利用

加えて、統合検証などで利用するため、我々のプライベートクラウドは各々の従業員向けに個人利用のために開放されています。我々のMacやLinuxマシン上に、novaコマンドラインユーティリティを簡単にインストールし、標準的なOpenStackに接続する環境変数は:


[leb:/devel/pf9-main/testing]$ env|grep OS_
OS_USERNAME=XXXXXXX
OS_PASSWORD=XXXXXXX
OS_AUTH_URL=https://XXXX.platform9.net/keystone/v2.0
OS_TENANT_NAME=service

殆どの開発者は一時的なインスタンスでバグのトラブルシュートや数日で実装できてしまうような機能の開発を行います。他ではもっと長い期間のプロジェクトのために、長時間利用できるインスタンスを作成するか、単に個人の開発環境をホスティングします。我々はOpenStackのタグ機能を利用して、インスタンスやイメージに所有者や目的などの情報についての注釈を入れたりしています。また、頻繁に既存のインスタンスのスナップショットを取っており、試験を動作させる前の状態へと復帰出来るようにしてあります。ユーザーインターフェースについては社内のほとんど半分のユーザーはCLI互換でのアクセスをしていますが、残りの半分は大体はPlatform9のウェブユーザーインターフェイスを利用しているようです。

実体験からの教訓

我々が自分自身のビジネスをPlatform9 Managed OpenStack上で動作させ、ドッグフードを行うと決めた時、とても重要な予見を持っていました。それは、製品に血管があった場合に、我々の会社にすぐにも影響が出てしまうということです。これが我々にとってはトラブルシュート、原因の根本的な解決、問題の迅速な修正についての強いモチベーションになりました。これはまったくもって、予見したとおりでした。製品を日々利用し、ミッションクリティカルなタスクをそれに依存していく中で、我々が検証だけでは様々な理由で見つけられなかった問題を発見することが出来ました。

我々の例は運用が急激にスケールするものです。我々の最初の世代の結合テストでは5ホスト未満でコンピュートインスタンスも1から10インスタンス程度のもので、日々のビルド・検証では数百インスタンス程度の負荷でした。ですが、直ぐに数千インスタンスにも膨れ上がったのです。我々は全てのコンピューティングホストがアイドル状態であっても、それぞれのnova-computeエージェントのサブシステムのうちの幾つかが定期的にNova controllerに状態のアップデート、たとえばKVMの仮想マシンの数やその状態を送るということを知りました。それぞれのこのステータスメッセージはcontrollerに少しずつながら、負荷を加えてゆき、その負荷が充分に大きくなると、公開APIのリクエストの処理をスローダウンさせるということを発見しました。この問題が積み上がっていくと、APIの呼び出しがタイムアウトし、他のビルドタスクの開始に失敗してしまうのです。

他にも、拡張性関連の問題がブートストーム問題の中から燻り出されてきました。上で書いたように、現在製品全体の統合ビルドを行うと、17種類の結合テストが開始されるようになっています。これらのテストは並行して、初期化シーケンスを経て、最終的には50ほどのコンピューティングインスタンスが同時稼働し始めます。我々の統合ビルドサーバは同時に3つのビルドしか同時に走らないように構成されているので、結果としてピークの際には100異常のインスタンスが同時に走ることになります。適切なほどに能力のあるコンピューティングサーバを利用しなかったので、我々はソフトウェアのサブシステムの幾つかが、このスパイクを我々が期待しているほど上手く取り扱うことが出来ないということを発見しました。リクエストがバッチ的に集中する場合、nova-scheduler サービス(インスタンスの配置を決定する)がしばしば同じホスト上に異様に沢山のインスタンスを配置し、リソースを食いつぶしてしまうことがありました。見る限り、ロードバランシングのアルゴリズムがホストの負荷の変化に十分な速さで対応ができていないように見えます。今のところ、これが構成上の問題なのか、設計上の問題なのか追求を進めているという状況です。また、ホストが同時に多くのリクエストを同時に受信するとインスタンスのディスクの処理のための高いCPUとI/Oの負荷の処理で「libguestfs」のサブシステムでタイミングによるバグが出ることも見つけました。これはゲストOSのネットワーク設定を構成する際に利用されます。このバグは修正済みです。

ドッグフードではさほど負荷がかからない、けれども長期にわたって起動し続けるシステムにおいて発生する不具合も見つけ出すことが出来ました。Novaを構成するサービス群は数多くのバックグラウンドタスクを走らせ、メンテナンス用のためのタスクを定期的に活動させます。それぞれのタスクは自分自身でタイマー期間設定を保持しています。あるタスクはその後のタスクの状況に依存している場合があり、その中に長時間に及ぶタイマー設定のタスクがあると数分から、数時間稼働してしまいます。これは時によって非常に見つけにくいバグで発現するのも数日後、しかも特定の状況においてのみ発生するというものです。

不具合や、パフォーマンスの問題を見つける以外にも、日々自身のプロダクトを使うことで製品の至らなさを見つけ、改善することができ、これは我々だけではなく、お客さまにとっても素晴らしい機会となりました。例えば、ウェブインターフェースを利用している時、ある従業員が誤って大きなインスタンスのグループを選択し、それを消してしまうということが有りました。重要なインスタンスがいくつも失われてしまい、こうしたアクシデントが起こらないようにするためにはどうしたらよいか、という議論をすることになります。これに対するソリューションは我々の問題トラッキングシステムの異なるチケットとして様々な形での提案が寄せられます。他と同様に我々は機能追加についてのプライオリティ付を行い、どの製品ヴァージョンでどのリリースを取り込むかを決めます。上で上げた問題では、UIの改善が実装され、ユーザーが大きな破壊操作を行おうとしていることを理解させることが出来るようになりました。最終確認を終え、この変更は既に製品に取り込まれています。製品のAPIレベルで書き込み禁止のフラグを追加で立てるというもっと先進的な改善実装も出来ますが、これは将来のリリースで実装予定です。

将来の方向性

我々はドッグフードの利用範囲を近日中に更に拡張しようと考えています。まずは我々はプロダクトだけでなく、そのワークロードへも拡張しようと考えています。殆どの我々のビルド・統合サーバはベアメタルのハイパーバイザー(ESXとLinux KVM)として動作しており、手動で管理されています。我々はこのミッションクリティカルなシステムを我々自身のプライベートクラウドへと移行させたいと考えています。他の移行候補としてはインフラストラクチャシステムが有ります(例えば、DHCP、DNS、NFS)そして、従業員の個人開発環境などです。

次に、将来のリリースでDockerコンテナのようなLinuxコンテナの管理をサポートする大規模なリリースを予定しています。(訳注:Platform9 Managed Kubernetesとしてリリースされています!)つまり、我々は革新的な方法でコンテナを我々のビジネスに取り入れることが出来るように考えているんです。例としてはまだ検討中ですが、Dockerの大規模スケールでの小さなオーバーヘッドを活用して、何千ものコンピューティングノードのテストを実現したいと考えています。このテクノロジーを利用することで我々のビルドサーバで発生する初期化が不十分であるという問題を解決し、ライフサイクル管理を簡略化したいと考えています。コンテナは常にそれぞれのサーバがクリーンな初期状態で起動することを保証してくれ、しかも高速に起動します。最初のコンテナの管理はマニュアル操作とカスタムのスクリプトで行いますが、直ぐにPlatform9 Managed OpenStackのAPIを利用して出来るようになると思っています。

最後に

自分自身のビジネスをPlatform9 Managed OpenStackで走らせたことは、疑いようもなく我々の製品の改善に役立ちました。日々の面倒な継続的なビルド・検証のシステムをそこへ任せることで、我々は多くの重要な問題を発見し、修正することが出来ましたし、それは人工的な検証シナリオでは見落としてしまうようなものでした。実際の利用シナリオにおける製品の強さと弱さを理解することが出来、そしてユーザーエクスペリエンスと機能の重大なギャップも埋めることが出来ました。これはこの活動の「ケーキ」とも呼べる収穫ですし、そのように意図したとおりとなりました。

この努力によって我々はより俊敏に、そして効率的になったか? 最初の投資コストは正直な話、非常に高いと言わざるをえないものでした。時間、新しいハードウェア、人件費。しかし、今ではシステムが安定し、鼻歌を歌ってくれています。我々はPlatform9 Managed OpenStackが劇的に我々の開発検証の業務を改善し、大規模な自動化を簡単なものにしてくれたと確信することができています。そして、最終的に見ると、今回の努力はパブリッククラウドのためのコストの削減につながりつつ有ります。その通りです、我々は長期の投資の観点から見て危機に脅かされていたのです。このプロジェクトによってそれは解消し、また、我々と我々のお客様のメリットの観点からはより大きな成果を挙げつつあるのです。

記事責任者 マーケティング本部 三好哲生 (@Networld_pf9)

2016/08/08

[最新鋭、IBM FlashSystem A9000を大解剖!]

最近発表されたIBMの最新鋭の超高速フラッシュストレージ FlashSystem A9000をお借りしちゃいましたっ。

グリッド・コントローラーってなあにっ??


分散する複数のコンピューティングリソースを並べて一つに見せる「グリッド」という技術があります。

A9000において、この「グリッド」を構成するのがこの「グリッドコントローラー」ですっ。

Grid_2*A9000は「フラッシュエンクロージャー x1台」+「グリッドコントローラー x3台」 で構成されています。

今をときめく超高速フラッシュストレージを、もっともっといろんな用途に使えないかなぁ・・・

沢山ある答えの一つがこのA9000で、その豊富なストレージ機能が詰め込まれているのが
何を隠そう、この「グリッドコントローラー」なのですっ!

観て通り、このグリッドコントローラーのハードウェア自体は
信頼性高いハイエンドサーバーがベースになっています。
ただでさえ複数のグリッドコントローラーによる冗長を提供しながら
このグリッドコントローラー単体もワンランク上の堅牢性を兼ね備えているんですっ♪。

Gridctl

*こちらがグリッドコントローラーですっ。

例えばグリッドコントローラー本体の冗長電源の、両方の電源供給が
同時に断たれてもシステムのシャットダウンを安全に完了できる機能を有します。

ハイエンドサーバーがベースでありながら、こういっためずらしい機能も搭載しています。
むろんストレージ機器であるフラッシュエンクロージャーにもこういった機能が実装されています。


また、自慢のインラインのデータ削減だって、グリッドコントローラーに搭載される余裕のリソースがあってこそっ!
これは「特定パターンの排除」に始まり、流行の「重複排除」、更にデータの「圧縮」で限りあるストレージのリソースを最大限に利用できるのですっ。

ちなみに圧縮には独自の専用ハードウェアアクセラレーターカードがグリッドコントローラー1機あたりなんと2枚も搭載されているんです!だから速いんです!!
高速な大容量メモリー、複数のマルチコアプロセッサーもそのために搭載されているのですっ♪
とにかく、ありとあらゆる手段でデータ量を削減しまくる!それも高速に!!

とまあ、これもA9000の数ある得意技の一部にすぎませんっ。
XIVで培った豊富なストレージ機能の数々が、このグリッドコントローラーに実装されているのですっ。

なかなかやるでしょ、グリッドコントローラーっ♪


次回は「実際に動かしてみようっ♪」へ続きます♪

*参考資料:英語*
IBM FlashSystem A9000 and IBM FlashSystem A9000R Architecture, Implementation, and Usage



by:まいけル

2016/07/29

【CommVault】次期バージョン v11の国内提供が始まりました!

こんにちは。

今回は、CommVault 最新バージョン V11 の国内提供が開始されましたので、ご紹介します。

最新バージョン V11 のリリース以降、製品名が CommVault Simpana から会社名と同じ "CommVault" に変わりました。Simpana (シンパナ) という製品の名称に慣れていましたので、CommVault社の CommVault と呼ぶにはまだ時間がかかりそうです(苦笑)。

 

2014年 4月 1日の初回のブログでもご紹介しましたが、今年のガートナー社「データセンター バックアップ/リカバリ ソフトウェア」のマジック・クアドラントで、バックアップ/リカバリ分野で6年連続「リーダー」に選ばれており、ワールドワイドで変わらず高く評価されています。

 

Commvault、ガートナー社「データセンター バックアップ/リカバリ ソフトウェア」のマジック・クアドラントで、「ビジョンの完全性」と「実行能力」においてリーダーとして最高評価の位置付け

※「データセンター バックアップ/リカバリ ソフトウェアのマジック・クアドラント」の完全版および詳細は、こちら (英文) をご覧ください。

 

V11 の新機能、V10 からの強化機能など、今後のブログで順次ご紹介していきたいと思いますが、V11では、インストーラー(CommServe インストール手順例:CS_Installtion.pdfをダウンロード )が変更されました。基本的なインスール手順は変わりませんが、インストール先のデフォルトのパスなど変更がありますので、V11 の製品評価の際にご確認ください。

 

CommVault V11 - 新機能
http://documentation.commvault.com/commvault/v11/article?p=new_features/new_features1.htm

 

また、これまでご紹介しておりませんでしたが、"Early Release Features" という将来のバージョンで搭載予定の機能が試験的に搭載され提供されています。V11 の Early Release Features の機能一覧は、こちらのサイトでご覧いただけますが、CommVault 社に Early Release Features の機能の利用を事前に申請して承認を取れば、正式リリース前でもサポートを受けることができます。

 

V10 の Early Release Features (機能一覧はこちら) の中で "Live Sync Replicaiton of Virtual Machines (VMware) (以下、Live Sync)"という災害対策用の機能が正式にサポートされました。

 

Live Sync は、仮想マシン(Source VM) のバックアップから同期先の仮想マシン(Destination VM) に対して、変更ブロック(増分)のデータ転送を可能にします。また、Live Sync は、ベストプラクティスとして、DASH Copy のブロックベースのバックアップ機能と併用する構成になりますが、同期先の仮想マシンに対して最後の同期点以降のソースからの変更ブロックのバックアップを適用します。

 

[Live Sync 機能の利点]

  • 本番環境の仮想マシンへの負荷が最小限(バックアップデータから仮想マシンを複製)
  • リモートサイトへのデータ転送は、重複排除と圧縮機能により最小限
  • ハードウェアに依存しない(災対環境での元のハードウェア環境と同一構成は不要)
  • リストア操作が不要(基本、災対環境上の仮想マシンのパワーオンのみ)
    ※災対環境での新たなネットワーク設定(IPアドレス)を事前に設定しておく機能(設定画面:LiveSync_Settings1.JPGをダウンロード)が提供されています。

  

続きを読む »

2016/07/25

PernixCloud データ : FVPのレイテンシとSANのレイテンシの比較

本ブログエントリーはPernixData社のテクノロジーエバンジェリストだったFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はPernixCloud Data: FVP Latency Compared To SAN Latencyで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら

地球全体の仮想化データセンタをポータル化ESXiホストのCPUとメモリの構成についての考察そして、仮想マシンの密度(統合率)についての考察などの記事の中で、我々のPernixCloudの中のデータについて述べてきました。我々は世界中の仮想化データセンタのデータを多く集めることで、様々なアーキテクチャ、会社、運用を理解しようとしています。ですが、もちろん、我々は我々の製品のパフォーマンスについて理解するためにもこのデータを利用します。今回キーとなるメトリックは我々のFVPがどれだけワークロードのレイテンシを改善したか、という点です。Satyam氏Woon Jung氏とSriram Sankaran氏にデータセットへとダイブし、どれだけのレイテンシが改善されたのかを明らかにするように命じました。以下はデータ取得時のSatyamによるコメントです:

データセット

Satyam :我々は日々91000ぐらいの仮想マシンを観察しています。仮想マシンのIOの特性は時刻や曜日によって変わり続けます。ドーナツチャートのそれぞれのセグメントごとの色はx-y%のレイテンシの改善がSANのレイテンシに対して見られた仮想マシンの割合を表しています。例えば、ドーナツチャートの左上の内側の(濃い)ブルーのセグメントはWrite-Thoroughに設定した仮想マシンの全体うち5%は0~19%のレイテンシの改善がFVPによって見られたということです。

以下の記事を読んで、FVPとWriteポリシーについて理解しておいてください:

我々は1382の仮想マシンの数年分のデータについて収集しました。データの表示は標準的に、一時間あたりでどれだけか、という値にしてあります。これはEC-2などのクラウドと比較しやすいようにするためです。

VMFS上のWrite Throughの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig421

NFS上のWrite Throughの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig422

VMFS上のWrite Backの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig423

NFS上のWrite Backの仮想マシンのレイテンシの改善 ー Read(内側)とWrite(外側)

Fig424

Satyam : さぁ、準備はいいかい? いっぱいあるけど、以下の様なところが見どころさ、それ以外は読者の楽しみとして取っておきます。

  • VMFS上の仮想マシンでWrite Throughに設定されている場合、35%もの場合で、100%以上のレイテンシの改善が見られています。つまり、SANのレイテンシよりも仮想マシンから見たレイテンシが半分以下になっているということです。
  • Write Throughに設定されている仮想マシンでも、ストレージに対する負荷が下がることで実際にはWriteのパフォーマンスを向上させることができています。14%ものWrite Throughの仮想マシンが80%~90%の割合でWriteのレイテンシの改善をしています。これはとーーーーっても大きい!!
  • NFSのチャートの右上、NFSの仮想マシンはより大きなレイテンシの改善がなされています。これはNFSはダメだからです(パフォーマンスの観点からはね・・・。)
  • Write Backに目を移しましょう。VMFSで動作している仮想マシンの半分はWriteBackで100%以上のレイテンシを改善しています。Write Backはすごいね!
  • 一般的にはほとんどの仮想マシンが50%以上のレイテンシの改善しています。Readでも、Writeでも、Write ThroughでもWrite Backでも、VMFSでもNFSでも。なんという強者っぷり!

実際のデータは見ていただいたとおりです、注目したいのはWrite ThroughでのSANのWriteレイテンシの改善です。これは実際の話しですし、オールフラッシュストレージの上でFVPでRAMによる高速化(DFTM)を実施したことを考えてみてください。最近、Ramboll社 ーグローバルで展開するエンジニアリング会社ー が何故Pureのオールフラッシュストレージの上で、DFTMを利用するFVPを導入したのかという理由を答えてくれています。レコーディングは以下から聞くことが出来ます。Maximize Your All Flash Array Investment With Analytics(訳注:英語ビデオ)

Chethan Kumar氏、我々のパフォーマンスエンジニアもSANのレイテンシがFVPを動作させる前よりも下がったということを述べています。帯域が削減されることにより、ストレージエリアネットワークとストレージコントローラーに対する負荷が下がるからです。もし90,000もの仮想マシンからのIOが発行されたとすると、レイテンシはもっと高いものになっているはずです。そうした意味では、このドーナツチャートで見るよりも実際の結果はもっと優れたものになるはずです。本当のドーナツでは殆どが紫になってしまい、上の方にちょこっと色が出てくるような状態のはずです。

Write Throughで削減される仮想マシンからの帯域の総量を甘く見てはいけません。今週私は32のデータベースを動作させている仮想マシンを高速化されているお客様をご訪問いたしましたが、1日辺りで145TBもの帯域が削減されていました。ストレージエリアネットワークでの帯域はストレージ装置自身のキャッシュにも影響をあたえるのです。

Fig425

我々がFVPによるメリットにどれだけの確信を持っているかを示すために、我々は「Fastest SAN alive(最速のSANの誕生)」キャンペーンを実施しています。最大で10倍の高速な仮想マシンのパフォーマンスをFVPが実現するということを是非チャレンジしてみてください。詳細はこちらです。

Fig426

訳注 : 残念ながら上記のキャンペーンは国内では展開されておりませんが、FVPのパフォーマンス改善とその効果に絶対の自信があるということは上記の統計からの実際のお客様の例からも明らかです。是非無料トライアルをお試しください!

記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)

2016/07/22

[最新鋭、IBM FlashSystem A9000 をこっそりレポート]

最近発表されたIBMの最新鋭の超高速フラッシュストレージ FlashSystem A9000をお借りしちゃいましたっ。

FlashSystem A9000 ってなあにっ??


写真:緊張をしながらA9000に灯を入れたところをパシャ!

_20160617_131927

究極の低遅延を誇る 超高速ストレージ
IBM FlashSystem 900 は爆速街道まっしぐらっ!

A9000は、その超高速ストレージに「IBM XIV」で高い実績の 「IBM Spectrum Accelerate」 を組み合わせた
一言で言うと超高速ミニXIVだっ♪

もちろんリアルタイム圧縮、そしてインライン処理での重複排除機能も標準搭載され、アクセスタイム250usという驚異的な応答速度に、最大500,000IOPSを叩き出し、同時に99.999%を超える可用性をも実現しているっ!
リアル何でもアリなのであるっ。

で、更に
QoS+マルチテナンシー というクラウド環境を意識した機能を併せ持つまさに理想のストレージっ。

ちなみに最大2,000,000IOPSに達するモンスターマシンA9000R にいたっては
複数のフラッシュエンクロージャーによるスケールアップにも対応しているよっ。

 

FlashSystem A9000 中身を覗いてみよう♪


FlashSystem A9000はマイクロレイテンシーフラッシュモジュールを12個搭載したフラッシュエンクロージャー1台にIBM Spectrum Accelerateが実装されたグリッドコントローラー3台で構成され
各筐体同士が超広帯域なInfiniband (FDR/56Gbps)で接続されいるんですっ。凄いでしょ♪
裏にまわって、実際の結線をたぐっていったら、下の図のようになっていました!!。

Infiniband_4

次回は「グリッドコントローラーってなに??」の謎に迫ってみまっしょうっ。

by:まいけル

2016/07/20

Platform9のOpenStackアーキテクチャの中を覗いてみる

本記事の原文:Under the Covers of the Platform9 OpenStack Architectureの公開は2015年の7月7日です。現時点では機能が拡張されたり、改善されている場合がございますのでご注意ください。

Platform9製品詳細についてはこちら

Fig004

Platform9のミッションはあらゆる規模のエンタープライズのプライベートクラウドを簡単にすることです。これは以下の様な我々の顧客にとって重要なメリットを提供するソリューションを作るということに他なりません:

  • 展開が容易というだけのプライベートクラウドではなく、管理も容易でなくてはなりません。Platform9で、我々は顧客にとっては退屈な展開作業や監視、拡張、バックアップ、更新など、クラウド管理システムを管理するということは現実的ではなく、取り除くべきだという決断をしました。我々はクラウド管理自身をSaaSとして提供するというユニークなモデルを成し遂げたのです。
  • インフラストラクチャ、スキルセット、手順などのすでに顧客がお持ちの資産を活用できるプライベートクラウドである必要があります。これはまっさらな環境を必要とする多くのソリューションとは対照的です。Platform9は既存のKVMやVMware vSphere環境の上に統合して利用することが出来るのです。
  • 標準的なインターフェイスやAPIセットを利用しながら、Linuxコンテナーのような最新のテクノロジーを迅速に、そして簡単に利用できるようなプライベートクラウドである必要があります。これはPlatform9がOpenStackの標準化された技術を我々のクラウド管理プラットフォームに採用した主な理由の一つです。我々はOpenStackがプライベートクラウドにとってデファクトの標準APIを提供しており、柔軟なプラグインアーキテクチャで新しいテクノロジーを簡単にプラットフォームに統合できる用になっていると信じています。

今後、我々の既存環境との統合や、テクノロジーとの統合についてもっと耳にすることが増えてくると思います。この記事はわれわれのSaaSソリューションがどのようにPlatform9のエンジニアを助け、クラウド管理-as-a-serviceを実現しているのかを述べていきます。このソリューションを設計し、実装したPlatform9の輝けるエンジニアリングチームに感謝したいと思います。また、共同創業者であるBich Le氏、Madhura Maskasky氏、そしてRoopak Parikh氏の本記事への寄稿についても感謝致します。さぁ、まずはPlatform9 Managed OpenStackのハイレベルなアーキテクチャから初めましょう。

Platform9 Manged OpenStackのアーキテクチャ

Fig005

Platform9は3つの層からなるアーキテクチャで動作していると考えることが出来ます。この3つの層は:

  • コアサービス ー それぞれの顧客のプライベートクラウドの展開ユニットを一元的な手法で行うためのサービスやツールの集まり
  • 展開ユニット ー Platform9社がそれぞれの顧客に対して展開するOpenStackのクラウド管理インスタンスとそれに紐づく管理サービス。全ての展開ユニット(Deployment Unit - DU)はPlatform9コアサービスによって一元管理されていますが、それぞれのDUはあらゆる顧客において共有されることはありません。
  • オンプレミス層(ホストエージェント) ー 顧客のオンプレミス環境のLinux KVMサーバでデーモンとして動作し、サーバをOpenStackのコンピューティングノードとして機能させます。エージェントはnova-computeやnova-novncproxyバイナリのようなコンピューティングノードとしての要件のインストールについても実施します。エージェントは動作している仮想マシン(VM)、ネットワーク構成、ストレージの容量などのサーバ上で動作しているリソースのディスカバリも可能にします。顧客のDU内で動作しているOpenStackのコントローラーはエージェントを利用して、サーバ上に展開されているリソースの管理などのコミニュケーションも行います。
  • オンプレミス層(ゲートウェイ) ー 顧客のオンプレミスのvSphere環境上に展開されたオープン仮想化アプライアンス(OVA)で、顧客のDUと顧客のvCenterサーバ間のコミニュケーションを実現します。ゲートウェイは顧客のvSphereクラスタ内の動作中の仮想マシン、ネットワーク構成、そしてストレージ容量などの全てのリソースのディスカバリも実現します。顧客のDU内で動作しているOpenStackコントローラーもゲートウェイを利用してクラスタ上の各リソースの管理のためのコミニュケーションを実施します。

記事の残りの部分では、協調してSaaSとして動作し、クラウド管理-as-a-Serviceを実現するPlatform9のコアサービスと顧客の展開ユニット(DU)にフォーカスをあてます。将来の記事でホストエージェントやゲートウェイがどのように顧客のオンプレミスの環境とやり取りしているのかを取り上げる予定です。

コアサービス

Platform9のコアサービスは分散されたサービスとユーティリティで、現在はAmazon Web Services(AWS)上に展開されています。我々がAWSを選択した理由はそのインフラへの展開が簡単で、彼らのグローバルな展開と様々な機能ー例えば可用性ゾーン(Availability Zone)を活用することができるからです。アーキテクチャ的にいえば、コアサービスはどんなインフラストラクチャへの展開にも対応が可能です。

コアサービスを構成するコンポーネントには以下が含まれます:

  • アラーティングサービス(Alerting Service) ー 我々の状態サーバ(Stat Server)、ログ分析(Log Analyzer)をPlatform9のアラーティングやページングシステムと統合するためのソフトウェア
  • ログ分析(Log Analyzer) ー 顧客の展開ユニットからログを集めてパースするためにPlatform9が利用するソフトウェア。ログ分析はアラーティングサービスと統合されており、アクティブに監視を行っています。
  • 状態サーバ(Stats Server) ー 顧客の展開ユニットの健全性を監視し、すべてのサービスが起動し、稼働し続けていることを保証するために利用します。状態サーバはそれぞれの顧客のDUで動作している状態/ヘルスエージェントと通信し、展開状態を受信します。
  • スネイプ(訳注:Platform9らしく、ハリーポッターのキャラクターの名前です) ー それぞれの顧客ごとのDUの管理サービスで、顧客ごとの展開バンドルの作動を含め、利用されている展開ツール群です。
  • 構成リポジトリ(Configuration Repo) ー 展開バンドルを作成するファイルの共有リポジトリで、顧客の展開ユニットの新規作成に利用されます。Ansibleのスクリプトや顧客ごとに固有の識別子が埋め込まれる前の状態の顧客展開バンドルの一部であるゲートウェイのRPMパッケージが格納されています。

Fig006上で述べたように、コアサービスはAWS上に展開されています。これによって、顧客のワークロードがセキュアな状態でオンプレミス層の一部としてオンプレミスのプライベートクラウドで動作していることを保証しながら、パブリッククラウドのスケーラビリティとサービスを活用することが出来るのです。Platform9では、AWSサービスを利用し、高可用性(HA)をコアサービス層に提供しています。

  • すべてのコアサービスのコンポーネントは利用している可用性ゾーン(AZ)内に1つ又は複数のAWSインスタンスとして動作しており、そのレプリカが別のAZ内に作成されます。どのAZが展開に利用されるかは顧客のデータセンターの地理的な場所によって決まります。
  • コアサービスは永続データをAWS Relational Database Service(RDS)インスタンスに保管します。このインスタンスもコアサービスのレプリカと同様に同じAZへレプリケーションされています。コアサービスはこのように設計されており、もしも本当にkey-valueストアのソリューションへの移行が必須となった際にはそれが簡単に出来るようになっていることを付け加えておきます。
  • コアサービスのインスタンスやそれがホストされているAZにダウンタイムが発生した際には、AWS Elastic Load Balancer(ELB)を活用して、トラフィックをコアサービスのフェイルオーバーのためのレプリカやAZへと転送します。もちろん、普及後の再転送にもELBを利用します。

展開ユニット(Deployment Unit - DU)

Platform9のアカウントにサインナップが完了すると、展開ユニット(DU)がそれぞれの顧客ごとに作成されます。うえでも述べたように、あらゆる顧客においてDUが共有されるということはありえません。Platform9のコアサービスと同様、顧客のDUも現在はAmazon Web Services(AWS)上に展開されます。我々がAWSを選択した理由はそのインフラへの展開が簡単で、彼らのグローバルな展開と様々な機能ー例えば可用性ゾーン(Availability Zone)を活用することができるからです。アーキテクチャ的にいえば、DUはどんなインフラストラクチャへの展開にも対応が可能です。

展開ユニット(DU)を構成するコンポーネントにはいかが含まれます :

  • OpenStack コントローラー ー 安定版リリースをベースとしたOpenStackの標準のサービスで、顧客のプライベートクラウドのインスタンスに対して、クラウド管理機能を提供します。これらのサービスは複数のAWSのインスタンスにまたがっており、顧客のリソースの要求に応じて簡単にスケールアウト出来るようになっています。
  • リソースマネージャー(Resource Manager) ー Platform9 OpenStackコントローラーで管理されている顧客のデータセンタ内の全てのコンピューティング、ネットワーク、ストレージリソースの状態を追跡し、カタログ化しています。顧客は新しい環境や既存の環境の両方をいつでもPlatform0の管理下に置くこと出来るため、状態は非常にダイナミックです。リソースマネージャーは他のDUサービスと強調し、OpenStackコントローラーがいつも一貫した、そして最新のリソース管理が行えるようにしています。
  • 認証リポジトリ(Certificate Repo) ー 顧客ごとに様々なDU内のサービスの展開にされる、自己証明書であり、顧客のデータセンタ内のインフラサービスの認証にも利用されます。
  • ログ収集(Log Collector) ー 特定の顧客のDBのログを収集し、コアサービス層内のログ分析へ処理のために送信を行うためにPlatform9が利用するソフトウェアです。
  • 状態/ヘルス エージェント(Stats/Health Agent) ー このエージェントは定期的に中央のコアサービス層内の状態サーバへステータス情報をレポートします。以下のサービス/コンポーネントの状態データの収集を行います:
    • 顧客のDU内に展開されたすべてのサービス
    • 展開されたすべてのホストエージェント
    • 展開された全てのゲートウェイ
  • 構成マネージャー(Configuration Manager) ー 構成マネージャーは以下のタスクを実施しています:
    • DU内、そして顧客のデータセンタ内のオンプレミスに展開されているPlatform9アプリケーションソフトウェアのインストール、構成、更新。この中にOpenStackサービスやホストエージェントやゲートウェイも含まれます。
    • ハイパーバイザーなどの顧客のリソースのディスカバリや、それらのリソースについてのテレメトリーの収集。構成マネージャーはPlatform9が作成したものや、Ansibleによる構成管理、オーケストレーションを含む様々なユーティリティを数多く利用しています。

Fig007

コアサービスと同様、展開ユニットもAWS上で動作しています。これによって顧客のワークロードがセキュアな状態でオンプレミス層の一部としてオンプレミスのプライベートクラウドで動作していることを保証しながら、パブリッククラウドのスケーラビリティとサービスを活用することが出来るのです。Platform9では、AWSサービスを利用し、高可用性(HA)を顧客のDUに提供しています。

  • すべてのDUのコンポーネントは利用している可用性ゾーン(AZ)内に1つ又は複数のAWSインスタンスとして動作しており、そのレプリカが別のAZ内に作成されます。どのAZが展開に利用されるかは顧客のデータセンターの地理的な場所によって決まります。
  • DUは永続データをAWS Relational Database Service(RDS)インスタンスに保管します。このインスタンスもDUのレプリカと同様に同じAZへレプリケーションされています。
  • DUのインスタンスやそれがホストされているAZにダウンタイムが発生した際には、レプリカのRDSインスタンスが対応に当たり、DUのインスタンスのスナップショットが展開され、構成されます。オンプレミス層からの、またはオンプレミス層へのトラフィックはDR DUへと転送されるようになります。

この記事によってPlatform9がどのようにクラウド管理-as-a-Serviceをエンジニアリングし、膨大なプライベートクラウドの展開・管理にかかる作業を簡単にしているかのいくらかでもお伝えできれば幸いです。続いての記事ではオンプレミス層と様々なコアサービスそして展開ユニットそうのコンポーネントについて深く見ていきたいと思います。

記事責任者 マーケティング本部 三好哲生 (@Networld_pf9)