« 2016年4月 | メイン | 2016年6月 »

2016年5月

2016/05/31

仮想環境をバッチリ管理!仮想化専用ストレージTintriとは

前回から、だいぶ時間が空いてしまいましたがTintri第2稿目です!

 

今回は、Tintriの基本機能についてご紹介したいと思います。

 

Tintriは「"仮想化専用ストレージ"です。」とご説明させていただきましたが、どういうことなのか見ていきましょう。

 

「IOPSがすごくて、仮想環境の可視化もすごくて、GUIがもうほんとにすごくてぇ、、、」は、前回ご紹介した部分ですが、今回は具体的に見ていきたいと思います!

 

まず、IOPSです。

一番下のモデルT820でも30000IOPS(R:W=5:5)の性能です。

T850というモデルだと50000IOPS、T880では80000IOPSとなります。

そもそも一般的なHDDではどのくらいのIOPS性能が出せるのか見てみましょう。

HDD1本辺りのIOPSはSATA、SASの差はありますが、おおよそ100~300くらいです。

ではなぜ、TintriはこれほどのIOPS性能を出せるのか?

それはTintriがSSD搭載のハイブリッドモデルであり、かつIOの99%以上をSSDから返すというTintriのインテリジェントな仕組みを持っているからです。

 

次に仮想環境の可視化についてですが…

まず、一般的なストレージを考えてみましょう。

一般的なストレージですと、管理の対象把握までVolumeLUNの単位になります。

つまり、下の図1のようなイメージになります。

 

1

(図1)

1つのVolumeやLUNの上で複数台の仮想マシンが稼動しストレージ側からは仮想マシン1台1台の状況が分からないということですね。

この状態で、特定の仮想マシンが突発的なIO要求を出したとすると、ストレージ側からはどの仮想マシンが問題を引き起こしているか特定が難しいです。

考えられる問題点は、ストレージ(Volume、LUN)のパフォーマンス低下、ネットワークの遅延、仮想マシン・ホストの問題の3点になりますが…

切り分け作業は、かなりの工数が必要となります。(うーん、困った。)

 

そのお悩み、Tintriで解決しませんか!?!?

Tintriは自分のVMwareとの相性が非常によく、自分のおなかの中にいる仮想マシンを把握しています。

(Tintriの開発エンジニアはもともとVMwareでESXの開発に携わっていたメンバーです。)

仕組みとしてはvCenterから情報を取ってきております。また、ネットワーク遅延についてもpingで遅延時間の確認を取っています。

 また、仮想マシンのパフォーマンスに何らかの不具合が発生したときには、瞬時に一次切り分けができることも魅力の1つです。

 

今回の記事では、特に”Latency ms”について確認してみましょう。

 

まず、図2をご確認ください。

これが、Tintriのダッシュボード画面となります。

 

2

(図2)

 

ダッシュボード画面で確認できるのは、Tintri全体としてのパフォーマンス情報(”IOPS”,”Throughput”,”Latency”,”Flash hit ratio”)と

Tintriのリソース使用状況(”Performance reserves”,”Physical space”)です。

 

ここでは、ある仮想マシンが重いことを想定してみましょう。

 

仮想マシンが重いことに気づいたユーザーが管理者に問い合わせをしてきます。

(仮想マシンが重いけどどうにかならない?)

そんな時には、図3の赤枠で囲った部分”Serch VM”をクリックしてください。

3

(図3)

そうすると、図4のようにTintriをデータストアとしている仮想マシンが一覧で表示されます。

4

(図4)

 

そして、お気づきかと思いますが”Latency ms”の所に棒グラフがありますね。

マウスオーバーしてみましょう。

すると…図5のように”Latency ms”の詳細情報が出てきます。

 

5

(図5)

 

少し見づらいので拡大してみると…

6

(図6) 

なるほど、”Latency ms”の中身について詳細な情報が見られるわけですね!

"Latency ms"の中身として"Host”,”Network”,”Storage”(“Contention”,”Flash”,”Disk”)が確認できます。

 

実際のトラブルに見舞われた時、この機能は非常に便利です。

簡単にご説明しますとStorage=TintriNetwork=ネットワークHost=仮想マシン・ホストということです。

Storage部分についてはさらに細かく、Contention,Flash,Diskについて確認できます。Contentionはひとまずおきましょう。

まず、FlashはSSD、DiskはHDDで発生している遅延になります。

そして、気になるContentionですが、こちらはリソースの競合によって発生する遅延となります。

仮想マシンが大量に稼動している際にTintriのSSDのバスがいっぱいになり渋滞が発生してしまいます。

これが、Contentionです。

SSD自体の応答遅延ではなく、SSDにたどり着くための道路が混んでいるために起こる遅延ということですね!!

 

実際には、まだまだTintriならではの嬉しい・美味しい・楽しい機能があるんですが…

本記事では一旦ここまでにしましょう。

 最後にお知らせです。

一刻も早くTintriについて知りたいという方は、

Tintri VMstore T800シリーズ体感セミナー ~噂の仮想化専用ストレージTintriをさわってみよう~

こちらのセミナーにお越しください。Tintriの実機に触って機能を堪能できます! 東京でのセミナー講師は本記事の筆者が担当しております。

また、東京で大好評だったVDI de ドリームナイトの大阪開催が決定しました!!!

果たして、TintriはVDIに耐えうるストレージなのでしょうか・・・(乞うご期待!)

 

【日中忙しいお客様のための夜セミナー】VDI de ドリームナイト!<Tintri編> in 大阪開催決定!!

~VDIガチ検証!仮想化専用ストレージの実力やいかに!?~

お申し込みURLはこちら↓<https://networld.smartseminar.jp/public/seminar/view/639>

記事担当者:山元

2016/05/30

仮想化ワークロードを知る : Read/Writeとアクセスパターン

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

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

本記事の原文はKnow Your Virtual Workloads: Reads/Writes and Access Patternsで閲覧可能です。

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

いいことに、この10年ぐらい、情報システム部は主にアップタイムを最大化するということに重きをおいてきました。ハードウェアの障害やソフトウェアのエラーに対して充分な耐性を持つようなインフラストラクチャをつくり上げるということです。計画的なメンテナンスは時々ある記念事業のようなものでした。しかし、仮想化やアプリケーションの耐障害性の改善によって、堅牢なインフラストラクチャをつくり上げるということは今日では比較的に簡単になってきています。結果として情報システム部の仕事はその代わりに最適化へとシフトしてきています。作り上げたインフラストラクチャを高速で、運用効率よく、またコスト効率もよくするためにはどうしたらよいでしょうか?

