« 2015年8月 | メイン | 2015年10月 »

2015年9月

2015/09/30

VMworld2015 サンフランシスコより : Cloud Native Apps続き

みなさん、こんにちわ。またも一週間が経ってしまいました。

さて、伏線を張りっぱなしの記事は以下です。

今回の記事は前回のCloud Native Appsについての記事の続編です。

前回はVMwareはCloud Native Appsの受け皿として従来からのvSphereプラットフォームの拡張(vSphere Integrated Container)と全く新しいPhotonプラットフォームの2つで対応していくというビジョンを発表したというところまでお伝えしております。こちらの例えですね。

4

この喩えが優れているのは仮想マシン(乗客)とコンテナ(貨物)の両方をホストできる飛行機として、vSphere、コンテナ(貨物)専用としてPhotonプラットフォームを上げている点はもちろんですが、いずれも飛行機としての基盤は同じ、すなわち、vSphereもPhotonプラットフォームもいずれも共通の基盤をベースとしており、NSX、VSANなどVMwareの優れたイノベーションはいずれのプラットフォームでも利用できるということです。それぞれを詳しく見ていきましょう。

vSphere Integrated Container(VIC)

VICを利用すると変わることは何でしょうか? VICはContainerとVMの垣根をなくす技術の連合軍だと思うのが良いと思います。では、ContainerとVMの垣根とは?前回の記事にもありますが、以下のとおりです。

  1. ワークロードの起動が遅い
  2. ワークロードの統合率が良くない
  3. ワークロードの構成が不便
  4. 管理者が手軽にワークロードを作り出しにくい

起動が遅い点についてはInstant Clone(旧Project Fargo)によって克服ができました。統合率が良くないという点についてはPhoton OSという非常に軽量なOSを利用することでこれを克服しています。Photon OSは25MBしかないOSで、これがインスタントクローンで瞬時に複製されますので、統合率にも優れ、さらに起動のスピードも後押しします。これで、1と2がカバーされています。

ワークロードの構成が不便という点はVirtual Container Host(VCH)というものを用意しています。これはDockerエンジンと同じコマンドセットを理解するLinuxベースの仮想マシンです。開発者はLinux上でDockerエンジンを実行して様々なコマンドセットを利用してワークロードを自動的に構成しますが、VCH上で全く同じコマンドを実行することが出来るようになっています。

6

開発者から見ると今までと同じフレームワークで開発環境を展開できるようになっているので、3つ目の問題が完全に解決するだけでなく、4の問題は消滅します。つまり管理者はワークロードの構成にタッチする必要がなくなり、従来通りVMとしてContainerを管理できるようになるわけです。

Photonプラットフォーム

さて、もう一つのPhotonプラットフォームについては貨物専用機なのですから、ESXをベースとしながらも、不要なものを削ぎ落としたものです。飛行機で言うと客室のシートやギャレット、手荷物用格納スペースなどに当たりますが、ESXからマイクロサービスで冗長化されているCloud Native Appsには不要なHAやFT、それからVDP、SRMなどの可用性機能、マイクロサービス内で負荷分散されているため、不要になるvMotion、Storage vMotion(もちろんDRS/SDRSも)なども削ぎ落とされています。共通してみえるのはAuto Deployなどぐらいでしょうか。ここまで徹底的にダイエットした上に、更に上で動作するのは先にも出てきたPhotonOSをベースとしたワークロードです。vCenterでは10000VMまでの仮想マシンを管理できますが、Photon Platformではそれを遥かに超える数のワークロードを管理することができるそうです。

7

APIについても幅広くサポートされており、開発者は様々なフレームワークを通して開発を行えるようになっています。(上の図ではCloud Foundry、Kubernetesのコマンドでアクセスしている例が出ています。Kubernetesについてはこちらもご参照ください。)

vSphere Integrated Container/Photon Platformはいずれもプライベートベータからスタートしていくとのことですので、ご興味のある方は是非お問い合わせください。

ようやくVMworld 1日目の伏線を回収し終わりました。。。さて、2日目の伏線も回収しに行きます。(来週にでも・・・。)

Stay Tuned!

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

2015/09/28

PernixData FVPで実際のSQLのワークロードを高速化

本ブログエントリーはPernixData社のシステムズエンジニアであるPeter Chang氏のブログ記事を翻訳しています。 Peter氏はネットワールドのプリセールス活動をサポートしてくださっている担当エンジニアでもあります。

本記事の原文はAccelerating Real World SQL Workloads with PernixData FVPで閲覧可能です。

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

様々な高速化ツールをIometerや他の実際のパフォーマンスを再現するツールを使って検証するのもおもしろいことです。ですが、このシリーズでは本稼働環境で実際に実装されている標準的なエンタープライズアプリケーションにおけるグラフを投稿していこうと思っています。今回はMS SQLサーバです。

利用している環境はDell M620ブレードサーバが8ノードあり、それぞれESXi 5.0 Update 2がインストールされています。ネットワークは10Gbで、ストレージとはFCで接続されています。バックエンドのストレージ装置は大体250本(FC, SAS, SATAのディスクが組み合わさっています)のスピンドルでこうせいされており、だいたい35,000~40,000IOPSぐらいの性能を提供できます。PernixData FVP 1.0が400GBのIntel S3700 SSDドライブを各ホスト1本ずつで構成されており、200台にちょっと届かないぐらいの仮想マシンがWrite-Back(WB)と冗長化のレプリカを2つで構成されています。特定のワークロードのみを選んで高速化することもできたのですが、FVPはクラスタ内のすべてのフラッシュをプールし、冗長性を提供できる(ですから、もっと容量の大きな安いMLCフラッシュドライブも利用できます)ので、ほとんどすべての仮想マシンを高速化することにしました。しっかりとどの仮想マシンがフラッシュを使うのか選択する場合ほど仮想マシン毎のパフォーマンスの向上は大きくありませんが、こうすることで少ない数のアプリケーションだけでなく、すべてのアプリケーションがメリットを受けることができます。

サーバ名はそれぞれどんなアプリケーションがメインで動いているかをわかりやすくするために変更してあります。

MS SQL Server 1

概要: SQL Server 2008R2 Stdが動作しているWindows Server 2008R2 Std

このSQLサーバはOracleのPeopleSoftの複数の開発/検証環境のバックエンドとして動作しており、様々なデータベースが格納されています。パープルのラインはデータストアのレイテンシを表しており、低い時は2ミリ秒ととても良いのですが、悪い時は16ミリ秒とさほど良いとは言えない値で変動しています。オレンジのラインは一貫して1ミリ秒未満をたもっています、そしてブルーのラインはー2つのWriteのレプリケーションを含めたー仮想マシンから見た際の実行レイテンシを表しており、1.5ミリ秒あたりを推移しています。このグラフは午後の1時間の時間範囲でのものであることに注意してください。バックアップ時の集中時の後の数時間はほとんどこのようなパターンです。夜間のSQLのバックアップはフラッシュ内にキャッシュされており、バックアップを高速化することができるのです。

レイテンシ:

Fig288SQL Server 1のデータストアレイテンシ 1時間

