« 2015年11月 | メイン | 2016年1月 »

2015年12月

2015/12/29

クラウドを活用できる今話題のEMC CloudArrayとは!?①

こんにちは、長らくご無沙汰していました。NetworldのEMC製品担当の片山です。

EMC社が1年ほど前に買収したTwinStrata社の製品で、2015年新製品として発表したCloud Arrayについて、今回は物理アプライアンス版ではなく、無償で評価できるVirtual Edition(以後VE)についての動作検証をしてみました。CloudArrayは特に操作が難しい製品ではないので、2~3回程度で説明していければと思います。

しかも!?このCloudArrayはEMCハイパーコンバージド製品であるVSPEX BLUEを購入すると、VE版のCache 1TBの利用ライセンスが付属していますので、VSPEX BLUEユーザはまさに必見です!!

VSPEX BLUEについてのブログ記事はこちらです↓

http://blogs.networld.co.jp/main/2015/04/vspex-blue-e63a.html

 

1

 

さて、話は戻ります。CloudArrayって一体どういう製品??かと言うと、インターネット上のクラウドストレージ(AWS S3、Microsoft Azureその等…)にデータ保存するためのハードウェア/ソフトウェアでクラウドゲートウェイといわれるカテゴリ製品になります。 

CloudArrayの製品ラインナップは、VE版以外にも物理アプライアンス版VSPEX BLUEバンドル版があります。今回、検証にも利用しているVE版の評価ライセンスは容量無制限で14日間利用することができます。

3

※  14日間以降の評価の継続には評価ライセンスの再申請が必要
※ 最新の対応バージョンやスペックについてはメーカーのWebサイトをご確認ください。

 

2015/12現在の対応仮想化ホストは、vSphereHyper-vです。しかし、何故か6.xバージョンのHyper-v用のバイナリファイルについてはまだ公開されていない様です。vSphere用はOVF形式ファイルでの提供がされています。

<詳細は下記コンパチビリティ参照>

4 

次にCloudArrayの概要について説明していきます!

では、実際にクラウドゲートウェイ製品ってどう使うの?という疑問がわくと思いますが、CloudArrayの動作の概要としては以下イメージになります。

2_2

 

  上図で例えると、ユーザからはCloudArray上のCIFS共有サーバーにVolume(10GB)の共有があるように見え、ユーザが共有に対してデータを書き込むとCache(5GB)に蓄えられ、Cache上から設定した各CloudプロバイダへデータがReplicationされます。簡単に言うとこれだけです。

  その他にもCloudへのReplication帯域制御DRテスト機能インクラウドスナップショットなど色々ありますが、単純に考えるとこれだけで十分です。要はCloudにデータを保存するだけでなくローカルディスクをCacheとして扱うことにより、ユーザアクセスを高速化しています。もし仮にクラウド上ですべてのRead/Write処理をすると、Cloudプロバイダへの重課金の問題や、ダウンロードなどにすごく時間がかかってしまいますよね。

  つまりユーザはデータをCache(ローカルディスク)に書き込みをすると、CloudArrayはバックグラウンド処理でデータを圧縮、暗号化(AES256bit)、最適化をしてCloudへReplicationを行います。ちなみに今回テストで利用したCloudプロバイダはAmazon Web ServiceのS3を利用しました。

最初の説明は少し簡単すぎたので、もう少し細い図で説明していきたいと思います。

5

  VE版では個々のvmdkファイルがPoolになります。このPoolから容量を切り出す形でCacheを作成します。Cacheを作成すると同時に、転送先のCloudプロバイダも選択していきます。最初にも説明しましたが、Cacheはユーザが利用する容量よりも小さくすることができます。例えばCacheが5GBしかない場合でも、ユーザに見せる領域としては10TBに見せたりする設定も可能です。

  CloudArrayで提供できるプロトコルはCIFS、NFS、iSCSIで利用することができます。特に簡単に試せるWindows環境については、本当に簡単にボリュームを作成して共有することができます。Windows環境ではStandalone構成、Active Directory構成が可能です。

  以下は、CloudArrayの実際の画面ですが、簡単にCloudプロバイダを選択して設定することができます。

6

 

  現在、対応のCloudストレージプロバイダは、設定画面から確認するとAmazonS3 Amplidata Atmos Azure Cleversafe Cloudian ECS2 Google HP Cloud NFS OpenStack RackSpace SoftLayer S3 Compatible Seagate Cloud Seagate Storage Cloud Synaptic ThinkOn vCloudAir Verizon ViPR Windstream などと多くのCloudストレージプロバイダが選択可能でした。またCloudプロバイダを選択とありますが、必ずしもインターネット上のCloudプロバイダが対象ではなく、例えば既存で利用しているオンプレミス環境のOpenStack、ViPR、ECS等へもデータ連携が可能です。

 今後もCloudプロバイダの選択肢には他のBlog記事でも紹介があったEMCオブジェクトストレージがいくつかありますね。今後もIsilonも含めどんどん追加されていくと聞いています。

 

  最後にCloudArrayポータルサイトには面白い仕組みがあります。CloudArrayでは、このポータルサイトとインターネットを介して自動的に容量やAlertのReportなどの情報を自動で収集していて確認できたり、CloudArrayの設定情報が定期的に自動バックアップされていて、いつでもCloudArrayのバックアップファイルがダウンロードができるので、別サイトへのリストアが簡単にできたりします。こちらは今後また説明していきたいと思います。

ここまででCloudArrayがどんな製品かはある程度は理解いただけたかと思います。

それでは、次回以降はCloudArrayの機能や設定方法について説明していきたいと思います!

記事:片山

今回の記事一覧はこちら

クラウドを活用できる今話題のEMC CloudArrayとは!?①

クラウドを活用できる今話題のEMC CloudArrayとは!?②

クラウドを活用できる今話題のEMC CloudArrayとは!?③

クラウドを活用できる今話題のEMC CloudArrayとは!?④

2015/12/28

発想の転換:世界で最も早いストレージを作る! その2

前回の記事ではメモリのレイテンシでI/Oでき、しかも耐障害性のあるストレージ環境を作るという話をしてきました。今回はその第2弾です。

