« 2015年5月 | メイン | 2015年7月 »

2015年6月

2015/06/29

インメモリコンピューティング - メモリレーンを散策

本ブログエントリーはPernixData社のプロダクトマネージャであるTodd Mace氏のブログ記事を翻訳しています。 

本記事の原文はIn Memory Computing - A Walk Down Memory Laneで閲覧可能です。

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

PernixDataの製品担当VPであるBala Narasimhanをゲストに迎えて記事をかけることを喜ばしく思います。彼はインフラストラクチャレベルのインメモリーコンピューティングについての新しい連載を始めようとしています。これは将来的にあなたの環境の考え方や設計を変えていくことになるでしょう。お楽しみに。

インメモリーコンピューティング(IMC)は近頃、再び脚光を浴びています。この記事ではメモリレーンを散策(特に深い意味はありません)し、IMCの進化について追求していきます。特に我々はストレージシステムとIMCの接合点をフォーカスしていきたいと思います。

以下はIMCの進化の簡単なタイムラインを表したものです。

Fig254

IMCはもともとはオペレーティングシステムや各種データベースのバッファキャッシュと呼ばれていたものです。バッファキャッシュは今日でもこれらのソフトウェアシステムに統合されたパーツとして残っています。バッファキャッシュは直近でアクセスされたデータのReadキャッシュです。ディスクアクセスを避ける事ができるため、バッファキャッシュにヒットしたReadは高速になります。しかしながら、Writeはその下にあるデータストアと同期させる必要があります。これはつまり、バッファキャッシュはReadの助けにはなりますが、Writeの手助けにはまったくなりません。全てのデータをメモリ内に保持し、高速なクエリ処理を実現するインメモリデータベース(IMDB)が1990年台に登場しますが、さほど大きな進展はしませんでした。近年になってIMDBは再び脚光を浴びるようになり、データベースの業界において、大きな話題となっています。再び光を浴びている理由の一つにはサーバに搭載できるRAMの総量が劇的に大きくなったことが挙げられます。1台のサーバが1テラバイト以上ものRAMを保持できるのです。IMDBもバッファキャッシュと同様に、Readをうまく取り扱うことができますが、Writeについては永続的なメディアとの同期が必要という理由のため、パフォーマンスについてはペナルティを受けてしまいます。2000年台のはじめ、Memcachedのようなメモリキャッシングライブラリが登場します。これによってアプリケーションはアプリケーションのロジック内でメモリのパフォーマンスを活用できるようになりました。アプリケーションのオーナーはAPI経由でこれらのライブラリを利用し、よく利用するものをメモリを使ってキャッシュすることができるようになったのです。残念なことに、利用するメモリキャッシングライブラリ自身の変更や、アプリケーションへの変更はアプリケーションを完全に書き換えるということを意味していました。

これらのすべてのアプローチはメモリを不揮発性のキャッシュとして活用しようというアプローチでした。つまり、これらのすべてのアプローチはReadキャッシュのアプローチであり、アプリケーションの一部のみの高速化に過ぎないということです。更に重要なことは、これらのすべてのアプローチはインメモリーコンピューティングをアプリケーションの中に押しこむようなものだということです。これによって多くの不幸な副作用が起こります。

  • アプリケーションは不必要なまでに複雑になります。複雑なキャッシングのロジックと後ろのデータストアとの一貫性の保証を維持していかなければなりません。
  • どのようにIMCを活用するか考える責任はエンドユーザーに覆いかぶさります。バッファキャッシュの適切なサイズを決めたり、どのテーブルをRAMに配置するかなどの判断はオーナーが判断しなくてはなりません。
  • アプリケーションのオーナーは必ずしもアプリケーションが展開されているインフラを管理できるとは限りません。むしろ、不幸なことに(サーバなどの)インフラストラクチャがどのように利用されていたり、拡張されていくかを知らないまま、どれだけのメモリをアプリケーションがキャッシュとして利用できるか決めなくてはなりません。さらに、アプリケーションのオーナーは同じサーバ上で他にどのようなアプリケーションが動作しているかを俯瞰的にみることもできません。
  • メモリ管理についての革新を活用するということも非常に大きな困難です。NUMAはアプリケーションがNUMAに対して対応しなければその恩恵をうけることができないという意味で、非常に良いインフラストラクチャレベルの革新の例と言えるでしょう。

これら全てはRAMのデータレイヤとしての強みを完全に有効活用できているとはいえないということを意味しています。これは今日まではほとんどのサーバが32GBや64GBと言った、非常に少ない量のメモリしか搭載していなかったので問題ではありませんでしたが、急速に変わりつつあります。数テラバイトのメモリを搭載するサーバは今日、もはや稀ではなく、また、この傾向は続いていきます。IMCを根本から再度、考えなおすべき時が来ているのです。アプリケーションがよりよいReadキャッシングができるようにする改善や、責任をエンドユーザーに負い被せることは答えではありません。将来、このシリーズの記事の中では高性能、高拡張性をもつインフラ全域に渡るIMCをご紹介していきます。

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

2015/06/26

本邦初公開!! V9000性能検証結果!!!