データセンタインフラストラクチャは変化のないものの集合に過ぎません。アプリケーションとワークロードが命を吹き込み、こうしたワークロードがどのように上手く動くか、ということを決めるのです。残念なことにこうしたワークロードは想像通りに動くということはありえません。設計通りにはいかないのです。全てのデータセンタで、様々なワークロードが混在し、どのようなアーキテクチャを採用しているかにかかわらず、インフラストラクチャへと影響を与えます。新しいワークロードを動作させ始めることは近年のデータセンタにおいては全く問題になりません。しかし、ここに問題が有ります。新しいワークロードはデータセンタ、そして既存のワークロードにどのような影響をあたえるのか、ということを予測することは難しいのです。

データセンタを適切に設計するためには、様々なワークロードの特性、そして、それがどのように変化していくのか、それがどのようにアプリケーションのパフォーマンスに影響をおよぼすのかを理解しておく必要があります。このブログはこの問題の解決を手助けするシリーズの最初の記事になり、仮想化されたワークロードについて知っておくべき最初の6つのことをお伝えしていきます。これらを理解することで、アプリケーションのパフォーマンスをコスト効率よく最適化しながら、仮想化データセンタのサービスも効率化することが出来るのです。

#1 ReadとWriteは振る舞いが異なる

殆どの人は仮想化データセンタ、特にストレージインフラストラクチャにおいては、ReadとWriteの振る舞いが異なっていることに気がついているでしょう。ですが、この詳細な振る舞いについてはしばしば見落とされています。それどころか、多くの会社はこれらの違いを計測する適切なツールすら持ち合わせていないという状態です。適切に計測ができなければ影響を考慮することも出来ないのです。逆もまた、しかりです。ストレージはフラッシュに向かって動いていますが、Read/Writeの振る舞いはこれまで以上に重要になってきます。

共有ストレージシステムにおいて、WriteはReadよりも難しい処理です。これはストレージシステムがデータ保護のために追加のアクティビティを実施しないといけないためです。「ペナルティ」がデータ保護の追加アクティビティという形でチャージされるのです。RAID 1ストライプを例に取ると、Writeが仮想マシンから発行される度に2回のI/Oが発生します。RAID 5では4つのI/O、RAID 6では6つのI/Oが発生します。これはストレージのパフォーマンスに大きな影響を与えます。しかし、違いはこれだけではありません。

ゲストオペレーティングシステムではしばしば仮想マシン内でバッファキャッシュを利用するファイルシステムを利用しているケースが有ります。これによってWriteを発行する際に大きなブロックサイズが生成される場合があります。ブロックサイズが大きいということはWriteデータではReadのI/Oよりもより多くのデータが取り扱われるということになります。これはインフラストラクチャ全体にわたって影響を与えることがあるということになります。特にこれはフラッシュストレージにおいては重要です。Readはフラッシュにとって比較的扱いやすいものですが、大きなI/OサイズでのWriteは殆どの場合に見てわかるほどのパフォーマンスの劣化を伴うからです。--これはディスクベースのストレージよりも更に悪いということもありえます。ストレージの要件に基づいて新しい高速なメディアへ移行した人にとってはこれは大きな驚きでしょう。

Read/Writeの振る舞いについて必要なだけの情報を把握するにはどうしたら良いのでしょうか?残念なことに既存のツールはこうした点をカバーできていません。理由は以下のとおりです :

  • 既存のツールはRead/Writeの割合を計算する際に、Readコマンドの発行数とWriteコマンドの発行数を数えています。しかし、上で述べたように、Write I/OはReadのI/Oよりもおおきくなることがしばしばです。ですから、Read/Writeの割合が50/50であるということは現実には正しくなく、実際に転送されているデータは30/70であったり、20/80であったりするのです。Read/Writeの振る舞いを見ていると、実際のデータ量の観点からは大きく異なってしまうのです。
  • 割合はもちろん知っておいて損はないものですが、これはパーセンテージの形で一定の期間をまとめたものです。本来知っておかなくてはならないものは時系列でのReadとWriteの分布であり、そして、その(Read操作とWrite操作の)ワークロードに紐付いた絶対数です。これはパフォーマンスの問題を理解するためには必須の項目です。

よく出来る管理者足るためには、Read/Writeの割合を把握しておくだけでなく、個々の仮想マシンと、そしてデータセンタ全体でこうしたReadとWriteがどのように分布して発生しているのかを知っておかなければなりません。これはRead/Writeのデータを単にI/Oのコマンドとしてだけでなく、どれだけの転送量が実際に行われているか、そしてそれぞれのアクティビティのレイテンシはどの程度なのかということも含まれます。

#2: アクセスパターンはパフォーマンスにも影響する

ワークロードのストレージへのアクセスパターンは仮想マシンの振る舞いや、それによって構成されるサービスの振る舞いに影響を与えるだけでなく、そのインフラストラクチャで動作している他のすべてのワークロードにも影響を与えます。これは「ノイジーネイバー(やかましいご近所さん)」効果で、上手く動作している環境内の他の仮想マシンに悪影響をおよぼすのです。

すでにReadとWriteがストレージインフラストラクチャに対して異なる影響をおよぼすことは述べてきましたが、それらが織りなすアクセスのパターンも同様に重要です。シーケンシャルアクセスとランダムアクセスパターンはストレージインフラストラクチャに大きく影響を与えるI/Oです。これらの特性はこれまでは回転するディスクの機械的なレイテンシにのみひも付けがなされてきました。しかし、これはフラッシュにも同様に言えることなのです。環境内に単一のシーケンシャルなワークロードだけがある場合、劇的に混雑が発生し、あっという間にうめつくされ、他のワークロードのためのキャッシュの廃棄が発生します。シーケンシャルワークロードは大抵は大きなブロックサイズで利用されるため、ストレージインフラストラクチャのパフォーマンスに異常をきたすのです。

環境におけるアクセスパターンを理解せず、そして、それに順応することがなければ、パフォーマンスは貧弱なものとなり、環境内で一様なパフォーマンスを得ることが出来ません。これはどのようなストレージアーキテクチャを利用していたとしても言えることです。従来型のSANインフラストラクチャ、もしくはハイパーコンバージド環境で利用される分散ストレージソリューションであっても、問題は残されているのです。

本シリーズの次の投稿をお待ち下さい、そこでは皆さんが見落としがちな仮想マシンの特性についてお話しようと思います。

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

2016/05/23

NetApp 7toC 移行サービス始めました!移行編

皆様こんにちわ

世間では花見のシーズンも終わり、ゴールデンウィークの話で持ちきりですね。

大型連休の後はもちろん、7toCの季節ですね。

という事で、引き続き7toCについて記事にしていきたいと思います。

前回はアセスメント編という事で、今お使いの7-ModeがcDOTに移行できるかどうか??という移行の前段階のお話を記事にしてみました。

今回は実際の7-ModeからcDOTへの移行手順を見ていきましょう!

こちらの記事は64bit環境想定ですのでご注意ください。

32bitからの移行も今後記載したいと思います。