メモリのスピードでI/O出来るプラットフォーム

今回作ったプラットフォームを評価していきます。今回は以下の様な構成でテストを実施しています。

サーバ環境
  • ftServer 6410 128GB Memory
  • VMware ESX 5.5 update2
  • vCenter 5.5 Applicance
ストレージ環境
見ていただいて分かる通りサーバのスペックはftServerではあるものの、2.5Ghz/10コアx2ソケット/メモリ128GBと普通のスペックです。また、ストレージについては2世代前のもので、更にSATAを5本RAID5で構成したもので、まったくもって早いと呼べるものではありません。
この上に、MS SQLサーバを仮想マシンとして構成しました。PernixDataの管理サーバやvCenterなども同居させている状態です。

Fig336

仮想マシンについては以下の構成ですが、CPUの構成を変えながら幾つかテストをしています。
  • OS :Windows Server 2008 R2
    • 1socket 6core
    • 1socket 10core
    • 2socket 10core
  • ワークロード : SQL Server 2014
  • 負荷テストツール : Transaction Generator

今回はOLTP(オンライントランザクション処理)の負荷をかけて見ることにします。OLTPはその名の通り、オンラインショッピングなどを行った際の負荷をデータベースにかける処理です。オンラインショッピングで、いつまでもウェブページが表示されなかったら?ユーザーはショッピングをやめて、別のショッピングサイトに移動してしまうでしょう。銀行ATMのバックエンドのデータベースや、証券会社のシステムのフロントエンドも同様な負荷になると言われています。

この処理はストレージから見ると小さなスループットの処理が同時に大量に発生します。ユーザーが「遅い」と感じないようにこれを処理するために必要なのは「レイテンシ」です。このレイテンシが悪い状態のストレージで処理を行うと、ストレージからちっともデータが来ないため、CPUで処理ができず、ユーザーは画面の前でほったらかしになります。

さて、結果を見ていきましょう。

同時接続500ユーザーのOLTPでのレイテンシ

Fig337_2

グラフの見方をご紹介致します。この画面はPernixData FVPのパフォーマンス画面で、のラインで仮想マシンから観測されたレイテンシ紫のラインデータストアのレイテンシを表示しています。

見ていただいてお分かりのとおり、紫のデータストアのレイテンシは271.307msになっており、すでにこの状態でストレージの処理負荷は一杯になっていることがわかります。しかし、気をつけてみていただきたいのは青のライン、つまり実際に仮想マシンが感じているレイテンシです。0.074ms=74μsという強烈な低遅延が実現されています。

もしもPernixDataとftServerのコンビネーションがなかったとすると271ms=0.27秒の遅延が発生しているので、ユーザーはすぐに「このサイトは壊れているか、何かで応答しない」と判断してショッピングをやめてしまったでしょう。ですが、高速化のおかげで数十マイクロ秒でデータが応答をしているため、さくさくとショッピングを進められただろうと推測できます。

アプリケーションとしての性能の向上

ベンチマークソフトから取得したアプリケーションとしての遅延時間を見てみましょう。これはユーザーがアクセスしてから、実際にページが表示されるまでにかかった時間に相当します。

Fig338_4

比較としてPernixDataをOffにした場合とOnにした場合の処理を並べています。同型色で色が薄いほうがPernixDataを利用した場合の性能を表示しています。また、Read/Writeの発生の割合を変えて処理を行っています。いずれの場合もOnの場合でレイテンシが低減、つまりウェブページの表示(Read)やオーダー処理(Write)にかかる時間が短縮されていることがわかります。

特にWriteの割合が大きい場合の性能向上が大きいのはReadのレイテンシはキャッシュヒット率に依存してしまうのに対し、Writeは100%の書き込みをメモリで受けることができるからです。

この環境は世界最速なのか?

そうです、今回はこれを示す必要があります。ですので、オールフラッシュストレージを用意して比較しました。同じサーバを使いTPS計測(一秒間に何トランザクション処理が可能かの限界値を調べる調査)を行っています。上の例のRead:Write = 9:1のパターンでの比較です。今回のグラフは今までのグラフと違い、低いほうが早いのではなく、アプリケーションとしての性能は高いほうが早いことになります。

Fig339同じCPU/メモリの構成でSATA 720rpm 5本のRAID5構成のストレージ(PernixData+ftServerのRAMで高速化)とオールフラッシュストレージ(高速化なし)を並べたものですが、およそ10%程ではあるものの、オールフラッシュストレージでの性能を凌駕することができました。

これはストレージ自体の価格の差を考えれば素晴らしい結果です。個人的にはメモリとフラッシュの速度差を考えればもっと差がつくかもしれないと思っていたのですが、ソフトウェアのオーバヘッドやキャッシュのヒット率(アプリケーション特性)などもあり、今回はこのような結果となりました。Writeの割合を増やすともう少し向上が見込めそうですが、Readと違いWriteはすべてのI/Oをストレージに書き込まなくてはいけませんのである程度バックエンドのストレージにも性能が必要になってきます。

忘れてはいけないPernixDataの特徴ースケールアウトー

いかがでしたでしょうか?2回にわたって世界で最も早いストレージを作る!という目的に向かって邁進してきました。結果としてはOLTP処理という条件付きにはなりますが、オールフラッシュストレージを上回る性能をマークすることができました。もう一つ付け加えるのであれば、今回の性能はftServerが1台の時の性能だということです。オールフラッシュストレージはサーバが増えてもその性能が上がっていくことはありませんが、PernixDataはサーバを増やすことで更に性能を上げていくことが可能です。PernixDataを搭載したftServerを2台、3台・・・と増やしていくとこの差はもっと大きなものになってくるでしょう。

Fig340このようなスケールアウトについての検証は将来また実施できた際に掲載していきたいと思っています。

最後に

今回の検証には日本ストラタステクノロジー様に多大なるご協力を賜りました。この場を借りて、厚くお礼申し上げます。

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

2015/12/25

clustered Data ONTAPパフォーマンス監視への道のり④

今回はOnCommand Performance Managerの基本設定セットアップ(GUI)を記載します

-------

OnCommand Performance Manager for VMware Virtual Appliances

基本設定 GUI