はじめまして FlashSystem V9000 検証担当:稲場です。


さて、先日は日本初上陸を果たしたV9000がネットワールドにやってきた!!
という記事をご紹介いたしました。

今回は、ついにその性能のベールを脱ぐ!!

という事で、
FlashStorageを検討する際に一番気になるポイントかと思いますが
FlashSystem V9000の性能検証の結果をご紹介致します!

Flashの性能ってどの位なのかっ!? 

FlashSystem V9000の実力は!? 


◆検証環境について

検証構成図

注:本構成ではAC2コントロールエンクロージャとAE2ストレージエンクロージャ間はそれぞれ8G x 4本で物理結線を実施しましたが、本来はAC2、AE2間は6本ずつでの結線が推奨されます。

Topology

◆検証機器
 FlashSystem V9000
  モジュール:2.9TBモジュール x 12

 サーバは、ベアメタルサーバを2台用意しました。それぞれのスペックは以下になります。
 Server_A
  OS:Windows2008R2 SP1 x 2台
  CPU:Intel Xeon CPU E5-260 v3 2.6GHz x 20CPU
  MEM:64GB
  Disk:RDM接続(500GB x 20) ※1:File Systemは経由しない

 Server_B
  OS:Windows2008R2 SP1
  CPU:Intel Xeon CPU E5-2660 v3 2.6GHz x 24
  MEM:96GB
  Disk:RDM接続(500GB x 24) ※1:File Systemは経由しない

 ※1:V9000の領域をOSにマウントさせオンライン状態にした状態であり
    ファイルシステムでのフォーマットは実施していない状態

◆チューニング設定
 ベアメタルサーバ(Windows2008R2 SP1)
  電源オプション バランス⇒ 高パフォーマンス
  SDDDSMインストール ※2
  ※2:MicrosoftのMPIOテクノロジーに基づきマルチパス入出力サポートを提供するためのモジュール

 FlashSystem V9000
  ボリュームキャッシュモード: 使用不可(キャッシュ無効)
  ボリュームサイズ:500GB
  ボリューム数:Server_A用:20※3 Server_B用:24※3 
  ※3:ボリューム数は使用するサーバのCPUコア数と合わせる

 

◆負荷ツール(IOmeter)設定
 IOmeter設定
 ・Worker数 :それぞれのサーバのCPUコア数で設定(Server_A:20,Server_B:24)
 ・Targets  :各Worker毎に1つずつVolumeを指定
 ・of OutstandingI/Os:32 per target
 ・試験パターン  :4k Read 100% rondom 0%
負荷実施端末:Server_A,Server_B Total:2台


◆検証結果
 FlashSystem V9000 のパフォーマンス結果

Graf_3

 

◆まとめ

53万IOPSを処理していても遅延はほとんど発生せず、

 常に遅延はms以下!!

・今回の構成ではRead処理のみを実施したが、
 Write処理であれば、
 より大容量のモジュールタイプを使用する事で、
 IOPS処理性能を向上させる事ができる!

 

Hyou_6

今回は、簡単なIOmeterを使用した性能検証の結果をご紹介させて頂きました。

今後のFlashSystem V9000 検証予定としては以下を考えております

 ・今回と同様の性能試験をV7000で実施し
  Disk vs Flash , SSD vs Flash の性能比較を実施

 ・DB環境での使用を想定したパフォーマンス検証を実施

 検証終了後またBlogにアップさせて頂きたいと思います!
  (頑張れV9000検証担当!って俺か。。。)

 

2015/06/25

MobileFirst Protect (MaaS360) (2) MDM編

レビューって大事ですよね♪ こんにちは、鈴木です。

昨日の記事をアップして事後報告したところ、ナニコレ?な誤字がありました。(修正済みです)

今後は気を付けます。。。きっと

今回は、(2)ということで機能の話をしていきます。ただ、弊社のWebを見ているとそこそこ細かく説明している内容ががが

http://www.networld.co.jp/ibm/mfprotect/main.htm

・・・そういえば作ったと聞いたような聞いていないような・・・

ですので、文言だけでわからないちょっと細かい部分を書いていきたいと思います。

今日は↓このあたりを。

Emm_mdm

「Mobile Management」一般的にはMDMと呼ばれる機能の部分です。
この機能ですが、この製品独自の特徴はあまりなかったりします。

特徴がないものを勧めるとかどうなの?と意見をいただくかもしれませんが機能の部分でのネックとしてOS側の制限があります。特に最近ですとiOS系デバイスの利用が多いので、話としてもそのあたりの話になるのですが、正直なところiOSの制限でできることが限られてきます。ですので、他社製品であっても機能の○/×表をつけるとほぼほぼ同じになってきます。

特徴的なこととしては、複数OSにまたがってデバイスの管理ができることです。対象OSとしては、iOS, Android, Windows Phone, BlackBerry, Windows PC & Mac になります。ただ気を付けてほしい点としては各OSによって制御できる内容は異なるので事前に使用するOSを確認し、なにができるかは調査する必要はあります。

そのほかとしてはMAMの部分も機能としては入ってきます。機能としてはアプリケーションの配信はもちろんできますし、企業用のアプリストアの設定など、必要とされる設定はそろっています。それ以外のおすすめとしてはコンプライアンス・ルール設定です。