比較のため、以下に別のアプリケーション層や「ファットクライアント」やブラウザベースのクライアントなどを含む多くのアプリケーションのためのSQLサーバのレイテンシのグラフをお見せします。

MS SQL Server 2

概要: SQL Server 2008R2 Stdが動作しているWindows Server 2008R2 Std

上の例と同様に、データストアのレイテンシは2~3ミリ秒ーとてもいいーと13~20ミリ秒の間を行き来しています。65ミリ秒というところもありーとても悪いーです。しかし、フラッシュのレイテンシは一貫して1~2ミリ秒の間にあり、実行レイテンシもーWriteのレプリケーションを含めてもー1.5~2、時々のスパイクがあっても悪くとも10ミリ秒未満です。スパイクが発生しているときはキャッシュされていないデータを後ろのデータストアに読みに行っていることが考えられます。

レイテンシ:

Fig289SQL Server 2のデータストアのレイテンシ 1時間

上の例は中規模のエンタープライズでの本番環境の実際のMS SQLサーバのワークロードです。各々のESXiホスト上の小さなフラッシュとPernixData FVPを活用して、どれだけ環境が改善するかをよく表しています。これらのグラフは営業時間の終わりぐらいに取得されたもので、短時間に多くの従業員が一斉に環境にアクセスする日中では同程度か、更に大きな改善がみられたことを付け加えておきます。大きなメリットはレイテンシが定常的に高くなり長時間それが続くバックアップウィンドウ中も続いています。この実装のあと、レイテンシが高いのは他の2つのクラスタにある高速化されていない仮想マシンだけになりました。できれば来年にもこれらのクラスタをFVPで治療することを考えて欲しいところです。

さて、次も他のエンタープライズアプリケーションの実装を投稿していきます。お楽しみに。

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

2015/09/24

VMworld2015 サンフランシスコより : Cloud Native Apps

みなさん、こんにちわ。帰国後バタバタとしており、うっかりと全く記事を更新できないまま時間が立ってしまいました。すいません、伏線を張りっぱなしで回収できていない状態です。

さて、伏線を張りっぱなしの記事は以下です。

今回の記事はDay 1の記事の中で残してきたCloud Native Appsについての記事です。

なぜ今Cloud Native Appsなのか?

「Ready for Any」、「One Cloud, Any Application, Any Device」が今回のVMworldのテーマですから、Any Applicationに対してReadyになるために、VMwareがこれまでに得意としてきた2nd Generationのアプリケーション(語弊を恐れずに言うとレガシーなアプリケーション)だけでなく、クラウドで動作する前提でコーディングされた3rd GenerationのアプリケーションへもReadyにならなくてはならない、ということになります。様々な記事で2ndと3rdの違いが表現されていますが、もっとも大きく異なっているのはその思想だと思います。

この思想の違いを最もよく表していると現地のセッションでもよく紹介されていたのがこちらです。

Vcloudopenstackpetsandcattle1

2nd Generation

  • ペット(≒仮想マシン)に名前をつけてかわいがる
  • 愛情を注ぐべき対象で、しっかりと面倒を見る(しっかりと運用管理する)
  • 病気になったら治す(障害が起きたら復旧する)

3rd Generation

  • 家畜は名前ではなく、個体識別番号をつける
  • 家畜同士はほぼ同等として取り扱う(特別に特定のVMをかわいがるなどはしない、フレームワークで自動的に運用管理される)
  • 病気になったら別の家畜を使う(復旧しないで捨て去る)

このように根本的な思想が異なっていますから、3rd Generationの思想には特定の家畜を長生き(データ保護)、大事(高可用性)にしようという考え方はありません。我々も複数のサーバを冗長的に構成し、サービスとしての可用性をあげようと考えるケースが有りますが、3rd Generationのアプリケーションは常にこの考え方を採用しています。

マイクロサービスアーキテクチャ

Microservicearchitecture

3rd Generationのアプリケーションはマイクロサービスアーキテクチャと呼ばれるアーキテクチャを採用しています。VMを守るのではなく、アプリケーションをファンクション単位でサービス(マイクロサービス)に分解し、それぞれのサービスで可用性を担保するのです。

3

マイクロサービス同士はAPIで連携しており、APIさえ互換性が担保されればアプリケーションが起動中にマイクロサービスを入れ替えてしまうことも可能です。つまり、クラウドネイティブなアプリケーションはマイクロサービスごとに完全に独立した開発体制を敷くことが可能なのです。日々アプリケーションのあちこちで新機能追加、修正を行うことができるため、従来のようにアプリケーションのリリースサイクルに従うことなく迅速にアプリケーション開発が行えるのです。すぐに本番環境からユーザーのフィードバックを受けることも出来るため、トライアンドエラーしながらどんどん優れたアプリケーションに昇華していくことも出来るのです。これが「家畜」をつかってアプリケーションを構成するメリットです。

なぜ仮想マシンでは不向きなのか?

逆に考えてみましょう。様々なマイクロサービスはその可用性を担保するために多くの冗長構成をとっています。単一のクラウド内でも負荷分散やデータ保全のために分散構成をとっていますが、近年はクラウドのリージョンをまたいでそれを行うことも多くなっています。非常に多くのワークロードが必要となります。仮想マシンをワークロードの受け皿に使う事もできますが、仮想マシンを利用するにあたって不便に感じるところが出てきます。

  • ワークロードの起動が遅い
  • ワークロードの統合率が良くない
  • ワークロードの構成が不便
  • 管理者が手軽にワークロードを作り出しにくい

などが挙げられます。この辺りについては昨年のVMworldの後の記事にも記載していますのでご参照ください。

昨年発表されたProject Fargo(インスタントクローン)によってワークロードの起動スピードについては十分に解消されました。また、統合率の問題についてはPhoton OSと呼ばれる軽量のLinuxを用いることで十分に解消されています。また、構成の不便さや管理者と開発者の権限の問題も新たなやり方で解消されてきています。

VMwareのCloud Native Apps 2つのプラットフォーム戦略

さて、ようやく本題にたどり着きました。VMware社はこの新たなアプリケーションに対して2つのプラットフォームで「Ready」になっていくことを発表しています。

4

VMとContainerを乗客と貨物に例えて、乗客も貨物も運べるプラットフォームとしてvSphere(vSphere Integrated Container)を、そして貨物専用のプラットフォームとしてPhoton Platformをリリースします。これらの詳細については次回の記事とさせてください。

Stay Tuned!

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

2015/09/21

PernixData FVPのクラスタ化リードキャッシュ機能を理解する

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

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

本記事の原文はUnderstanding PernixData FVP’s clustered read caching functionalityで閲覧可能です。

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

2013年の8月、PernixDataがFVPをデビューさせた時に戻りますが、私にとっては何者にも代えがたいイノベーションがありました。サーバサイドでWriteを高速化させる能力(「Write Back」キャッシングとして知られています)と、そしてそれを耐障害性のあるやり方で実現できたことです。サーバサイドの高速なメディアを活用し、VMwareのクラスタリング(vMotion, HA, DRS等)のメリットをすべてそのままに、仮想マシンにマイクロ秒のレイテンシを提供します。すぐ近くで完了通知を返すことによる物理的な優位性を仮想マシンに提供しながら、コンピューティングとストレージのレイヤを別々にするというメリットを提供するのです。