-------

1.設定した管理IPにWeb browserにアクセス

 例)https://<管理IP>

 サポートブラウザは下記になります。    

 • Mozilla Firefox ESR versions 24 and 31

 • Microsoft Internet Explorer (IE) version 11

 • Google Chrome version 41 and 42

 • Apple Safari version 7.x

2.ユーザ名とパスワードを入力して「Sign in」をクリックしてログイン

00010

3.基本設定の画面が表示されますので必要項目を入力して「Save and go to next step」をクリック

 ・Maintenance User Email Address

 ・SMTP Server

  -Host Name or IP Address

  -Port

   -User Name

   -Password

   -Use STARTTLS(チェックボックス)

  -Use SSL(チェックボックス)

00012


 ・NTP Server

  ※デフォルト「time.nist.gov」が表示されていますので必要に応じて修正して下さい。

00014

---

後で変更可能ですが、未入力の項目があると先進めませんので仮でも入力が必要です。

---

4.AutoSupport設定画面が表示されるので『Yes』を選択して「Save and go to next step」をクリック

00016


5.管理ユーザの変更画面が表示されます今回はそのまま「Save and go to next step」をクリック

00017_2

6.クラスタ追加画面が表示さますので必要項目入力して「Add Cluster」をクリック

・Host Name or IP Address

・User Name

・Password

・Protocol(HTTPS or HTTP)

・Port

00022

追加されると「Cluster Added」に登録されたことを確認して「Save and complete」をクリック

00024_2

---

後で変更、追加可能ですが、最低1Cluster追加しない先進めません。

---

7.完了しますとダッシュボードが開きます。そうしますと下記メッセージが表示されます。

00026_2

どうやら、15分ぐらい待つようなメッセージが出てきますね


次回は簡単ですが操作方法記載したいと思います。

/長谷部(ハセベ)

2015/12/21

発想の転換:世界で最も早いストレージを作る! その1

いつも翻訳記事ばかりですが、年の瀬になってきましたのでVMworldレポート以来のオリジナル投稿です。

今回の話題は「世界で一番早いストレージを作る!」です。

オールフラッシュを期待していた方、違います。フラッシュよりも早いものがあるのです。フラッシュよりも早い? 3DXpoint(スリーディークロスポイント)でしょうか?それもまた違います。この先に予定されているNV-DIMM? 違います。それはDRAM、つまりメモリです。

Fig330

メモリでストレージを作るという発想

馬鹿な!と思う方がいらっしゃると思います。メモリが早いというのは周知のとおりですが、もう一つ、メモリは揮発性メディア、すなわち電源がなくなると保持されているデータが失われてしまいます。こんなものでストレージを作れるはずがないと思うのではないでしょうか?

そのとおりです。ストレージはデータの保管庫ですのでこれまでは必ず不揮発性のメディアが必要でした。高速な書き込みを実現できると謳っているストレージであっても、書き込んだデータを失わないようにするため、NVRAM(メモリよりも低速だが、電源断時もデータを保持できるメディア)を利用しています。ですが、この考え方を変えるべき時が来ているのです。

ストレージは一体何を提供しているのでしょうか?

世の中にはハイエンドからローエンドまで、また記憶メディアとして磁気ディスク、フラッシュなどを採用するものなど広く数多に種類がありますが、提供しているものは結局のところ以下の4つです。

  • キャパシティ(どれだけのデータを格納できるか)
  • パフォーマンス(どれだけのスピードでデータにアクセスできるか)
  • データサービス (データに対してどんな操作を行うか/スナップショット、レプリケーション、圧縮、重複排除、暗号化等)
  • マネージメント (データの状況を表示、分析)

この4つのうち何を重視するかでどのストレージを選ぶかが変わってくるはずです。たとえばキャパシティを再優先するのであればオブジェクトストレージになるでしょうし、DRのために重複排除率・圧縮率そしてレプリケーションが重要ということであればEMCのData Domainという選択もあります。データの分析が重要ということであればData-Awareストレージという新しいジャンルのストレージも登場し始めています。

Software-Defined Storage(SDS)

もう一つ新しいジャンルとして立ち上がり始めているストレージがSoftware-Defined Storage(SDS)です。各社それぞれの定義があり、非常にバリエーション豊かなストレージのジャンルですが、ここでは@ITの三木さんの定義をお借りします。

「Software Definedとは、利用者がやりたいことを最短距離で実現できるようにするための、ITインフラ製品の機能および利用方法」

特定の技術ではなく、利用者にとって非常に分かりやすい定義だと思います。フラッシュ、次世代フラッシュと高速な不揮発性のメディアが登場してきています。ただ、これはストレージが上の4要素すべてを提供するハコ(ハードウェア)として考えた場合において、更に最速な選択肢が出てきたというだけです。ですが、SDSは別段ストレージの4要素全てを提供する必要はありません。欲しいのはストレージのパフォーマンスだけ、という利用者だって当然いるわけです。

さて、今回我々は世界で最も早いストレージを作りたいわけです。最短距離で考えると

世界で最も早いストレージ(ストレージのパフォーマンスを可能なかぎりあげたい)を作るのであれば、世界で最も早いメディア(=DRAM)を使うのが最短距離です

という考えに至ります。

PernixData社のビジョン

PernixData社はVMwareのファイルシステムの父であるSatyam氏、Oracle ExaDataの父であるPoojan氏によって創業されたスタートアップ企業ですが、そのビジョンは単に「ストレージを高速化する」というだけのものではありません。Satyam氏、Poojan氏はすでに非常に大きな実績を持っているにもかかわらず、口をそろえて

もっとすごいことをやるためにPernixDataを始めたんだ。今は詳しくはいえないけれど、すぐにみんながわかる形にしてみせるから、楽しみにしていて。ストレージの世界をVMwareの様に変えてみせる。

とおっしゃっていました。当時はストレージのパフォーマンスだけを後から提供するFVP製品しかありませんでしたが、今年はストレージのマネージメントだけを提供するArchitectという製品がリリースされました。もしかするとキャパシティだけを提供する製品、データサービスだけを提供する製品が今後リリースされてくるかもしれません。しかも、ソフトウェアでリリースされてくるのです。ストレージを全く違うものにする、それは今年国内でいくつも導入事例を発表させていただきましたが、すでにもう始まっているのかもしれません。

