« 2016年1月 | メイン | 2016年3月 »

2016年2月

2016/02/25

クラウドを活用できる今話題のEMC CloudArrayとは!? ④

いよいよ、最終回です!

最後にウィザードを利用せずに設定していき、CloudArrayを極めていきたいと思います。

引き続き、EMC担当の片山です。

前回は初期セットアップウィザードを利用してCIFS設定をしてきましたが、今回は各設定を理解した上で個別に今までの設定を実施していきたいと思います。この操作が一通りできれば、あなたも今日からCloudArrayマスターを名乗れます! 

簡単な設定の流れとしては、下記を項目の様になります。

N_3



では、上記の流れで項目の順を追って説明していきたいと思います。

(1)Cloudプロバイダの設定

まず第一に、利用したいCloudプロバイダを設定していきます。

左側メニュから【CLOUD PROVIDERS】をクリックします。【Configure New Cloud Provider】をクリックします。

C

【Select Cloud Provider】のメニュから、今回も検証で利用している【Amazon S3】を選択して、【Continue】をクリックします。

D

Amazon S3に接続に必要な情報を入力します。入力後【Save Cloud Provider】をクリックします。これでCloudプロバイダ設定は完了です。

E

(2)CACHE設定

次に、PoolからCacheを切り出す設定をしていきます。GUIの左側メニュから【CACHE MANAGEMENT】⇒【Caches】をクリックします。そして【Configure New Cache】をクリックします。

A_4

まずはCacheの名前を入力します。次にここでは、【Pool_1】から10GBを利用する形でCacheを作成しています。値に間違いがなければ【Configure New Cache】をクリックします。

B_2

【Create One Big Cache Using All Available Capacity】は複数Poolから大容量のCacheを作る際にチェックをします。

(2)POLICY設定

次に、Cache⇒Cloudプロバイダの紐づき設定であるポリシーを作成しておきます。 左側のメニュから【PROVISONING POLICYS】をクリックし、【Configure New Provisioning Policy】をクリックします。

F

まず、ポリシー名を入力します。またここでさきほど設定したCloudプロバイダ設定とCache設定を選択して紐づけます。紐づきが正しければ、「Configure Provisionig Policy」をクリックします。

G

(2)接続プロトコルの有効化(CIFS)

左側メニュより、【SHARES】⇒【Settings】をクリックして、CIFS機能を有効にします。

※ デフォルトは無効になっています。

I

CIFS機能を有効にすると表示される【CIFS】メニュをクリックします。ここではサーバ名やWorkgroup環境、ActiveDirectory等のCIFSサーバの基本設定をしますが、今回は検証ですぐにアクセスして利用するためWorkgroup、【Allow Guest Access For CIFS Shares】にチェックを入れゲストアクセスを許可しています。

※AD連携、Workgroup環境でローカルユーザーを作成することも可能です。

※AD環境でダイナミックDNS機能連携はないためホストをDNSに登録する必要があります。

J_2

次に、Volumeと共有を作成するため、【New Share】をクリックします。

K

(2)Volume、Shareの作成とPolicyの紐づけ設定

【New CIFS Share】ウィンドウが開きますので、【Share Name】を入力します。次に、さきほど作成したCache(10GB)⇒Amazon S3への【Policy】を選択します。【Capacity】には50GiBを入力します。最後に【Save】をクリックします。

M_5

以上でCloudArryaへの設定は完了です。CloudArrayのIPアドレスへアクセスすると普通にアクセスできるかと思います。これであなたもCloudArrayマスターです!

最後に設定完了のついでに、構築したCloudArrayのCIFSサーバに、600MBと3,000MB程度のファイルを共有に対して同時に書込んで見たいと思います。そして、ダッシュボードで監視してみます。

データ自体はCacheに書込まれるため、書込み遅延が発生するような事はありませんが、Cloudに書込まれていないデータはDirty Pageとして【Current Cache Activity】に表示されています。また、FIFOデータ処理方式により、圧縮、暗号化処理が完了次第、順次Cloudに転送していることがわかるかと思います。

※ 圧縮、暗号化を設定しない場合でも分割と最適化をしているのか同様の動きをします。

1_3

 

 少し待って再度確認してみると、右上の【Cache Usage】のUsedのグラフが約3.6GBぐらいになっているのがわかります。Dirty Pageはほぼ横ばいの"0"となり、定期的にCloudプロバイダへReplicationが一定の間隔で継続していることがわかります。

2_3

この結果からも、仮にCloudプロバイダへのReplicationが書込みに追いつかず、Dirty Pageが90%以上に達っしてしまうと、そのCacheを利用している対象領域へのアクセスが一時停止してしまうため、CloudArrayのCache容量をどう設定するかが非常に大事だという事が見て取れるかと思います。やはりCache設計には注意が必要になります。

これで4回目となった今回の記事【クラウドを活用できる今話題のEMC CloudArrayとは!?】ですが、EMCクラウドゲートウェイ製品はどうでしたか?まだ発展途上の製品ではありますが、思ったより設定がシンプルで、VE版であればすぐに検証及び導入できそうに思えるかと。もし興味がある方は是非お試しを!

 

記事:片山

 

今回の記事一覧はこちら

クラウドを活用できる今話題のEMC CloudArrayとは!?①

クラウドを活用できる今話題のEMC CloudArrayとは!?②

クラウドを活用できる今話題のEMC CloudArrayとは!?③

クラウドを活用できる今話題のEMC CloudArrayとは!?④

 

 

2016/02/22

いよいよリリース! VSAN 6.2 すべてはErasure Coding!! 細かな機能も抑えておこう

この記事は前々回、前回につづき新しいVSAN 6.2についての記事です。是非こちらの記事もお読みください。

いよいよVSAN 6.2がリリースされています。詳しくはこちらの桂島様の記事でカバーされていますので、是非ご覧になってください。

ご紹介している「Erasure Coding」、大注目の「インライン重複排除&圧縮」についてはAll flash構成のみでサポートされます。桂島様の記事によると重複排除&圧縮で2~7倍の容量効率、Erasure Codingを併用する10倍までの容量効率を実現できるとのことです!

また、EMC/VCE社からはVSPEX BLUEの後継に当たるVxRailも発表されています。VSAN Ready Node程細かく指定はできませんが、選べる構成の幅が大きく広がり、さらに「4ノード縛りにこだわらない」という発言も飛び出しているようです(ネタ元)ので、EVO:Railの画一的な構成ではなく、今後幅広く利用していくことが可能になっています。

リリースされたErasure Codingの実装について(前回の記事の訂正を含む)

先日の記事ではリリース前の情報から推測しての記載でしたのであたかもパリティデータを専門で担当するノードがあるような図になっていましたが、実際の実装ではパリティも各ノードに分散して保持されます。