しかし、このイノベーションの有効性によって、見落とされてしまいがちなのが、FVPがどのように高速化デバイスをクラスタ化し、Readのキャッシング(FVPの「Write Through」キャッシングとして知られています)のためのリソースのプールを作るのか、です。新規のそして既存のFVPのユーザーにとって、クラスタ化されたReadキャッシングの効率性を理解しておくことは非常に重要です。これは環境を改善していく非常に良い機会となるでしょう。そのようなために今後リリースされる予定のFVP Freedomエディションを利用していただきたいです。これは非常に優れた監視と表示の機能を持ち合わせています。Virtualization Field Day 5でアナウンスされたとおり、FreedomエディションはFVPのフリーエディションであり、Readのキャッシングのみと、最大で128GBまでのメモリ(RAM)しか使えないといった、ちょっとした制限がかかっています。

適切なやり方でのReadキャッシングの力

Readキャッシング自体は有効なパフォーマンス改善の方法と理解されていますが、一過性のものであり、I/Oの対話の1方向しか解決をしてくれないと見られています。残念ながら、この見方では話の半分も理解していないことになります。よく悪く言われがちですが、このタイプのキャッシングはほとんど誰もが、そしていたるところで利用しています。あらゆるタイプのストレージ、ハイパーコンバージドソリューション、そしてDASに至るまでです。ちょっと掘り下げると、安直なソリューションだと気が付くでしょうし、どのようにそれが実装されているのか気になることでしょう。ですから私は以下のようにお話しています:

  • ストレージやハイパーコンバージド環境内のキャッシュサイズの調整ができない制限
  • 単一ホストのサーバサイドソリューション(vMotionのような操作で有効性を失う)
  • 仮想マシンやワークロードを理解できない

既存のソリューションは上のような安直さを抱えています。しかし、上記の3つを欠いては本当に効率的にはReadキャッシュを提供できません。FVPのアーキテクチャはこの3つ全てを解決しています。中央のストレージが最も得意なこと、つまりデータの保管に集中させながら、パフォーマンスの層を素早く適応させていく事ができるのです。

FVPは高速化層のサイズを自由に選ぶことができます。これだけで非常に大きな結果につながります。例えば、現在のNVMeベースのフラッシュカードは2TBの大きさです。そして、近い将来劇的に大きくなる予定です。10ノードのクラスタが20~40TBもの高速化層でたった50TBもの永続ストレージを高速化できることになるのです。ハイブリッドストレージは数百GBのフラッシュで同じ50TBのストレージと相対しなくてはなりません。そして、アレイコントローラーにはこれが一気に注ぎ込まれることになります。ネットワークやストレージスタックをへて流れてきたI/Oがようやくキャッシュデータになり、新しいブロックが入ってくるとすぐにフラッシュから廃棄されてしまうのです。

他のホストサイドのキャッシュソリューションとはことなり、FVPはそれぞれのホスト上の高速化デバイスを集約し、プールのように扱うことができます。ワークロードは積極的にvSphereクラスタ上のホストを移動します。それらのワークロードは軽量なプロトコルを用いてプールから(ネットワーク越しに)キャッシュの内容を取得することができます。従来、vMotionのようなイベントが発生すると、ホストベースのキャッシュはデータを再度バックエンドのストレージから、従来のプロトコルを用いてストレージスタック全体からキャッシュを再構成する必要がありました。

FVPは仮想マシンが見えています。これはそれぞれのキャッシュブロックがどの仮想マシンのものなのかーどこから来て、どこへ行くのかーを理解しているという意味です。そして、数多くのキャッシュの一貫性を保持する方法を備えています。(詳しくはFrank Dennemanの記事 キャッシュの汚染の解消) 従来のやり方でのキャッシュ層の提供は全くと言っていいほどそのブロックが何に紐付けられたものなのかということを理解せずに行っています。必要な情報はブロックがホスト上のHBAを通り抜けた瞬間に消え失せます。このような構成は最も広く利用されているものですが、実際の環境でのシナリオを見落としているのです。1台、もしくは複数のやかましいご近所仮想マシンが簡単に汚染してしまい、キャッシュ内の他の仮想マシンが利用すべきホットブロックを強制的に廃棄してしまうのです。結果として自然に導き出されるのは従来のアプローチではパフォーマンスの予測はできないということです。

どのように動作しているか?

FVPのクラスタ化Readキャッシュアプローチの背景にあるロジックは非常にしっかりしており、効率的です。仮想マシンのキャッシュされたReadはクラスタに参加しているどのホストからでも習得が可能です。これによってクラスタ内のどこに仮想マシンがいたとしても関係なくキャッシュを活用できるのです。Frank DennemanのFVPのリモートキャッシュアクセスという記事がこの詳細を解説しています。

チャートの調整

今回はReadキャッシュのメリットをFVPのチャートから理解しようとしていますので、カスタムビューを作成しましょう。これによってRead I/Oに完全にフォーカスし、並行して発生しているWriteのI/O活動に惑わされることはなくなります。

Fig282

「Custom Breakdown」を利用した際に、標準の「Storage Type」の表示でReadとWriteに利用されているのと同じ色が利用されますが、今回はリソースタイプを指定したReadのみを選択します。標準の「Storage Type」表示とカスタム表示で気持ちを切り替えてください。

Fig283オフロードを見る

よく設計されたあらゆるストレージシステムの目的は適切なパフォーマンスをアプリケーションに提供することです。FVPを利用していると、I/Oはストレージからサーバサイドの高速化層にオフロードされます。Readのリクエストは仮想マシンに高速に提供され、レイテンシが削減され、アプリケーションのスピードが上がります。

財政的な投資の観点からはI/Oの「オフロード」のメリットを忘れてはいけません。もしくは、言葉を変えると高速化層から提供されるReadのリクエストです。FVPを利用すると最終的なストレージ層であるストレージ装置、アレイコントローラー、ファブリック、そしてHBAからオフロードされるのです。つまり、もっと現実的なバックエンドストレージを選ぶことができます。ヒーローナンバーのショーケースはこのオフロードをうまく集計してくれます。

Fig284

Network acceleration Readを見る

他のホストベースのソリューションとは異なり、FVPはvMotionやDRS、そしてHAのような活動と共生することができ、バックエンドのストレージからキャッシュを再構成するようなことを強要することなくシームレスに動作します。以下は3つの本番環境の仮想マシンからくるReadのI/Oの例です。キャッシュされたReadについてリモートホスト上の高速化デバイスへアクセスしています。

Fig285レイテンシがリモート高速化デバイス(グリーンのライン)から提供されることによって、低く保たれていることを確認して下さい。

リードのキャッシュがどのぐらいうまく動作しているか?

FVPで設定されているWriteポリシー(Write Through または Write Back)によらず、キャッシュは同じ方法で行われます。

  • すべてのバックエンドのストレージへReadリクエストはデータがストレージから取得されたタイミングで高速化層に配置される
  • すべてのWrite I/Oはストレージに書き込まれたタイミングでキャッシュに配置される