ちょっと話が横にそれましたが、PernixData FVPを利用することでストレージのパフォーマンスを分離(De-couple)してソフトウェアで外から提供できるようになっています。そして高速なメディアを利用することと、SANネットワークやストレージコントローラーなどの物理的なオーバーヘッドを排除することで高速なメディアのスピードを可能な限り失速させないようにして利用可能にしています。

Fig331

最後に残ったオーバーヘッドにサヨナラを

PernixDataはメモリを使ってのストレージパフォーマンスの提供を実現していますが、どうしても取り去れないオーバーヘッドが残っていました。それはWriteデータの冗長化のためのホスト間通信です。こればかりはいくらパフォーマンス優先とは言え「データを失っても良い」わけではありませんのでどうしても最後に残ってしまう問題です。最近のネットワークの遅延は小さく、PernixDataのデータ転送プロトコルも非常に軽量なものになっているとはいえデータ転送によるオーバーヘッドは4Kブロックサイズで250マイクロ秒程かかってしまっています。メモリ自体は数マイクロ秒程度で動作していることから考えると、この値はまだまだ大きいと言わざるを得ません。Readについては数マイクロ秒まで小さくできるのに、Writeは250マイクロ秒が限度となると非常に残念な結果になってしまいます。

Fig332

これは「サーバが落ちるもの」である以上しかたのないことなのですが、逆に言えば「落ちないサーバ」ならネットワークを使って冗長化する必要はなく、遅延を最小に抑えられるという意味にもなります。そこでストラタステクノロジー様のftServerの登場です。

Fig333

人類史上最速のメディアであるメモリをストレージとして使えるプラットフォーム

このサーバとPernixData FVPを組み合わせると以下のような、Read/Write両方についてネットワークの遅延を気にすることなく応答するシステムを実現可能となります。

Fig334

いかがでしょうか? これでRead/Writeをメモリで行ってもデータを失う心配のないストレージ環境が実現しました。実際のパフォーマンスについての検証結果については次回の記事、今年の最後の記事でお伝え致します。アゴが落ちないようにしっかりと支えておいてください!

結果のチラ見せ

来週まで待てない方のためにちょっとだけお見せします。

Fig335

ではまた来週!

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

2015/12/14

地球全体の仮想化データセンタをポータル化

本ブログエントリーはPernixData社のCTO、Co-FounderであるSatyam Vaghani氏のブログの翻訳版です。

本記事の原文はA portal into the planet's virtualized datacentersで閲覧可能です。

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

背景

とある問題

2015年の6月に遡ります。私はPernixDataのビジョンとしてビッグデータやリアルタイム解析の技術を企業のデータセンタに融合させるというビジョンを公開しました。企業のインフラストラクチャチームはとりおり、「ハムスターモード」で運用を行っているということに気がついたのです。つまり、ネットワーク運用センター内で赤いライトの点滅として現れる新しい問題を追跡し、そのライトが緑に戻るまで様々なハックをためしてみるという状態です。動作させているワークロードについてより深い知識を得るためのソリューションを持ち合わせていないのです。さらにいえば、永遠に、データに基づいて仮想化されたインフラストラクチャの設計、運用、最適化を行うことなどはできないのです。

トラブルシューティングを減らし、もっとよく理解する。私はは映画マトリックスの以下のやり取りを思い出します。

ネオ : 何が言いたいんだ? それでピストルの弾丸を避けられるとでも?

モーフィアス : 違う。 出来るようになったらそう言う。出来るようになろうとしなくてもいい。

トラブルシューティングはこの弾丸を避けるようなものです。何が起こっているかを理解すれば、トラブルシュートをこれ以上やる必要はなくなっていくのです。

なにがおこったのか?

どうしてこれまでに上記のような問題を解決するソリューションが発明されなかったのか、不思議に思うかもしれません。技術的な理由と、そうではない理由があるのです・・・。

技術面からは、非常に多くのデータを、しかもほとんどリアルタイムに集めなくてはならなかったという点から、こうしたソリューションが発明されてこなかったのだと思っています。そして集めたデータをどのようにデータセンタが動作しているのかということを理解している解析エンジンに通す必要があります。結果としては問題発生イベント(赤の点滅ライト)のみならず、どのようにそれを沈静化するかという意味のある結論を導き出さねばなりません。それだけではありません、ワークロードがどのように変化していっているか、なぜ変わっているのか、その変化が上位層へどのような変化をもたらすかなど。これら全てはコードにすることが非常に難しいものです。

技術的でない面からは、私は赤い点滅ライトを見せることだけに過剰に執着したことによって、ソリューションの発明が遅れたと思っています。いわゆる、いにしえのデータセンタの運用方法です。運用だけではなく、データセンタの設計や最適化を手助けしてくれるツールにはフォーカスがあたっておらず、ハードウェアに依存する形でしか、これを実現しようとするベンダーはいなかったのです。

さて、もう一つの面です。我々はFVPの物語を発展させていくと、このことは非常に論理的であるということがわかっています。というのもFVP 1.0を発明した際から積極的にストレージ解析についての機能を組み入れてきており、大きな成果を上げているからです。そして、我々は我々自身がこのリアルな問題をハードウェアに依存しない形で解決するために非常によいポジションに位置していると考えています。すべてのアプリケーションと全てのインフラストラクチャの接合点、すなわちハイパーバイザーに位置しているからです。これが我々をPernixData Architectの創造へと駆り立てました。インフラストラクチャとアプリケーションをデータに裏打ちされた形で設計、運用、最適化するためのインフラストラクチャ解析プラットフォームです。今年Architectをリリースして以降、その反応は非常に大きなものです。

次なる一歩 : 惑星規模でのArchitect

おなじくVFD5で、私はPernixData CloudをArchitectの論理的な進化系としてお話しました。惑星全体のアプリケーションとインフラストラクチャに対しての可視性と解析を皆さんにご提供するものです。我々は自分自身のデータセンタ内で発生している出来事から学ぶことができますし、Architectのような製品はそれを手助けしてくれます。しかし、他のデータセンタで起こっていることから相互に学び合うことはこれまでにできなかったのです。理由は上手く情報を取りまとめ、共有するうまい方法がなかったからです。我々はそこに手を入れます。

