*PernixData Feed

2016/07/18

PDキッド エピソード3 : PDキッドがデータベースのパフォーマンスに挑む

さて、アメコミファンの皆様、そしてストレージのファンの皆様、前回からわずか一週間。PDキッドの第3話の登場です!

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

個性的な登場人物の詳しいプロフィールはこちら。みんな相当ヤバイ奴らですが、なんと今回はPDキッド以外は出てきません!(笑) なぜなら、今回の問題はストレージの問題では無いからです。 ストレージの世界から飛び出したPDキッドの行方は果たして!?

Fig418

続きを読むをクリックして進んでください!

続きを読む »

2016/07/11

PDキッド エピソード2 : PDキッドがキャパシティの難題に挑む

さて、アメコミファンの皆様、そしてストレージのファンの皆様、前回からわずか一週間。PDキッドの第2話の登場です!

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

個性的な登場人物の詳しいプロフィールはこちら。みんな相当ヤバイ奴らです! PDキッドの行方は果たして!?

Fig415

続きを読むをクリックして進んでください!

続きを読む »

2016/07/04

PDキッド エピソード1 : PDキッドのSANtasticな冒険

さて、アメコミファンの皆様、そしてストレージのファンの皆様、長らくおまたせ致しました。いよいよPDキッドの本邦初公開(あたりまえ)です!

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

個性的な登場人物の詳しいプロフィールはこちら。みんな相当ヤバイ奴らです! PDキッドの行方は果たして!?

Fig411

続きを読むをクリックして進んでください!

続きを読む »

2016/06/27

アメコミファン必見! ストレージの世界で戦うスーパーヒーロー PDキッド まずは登場人物紹介!

皆さんこんにちわ。PernixData社が面白いコミックを作成していることをご存じですか? せっかくなのでこれを翻訳していこうと思います。

まずは登場人物について、さすがアメコミ!名前がとーってもアレですが、できるだけ忠実に訳したつもりです。なお、あくまで極度にデフォルメされたあくまでコミックなので気軽な気分でお読みください。原文はこちら

来週以降は実際のコミックを掲載していきます!

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

PDキッド

Fig406

PDキッドの表の顔は、大学に通う普通の若者です。ですが、それは世を忍ぶ仮の姿。実際に彼女は若い女の子ですが、彼女の家族はストレージ戦争で荒廃した彼女の生まれた星、惑星サーヴァラニアから逃げだし、安全だと考える地球へと訪れたのでした。PDキッドは地球ですくすくと成長し、そのうちにどのようにストレージを設計するのが良いのかという議論が発生しだすのです。恐ろしいことに、彼女の生まれた星を荒廃させたストレージ戦争が、新しい彼女の星でもまた、起ころうとしているのです。PDキッドは正しい理の代弁者となり、彼女の新しい星に平和で、論理的なストレージの設計と展開をもたらすために立ち上がります。

PDキッドは空いた時間を見つけてはストレージを学びました、そして時がたち、彼女は地元の大学でその研究を続けました。まもなく彼女は大学においてトップのストレージエンジニアとなり、彼女が率いる大学の生徒のチームは大学ストレージ設計チャンピオンシップで勝利をおさめることになります。大学新入生時代が終わり、彼女は自身の知識を理論から実践へと拡大するためにPDキッドは地元の会社でストレージ管理者として夏季インターンを行うことにします。

ある日、その会社でストレージ管理者では解決のできない、パフォーマンスの問題が発生します。PDキッドは自分自身はその問題を解決できる方法を知っていると思いましたが、ソリューションを提案できるという確信はありませんでした。ストレージ管理者は頭を抱え、自身の不幸を憂いました。問題を解決するために、ヴァートマンが部屋に飛び込んできたのです。ヴァートマンがソリューションをシステム管理者に説明している時、PDキッドは高ぶる気持ちを抑えられず、自分のアイディアをヴァートマンのソリューションに付け加えました。ヴァートマンは感心し、彼女にこの会社はとても幸福だ、いつの日か彼女は素晴らしい管理者になるだろうと告げました。

ストレージ管理者の感謝の雨の中、ヴァートマンが立ち去った時、PDキッドは問題解決を手助けすることの素晴らしさを感じます。そして、彼女はもはや単なるインターンとして以上の活動をすべき時で、ただの1社だけを助けるだけでは新たなるストレージ戦争の亡霊を撃退できないとも実感します。彼女はヴァートマンの後を追い、すぐに素晴らしいチームを組むことが出来ると納得させます。彼女が知識を蓄えるにつれ、PDキッドはヴァートマン以上にストレージについてよく理解するようになり、ヴァートマンがいない時でもシステム管理者の問題を解決できるようになってきました。ストレージやデータベース管理者が助けを必要としている時、疾風のようにPDキッドが現れるのです。

PDキッドは物理的なスーパーパワーは持ちあわせていません。彼女の知恵、素早さ、そしてPernixDataとその製品そして、ストレージについての深い知識が彼女の武器です。PDキッドは彼女の生まれた星から運んできた技術的なアドバンテージを持っています。それは彼女のコスチュームの中の特殊なガントレットからサーバや他のシステムに瞬時にソフトウェアをブラストとして放出出来るのです。

ヴァートマン

Fig407