ですから、ReadのI/Oが高速化層から提供されない場合、以下のうちの3つのどれかであると簡単に結論付けられます。

  • これまでに一度もリクエストされたことのないブロックのデータ
  • FVP導入前に書き込まれたデータで、キャッシュにのっていなかった
  • 一度はキャッシュに保持された(ReadまたはWrite経由で)がキャッシュサイズの問題で廃棄された

最初の2つの場合、ワークロードの特性を反映することになりますが、最後のものは設計上の決断ーキャッシュのサイズーによるものです。FVPでは、キャッシュ層を構成するためにどのぐらいの大きさのデバイスにするかを選ぶことになります。ですから、どのぐらいのメリットを得るのかということを決めることになります。キャッシュのサイズはパフォーマンスに大きく影響します。以前のデータを廃棄して新しいデータのためのキャッシュの容量を確保するというプレッシャーが小さくなるからです。

Readキャッシュの利用量を可視化する

FVPのメトリック計測がモノを言う部分です。記事の前の部分で「Custom Breakdown」表示を見た際、簡単にどれだけのReadが高速化層から提供されたのかということを見ることができます。ほとんどのRead(3500IOPS以上が継続)がこのフレーム(1週間)ではバックエンドのデータストアから提供されています。

Fig286

さて、別の環境のべつのワークロードと比較してみましょう。以下のイメージは1日のうち、大部分のデータが高速化層から供給されていることを表しています。60MBpsものスループットのRead I/Oのうちほとんどはストレージ装置に一度も触れません。

Fig287

Readキャッシュサイズを評価する際に、私が「Custom Breakdown」を利用するのがとても大好きな理由がこちらです。FVPがReadをオフロードどれ位しているかということがわかるだけではなく、すべてのストレージからオフロードできた"かもしれない"Readも見つけることができるのです。どのぐらいのオフロードが発生するかということをみることができ、それによってどのぐらいの層のサイズが必要か、どのぐらいの仮想マシンがその層を利用できるかということがわかるのです。

ヒット率もあらゆる時系列上のポイントでどのぐらいのReadが高速化層から供給されているのかということを%で表します。これもキャッシュのヒット率が低い場合には非常に有効な方法ですが、もっとよく見てみたい場合、「Custom Breakdown」を利用し、さらなる文脈やどれだけのデータがキャッシュとバックエンドのデータストアから来ているかを調べます。廃棄率も廃棄率が継続的に高いようであれば重要な情報です。しかし、廃棄率が低くても何度もキャッシュデータを廃棄しており、影響がある場合もあります。ですから、「Custom Breakdown」がReadを評価する際のお気に入りのツールなのです。

多くのReadがバックエンドのデータストアから来ており、キャッシュからではない場合、どのようにすればよいのでしょうか? 例えば500の仮想マシンがほんの数GBの高速化層で動作していることをイメージしてください。キャッシュはすぐに流れ去ってしまい、メリットを出せる喉の効果はありません。高速化リソースとしてとても少ない総量のメモリ(RAM)でFVPを利用しようとしているときには2つの効果的な方法があります。1.) キャッシュのサイズを増やす 2.) 高速化に参加させる仮想マシンの数を減らす。いずれの方法も同じことをやろうとしています。高速化した仮想マシンにもっと大きなキャッシュサイズを割り当てようとしているのです。キャッシングのレイヤがアクティブなデータ(「ワーキングセット」とも)のうちほとんどを格納できるように私用という考えです。FVPではサイズの調整や仮想マシンの追加は非常に簡単に行えます。

ワーキングセットのサイズがわからないって? PernixData Architectをお待ちください!

まとめ

FVPでReadキャッシングを計画しているとしたら、そして最大限のオフロードを実現しようとしているのなら、クラスタ化されたReadキャッシングによって最高のパフォーマンスを得られます。FVPに実装されているクラスタ化されたReadキャッシュはアーキテクチャ上からどのように設計するかという議論や、どれだけのコストがかかるのかという議論を変えてしまいます。Writeのバッファリングを行える完全版のFVPと一緒にゲームを完全に変えてしまいます。

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

 

2015/09/18

なぜなに Data Domain - 第七回 - Data Domain をファイルサーバにできますか?

Dd_1

 

皆さんこんにちは。

 

Data Domain の時間がやってまいりました。

 

Data Domain の担当を行っているとお客様から色々なご質問を頂きますが、今回ご紹介するご質問はこれ!

  

Data Domain をファイルサーバのように使用したいです!

 

75

  

似た質問に、「ファイルサーバのコピー先として Data Domain を使用したい」等があります。

 

DD Boost (第四回を参照ください) を使用しない場合は、Data Domain へのアクセス方法は CIFS や NFS になることがほとんどです。

 

ファイルサーバも CIFS でアクセスすることが多いので、Data Domain をそのように使用したくなる気持ちもわかります。よ~くわかります。

ファイルサーバと同じように使用出来て、保存した瞬間に重複排除で容量削減!!!もう保存先の容量を気にする必要もないという夢のような話ですよね。

 

ですが、Data Domain はバックアップデータ専用の重複排除ストレージです。残念ながらファイルサーバのようには使用できません。これから Data Domain をファイルサーバのように使用してはいけない理由をご紹介致します。

 

 

1. Data Domain への同時接続数には制限があります。

 

下の表をご覧ください。Data Domain への最大同時接続数を表にしてみました。エントリーモデルである DD160 や DD2200(mini) は同時に読み取れるストリーム数は 4~6 しかありません。同時書き込み数も 16~35 と決して多くはありません。

 

71

 

数人が Data Domain 上のファイルを開いていたら他の人は Data Domain にアクセスすることが出来なくなってしまいます。

これではファイルサーバとして使用することは出来ません。

 

  

2. Data Domain は細かい大量のファイル操作が苦手です。

 

Data Domain は大きなファイルを書き込みすることは得意です。それこそ、バックアップデータのような。

ですが、大量のファイルを書き込みすることは苦手です。

 

Data Domain はファイルを書き込みする際に重複排除処理の他にファイル情報も処理します。ファイルのパスや属性値などは通常のファイルサーバも持っていますが、Data Domain はその他にファイルを復元するためのポインタ情報も持ちます。

つまり Data Domain は通常のファイルサーバが行う処理に加えて「重複排除」「ポインタ取得」という処理を行っているため、大量のファイルを保存しようとするとパフォーマンスが非常に悪くなります。

 

大量のファイル、良くない…

73

 

 

少量のファイル、良い!!!

74


 

 

上記の処理はファイル単位に行われますので、同様に細かいファイルの場合もパフォーマンスが下がってしまいます。

 

 

3. Data Domain はファイルの読み込みも苦手です。

 

2つ目の理由と似たような話ですが、ユーザが Data Domain 上のファイルを参照(読み込み)する場合、Data Domain の中ですがファイルの複合処理が実行されます。その処理分、読み込みも遅くなってしまうんですね。そのため、Data Domain は最大書き込み数よりも読み込み数の方が少なく設定されています。

 