我々が現在見ているものをチラ見せ

すでに我々は前に進んでいます。そして十分な量の情報を集めることができています。数万のホストと数千のストレージシステムにも及ぶ情報です。ご参加してくださった全ての方々に感謝します。我々が惑星の(データセンタから集めた)メタデータから学んだことのうちの幾つかは非常に興味深いものです。どんどんそうしたものを共有していこうと思いますし、もしリクエストが有ればTwitterで教えて下さい。我々が出来る限りの範囲でお教えします。

サーバ

人々は野生環境(実際に利用されている環境)に分散しているESXのヴァージョンについて、新しいリリースの度に関心を持っており、自分自身がアーリーアダプターなのか、それともレガードになってしまっているのかで一喜一憂します。これが3000弱の実際に利用されているESXのヴァージョンの統計的な分布です。

Fig324ESXi 5.0はほとんど絶滅しつつあり、それ以前のものは見る影もありません。ESXi 5.5が生態系の主力であり、ESXi 6.0が勢力拡大のステージにあります。

この統計的なサンプルがお見せできるのも、我々は我々の集めた非常に大きなデータセットに対してクエリを発行しているからです。そうすることによって複雑さを減らし、正確さを上げることが出来るのです。ですから、我々はどんな質問にお答えする際にも、統計的なサンプルを用いる戦略を選びます。求められる正確さと適切なレベルでの複雑さをもってお答えするのです。今回の場合、3000ホスト程度のサンプルがあれば十分であると事前の解析でわかっていました。まぁ、本題に戻りましょう。

サーバについてのトピックを続けましょう。6500弱のホストからCPUのトレンドを統計サンプルとして取り出しました。以下がそのグラフです :

Fig325仮想化の世界が2ソケットのマシンに席巻されていることに驚く人はあまりいないかもしれません。そう、私はそれでは大して驚かない、4ソケットのサーバの見積もりをとって、がっかりしたことが数年前にあったからです。私が顎を落とすほどびっくりしたのは8ソケットや10ソケットのサーバを利用しているという人がいたからなんです!

サーバあたりのコア数を見るともっと面白いことがわかります :

Fig326

Ivy Bridge以前のテクノロジーもコア数のカウントから多くいることがわかります。これは別に驚くことではなりません。ハードウェアには更新のサイクルという期間がありますから。私はこのデータを枚クオーター新しいデータと比較し、2016年のサーバの更新のペースを見てみたいと思います。

それはさておき、分布の低い方(サーバあたり2,4,6コア)はホームラボだと想像しています。1ソケットサーバの割合はこの3つを合計したものと非常に近くなっています。もう一つ、2コアの棒グラフは惑星内にこっそりと潜んでいる仮想マシンとしてのESXサーバを掴まているかもしれないと思っています。

さて、メモリへと進んでいきましょう。64GBよりも大きく384GBよりも小さなサーバが流行です。x軸のメモリ分布は幅があることに注意してください。32GB以上、64GBまでという具合です。そして幸運な1TBから3TBをもメモリを積んでいる幸せな魂も見つけることができました。やぁ、データベースさん!

Fig327

ブロックストレージ

ブロックストレージへと歩みを進めましょう。仮想化システムにおけるストレージについては素晴らしいまでの多様性を見ることができます。これと同時にPernixDataの製品がこれらのすべての環境に驚くべきスピードで導入されたことを誇りに思います。幾つかのベンダーではFCとiSCSIプロトコルを使うときそれぞれで別の製品ファミリであるというレポートを返してきますので、2つ別々にレポートされてしまっています。ご期待のとおり、EMCのVNXが仮想化の世界では丘の上の王さまです。ではその次は?

Fig328

上記の分布は配備されたストレージの数を数えたものです。しかし、200TBのストレージでをベンダー1から、10TBのストレージをベンダー2からということもありますので、不公平かもしれません。データは適切に集計されていなくても我々の前でいたずらをしようとします。これはまた、マトリックスを思い出させてくれます。

エージェント ブラウン : おそらくは、間違った質問をしているのかもしれない。

我々はどれだけのデータがベンダーによって管理されているのか、というクエリにそれを修正しました。以下がその結果です :

Fig329

この結果はもともとの結果と異なって大きな別の結果を表しています。例えば、Tegileは新しいランキングで大きく順位を落としています。あるJBODベースの共有ストレージソリューションが新たにランキングに入ってきたりなどなど、です。

今後はもっと

同僚のPrashant Saxena、Jason Lloyd、そしてChethan Kumarが解析の手伝いをしてくれました。この先、我々のデータセットに基づいた結果を公開していきます。そして、その際にはアプリケーションや仮想化レイヤー自体の次元での分析も行いたいと思います。以前にお伝えしたとおり、遠慮無く惑星のデータセンタについての興味深い質問を投げかけてください。

@SatyamVaghani

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

2015/12/10

clustered Data ONTAPパフォーマンス監視への道のり③

今回はOnCommand Performance Manager for VMware Virtual AppliancesのOVFファイル展開後のセットアップを記載したいとおもいます。

-------

OnCommand Performance Manager for VMware Virtual Appliances

初期設定 CLI

-------

1.展開したOVFファイルの仮想マシンの電源ON

2.VMware Toolsインストールを求めてきます。

Gw00082

---

VMware Toolsをインストールしないとセットアップが進みません。

---

3.自動でセットアップはしてくれないのでインストールファイルを設定します。

Gw00084

4.VMware Toolsをインストール(インストール完了まで先に進めません)

Gw00088_2

5.タイムゾーンの設定その1

Gw00089

 私はアジア圏在住なので、6.Asia、の「6」を入力

6.タイムゾーンの設定その2

Gw00093

 私は日本在住なので73. Tokyoの 「73」 を入力

7.ログインユーザとパスワードを設定

Gw00097

8.下記画面が表示されれば完了です。

Gw00111

後は、GUIの画面からセットアップしていきます。

GUIセットアップは次回記載します。