ヴァートマンも以前は普通の名前の普通の男でした。彼は長年大きな企業の管理者として勤務していました。彼は仕事に打ち込みながら、ストレージのパフォーマンスの低下が起きる度にそれをどのように対処すればいいのか考えていましたが、誰かに答えを聞く度に異なった回答が返ってくるのです。ベンダーと話をしようとしましたが、それぞれのベンダーは自分自身の話しかしてくれません。そんな話の果てに、パフォーマンスの本質を理解し始めますが、一方でベンダーに対して、他のベンダーとも会話をしているという話をするまでのことでした。そうなると、もうてんやわんやです。というのも、それぞれのベンダーがいうことは、他のベンダーについて彼が考えていたこととほとんど同じでした。すべてのベンダーは他のすべてのベンダーのいうことは矛盾しているということだけでした。自明なことですが、それぞれのベンダーは自社の製品を買うようにしかアドバイスをしてくれません。誰も彼の問題を解決してくれようとか、興味を満たそうという部分を気にしてはくれないのです。

ヴァートマンは幻滅し、あらゆるベンダーが彼の心に植えつけた恐怖、確実性のなさ、そして嘘でおかしな物を見始めます。金縛りにあっている山積みの情報がそれぞれ競合しあってその山の先には進めないのです。誰かと話をする度にひっくり返ってしまうほどでした。失意のもとに彼は職を去り、山小屋に一人こもってストレージシステムの真実を探しだすことを決意します。どう設計するか、どうやって最適化するか、どのようにしてパフォーマンスを最大限に発揮させるか。1日のうち2時間だけは運動をし、残りはすべてコンピューターの前で検索、思索、評価を行いました。

ある日、彼はPernixDataに出会います。そして、彼が探していた明確な答えをそこで見出すのです。ストレージは仮想化環境に対して最適化され、彼は仮想化の男、すなわちヴァートマンへ変身します。知識によって武装され、ついに彼は孤独に別れを告げたのです。今後、データセンタのストレージ管理者に彼がこれまで苦しめられてきたような困難をさせないことを誓ったのです。彼はストレージ管理者たちを仮想の救い上げる道へと誘導します。しかし、彼は青いシャツとスラックスのおじさんの言うことをそうそう聞いてはくれないということを思い知ります。あらたなる知識と確信を持って孤独なおじさんからヴァートマンへと返信したのです。仮想化の守護者、そしてストレージと仮想化の管理者のチャンピオンで、どこにでも駆けつけるのです。

ヴァートマンは物理的なスーパーパワーは持ちあわせていませんが、彼は山小屋に一人こもった時に鍛え上げた肉体を持ち、以前のようにポテトチップスの袋から袋へと食べまくったりするようなことはしなくなりました。長年の管理者としての苦難は彼に超能力を与え、ストレージや仮想化管理者が悪者による疑念に付きまとわれているようなときに発揮されます。ヴァートマンの最大の弱点はスーパーヒーローになってやや、はしゃぎ過ぎているというところです。

ザ・ハイパーコンフューザー

Fig408

ハイヤム・ミッシュマッシュはストレージの荒野で生まれました。広大な砂漠と低木だけの荒野で、蜃気楼の立ち上る中にストレージサイロが立ち並びます。彼の父親はそこでシステムとネットワークの運用を行っていました。彼はデータの補完に遠隔地のサイロを利用し、リモートからそれを利用している涼しい都市から遠く離れていることに苛立ち、なぜすべてのものが一箇所に集まっていないのか不思議に思うようになりました。

「SANが別になっているのにはいろいろな素晴らしい理由があるんだよ」と彼の父親は説明しました。

「そんなの気にしないさ!」 若いハイヤム・ミッシュマッシュは譲りません。「すべてのものを一緒にしたいんだ! SANなんて嫌いだ! SANなんか要るもんか!」彼は叫びました。

ついに、彼の家族は大都市へと引っ越すための資金をためることが出来ました。ハイヤム・ミッシュマッシュはこれでようやく幸せになれると考えましたが、もはや大都市においてもストレージの荒野がそうであったようにあらゆるものが一緒という状態ではありませんでした。友達が特別なコントローラーとPS3を持っている時に、彼はゲームボーイしか欲しがりませんでした。「ゲームができる、それで十分さ!」と両親に言いました。「コントローラーが分かれていたら無くすかもしれないし、全てが一つの箱に入っている方がいいんだよ。」

彼の友達が色鉛筆、ブラシ、絵の具、キャンバス、そしてイーゼルの図工セットを買った時に、彼はクレヨンを一箱欲しがるだけでした。「これで描けるよ。」と両親に言います。「これで充分、しかも全部一つの箱に入っている! クレヨンを研ぐ道具もね!」 彼は一つの箱に入っていないものは全て信用しなくなりました。それが別々のコンポーネントであったとしてもです。

学校の給食の時間、かれは全てをトレイの上に一塊のハイパーコンバージドフードとして一緒くたに盛り合わせます。 肉、野菜、パン、そして、デザートまでもが一緒に混ぜ合わさります。彼は食べ物がトレイ上の別々の場所に分けておかれることに耐えられないのです。全てが一つでなくてはなりません。「ほんとうに美味しく食べようと思ったら、別々に食べたほうがイイよ。」という友人の助言も 「そんなの、いらないよ」という返事です。「簡単だし、これで充分なんだ。」