72_3

 

今回の内容はここだけで良いかもしれません。

簡単に言うと、Data Domain は読み込み / 書き込み時に通常のファイルサーバよりもたくさん処理を行うため、頑張ってもパフォーマンスが出ません。

また Data Domain へ同時にアクセスできる数が限られているため、ファイルサーバとしての使用に耐えられない可能性が高いです。

 

大容量ファイルの書き込みに特化していると言っても良いと思います。

 

 

 

で、終わってしまうと Data Domain 使えないね、で終わってしまうので少しだけ続けましょう。上記については、裏返すと上の3つの制限に引っかからない、もしくは引っかかっても問題のない場合にはファイルサーバのように使用することができます。

・同時にファイルを読み込まない。 

・1日一回ログファイルを保存する等の用途として使用。

・パフォーマンスなんて飾りですよ!的にパフォーマンスが遅いのを気にしない。

 

既にファイルサーバとしてどうなの、という感じですが、実際は Data Domain をファイルサーバとして使用しようと思えば出来てしまいますので、そこは自己責任でお願いします。

 

以上、今回は やってはいけない Data Domain というお話しでした。

 

 

担当 齋藤・吉田

 

- 過去記事 -

 

2015/09/14

時間軸 : レイテンシの指標

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

本記事の原文はTime Scale: Latency Referencesで閲覧可能です。

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

スピードがもっとも重要な世界において、私はレイテンシは相対的であると気がついてきました。言い方を変えると、あるものがどれだけ速かった、速いのかということを理解するためには、一定尺度、時間のものさしが必要だということです。

非常に頻繁でレイテンシの低い取引がこのビデオ(訳注:証券取引のリアルタイム性に関するビデオ)では行われています。ミリ秒がこのゲームの名前です。例えば、2秒のロスをしてしまうと、数百万ドルの損失の話になったり、それによって倒産の危機から免れたりとった具合です。

この例で、2ミリ秒をあなたはどのように感じますか?あなたは2ミリ秒と3ミリ秒の違いを区別できますか?私は我々人間が何が早くて、何が遅いのかということをフィーリングで決めていることを素晴らしいことだと思います。では、実際にどのようにフィーリングを図るのでしょうか?大抵の場合、(ベースライン)と比較して、それが本当に早いか、遅いかを決定しなくてはなりません。私はそれを我々が計測しようとしているレイテンシの結果や効果としてしばしば言われていると思います。レイテンシの低い取引では、効果や結果は非常に巨大なものになることがありますし、そこにはまだ過去にはなっていないという一定のしきい値があります。しかし、この閾値も競合からのプレッシャーによってどんどん低くなっており、チャレンジングなものになっています。これは効果の積み重なりが良いのか、悪いのかを判断するために、レイテンシの指標を定期的に図るのが重要だということです。

これはなぜ、人工的なワークロードを使って(パフォーマンスを計測し)、不明確な何が早くて遅いのかを調べる理由にもなります。一つだけのワークロードでテストを行う場合、バラバラのワークロードとそれらの間のやりとりの結果の積み重ね全体を表してはいません。もう一つの不明確な方法はエンドユーザーが早いと感じるか、遅いと感じるを調べるだけで決定を下してしまうことです。エンドユーザーが何を考えているかを見ることは興味深いことですが、システム全体を見る計測の方法としては正確な方法ではありません。(おそらくはプロジェクトで)すべての仕事を終えてから効果を図るのがより良い方法です。これは明らかに計測の方法としては複雑です。しかし、もし、私が時間軸の指標と呼んでいるものに従うのであれば、レイテンシの結果を全体としてみることに集中するだけの価値があります。

歴史的に我々が速いと認めているものと地平線を比べることは興味深いだけではなく、ベースラインとして重要です。適切なレイテンシの計測はスピードや高速化の完全な効果を感じるためにはとても重要なのです。

ジョージア州のアトランタからカリフォルニア州のサンフランシスコまで、桃を運ぶ旅を例に取りましょう。ルートは2つから選べます。ひとつは3日の旅程で、もうひとつは6ヶ月かかります。この場合、もしもあなたが景色の良いルートを通りたいと思ったら、ものすごく時間がかかるのです。もしも桃がなければ長いルートを選びたいことでしょう。しかし、6ヶ月かかってしまったら桃の香りはサンフランシスコにつくまでに掛けた時間の分だけ、非常に悪いものになります!!このような実際時間軸の例を用いて、その効果の違いを理解することができます。さて、なぜ私は3日と6ヶ月を例に取ったのでしょうか? 大抵のソリッドステートディスクは平均的には100マイクロ秒ぐらいのレイテンシで動作します。これと比べ、標準的な回転するハードドライブは5ミリ秒ぐらいです。もしこれら2つの劇的な時間の差を比べるために引き伸ばしたら? SSDは3日で、標準的なハードドライブは6ヶ月になるのです。どうですか?こうなればこの2つのメディアの違いを本格的に理解できるようになりますし、単純な決定で巨大な利益の差になるということを理解できます。さて、もっと違うレベルでみていきましょう。桃をのせたトラックの旅の時間が3日ではなく6分で、もしくは更に縮まって40秒になったとしたら?今日6分は標準的なDRAMで実現することができます。しかし40秒もインテルとマイクロンが3DXpoint NANDを登場させたことで、さほど遠い話ではなくなっているのです。

もし、このレイテンシの値をデータセンタに適応することができれば、それが良いのか、悪いのか簡単に理解ができます。「もし、いまSSDを使ったら、明日には新しい3DXpoint NANDや、それよりも速い次の何かのような新しいレイテンシの閾値に対応するために全部を取り替えなくちゃならない」と思うかもしれません。すばらしいのは最新で最速のものを活用するために全てを取り替える必要はないのです。あなたの桃を運んでいるトラックはエンジンにターボブーストをつけるだけで良いのです。新しいトラックを買う必要はありません、適切なプラットフォームを選ぶということが重要になります。適切なトラックを最初に選んでいれば、パフォーマンスに関して、ベンダーのロックインを受けるということにはならないのです。

結論です。適切なベースラインがなぜ重要なのかをしっかりと理解してほしいと思っています。検証においてもこれを参照しながら、実際の環境でおこなうべきなのです。何が速いのかということはただのフィーリングではありません。我々は今回、本当のスピードがどのように感じられるのかということを理解しました。閾値をベースに原因と効果または結果を決めるべきなのです。明日には閾値は新しいイノベーションによって閾値が低くなるかもしれません。これは時間軸の指標が重要であるということの理由付けにもなります。指標がなければ、人々はまわりのものに慣れてしまい、アトランタからサンフランシスコまでの旅が40秒やそれ未満になるということもどういうことを意味するのかわからなくなってしまいます。今日、そして明日からのレイテンシのイノベーションにご注目を!そして、賢くプラットフォームを選びましょう!

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

2015/09/08

VMworld2015 サンフランシスコより : EVO SDDC

みなさん、こんにちは。すでに帰国しておりますが、General Sessionの記事の中で触れずに残してきた伏線を回収する記事を書いていきたいと思います。