では、早速データ移行の準備をしていきます。

まず初めに必要なもの・・・

そう!SnapMirrorライセンスです。

この記事を見た半分くらいの方から

「持ってないんですけど・・・」

という心の声が聞こえてきた気がします・・・(笑)

大丈夫です。安心してください。ありますよ?

【移行用途で使用する目的であればSnapMirrorライセンスは無償で貸し出し可能です!!】

ですので、SnapMirrorライセンスがないから7toCは無理だなー・・・とお考えの方々も諦めずcDOTをじゃんじゃん売ってください。

こちらのライセンスは別途申請が必要になりますので、お近くの販社様、営業さんにお問合せください。

ライセンスキーをGetしましたら、まずは7-Modeから準備を行います。

7-ModeにCLIでログインしてください。

①7-ModeでSnapMirrorライセンスを有効にします。

>license add <ライセンスキー>

②7-ModeでSnapMirrorを有効にします。

>options snapmirror.enable on

③SnapMirrorのアクセス許可設定を行います。

>options snapmirror.access <cDOT側のInterClusterLIFのすべてのIP>

※細かい事を気にしない場合は【all】や【*】でも可能です。

④移行対象のVolumeのオプションを変更します。

>vol options <Volume名> no_i2p off

>vol options <Volume名> read_realloc off

>vol options <Volume名> nvfail off

恐らくあまり見慣れないvol optionsだと思いますが、基本はすべてデフォルトは【off】

になっております。もしこちらのoptionsを変更しているシステムはご注意ください。

それぞれのvol optionsの意味は以下になります。(マニュアル抜粋)

------------------------------------------------------------------------------------------

no_i2p on | off
このオプションをonにすると、inodeはボリューム上でパスネーム変換を行うことができなくなります。
デフォルト値はoffです。

-----------------------------------------------------------------------------------------

read_realloc on | space_optimized | off
このオプションをonまたはspace_optimizedにすると、ボリュームの読み取りの再配置が有効になります。

結果、一部のブロックをディスク上の新しい場所に書き込むことによって、ファイル・レイアウトが最適化されます。レイアウトが更新されるのは、ユーザの読み取り処理によって該当ブロックが読み取られた場合のみです。また、レイアウトを更新することによって将来的に読み取りのパフォーマンスが向上する場合以外は更新されません。

読み取りの再配置は、ランダムな書き込みと大量の連続読み取りが混在するワークロードで有効活用できます。このオプションをspace_optimizedに設定すると、再配置の更新で、Snapshotブロックがアクティブ・ファイルシステムに複製されないため、スペースの利用率を抑えることができます。

ボリュームにSnapshotが存在するか、ボリュームがSnapMirrorの送信元であるとき、フレキシブルボリューム用のストレージを減らし、次回の更新時にSnapMirrorによって移動されるデータの量を減らせる場合は、space_optimizedを使用すると効果的です。space_optimized値を使用すると、Snapshotの読み取りパフォーマンスが低下する可能性があります。通常は、フレキシブルボリュームでのみ使用されます。デフォルト値はoffです。この場合、読み取りの再配置は使用されません。

-----------------------------------------------------------------------------------------

nvfail on | off
このオプションをonにすると、ファイラーはブート時に追加のステータス検査を実行し、NVRAMが有効な状態にあるかを確認します。このオプションは、データベース・ファイルを保存する場合に便利です。ファイラーが何らかの問題を検出すると、データベース・インスタンスはハングアップするか、シャットダウンされます。さらに、コンソールにエラー・メッセージを送信し、データベースの状態を確認するよう警告します。デフォルト値はoffです。

-----------------------------------------------------------------------------------------

以上で7-Modeでの準備は完了になります。

簡単ですね!!

では、引き続きcDOTの移行準備を行いましょう!

cDOT側にCLIでログインしてください。

cDOT買ったはいいけどよくわからなくて・・・という方も安心してください!

ネットワールドではcDOTの構築動画を配信しております!!

clustered Data ONTAPとは?から初期設定方法やSVM、Volumeの作成方法等も解説されておりますので、是非こちらもチェックしてみてください。

http://www.networld.co.jp/product/netapp/movie/cdot/

Cdot

①InterClusterLIFを作成します。

※もし作成済みの場合はこちらの手順はスキップしてください。

※InterClusterLIFは各Node(コントローラ)に最低一つ必要になります。

>network interface create -vserver <クラスタ名> -lif <InterClusterLIF名> -home-node <node名> -home-port <ポート名> -address <IPアドレス> -netmask <ネットマスク>

コマンド例:

>network interface create -vserver FAS-Cluster -lif intercluster_lif1 -home-node FAS-Cluster-01 -home-port e0d -address 192.168.1.1 -netmask 255.255.255.0

上記コマンドでは【FAS-Cluster】というクラスタの【FAS-Cluster-01】というnodeの【e0d】ポートに対してInterClusterLIFを作成しております。

InterClusterLIFは各nodeに必要ですので、もしお使いのcDOTが2node-Switchless等の場合は、もう片側のnodeにもInterClusterLIFを作成してください。

②作成したInterClusterLIFより7-Modeに疎通可能か確認します。

>network ping -lif <InterClusterLIF名> -vserver <クラスタ名> -destination <7-modeのIPアドレス>

③次に移行先となるVolumeを作成します。

>volume create -vserver <移行先のSVM名> -volume <移行先となる新規Volume名> -aggregate <アグリゲート名> -size <Volumeのサイズ> -state online -type DP

コマンド例:

>volume create -vserver svm-cifs -volume vol_cifs -aggregate aggr1_n1 -size 2t -state online -type DP

ここでのポイントは-typeをDPにすることです。

cDOT間でのSnapMirrorでもdestination VolumeはDPで作成しますが、7toCの場合も同様にDPで作成します。

ここでもしRWで作成してしますと後々のSnapMirror設定で失敗しますのでご注意ください!

④7-Modeとの移行ピア関係の作成をします。

>vserver peer transition create -local-vserver <移行先のSVM名> -src-filer-name <7-Modeのホスト名またはIPアドレス> -local-lifs <InterClusterLIF名>

コマンド例:

>vserver peer transition create -local-vserver svm-cifs -src-filer-name 192.168.1.100 -local-lifs intercluster_lif1,intercluster_lif2


ここでのポイントは通常のvserver peerを作成するコマンドではなく、【vserver peer transition】コマンドを用いる事と、-local-lifsに指定するInterClusterLIFをカンマ区切りですべて入力する点になります。

⑤移行ピア関係が作成されたか確認をします。

>vserver peer transition show

問題なければ以下のように出力されます。

FAS2240A::> vserver peer transition show
Vserver  Source Filer  Multi Path Address Local LIFs
-------  ------------  -----------------  ---------------
svm-cifs  192.168.1.100   -                 intercluster_lif1, intercluster_lif2