Paritydistribution※ 図については桂島様の記事よりお借りしてきました。

また、サポートされるのはRAID-5およびRAID-6のみで、それぞれの最小要件はRAID-5は4ノード(3+1)から、RAID-6は6ノード(4+2)からとなります。つまり、VxRailのような4ノードのアプライアンスでもRAID-5が利用できるため、VDIなどのある程度キャパシティの必要な構成も対応が可能です。(クドいかもしれませんが、RAID-5を含むErasure Codingはオールフラッシュ構成のみでサポートされます)

QoS

ストレージポリシー内で各VMDKあたりのIOPSの上限値を設定できるようになりました。ストレージポリシー内で設定できるということはオンデマンドで(VMの再起動などなく)これを変更出来るということです。過度にオーバープロビジョニングするような構成は想定されていない(コスト高になりますから・・・)ので最低値の設定はありませんが、業務に不必要なVMがノードのI/Oを食い潰すようなことを防ぐことができますので、ビジネスクリティカルアプリケーションの動作について、より安心が出来るようになっています。IOPSでの指定ですので、ブロックサイズも見なくてはなりませんが、非常に強力な機能です。(今回の記事内で唯一Erasure Codingと直接関係しません。)

Qos

※ 上の画像はVMwareのCTOオフィスのDuncan Epping氏のブログからお借りしました。

インメモリ・リードキャッシュ

容量効率やQoSの影に隠れていますが、個人的には非常に重要と思う機能がこちらです。VSANはノード間でデータを分散します。VMのReadリクエストに対する応答は「データを持っているもっとも遅いノードを待たなければならない」ことになります。

前回の記事はWriteのトラフィックだけを解説しましたが、Readのトラフィックも同様にネットワークを何度も流れることになります。特にRAID5/6の構成の場合、「たまたまローカルのノードにデータが有った」ということもありえませんので、ローカルのノードにリードキャッシュを保持するということはパフォーマンスの観点からもネットワークの観点からも非常に重要な機能です。

Traffic_for_read_request_2※ 図の統一のためにErasure Codingもハイブリッド構成のようにしてありますが、All Flashのみで対応です

Duncanさんの記事によるとこのリードキャッシュは非常に小さいもので、各ホストの物理メモリの0.4%または最大でも1GBとのことですが、上で解説したとおり、Readのためのネットワークトラフィックを削減するため、およびネットワークトラフィックによるレイテンシの低下を防ぐためには非常に重要な機能です。

気がついている方も入るかもしれませんが、このインメモリキャッシュはPernixData社の無償製品FVP Freedomエディションに相当する機能です。アプリケーションにとっては小さなキャッシュサイズでも非常に大きな効果が得られる場合がありますので、是非心に留めておいてください。

CheckSum

VSANはネットワークを通じてデータを書き込むため、ネットワーク転送によってデータが変化していないことを保証する必要があります。近年のネットワーク品質を考えればほとんどありえないことですが、そこまで保証するのがVSANです。金融機関などで万が一が起こったとしたら、大混乱です。これも一種のErasure Codingと言えるかもしれませんが、RAID5/6が横方向にパリティを発行するものだとすると、CheckSum機能は縦方向に対してはチェックサムを発行し、VMから出たデータが正しくキャパシティ層に着地したことを保証するものです(データが変更されていることを検知するのが目的で、復元することが目的ではないのでパリティではなく、チェックサムが利用されています)。

まとめ

他にも管理系の機能なども充実していますが、今回のシリーズはあくまで「Erasure Coding」のシリーズでしたので、関連する部分に留め、別の機会にしたいと思います。

とにかく、新しいVSANは良く出来ている! 注目されている容量効率の面からだけでなく、ネットワークトラフィック、そしてパフォーマンスの観点からも理にかなっているのです。

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

2016/02/19

仮想マシンの密度(統合率)についての考察

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

本記事の原文はInsights into VM densityで閲覧可能です。

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

この3ヶ月、私がPernixDataで主にフォーカスしていたのは(現在進行形ですが・・・)PernixCloudプログラムです。PernixData CloudはPernixData Architectの論理的な進化系であり、仮想化データセンタ、そのインフラストラクチャ、そしてアプリケーションについての可視化や解析を提供します。仮想化インフラストラクチャの様々な要素についての真実を描き出すことで、設計者や管理者はデータに基づいて環境を設計できるようになるのです。

前回の記事 「ESXiホストのCPUとメモリの構成についての考察」では、8000ものESXiホストのコンピューティング構成にズームインし、今日VMware vSphereを動作させているデータセンタでどのようなシステムが最もよく利用されているのかを理解することができました。次のステップとしてふさわしいのはこれらのシステム上でどれだけの仮想マシンが平均して動作しているのかを見ることでしょう。データセットが以前よりも大きく膨らんでおり、今では25000以上ものESXiホストの情報が含まれています。

とてつもないデータセットの探検ですが、毎日のように大きくなっているのです。このように膨大な量のデータをどう取り扱っていくのかを学ぶのは大変に面白い体験です。こんなにも大きなデータセットから様々なメトリックを取り出して行くことはチャレンジングなことです。よくあるツールはこうしたデータの量に対応できるようには設計されていません。ですから、全てをカスタムで創りあげなくてはならないのです。そしてデータセットの成長が非常に速いペースであることから、ソフトウェアとハードウェアで、出来売る限りのギリギリを定期的に探検しなくてはいけないのです。

仮想マシンの密度(統合率)

どのようなシステム構成が一般的なのかを学んだあと、そのシステムの上でどれだけの仮想マシンが動作しているかすぐに気になるはずです。ですが、どれだけの詳細のレベルで知りたいでしょうか?設計者や管理者が自身のシステムと比較し、新しいデータセンタの設計に役立てることは出来るのでしょうか?

よく質問を受けるのは仮想CPUと物理CPUの割合です。これはとても興味深いものです。しかし、残念ながら、意味のある結果を得るためにはいくつかの複数のメトリックを考えに入れておく必要があります。もちろん、vCPUとpCPUの割合をマッピングすることは可能です。しかし、仮想化の創世記から脈々と続いている仮想マシンをオーバーサイズにしているという事実をどうすればよいでしょうか? シングルスレッドのプログラムしか動かしておらず、システムがシングル、もしくはダブルのCPUしか必要としていない時にはこうした議論は全く意味が無いものですが、どうすべきでしょうか? ベンダーがソフトウェアが最低、専属の状態で8CPU必要と特記事項に書いているのを何度目にしたでしょうか? ですから、正しい結果を得るためにはCPUの利用率を勘定に入れる必要があり、それによってどの時間帯のデータを利用すれば仮想マシンが適切なサイズになっているか、もしくは殆どの時間でvCPUがただアイドル状態なのかも理解しなくてはなりません。つまり静的なデータ(インベントリ)と移り変わるデータ(利用率)をミックスしなければいけないのです。メモリにも同じことが言えます。