コンプライアンス・ルール設定では、ポリシーに違反したデバイスについてアクションを行うことができます。なにがどこまでできるかについてはきっとそのうち書きますが、一例としては、会社として認めていないアプリをユーザーがインストールした場合に、デバイスをワイプしてしまったりできます。(ワイプ=初期化なので基本はやらないですが・・・)

こういったポリシー違反に対する操作系は設定が面倒なイメージがありますがこの製品はさくっと動かすことができます。

今回はこれくらいで!次回はProductivity Suiteについてご紹介したいと思います!

鈴木(け)

2015/06/22

ONTAP8.3降臨編 これであなたも!ONTAPシミュレーターマスターだだだっ!!②

皆さんこんにちは。

NetAppチームの和田です。

 

さすがに前回の記事で「毎週連載を予定しています!」と書いておいて

きちんと記事がアップされなかったら多方面から怒られそうです。

常に二週間分の記事のストックがあれば安心ですね。SnapVaultですね。

 

目次(カッコカリ)

ONTAPシミュレータの入手とVMデータストアへの展開編←前回のテーマ

・シミュレータ起動前の下ごしらえ編←今回のテーマ

・初期セットアップとディスク本数/容量を増やしてみましょう編

・SVMも作っちゃいます?編

・BRODECAST DOMAIN編

 

目次が前回と微妙に変わっていることに気づいてはいけません。

 

 

 

さて、前回の記事ではシミュレーターをデータストアにアップロードするところまで実施しました。

tgzファイルを展開すると非常にたくさんのvmdkファイルが見えたはずです。

 

この大量のvmdkファイルをひとつのvmdkファイルに結合する操作が必要です。

 

操作自体はこのKBにも書いてあることなのですが、せっかくですので

スクリーンショットつきで説明していきます。 

・ 

 

ESXサーバーにsshで接続します。

この記事ではESX側でのsshログインの有効化の手順は割愛させていただきます。。

 

sshログインを有効化してもチャレンジレスポンス認証でないとログインできません。

ちなみに私はここでハマりました。

 

68

cdコマンドで先週アップロードしたシミュレータがあるフォルダまで移動します。

デフォルトでは/vmfs/volumes以下にESXサーバにマウントされたデータストアがあるはずなので、

さらにその下まで移動しましょう。

 

以下のコマンドを実行してvmdkファイルを操作するモジュールを読み込みます。

 

vmkload_mod multiextent

 

ここまで操作するとこんな感じになります

 

Ws000003

このフォントは見ればわかる通り創英角ポップ体です。

インフラエンジニアの癒しです。

 

Ws000004_2

うわ。。lsコマンドを実行すると大量のvmdkファイルが見えますね・・・

 

とりあえず無心で以下のコマンドをコピペして実行してみましょう。

 

vmkfstools -i DataONTAP.vmdk DataONTAP-c.vmdk -d thin

vmkfstools -i DataONTAP-sim.vmdk DataONTAP-sim-c.vmdk -d thin

vmkfstools -U DataONTAP.vmdk

vmkfstools -U DataONTAP-sim.vmdk

vmkfstools -E DataONTAP-c.vmdk DataONTAP.vmdk

vmkfstools -E DataONTAP-sim-c.vmdk DataONTAP-sim.vmdk

 

Ws000005

 

驚きのすっきり加減でございます。

 

この操作をもう片nodeのシミュレーターが入っているフォルダでも実行して、

データストアブラウザでvmxファイルをインベントリに追加します。

 

追加だけです。起動はまだです。

 

・・・思い出してください。7modeでは不要でcDOTでは必要だったもの。

cluster interconnectです。

10Gでノードごとを接続する、アレです。

 

 

cluster interconnect用のvSwitchを追加しましょう。

 

ネットワークラベルのおなまえは何でもいいのですが、

今回は"cluster_interconnect"で作成しました。

 

内々のネットワークですので、ネットワークアダプタの設定は不要です。

74

 

cluster interconnect用vSwitchの作成ができましたら、インベントリに追加した仮想マシンの編集を行います。 

 

ハードウェアの追加からシリアルポートを選択し、

名前付きパイプに接続→近端:サーバ 遠端:プロセスを選択します。


パイプ名は一つ目のノードが\\.\pipe\仮想マシン名-cons
二つ目のノードが\\.\pipe\仮想マシン名-gdb です。

 

こんな感じですね.

儀式みたいなものです。

 

この設定をせずにシミュレーターがきちんと動くか検証すべきとは思うのですが、なかなか時間が・・・

 

16

最後にネットワークの設定を行います。

 

シミュレータのネットワークアダプタ1と2がcluster interconnect用ポートですので、

先ほど作成したvSwitchのポートグループを指定します。

 

ネットワークアダプタ3と4はサービス用のポートですので、

皆さんの環境の適切なvSwitchのポートグループを指定しましょう。

 

12_2

13

ここまでの作業が終わったら仮想マシンのスナップショットを取得しておきましょう。

 

次の記事に記載する予定の操作を失敗したとき、このスナップショットが非常に役に立ちます。

