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

2016年3月

2016/03/31

なぜなに Data Domain 第九回 - DD Boost over FC で最速バックアップを体感してみませんか?

皆さんこんにちは。

Data Domain のお時間です。

 Dd

Data Domain とバックアップサーバの接続方法は色々ありますが、今回はその中でも一番スループットの出る DD Boost over FC について、前後編でお届けします。

 

DD Boost って何?という方はまず 第四回 Data Domain DD Boostでバックアップ性能を向上! をご確認ください。前回の記事の 第八回 Data Domain と Backup Exec バックアップパフォーマンス動作検証レポート では、DD Boost のパフォーマンスにも触れています。

 

Data Domain の接続方法は色々あるといいましたが、実際はこんなにあります。

 

・CIFS

・NFS

・VTL(FC)

・DD Boost(over Ethernet)

・DD Boost(over FC)

・DD Boost(Enterprise Applications)

 

これらの中で、最大のスループットを出せるテクノロジーが DD Boost です。DD Boost for Enterprise Application は少し特殊なので置いておいて、DD Boost over Ethernet と DD Boost over FC の違いはバックアップサーバとの結線が LAN か SAN か、というところになります。 

LAN はデータ転送時にデータ以外のオーバーヘッド情報が SAN より大きいため一般的には SAN の方が高速と言われています。DD Boost over FC は DD Boost over Ethernet よりも対応製品が少なく、情報も出回っていないことから今回社内の DD2200 を使用してやってみました!

 

今回は対応製品のひとつ、Veritas(旧Symantec) NetBackup で検証してみました。

 

 

まずは Data Domain の設定をします。

  1. 忘れてはいけません、バックアップサーバと Data Domain を FC で接続しましょう。


  2. 何はともあれ DD Boost を有効にします。

    008_2

     

  3. ストレージユニットを作成します。こちらは特に over FC 用の設定はありません。普通にストレージユニットを作成します。

    009_2

     

  4. over FC 用の設定を行います。
    [Server Name] は バックアップサーバが over FC で接続する時に指定する名前を入れます。今回は「dd2200-lab1-1」にしました。
     [Server Name] は NetBackup の設定で使用しますので忘れないようにしましょう。
    [DD Boost Access Group] は over FC でデータを転送する Initiator を設定します。

    010_2



Data Domain の DD Boost over FC 設定が完了しました。
次はバックアップソフトである、NetBackup の設定です。
 

 

次は NetBackup 側の設定です。

  1.  NetBackup サーバが Data Domain のホスト名を名前解決できるように hosts もしくは DNS に Data Domain のホスト名を登録します。NetBackup の基本ですね。ここで登録するホスト名は、Data Domain 側で設定した [Server Name] です。

  2. NetBackup に DD Boost プラグインをインストールします。
    DD Boost プラグインは EMC サイトよりダウンロードします。バージョンの互換性がありますので、Data Domain の DD Boost 互換性リストから互換性の確認をしましょう。

    まずは NetBackup のサービスを停止しましょう。サービス稼働中はプラグインのインストールはできません。

    002
    次にダウンロードした DD Boost プラグイン tar.gz ファイルを展開します。

    003


    DD Boost プラグインをインストールします。

    004


    最後は忘れずに NetBackup のサービスを起動しましょう。

    005

     

  3.  NetBackup の管理画面から Data Domain を登録します。
    実際に NetBackup で DD Boost を使用する場合は、Storage Server, Disk Pool, Storage Unit の設定が必要ですが、「
    Coufiguration Disk Storage Server」 という項目からウィザードですべて設定が可能ですので、今回は「Coufiguration Disk Storage Server」から設定を行います。

    006_2

  4. NetBackup では DD Boost を使用する場合 Data Domain は Stoage Server として登録します。

    007


    Data Domain の情報を設定します。
    [Storage server type] は「DataDomain」を入力します。DD Boost を使用してData Domain へバックアップする時の決まり事ですね。間にスペースは入れません。
    [Storage Server name] は先ほど Data Domain 側で設定した [Server name] を入力します。が、 over FC でバックアップしますので [Server name] の前に「DFC-」を入れます。これは over FC の時の決まり事です。
    [Select media server] は Data Domain へデータを転送する(FC 接続している)NBUサーバを指定します。
    [User name], [Password] は 保存先の Data Domain ストレージユニットへのアクセス権のあるDD Boost ユーザ情報を入力します。

    011_3



    入力した情報に間違いがなければ以下のように Storage Server(Data Domain) の登録が完了します。

    012


    Data Domain の登録が完了しました。

  5. 続けて Disk Pool の設定を行います。
    [OpenStorage (DataDomain)] を選択します。NetBackup では DD Boost 等、サードパーティのストレージ機能と連携する場合は OpenStorage という機能を使用します。

    013
    先ほど登録した Storage Server を選択します。

    014
    Storage server の登録時に設定した DD Boost ユーザがアクセス可能な DD ストレージユニットが表示されるので、バックアップデータを保存する DD ストレージユニットを選択します。

    015


    Disk Pool の名前を入力します。名前は何でも良いです。

    016

    Disk Pool が作成されました。

    017

  6. 最後にNBU ストレージユニットを作成します。
    ここでの名前が NetBackup で保存先を指定する時の名前ですので、分かりやすい名前を付けましょう。
    018


    Finish です!

    NetBackup で DD Boost over FC を使用する準備が整いました。

    019