/長谷部(ハセベ)

2015/12/09

clustered Data ONTAPパフォーマンス監視への道のり②

今回はOnCommand Performance Manager for VMware Virtual AppliancesをOVF展開してみたいと思います。

-------

OnCommand Performance Manager for VMware Virtual Appliances

システム要件

-------

システム要件は下記になります。

000000

これは!!?結構ハイスペックですね。

VMwareサポート環境

・VMware ESXi

 -ESX 5.5 and updates

 -ESX 6.0

・VMware vCenter

 -VMware vCenter Server 5.5 and updates

 -VMware vCenter Server 6.0

-------

OnCommand Performance Manager for VMware Virtual Appliances

OVFファイル展開

-------

1.VMware vSphere Clientにて対象ESXi or vCenterへログイン

2.上記タブ 「ファイル」 → 「OVFファイルのデプロイ」を選択してクリック

00008

3.ソース画面にて対象のOVAファイル選択して「次へ」をクリック

Gw00064

4.OVFテンプレートの詳細画面が表示されますがそのまま「次へ」をクリック

Gw00065

5.エンドユーザの仕様許諾契約書の画面が表示されますので「承諾」をクリックして「次へ」をクリック

Gw00067

6.名前と記入、インベントリファイルの場所を選択して「次へ」をクリック

Gw00069

7.作成するホストを選択して「次へ」をクリック

Gw00070

8.作成するデータストアを選択して「次へ」をクリック

Gw00071

9.DISKフォーマット画面にて今回は容量の関係がありますのでThin Provisioningを選択して「次へ」をクリック

Gw00072

10.ネットワークのマッピング画面にて適切なネットワーク選択して「次へ」をクリック

Gw00073

11.プロパティの画面にて必要項目を入力して「次へ」をクリック

■Use IPv6
-IPv6を使う場合はチェック

■Enable DHCP(IPv4) or enable auto-addressing(IPv6)
-DHCPを利用する場合はチェック

■Fully qualifired hostname
-ホスト名を入力

■IP address
-固定IPを利用する場合は入力

■Subnet mask
-サブネットを指定

■Defaut gateway
-デフォルトゲートウェイを入力

■Primary nameserver
-プライマリDNSサーバを入力

■Secondary nameserver
-セカンダリDNSサーバを入力

■Additonal search domains
-追加したいドメインがある場合は入力

----

Fully qualifired hostnameの項目では必ずFQDNで入力しましょう。入力しないと再起動したらセットアップする画面が登場します。

----

12.設定の確認をして「完了」をクリック

Gw00076

これでOVF展開は完了です。次回は電源投入後のセットアップを実施したいと思います。

/長谷部(ハセベ)



2015/12/07

clustered Data ONTAPパフォーマンス監視への道のり①

昨今、clustered Data ONTAPご利用の方々も多いかと思います(たぶん)

そこで最近よく耳にするのが、clustered Data ONTAPパフォーマンス監視ってどうやっているの!?

Storage Virtual Machine(SVM)、論理インターフェイス(LIF)を複数作成できますし、ボリュームも筐体を跨いで作成できます。

確かに何処がボトルネックになっているのか確認するのも大変ですよね

そこでNetAppのホームページにこんな文言が・・・

『clustered Data ONTAP環境のデータ ストレージ パフォーマンスを監視、管理、最適化します』

ライセンス無料これはなかなかよさそうな感じがします。

しかし!!百聞は一見にしかずとは、まさにこのこと!!

取りあえずインストールして動作確認(ほんとうにつかいものになるか!!)してみたいと思います。

-------

OnCommand Performance Manager for VMware Virtual Appliances

ダウンロード

-------

NetAppサポートサイトからダウンロードします。

【注意】Data ONTAPシミュレータはNetAppサポートサイトからダウンロードしますが、NetApp社とみなさんが所属している会社の契約によってはダウンロードできない場合があります。※ 契約についての問い合わせはこちらへどうぞ

1.NetAppサポートサイトにログイン後、上記タブの「Downloards」→「software」を選択

0003

2.OnCommand Performance Manager(Unified Manager Performance Pkg)を探して右にある<Select Platform>をクリック

0002

お、どうやら、VMware Virtual Appliances版とLinux(RedHat)版と二つあるみたいですね。

ここでは一旦、「VMware vSphere 」を選択します。

3.システム要件の確認やドキュメントなども表示されますが下の方のsoftware Download Instructionsの「CONTINUE」をクリック

00005

4.ラインセンスの承諾画面が表示されるのでそのまま、「Accept」をクリック

5.Download and Installation Instructionsの「software image」をクリックしてダウンロード

00006

OVAファイルがダウンロードされ完了。

次回はOVFファイルの展開を記載したいと思います。

/長谷部(ハセベ)

データセンタ内のワーキングセットのサイズ

本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。

今回はそんなPete氏の記事翻訳第9弾です。

本記事の原文はWorking set sizes in the Data Centerで閲覧可能です。

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

データセンタのミステリーは尽きることはありません。正体不明の彼らはパフォーマンスや環境の一貫性を阻害したりする一方で、切り分けや定量化、コントロールを難しくします。仮想化はこれらの情報のうちの幾つかを取り出す手助けとなりますが、それは理想的な可視化コントロールプレーンがあればの話です。実際にはそうではありませんし、正体不明の彼らを監督していくために必要で適切なすべての情報が提供されているわけではありません。ハイパーバイザーも誤解を生みやすい形でしか、データを表示していないのです。

今日の仮想化されたデータセンタに登場するミステリーの一つが「ワーキングセット」と呼ばれるものです。これは歴史的にはコンピューターサイエンスの領域で呼ばれていたものですが、実際にはデータセンタのコンポーネント~特にストレージ~を含んで利用される様な言葉になってきました。多くの場合、その定義すら難しいものです。それではこのワーキングセットがデータセンタに与える影響について見ていきながら、更にどのように計測するのかをお話していきましょう。