ホントです。

IBM IPS製品ブログ開始のごあいさつ

みなさん、はじめまして。

IBM IPS製品技術担当の小室です。

今回、新たにIBM IPS製品に関するブログを開始する運びとなりました。

IBM IPS製品に関するさまざまな情報をお伝えしていきたいと思います。

どうぞよろしくお願いいたします。

初回の今回は、IBM IPS製品のラインナップについてご紹介します。

以下が、IBM IPS製品のラインナップです。

  1. IBM Security Network IPS アプライアンス GXシリーズ(旧名称:IBM Proventia Network IPS)

    ・X-Force(民間企業最大のセキュリティ研究開発組織)による研究結果の活用
    ・独自のプロトコル分析モジュール(PAM)による脆弱性分析
    ・脆弱性に対する事前防御を実現するVirtual Patch Technology

    Gx_3

     

  2. IBM Security Network IPS 仮想アプライアンス GVシリーズ(旧名称: IBM Proventia 仮想化ネットワーク・セキュリティー・プラットフォーム)

    ・実績のIBM Security Network IPS アプライアンスを仮想化
    ・仮想環境内にIBM Security Network IPSを実装可能

    Gv_3

     

  3. IBM Security Network Protection XGSシリーズ NEW!!

    ・次世代型IPSで求められる機能を搭載
    ・IDやアプリケーションによるコントロールを提供
    ・IPレピュテーションやSSL Inspection

    Xgs_3



過去に、インターネットセキュリティシステムズ社からProventiaというIPSが販売されていましたが、2007年に経営統合が行われ、現在はIBMブランドとして開発・販売を行っているのが、IBM Security Network IPSになります。

IBM Security Network IPSには、物理アプライアンスモデルのGXシリーズと仮想アプライアンスモデルのGVシリーズがあります。

IBM Security Network Protection XGSシリーズについては、IBM Security Network IPSの機能を継承しつつ、IPレピュテーションやSSL Inspectionなど、次世代型IPSに求められる機能を搭載した最新モデルになります。

現状、物理アプライアンスモデルのみの販売となりますが、今後、仮想アプライアンスモデルがリリースされる予定です。

製品のおおまかな棲み分けですが、純粋なIPS専用装置をお求めのお客様には、GXシリーズ、仮想環境の保護を行いたいお客様にはGVシリーズ、IPレピュテーションや暗号化通信の検査など、より高度なセキュリティチェックを行いたいお客様には、XGSシリーズのように棲み分けしていただければと思います。

以下は、IBM IPS製品で行える対策になります。

レガシーOSの保護と延命

※直近のOSとアプリケーションのサポート終了状況

  • RedHat Enterprise Linux 3(2014年1月サポート終了)
  • Windows XP/Office2003(2014年4月サポート終了)
  • RedHat Enterprise Linux 4(2015年2月サポート了)
  • Windows Server 2003(2015年7月サポート終了)
  • RedHat Enterprise Linux 5(2017年3月サポート終了)


直近では、2015年2月に、RedHat Enterprise Linux 4のサポートが終了しました。また、2015年7月にはWindows Server 2003のサポートが終了しますので、OSサポート切れ対策にIBM IPS製品をご利用いただけます。

突発的に発生する広範囲への脆弱性対策

2014年に世間を騒がせた、OpenSSL、Apache Struts、IEなどの突発的に発生する広範囲への脆弱性対策にIBM IPS製品をご利用いただけます。

標的型メール等による情報漏えい対策

実在の組織や活動内容を騙って、特定の企業や組織を対象とした悪意あるメールの送信が増えています。ウイルスの侵入や感染を防ぐためのネットワーク監視やウイルスに感染したPCによる外部との通信を検出し、ウイルスが窃取した情報を外部へ送信することを防ぐ対策としてIBM IPS製品をご利用いただけます。


以下の弊社WebページにもIBM IPS製品のラインナップについて記載がありますので、ご覧ください。

http://www.networld.co.jp/ibm/hw.htm

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

担当:小室

MobileFirst Protect (MaaS360) (1) 基礎編

こんにちは。

数年前にモバイル関連製品であれこれ見たり触っていたりしたらいつのまにか担当になっていた鈴木です。

あれやこれやいろいろと触っているので毎回違う製品の話になったりするかもしれませんが、まず最初はちょっと連載ちっくにやっていきたいと思ってます。(途中で人が変わるかもしれませんがフフフ)

ところでみなさんの会社ではスマートフォンは支給されていますか?また、メールとかも見れたりしますか?スマートフォンを落としたら初期化されるような話を聞いていたりしませんか?

と、いうことで今回は「スマートフォン」というキーワードがある通り、モバイル系の製品のお話しになります。

ご紹介する製品名は

       MobileFirst Protect (MaaS360)

                                           death。

この製品 IBM社 の製品になります。

個人的な感覚(偏見)ですとIBMさんの製品はむずかしくて・・・グフッ と思っていたのですがこの製品でかなり印象が変わりました。

ではでは、実際の製品について。

製品正式名称は「 IBM MobileFirst Protect 」で旧名称は「 MaaS360 」となります。