前編はここまでです。 

決まりごとは多いですが構築自体は比較的簡単にできますのでぜひお試しください。

後半は NetBackup のポリシー(バックアップジョブ)を作成して実際の動作を確認してみましょう。 

 

 

- 過去記事 -

 

 

 

担当 齋藤・吉田

 

2016/03/28

EMC ScaleIOのハイパーコンバージド環境にI/Oパフォーマンスの飛躍を

本記事はPernixData社のホワイトペーパーの翻訳版です。原文は「Attaining Breakthrough I/O Performance In EMC ScaleIO Hyperconverged Environments」にて参照可能です。

イントロダクション

ScaleIO

EMC ScaleIO はソフトウェアをベースとしたソリューションであり、vSphereホストに搭載されたディスクをプールし、ホスト間のインターコネクトを実現することで、ハイパーコンバージドインフラストラクチャ(HCI)を構成します。ホスト上の仮想マシン(VM)はScaleIOによってブロックストレージとして構成されたデバイスをVMFSデータストアやRDMデバイスとして利用することが可能です。HCIはコンピューティングレイヤ(仮想マシン)とストレージレイヤの間の距離を縮め、I/Oパスをホスト内だけに留めることができます。これによって、単一の物理レイヤであるサーバはコンピューティングプラットフォーム(VMware ESX ハイパーバイザーで管理)とストレージプラットフォーム(EMC ScaleIO)の両方として動作させることが可能となり、これはハイパコンバージドプラットフォームとして知られています。

ScaleIO ソフトウェアはサーバとクライアントコンポーネントから構成されています(下図)。サーバコンポーネントはLinuxベースの仮想マシンにインストールされており、ESXホスト上で動作します。サーバコンポーネントはScale IO Data Server(SDS)と呼ばれています。クライアントコンポーネントはScale IO Data Client(SDC)と呼ばれており、SDS仮想マシンが動作しているのと同じホストのESX kernel上の軽量なドライバーとしてインストールされます。ScaleIOのHCI環境では、コンピューティングに加えて、ストレージ機能を仮想マシンに提供するため、SDSとSDCの両方が全ての適切なホストにインストールされている必要があります。Scale IOについての更に詳しい情報についてはEMC VSPEX Private Cloudをご参照ください。

Fig365アプリケーションからのI/OリクエストはSDCからSDSに対して構成されている論理アダプタ(logical adapter)を経由して、上の図に記載の物理ストレージへ送られます。このパスはデータの格納箇所によっては長くなってしまうことがあり(EMC VSPEX Private Cloudの第3章 "Storage Layer"をご参照ください)、高いI/Oアクティビティが行われる場合には不必要な遅延がボトルネックとして露呈します。ScaleIO仮想マシンのCPU負荷もI/Oレイテンシが予期しない動きをすることへ影響を与える要素の一つです。Scale IOはSAN環境におけるパスと比較するとアプリケーションからのリクエストから物理ストレージまでを短くすることができていますが、そのパスはまだ長く、混雑しがちです。結果としてこのパスを通るI/Oのレイテンシはまた高いと言わざるを得ません。

FVP

PernixData FVP® ソフトウェアは高速なRAMやSSDのようなホストリソースを利用し、低遅延の耐障害性のあるデータ高速化レイヤをvSphere ホストのクラスタ全体に提供することが可能です。このレイヤは頻繁にアクセスされるデータの格納場所やアプリケーションによって書き込まれる新しいデータの高速なI/Oを完了させる場所として利用することができます。

Fig366ESXカーネル内で動作し、他の様々なソフトウェアソリューションよりもコンピューティングレイヤに非常に近いレイヤに位置する(上の図を参照)ことから、FVPはデータのReadを劇的に改善することが可能です。アプリケーションは様々なタイミングでデータにアクセスします。FVPはこうしたリクエストに対して高速化レイヤー内のデータで応答します。高速化レイヤー内にデータがない場合にだけ、FVPはプライマリストレージへとそのリクエストを転送します。ですが、そのプライマリストレージからリクエストに応じて読み込まれたデータのコピーはデータ高速化レイヤに書き込まれ、将来のリクエストに備えることになります。

FVPはデータが高速化レイヤに書き込まれた直後にACK(完了通知)を返すことによって、Writeも高速化します。バックグラウンドではFVPがプライマリストレージへと送信されることを保証しますが、プライマリストレージへ書き込むレイテンシは仮想マシンからは見えなくなります。

ScaleIOをFVPと一緒に利用することで、I/Oのパフォーマンスはそのキャパシティから分離された最高のパフォーマンスを誇るHCI環境となります。この分離はIT管理者がそれぞれの要件に対して独立して管理、そして成長できるということを保証します。FVPはReadデータを削減し、Writeのレイテンシを劇的に低減するだけでなく、ScaleIOストレージ構成や複数のストレージの混在にかかわらず、一貫した均一のレイテンシを提供するのです。本ホワイトペーパーは以下では、ScaleIOとFVPを統合したインフラストラクチャにおいて実施した検証における定量的な効果について述べることにします。