彼は全てが一つの箱に入っているのが大好きです。効率やコストやパフォーマンスには関心はありません。最高の状態である必要はなく、充分なレベルで、一つの箱に入ってさえいればいいのです。彼は近年の分散ネットワークが専用コンポーネントと一緒につながっているのを見て、ネットワーク設計などが不要だった時代を懐かしく思います、別の箱を単に繋げばよかったのです。そしてその次にも別の箱をつなぐ。何が必要かは関係ありません。別の箱をつなぐことが全てです。というのも、必要な物は全てその箱の中に入っているのです。必要でないものが入っているということも気にする必要はありません。動きさえすれば、それで充分なのです。

成長した彼が自身の子供に語ったことは、誰も金メダルなんて保つ必要はないということです。もっと手を抜いて銅メダルをもらう、それで充分なのです。メダルはメダル、ストレージはストレージ、意味をなしさえすれば、それで充分なのです。

大学を卒業後、ハイヤム・ミッシュマッシュはシステム管理者のキャリアを選択します。そこでは皆が彼と同じ考えを持つと考えたからでしたが、実際の人々はパフォーマンスやコスト、効率性に興味を持っていました。彼は彼の主張に合意できない人々にますます苛立ちを高めます。最高であることを諦め、それで充分な程度を受け入れさえすれば物事がどんなに簡単になるか、わからないのか?ある日、PernixData社のソリューションに出会い、ついに耐え切れなくなってしまいました。ハイヤム・ミッシュマッシュは逃げ出しました。彼は何週間もの間、地下室に身を隠し、誰も自分の発言に耳を傾けてくれないことに苛立ち、みるみるうちに更にマニアックになっていきました。そして、ハイヤム・ミッシュマッシュのいうことは誰も聞いてくれない、ですが、聞かなければならない状況に陥れば聞いてくれるだろう、よし、自分でその状況を作り出そうと考えるようになります。ハイヤム・ミッシュマッシュは地下室を飛び出し、別の人間に生まれ変わります。SANの宿敵、ハイパーコンバージドのチャンピオン。そう、彼はハイパーコンフューザーになったのです。

スピンドラー

Fig409

ハイパーコンフューザーと同様、スピンドラーもストレージの荒野で育ちました。ハイパーコンフューザーと違うのは、スピンドラーは裕福な、何世代も前から続く、古き良き時代の家族のもとで育ったということです。彼の家族は古い風習や従来通りのやり方を貫き通すことを大きな誇りとしていました。家族で車を購入しましたが、ほとんど場合、馬が引く馬車を利用していました。家には電灯が有りますが、大抵は以前通りロウソクを使っています。デジタルミュージックも有りますが、殆どはビニールのレコードを使います。スピンドラーは古いレコードを聞き、そのレコードがターンテーブルの上で、何度も何度も回転するのを眺めるのが大好きです。

スピンドラーは学校へいくようになると、スピンドルベースのストレージに夢中になりました。スピンドル上のディスクは彼の愛するターンテーブルのスピンドルを思い起こさせてくれます。彼の音楽のコレクションをMP3ファイルで聞く時もあります。ですから、喜んで近年のフラッシュのテクノロジーをストレージの設計喜んで取り入れましたが、ほんとうに必要な以上には利用しません。どうして誰も彼の美しいスピンドルと、美しいディスクのエレガントさを理解してくれないのか、わからないのです。

年をとるにつれ、スピンドラーはどんどんつまらなくなったと感じます。ですが、パフォーマンスやレイテンシについて文句をいう、若い管理者に対しては古き好き価値が理解できないと頭ごなしです。しかし、彼の言うことに耳を貸す者もどんどん減っていきます。ですから、彼は誰もが無視できなくなるように自分自身をコスプレで打ち出すことを決意したのです。彼は・・・スピンドラーとなったのです。

ザ・デュープスター

Fig410

デュープスターは心が広く、どこまでも正直な若者でした。彼は人が言うことは全て信じます。嘘や誇張があるかもしれないということなど考えもしません。同僚の学生や教授に不愉快な思いをさせられつつも、世界はほとんど完璧であるという博愛の信念のもと大学を卒業します。彼は性善説主義者なのです。

卒業後、地元の会社で職につき、ストレージ管理を学びます。そして、その後会社のストレージ装置の設計についての責任を与えられるようになります。最初はとても面白い業務でした。ベンダーが製品を説明しにやってきて、どうして彼がそのストレージを買わなければいけないのかをとうとうと話します。製品も良さそうに聞こえ、全部を試してみたいと思うようになります。製品を評価する際に、今度は営業マンがしゃべるほどまでには製品が良くないと感じるようになります。実際、ある部分はとてもできが悪く、予期せぬストレージのパフォーマンス問題が発生します。

「設定が間違っている」としか言わない営業マンのところへ行き、セールスエンジニアが時にはなんとか問題を修正しますが、その度にデュープスターは装置に何かを追加したり、設定を変えたりするので、更に問題が誘発されます。営業マンが約束した素晴らしいパフォーマンスはその角のちょっと先、もうちょっとしたら手に入る、、、ですが結局どうしても手にはいりませんでした。営業マンは嘘をついていたんでしょうか? なぜそんな不誠実なことをするのでしょうか? 彼は言葉巧みに騙され、役に立たないものをかわされた、イカサマだ、と考えるようになります。インチキだと。