ここまでの手順が前準備になります。

ここからはデータ移行手順になります。まさに【7toC】を行います。

7-ModeのデータがcDOTへ移行される奇跡の一瞬を目の当たりにします。

皆様準備はOKでしょうか?

では行きましょう!!Let's 7 to C~!!

①cDOTからSnapMirror関係を作成します。

>snapmirror create -souce-path <7-Modeのホスト名もしくはIPアドレス>:<7-Modeの移行対象のVolume名> -destination-path <移行先のSVM名>:<移行先となるVolume名> -type TDP

コマンド例:

>snapmirror create -souce-path 192.168.1.100:vol_cifs_7 -destination-path svm-cifs:vol_cifs -type TDP

ポイントは-typeが【TDP】になる事です。

通常のcDOT間でのSnapMirrorですと、こちらはDPになるかと思いますが、7-Modeからの移行時はTDPになるのでご注意ください。

②SnapMirror初期転送の開始

>snapmirror initialize -destination-path <移行先のSVM名>:<移行先となるVolume名>

コマンド例:

>snapmirror initialize -destination-path svm-cifs:vol_cifs

※こちらのコマンドを実行しますと、SnapMirrorの初期転送が開始されます。

7-ModeではReadが、cDOTではWriteが増えますので、業務に影響がない時間帯に実行する事をお勧め致します。

③SnapMirrorのステータスを確認します。

>snapmirror show

>snapmirror show -instance

>snapmirror show-histoly

cDOTではコマンドオプションで【-instance】を付けることでより詳細な情報を表示できます。

転送中は以下のような出力になります。

FAS2240A::> snapmirror show
                                                                                                             Progress
Source                      Destination      Mirror      Relationship    Total                  Last
Path                 Type    Path              State       Status          Progress  Healthy  Updated
-----------          ----  ------------      -------      --------------   --------- -------   --------
192.168.1.100:vol_cifs_7 TDP  svm-cifs:vol_cifs    Snapmirrored Transferring  0B     true        04/27 13:22:18

転送が完了しますと以下のような出力に。

FAS2240A::> snapmirror show
                                                                                                             Progress
Source                      Destination      Mirror      Relationship    Total                  Last
Path                 Type    Path              State       Status          Progress  Healthy  Updated
-----------          ----  ------------      -------      --------------   --------- -------   --------
192.168.1.100:vol_cifs_7 TDP  svm-cifs:vol_cifs    Snapmirrored Idle  -     true        -

④SnapMirrorの差分転送を実施

ほとんどの環境において、初期転送は負荷の少ない休日に、差分転送は平日夜間に行いたい等のご要望があるかと思います。

cDOT側でSnapMirror転送のスケジュールを設定するか、以下のコマンドにて手動で差分転送を実施してください。

>snapmirror update -destination-path <移行先のSVM名>:<移行先となるVolume名>

コマンド例:

>snapmirror update -destination-path svm-cifs:vol_cifs

カットオーバー前の最終差分転送も上記コマンドで実施してください。

⑤SnapMirror関係の解除

>snapmirror break -destination-path <移行先のSVM名>:<移行先となるVolume名>

コマンド例:

>snapmirror break -destination-path svm-cifs:vol_cifs

※このBreak状態であれば再同期も可能です。

Break状態にすることでDestination VolumeがR/W可能な状態になります。

ここまで来たらあとは簡単ですね。

CIFSで共有するなりNFSでexportして、Volumeの中身のファイルを確認します。

⑥すべての移行が完了後、SnapMirror関係を削除します。

※cDOT側で入力

>snapmirror delete -destination-path <移行先のSVM名>:<移行先となるVolume名>

※7-Mode側で入力

>snapmirror release <7-Modeの移行対象のVolume名> <移行先のSVM名>:<移行先となるVolume名>

コマンド例:

>snapmirror release vol_cifs_7 svm-cifs:vol_cifs

⑦最後にvserver peer transitionを削除します。

>vserver peer transition delete -local-vserver <移行先のSVM名> -src-filer-name <7-Modeのホスト名またはIPアドレス> -local-lifs <InterClusterLIF名>

コマンド例:

>vserver peer transition delete -local-vserver svm-cifs -src-filer-name 192.168.1.100 -local-lifs intercluster_lif1,intercluster_lif2

以上、     完   了 !

今回はコマンドばかりで難しい印象を持たれた方もいらっしゃるかと思いますが、実際にやってみますと非常に簡単です。

移行時間を除けばオペレーションで1時間かからない程かと思います。

ただやはり既存の7-Modeの状況や、cDOTの設計構築にかかわる部分もありますので、

「どこかまるっと実施してくれるベンダーはないかなー・・・」

と、お考えの方は是非!ネットワールドにお声がけください!

ネットワールドでは7-Mode/cDOTの設計、構築、支援、7toCでのデータ移行もすべて行うサービスもご提供しております!!

ご要望ある方は是非、弊社営業担当もしくは下記URLよりご連絡頂けますと幸いです。

【NetApp製品問い合わせ先】

分析:ストレージ用語の誤解の戦争に透明性を

本ブログエントリーはPernixData社のVP MarketingであるJeff Aaron氏のブログ記事を翻訳しています。 

本記事の原文はAnalytics: Bringing Clarity to the Confusing War of Storage Wordsで閲覧可能です。

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

ストレージの業界はこれまでにないほどまでに盛り上がっています。新しいアプリケーションや新しいメディアなどのすべてが、天文学的なまでのデータ量の増大を引き起こしています。これまでにないほどまでにストレージは戦略的でなくてはなりません。

しかし、ストレージはこれまでにないほどまでに誤解を引き起こしています。

従来型のSAN/NASアーキテクチャはこの傾向の変化に追従ができなくなりました。例えば、仮想化は一般的なストレージをアプリケーションのパフォーマンス不足、割にあわないコストという面から、文字通り破壊してしまいました。

あらゆるプレイヤーがこの困難に最も適切に対処するための方法を知っているように見えます。サーバサイドストレージ高速化、オールフラッシュストレージ(AFA)、そしてハイパーコンバージドプラットフォームがその主たる対処法です。

Fig400

しかし、実際問題として、あらゆる会社組織はことなっています。そして、たとえ、同じ会社の中であったとしても、異なるアプリケーション要求があり、そのために複数のストレージソリューションが必要になってくるのです。

その中で共通していることが一つあります。何がそれを引き起こしているのかということをよく知り、それがどのように変化していっているのかを掴んでおかなければ、そのデータセンターの問題を解決することは出来ないということです。

これが「分析ドリブンのストレージ」という新しい時代の幕開けにつながります。

分析 : 縛りを行う紐付き

既存の仮想マシンの管理ツールは詳細なストレージのデータを持ち合わせていません。同様に、既存のストレージ管理ツールも適切なアプリケーションの可視性を欠いており、また、特定のストレージソリューションに紐付いています。(例えばそのハードウェアを作っているストレージベンダーに紐付いています)