結果についてはホストあたりの仮想マシンの密度(統合率)のみにフォーカスします。仮想化は様々なバリエーションのアプリケーションの挙動と、それらの統合、DRSやVMturboの様な分散メカニズムを前提として仮想と物理のコンピューティング構成を適切に合わせてくれます。ですから、データセンタがシステムをどれだけストレッチして利用しているのか、そして仮想マシンの統合率がどれだけなのかを見ていくことは非常に興味深いものになります。ホストあたりの仮想マシンのスイートスポットを見つけることが出来るでしょうか?

以前お見せしたとおり、デュアルソケットのシステムが仮想化データセンタにおいての人気の構成です。ですから、今回私はこのシステムだけにフォーカスします。この構成でデータセットは25,000以上ものESXiホストの情報を持っています。CPUのタイプを見てみましょう。

Fig351

人気のシステムは合計で12,16,20,24コアを搭載しているものです。ですから、今日人気のCPUは6,8,10そして12コアということになります。しかし、我々がよく想定するようにホストを「クローズドな」システムであるとみなし、ホスト上のCPUのスケジューラーは利用可能な物理CPUに綺麗に分散されているだろうと信じて、全てのチャートはCPUごとではなく、システム内のコア数の合計として集計しています。例えば、16コアのESXiホストは2つの8コアのCPUを搭載しているとしています。

CPU構成のサブセットを見て行く前に、全体での仮想マシンの密度を見てみましょう。

Fig352

どこをとってみても興味深い結果です。仮想マシンの密度が1ホストあたり0~10から250異常まで多岐にわたっています。幾つかおかしなデータが有りましたので、それは取り除いています。あるシステムは580以上の仮想マシンが16コア、192GBで動作していました。さぁ、CPUの構成毎の仮想マシンの密度を見ていきましょう。

CPU構成毎の仮想マシンの密度

Fig353

すべてのデュアルソケットCPU構成ではなく、3つのよくある構成のみに絞ってあります。今日では一般的な16コアの構成と私が今年には標準的な構成になると考える20,24コアの構成です。これによって、現在データセンタで動作している平均の値と今後考えられる仮想マシンの密度を比較することができます。

メモリ

ホストメモリは仮想マシンにパフォーマンスを提供する上で不可欠ですから、CPUとメモリの構成から仮想マシンの密度を考えるのは論理的だと思っています。今日の仮想化データセンタにおける、デュアルソケットシステムのメモリの構成の分布はどうでしょうか?

Fig354

16コアシステムにおけるメモリ構成と仮想マシンの密度(統合率)

16コアのESXiホストのうち、30%が384GBのメモリを搭載しています。この構成内では、21~30VMが一般的な統合率です。

Fig355

Fig356

20コアシステムにおけるメモリ構成と仮想マシンの密度(統合率)

20コアのESXiホストのうち、50%は256GBのメモリを搭載しています。この構成では31~40VMが一般的な統合率です。

Fig357

Fig358

面白いことに、平均的には16コアのシステムよりもコアあたりのメモリサイズが小さくなっています。(16コアでは24GB/コアでしたが、20コアでは12.8GB/コア)

24コアシステムにおけるメモリ構成と仮想マシンの密度(統合率)

24コアシステムのうち39%が384GBのメモリを搭載しています。この構成では101~150VMというのが一般的な統合率です。

Fig359

Fig360

101~150VMと言うのはVDIプラットフォームとしての利用でしょう。このぐらいの値が仮想デスクトップ環境のスイートスポットでしょうか?

結論

仮想マシンの実際の統合率のデータがわかっただけでなく、他にも面白い事実が浮き彫りになりました。こうした数字と格闘している中で気になったのは利用されているメモリ構成です。私が話をしてきた殆どの設計者はホストにメモリを搭載出来るだけ搭載し、償却期間を終えるとシステムをごっそりと入れ替えていました。しかし、私は面白い事実を見つけました。例えば、104GBや136GBというようなメモリ構成です。どうしたら104GBのメモリのシステムを構成できるでしょうか? 4GBのDIMMが実際に転がっていて、それをシステムに突っ込んだのでしょうか? メモリが多い=パフォーマンスが良い これは正しいですか? 是非私のメモリディープダイブシリーズにも目を通してください。パフォーマンスについての考えが間違いであることがわかりますが、これはちょっと脱線ですね。他に面白い事象としてデータベース内の4%もの24コアシステムが128GBのメモリしか搭載していませんでした。コアあたり5.3GB、NUMAノードあたり64GBです。これによって、VMあたりのメモリの平均値やNUMAノードあたりの統合率などへの疑問も出てきます。もっと我々がデータを見ることで、もっと多くの疑問が出てくるでしょう。あなたの疑問をぜひ聞かせてください!

訳注 :  日本語でご質問したい方は以下の私のTwitterアカウントにお気軽にご質問ください。

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

2016/02/16

クラウド統合ストレージAltaVaultをさわってみた-概要説明編-

最近、よく「クラウド」なんて言葉をよく耳にする機会が多くなってきましたね

NetApp社からも「バックアップとアーカイブに最適なAltaVaultクラウド統合ストレージ」が提供されています。
実際に何ができるのか!?記載して行きたいと思います。

今回は概要説明をメインにしたいと思います。

-------

AltaVault 概要説明

-------

下記に製品概要を記載します。

Av_blog1

文字で記載するとちょっとわかりにくいので、構成イメージは下記になります。
AltaVaultに直近のバックアップデータはキャッシュとしてお客様環境(ローカル)に保存します。
ある一定の期間経過したバックアップデータはクラウドに保存される仕組みになります。
しかし、バックアップデータをそのままクラウドに保存しますと大容量が必要になりますが
AltaVaultは重複排除と圧縮機能でバックアップデータ容量を節約できます。

Av_blog2


リストアするイメージは下記になります。
直近のデータはキャッシュとしてお客様環境(ローカル)にありますのでそこからリストアします。
ローカルキャッシュにない場合はクラウドから差分データのみリストアします。

ここで注目は、多くのクラウドベンダーはデータ保存にも費用が発生しますが
データ取り出す場合も費用が発生します。
リストアする場合に費用が発生しないようにローカルキャッシュに直近データが保存されているのがいいところですね

Av_blog3_3