なぜ旧名称が?という点ですがこの製品IBM社が買収した製品になります。

買収元の会社は「 FiberLink 」という会社になります。まだ、買収して日が浅いのでWebのドメインやメール等にいろいろと痕跡が残っています。ちなみにまだ新名称はそこまでなじんでおらず、「 MaaS360 (まーすさんろくまるorまーずさんろくまる) 」と言ったほうが通じたりします(笑)

また、この製品ですが、「 Complete Enterprise Mobility Management 」と呼ばれています。おそらく大半の人がナニソレ?おいしいの?状態かと思うのでちょっと補足します。

最近のモバイル関連製品のくくりとして「Enterprise Mobility Management」というものが出てきています。このくくり、ざっくりいうとMDMとMAMとMCMの機能が含まれたモバイル製品になります。絵的にはこんな感じです↓

Emm_2



IBM的には「CompleteされたEMM」とか、ちょっと前だと「Totalな」とか言っていました。そうなるとこの製品的にはどんなことができるのか?ということになりますが機能的にはCompleteとかTotalとか言ってしまう感じなのでいろいろあります(笑)

これも図でざっくり表しているものがあります

Emm_maas360

6つの機能のくくりがありそれぞれのくくりの中にも細かい機能があります。この記事で機能まで書いてしまうとかなりぐったりするのでまた今度・・・

では、この製品の何がよいのか?というところですが3つあります。

  1. 簡単
  2. 早い
  3. 安い(かも)

「1.簡単」ですがこの製品基本マニュアルがいりません。理由としてはコンソールがすべて日本語化されていて且つ各設定に設定の内容が記載されています。

「2.早い」ですが、あとでこっそり書きますが弊社のトライアル申込みサイトから登録してもらうとすぐに使えるようになります。環境にはいって単純な端末管理であれば30分~1時間で設定できます(経験談です)ですのでさあやってみよう!と始めれば1日である程度動かせるようになります。

最後に「3.安い(かも)」ですが、この製品は各機能ごとにライセンスが販売されています。具体的には↑にある6つのくくりだけでなく、その中の各機能単体での購入もできます。あーんど実は1ライセンスからも買えます!

そんなこんなでこの製品、いろいろと面白い話もありますし、勝手に宿題にしている機能の説明の話もありますので次回をご期待いただければと思います。

☆宣伝

この製品のトライアルは弊社Webサイトから開始できます。

http://www.networld.co.jp/ibm/mfprotect/trial.htm

お時間のある方、興味のある方は是非!

鈴木(け)

Virtual VNXマスターへの道:その①

 初夏の候、緑がまぶしい季節になりました。全国7000万人のEMCファンの皆様 いかがお過ごしでしょうか。今回、初投稿させて頂きます銀のしゃちほこといいます。趣味はバスフィッシングとサッカー観戦、名古屋グランパスをこよなく愛する駆け出しの名古屋人です!!

 今回はEMC World 2015で発表されたVirtual VNX(以下、vVNX)を紹介したいと思います。まずは、vVNXって何!?という方に簡単にご説明を。EMCではストレージをソフトウェアによって仮想的に提供する製品開発プロジェクトが数年前から行われており、vVNXはまさにそのプロジェクトの記念すべき第一歩となる製品なのです。ソフトウェアで定義されたストレージ、カッコよく言うと、Software Defined Storageとなります!!

 vVNXはVNXe3200のアーキテクチャを採用しており、VNXe3200の機能をほぼ忠実に再現しています。CIFS/NFSに加えて、iSCSIをサポートしており、ユニファイドストレージとして利用することが可能です。さらにSnapshot/Replication等のオプション機能までサポートしています。しかも無償!!今現在はコミュニティサポートのみとなっていて、テストや開発環境での利用となりますが、今後は本番環境で利用可能な製品版がリリースされる予定となっています。

それでは、気になるvVNXの動作要件とセットアップの流れを見ていきましょう。

◆vVNXの稼働OS

0001_6 

vVNXのハードウェア動作要件

☆CheckPoints:リソース要件を満たさないとvVNXが起動しない場合があるので、注意して下さい!!

0002_3

vVNXとVNXe3200のLimitation比較

0003_3

vVNXとVNXe3200の機能比較

0004_3

vVNXのダウンロード

まずは、EMCのサポートサイトからvVNXのソースファイルをダウンロードします。事前申請や登録、アンケートなどは一切不要で、無料で瞬時にダウンロード可能です。サポートサイトのアカウントは事前にご用意下さい。

01

<ダウンロード先>

https://www.emc.com/products-solutions/trial-software-download/vvnx.htm

 

vVNXのデプロイ

ダウンロードしたファイルを仮想環境に展開していきます。今回のブログはvVNX Ver.3.1.2 ESXi 5.5 updateなしの環境で構築。環境毎に動作が異なる可能性があります。

vSphere Web Clientを起動して、「OVFテンプレートのデプロイ」を実行します。

 ☆CheckPoints:デプロイを行う際に、Web Clientではエラー表示される場合があるのですが、その場合には、vSphere Clientからの操作も試してみて下さい!!

02

 