これが今日のデータセンターに巨大な断崖(キャズム)を生み出しています。包括的な分析ができないので、ストレージの設計、展開、最適化、そして管理を効率的に行うことは非常に難しい物になります。

これに対する最初のステップはサーバ内にストレージのインテリジェンスを入れることです。ここは正確な仮想マシンのデータを収集し、それをあらゆるストレージプラットフォームからの情報と結合させるには最高の場所です。この概念はインフラストラクチャ分析と呼ばれています。

ここを利用することで刻々と変化するワークロードを正確にそして、継続的に把握することが出来るようになり、仮想マシンとストレージの詳細な振る舞いを可視化してみることで、インテリジェントな設計と管理の判断ができるようになります。例を挙げると、Read/Writeの比率、データのアクセスパターン、ブロックサイズ、データと特定のストレージプラットフォームの能力など、刻々と変わり続ける詳細を把握することができるようになるのです。

このような知見を持つことで、確信を持ってあなたの環境にとって適切なストレージアーキテクチャ(と製品)を選択することが出来ます。ストレージの購入を検討している際に、高価なオーバープロビジョニングのためのコストを避けることも可能です。さらに、ストレージソリューションの構成を最適化し、アプリケーションのパフォーマンスを最大化することも可能です。

加えて、これは「やっておしまい」ではないということを付け加えさせてください。ワークロードは常に変化していきます。設計における判断も現在や将来の要件を反映して繰り返し行われることになります。適切なツールを利用し、環境の成長につれて常に分析、最適化を行うことが出来るのです。

ストレージと仮想マシンの環境にこれまでにない可視性をもたらすことがすべての始まりです。そこから、ストレージを最適化し、ビジネスのニーズと将来の要件の成長予測に見合うだけのコストの最適化が行えるのです。

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

2016/05/20

SQLサーバ2005のEOLを黄金に変えるための3つのヒント

本ブログエントリーはPernixData社のSheldon D'Paiva氏のブログ記事を翻訳しています。 

本記事の原文はThree Tips for Turning SQL Server 2005 EOL into GOLDで閲覧可能です。

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

SQLサーバ2005を動作させている環境にとって、時間はもう残されていません。Microsoft社はSQLサーバ2005を2016年の4月12日までしかサポートしないとしています。しかし、多くの会社組織はビジネスを中断させないためにこのアップグレードを遅らせてきました。IDCによると、数ヶ月前の調査で、800,000ものサーバがまだSQLサーバ2005を動作させているという見積もりを出しています。

サポートされないSQLサーバのヴァージョンを使い続けるという選択肢はありません。ビジネスを中断するということは大変に苦痛を伴うものですが、一方で近年のインフラストラクチャのイノベーションを活用し、古ぼけた環境から黄金の環境へと移行するチャンスでもあるのです。運用を簡素化し、コストを低減、そしてビジネスにとって意味のある変革を提供することが出来るのです。

いかに、SQLサーバの更新に際して行うべき3つのことをご紹介します :

  1. データベースの仮想化 : 最も要件の高いデータベースだとしてもその一部は、今では仮想化することが可能です。仮想化による俊敏性を得ながら、ハードウェアとソフトウェアライセンスの両方のコストを統合によって削減することができるのです。
  2. パフォーマンスのブースト : フラッシュは素晴らしいパフォーマンスをもたらします。特にデータベースにとっては、プロセッサの直ぐ側に配置することが出来るという点でサーバ内に配置するのが最も効果的です。しかし、フラッシュは大きなブロックサイズでのWriteには向いていません。そこでRAM(メモリ)の登場です。PernixData FVPを利用すれば、フラッシュとメモリの両方でハイパフォーマンスのメディアをプール化して、サーバに搭載することが可能です。インメモリコンピューティングのパフォーマンスをアプリケーションの書き換えることなく手に入れることが可能です。
  3. インテリジェンスの組み込み : データベースの構成はそれぞれ毎に異なります。インフラストラクチャのスタック全体に渡るエンドツーエンドの可視化によって、適切にデータセンタを設計し、運用を最適化し、コストを最小化することが可能です。PernixData Architectでは、情報を提示してくれる協力なダッシュボードだけではなく、ハイパフォーマンスなデータベースインフラストラクチャのために何を用意し、運用していくべきなのかを知ることも出来るようになります。

もっと詳しく知りたいですか? 4月21日のWebセミナーに登録してください。(訳注:日本語でのWebセミナーは5月26日です。) SQLサーバのMVPであるDavid Klee氏とBala Narasimhan氏がSQLサーバのアップグレードの問題についてナビゲートします。(日本語版ではPernixData社の最新情報についてもお知らせします。)

参考文献 :

Website: SQL Server Solutions Page(英語)

Whitepaper: SQL Server License Reduction with PernixData FVP Software(英語/ブログで今後翻訳予定)

Whitepaper: PernixData Architect for Microsoft SQL Server(英語)

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

2016/05/09

CommVault Simpana:番外 クライアントPCのバックアップ パッケージカスタマイズ(Mac OS)編

前回、クライアントPCのバックアップのバイナリ収集のところまで実施しました。
今回は、そのバイナリのカスタマイズの実施です。
共通のインストール・バイナリを作成して簡易なインストールを目指します。

WindowsPCは、サーバ系と大きく変わらないので、本編ではMac OSを対象としたカスタマイズを行います。


①バイナリ:CVDownloads.tarをMac OS環境にコピーして、tarファイルを展開します。

Simapanacustom01


②展開したフォルダ:CVDownloads内に、Simpana.appが存在するので、こちらをダブルクリックします。 赤枠内を選択してクリックしていきます。

Simapanacustom02red


③次に、Licenseに関する同意に応じ、パッケージを選択します。

Simapanacustom03red


④次に、クライアントOSで、Firewallを使用している環境があればチェックを入れます。 CommServeのサーバ名を入力します。

Simapanacustom04red


⑤先に進めて、Configuration画面で、予め設定しておいた、Client Group、SubClient Policy、StoragePolicyを入力して、Createボタンを押します。

Simapanacustom05red


⑥カスタムパッケージを生成している画面が続き、MacOS用のDMGファイルが作成されます。

Simapanacustom06


⑦その後、インストーラ画面が表示されるのでクローズして、完了を待ちます。 [Done]ボタンを押して終了です。

Simapanacustom07red

"Welcome to Simpana"の左の画面は、作成したパッケージのインストール画面で、この場ではインストールしないのでクローズします。


⑧デスクトップ上に、以下のSimapana.dmgファイルが存在するのを確認します。

Macoscustom13_2


これでクライアントPCへ配布できるパッケージが完成しました。

今回はここまで、次回いよいよインストール編です。