検証の構成

本ホワイトペーパーにおける検証では4ノード構成のScaleIOベースのハイパーコンバージドインフラストラクチャを利用しました。検証の構成は以下の図の通りです。

Fig367それぞれのノード上にWindowsオペレーティングシステムが動作する仮想マシンを動作させました。4つ全ての仮想マシンにIOMeterをインストールしてあります。IOMeterはそれぞれのカオスマシンの仮想ディスクに対して事前に設定されたI/O負荷を生成して、負荷を与えるように構成されています。

ベースラインテストの後、FVPをそれぞれのScaleIOノードにインストールしました。FVPとホストメモリを利用して、すべての4つのノードをまたがった高速化レイヤを作成しています。IOMeterを動作させているテスト仮想マシンを順次FVPクラスタへと追加します。「Write-Back高速化」として知られるポリシーを用いて、仮想マシンのReadとWriteの双方を高速化します。IOMeterを高速化した仮想マシン内で動作させ、繰り返し、それぞれのスループットの総計とレイテンシの平均を記録しました。

検証

本ホワイトペーパーの検証で利用したI/Oワークロードのプロファイルは以下の図の通りです。ワークロードはReadとWriteのバーストを定期的な間隔で生成するように構成してありますが、同時には発生しないようにしてあります。バーストしていない期間におけるReadとWriteの操作はピーク時におけるものよりもかなり低く設定してあります。このIOmeterのワークロードはIOPSが定期的にスパイクするような一般的なワークロードのプロファイルを模したものであり、ReadとWriteのバーストは予期せずに発生します。

Fig368検証はReadとWriteのピーク性能を図ることとその際のそれぞれのテストケースにおけるレイテンシを図ることを主目的とします。それぞれの仮想マシンのIOMeterはI/O負荷を同時に発生させるように構成してあります。それぞれの仮想マシンのピーク性能は合計されて全クラスタに対して発生するため、全てのノードのレイテンシの平均値はクラスタレベルでの平均値を表すことになります。

検証結果

IOMeterはReadとWriteの両方のリクエストを同時に生成するため、この「検証結果」のセクションではそれぞれの操作を個別に見ていくことで理解しやすいようにしています。

ReadとWriteに対するFVPの影響

ScaleIOベースのHCI環境においてのFVPのReadとWrite操作に対しての影響を理解しやすように、単一の仮想マシン内でIOMeterを動作させるという検証を実施します。

Read

ベースラインとFVPを利用した場合のReadのパフォーマンスを以下の図に示します。図の上のグラフはピーク時のベースラインとFVPを利用した場合とそれぞれのReadの平均レイテンシを比較しています。

Fig369

Fig370

IOMeterの仮想マシンがFVPによって高速化された際にはReadのレイテンシは対応するベースラインでの結果に対して86%低減されています。これによってピーク時のIOPSはFVPによって8倍分増加しています。

Write

ベースラインとFVPを利用した場合のWriteのパフォーマンスは以下の図に表されています。図の上のグラフはピーク時のベースラインとFVPを利用した場合とそれぞれのWriteの平均レイテンシを比較しています。

Fig371

Fig372

Writeがピークに達した際のWriteのレイテンシはWriteが高速化されている場合には55%低減されており、このレイテンシの低減によってピーク時のWriteのIOPSは1.2倍分増加しています。

FVPによるパフォーマンスの拡張

ScaleIOのハイパーコンバージドインフラストラクチャはノードを追加することでリニアにI/Oパフォーマンスを拡張していくことが可能です。これは一極集中のアーキテクチャではないためです。巨大なScaleIOインフラストラクチャは強力な並列ストレージシステムとなります。

前出のセクションで、FVPが単一のScaleIOノードのI/Oパフォーマンスを劇的にブーストさせることが出来ることを示しました。ScaleIOのアーキテクチャを考慮すると、FVPをそれぞれのScaleIOノードにインストールして高速化レイヤを拡張させることで、ScaleIOインフラストラクチャ全域にわたってパフォーマンスをブーストさせることが可能となります。4ノードのScaleIOインフラストラクチャと4つのIOMeter仮想マシン(各ノードに1つづつ)において実施した検証によってこれを定量的に示すことができます。

Fig373

Fig374

Fig375

Fig3762つの棒グラフが示すとおり、ReadのIOPSとWriteのIOPSの両方がFVPの有無に関係なくScaleIOノードを追加するごとにリニアに拡張されています。さらに、それぞれのノード上の仮想マシンをScaleIOノード上に構成されたFVPクラスタに追加することでFVPによって線形にパフォーマンスはブーストされながら、それに対応するレイテンシはほぼ一定に低く保たれています。