ラインナップは下記になります。

  • AltaVault物理アプライアンス    

  • VMware vSphere、Microsoft Hyper-V対応のAltaVault仮想アプライアンス

  • Amazon Web Services、Microsoft Azure対応のAltaVaultクラウドベース アプライアンス

Av_blog4

ちなみにAltaVault物理アプライアンスはNetApp FAS8080EXと同じサイズですので
大企業向けになっています。

ライセンスは90日無償になっていますのでNetApp社から評価用がダウンロード可能になっています
無償の90日間試用版をダウンロード

もし興味がある方がいましたら、下記URLからご連絡お願いします。

【NetApp製品問い合わせ先】

さて、次回は「AltaVault仮想アプライアンス」の展開から設定方法を記載予定です。

長谷部(ハセベ)


2016/02/15

困難な時代だからこそ、スマートに最適化 ~不景気とその時に売れたプロダクト~

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

本記事の原文はWhen the Going Gets Tough, the Smart Optimizeで閲覧可能です。

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

情報システム部門はいつも、少ない投資で多くの成果を上げるようにと言われ続けます。景気が上よい際には、当然悪い時よりも輝かしい新しいオモチャを買うのは簡単なことです。これが近年AFAの市場が非常に活発である(訳注:リンク先はIDC.comの英文リリース)と言われている理由の一つです。

しかし、2016年、誰かが予想し始めているように(リンク先はCNN.comの景気後退についてのビデオ)経済が停滞したら、投資の様相は変わっていくのでしょうか?

過去の歴史に目を向けてみましょう・・・

2001年、VMwareはESXの最初の出荷を開始しました。それはドットコムバブル後の経済低迷の最中のことでした。この製品はVMwareのその後の成功の推進力となります。なぜ、そんなにも上手く行ったのでしょうか? その当時、情報システム部門はその労力を付加価値へフォーカスさせて(リンク先はGartnerの2001年の記事)いました。例えば、基盤の改善のためのプロジェクトに投資を集中させるという具合にです。ESXはそれを素晴らしいやり方で、導入するだけで実現させてくれるものでした。もっと具体的に言うと、仮想化によってサーバインフラストラクチャを最適化し、サーバハードウェアを大量に買うということをしなくて済むようになったのです。ROIは現実のもので、簡単に定量化することができました。

同じように2010年、IT産業はGartnerによると「緊縮の年(Age of Austerity)」を迎えます。しかし、多くの企業がサブプライムローンとヨーロッパの金融危機のために、もがいていたにもかかわらず、Isilonはこの時、(EMCに$2.25Bドルで買収される前を除くと)4四半期全てにおいて、素晴らしい業績を残しています。なぜでしょうか? 彼らは会社組織がインテリジェントにストレージを成長させ、高くつく余裕を見過ぎた構成を取らなくて済む、新しいスケールアウトアーキテクチャをもたらしたのです。

ここから学ぶべきことは?

困難な時代だからこそ、人々は最適化を行います。VMwareはサーバのパフォーマンスを最適化するソフトウェアとして名を成し、Isilonはストレージハードウェアをスケールアウト成長とともに最適化することによって、数億ドル規模の会社へと成長したのです。どちらの場合も、ソリューションはハードウェアの投資を最小化しながら、しっかりとした付加価値を提供しています。

では、2016年はどうなるのでしょうか? 経済の不安定さによって、今年、CIOたちは情報システム部門にかける予算を非常に厳格に管理し始めるでしょう。これは盲目的に問題に対してハードウェアを投げつけるということが難しくなって行くということを意味します。例えば、ストレージ装置のパフォーマンスを得るために、キャパシティを購入するということは効率的ではなく、高価で、顧客がそれを受け入れなくなっていくにつれ、難しくなってくるでしょう。これは非常にコスト効率のよいクラウドベースのサービスによって、実際の機材に対して投資をすることが大きく疑問視されていることとよく似ています。

加えて、いわゆる「キャデラック(高級乗用車)」への投資も疑問視されています。例えば、すでにデータベース環境のそれぞれのインスタンスがOracleが必要なのか、もっと安価な、SQLサーバやMySQLですんでしまうのか、よく吟味している顧客は多くあります。これによって高価なインメモリコンピューティングやExadataのような専用ハードウェアへの投資を、代替の同等のパフォーマンスをもっと安価に提供できるソリューションへと切り替えつつ有ります。

私は、特にストレージの領域において、こうした要素(投資の最適化)がAFA(オールフラッシュストレージ)とハイパーコンバージドのマーケットをやわらかく、それぞれがより近い意味あいのものにしているように感じます。会社組織は既存のストレージを最適化しようとしているのであって、高価な新しいハードウェアで置き換えようとしているのではありません。しかも、本当にストレージのキャパシティがもっと必要とされているのでないのであれば、新しいストレージを購入しようとは思いません。次の世代のソリューションが更に優れたスケールアウトの能力(もしくはもっとコスト削減が可能など)を搭載してくるからです。

時が流れるにつれ、人々は基本を忘れていきます。好き勝手なことをやり始めますし、実際のニーズではなく、周りのトレンドで購入の決断をしてしまう時もあります。(Apple Watchを持っている人はいますか?) しかし、困難な時代を迎えると、基本が全てを支配します。この調達のビジネス上の意味は? これは最もコスト効率が良いソリューションなのか? 今でなくてはならない投資なのか?もっとあとでも良いのか? 前回の投資の高価は最大化できたのだろうか? 非常に慎重で、しっかりとした、効率のよい決断が必要で、新しい輝かしいオモチャを購入することに比べると楽しいものではないかもしれません。しかし、これがビジネスをより強くするのです。

引用

経済が良い時に輝かしい新しいオモチャを買うのは、悪い時に買うよりも簡単である。

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

2016/02/08

最新のVSANに搭載される「Erasure Coding」とネットワークのステキな関係

この記事は前回の最新のVMware VSANに搭載される 「Erasure Coding」とは何か?の続編に当たります。

前回の記事ではErasure Codingとはネットワークをまたいで実装されたRAID5/RAID6の様な技術だということをお伝えしました。今回はその副次的な(けれども重要な)効果をお伝えします。ストレージエリアネットワークの帯域についてのお話です。

わかりやすさのため、以下の仮定を入れています。

  • 各ノードに動作しているVMの数が十分に多い
  • 各ノードで動作しているVMのワークロードは全て同じ
  • VSANのストレージポリシーは全て同じ
  • 図はRAID6(4+2)、または従来の2障害保護(FTT=2)を想定
  • Write時のトラフィックのみを考える

6ノード構成での各ノード間のトラフィック

この状態で6ノード構成でのネットワーク帯域を流れるトラフィックを考えていきましょう。