General Sessionについての記事は以下です。

今回の記事はDay 1で発表されたEVO SDDCです。

EVO SDDCはEVO:RAILと同様のハイパーコンバージドインフラストラクチャですが、EVO:RAILとは異なり、VMwareのOEMパートナーからハードウェアにインストール済みのアプライアンスを購入するのではなく、EVO SDDCパートナー(現時点での発表ではDell, VCE, QCT, Fujitsu)からEVO SDDC対応のハードウェアを購入し、EVO SDDCのソフトウェア部分はVMwareのパートナーから購入することになります。

EVO SDDCに含まれているコンポーネントは以下のとおりです。

20150908_12_51_42day_1_keynote_vmwo

vSphereそして、VSANはもちろん、EVO:RAILには含まれていなかったNSX、そしてvRealize Suiteも含まれています。EVO SDDCは旧称EVO:RACK、ラックスケールのアーキテクチャを有する非常に巨大なデータセンタインフラです。こうしたインフラでは後から動的にそして、自由自在にネットワーク切り出して利用するためにもNSXはキーとなります。

一番上に記載されているEVO SDDC Managerはこれらのインフラとソフトウェアを統合管理するソフトウェアで、TOR(トップオブラックスイッチ)の構成まで全て自動で行うことができるようになっています。その効果たるや・・・!

20150908_12_52_28day_1_keynote_vmwo

なんとわずか、2時間でデータセンタを立ち上げられるとのこと。EVO:RAILも最初のVMの起動までに15分でしたが、スケールの大きさから考えると驚異的なスピードです。ラックあたりの性能値もコンバージドシステムである以上しっかりと保証! 以下が公表されていました。

20150908_12_53_41day_1_keynote_vmwo

1ラックあたり1000VMもしくは2000VDI! IOPSは2M+とのことです。なんだかよくわかりませんね。ネットワールドの社員は350人ぐらいですから、ネットワールド6社分!!余計意味がわかりませんね。とにかくすごいスケールのインフラが2時間で上がってくるわけです。

この巨大なインフラはマルチ用途で利用されます。ですから、このインフラを仮想的にラックにきる事が可能になっています。

20150908_13_12_31day_1_keynote_vmwo

せっかくラックをまとめて一つのリソースにしたのに、また仮想的にラックに分割するのは残念ですが(笑)あくまで仮想的なラックですので用途に応じて、そしてニーズに応じて柔軟に分割出来るようになっています。

20150908_12_54_31day_1_keynote_vmwo

もちろん、ハードウェアトラブルがあったとしても自動的にラック無いから別のリソースが払い出されますし、様々なシステムをこのレベルでリソース統合し、自動化することでインフラの稼働率を更に押し上げることが可能です。なにより、コンバージドシステムですから、メーカーが保証する構成でのソフトウェアのアップグレードなども自動で行うことが可能です。頭を悩ませていたローリングアップグレードの順番などの検証ももう過去のもの。Windowsアップデート並になってしまいます。

当社も以前からVCE社のディストリビュータとして国内展開を行っており、フルコンバージドインフラストラクチャの素晴らしさはよく理解していたつもりですが、TORも含めたネットワークの構成の自動化やNSXによるネットワーク部分の自動化が入ってきたことでよりTurn Key(鍵を回すだけ)のソリューションになってきましたね。

さて、次回はGeneral Session Day 1でもう一つ落としてきた伏線、CNA(Cloud Native Apps)についての記事を投稿予定です。 Stay Tuned!

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

2015/09/07

ワンちゃん、通勤ラッシュ、そしてストレージI/Oのベンチマーク パート2

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

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

本記事の原文はDogs, Rush hour traffic, and the history of storage I/O benchmarking–Part 2で閲覧可能です。

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

パート1の「ストレージI/Oベンチマークの歴史」では人工的なベンチマークは単純すぎて意味があるレベルでストレージのパフォーマンスを生成したり、計測したりすることは難しいというお話をさせていただきました。実際のワークロードを再現することは非常に簡単なことのようにみえるのですが、その実、非常に複雑で技術的、そして技術的ではない問題の双方をはらんでいるのです。

  • ワークロードの特性を測るために必要なのは推測です。正しい要素を観測していると理解して始めて、テストのためにシミュレーションが行えるのです。どんなツールを利用しているかよりも問題をどのように捉えているかが重要です。ほとんどのツールが不適切な値を表示しています。ストレージ装置はディスクアレイを監視するためには非常に優れたツールですが、仮想マシンやアプリケーションのパフォーマンスについては不完全なのです。
  • データセンタのパフォーマンスを理解するためには特定の問題に対する専門性の境界を超える必要があります。従来型のストレージの管理者はディスクアレイが見ているのと同じように世界を見ています。ブロック、LUN、キュー、そして転送プロトコルです。パフォーマンスについて聞いてみると、レイテンシ、RAIDのストライピングの効率性、そしてRead/Writeの取り回しなどの繰り返しのひとりごとを聞かされることでしょう。仮想マシンから見えているレイテンシについてはどうでしょうか?これについて言及されないことに驚かないでください。これは管理者の問題では無いのです。というのも、彼らのインフラストラクチャに対する視野はアクセスコントロールで制限されているからです。
  • フラッシュのようなテクノロジーを利用するソリューションを紹介するとき、言葉自体が大きく取り上げられ、テクノロジーはさほどでもありません。名前がすぐに早く、そして、スーパーヒーローのような品質を想起させてしまいます。素晴らしい業界のマーケティングによってこれがひとつの障壁になってきました。ストレージソリューションは、あとからFlashを利用するテクノロジーが登場し、周知の事実として過去の何よりもどんな場合も速いとされてしまったため、正しいテストをなされていないことがあります。単純化のために誤解もよしとしたのです。

パフォーマンスを評価するためにはインフラストラクチャ、ワークロード、そしてそれが動作しているソフトウェアプラットフォームをバランスよく理解する必要があります。これは非常に時間がかかりますし、正しいツールを見つけ出す必要がありますーが、大抵はみつかりません。パート1では実際のワークロードの特性は再現しにくく、クラスタ化されたコンピューティング環境では誤ったアプローチであると述べました。残念ながら、それだけでは済みません。他にもまだ考えなくてはいけないことが残っています。ストレージパフォーマンスの階層レイヤの特性や、そのレイヤ間をどのようにデータ移行させるかというロジックです。

ストレージパフォーマンスの階層化

ほとんどのデータセンターが複数の永続ストレージと様々な形のキャッシングとバッファリングでストレージのパフォーマンスを提供しています。人工的なベンチマークはこれらの階層に非現実的な動作を強要します。殆どの場合、これは理解ができない事態に陥ります。というのも、階層のサイズやデータのハンドリングはストレージベンダーによって検証を行う人にとって、あいまいか、分からないという状態にされているからです。我々にわかっているのはストレージの階層化はそれなりの形とサイズで確実に入っているというこということだけです。それは従来型ストレージのデータの先読みの技術であったり、ハイブリッドアレイであったり、PernixData FVPのような分離アーキテクチャであったり、ハイパーコンバージドソリューションであったりします。現実的にはこの階層化はあらゆる時に起こっています。