我々は我々が知っていることや、コントロール可能なものだけにフォーカスしがちです。しかし、データセンタの影響要素を十分に可視化しないままでは本当に必要なものにフォーカスがあたらないのです。残念なことに、ワーキングセットは通常そういう扱いを受けています。まったく予測できないものですから、データセンタ設計の講習にも含められていないということもしばしばです。同じ理由から殆どの文献にも含められていません。皮肉なことに、あらゆる最近のアーキテクチャの案件では、パフォーマンスの向上のためにデータの最適配置の問題に取り組まなくてはなりません。キャッシュされたコンテンツとそれを永続的に格納する場所の話題です。どれぐらいのサイズが必要なのでしょうか?どのぐらいの頻度でアクセスが起こるのでしょうか?こうしたあらゆる疑問に対する答えを知っておくことが非常に重要なのです。

ワーキングセットとは?

定義としては、ワーキングセットとは一定の時間内に処理されるデータのサイズの総計を意味します。これがホットだということは、永続ストレージのキャパシティの中において、頻繁にアクセスされているデータであるということになります。ですが、こうした簡単な説明は分かりやすい一方で、しっかりとした質と量での説明にはなりません。直近でとはどういう意味なのか?総計はRead, Writeもしくはその双方なのか?そして、何度も同じデータが書き込まれた場合はどう考えればいいのか?新しいデータの場合はどうなのか? さぁ、もっと掘り下げてみましょう。

以下のワーキングセットの特徴を抑えておけば、充分です。

  • ワーキングセットはワークロードによって稼働し、ワークロードはアプリケーションによって稼働し、そのアプリケーションは仮想マシンで稼働します。永続ストレージがDAS、共有ストレージ、または分散ストレージであったとしても、それは仮想マシンからどう見えるかには影響しません。殆どの場合、そのサイズは同じです。
  • ワーキングセットは常に一定の期間にで計測されます。しかし、連続的なものです。データのアクティビティについてはサイクルがあり、何度も繰り返されます。
  • ワーキングセットはReadWriteを含みます。それぞれの総計を知ることが重要で、それはReadとWriteは異なる特性を持ち、ストレージシステムへの要件も異なっているからです。
  • ワーキングセットのサイズは総計やキャパシティと関連します、しかし、どれだけの数のI/Oによってそのキャパシティが出来上がっているかはブロックサイズによって様々です。
  • データアクセスのタイプによっても異なってきます。1つのブロックに対して1000回のReadを発行するのか、1000のブロックを1回Readするのか?既存のデータを大抵の場合上書きしてしまうWriteなのか、新しいデータなのか? これによってワークロードはユニーク担っていくのです。
  • ワーキングセットのサイズはワークロードやデータセンタの変更によって大きくなり、変わっていきます。他のあらゆるものと同じく留まっているものではないのです。

簡単にするために、ワーキングセットを視覚的に表してみました。以下の様なものになります。

Fig319もし、ワーキングセットが常に一定の期間によって決まるのであればどうやってそれを定義できるのでしょうか?実際には出来るのです。ワークロードというものは活動の後に、休眠の期間を持つものだからです。これは「負荷サイクル(duty cycle)」と言われることもあります。負荷サイクルは1日のメールボックスサーバや、1時間のSQLサーバのバッチ処理の負荷、30分のコードのコンパイルのようにパターンを示すようになります。長い時間の間隔で見ると仮想マシンの負荷サイクルは以下の様なものになります。

Fig320

ワーキングセットを定義するためには時間を長くとってみることが重要です。しかし、本来の目的はワーキングセットを最短時間で見つけ出すことです。つまり、1つかもういくつかの負荷サイクルでそれを見つけ出すことなのです。

なぜそれが重要なのか?

ワーキングセットのサイズを理解することで、ワークロードの振る舞いを理解することができ、環境の設計、運用そして最適化を行うことが出来るようになります。全く同じ理由でコンピューティングやメモリの要求にすでに目を配っていると思いますが、ワーキングセットを含むストレージ特性についてもそれを知っておくべきなのです。ワーキングセットを理解し、正しく計算することでデータセンタの深淵でどんなことが起こっているかを理解できるのです。実際にワークロードのパフォーマンスが貧相であったり、階層化ストレージやハイブリッドストレージやハイパーコンバージド環境でパフォーマンスの不均一が起きたりということを聞いたことがありませんか?これらはキャッシュレイヤのサイズが不十分にしかサイジングされていなかったことによって引き起こされているのです。実環境のワークロードの正しくないワーキングセットのサイズの計算ミスはこうした問題を引き起こすのです。

従来のやり方での計算方法

何年もの間、このワーキングセットのサイズにまつわるミステリーは計算をしようとした悲しい試みの結果生み出されてきました。以下のような試みです:

  • わかっている(けれどもさほど役には立たない)要素を用いての計算。大抵の場合、一定時間のIOPSを確認するというものです。もう幾つか要素を加えて綺麗に着飾ってみたものもあるかもしれません。これはひどいものです。ワークロードは全て同じブロックサイズを生成していると仮定してしまっていますし、ワークロードが常に一定であるとも仮定してしまっています。その上、すべてのReadとWriteが同じブロックサイズであると仮定してしまっているので、これも誤りです。
  • ストレージのキャッシュレイヤとしてワーキングセットをストレージ側で図るという試み。この試みも場所を間違っているという点で失敗してしまうことがあります。どのブロックのデータがよくアクセスされているかということはわかるかもしれませんが、仮想マシンやワークロードからくる要求を理解しないままになっています。データに対するインテリジェンスの殆どはvSphereホストのHBAを抜けた瞬間に失われてしまいます。仮想マシンに対する情報の不足しているとノイジーネイバーな仮想マシンからによるキャッシュの汚染などの際には適切なストレージ上のキャッシュサイズの測定は行えなくなってしまいます。
  • 変更差分バックアップを取って、変更差分の総計を見るというやり方。これはロジカルに見えますが、誤解をはらんでいます。というのも、何度も何度も上書きでWriteされたデータを合計したものではなく、Readも勘定に入っていません。変更差分バックアップもワークロードのサイクルを表したものではないのです。
  • 推測。ストレージのキャパシティのうち、一定の割合がホットなデータであるという「推奨」を目にすることがあると思います。これは最もよく目にするものですが、これはほとんど不可能です。十分に大きければよいですが、足りなかった場合技術的にも金銭的にも大きな爪痕を残します。