OVFテンプレートのデプロイウィザードが起動するので、「参照」をクリックしてダウンロードしたソースファイルを選択し、「次へ」をクリックします。

03 

詳細の確認画面が表示されるので、「追加の構成オプションの承諾」のチェックボックスをオンにして、「次へ」をクリックします。

04

 

EULAの承諾画面が表示されるので、「承諾」をクリックした後、「次へ」をクリックします。

05

 

名前およびフォルダの選択画面が表示されるので、vVNXの名前と配置先を指定して、「次へ」をクリックします。

06

 

リソースの選択画面が表示されるので、vVNXのデプロイ先のリソースプール・ホストを選択して、「次へ」をクリックします。

07

 

ストレージの選択画面が表示されるので、vVNXの保存先となるデータストアを選択して、「次へ」をクリックします。

☆CheckPoints保存先のディスクフォーマットは【シックプロビジョニング(Eager Zeroed)】が推奨!!

08

 

ネットワークのセットアップ画面が表示されるので、vVNXの各ネットワークの接続先を指定して、「次へ」をクリックします。

09

 

テンプレートのカスタマイズ画面が表示されるので、vVNXの管理名・管理用IPアドレスを入力して、「次へ」をクリックします。

☆CheckPoints:初期セットアップツールのConnection Utilityからセットアップしたい方はブランクでOK!!

10

 

設定内容が表示されるので、内容を確認し、「デプロイ後にパワーオン」のチェックボックスをオンにして、「終了」をクリックします。

11

 

約60分ほどセットアップに時間がかかるので、ここでしばし休憩です!!

 

vDiksの割り当て

セットアップが完了したら、次はデータ保存先のvDiskの設定を実施します。

vVNXの「仮想マシンの設定の編集」をクリックします。設定の編集画面が表示されるので、新規デバイスで「新規ハードディスク」を選択して「追加」をクリックします。

12_2

 

追加するハードディスクの容量を指定して、保存場所を選択します。

☆CheckPoints:保存先のディスクフォーマットは【シックプロビジョニング(Eager Zeroed)】が推奨!!

また、vVNXとは異なるデータストアから取得する事が推奨!!

13

 

追加した新規ハードディスクの内容を確認して、「OK」をクリック。

14

 

以上で下準備は完了です!!

これであなたもvVNXマスターです!!続きはまた次回!!

なぜ私がストレージにフラッシュを入れないと決めたのか?

本ブログエントリーはPernixData社のプロダクトマネージャであるTodd Mace氏のブログ記事を翻訳しています。 

本記事の原文はWhy I Decided Not To Put Flash In The Arrayで閲覧可能です。

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

話は3年前にさかのぼります。その頃私はジョージア州のアトランタで大きなNPO法人の情報システムの統括を生業としていました。その頃に着手していたことの1つが6ヶ月ですべてのシステムを100%仮想化するというものです。このマイルストーンを達成する前に成し遂げる必要があるタスクが山積みになっているような状況でした。最初のタスクはストレージプラットフォームのアップグレードです。当時のワークロードの特性ですら、パフォーマンスに影響が出ている状態でしたから。あらゆるプロジェクトにおいて、我々は市場のメジャーなメーカーすべてと一緒に、トライアルを実施したり、他の顧客と話しをしたり、そしてプロジェクトのための総合評価を実施したりしていました。NPOですから、コストに対して厳しくするということも重要ですが、それ以上に我々が行うこと全てに対して慎重でもありました。

アップグレードしようとしていた既存のストレージシステムは毎秒7200回転のディスクを組み合わせた24TBのシャーシで、容量としては十分に我々のニーズを満たしてくれたのですが、ほんの3000IOPS程度の負荷を掛けただけで、レイテンシが50ミリ秒にもなってしまいました。お分かりの通り仮想化環境を動作させるには明らかに向いていません!! 我々は登場したばかりの初期のオールフラッシュストレージや、ハイブリッドストレージを検討しました。その全てがIOPSの増加とレイテンシの低減を約束してくれるものでした。問題は決して安い買い物ではなかったということです。つまり、コストを抑えながら、1桁台のレイテンシと50,000 IOPSを両立しないといけないというジレンマに陥りました。とてもむずかしい問題でした。

時を同じくして、私は本当だったらどんなに素晴らしいだろうという魔法の物語を語る紳士に出会いました!その男の名前はSatyam Vaghaniです。PernixDataのCTOで、VVOLS、VAAI、VMFSを世に生み出した人物です。Satyamとのミーティングの直後、私はPernixData FVPのアルファ版を手にする権利を得ました。私は製品がアルファ、もしくはベータのステージであるにも関わらずそれを動作させ、検証しました。そして、すぐに購入することを決め、PernixDataの最初の有償での顧客になったのです。これまでにベータ段階の製品を購入したことはありませんでした。しかし、この製品は普通では無いと感じたのです。その価値と効果はベータであっても保証されていました。新しいストレージをパフォーマンスのために購入する必要はなく、結果として組織はトータルで$100,000もの節約をすることが出来ました。これは我々に固有の問題ではありません。1つのストレージや複数のストレージシステムを組み合わせても解決しないような、アーキテクチャ上の問題だったのです。ですから、今日も私が同じ仕事をしていたとしたら、FVPのスケールアウト性を考えると3年で$500,000に匹敵するような節約ができただろうと確信を持つことができます。環境が大きくなり、100%仮想化されても、私はストレージパフォーマンスの問題を同じように悩む必要はなくなりました。ストレージのファブリックの接続についても悩む必要はなくなっています。素晴らしい仕事をしたということを話すだけでなく、やり遂げたことでCFOを感激させることまで出来たのです。