ReadとWriteの双方は仮想マシンがFVPで高速化されている場合には同じレイヤから供給されるということを付け加えておきます。IOMeterでのレイテンシはReadとWriteで同じになっています。見てわかるほどのReadとWriteのレイテンシの低減は殆どのアプリケーションにとって劇的な効果をもたらします。アプリケーションはRead-変更-Writeという操作を大量に実行しているからです。ReadまたはWriteもしくはその両方のレイテンシが高い場合にはアプリケーション全体がスローダウンし、エンドユーザーはより多くの時間を待たなくてはならなくなります。

サマリ

ScaleIOはソフトウェアベースのソリューションでvSphereホストのローカルストレージとホスト間のインターコネクトを活用して、既存のvSphereベースのクラスタをハイパーコンバージドインフラストラクチャへと変革することが可能です。ScaleIOベースのハイパーコンバージドインフラストラクチャはインフラストラクチャ内のノードを増やすことでI/Oパフォーマンスをリニアに拡張することが可能です。PernixData FVPはメモリやSSDのような高速なサーバリソースを活用し、ScaleIOノード個々のI/O性能を劇的に向上させることが可能です。

本ホワイトペーパーの検証では超並列で拡張可能なサーバベースのストレージインフラストラクチャをScaleIOで構成した上で、FVPによってこのインフラストラクチャのパフォーマンスとキャパシティを分離させることで、非常に高いIOPSと低いレイテンシを実現できることを示唆しました。高速化したHCIはReadとWrite操作双方に一貫した均一のレイテンシを提供しながら、パフォーマンスをリニアに、そしてその下のストレージハードウェアとは独立して改善拡張することが可能です。

参考文献

EMC VSPEX Private Cloud

http://www.emc.com/collateral/technical-documentation/h13156-vspex-private-cloud-vmware-vsphere-scaleio-pig.pdf

Iometer

http://www.iometer.org/

PernixData FVP

http://www.pernixdata.com/pernixdata-fvp-software

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

2016/03/22

FVP Freedom -無償のハイパフォーマンスストレージ高速化ソリューションについての考察-

本記事はPernixData社のブログに投稿されたPernixDataの顧客の記事の翻訳版です。

記事の原文はFVP Freedom – A poor man’s thoughts on a free high performance storage acceleration solutionで参照できます。

筆者 : Aske Sønderup

みんな「オールフラッシュ」の話ばかりしているけど、それって本当に必要なものなの?

「オールフラッシュ」は疑いもなく、高いIOPSと高速なストレージを提供します、しかし、そのコストに価値が見合うのでしょうか?

PernixDataはストレージのリセラーではなく、ソフトウェアの企業です。この会社は完全に無償で、128GBのRAMを利用して、VMwareの構成に超高速なReadアクセラレーションをもたらします。このソリューションはFVP® Freedomと呼ばれています。

FVP Freedomを支えるテクノロジーはとことん直球です。このソフトウェアはどのデータが読み込まれるかを継続的に追跡し、それがメモリにキャッシュされている場合にはI/Oを大幅に高速化します。コントロールパネルではどの仮想マシンを「高速化」するか選択することができ、リソースは適切に割り当てられます。例えば、要件が高く、非常に多くのIOPSを必要とするデータベースには相対的に多くのリソースが割り当てられます。

PernixDataは既存の共有ストレージ上でI/O高速化層になるということは重要なので覚えておいてください。FVP Freedomはレイテンシの低減にも効果があります。というのも、仮想マシンはSANのデータストアからではなく、サーバーサイドのRAMからReadとWriteを提供されるからです。PernixDataのWebインターフェイスから、それぞれの仮想マシンのレイテンシを監視することが可能ですー そして、それとデータストアの実際のレイテンシを比較することが出来るのです。

Fig362テストで利用したホームラボの構成は以下のとおりです:

1. サーバ:

2台

HP DL380 G7

Dual X5650 Xeon (6 コア)

120 GB DDR3 メモリ

2x 600 GB SAS 10K

10G Fiber NIC

2. ネットワーク:

Cisco 3750 E with 10G Fiber (Primary)

Cisco 2960 X (バックアップ接続、耐障害性接続、VMware等)

Cisco ASA 5512X with SSD for FirePower

3. ストレージ:

Synology DS1515 3x 4 TB WD RED + 2x INTEL 330 120 GB SSDを搭載

FVP Freedomのインストール

FVP FreedomはFVP Freedomライセンスをオンラインでリクエストした後、PernixDataのサポートポータルから簡単にダウンロードができました。パッケージはVMwareのアップデートマネージャーとホストにパッチやプラグインを適用するのと同じようにメンテナンスモードと再起動によって導入することが可能です。

ソフトウェアのセットアップ

管理サーバを展開した後は、ウェブブラウザを通してIPでアクセスします。ウェルカムスクリーンで歓迎され、vCenterへ接続してホストへも接続がなされます。vCenterに接続ができればウェブのコントロールパネルは非常に簡単な管理が実現されます。