従来のVSAN(FTT=2)では障害からデータを保護するためにネットワーク越しにVMDKのコピーを3つ作ります。このためネットワークのトラフィックは3であるということになります。VM自身が動作しているノードにデータを置けばネットワークを流れるデータは2で済みますが、このノードが障害を起こしてしまうと「FTT設定を満たすため、レプリカを再生成する必要がある」「HA処理を実行する」という二重苦が発生するため、可能な限り3つにしておくのがベストです。ここで、上の仮定を導入します。すなわち、各ホストの送信するデータは自分自身以外の5ホストに3つのVMDKを送るということです。平均すると「5ホストにそれぞれ3/5のデータを送る」と考えることができます。

各ホストの送信・受信するデータは以下のとおりです。

(送信) 自分自身以外の5ホストへVMDKの3/5のデータを送信する

(受信) 自分自身以外の5ホストからVMDKの3/5のデータを受信する

(合計)  3/5(送信)*5 + 3/5 * 5 (受信) = 6

(各ノード間通信) 6 ÷ 5 = 1.2

一方で、新しいVSAN(4+2)ではVMDKの1/4のデータを6つのホストに転送することになります。お分かりのとおり、2ノードへはパリティが転送されますが、このサイズは残り4ノードへ転送されるデータのサイズと同じです。こちらの場合はどのノードが落ちてもデータ復元ができますので、自分自身とそれ以外のホストの区別はありません。各ノード間のトラフィックは以下のとおりです。

(送信) 5ホスト全てにVMDKの1/4のデータを送信、自分自身にも1/4のデータを格納(送信しない)

(受信) 5ホストからVMDKの1/4のデータを受信する

(合計) 1/4 * 5 (送信) + 1/4 * 5(受信) = 2.5

(各ノード間通信) 2.5 ÷ 5 = 0.5

ご参考までに従来型ストレージでの場合のトラフィックも併記しておきました。これはVMDKと同じサイズのデータをストレージに送信していますので、流れるトラフィックは1です。各トラフィックが分かりやすいように、それぞれの太さを図に反映しています。

Inter6nodetraffic_3

六角形の頂点に各ノードがあると考えて、各辺と対角線の太さがそれぞれのノード間を流れるトラフィックです。いかがでしょうか?FTT=2より、4+2でトラフィックが小さくなっている具合が御理解いただけると思います。さて、更に仮定を進めていきましょう。

12ノード構成での各ノード間のトラフィック

ノードが倍に増え、12ノードになったと仮定します。

FTT=2の場合、

(送信) 自分以外の11ノードに3のデータを送信(つまり11ノードに対して、3/11のデータを送信)

(受信) 自分以外の11ノードから3/11のデータを受信します

(合計) 3/11*11 + 3/11 * 11 = 6

(各ノード間通信) 6÷11 = 0.54

4+2の場合、今回はノード数に余裕があるのでVMの動作しているホストにデータを置かない(障害時にリバランス+HAの二重苦を避ける)という戦略をとることになります。自分以外の11ノードのうち、6ノードに1/4ずつデータを送信します。ノードが均一であるという仮定を加えると、

(送信) 自分以外の11ノードのうち6ノードに1/4のデータを送信(1.5)、11ノードで平均すると1.5/11

(受信) 1.5/11を11ノードから受信

(合計) 1.5/11*11 + 1.5/11 * 11 = 3

(各ノード間通信) 3÷11 =0.2727・・・

図にすると以下のとおりです。

Inter12nodetraffic_3

なんだか、綺麗な図形になってきていますが、注目いただきたいのはそこではありません。FTT=2の場合、もう潰れてしまってよくわからなくなってしまっていますが、4+2ではErasure Codingによって、12ノードでも各々のノード間通信の具合を確認することができます。実際に絵にしてみることで、Erasure Codingの削減効果を実感できたのではないでしょうか?(直感的に分かりやすいように恣意的に図と線の太さを調整していますが、上の計算結果から誰がやっても同じ結果になります。)

また、実はVSANの場合はFTT=2も4+2の場合も7ノード以上で計算をするとすべての場合で(合計)はおなじになります。つまり、各ホストでこれ以上帯域が混雑することはありません。ホスト数が増えれば特定の2ホスト間の通信の平均値はどんどん下がっていきます。(もちろん、ノードが増えるのでスイッチでは大きな容量が必要になります。)

VSANは小規模環境向けだけじゃない!

ここで考えていただきたいのは「小規模環境ならVSANでも良いが、大規模環境はやっぱり従来型ストレージだ」というなんとなくの思い込みについてです。今回の結果は完全にこれは誤りであるということを裏付けています。今回の図では参考につけていますが、従来型ストレージの直近のトラフィックは6ノードで60pt、12ノードでは120ptとなります。仮に今回1となっているトラフィックが1GBであったとすると、VSANを利用している場合4+2で3GB、FTT=2で6GB、いずれも10GBのネットワークだけで構成ができますが、従来型ストレージは120GBの帯域が必要なため、40GBや10GBの回線を複数本準備しなくてはなりません。非常に大きなコストになることは言うまでもありません。

もちろん、IsilonやNetAppのcDotのようなスケールアウトストレージを導入することが主流となりつつある今ではこの議論は単純なものではなくなりつつ有りますが、少なくともVSANも従来型ストレージの弱点を補うアーキテクチャであるということはご理解いただけたのではないかと思います。

確かにVSANは3ノード(厳密には2ノード)から構成できるため、小規模環境にも向いているのは事実ですが、大規模になればなるほどネットワークの観点からは従来型ストレージは帯域が集中してしまうのに対し、VSANは各ノードでトラフィックを分散することが出来るため、大規模な環境も比較的安価なネットワーク機器を組み合わせて構成ができるのです。

Erasure Codingでさらなるスケーラビリティを

前項は従来型ストレージに比べてVSANがトラフィックの分散の観点ですぐれているということのほうが大きな結論になってしまいましたが、Erasure Codingによって50%以上帯域を抑えることができているというのが今回非常に大きなポイントです。VSANは64ノードまで拡張が可能ですのでFTT=2においてもノード数が大きければトラフィックが多くなり、ノード間通信を圧迫してパフォーマンスへの影響が出る可能性があります(12ノードの時の図のように)。しかし、Erasure Codingがあればトラフィックを半分に抑える事が可能です。これは機材調達コストにおいても大きな優位性を生みます。

つまり、新しいVSANはネットワークまで含めて考えていただくことでより大きなコスト削減に繋がるということなのです。

VSAN.nextはいよいよ今週!?

リリースは目前です。今週はVMwareがWebセミナーでいろいろと発表するようですので、いよいよ実際のリリース情報を目にすることが出来ることでしょう。時差がありますが、是非みなさん自身の目でご覧になってください。

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