覚えておいてください。この環境をテストするためには2つの別々のアプローチがあります。

  • 最高のパフォーマンスの階層に全くI/Oデータが流入出していないことを保証して実施するストレージテスト
  • 最高のパフォーマンスに全てのI/Oデータが流入出していることを保証して実施するストレージテスト

いずれのアプローチがあなたにとって正しいものでしょうか?目的によってはどちらの方法が正しいこともあり、間違っていることもあります。さて、通勤ラッシュの例を再度取り上げましょう。

  • 電気自動車はたかだか航続距離が100マイルぐらいなので、嫌がる人がいるかもしれません。ですが、通勤が1日辺り30マイルを超えることが殆ど無い場合には?これをキャッシュやバッファの層だと考えてください。キャッシュの階層が非常に大きく、95%ものI/Oを捌けるとしたら、パフォーマンスの低い階層のストレージのパフォーマンスの検証にフォーカスする必要はなくなります。
  • 同じ車で、この車のオーナーが職を変え毎日200マイル運転するようになったとしましょう。そうなるとこの車はソリューションとしては非常に貧しい物になります。同様にストレージアレイ外20GBのキャッシュ・バッファの領域しか持っていないにもかかわらず、100TBの保存ストレージ領域があったとします。実際のストレージの領域上で動作しているそれぞれの仮想マシンは20GBのキャッシュ領域からだけではほとんどメリットを受けられない事になります。こうした場合はストレージの低い層のパフォーマンスを検証する方が良いです。

ストレージのすべての層からデータが読み出されることを想定した検証はどうですか?2つの負荷を一緒に走らせてみるのが理想的ですが、実際のデータがどの階層にあるのかということをシミュレーションすることは難しく、実際のワークロードでの振る舞いをどれだけ反映しているのかということを判断することも難しいです。これはキャッシュ層のサイズの不足がどれだけなのかということ判断できないということと、階層を隔離できないためです。このため、殆どの場合、このアプローチは皮肉な結果に終わります。 つまり、事故です。(訳注 : この検証はやっても意味が無い)

人工的なワークロードを生成して、そのワークロードのほとんどがWriteであった場合、簡単にバッファの上限のしきい値に引っかかってしまうことがあります。繰り返しになりますが、これはベンチマークはCPUサイクルのすべてを使ってWrite I/Oを生成するためで、現実的な時間の間隔を開けてくれるわけではないからです。非常に書き込みが多い環境であってもまったくもって現実とは異なっています。これが階層化ストレージソリューションで人口的なベンチマークを行う際の真実です。ほとんど現実の環境では起こりえないのです。

巨大なテストファイルを利用し、Read I/Oを人工的に生成しているような場合、このReadはキャッシュ層にヒットすることもあり、他の場合はパフォーマンスの遅い階層へとヒットします。それによって結果散在してしまいます。この結果のためにテストを長く走らせるということを行う場合もあります。ですが、問題はテストのやり方であって、テストの長さではありません。仮想マシンのワーキングセット(データが良く動いている量)を理解することが鍵で、環境に合わせてどのように懸賞を行うべきか翻訳すべきなのです。どのようにワーキングセットのサイズを決めるかって?これは将来の記事のために残しておきます。究極的にはこれは実際のワークロードの問題です。ですから、実際のワークロードを真似できる限り真似すればより良くなっていきます。

ストレージキャッシュへの格納と廃棄、全てのキャッシュは同じではない

ストレージソリューションのキャッシングのレイヤはありとあらゆる形や大きさになっています。しかし、どのようにそれが利用されるのかというのは簡単にはわからないルールに依存しています。とても重要な特性の2つの例として:

  • キャッシュ内にどのようにデータを置くか。「データ先読み」のアルゴリズムのようなものを利用しているか?その階層がバックエンドのストレージから読みだしたデータ以外に、Write-Throughキャッシングでもデータを読み込むのか?
  • キャッシュからどのように廃棄するデータを選ぶのか。階層は「先入れ先だし」(First-in-First-out : FIFO)を利用するのか、再長時間利用されなかったもの(Least Recently Used : LRU)を利用するのか、参照頻度が最も低いもの(Least Frequently Used : LFU)を利用するのか?または、廃棄に他のアプローチを利用するのか?

人工的なベンチマークはこれにうまく対応していません。ですが、実際のワークロードはこれに大きく依存しますし、本番環境では違いが出てくることになります。

他の検証の誤り

テストを行う際に十分な手がかりがない場合のために、以下にいくつかのストレージパフォーマンス検証においての典型的な誤りを列挙しておきます。

  • アプリケーションに可能な限り近くでテストを行っていない。こうした機能検証はアプリケーションが(そしてそれが動作しているOSが)実際のデータをどのように扱っているかをよりはっきりさせて行うべきです。
  • 検証時間が長い。(数時間に及ぶ)人工的なベンチマークから得るものはほとんどありません。大したことはわからないので、時間の無駄です。
  • ベンチマークツールのパラメーターを軽んじる(ただツールを動作させるだけ)。設定が重要です、そうでなければ全く別の結果が得られることになります。
  • 環境のRead/Writeの割合を間違う。割合をIOPSやスループットで計算していませんか?この2つだけでも別の結果が得られてしまいます。
  • ReadとWriteの環境内での典型的なサイズを間違う。どのようにI/Oのサイズを決めていますか?
  • ReadとWriteを2つの独立したものだとして検証する。実際のワークロードはそうではありません。ですからこれらを分けて検証する理由はありません。
  • ベンチマークによる最終「得点」だけを利用する。フォーカスすべきは検証の最中の振る舞いです。特にフラッシュのようなテクノロジーの場合、ガーベージコレクション技術や他のレイテンシがスパイクさせてしまうイベントなどに細心の注意を払う必要があります。このスパイクこそが問題です。

テストを行っている人々はしばしば検証の妥当性を争うあまり、検証方法や、このブログの記事で紹介しているような誤りが排除できるような標準を押し付けてきます。残念なことに、どんな状況においても、これはうまくいくことはまずありません。問題になっているのがあなたのデータであり、あなたのワークロードだからです。

人工的ベンチマークの良い利用方法

人工的なベンチマークや人工的な負荷生成器は意味が無いと思うようになってしまったかもしれません。そうではありません。実際、私はそれをよく利用しています。違うのは一般的な知識でいわれているような利用の仕方をしていないことです。本当のメリットは実際のワークロードをシミュレーションできないという事実を受け入れてからです。以下は非常に有用なシナリオ野内の幾つかです。

  • 定常的な負荷の生成。これは少ない数のシステムが負荷を生成しているような仮想環境の場合には特に有効です。環境を学び、トラブルを発見するのに役立ちます。
  • 小さなベンチマーク。本当に小さなワークロードのかけらで、テストや評価をしようという場合です。5秒から30秒ほどの長さですが、ほんとうに必要なものを見つけ出すことができます。I/Oが生成されている際に何が起こるかを観測するためで、絶対的なパフォーマンスを図ろうというものではありません。こちら(訳注:リンク先は英語原文)に良い例があります。
  • 独立したハードウェアコンポーネントの比較。新しいSSDと古いSSDと後k街を見るのに非常に良い方法です。
  • 大きなアーキテクチャの幅広い動きを理解するために利用する。