ある日、ある営業マンがデュープスターが抱えるパフォーマンスの問題を彼のストレージが全て解決すると約束しました。「今まで散々馬鹿されてきたしな・・・」と営業マンに告げます。営業マンは発言は全て事実で、絶対にこのストレージを気に入ると保証すると言いました。一ヶ月後、仮想マシンが落ち、ユーザーがパフォーマンスが酷いと叫び、愛を注いだストレージは完璧に用なしになりました。マネージャーたちは彼を取り囲み早口でダウンタイムや遅延について罵ります。彼は両手を耳にあてて「もう沢山だ! 期待通りに動いているように見えないのか?」と叫びます。

笑いが巻き起こりました。笑い、笑い、笑い・・・。「期待通りに動いているじゃないか!」もう一度彼は叫び、そしてデータセンターから逃げ出しました。誰も彼を騙してはいないのです。いや、いや、いや、その逆、インチキをかわされたのではなく、彼自身がインチキなのです。他人を悲劇に巻き込み、他人を困惑させる、他人のお金を使い、後始末を他人にさせる。誰も彼を騙す(Dupe/デュープ)することはありません。それは、他の誰もデュープスターではないからです。彼自身がデュープスターなのです!

いかがでしょうか? いよいよ来週から本編を掲載していきます。そうとうヒドイ話になりそうな登場人物たちですね(笑) みなさんの周りにもこんな人いませんか? 来週をお楽しみに!

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

2016/06/20

仮想化ワークロードを知る: ブロックサイズとワークロードの変移

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

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

本記事の原文はKnow Your Virtual Workloads: Block Size and Workload Shiftで閲覧可能です。

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

データセンタを適切に設計し、最適化するためには様々なワークロードの特性そのもの、そしてそれが時とともにどのように変わっていくのか、それによってアプリケーションの性能はどんな影響を受けるのかということを理解しておくことが重要です。私は6つの仮想化ワークロードについて知っておくべきことを突き止めることが出来ました。

最近の私の記事で、私はデータセンタにおいて見落とされがちな2つの仮想マシンの特性についてのべてきました。ReadとWriteがそれぞれ仮想マシンに異なった影響を及ぼすということと、アクセスパターンが異なればパフォーマンスへの影響を大きく異なるという2つの特徴です。これらを誤って認識したり、適切に計測ができないことになれば、アプリケーションのパフォーマンスへ多大なる影響を及ぼし、結果としてITコストが高く付くことになります。

今回の記事では前回同様に重要な2つの特性についてご紹介していきます : ブロックサイズとワークロードです。

#3 ブロックサイズが重要

仮想マシンのパフォーマンスの問題を特定し、解決するという冒険の中で、管理者は大抵CPU、メモリ、そしてストレージにまつわる計測値を利用します。しかし、仮想化インフラストラクチャ内のデータを得ることは難しいことも多々有ります。ブロックサイズはストレージのパフォーマンスに劇的な影響を与えることのある計測値の代表格ですが、アプリケーション、OS、そしてワークロードによって劇的に異なったものになります。しかも、一般的な管理システムでは殆どの場合、見えない値なのです。これが見えないことに起因して、ブロックサイズは仮想化、ネットワーク、ストレージの管理者のような方々に誤解されたり、見落とされたりしてしまうのです。

ストレージI/Oという文脈では、ブロックはデータの流れの中で転送される単なるデータの集まりの単位ということに過ぎません。ブロックの「サイズ」はReadであれWriteであれ、単一の転送サイズを表しているだけなのです。スループットは毎秒行われるI/O(IOPS)とそれぞれの送受信されたI/Oの結果を表します。アプリケーション、そして、それが動作しているオペレーティングシステムはアプリケーションとそれにまつわるワークロードの特性によって幅広く、そして常に変わり続ける混在したブロックサイズを生成します。ReadとWriteでブロックサイズが異なることさえ日常的です。

ブロックサイズはストレージシステムに異なる影響を及ぼすので、この計測値を見ておくことは非常に重要です。例えば、256Kのブロックは4Kのブロックよりも64倍も転送量が大きいですし、それによってストレージスタックの全てのコンポーネントがI/Oリクエストを完了するためにより多くのリソースを利用します。ストレージファブリック、プロトコル、HBAでの処理のオーバーヘッド、スイッチ、ストレージコントローラー、そしてストレージで利用されているメディアなど全てが影響を受けることになります。データセンタにおいてフラッシュを利用する際には、これまで以上にブロックサイズを確認しておくことが重要になります。これはフラッシュが大きなブロックサイズを通常上手く処理が出来ないからに他なりません。

vCenterのような従来型のハイパーバイザーの管理ツールでは、こうしたデータを確認することはできません。もちろん、vCenterの統計情報を利用する監視ツールも同様です。ストレージ装置は限定的なブロックサイズのデータを表示することも出来ますが、情報は非常に荒いもので、利用用途が限られます。ストレージの設計、最適化、そしてトラブルシュートの真に規範的なアプローチとしてはデータセンタ全体に渡るブロックサイズを適切に見なければなりません。しかも、個々のワークロードの状態を適切に理解出来るだけのきめ細やかさが必要です。

#4: ワークロードは常に変化する

パフォーマンスに関連する計測値はどのようにワークロードが振る舞うのかがわかるレベルで見なければなりません。管理者に提供されるデータの品質はそれをどのように計測したかだけでなく、どのぐらいの頻度でそれを計測したかも重要です。そもそも非常に動的で、バーストを起こすようなシステムにおいて、どの計測値が重要なのかということを考える場合、どのぐらいの頻度でデータをサンプリングしたのかが最も重要になります。