私は自分のVMware環境のうち、1つのクラスタのみで動作させます、ですから、そのクラスタを選択してFVP Freedom Acceleration clusterを作成しました。クラスタを作成した後は高速化リソースを選択します(今回はメモリです。)。それぞれ60GBぐらいのメモリを両方のホストで利用していましたので、それぞれのホストで32GB、合計で64GBの超高速Readキャッシュを利用することにしました。キャッシュは私のiSCSIターゲットでホストと接続されたSynology NASに適用しました。直接仮想マシンにキャッシュを適用することもできたのですが、今回はキャッシュをクラスタ全体のパフォーマンスに利用することにしました。

テストと期待すること

私のこの新しい製品に対する期待は非常に高いものでした。私は以前にVMware VSANをとことん実験し倒しています。VMware VSANはホスト内のストレージを直接階層化します。残念な事に、これでは私が持っているSANをリプレースすることになってしまいます(その名前がほのめかすとおりですね)。その代わりに私はストレージにFVP Freedomというサプリメントを与えることにしたのです。さらに、VSANでは安全性のために最低3ホストでレプリケーションを行わなくてはなりませんでした。VSANは私が思っている以上に高価なものだったのです。

まず最初のテストのために、私はATTO diskベンチマークをダウンロードしました。このツールはあらゆるストレージのベンチマークのためによく利用されていますし、ベンチマークを調整するための多くの機能も搭載されています。キューデプスを10、全体長を512MBに設定して、それ以外はすべて標準のままでテストを実施しました。結果は以下の図のとおりです。

Fig363

見て明らかな通り、ReadのスピードがFVP Freedomによってとてつもなく高速化されています。Writeのスピードは1GbitのNIC経由でスイッチを通したSynology NASへの接続がボトルネックになっています。しかし、Readのスピードはボトルネックにはなりません。理由は全てが同じボックスの中での出来事だからです。(更にいえば、FVP FreedomはWriteの高速化を提供していませんが、FVPの完全な製品版ではそれが利用可能です。)

以下の図が示すとおり、クラスタ内の仮想マシンの平均レイテンシはFVP Freedomによって劇的に低減されています。(ブルーのグラフは仮想マシンが観測したレイテンシで、パープルのグラフがSANのレイテンシです。)

Fig364

結論

FVP Freedomの効果に大変満足しています。小規模・中規模の企業でオールフラッシュSANを購入する予算がなく、128GBのメモリが高速化に利用できる場合には非常に有効です。(Writeの高速化やRAMの代わりにフラッシュを利用したい場合には制限のないFVP製品を推奨します。)

各々のサーバに32GBのキャッシュしか無いというのは大きな制限です。しかし、FVP Freedomは高価なメモリキャッシュの中では非常に良い選択だといえるでしょう。FVP Freedomをクラスタに適用した後に、劇的にレイテンシが落ちるのを目にしました。重たい負荷の中でもレイテンシが全く消え失せてしまったのです。

訳注 : この無償ソリューションをご利用してみたいという方は日本語Freedomコミュニティへご参加ください。

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

2016/03/16

ついに日本国内リリースされたVxRAIL【イントロ編】

こんにちは、石塚です。かなり久しぶりにブログ登場です。

登場しなかった期間の個人的なご報告として、今年もEMC Electに選出され、さらにVMware vExpertにも選出頂きました。 今年も各種イベントや本ブログ、そしてEMC Community Network で皆様のお役に立てる情報を発信していきたいと思います。

私は昨年からハイパーコンバージドを中心に活動しているわけですが、EMC社から新たにVCEブランドでリリースした VxRail (ブイエックスレール)がついに日本でも発表されました!! VxRailはVSPEX BLUEの後継機でもあるわけですが、今回はVxRailがどのように変わったのかをお伝えしようと思います。

ブレてないプロダクトコンセプト(簡単導入・簡単管理・簡単拡張)

 変わったところをお伝えすると言いながら、まずはブレてない製品コンセプトをおさらいしたいと思います。 VSPEX BLUEでもそうでしたが、VxRailも簡単導入簡単管理簡単拡張と簡単3ポイントが基本コンセプトになっています。 初期設定から完全にGUIで利用できて、さらに当然のことながら日本語です。 シンプル&グラフィカルなVxRail Manager(旧EVO:RAIL Engine)でvSphereの統合管理が可能ですが、これまでのvSphereと同様の運用がしたければvSphere Web Client(及びVI Client)を利用することも可能です。 ハードウェアの管理もVxRail Managerと同じ操作感で実装されているVxRail Manager Extension(旧BLUE Manager)で管理者様の負担を軽減します。

 簡単導入の点では、導入時の事前チェックプロセスがより詳細なものになりました。例えば指定されたVSANネットワークが正しく通信できない場合や、DNSサーバやNTPサーバへきちんと疎通ができない場合は先に進めません。初期セットアップのトラブルの殆どがネットワークトラブルだったと言う経験から実装された検証機能なのかと思います。これでさらに導入がシンプル&スマートになるでしょう。

通信ができない場合はエラーになって確認を促します