観測、学習、そして検証

意味のない状況を「検証」して時間をムダにしないために、vCenterやesxtopや他の方法で、統計を集める時間を作ってください。ベンチマークを走らせる前に、今あるワークロードをよく知るのです。例えば、もしもSQLのパフォーマンスを改善したいのであれば、いくつかの検証をシリーズとして作成するか、既存のSQL内で実行されているバッチジョブを変更してベースラインを確立して、振る舞いを観察するのです。負荷集中時や負荷が低い時間帯の両方でテストを行うと、それぞれで素晴らしい結果が得られます。このアプローチは私がコードのコンパイル環境を最適化する際に非常に役に立ったアプローチです。

まとめ

ストレージのパフォーマンス検証はディスクアレイの検証ではないという事実を忘れないようにしてください。あなたのワークロードがあなたのストレージアーキテクチャに対してどのように動作するのかという検証なのです。実際のアプリケーションはいつも事実を告げてくれます。このような答えを望まない理由は再現性がなく、正しく計測することが難しいということです。正しく検証を行う方法はアプリケーションのデマンドを正しく理解するための時間を費やし、それを環境に取り込むことなのです。

さて、やることはたくさんありますね。ハッピーテスティング!

Fig281

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

2015/09/02

VMworld2015 サンフランシスコより : General Session Day 2

昨日の記事に引き続き、サンフランシスコよりお届けいたします。

本日のGeneral Sessionはオープニングビデオのあと、EUCのSanjay氏が登壇して始まります。テーマは「Consumer Simplicity & Enterprise Security(コンシューマーの手軽さとエンタープライズのセキュリティ)」です。IDC2015年の発表やAirWatchのさらなる成長についてのマーケット情報が語られます。「まだブラックベリー使ってる人いる?あ、2人だけ?」という感じで、とても勢いに乗ってハツラツとしたプレゼンテーションです。

Sanjay氏は昨日の振り返りも兼ねて、仮想化(Compute)からStorage, NetworkingそしてManagementとSDDCを説明、その上で動く元して、デスクトップ、そして、それだけにはとどまらずモバイル、コンテンツコラボレーション、ID管理とEnd-User Computingが提供するものを紹介しました。ちょうどVMwareの歴史を紐解いてのプレゼンテーションで、途中に前CEOのPaul氏の名前も出てきていました。

20150901_090722

おどろくべきことにマイクロソフトのWindows Enterprise and SecurityのCorporate Vice PresidentのJim氏が登壇されました。VMwareはWindows10大好き!ということです。

20150901_091418

その後は、またも新技術! どうやって実現しているのか、これから調べていきますが、AirWatchで管理された物理Windows 10にApp Volumesを利用してアプリケーションをリアルタイム配信するデモも行われました。こちらはA2と呼ばれるTech Previewとのことです。

20150901_092224

また、AirWatchのIDに紐付いたポリシーとNSXのFWポリシーを連携させ、ユーザーごとの決めの細かいネットワークアクセス制御についてもデモが行われました。

続いて登壇したのは我らがMartin氏です。「アプリケーションこそがネットワーク」がテーマです。すでに様々なネットワークをまたがって構成されているアプリケーションが殆どになっており、そのため「構成・設定」、「トラブルシュート」、「セキュリティ」の課題があるこれを解決することができるのがネットワーク仮想化ということで、先日発表されたNSX 6.2についての紹介がなされました。中でも非常に興味深かったのは「Distributed Network Encryption」です。

20150901_094725

パケットの暗号化をESXi内で実装しているため、仮想マシン間の通信を暗号化できた上、アプリケーションには一切の変更が必要ありません。マイクロセグメンテーション(分散ファイヤウォール)も面白いユースケースでしたが、この分散ネットワーク暗号化も非常に強力なセキュリティのユースケースになりそうです。

この後CEOのPat氏によるプレゼンテーションもありましたが、こちらの内容については以下のセミナーでのお楽しみとさせてください。

VMworld2015 フィードバックセミナー
~VMworld2015の内容をいち早くお届け!~

昨日に続いて非常にライトな内容ですが、第2弾とさせていただきます。まだまだ更新していきます。Stay Tuned!

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

2015/09/01

VMworld2015 サンフランシスコより : General Session Day 1

本年もVMworldの現地で合間を縫って、出来る限り現地の雰囲気をお伝えしていきたいと思います。

現地での8月31日のゼネラルセッション、すでにYouTubeに映像が上がっておりますが、88カ国から23,000人以上が参加する盛大なイベントです。

20150901_09_44_37day_1_keynote_vmwoCo-PresidentのCarl氏の語るVMwareのITアーキテクチャは変わらずOne Cloud, Any Application, Any Deviceですが、One Cloudの部分、UNIFIED HYBRID CLOUD(統合されたハイブリッドクラウド)と銘打って、少しメッセージが変わってきています。いよいよ新たに構築中としていたCloudプロバイダーとしてのDNAと従来からのソフトウェアソリューションプロバイダーとしてのDNAが融合してきています。

その後はDirecTVのCEOが登場、ビジネスのスピードを上げるための一手としてSoftware-Defined Datacenterが必要ということでした。Huluなどのデジタル産業のプレイヤーと競合し始めている今、従来のビジネスドメインを守るためにも待ったなしということでしょうか。

その後はBill氏、Raguh氏と技術的な内容が続きます。EVO SDDC Managerなどもありましたが、中でも今回はこれでしょう!(EVOについては別で後ほどご紹介します。)

20150901_09_53_57day_1_keynote_vmwo

「vMotion based migration」ですって!! これまではReplication baseでしたが、ついにクラウドの間をvMotionで飛び越えるという機能が出てきました。もちろん、以前からvMotionがLong Distanceをサポートしたりしていましたのでおどろくべきことではないのですが、ここまで手軽にできた「隠し味のソース」はやはりNSXによる先進的なネットワーキング機能のおかげとのこと。

その後はEMCフェデレーションに最近参加することになったVirtuStreamのCEOが登壇します。この会社、PernixDataのユーザーとして知っていましたが、今回紹介されているμVMという技術も面白いですね。こちらは詳しく研究して以下のセミナーでも触れられればと思います。

VMworld2015 フィードバックセミナー
~VMworld2015の内容をいち早くお届け!~

最後は新CTOのRay氏とCloud Native Apps担当CTOのKit氏によるCloud Native Appsについて。こちらも盛り沢山ですので、後日こちらのブログでもご紹介していきます。

20150901_10_03_34day_1_keynote_vmwo

これまでにバラバラに様々なテクノロジーが紹介されてきましたが、本日はReady for AnyのApplicationsの部分が非常にわかりやすくまとまっていました。明日は順番的にAnyのDevicesの方かなぁ、なんて思いながら、まずは速報第1弾でした。

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