ストレージのI/Oレイテンシを例に取ってみましょう。小さいながらも何度もレイテンシがスパイクするような状態はインフラストラクチャ上の全ての仮想マシンに影響を及ぼします。既存のソリューションを利用している場合、ポーリングのインターバルが長いせいで、こうしたスパイクを適切に拾いきれていないということもありえます。さらに悪いことに、こうしたソリューションが時間軸上のデータを結合して平均してしまうことで、折角の情報を全く意味のないものにしてしまうこともあるのです。

こうした問題はレイテンシを分析するときに限った話ではありません。単一のワークロードや、環境全体のピークのIOPSを調べてみようと思ったことがある方も多いと思います。もし、ソリューションがデータを5分か、10分に一度しかサンプリングしていないとすると、このピークが本当にストレージシステムにとってのピークになっていると確定することが出来るのでしょうか?データセンタインフラストラクチャでは、ミリ秒の単位で物が動いているのです。

ワークロードはアプリケーションが何をさせられているかによって常に変わり続けます。Readリクエスト数とWriteリクエスト数、アクセスパターン、ブロックサイズの分布、データアクセス頻度は多くの変化し続ける値の中のほんの一部です。こうした値の全てが仮想マシンの要求を環境がどの程度満たせているのかという指標となります。理想的なソリューションは、管理者がこうした計測値を仮想マシンのパフォーマンスと、それ以外の環境上の仮想マシンにどのような影響を及ぼしているのかを適切に見ることが出来るようなものです。

次回、本シリーズの最終回では、環境において適切なパフォーマンスを提供するために重要なのに、見落とされがちなさらに2つの特性について取り上げていきます。乞うご期待!

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

2016/06/13

なぜ正確なIOブロックサイズの頻出度とワークロードの分布メトリックが重要なのか?

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

本記事の原文はWhy accurate IO block size frequency and workload distribution metrics are so valuableで閲覧可能です。

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

ストレージのアーキテクチャの議論や比較をする際に、IOPS、レイテンシ、そしてスループットはその差別化のための主となるメトリックです。残念なことに、IOPSが業界の住人によって、ストレージ装置を比較する際の最初のメトリックとなってしまっています。正直な話、これは中毒性のある数字です。業界においては揺るがし難い影響を持っています。90年台においては3,000IOPSを実行できるシステムに皆が歓声を上げました。今では新しいSSDデバイスが250,000IOPSもの性能を提供してくれています。

IOPSの値はストレージシステムの得点順位表において普遍的な単位である、そこに疑問の余地はないという所まで来てしまっています。しかし、その実、IOPSの値はそれだけでは何の意味も持たない事もわかっています。システムの特性を適切に理解するためにはIOブロックサイズをこの公式に加える必要があります。そして、私自身はあらゆるレベルの情報システム部門、つまり管理者からCIOに至るまでが正確なIOブロックサイズの頻出度を理解しておくべきだと信じています。もちろん、それぞれの役割によって必要とされる詳細さは異なります。

SLAを順守する

ワークロードのプロファイルを理解て、それがどのようにインフラストラクチャに合致するのかということを問い続けるのが今日の情報システムチームの頭のなかの大部分を占めています。以前はそれはストレージチームが中心になっていましたが、今日では仮想化管理者や設計者もがこれに挑んでいます。ワークロードのプロファイルの変化に気づくことができると、トレンドを理解した上で、インフラストラクチャやサービスを状況に応じて割り当てるなどのより高いレベルでの管理ができるようになります。それだけではなく、近年では開発チームがインフラストラクチャチームとインフラストラクチャの限界を理解しようとコミニュケーションが始まっています。こうした情報で開発チームはアプリケーションを本稼働環境のパフォーマンス特性に合わせた形で調整することが出来るようになります。今日、あらゆるチームはITインフラストラクチャをビジネス要件に合わせていくことにフォーカスを当てています。現在動作しているワークロードの特性を正確に分析し、今後動作させる可能性があるワークロードがどのように環境内で振る舞うかを理解することでSLAを順守する運用の中で得難い情報を知ることが出来ます。

顧客との会話の中で必要な(正しい)情報を得る

CTOやCIOの関心事項の中で大きなものの一つとして、自社のチームが顧客と適切に対話するための充分な正しいデータを生成できていないというものが有ります。例えば、これは開発ステージから本可動ステージにプロジェクトが移行されるときに発生します。ワークロードの使われ方が変化し、ユーザーは新しいプラットフォームを利用し始めます。人工的なテストはもう登場しませんし、インフラストラクチャに対する変更もたびたび発生します。ほとんどの開発検証環境は本稼働環境のインフラストラクチャとは異なっています。それにとどまらず、本稼働環境では負荷の同時集中や他のワークロードとの相乗効果による負荷など、そのプロジェクトが最後のステージで利用していた開発検証環境では殆ど起こらなかったような負荷も発生します。本稼働環境の機能的なキャパシティは充分なのか?とそもそもの会話が再び繰り返されます。こうした際には以前のステージと現在のパフォーマンスを適切に比較した分析データが必要となります。以前の環境とどこがちがっているのだろうか?正しいデータを簡単に入手することができればどっちのプラットフォームが今回の新しいアプリケーションにとって最適なのかを簡単に決めることが出来ますし、新しいワークロードやサービスにどのようにインフラストラクチャを適合させていくかということも明らかです。

ストレージシステムの購入プロセス