Error_2

 そして管理面ではシャットダウンがGUI上のボタン1つで可能になっています。VSANで構成されているため、VSPEX BLUEではやや煩雑な電源断手順が必要だったのですが、これを一気に解消してくれました。 しかも、実際にシャットダウンする前には「正常な状態であるか」をきちんとチェックしてくれます。問答無用で電源断するようなことは無いので、この点でも安心&確実な運用を支援してくれるはずです。 標準でサーバ管理ポート(Remote Management Module, RMM)が利用できて、RMM経由で電源を投入することが可能ですから、わざわざ設置されている場所に赴かなくても、リモートで電源操作が可能です。 機能エンハンスとしてのインパクトは小さい印象を受けますが、実運用面では大切な機能だと思います。

シャットダウンもボタン1発!しかも事前チェック付!!

Shutdown

今回のリリースの目玉はモデルラインナップの拡充!!

 今回のVxRailのリリースで最大の注目ポイントは間違いなくモデルラインナップになると思います。 VSPEX BLUEも非常に優秀で完成された製品でしたが、モデル選択はメモリ搭載容量(128GB/192GB)とネットワークインターフェース(RJ45/SFP+)の合計4モデルに絞られていました。 EMCと言えば「選択肢が豊富」と言う印象があったので残念ポイントだったのですが、今回のVxRailではCPU、メモリ、ディスク容量、インターフェースが複数の選択肢から選べるようになりました。さらに2016年Q2(4月~6月)にはさらにローエンドモデルとオールフラッシュモデルのリリースが予定されています。

ハイブリッドモデル(SSD+HDD)

Modellist_hybrid

オールフラッシュモデル(SSDのみ)

Modellist_afa

 上のリストにも記載されていますが、Q2以降では1ノード単位での追加が可能になりますし、その後にも色々な機能拡張が予定されています。 これらの機能拡張は全てvSphereの進化に追従できる純然たるvSphereアーキテクチャで実装されているからこそだと言えます。

基本ソフトウェアはvSphere6ベース

 VSPEX BLUEはvSphere5.5ベースでした。 このため、VSANのパフォーマンスや使い勝手、実績面でお客様からのご質問を多く頂いていましたが、VxRailはvSphere6ベース(6.0 update1)になりました。このため、色々な機能制限が向上し、パフォーマンスも向上しています。

VxRailと旧EVO:RAILとの比較Diff_vxevo

 VSANの実績としても、1000人以上のユーザ規模のVDI環境での利用も事例として出てきています。 スモールスタートできて、そのままスケールアウトできるメリットを生かせるVDI環境にはうってつけなのかと思います。

 

 今回はVxRailのイントロダクションとして、ここまでにしておきたいと思います。次回以降、初期セットアップや管理画面の操作性、ゲストOSの作成・管理、拡張などをご紹介してきたいと思いますのでご期待下さい。

2016/03/14

仮想化環境のブロックサイズについて理解する

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

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

本記事の原文はUnderstanding block sizes in a virtualized environmentで閲覧可能です。

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

データセンタのミステリーを紐解くことは宇宙を探検することにちょっと似ています。あらゆることを理解できており、すべてがどのようにかみあっているかも理解できていますが、事実に推測が入り混じり理解に苦しむケースも有ります。今回はブロックサイズについてのトピックスです。全てに関連するもので、まさにデータセンタのミステリーのうちの一つと言えるでしょう。ある意味で非常に身近なものですが、とっつきにくいもので、それが何なのかわかりにくく、またその影響も不確かなものです。

この目立つことのない、それでいて、とても重要なストレージのI/O特性ですが、ストレージを設計、最適化、トラブルシュートしようとしている注意深い管理者であっても、時々誤解(完全に見落とされてしまうことはないにしろ)をしています。似たようなトピックスにワーキングセットのサイズがありますが、ブロックサイズは管理者もしくは設計者から可視性と理解を欠いているという点から、心配すらされてこなかった分野です。悲しいことに、神話が一般的な知恵に変わって着ているようでも有ります。つまり、典型的な環境においてどうである、ということだけが取り沙汰され、アプリケーションやストレージシステムの挙動、そしてその環境においてどのように設計、最適化、トラブルシュートするべきかということだけが注目の対象となっているのです。

さぁ、こうした状況の中でブロックがどういうものであるかを理解し、その理解がどれだけ重要か、そしてデータセンタにどのように影響するかを見ていきましょう。

ブロックって何?

必要以上には難しくないレベルでお話をすると、ブロックとは単純なデータのチャンク(塊)です。ストレージI/Oという文脈で言うと、単一のReadもしくはWriteI/O操作を行うためのデータストリームの単位です。ブロックサイズは単一のユニットのペイロードのサイズによって決まります。業界の学術的な定義とこれが一部オーバーラップするため、ブロックとはなんなのか?という点で少し混乱がうまれます。ブロックサイズやクラスタサイズ、ページ、レイテンシなどは一般的な会話の中で普通に利用されていますが、その意味はどのように測定するか、どれが影響するかなど、多岐にわたります。ファイルシステムやストレージメディアの特性やハイパーバイザー、もしくはOSなどの文脈ではこれらの意味は様々に変わり、いつも同じ意味ではなくなってしまうのです。