Edit by :バックアップ製品担当 松村・安田

CommVault Simpana:番外
クライアントPCのバックアップ バイナリ作成編
パッケージカスタマイズ(Mac OS)編
インストール(Mac OS)編



【過去の記事】

メーカのサイト:
Simpana早わかり講座

導入編:
【連載】第1回 始めてみよう!CommVault Simpana インストール編
【連載】第2回 始めてみよう!CommVault Simpana インストール後の作業とバックアップ編
【連載】第3回 始めてみよう!CommVault Simpana VMwareバックアップ編
【連載】第4回 始めてみよう!CommVault Simpana VMwareバックアップ応用編(1)
【連載】第5回 始めてみよう!CommVault Simpana VMwareバックアップ応用編(2)とリストア
【連載】第6回 始めてみよう!CommVault Simpana データアーカイブ機能を活用してみませんか?

製品紹介編:
第一回、最新!データ統合管理ソリューション CommVault Simpana のご紹介!
第二回、データ統合管理ソリューションCommVault Simpana 基本構成
第三回、データ統合管理ソリューションCommVault Simpana Backup
第四回、データ統合管理ソリューションCommVault Simpana Deduplication
第五回、データ統合管理ソリューションCommVault Simpana SnapShot Management
第六回、データ統合管理ソリューションCommVault Simpana Virtualization 

Tips編:
【CommVault】次期バージョン v11の国内提供が始まりました! 
【CommVault】管理コンソールの言語表示の切り替えってできるの?

2016/05/03

★Unity&Unity VSAリリース★

皆さんこんにちは!

とりあえず検証してみた!シリーズ」のニュータイプ 渡会です。

現在私はEMC World 2016 In Las Vegasにきています!

そして!アメリカ時間201652日!

日本時間53日(おそらく)についに待ちに待った

Unity

001

002

003

がリリースされました!!!パチパチパチパチパチパチパチパチ

Unityは!

UnityとはVNX(色々出来るけど複雑)とVNXe(簡単だけど機能制限有り)といった2種類のストレージのいいとこ取りをした製品となっています。

Unityのコンセプトはずばり!

              ・シンプル

              ・モダン

              ・柔軟

              ・安価

4コンセプト製品となります。

Unityは現在のVNXe3200/VNX5200VNX5800までのパフォーマンスレンジをカバーしています。

しかし値段はハイブリッドの最小構成で10000ドル前後から購入可能となりそうです。

これだけ安価にもかかわらずハイパフォーマンスを提供できるすばらしいストレージがリリースされました!

※詳細な価格に関しては「emc-info@networld.co.jp」まで!

 

そしてUnityには同時に

Unity Virtual Storage AplianceUnity VSA

がリリースされました。

 

Unity VSAとは!

Unity Virtual Storage Aplianceのことでこの製品はESXサーバ上で稼動するUnityとなっています。

EMCさんは昨今ストレージをどんどんSoftware-Defined-Storage(SDS)化をしておりついにミッドレンジストレージも仮想化されました!!

(以前にIsilonVirtual Editionも記載しているのでよければぜひお読みください)

URLhttp://blogs.networld.co.jp/main/2016/02/isilonsd-edge-04df.html

 

さてインストール前にUnity VSAの機能紹介を行います。

まずはUnityUnity VSAの機能比較を以下表にまとめます。

 

機能

UnityVSA

Unity Hardware

SMB

NFS

iSCSI

FAST VP