管理者や設計者の大きな問題は自身のデータセンタ内の現在のワークロードを適切に反映したデータをつくり上げることです。このデータは新しいストレージインフラストラクチャを購入しようというプロセスの中では非常に重要なデータです。ストレージベンダーは顧客にワークロードの特性とパフォーマンス要件の提出を求め、それによって顧客の供給を満たせるようにしようとします。加えて、償却完了までの期間内で、予測される将来的な成長も加味してパフォーマンスを保証できるようにします。にも関わらず、サイジングが正しくなく、ストレージ装置が性能を補いきれていないというような例は数えきれないほど見てきました。これは、大抵は正しくないデータを元にストレージソリューションに正しくない設定を施してしまったということが原因です。環境の適切な分析が行えていればこうしたコストの高くつく状況は防げるはずです。

PernixData Architect

PernixData FVPのワークロードに対してのメリットや以前には不可能だたストレージプラットフォームを構成できる能力を理解した顧客が次に口にする疑問は非常に興味深いものです。それはどのワークロードからやったらいいでしょうか?というものでした。これがPernixData Architectの誕生につながりました。ワークロードとインフラストラクチャの振る舞いについての正確な分析を提供することで、これまでにない気づきを得ることが可能になります。情報を充分に保持するハイパーバイザーを活用することで、Architectは仮想化インフラストラクチャのあらゆるレベルでの気づきを提供することが可能です。私がArchitectで最も気に入っているのは先進的な設計のビジョンにもとづいて作られているというところです。システムは運用を手助けし、そして要素的なレベルにまで掘り下げた情報を提示します。クラスタレベルから特定の仮想マシンワークロードへと抽象的な部分から特定レベルへと遷移していき、適切なタイミングで必要な情報を提示します。ArchitectがIOブロックサイズの頻度やRead/Writeの分布と言ったメトリックをどのように表示するか、よく見ていきましょう。

PernixData Architectは独立した製品でPernixData FVPが必要でない場合にもあらゆるストレージ装置を分析することが出来るとうことを覚えておいてください、。以下のスクリーンショットはすべて、オールフラッシュストレージ装置(AFA)をArchitectで分析したものです。

クラスタビュー

スクリーンショットになっているのはクラスタレベルのワークロードの概要です。ここにはvSphereクラスタで動作している全ての仮想マシンでのRead Writeの分布の概要が表示されています。青いバーで表示されているのはvSphereクラスタ内で生成しているすべてのI/OのI/Oブロックサイズの分布です。

バーの上にマウスカーソルを乗せると、特定のブロックサイズについての更に詳細な情報が提示されます。この場合、全体のIOブロックのうち17.2%が4Kよりも小さいということになります。何故この情報が重要なのかということと、4Kよりも小さなブロック仮想マシンのパフォーマンスとストレージのオーバーヘッドを理解するのに役立つかということは後々の記事でお話します。

Fig402

IO Frequency(IO頻度)ビュー

IO Frequencyビューを選択すると、Architectによって更に詳細なビューが表示されます。ReadとWriteの操作がわけられて表示されるようになります。グリーンの色の濃さがブロックの頻出度を表します。マウスカーソルを乗せると、その特定のI/O操作が全体のI/Oのどれだけに当たるか、など詳細な情報が表示されます。

Fig403

Architectではユーザーにとって適切な期間での分析結果を表示することも可能です。管理者は特定の期間をドリルダウンして見ることもできれば、長い期間でみてトレンド分析のレポートを作ることも出来るようにしてあります。

Fig404

こうしたメトリックは仮想化インフラストラクチャの複数のレベルで見ることが可能です。これによって仮想マシンの振る舞いについて、ターゲットを決めて探索を行うことが出来ます。以下のスクリーンショットはSQLを動作させている仮想マシンのスクリーンショットです。管理者が(クラスタレベルでの表示と同じような情報に)アクセスをしようと思えばすぐに行えるようになっています。

Fig405Architectは刻々と変わりゆく仮想マシンのワークロードや仮想化インフラストラクチャの振る舞いを継続的に表示してくれます。Read/Writeの分布やI/Oブロックサイズの頻出度などの正確なメトリックはストレージインフラストラクチャの購入のプロセスを成功に導くためには重要なデータです。また、SLAを管理し、順守していく際に重要な影響をもつ、差分分析、ワークロード要件分析などを提供します。「Maximizing performance with the correct drivers - Intel PCIe NVMe driver(訳注:翻訳予定なし)」という記事でふれたとおり、Architectは主だったストレージのメトリクスの詳細なパフォーマンス分析も提供しています。こうしたメトリクスで現在の環境や、新しいストレージを購入する際のPOCの環境などのインフラストラクチャの振る舞い分析をより精緻なレベルで行うことが出来るようになります。PernixData Architectについての記事はまだまだ続きます。

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

2016/06/06

優れた製品を生み出すPernixDataのアプローチ

本ブログエントリーはPernixData社のUser Experience DesignerであるBryan Crowe氏のブログの翻訳版です。Brayan氏はPernixData社のソフトウェアアプリケーションのデザインとユーザビリティ全般の責任者です。PernixDataに入社する前にはVMwareとGoogleで同様な役割を担っていました。PernixDataでは彼の強みであるVMwareでの仮想化のバックグラウンドとGoogleでのビジネスインテリジェンスや分析で培った強力な情報をうまい方法で有益に伝えるというインターフェイス作成の経験を融合させて活動を行っています。