これによって私はストレージレイヤーにフラッシュを配置した時の無駄と非効率性を確信することが出来ました。ディスクはキャパシティのために利用した場合には安価です。ですから、ネットワークの後ろ側で、自身の制限やボトルネックを持っているモノリシックなボックスに入れてフラッシュのパフォーマンスを得るということは理にかなっていないのです。

今日の話に戻りましょう。フラッシュは非常に業界の中でホットになっています。この話は今日ではより強烈になっています。90,000IOPSとひと桁台のレイテンシのために$100,000もの投資をする人がどれだけいるでしょうか?エンタープライズクラスのSSDは$500ほどですが、50,000IOPSをマイクロ秒単位のレイテンシで実行できます。そこでこんな質問が自然に出てきます。CFOやCIOが納得するような説得ができるでしょうか?

誤解しないでください、私はFVPがストレージのキャパシティを置き換えるとは言っていません。ストレージのキャパシティが必要な場合は新しいストレージを購入しなくてはいけません、しかし、これはオールフラッシュストレージをキャパシティのために買わなくてはいけないということではありません。もっとコスト効率のよい方法があり、重複排除や圧縮率が提供するものよりも経済的に理にかなっているのです。

みなさんに対して個人的なアドバイスをするとすれば、ストレージにフラッシュを入れるという選択に対しては反対したほうがよいでしょう。私にとって、3年前にこれは理にかなっていませんでしたし、今日でも理にかなっていません。

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

2015/06/15

エントリーなオールフラッシュストレージ:VNXe3200 All-Flash-Arrayモデル

こんにちわ、石塚です。気が付けば梅雨入りですね。朝夕は涼しくて、昼間の日差しは厳しい季節になりましたので体調管理には気を付けて下さい。私は4月末から出張続きで少々グロッキーです(@~@) そんな中、6月15日~6月26日にかけてEMC Community NetworkでVSPEX BLUEについてのWebイベントが開催されます。私が回答者として参加していますので、素朴な疑問からちょっとマニアックなご質問でも、なんでもディスカッションできるので是非ご参加下さい!

【エキスパートに聞こう!】VSPEX BLUEを導入!ハイパーコンバージドインフラがこれでわかる

さて、先日のゴールデンウィーク中に開催されていたEMCworldに私も参加してきました。その中で発表されたオールフラッシュアレイシリーズの末弟に位置する(?)VNXe3200のオールフラッシュアレイモデルに興味が沸いたので、久しぶりに検証と合わせた情報をお伝えしようと思います。