2016/02/05

★IsilonSD Edgeリリース★

★IsilonSD Edgeリリース★

皆さんこんにちは!

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

今回はついにリリースされたIsilonSD Edgeをインストールしてみます!

※注:本検証はとりあえず動かしてみるということが目的のため運用・障害等に関しては考慮せず検証を行っていることあらかじめご了承ください。

IsilonSD Edgeはリリースされたばかりのため、詳細なインストール手順に関しては別の機会に記載するとして、今回はIsilonSD Edgeの構築概要&ポイントを記載していきます!

001

おっとその前にIsilonSD Edgeとはどういうものかを説明させていただきます。

IsilonSD Edgeとは!

Isilon OneFSのVirtual EditionのことでIsilonSD Edgeという製品名でリリースされました!

Virtual Editionということでこの製品はESXサーバ上で稼動するIsilonとなります。

まさしく昨今はやり!?のSoftware-Defined-Storage(SDS)となります。

 

IsilonSDファミリーとして登場したIsilonSD Edgeは、リモートオフィスやブランチオフィス向けの製品として位置づけられたIsilonSDファミリー最初の製品となっています。

 

IsilonSD Edgeの登場により、お客様は更に容易でお手軽に、有名なIsilonを使用することが出来るようになります!

 これで拠点にIsilonはちょっとと二の足を踏んでいたあなたも、各拠点にIsilonSD Edgeを設置することにより夢のIsilon統合を容易に実施頂けます!

002

この製品は無償版と有償版の2種類があります。

無償版と有償版の差は以下表を参考にしてください。

003

※有償版は物理Isilonと同等の機能が使用可能!!

次にIsilonSD Edgeを構築するための環境要件を以下に記載します。

004

要件は以上となります。

今回は詳細な手順は投稿しませんが、ざっくりとしたIsilonSD Edge構築の流れとポイントを記載したいと思います!

(詳細な手順に関してメーカドキュメントを参考にしていただければと思います。)

 

IsilonSD Edgeを構築する前に各種コンポーネントの説明をしたいと思います。

IsilonSD Edgeを構築するためには、以下2つのバーチャルアプライアンスの構築が必須となります。

  • IsilonSD Edge Management Server:VMware ESXi上に展開されるサーバのことで、vCenterと連携しOneFS Virtual Machineを、ESXi上に展開するためのゲートウェイサーバとなります。IsilonSD Manegement Serverは、OVAファイルとして提供され、WebClientから展開することによりインストール可能となります。
  • IsilonSD Management Plug-in:VMware vCenterプラグインとなり、vCenter ServerからOneFS Virtual Machineを展開・管理するためのプラグインとなります。  このプラグインはIsilonSD Management Serverに、VMware vCenterを登録することにより自動でインストールされます。
  • OneFS virtual machine:OneFSを提供する仮想マシンとなります。OVAファイルで提供されるがインストールは、IsilonSD Edge Management Serverからのインストールとなります。

 

IsilonSD Edgeをインストールした場合の全体構成例を以下に記載します。

ポイント:OneFS Virtual Machineに設定するディスク1つに対して物理ディスク1つを割り当てる必要があります。

005

ここからインストールの流れに入って行きたいと思います。

1.IsilonSD Edgeのダウンロード

以下URLよりダウンロードが可能となります。

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

※IsilonSD Management ServerとOneFS Virtual Machieは1つのファイルでダウンロードされます。

2.IsilonSD Management Serverの展開を行います。

Web Clientの「OVFテンプレートのデプロイ」から展開します。

※特に難しいことは無くウィザードに沿って設定を入れれば問題なくインストール可能。

3.IsilonSD Management Serverの設定(ネットワーク/パスワード等)

細かい内容は今後記載するがここでの注意点はアカウントが2つあることです。

①     Administrator:Management Serverに関連するバックエンドタスクを管理するユーザで主に以下を管理する。

    • Management Server DBのバックアップ/リストア
    • ログの収集
    • 管理サーバへのシリアルアクセス
    • Management Serverのアップグレード

②     Admin:Management Serverに関連するフロントエンドタスクを管理するユーザで主に以下を管理する。

    • ライセンス管理(追加/削除)
    • vCenter Serverの登録
    • ユーザのパスワード変更
    • OVAテンプレートの管理

ポイント:私はドキュメントをちゃんと読まずにセットアップしてしまったためユーザが2つあること、パスワードがデフォルト設定になっていることがわからずつまずいてしまいました。ドキュメントを読みながら構築することをお勧めします。

 006

4.vCenter Serverの登録

Management ServerにWebアクセスを行い対象のvCenterを登録します。

007

IsilonSD Management ServerにvCenterを登録すると下記のようにPlug-inが自動で登録されます。

008_2

5.IsilonSD Edge OVAファイルをManagement Serverにアップロードします。

009

6.VMware Web ClientよりIsilonSD management plug-inを使用してIsilonSD Edge OVAファイルをESXiサーバに展開します。

ポイント:IsilonSD Management ServerではなくPlug-inを用いてVMware Web Client上から展開します

ポイント:IsilonSD Management ServervCenterを登録した後ブラウザを一度すべて閉じて再度VMware Web ClientにアクセスしないとPlug-inが有効にならないので注意!また、Web ClientIEで開いているとうまく動作しない場合があるので要注意!

私はここでハマリました・・・

010

011

7.OneFS Virtual Machineの設定

OVAファイルを展開する際にウィザードによりOneFS Virtual Machineの各種設定を行います。

ポイント:クラスター容量を1152GB以上にしないと設定が先に進めない

012

ポイント:NASでマウントしているディスクは表示されなかったためSANディスクまたは内蔵HDDが必要になります

013

8.デプロイ完了後OneFS Virtual MachineにWebアクセスを行うとIsilon管理GUIにアクセスされるので完了となります。

GUIOneFS 8.0GUIとなっていました!

014

またOneFS8.0から搭載されたCloudPoolsもGUI上に表示されています!

015

以上がインストールの簡単流れとはなりますが、非常に簡単IsilonSD Edgeを導入することが出来ました!

シミュレータと違いディスクがあれば容量もかなり使えるのでこのIsilonSD Edgeの用途に関してはかなり幅が広がりIsilonがよりいっそう便利になると私は確信しています!

今回は詳細な手順は省きましたが今後はインストール手順や機能検証・障害検証を行いたいと思っているので検証が完了した際にはまたこのネットワールドらぼに投稿したいと思います。

Isilonに関しては以下HPまで!

http://www.emc.com/ja-jp/storage/isilon/index.htm

では、また次回!

2016/02/02