データセンタの設計や運用を行っている方々に取っての意味はストレージシステムのパフォーマンススペックシート上のそれであったり、人工的なI/O生成器の構成のそれでしょう。ストレージシステムのパフォーマンススペックはアレイに対して特定のブロックサイズ(大抵は4Kかそれ未満)での人工的な負荷をかけ、アレイが最大どれだけのIOPSを提供できたか、というものです。人工的なI/Oの生成では大抵1つのサイズしか指定できません。ですから、ユーザーはブロックサイズがワークロード内で分散していることに気が付かず、また、人工的なI/Oをつかって、自身の環境にとって十分な検証ができているかもわかっていません。実際には多くのアプリケーションはそれぞれ固有のブロックサイズをあらゆる時点で、そしてアクティビティに応じてミックスして生成しているのです。

2013年に私は自分自身の本稼働環境にFVPを導入した際にブロックサイズの影響について記載しました。("IOPSとスループットとレイテンシの相関"の段落を見てください) FVPは私の環境のブロックサイズについて、直接的ではないにしろ、副次的な情報を提供しています。パフォーマンスグラフのサンプリング間隔の谷間とvscsistatコマンドを利用することでこれらのワークロードとそれを動かしている環境について新しい知見が得られました。しかし、そうしたツールがリアルタイムな分析には必要になってしまい、単一の仮想マシン、またはデータセンタ全体の長期でのブロックサイズの傾向の分析には不向きです。もっと簡単な方法が必要でした。

どう影響する?

ブロックサイズについて考える際に有効なのは、ストレージのペイロードが単一ユニットでどのように構成されているかを見ることです。4KBのペイロード、256KBのペイロード、または512KBのペイロードがどのように処理されるのかを見ることで、原理が明らかになります。ブロックとして参照しているので、四角形を使ってキャパシティを表しています。

Fig361

スループットはIOPSの結果です。そして、ブロックサイズはそれぞれのI/Oで送受信されるデータのサイズです。256KBは4KBのブロックが64回やり取りされた総量というだけではありません。ストレージのスタックがそれだけのスループットをやり取りできるだけの処理を行ったということです。つまりはファブリックの帯域、プロトコル、HBAやスイッチ、ストレージコントローラーの処理のオーバーヘッドを含みます。そして、永続層のメディアに焼き付けも行わないといけないということも忘れないで下さい。

このパフォーマンスは従来の回転するディスクよりもフラッシュにおいてより大きく変動します。Readは比較的フラッシュにとっては簡単ですが、NANDフラッシュに対する書き込みの方法はReadに比べ悪いものになり、特に大きなブロックを利用したWriteは更に悪い結果になります。(フラッシュについての基本的な挙動についての詳細はFrank Dennemanの記事のフラッシュのウェアレベリング、ガーベージコレクション、ライトアンプリフィケーションを参照してください。こちらにも素晴らしいフラッシュについての記事があります。)ラージブロックによるほんの僅かな数のWriteだけで、小さなブロックのI/Oであれば適切なパフォーマンスを生み出すためのフラッシュデバイス上のすべての機構を埋め尽くすだけのアクティビティが生成されてしまうのです。このパフォーマンスの劣化は初めて見ると、みんなビックリしてしまうほどです。

ブロックサイズはどのようなストレージアーキテクチャを利用しているかにかかわらず、ストレージのパフォーマンスに影響を与えます。従来からのSANアーキテクチャ、ハイパーコンバージド環境で利用されている分散ストレージソリューション、事実、問題が残されています。ストレージシステムはワークロードとは関係なく、特定のサイズのブロックサイズに最適化されている可能性があるのです。これはストレージシステムの設計上の想定の結果であり、そのアーキテクチャの限界でも有ります。ストレージソリューションの特定のワークロードのパターンに対処しようとする能力もまた、非常に多岐にわたります。優れたストレージシステムとそうでないシステムの違いはしばしば、ラージブロックのI/Oに対しての能力に帰結することもあります。こうしたことを理解しておくことはあらゆる環境において設計や運用の重要な要素となります。

それを生成するアプリケーション

ブロックサイズに関するトピックスを興味深いものにするのはOS(オペレーティング・システム)やアプリケーション、そしてそれを生成するワークロードです。ブロックサイズはOSやその中で動作しているアプリケーションによって変換されてしまうことが有ります。

多くの人が想像するのとは違い、単一の仮想マシンの任意の時間を切り取ってみたとしても、ブロックサイズは幅広いものがミックスされているのです。そして、刻々と劇的に変化します。こうした変化は仮想マシンとそれが動作しているインフラストラクチャにおけるI/Oに、すぐさま影響を与えます。大体30%ぐらいのブロックは64KBだと知っているぐらいでは十分とはいえません。時系列上でどのようにそれが分布するのかを理解する必要がありますし、様々なブロックサイズにおけるレイテンシや他の属性を相関づけて理解しておかなければなりません。これは将来、このトピックスをさらに掘り下げる際の話題として残しておきましょう。

可視性に関する従来からの手法での限界

従来型の方法でブロックサイズを見ることにはいくつかの制限事項が有りました。その影響の一部しか見ることができませんでした。ーつまり、データセンタ全体か、または単一のワークロードかーです。