Sasynchronous Unified Replication
(SAN/NASReplication

Unisphere HTML 5 GUI +REST API

Quality of Service(QoS)

Monitoring & Reporting

Thin Provisioning

VVols

FAST Cache

×

Data at Rest Encryption

×

Fibre Channel

×

Synchronous Replication
(SAN Only)

×

 

こちらの表を見ていただいてもわかるとおり物理版・仮想版との差はあまりありません。

そのためこのUnity VSAは今までストレージを置くには小さいかなと思われていた各支店・拠点等に導入しさらに本社・各拠点で相互Replicationを実施しお互いのバックアップデータを持ち合うといった構成も可能となりメリットが出ると感じています。

また機能に差異が無いので機能検証・実環境へのテスト導入に需要が出そうです

 

では次にUnity VSAの制限値を見たいと思います。

 

Unity VSA
(Based on Max License)

vDisk最大使用数

16

vDisk最大容量

50 TB

NAS Server最大作成数

16

ファイルシステム最大サイズ

50 TB

ファイルシステム最大作成数

32

Pool LUN最大作成数

64

スナップショット最大作成数

128

201653日時点

 

またこのUnity VSAに関しては3つのライセンス体系があります。

1.    Community Edition(無償)

2.    Professional Edition(有償)

3.    VVols Edition(有償)

各ライセンスの違いに関しては以下に記載します。

 

Community

Professional

VVols

機能

ALL

VVols Only

ライセンス

Free
(Unlimited)

Subscription

RPQ for VNX2

使用可能容量

4 TB

10/25/50 TB

50 TB

ノード

Single

サポート

Community

EMC(Enhanced)

用途

Non-Production

Production

次にUnity VSAをインストールするための機器仕様を以下に記載します。

ESXサーバ要件

要件

CPU

Xeon E5 Series Dual Core CPU 64-bit x86 Intel 2 GHz+

(or equivalent)

OS

VMware ESXi 5.5(Minimum)

(VMware ESXi6.0 Recommended)

メモリ

Minimum16 GB(ESXi5.5)/Minimum 18 GB(ESXi6.0)

ネットワーク

4×1GbE/4×10GbE(Recommended)

RAIDコントローラ

RAID card 512 MB NV cache, battery backed

(recommended)

Unity VSAの仮想マシン要件を以下に記載します。

仮想マシン要件

要件

vCPUs

2(2GHz+)

メモリ

12 GB

Virtual Network(vNICs)

Management1GbE×1
Data
1GbE×4 or 10GbE×4

System×1

Support Protocols

iSCSI/NFS/CIFS

ここまで各種仕様等を記載しましたがここから実際にインストール手順を記載していきます!

 

Unity VSAのデプロイ★

1       以下URLよりUnity VSAをダウンロードします。

https://www.emc.com/auth/unityvsasoftwaredownload.htm

2       vCenter ServerWeb Client or vSphere Clientでアクセスします。

004

3       vCenterメニューより「OVFテンプレートのデプロイ」を実行します。

005

4       OVFテンプレートのデプロイ」ウィザードが起動するので以下手順に沿って設定を行います。

006

4.1      ソースの選択

ローカルファイルにチェックを入れ参照ボタンをクリックします。

007

[ファイルを開く]画面が表示されるのでダウンロードしたOVAファイルを選択し「開く(O)」ボタンをクリックします。

008

[ソースの選択]画面に戻るので「次へ」ボタンをクリックします。

009

4.2      詳細の確認

セキュリティリスクに関する警告が表示された場合は「追加の構成オプションの承諾」にチェックを入れ「次へ」ボタンをクリックします。

010

4.3      名前およびフォルダの選択

[フォルダまたはデータセンタの選択]欄より仮想マシンを作成するデータセンタまたはフォルダを選択し[名前:]欄に仮想マシン名を入力し「次へ」ボタンをクリックします。

011

4.4      リソースの選択

デプロイされたテンプレートを実行するクラスタ・ホスト・vAppいずれかを選択し「次へ」ボタンをクリックします。

012

4.5      ストレージの選択

Unity VSAを格納するデータストアを選択します。

Unity VSAOS部分を格納するデータストアの選択となります。

※ここで選択するデータストアと実際にデータが格納されるデータストアは分けることが推奨されます。

013

[仮想ディスクフォーマットの選択:]欄より「シックプロビジョニング(Eager Zeroed)」を選択し「次へ」ボタンをクリックします。

※仮想ディスクフォーマットはシックプロビジョニング(Eager Zeroed)が推奨されます。

014

4.6      ネットワークのセットアップ

管理ネットワークとデータネットワークに使用する仮想スイッチを選択し「次へ」ボタンをクリックします。

015

4.7      テンプレートのカスタマイズ

[System Name]Unity VSAに設定するシステム名(ホスト名)を入力します。

016

IPv4 or IPv5を展開しUnity VSAに設定する管理IP情報を入力し「次へ」ボタンをクリックします。

017_2

4.8      終了準備の完了

設定内容の確認をし「デプロイ後にパワーオン」にチェックをし「終了」ボタンをクリックします。

018

5       Web Clientに戻りデプロイが開始されます。

019_2

6       デプロイ完了後自動でUnity VSAが起動するのでコンソールを開き起動完了まで待ちます。

※起動完了後は以下のようにLoginプロンプトが表示されます。

※起動完了まで30分程度かかる場合があります。

020_2

7       以下IDPWでログインします。

IDservice

PWservice

023_2

8       正常にデプロイできたことを確認するため以下コマンドを実行します

svc_diag

9       以下のように「failure」が出力されなければ正常にデプロイ完了です。

024_2

10    データ用ディスクを追加するためUnity VSAを選択し右クリックします。

025_2

11    メニューが表示されるので「設定の編集」をクリックします。

026_2

12    [設定の編集]画面が表示されるので以下手順に従ってディスクを追加します。

027_2

12.1    [新規デバイス]プルダウンメニュより「新規ハードディスク」をクリックします。

028_2

12.2    新規ハードディスクが選択されたことを確認し「追加」ボタンをクリックします。

029_2

12.3    新規ハードディスクが追加されるので展開します。

030_2

12.4    ハードディスクの各項目が表示されるので以下入力し「OK」ボタンをクリックします。

    容量:ディスクとして使用する容量を入力

    場所:使用するデータストアを指定

    ディスクプロビジョニング:シックプロビジョニング(Eager Zeroed

031_2

13    Web Clientに戻り仮想マシンの再構成が開始されるので再構成が完了した時点でデプロイの完了となります。

032_2

以上でUnity VSAのデプロイが完了です!

なんとも簡単に構築できてしまいました。この後はVNXeUnityの構築と同じくUnisphereにアクセスし初回起動ウィザードから構築を行っていきます。

 

今回はUnity VSAのデプロイまでとしたいと思います。

 

次回はUnityUnity VSAで搭載されている目玉機能である以下機能に関して画面を交えながら説明したいと思います。

 ・FAST VP(仮想ストレージアプライアンス版のに階層化が可能!!)

 ・ついに搭載NAS Replication!!

 ・ついに搭載Quota!!

 ・ついに搭載Virtual Data Mover

 ・仮想化環境に最適VVols

 ・他社を追随するファイルシステム縮小

これらに関しては日本帰ってからじっくりと検証したいと思います。


 

 

引き続きEMC Worldで情報収集を行いたいと思います。

EMC Worldでの最新情報に関してはEMC ism 2016で発表させていただきますので是非ご参加お待ちしております。

EMC iSM 2016

EMC WORLD2016@ラスベガスの最新情報をメーカーより先にお届け!!

【来場時アンケートご記入のお客様全員にQUOカード500円分プレゼント!】

↓↓詳細な情報・ご登録はこちらから↓↓

EMC ismhttps://networld.smartseminar.jp/public/seminar/view/625

 

以上

2016/05/02

VMware VDPの実測値。。。

Q:VMware VDPの重複排除率はいかほどのものか?

A:環境によって異なるので試してみてください。

このようなやりとりは頻繁にありますよね。

まあ、そうなんですがバックアップ対象がOSをインストールしただけの状態であれば"環境によっ

て異なる"ということも最小限の誤差の範囲に収まると思いますので試してみました。

VDPのバージョンはvSphereDataProtection-6.1.1です。

バックアップ対象は以下の通りです。

下記のプロビジョニングポリシーで作成したWindows2012R2 と CentOS6

Thick Lazy Zeroed

Thick Eager Zeroed

Thin Provision

各OSのディスクサイズと使用容量は下記のとおりです。

各プロビジョニングポリシー共にOSが認識する使用領域は同じです。

Win2012r2

Centos6

バックアップ前のVDPの使用容量は下記のとおりです。536GBですね。 

Vdp_2

バックアップ後に536GBから減った容量がバックアップに使用された容量ということになります。

各種2回ずつバックアップを実施しますが、1回目と2回目の間にデータ更新は一切行いません。

1)Windows2012R2 Thick Lazy Zeroed を2回バックアップしてみました。

Photo_9

1回目のバックアップ後の容量

1a

2回目のバックアップ後の容量

2b_4

OSの使用容量が8.96GBに対して1回目のバックアップに使用されたストレージの容量は

4.9GBでした。2回目のバックアップに必要な容量はゼロでした。

VDPの容量は2回目のバックアップのあと1バイトも変化しませんでした。

2)Windows2012R2 Thick Eager Zeroed を2回バックアップしてみました。

Photo_6

1回目のバックアップ後の容量

2b_52回目のバックアップ後の容量

2b_6Thick Lasy Zeroedと同じ結果でした。

3)Windows2012R2 Thin Provisionを2回バックアップしてみました。

Photo_11

1回目のバックアップ後の容量

W3_22回目のバックアップ後の容量

W32

Thick Lazy Zeroed,Thick Eager Zeroedと同じ結果でした。

4)CentOS6  Thick Lazy Zeroed を2回バックアップしてみました。

Photo_121回目のバックアップ後の容量

1_2

2回目のバックアップ後の容量

2b_7

OSの使用容量が4.2GBに対してバックアップに使用されたストレージの容量は2.4GBでした。

1回目と2回目では1バイトも変化しませんでした。