クラウドにバックアップするには?(クラウドゲートウェイ編)

 前回、NetBackupを使用したクラウド(Amazon S3)へのバックアップ方法をご紹介させていただきました。この方法も良いのですが、いくつか課題もあります。

課題①NetBackupはAmazonやGoogleのクラウドには対応しているが、Microsoft Azure等の他のクラウドにはバックアップできない。

課題②NetBackupからクラウドへのバックアップではバックアップデータの重複排除ができないため、クラウドストレージの使用量を削減できない。

課題③NetBackupがアクセラレーター機能で永久増分バックアップができるのは、ファイル・VMware・NDMP(NetAppのみ)だけで、SQL ServerやOracle、Exchange等のアプリケーションやHyper-Vの仮想環境などのバックアップではアクセラレーター機能が使えないので、クラウドへのバックアップ時間を短縮できない。

課題④バックアップはNetBackupのアクセラレーター機能の永久増分により転送量を少なくできても、リストアは対象データが丸ごと転送されるので復旧に時間がかかる。

上記の課題に悩んでいる方、安心してください!解決できますよ!
では、どうやって解決するのかと言うと、クラウドストレージゲートウェイ製品を使用します。

クラウドストレージゲートウェイは、オンプレミスのバックアップサーバとクラウドストレージを仲介する役割を持つアプライアンス(物理or仮想)です。オンプレミスのネットワーク上に配置して、バックアップサーバからは、NAS(Network Attached Storage)やVTL(Virtual Tape Library)の様に見えます。バックアップソフトはオンプレミスのNASやVTLに対して、従来のバックアップと変わらない方法でクラウドストレージゲートウェイにバックアップするだけで、後はクラウドストレージゲートウェイが裏でクラウドストレージにデータを転送してくれます。

クラウドストレージゲートウェイとしては、AmazonのAWS Storage Gatewayが有名ですが、S3やGlacierなどのAmazonのクラウドストレージにしかバックアップできませんし、重複排除ができませんので、上記の課題を解決することはできません。

Nbugw1


そこで、全ての課題を解決するのが、EMC社のCloudArrayNetApp社のAltaVaultといったサードパーティのクラウドストレージゲートウェイ製品です。この2つのストレージゲートウェイ製品は、バックアップサーバからはCIFSやNFSを提供するNASのように見えます。各製品の説明は各製品担当の方のブログにお任せするとして、ここではバックアップソフトの観点でサードパーティのクラウドストレージゲートウェイ製品がどのように前述のバックアップの課題を解決するのか見ていきましょう。


課題①
NetBackupはAmazonやGoogleのクラウドには対応しているが、Microsoft Azure等の他のクラウドにはバックアップできない。

解決①:サードパーティのクラウドストレージゲートウェイ製品はAmazon やGoogleは勿論のこと、下図の通り、Azure等の様々なクラウドに対応しています。きっと、お客様が使用したいクラウドストレージも含まれていることでしょう。 Nbugw5     <AltaVault 4.1>          <CloudArray 6.0>

  

課題②NetBackupからクラウドへのバックアップではバックアップデータの重複排除ができないため、クラウドストレージの使用量を削減できない。

解決②: AltaVaultやCloudArrayは重複排除機能があるため、クラウドストレージゲートウェイ上にバックアップした後、バックアップデータを重複排除し、ユニークなデータのみをクラウドストレージにデータを転送しますので、クラウドストレージへの転送量を抑えることができます。また、ストレージ容量を削減することにより、クラウドストレージのランニングコストも抑えることが可能です。重複排除処理もクラウドストレージゲートウェイ上で行われますので、バックアップサーバに負荷を掛けることもありません。

Nbugw4_9

 

課題③NetBackupがアクセラレーター機能で永久増分バックアップができるのは、ファイル・VMware・NDMPだけで、SQL ServerやOracle、Exchange等のアプリケーションやHyper-Vの仮想環境などのバックアップではアクセラレーター機能が使え

ないので、クラウドへのバックアップ時間を短縮できない。

解決③:クラウドストレージゲートウェイはオンプレミス環境にあるため、インターネット経由でクラウドストレージに直接バックアップする場合と比べて、短時間で確実にバックアップすることができます。また、バックアップ方法も従来のNASに対しての手法と変わりませんので、特定のアプリケーションのみがサポートということもありません。


課題④
バックアップはアクセラレーター機能の永久増分により転送量を少なくできても、リストアは対象データが丸ごと転送されるので復旧には時間がかかる。

解決④:リストアの際もオンプレのクラウドストレージゲートウェイからリストアするため、高速です。リストア対象のデータがクラウドストレージゲートウェイのキャシュ上にない場合でも、クラウドストレージから重複排除されたデータのみをクラウドストレージゲートウェイ転送するため、データ取得(リクエスト)にかかる料金も抑えることが可能です。



バックアップソフトの機能でクラウドストレージにバックアップする場合と比べて、クラウドストレージゲートウェイ製品の費用が追加で必要にはなりますが、重複排除によるクラウドストレージ容量の削減やリストア発生時のデータ転送量の削減によるランニングコストのメリットとバックアップ・リストアのパフォーマンス向上による運用のメリットを考えると、決して高くはないかもしれません。

まずは、クラウドストレージゲートウェイ製品をちょっと触ってみたいけど、環境を作るのが面倒という方は、下記のTest DriveでNetBackup7.7を使用してのAltaVaultへのバックアップを無料で試すことができます。

Test Drive AltaVault backup to AWS S3 (日本語版利用ガイド)

このTest DriveのAltaVaultのCIFS設定では、Everyoneにアクセス許可が設定されていますが、実際の運用ではアクセス許可を設定するものと思います。その際には、NetBackupのサービスのアカウントをCIFSにアクセスできるユーザーに変更する必要がありますので、ご注意ください。

参考:Configuring credentials for CIFS and disk storage units

クラウドストレージゲートウェイを使用したクラウドバックアップ方法はNetBackupだけでなく、CIFS/NFSにバックアップが可能なバックアップソフトであれば、どのソフトでも技術的には適用可能です。お客様の環境や要件に合わせて、最適なクラウドバックアップ方法・製品を選択していただければ幸いです。

担当:臼井

最新のVMware VSANに搭載される 「Erasure Coding」とは何か?

新しいVSANは最強のVMware用ストレージになる!?

VMware VSANは6.0でVMFSベースのファイルシステムから、VSAN専用のVSANFSへとファイルシステムを転換し、(VMFS-Lを悪くいうわけではありませんが、)フォルトドメイン機能の実装によってデータセンタトポロジに合わせたデータの保全性を実現しています。パフォーマンス面でもオールフラッシュモードが搭載され、ミッションクリティカルな領域でも十分に利用出来るようになってきました。それから半年と空けずにリリースされたVSAN 6.1ではいよいよ様々なデータサービスがVSAN上に実装されてきています。2ノードから始められるVSANもその一つですし、(まだいろいろと課題はあるものの)コモディティのサーバだけでメトロクラスタを実現する事も可能になってきました。