VNXe3200は既に紹介済みですが、ユニファイドストレージのエントリーモデルとしてリリースされています。アーキテクチャはVNX2シリーズと同じくしているので、マルチコアパワーを存分に発揮できるのはご存知かと思います。(ご存知無い方は以前に投稿したこちら<http://blogs.networld.co.jp/main/2014/08/2vnxvnxe-f41c.html>をご覧ください)

EMCオールフラッシュストレージはXtremIOだけじゃない
VNXシリーズには以前からオールフラッシュモデル、通称Fシリーズと言うのもがリリースされていましたが、あまり知られていません。Fシリーズはストレージ構成がオールフラッシュパフォーマンスをきちんと発揮するためなのか、固定構成化されていてファイル機能などが利用できませんでした。(VNX-Fの製品情報はメーカサイトをご参照下さい)

VNXe3200オールフラッシュモデルはこれまでのFシリーズとは違い、ユニファイドストレージとしての自由度はそのままに、フラッシュドライブ(SSD)がパッケージ化されていて、大幅にコストが抑えられているのが最大の特徴となります。

EMCのオールフラッシュストレージと言えばXtremIOが最初に思いつきます。インラインの圧縮と重複排除機能を有し、メタデータ情報をインメモリ管理することで圧倒的なパフォーマンスを発揮するストレージです。そして、そのパフォーマンスはスケールアウトすることでリニアに拡張することが出来る、現時点で最高のオールフラッシュストレージです。しかしながら当たり前ですが絶対金額としては「お高い!」※語弊無くお伝えしたいので補足しますが、パフォーマンスあたりのコストからすれば相当お安いとなる価値があるストレージですので、興味がある方は是非弊社担当者までご連絡下さい!!

一方、今回リリースされたVNXe3200オールフラッシュモデルは、従来のVNXe3200との機能の違いはありません。XtremIOのような特筆すべき機能はありませんが、最大のポイントはイニシャルコストの安さと言っても過言ではありません。また、その価格に見合う以上のパフォーマンスを発揮することができます。

VNXe3200オールフラッシュパッケージのパフォーマンスと価格
以下の表はEMCのプリセールスSEトップであるChad氏のサイトからお借りしてきたVNXe3200オールフラッシュモデルのパフォーマンスと価格の一覧です。

Blog_1

実際に3.2TBモデルが見積もれるのでやってみたところ、以下のようになりましたのでご注目下さい!!

Blog_2

この価格は定価ですが、費用対効果を考えてみると、パフォーマンス(IOPS)当たりのコストとしては約88です。1.8TBの実効を容量前提にすると、容量コストとしては約3,523円となりますので、費用対効果は悪い印象になってしまうかもしれませんが、ポイントは「数TBクラスの容量で、かなりのパフォーマンスを欲しい方」向けのストレージとしてはかなりお安いモデルになると言うことです。中小規模のデータベースシステムでパフォーマンスチューニングに悩まれている方、そしてファイルサーバやVDI環境を分散して運用・管理されている方には非常に魅力的に見えるのではないでしょうか。

と言うことで、手元にSSDが20個ほどあったので実際にパフォーマンス検証をしてみましたので、以下にレポートします。

ネットワールド的検証レポート
まず、構成は以下の通りです。手元にある検証機材を使ったのであまり十分な機材ではありませんが、低コストシステムを具現化すると似たような構成になるのではないでしょうか。オプションとしてFCポートを追加しているのがスタンダードなVNXe3200オールフラッシュとは違う点に注意して下さい。※10GbiSCSIとほぼ同等と考えて頂いても大丈夫です。

Blog_3

パフォーマンス検証ツールとしては、IOmeterを利用しました。内容としてはVDIを想定して大きなブロックサイズの完全ランダムアクセスを行っています。書き込み/読み込みが50:50と言う比率なのもストレージとしては大きな負担になります。また、その他にもExchange相当のアクセスパターン、OLTP1を想定したアクセスパターン、Chad氏のサイトにあった公称スペックのアクセスパターン、そして最後に個人的に「凄いパフォーマンス値が見てみたい!」と言う欲求を満たすためのスモールブロック&シーケンシャルの読み込みのみのアクセスパターンも実験してみました。

Blog_4_2 

と、前置きはこれぐらいにして検証結果を発表します!

VNXe3200オールフラッシュパッケージの実力!

Blog_5 
ストレージのパフォーマンスサイジングに詳しい方であれば、ここから大凡のシステム規模感が分かると思いますが、具体的に仮想デスクトップ環境を例に挙げてみると、以下のような環境で利用できます。

Blog_6 
このシステムであれば、最大の懸念であるログインストームにおいても300人程度の同時ログインに耐えられるパフォーマンスを有していることになります。コストとこのシステム規模感からの印象は如何でしょうか?「お、これは使える!?」と思って頂けた方には、是非弊社担当者までご連絡をお願いします。担当者が分からない方は emc-info@networld.co.jp までご連絡下さい。

次のEMC関連記事はVNXe3200オールフラッシュパッケージと同様に、EMCworldで発表されたVirtual VNXについての記事になります。お楽しみに!

最前線より : 業界有数のテレコムプロバイダにおけるPernixData FVP ソフトウェア

本ブログエントリーはPernixData社の顧客であるJon Byrum氏がPernixData社のブログに寄せた記事の翻訳版です。 Jon Byrum氏について、詳しくはこちらのLinkedinもご参照ください。

本記事の原文はIn the Trenches: PernixData FVP Software at a Leading Telecommunications Providerで閲覧可能です。

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

編集者による注意事項: この投稿はPernixDataの顧客によるゲスト投稿シリーズの1つです。

我々のVMware環境は複数のテナントからなり、EMC社のVMAXストレージをバックエンドとしています。3つのクラスタに渡って550以上の仮想マシンがあり、それらの仮想マシンは程度の差はあるものの、ほとんどがリソースを多く利用するものです。ディスクリソースに対する高い負荷で、レイテンシの問題が出てくるようになってきました。そこで、我々はストレージ上の他のアプリケーションに影響が出ないようにパフォーマンスを上げる方法を模索し始めます。我々はSSDとして主流になってきたフラッシュをいくつかのホストに追加してみました。しかし、パフォーマンスは高い負荷がかかっていない時のFC SANと大体同じ程度でした。サーバサイドフラッシュをソフトウェアなしで追加しても効果はさほど出ないということが分かっただけでした。

我々はPernixData FVPソフトウェアを、まずはReadの高速化のためだけに使うところからはじめました。有効にした対象はほとんどの仮想マシンがSQLサーバを動作させているクラスタです。各ホストに搭載されていたSSD2本を再利用する形で割り当てしました。インストールは驚くほどあっさりと、簡単でした。本番環境で動き出すところまでに大体1日程度でした。にも関わらず、ストレージから取り除かれたトラフィックの総量は非常に感動的なものでした。このスクリーンショットは導入から大体1か月後に取得されたものです。15億回以上ものIOによる61TBのトラフィックがSANから取り除かれ、多くの負荷が減ったのです。ストレージを迫害していたものがなくなったという事実にスポットライトを当てる以外には、これがどんなに素晴らしいことなのかを伝えるための言葉が思いつきません。

Fig248

続きを読む »