1. vscsistatsによるカーネルの詳細な分析 - これはESXiの一部に組み込まれているユーティリティで、ESXiホスト上でコマンドラインで実行します。実行中のブロックサイズについての概要を得ることができますが、いくつかの大変な問題をはらんでいます。

  • 一つは特定のVMDKの非常に短い時間の情報以外に利用しようがないことです。リアルタイムに可視化することもできません。基本的には後から可視化を行うツールです。長時間にわたってデータを表示するためのツールでもありません。
  • vscsistatは特定の時刻の合計のI/Oを表示するだけで、サンプリング間隔次第です。時間を遡ってみることもできません。それを行うためには複数の結果を出力するスクリプトを書かなくてはなりません。
  • 文脈もありません。ワークロード(実際はただのVMDK)だけの情報が得られます。どんなアプリケーションが動いているかなどの文脈は失われ、適切な翻訳を行うこともできません。
  • データを視覚的に理解することもできません。これを行うためには可視化を手伝う別のツールの助けが必要です。
  • 結果として、多くのデータを見ようとした時、非常に労働集約的な作業が必要となり、ソリューションにはなりえません。管理者がこれをあらゆる仮想マシンで実行し、I/Oの特性を理解するするというようなことはありえません。

2. ストレージ装置 - これはベンダーに固有の「付加価値」機能で、ブロックサイズについてのシンプルな概要を表示することが出来るようになっています。しかし、これもまた不完全なソリューションです:

  • VM-awareではない。 I/OがサーバホストのHBAを通り抜けた瞬間から殆どのインテリジェンスは失われてしまいます。ストレージ装置はどのブロックがどの仮想マシンに関連付けられているかわからなくなりますし、どうした順番でそれが提供されているかもわからないのです。
  • 間違った場所での測定。単にストレージ装置はブロックサイズの影響を最初に測る地点としては誤った場所であるということです。ストレージトラフィックのすべてのキューを通り抜けた後にWriteはストレージにコミットされます。そして、それからReadが取得されます。(ストレージシステムの外側にはキャッシュ層がないと考えています。) 測定についてはこうしたことを全て考慮に入れて行わなくてはなりません。つまりハイパーバイザーで行うべきなのです。不幸なことに、ストレージ装置が素晴らしいパフォーマンスを誇っていたとしても仮想マシンのレイテンシで苦しむということが起こります。適切な場所での測定が重要であるということを教えてくれます。
  • 不確かな、または一元的ではない手法での測定。ブロックサイズの情報を表示するのはストレージ装置の本筋の機能ではありません。そして、I/Oが生まれる場所(仮想マシンとそれが動作しているホスト)と同じ方法で取得する必要もありません。とすると、どのように測定するのか、どれぐらいの頻度なのかは普通に考えて重要ではありません。そして公開されることもありません。
  • ストレージ装置に依存している。環境内でもしも別のタイプのストレージが利用されているのであれば、これは全てのワークロードが適切にカバーされているとは言いがたい事態です。

ハイパーバイザーはデータの分析には理想的なコントロールプレーンです。ゲストOS内の測定値やストレージソリューションの機能とは完全に独立した結果を見ることができます。これを受け継ぐことで、環境における理想的なデータセンタの包括的な理解を行うことが出来るのです。

完全に目をつぶってしまった状態 ー 最初からストレージの設計を誤っている

多くの設計に関する事項にひびが入っているとおもっています。我々の考えを示しましょう。まずストレージ設計の際に必要なことを考えてみましょう。大抵は以下の様な要素です。

  • IOPSとスループットのピーク
  • Read/Writeの割合
  • RAIDペナルティ
  • 更に面白くしたいのであれば、物理的なコンポーネントのレイテンシ

殆どの環境の設計や管理を行っている人はこうした訓練を様々で受けていると思います。ちょっとした数学を使って、ディスクの配合やRAIDレベル、そしてファブリックで必要なパフォーマンスに対応できるかどうかなどを示すことができます。そうなった際には必要な公式を利用できますが、そうでない場合にはそれは想定に満ちています。さて、ブロックサイズ、これは全てに影響しますが、どこにも書かれていません。どうして?見えないし、理解し難いものだからです。ストレージシステムにとってブロックサイズが劇的なパフォーマンスの影響をもたらすものだと知ったとしたら(今後も記事を投稿していきます)、設計や最適化や、トラブルシューティングの訓練に組み入れなくてもいいものでしょうか?もちろん、組み入れるべきです。ワーキングセットのサイズと同じです。見えないからといって、考慮しないわけにはいかないのです。インフラストラクチャはサービスやアプリケーションを動作させるために存在しているのです。そうしたアプリケーションとワークロードが教えてくれる、どうしたタイプのストレージがあなたの環境に最もあうかという声を聞いて、助けましょう。それ以外の道はありません。

もっといい方法は?

あります。もっといい方法。PernixData Architectはデータセンタ全体に渡るこれまでにはない可視性とブロックサイズの分析を提供します。乞うご期待、我々はArchitectがブロックサイズによる環境への影響をもっとはっきりと見せていくようにします。