お分かりのとおり、こうした古い戦略は上手くいっていませんし、管理者に対して本当の回答をせずに逃げ回っているに過ぎません。データセンタのアーキテクトはこうした要素までもを環境の設計や最適化に組み入れて上を目指していかなくてはならないのです。

PernixData Architectとワーキングセット

ハイパーバイザーは多くのものを計測するにはうってつけのコントロールプレーンです。ストレージのI/Oレイテンシを例に取ってみましょう。ストレージ装置からのレイテンシは気にする必要はありません、仮想マシンが実際に見ているものが重要です。でしたら、ハイバーバイザーカーネルの機能を拡張して、仮想マシンごとのワーキングセットのデータについての知見を得てはどうでしょうか?これがまさにPernixData Architectが提供するものです。ブロックサイズなどの以前ではまるで不可能だったストレージ特性を理解し、表示しながら、Architectは仮想マシン毎のワーキングセットの計算に不可欠なキー要素をも理解していくのです。

PernixData ArchitectはvSphereクラスタ内の個々の仮想マシンごとにワーキングセットを見積ります。仮想マシンごとの見積もり以外に、ホスト単位での見積もりも可能です。以下の例はそれぞれのブレイクダウンを表示しています。

Fig321そして、以下はホスト毎の見積もりです。

Fig322この見積りがユニークなのはReadWriteの両方をその要素としていることです。なぜそれが重要なのでしょうか?ReadとWriteはインフラストラクチャに異なる要求をかけるということがわかっています。ですから、片方の数字だけではまさに片手落ちになってしまうのです。

PernixData ArchitectはFVPとは異なる単独のプロダクトです。しかし、FVPの利用者がArchitectも利用している場合にはFVPがハンドルしているキャッシュのコンテンツとその解析によって特別な、どれだけのフラッシュかRAMがそれぞれのホストに搭載されているのが最適なのかという計算結果も利用することができます。この結果はホストごとの推奨値として表示され、最大限の場合と最低限の場合とが表示されます。

Fig323

このデータで何が出来るのか?

ワークロードのワーキングセットのサイズを知ることができれば、より良い環境設計と最適化についての多くの扉が開くことになります。以下はその一例です。

  • 永続ストレージの最高パフォーマンスレイヤを適切なサイズで購入することが出来る
  • PernixData FVPのようなサーバサイド高速化製品を利用している場合、ホストごとに適切なフラッシュやRAMのサイズを設定でき、できうる限りのI/Oをストレージ装置からオフロード出来る
  • もし、別のデータセンタへデータをレプリケーションしようとしているのであればワーキングセットの見積もりのWriteのゲージを見ることでどれだけの帯域が2つのサイト間で必要なのかを知ることが出来る
  • 既存のハイパーコンバージド環境にどれだけのキャッシュレイヤが必要かを知ることが出来る
  • チャージバック/ショーバック 環境において誰がヘビーユーザーを知るというもう一つの方法になります。そしてチャージバック/ショーバックの配賦において非常に上手く動作します。

まとめ

環境のワーキングセットのサイズを知ることは環境の運用において何よりも重要な要素となりますが、これまで非常に難しいものでした。ArchitectはvCenterやvCenterから情報を得る他の従来からの監視システムでは不可能だった知見や解析を提供します。ワーキングセットのサイジングはスマートでデータに裏打ちされた決断をサポートするArchitectの機能のほんの一部です。優れた設計は想定通りの一定のパフォーマンスを生み出しますし、大切なITの予算適切な利用を実現します。実際のデータに基づき、推測をすて、理想の環境を生み出しましょう。

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

2015/12/01

なぜなに Data Domain - 第八回 - Data Domain と Backup Exec バックアップパフォーマンス動作検証レポート

こんにちは。

Data Domainも今回で第八回目となりました。
第四回目ではDD Boost機能について見てきました。

今回はEMCジャパン様、ベリタステクノロジーズ様のご協力のもと、
Data Domain DD BoostとBackup Execを利用したバックアップ
パフォーマンス動作検証の結果をご紹介します。

flair 検証環境の構成を見ていきましょう。

■バックアップ検証環境
1_7
・ バックアップサーバ(1台)
・ バックアップ対象クライアント(ノートPC×5台,サーバ×1台)

バックアップ検証環境(ネットワーク構成)2_3

flair 次は検証項目パターンを見ていきましょう


■ 検証項目パターン
各検証項目ごとにバックアップを3回実施し、バックアップの所要時間を測定しております。

4_10


<説明>
【検証1】【検証2】【検証3】【検証7】【検証8】【検証11】はバックアップ先を
CIFSとしたバックアップ検証になります。

【検証4】
DD Boostを利用し、Backup Execの重複排除処理をクライアント重複排除とした
バックアップ検証になります。(対象台数5)

【検証5】
DD Boostを利用し、Backup Exec側の重複排除処理を
メディアサーバ重複排除としたバックアップ検証になります。(対象台数5)

【検証6】
DD Boostを利用し、Backup Exec側の重複排除処理をクライアント重複排除とした
バックアップ検証になります。(対象台数1)


flair 
次は各検証項目のバックアップ時間の結果について見ていきましょう。

■ バックアップ時間の比較

5_9

 shine<全検証項目のバックアップ時間の結果>shine
全検証項目のバックアップ時間の比較をしますと、【検証4】のDD Boostを利用した
クライアント重複排除
によるバックアップはパフォーマンスが向上し、バックアップ時間が短縮
する結果となりました。


■ まとめ
flair 弊社の検証ではバックアップ対象台数が5台の場合、CIFSと比較して
  DD Boostを利用するクライアント重複排除によるバックアップでは
  スループットが1.5倍~2倍に向上する結果となりました

flair バックアップ対象が1台の場合、DD Boostによるスループットの効果は
  得られませんでした。

  
『DD Boost』は同時に実行するバックアップジョブ数シングルストリーム数
少ない場合、DD Boostによるパフォーマンス向上の効果を得られない場合が
ありますので、ご注意ください。

次回は別の機能についてご紹介したいと思います。

それでは次回もよろしくお願い致します。

担当:斉藤・吉田