Fig401

Brayan氏はケント州立大学でコンピュータサイエンスの学士と、カーネギーメロン大学でヒューマンコンピューターインタラクションの修士を納めています。彼は素晴らしい技術バックグラウンドを武器に、チームのエンジニアと議論/討論をいといませんし、彼は自身のデザインでいつも周りの開発者が様々なクリエイティビティを発揮することをとても喜んでいます。

本記事の原文はPernixData's Approach to Creating Great Productsで閲覧可能です。

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

私の名前はBryan Croweです。PernixDataでユーザエクスペリエンスデザイナーをしています。ユーザエクスペリエンス(UX)とはいっても、どのようなものなのでしょうか?アプリケーションUIのビジュアル的なルック&フィールのことを思い浮かべる方もいるでしょう。また、全体の構造から情報をプレゼンテーションしながらワークフローを構成することだと考える方もおられるかもしれません。私自身は製品の最も日の当たる部分で、ユーザーに最も総合的に影響を及ぼす部分だと考えています。UIのユーザービリティの部分であることもありますが、あるときはストレージシステムのIOPSやレイテンシレベルだったりもします(例 : 高いIOPSを低いレイテンシで提供するストレージシステム = 優れたユーザーエクスペリエンス)。ですから、ユーザーエクスペリエンスはUXデザイナーだけで完結するものではありません。コードのすべての行、そして暗黙的に提供されるバックエンドの機能をの全てがユーザーエクスペリエンスに影響を及ぼします。本人が自覚していようが、いまいがバックエンドのエンジニアは製品のUXにとても重要な貢献をしているのです。

これまでのところ、上に述べてきた観点、つまり優れたUXという意味では、我々は優れた製品を生み出す素晴らしい仕事ができていると思っています。しかし、何故なのでしょう? PernixData社の製品とエンジニアリングチームはどうしてこれが実現できているのでしょうか?

マネーボール

私はクリーブランド・ブラウンズのファンです(まぁ、まぁ・・・わかってますよ)、更に最近も政権交代が有りました。今回は「マネーボール」の小説/映画のモチーフを地で行く、ポール・デポデスタが買収を行いました。最初の会見でポールは優れた組織はどう見えるものか、競争相手と自身を差別化するためにどのような特別なことをしていくのか、ということについてコメントを述べました。オークランドのAリーグにおいては先進的な分析によって彼はこれを実現してきました。彼のコメントは文字通りです、ですが私は同時に面白いと感じました。それによって私は何がPernixDataのチームにとって特別なものなのか、他との差別化になるのかを考えるきっかけとなったのです。

ユーザーにフォーカスを当てる

ユーザーとカスタマーには厳密な違いが有ります。びっくりすることはありません。カスタマーは製品の購入の責任者ですが、ユーザーはそれを利用する人です。コンシューマーソフトウェアの世界ではこれらの役割はたびたび重複しますが、エンタープライズソフトウェアでは区別されています。エンタープライズソフトウェア製品を作っていながら、カスタマーへフォーカスをしていると、幾つかのハイレベルな機能のチェックを行うことで売上が伸びることに気が付き、一方で実際のユーザーのための細かな部分やニュアンスを見失ってしまいます。これについては最初の取っ掛かりとしては非常に良いソフトウェア製品の作成の仕方だと思いますが、製品を毎日の様に使っていくようなユーザーが短時間に様々な操作を行い、様々なことを発見していくとなるとうまくいかない事になってしまいます。

PernixDataはかなり最初の段階からユーザーにフォーカスをしていました。VP of ProductのBala氏は非常にテクニカルですが、初期の段階からユーザーを巻き込み、ハイレベルから下の方までどのようなニーズを持っているのかということを理解することに積極的でした。さらに、プロダクトのメジャーリリースの度、私はシステムのプロトタイプを使ったユーザビリティ実験を繰り返し、ユーザーが言葉にするどの機能が好き、嫌いという意見だけでなく、どこでユーザーが苦労するのか、どんなユーザビリティ上の問題があるのか、という客観的なデータも集めています。加えて、外部でのベータプログラム(FVP 1.0の際には150ユーザー)も行っていますが、その目的は単に出荷前にバックエンドのクリティカルなバグを探しだすことだけではありませんでした。我々はあらゆるレイヤのスタックそれぞれでどのようにすればシステムがより良くなるかということを探し、理解しようとしています。一度製品が出荷されるとSE達はユーザーからのフィードバックを吸い上げてくれる優れた水路にもなってくれます。とにかく我々は色んな意見やフィードバックを我々のユーザーから積極的に集めようとしています。もちろん、何もしようとしていないのであればこうしたデータは無意味です。。。

変化に挑む

ソフトウェアを生み出す際には事故認識をしっかりとしておくことが重要です。UIのある部分が誤解しやすい、コードのいくらかはバグが有る、そしてとある要件はご判断を生むことが有ります。人間ですから、完璧であるということはありえません、ですからこうした物を横にのけておいたり、単に無視してしまうのではなく、より良い変化のためのきっかけとして利用します。ですが、言うは易し、行うは難しです。