Vsan61

非常に短期間で様々な機能を実装しているVSANの次なる一歩は何でしょうか? VSAN.nextのベータとして公開され、周知になっている機能は以下の3つです。

  • Compression(圧縮)
  • Dedupe(重複排除)
  • Erasure Coding(* 本日の本題)

圧縮・重複排除は様々なストレージ上にすでに実装され、みなさまはよくご存知のテクノロジーだと思いますが、3つめのErasure Codingとは一体何なのでしょうか?

そもそも「Erasure Coding」って何?

英単語の意味をしらべると「Erasure」は消去、抹消と言った意味であり、「Erasure Coding」といった場合、「抹消されてしまった情報」についての操作となります。わかりにくいですね。もっと身近でわかりやすい実装を上げるとRAID5やRAID 6の様な技術で、失われてしまったデータを残ったデータから復元するためのテクノロジーのことです。

WikiPediaにも「情報産業におけるErasure Codingはforward error correctionのことを指す」とあり、つまり情報の伝達の際に紛れ込むエラーを訂正する実装のことだと記載されています。

これがVSANに載ると何がいいのか?

現在(VSAN 6.1)まではこのエラー訂正のための機能は実装されておらず、ノード(サーバ)障害への対応にはレプリカを作成するという実装になっています。

Vsanftt1上の図にあるように、1ノードへの耐障害(FTT=1)で構成した場合には、単純に実際に仮想マシンが使える領域サイズの2倍のサイズが物理ディスク上で消費されてしまいます(今回は簡単のためWitnessについては説明しません)。逆を言うと最低限の障害に備えるためにもディスクの消費が2倍になってしまう事になります。

サーバに入れるディスクはストレージに内蔵されるディスクに比べ比較的安価であることを考えるとこの実装でも十分なケースもあるとは思いますが、RAID5、RAID6を知る我々からすると少し物足りなく感じた方もいらっしゃったのではないでしょうか。これを解決してくれるのがErasure Codingのテクノロジーです。

Erasure Codingを利用して1ノード障害耐性(3+1)を実現した場合は以下の様になります。

Vsan31※上の図はあくまで3+1を考えた場合のデータサイズ量をわかりやすくするための図で、実際にリリースされるVSAN.nextの実装とは異なるはずです。

この場合、各々のノードに格納されるデータはVMDKのサイズの1/3となり、パリティと合わせると、ディスク上で実際に消費されるデータはもとの仮想マシンのサイズの 4/3 ≒ 1.33倍で済むことになります。

実データ (1/3) x 3ノード + パリティ (1/3) x 1ノード = 4/3 ≒ 1.333・・・

またVSANのクラスタノードサイズが大きくなれば4+2の構成も取ることが出来るようになり、この場合は

実データ1/4 x 4ノード + パリティ (1/4) x 2ノード = 6/4 = 1.5

となります。

お気づきになった方もいらっしゃると思いますが、この方式を利用するためには最低でも4ノードまたは6ノード以上の構成が必要になってしまいます。(実際に正式にリリースされた後に、サポート対象になるのがどの構成で最低何ノード必要になるのか改めてご確認ください。)

また、もう一つの注意点として、ネットワーク障害時の耐性も考えておく必要があります。上の3+1の例では4ノードのうち2ノードがネットワークアクセスできなくなってしまった場合にはデータを正しく訂正することができません。NICの冗長化、スイッチなどの構成にも注意が必要です。

圧縮・重複排除と合わせて利用可能に

今回のErasure Codingが利用できるレベルのクラスタサイズであれば、従来のストレージ装置と同じレベルのスペース消費でVSANを利用することができます。更に新たに圧縮、重複排除の機能も追加されるため、いわゆる新世代のストレージと同じく、容量の消費を削減しての利用が可能になります。

さぁ、VSAN.nextを待ちましょう!

すでにあちこちで騒がれていますが、リリースは目前です。今回ご紹介した以外にも様々な機能が搭載されてくることでしょう。是非次世代のVSANにご期待ください!

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

2016/02/01

clustered Data ONTAPパフォーマンス監視への道のり⑤

今回はOnCommand Performance Managerの簡単ですが操作方法を記載したいと思います。

-------

OnCommand Performance Manager for VMware Virtual Appliances

操作概要

-------

最初にログインしますと下記画面(ダッシュボード)が表示されます。

クラスタ単位で表示されます。閾値を超えたクラスタなどひと目でわかります。

Opm_blog1_2

管理できるオブジェクトは一覧は下記になります。

Opm_blog2

ダッシュボード画面から各管理オブジェクトへアクセスが出来ます。

今回はSVMのオブジェクトページへアクセスしてみます。

アクセスしますと、上部に下記項目が表示されますので何処がボトルネックになっているか確認できます。

Latency
IOPS
MBps

Opm_blog3

オブジェクトページの下部には”Performance Explorer "が表示されます。

より詳細なグラフが表示されます。必要な項目追加も可能です。

Opm_blog4

”Performance Explorer "比較したいオブジェクトも追加可能です。

下記画面はボリュームを追加しています。

Opm_blog5_2ユーザ単位に閾値設定、変更も可能です。

しかも閾値を超えたアラートに関してはメール送信も可能です。

Opm_blog6_3

-------

OnCommand Performance Manager for VMware Virtual Appliances

まとめ

-------

特徴、注意点をちょっとおさらいします。

・Clustered Data ONTAP 8.2.x and 8.3.x 専用
・性能データの最大13ヶ月(390日)の保存(変更不可
 →5分x30日 +1時間x12ヶ月
・5分間隔で性能データ取得(変更不可)
・15分間隔で構成上の更新(変更不可)
・ユーザ定義とシステム定義の閾値によるアラートの通知
ライセンス無料

高スペックな仮想マシンが必要ですが、個人的には結構使えそうな印象を持ちました。

しかし、ちょっと残念なのが、、、、Excelなどのファイルに”エキスポートが出来ない”ことです。

余談ですが、OnCommand Performance Managerとは別に、OnCommand Insightなる製品があるそうです。

有償ですが、なんと他ベンダーのパフォーマンス情報も取得できるとのこと。。

機会がありましたら、OnCommand Insight 記事も書きたいと思います。

もし興味がある方がいましたら、下記URLからご連絡お願いします。

【NetApp製品問い合わせ先】

/長谷部(ハセベ)