5)CentOS6  Thick Eager Zeroed を2回バックアップしてみました。

1回目のバックアップ後の容量

Photo_14

2回目のバックアップ後の容量

2b_8

Thick Lasy Zeroedと同じ結果でした。

6)CentOS6  Thin Provision を2回バックアップしてみました。

Photo_16

1回目のバックアップ後の容量

B

2回目のバックアップ後の容量

2Thick Lazy Zeroed,Thick Eager Zeroedと同じ結果でした。

最後に3種のWindowsとCentOSを同時にバックアップしてみます。

Window 8.96GB×3台

CentOS 4.2GB×3台

合計39.48GB です。

All_3

E

1回目のバックアップ後の容量

C_2

2回目のバックアップ後の容量

F

合計39.48GBのバックアップに要したVDPの容量は1回目は14GB、2回目はゼロでした。

VDPに必要なバックアップ容量の算出にお役に立てれば幸いです。

唐突に話は変わりますが、現行のVDPはVDPAの機能が統合されましたので、従来のVDPAの機能(DataDomainとの連携等)を利用可能です。

担当:磯前

実況中継!? VSAN 6.2 中の人によるふかーい話 (パフォーマンス編・後編)

みなさん、こんにちわ。本記事は「実況中継!? VSAN 6.2 中の人によるふかーい話」の続編にあたります。

以前の記事はこちらです。

本記事はTech Field Day主催のイベントStorage Field Day 9内で2016年3月18日に実施されたVMware社のStorage & AvailabilityのCTOであるCristos Karamanolis氏のプレゼンテーションの録画から様々な情報を抜き出したものです。妙にマニアックな質問もありますし、実装手法をどう選んだかについてもCTO自ら意見しているケースも有りますので興味のある方は是非ビデオもご覧になってください。

実況中継というか、なんというか、ビデオから文字を起こしていますのでなんとなくゆる~い感じになってしまっていますが、内容はかなり濃いです。濃すぎてあえて文字にしなかった部分もありますので、そこは生のビデオを御覧ください。こちらの記事は雰囲気も含めてお楽しみいただければ幸いです。ベンチマークソフトを利用しての検証結果が中心ですので、重複排除や圧縮が特に聞きやすいテストになっていたり、ということもありますので、あくまでご参考としてご理解いただければ幸いです。

障害発生時のパフォーマンス

上手く動いている時の話はすべてお話してきました。ここからは壊れた時の話です。

Fig397

非常にシビアな状況を作り出しました。Writeキャッシュが埋まってしまうような負荷をかけ続けました。これには一定の時間(今回の場合60分)がかかります。Writeキャッシュが埋まってしまうと、デステージ(キャパシティディスクへのデータの書き出し)が始まります。これを表しているのは青のラインです。一貫したパフォーマンスが出ていますが、デステージが並行して走ることで少しガタガタしています。これがベースラインです。さて、障害を起こします。デステージが始まった瞬間、ホストを落とします。

念のためですが、今回はDVD Storeを利用していますですのでこの縦軸はユーザーが実際に体感するアプリケーションのOPM(毎分の処理数=多いほどパフォーマンスが高い)です。また、Y軸の一番下は0ではなく100で、通常状態では160の数字が出ています。

障害が発生した直後、一時的に158から112ほどまで低下しますが、130~140ぐらいに安定します。この間隔が落ちたホスト上にあったデータを生き残ったホスト内のデータから復元している期間です。この時に発生した再同期のためのトラフィックがグレーで表示されています。

ここで言えるのは一時的にパフォーマンスが劣化しますが、上手く保てています。最大でも25%しか劣化しませんし、殆どの期間は10%程度の劣化で済んでいます。

そして再同期が終わればオレンジのラインは標準のガタガタに戻っています。これはDVD Storeのワークロードでデータベースがどんどん膨らんでいるため、デステージが常に行われている状態だからです。

VSANはシステム内に分散スケジューラーを持っており、再同期のための帯域が25%未満になるように調整するようになっています。うまいことにちょうどこの例でも25%でしたね。とにかく、通常のIOのためのトラフィックを出来る限り邪魔しないようにしています。つまり出来る限り早く再同期を終わらせるということと、アプリケーションへの影響を最小にしようという2つのトレードオフを行っているのです。

会場より : どっちを優先したいというユーザーが居るのではないですか?

そのための詳細設定を提供しています。標準は20か25ですが、変更できます。

ビジネスクリティカルアプリケーションでのパフォーマンス

驚くべきことに、今日VSANで最も広く利用されているアプリケーションはビジネスクリティカルアプリケーションなのです。SAPやMicrosoftやOracleですね。様々なホワイトペーパーを提供しており、多くのお客様環境で利用されています。SAPとは緊密に活動しており、SAP HANAの認定検証を行いましたが、VSANはそれをすべてクリアしました。公に書くことは出来ませんが、レイテンシは600~650マイクロ秒程度でした。

Fig398

これはOracle RACの実際のワークロードで、4ノードのハイブリッド構成での結果です。私だったらオールフラッシュで構成しますが・・・まぁ、見てみましょう。 Oracle RACでそれぞれのノードで1台ずつ仮想マシンが動作しています。パフォーマンスは素晴らしいです。平均で287,000TPM(毎分処理されるトランザクション数)で、最大で331,000TPMを記録しています。これは非常に嬉しいことです。ハイブリッド構成であっても一貫したパフォーマンスが得られていることの証ですから。また1ノードだけでは155,000TPMだったトランザクション数も4ノードで287,000TPMまでスケールしています。

ストレッチクラスタでのパフォーマンス

多くの顧客はこうしたアプリケーションをストレッチクラスタで動作させています。理由は高い可用性を得たいがためです。ストレッチクラスタはどのようにパフォーマンスに影響するのでしょうか?

Fig399

今回も前のスライド(Oracle RAC)とお同じベンチマークを利用しています。Oracle RACによるSwingベンチです。正確なノード数を忘れてしまいましたが、ベースラインとしては同じデータセンタ内での値、1msのレイテンシのストレッチクラスタ、2.2msのストレッチクラスタ、4.2msのストレッチクラスタを比較しています。TPS(毎秒のトランザクション数)はそのレイテンシに対して、妥当なレベルでの劣化が見えています。つまり、データセンタの距離に応じてパフォーマンスにペナルティが生まれているということです。いわゆるメトロクラスタの距離であればラウンドトリップタイムは1ms程度でしょう。その環境ならもともとの環境の80%のパフォーマンスで利用が可能です。そして、RPOはゼロです。障害時にデータを失うことはありません。

いかがでしたでしょうか?キャパシティ・パフォーマンス、ストレッチクラスタと優れた技術がふんだんに盛り込まれたVSANはなんとただのx86サーバで動作するのです。まさにストレージの革命ですね。また面白い内容があればご紹介していきます。

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