ベータプログラムやユーザビリティテストを事前に行い、結果を利用することは製品出荷前に様々なことがわかるという点では理想的です(SEからフィールドのレポートを待つのとは反対です)。ですが、こうした手法はプロダクトの開発サイクルの終盤に訪れます。すべての会社はもちろん、こうしたメカニズムを通して製品がおかしくなるようなクリティカルなバグは発見、解決済みですが、他の問題やバグは将来に先送りされ、修正されるかもしれませんし、されないかもしれません。では、この問題を解決する秘密の魔法は何でしょうか? そんなもの、ありません。もちろん、プロセスの初期段階で何らかはできるでしょう(例:完成版からは程遠いプロトタイプを使ったユーザビリティテストは初期段階でも行えます)、しかし、そもそも全てを初期段階で行うということは全くもって、現実的ではありません。

実際に最高で、最もしっかりとしたフィードバックはプロセスの終盤にしか出てこないことが有ります。前に述べたとおり、簡単な解決策はありません。ですが、効率的に管理することは出来るのです。まず、情報は適切な組織に全てに行き渡らなくてはなりません。フィードバックが組織の階層とそれによるエンジニアリングチームへの伝達の時間によって極度にフィルタされてしまうということがあります。もういまさら遅い、ということもありますし、何をしていいかわからなくなっているということも有ります。一方で、情報が適切に管理され、伝達されることで、少なくとも戦うチャンスを得ることは可能です。

チャンスを得るためには、適切に配置された正しいチームが必要なのです。正しいことをすることに情熱を燃やし、実現のために延長戦を厭わないエンジニアが必要です。どのアイテムに優先順位があり、適切なエンジニアをアサインするという素晴らしい決定と効率的な判断ができるリーダーシップを発揮するメンバーも必要です。全ての優先順位が適切になった際に、本当に素晴らしいことができるようになるのです。PernixDataでは幸運にもこうした環境があるのです。

驚きと喜び

ユーザーにフォーカスして話をしていると、ここからの学びがどのように活用されているかを話しそびれてしまいます。これは本当にとても長いアイテムのチェックリストになり、それぞれ1つ1つ対応していく事になります。そして、多くの場合これが正しいやり方です。例えば、そこからの考察を経てそれをバネにしてもっと高く飛び上がり、もっと良いことを実現できる場合もあります。例えば、Satyam氏とPoojan氏が会社を設立した時、すでに存在しているソフトウェアの延長線上にあるような改善版を作ろうというようなことは考えませんでした。彼らは自身のユーザー、業界、そして市場に対する知識を用いて、本当にユニークな、新しく、これまでにない方法でストレージのパフォーマンスのモンダを解決するものを作ろうとしたのです。そして、FVPが生まれました。

同様に、FVPの最初のヴァージョンを生み出す中で、ユーザーはIOPS、レイテンシ、スループットが重要なメトリクスであるということは我々はユーザーに対する基礎知識として知っていました。これによって、今日これらの統計の状態を表すグラフを含めるということも比較的簡単に行うことが出来そうでした。ですが、我々はそうしなかったのです。もっといいものがあるという予感があったからです。単にそうした統計グラフを表示するだけではなく、ユーザーが様々なレベルで情報が引き出せ、注目しているデータをブレイクダウンしてもっと環境についての考察ができるようにしたのです。これはエンジニアの工数をより多く使うことになりますが、ユーザーにより気に入ってもらえると考えるものです。その努力は結果に見合うものだったとすぐに証明されました、充分なほどに。ですからすぐに我々は自分自身でインフラストラクチャ分析を中心とする製品の制作に取り掛かったのです。そしてArchitectが生まれました。

細部に神が宿る

FVPの以前のヴァージョンで我々は色盲のユーザーにとってももっと利用しやすいようにと可視化部分で利用されている色を微調整しました。それ以外にも様々な異なる要素を考慮しており、色盲シミュレーターを利用して様々なパレットを検証しました。UXの人間としてこれぐらいは最初にやっておくべきだったのではと思うかもしれません。予想外のことといえば、CTOのSatyam氏のことでしょう。この問題については様々なフィードバック会議を実施しました。実際 Satyam氏はレビューを行い、私が作成したデザインドキュメントのほとんどすべてに対して詳細なコメントを返してくれました。これは彼がある種の凶悪な独裁者だからでしょうか?それはご自身でご判断ください。ですが、真面目な話、これは彼が本当に優れたソフトウェアを作りたいということに情熱を燃やしているからに他なりません。それがUIにおけるほんの僅かな問題であったり、ほんの小さな学区エンドの機能であったとしても彼はその洞察、知見をそれに取り組んでいる人間に惜しげも無く貸してくれます。そうしながら、取り組んでいる人間の最終的な判断を信頼してくれているのです。

正しいことをほんの小さな細かな部分でも徹底するという決意はチームの血肉となっています。我々は小さなことを気にします。個人的にはこうした小さな問題を全て把握しておくことは時折効率が良くないと言われることも理解しています。ですが、それらを集約していくことは結果的には大きな変化となります。これが我々がユーザーから出来る限りの多くのフィードバックを集めそれを解決し、「将来のリリース」まで待ってくださいと放置しない大きな理由です。

まとめ

多くの人や会社が私がここに列挙したようなものが重要だと気がついていると思いますが、多くの人々は上手くやっているとは言いがたいと考えています。知識と実行、この2つは後から見れば全く別のものです。こうしたアイテムを難しくすることは技術的な魔術や分析の能力ではありません。それよりも中途半端に満足せずより予期を目指す取り組む姿勢や志が重要です。PernixDataはより良くなろうと戦い続けており、それが製品に反映されていれば嬉しいです。

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

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

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

本ブログエントリーは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)