« 2015年12月 | メイン | 2016年2月 »

2016年1月

2016/01/27

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

前回に引き続き、CloudArray第二回です!

 ※ CloudArray Ver6.0.3~6.0.4での検証結果を基にしています。

EMC担当の片山です。今回はCloudArrayのよく使いそうな機能に絞って解説していきたいと思います。

Read/Writeの動作フローや、インクラウドスナップショット、自動バックアップ、帯域制御、クラウドマイグレーション機能などについて順を追って説明していきます。

まずはCloudArrayの基本的Read/Write処理についてです。
 

 ◆  Write処理フロー

ホストからのWrite処理はCache領域に書込まれ、ACK応答がホストに返されたタイミングでホストへの書込み動作が完了します。1

Cache領域へのWriteが完了するとCloudプロバイダへのデータ送信のために準備が自動的に開始されて圧縮と暗号化(オプション設定)に応じて、CloudArray側の任意のタイミングでCloudプロバイダにデータがReplicationされます。CloudへのReplicationのデータ処理アルゴリズムとしては圧縮と暗号化が完了次第に順次転送するというFIFO(先読み先出)方になります。

3_2

※ Dirty Page=CacheからCloudへReplicationが完了していないデータの事

また、検証時の動作確認ではCloudへのReplicationが終了していないデータ(Dirty Page)がCache容量の90%に達すると、Dirty Page値が70%程度になるまでCloudArrayへの書込みが一時的に停止することが確認できました。

また、CloudArray自体のCache制御アルゴリズムですが、LRU(Least Recently Used)方式を採用しているとの事です。LRUとは「最も参照頻度が低いものを削除」する方式です。

◆  Cacheヒット時のRead処理フロー

 Read要求がホストから送られてきた時、CloudArrayはCache領域からホストに対して、Read対象のデータを送信して処理が完了します。

※ CacheヒットとはCache上にデータが存在した場合

2_3

 

◆  Cacheミス時のRead処理フロー

 Read要求がホストから送られてきた時、データがCache領域になかった場合はCloudプロバイダへデータを要求します。CloudプロバイダからCloudArrayにデータが受信され、CloudArrayで復号化して処理が完了します。Cloudより受信したデータはCache領域に配置されて、次回のRead要求の際に利用されます。

※ CacheミスとはCache上にデータが存在しなかった場合

2_5

 そのため、Read要求があったデータがCache領域にない場合、Cloudプロバイダからデータ送信が必要となる為にRead要求の待ち時間のためのアクセスがCloud経由で遅延する可能性があります。

 

インクラウドスナップショット

スケジュールもしくは手動にてVolume毎にスナップショットを作成できる機能で、スナップショットの実データはCloudArrayのCacheとCloudプロバイダ上に存在します。

1_5
インクラウドスナップショットはEXPOSEボタンを押すだけでアクセス可能になり、またWritable(書き込み可能)スナップショットなので、スナップショットに書込まれたユーザデータの差分はメインVolumeと同一のCacheを共有して保持され、そのままCloudプロバイダ上にもReplicationされる動作を行います。


◆  Replicationの帯域制御機能

Bandwidth設定はCloudArrayからCloudプロバイダへのReplication通信の帯域制御設定ができます。GUI操作で非常に簡単に曜日、時間でReplication帯域幅設定が可能です。

5_2

 

◆  CloudArray構成情報の自動バックアップ

前回の記事でも少し触れました。CloudArrayには自動バックアップ機能があります。CloudArrayの設定情報をCloudArrayポータルサイトに定期的に自動バックアップが行われています。

リストアする場合、災対側にOVFを展開した新たなCloudArrayをデプロイして、CloudArrayポータルサイトからダウンロードしたバックアップファイルを適用することで設定情報がリストアされます。CIFS共有設定はもちろんCloud上に保存された最新のデータも参照することができます。但し、複数箇所にリストアされてしまった場合は最新でリストアしたCloudArrayがCloudプロバイダに対して1対1でアクティブになるようです。

7
上の画像、CloudArrayポータルサイトから最新版のCloudArrayバックアップデータがダウンロード可能です。

8_2

もちろん、CloudArrayのGUIから直接、設定情報のバックアップを取得することもできます。

 

◆ クラウドマイグレーション機能

 こちらは名前の通りでCloudプロバイダを別に切り替えるときに利用する機能です。イメージとしてはCloudプロバイダAよりCloudプロバイダBに変更したい場合に利用します。

9
 今回、検証した例は以下の図の手順で行いました。S3のあるアカウントのバケットから、別のS3のアカウントのバケットにCloud上のデータを移行してみました。現バージョンでちょっと気になる点が、サービス提供しているCIFSボリュームが「10GB」であれば、Cacheも10GB必要になります。(Volume=Cache)また、移行対象の旧Cloudプロバイダからの全コピーが実行され、新Cloudプロバイダに対して、フルレプリケーションが動く仕組みになります。

10_2


 他にもまだ機能はありますが、次回よりセットアップを始めていきたいと思います。

まずは触ってみるのが一番です!それではまた第三回でお会いしましょう~。

記事:片山

今回の記事一覧はこちら

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

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

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

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

2016/01/11

ESXiホストのCPUとメモリの構成についての考察

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

本記事の原文はInsights into CPU and Memory configuration of ESXi Hostsで閲覧可能です。

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

最近、Satyam Vaghani氏はPernixData Cloudについての記事を公開しました。要約するとPernixData CloudはPernixData Architectを理論的に進化させた次世代製品で、仮想化データセンタとそのインフラストラクチャ、アプリケーションへ可視性と解析を提供するものといえるでしょう。

前提として、私はArchitectが大好きですが、世界中のお客様から聞かれる共通した疑問で頻繁に上がるものとして、他の会社はどのように仮想化データセンタを運用し、設計しているのか?という物があります。どんなシステムを利用し、その似たようなワークロードに対して、そのシステムのパフォーマンスはどうですか? 多くのデータセンタの設計者は自身が仮想化インフラストラクチャを設計するための材料のリストに対する支払いが適切なのかどうか、ということに奮闘しています。予算を得るというためにもこれは重要な事です。ハードウェアの構成について議論している時にこんなことを聞く人も多いのではないでしょうか? 「フェラーリを作るのか?メルセデスで十分じゃないか?」 PernixData Cloudでは、データセンタのトレンドを見ることが出来るのです。例えば、特定のハードウェアやアプリケーションの分布の詳細です。あたりを這いまわって情報を集めるのではなく、現在のデータセンタの傾向を曲線の先から読み取り、それに合わせていくことが可能になるのです。もちろん、まだこのソリューションは開発の途中ですから詳細までをお話することはできません、ですが、時々、我々が今、目の当たりにしているものを覗き見出来るようにするぐらいはいいと思っています。

この数日間、データセットの一部を利用して、8000ホストとそのCPU、メモリ、ESXiのビルド番号などについて分析し、典型的なホストの構成についての分布を考察しました。

CPU ソケット構成

興味があったのはCPUソケットの構成の分布でした。データセットを分析すると、デュアルソケットCPUの構成がもっとも多い構成であったことが明らかになりました。データセット内ではシングルCPUの構成がクアッドCPU構成よりも多くあり、クアッドソケットのCPUが実環境のワークロードにより多く利用されているのに対し、シングルCPUの構成は典型的には検証・開発・ラボのサーバでした。そのような状態ですが、大部分はデュアルCPUソケットのシステムで、一部で、クアッドCPUソケットのシステムがあるという状況です。このデータセット内には8ソケットのサーバはほとんど少数派ですが、驚くほど詰め込んだ構成も興味を引きます。その中には15コアのCPUを搭載しているものまであったのです。120CPUが1台のホストに! さぁ、CPUのパワーの話をしよう。

Fig343

CPUコアの分布

CPUのコアの分布はどうだろう? もっとも多かったのはESXiホストあたり16コアという構成でしたが、CPUソケット数の話がなければ、どっちのCPU構成のほうが多いのか推測しかできません。

Fig344

デュアルCPUソケットのESXiホストのコアの分布

デュアルCPUソケットのESXiホストのデータセットのみにズームインしてみると、8コアのCPUが最も利用されていることが明らかになります。さっきまでのデータセットと比較して、クアッドコアや6コアのシステムの分布の減衰が緩やかになっています。6コアは2010年に登場してきました、2016年には多くが更新を迎えると予測できます。2016年になってから、再びCPUの構成の分布をトレンド分析してお見せしたいと思います。

Fig345

クアッドソケットCPUシステムのコア数

クアッドソケットCPUシステムはどうでしょうか? どのCPU構成が最も多いでしょうか? クアッドソケットのCPUシステムの構成の場合では10コアを内蔵するCPUがスイートスポットであるとわかりました。

Fig346

メモリ構成

サーバのメモリ構成に目を向けると、これらのシステムのコンピューティングパワーを明確に描き出すことができます。デュアルソケットサーバで最も多いメモリの構成は? 256GBか384GBがもっとも多い構成であるということがわかります。今日のサーバはかなり太っちょになってきていますね。

Fig347

デュアルソケットの8コアのサーバのメモリ構成のみを分析すると、メモリの分布は以下のようになります:

Fig348

クアッドCPUのサーバのメモリ構成は?

Fig349

NUMA

クアッドCPUソケットのESXiホストにおいては512GBが最も多い構成です。サーバが適切に構成されている前提ですと、この構成はシステムのそれぞれのNUMAノードに同じだけのメモリを割り当てているはずです。デュアル、そしてクアッドのCPUソケットのシステムではいずれも128GBがそれぞれのNUMAノードに割り当てられている構成が最も多いということです。

ESXiのヴァージョンの分布

デュアルそれから、クアッドのCPUソケットシステムそれぞれでESXiのヴァージョンがどのように分布しているかについても調べてみました。5.1.0がデュアルCPUシステムでは最も多い一方で、クアッドCPUソケットのマシンの多くではESXiは5.5がインストールされていました。

Fig350

もっといろいろと

Satyam氏と渡しはもっといろいろな結果を我々のデータセットから公開していこうと思っています。データセットは急速に膨らんで、地球上にある様々なデータセンタについての知見を蓄えつつ有ります。それから、アプリケーションや仮想化レイヤ自身などの別の次元での分析もカバーしていきたいと思っています。惑星のデータセンタに対しての興味深いご質問について、お気軽に私に質問してください。我々の出来る限りでお見せします。私のTwitterもフォローして下さい。@frankdenneman

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

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

2016/01/04

VDIのパフォーマンスをFVPとLakeside SysTrackで最大化

本ブログエントリーはPernixData社のSystems EngineerであるJoshua Spencer氏のブログの翻訳版です。

Fig341


PernixData社にジョインする前はVMwareでエンドユーザーコンピューティングのスペシャリストとして5年間過ごしています。その前は12年間にわたってデスクトップエンジニアリングのスペシャリストとして情報システム部門のサポートをしていました。

Joshuaはトレド大学でビジネスにおけるテクノロジー分野での学士号と修士号を保持しています。10年近くにも及ぶデスクトップ、サーバ、アプリケーション仮想化テクノロジーと幅広いハンズオンの経験を持ち、国内外でその経験を活かして活躍しています。

本記事の原文はMaximizing VDI Performance with FVP and Lakeside SysTrackで閲覧可能です。

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

VMwareで8年間にもわたってVMwareのVDIの実装、販売、そしてトレブルシューティングをしてきた中で、私はこのテクノロジーの浸透を阻害する幅広く蔓延している障壁を見続けてきました。 ーそれは、ストレージのパフォーマンスですー。「パフォーマンス」という言葉を強調しておきます。長きにわたって、ストレージはほとんどキャパシティ(容量)という意味でだけ、評価されてきました。VDIが離陸し始めた直後は、情報システム部門は単に、エンドユーザーのローカルハードドライブにどれだけのデータが入っているか、ということにだけ注目していたのです。しかし、数百、数千のデスクトップを仮想化するという状況において、人々は突如立ち止まってしまいました。結局のところ、ローカルの100GB程度のハードドライブをリプレースすることは、同じキャパシティのエンタープライズクラスのストレージ装置リプレースすることに比べると遥かにコストがかかることだったのです。

展開のテクニック

VDIのベンダーが展開のテクニックを登場させるまでにさほど長くはかかりませんでした。例えばVMwareのコンポーザーなどがそれです。これによってキャパシティ要件を下げることが出来るのです。実際、これはうまくいきました。顧客はこれによってこれまでは一つのLUNにほんの僅かしか仮想マシンを展開できなかったところが、突然数百もの仮想マシンを展開できるようになったのです。簡単な算数を使ってこれを可視化してみましょう:

従来からのテクニック

LUN1 = RAID5構成の 500 GBのディスクドライブ x 5本 = 2 TB のストレージ利用可能領域 

2TB ÷ 100 GB のディスクドライブ = LUN1上には 20の 仮想化デスクトップ

*** シンプロビジョニングや他のストレージ装置由来のテクノロジーでこの数は40~60もしくはもっと多くなりますが、これについてはコンポーザーの概念を通して次の節でお話します。

*** LUNを完全に埋めてしまうようなことは望ましくありませんが、単純化のためにこの数字を利用します。5本のディスクドライブで20のWindowsインスタンスを動作させているということだけご注意ください。

(5本のドライブで20のWindowsインスタンスを動かしています。)

コンポーザーを利用したリンククローンでの展開

コンポーザーのようなものを利用すると、算数は随分違ってきます。:

100 GB (マスター) + 100 GB (レプリカ) + (デスクトップ数 x 5 GB (クローン))

お分かりのとおり、キャパシティの観点からは同じLUN上で300以上のデスクトップを展開することが可能になりました!

IOPSとWindows OS

残念ながら、この問題を解決したところ、別の問題が出てきました。これは従来のアプローチでモノリシックな共有ストレージシステムを利用するというアプローチでは解決するのがとてもむずかしいということがわかってきます。ーつまり仮想マシンのパフォーマンスですー。御存知の通り、WindowsのデスクトップOSは非常に意地汚いものです。これはPC内の単一のドライブを専有して利用することを想定して設計されているからです。設計からして、Windowsは利用できうる限りのディスクのパフォーマンス(IOPSとスループット)を利用しようとします。これはエンドユーザーのユーザーエクスペリエンスを最善に保つために行われます。ですから、ローカルのSSDのような高速なドライブを利用することで応答時間を改善し、加速することができます。VDIではWindowsはLUNのIOPSとスループットを他の動作しているWindowsインスタンスと共有することを強制されます。新しい問題を簡単な算数でもう少しわかりやすくしてみましょう:

LUN1 = RAID5構成の 500 GBのディスクドライブ x 5

15K SASドライブそれぞれはピーク時で200 IOPSの能力が有ります。ReadとWriteの割合はデスクトップのワークロードによって変動します(ブート、ログオン/ログオフ、定常状態で大きく変わります)。270IOPS(R:W = 10:90 ーログオンストームの間など)~ 770IOPS(R:W=90:10 ーブートストームの間等)の間のあらゆる場合が想定されます。

* IOPSの計算は簡略化していますが、この例で利用できるようにしてあります :

  • 最大 Read IOPS (100% Readと想定) = 200 IOPS x 5 本 = 1,000 IOPS
  • 最大 Write IOPS (100% Writeと想定) = 200 IOPS x 5 本 ÷ 4 (RAID 5のWriteペナルティ) = 250 IOPS

計算をシンプルにするために、一般的な「定常状態」のシナリオを用いると、500 IOPSを利用できることになります。これは R:W がきっちり 65:35 の割合だと想定ことになります。

  • 500 IOPS / 20 仮想マシン = デスクトップごとに 25 IOPS
  • 500 IOPS / 300 仮想マシン = デスクトップごとに 1.6 IOPS

Windows デスクトップにどれだけのIOPSが必要か、ということは多くの誤解が有りますが、思い出していただきたいのはOSがハードドライブを専用するという設計になっているということです。平均的に7200 RPMのドライブは75IOPS程度です。上の計算から明らかなように、いずれのシナリオでも物理PCと比較して十分なユーザーエクスペリエンスを提供できないのです。しいて言えば、最初の想定のほうがちょっとばかり2つ目よりマシなぐらいでしょうか。

つまり、根本的な問題があるということなのです :

仮想マシンごとのコストの天井はデスクトップごとに専属のディスクを用意する場合です。そうでなく、多くの仮想マシンをスピンドル内に統合しようとするとパフォーマンスは地に落ちてしまうのです。

どうやってこれを解決するか?

業界はこの問題を解決するために何年も必死になって努力をしてきました。様々なキャッシュソリューションが登場していますが、制限事項や複雑性で謎かけを行うようなものであり、ユーザーエクスペリエンスのさらなる悪化や、情報システム部門のさらなる頭痛の種となったりもしています。殆どのキャッシュソリューションはRead IOPSにだけフォーカスしており(実際にはRAIDのWriteペナルティによってWriteのほうがもっと大きな問題になるにもかかわらず)、更に、ゲストOS内にエージェントの導入が必須であったり、特定のホストにデスクトップをピン留めしてしまったり、ストレージのLUNやデータストア、ゲストOS内のディスクなど、ストレージの複雑さを更に繰り返すことで複雑性を上げてしまうものになっています。

フラッシュですべて救済できるか?

フラッシュメディアがメインストリームになったころ、ついに、ストレージのパフォーマンス問題を解決することを約束するというハイブリッドやオールフラッシュベンダーの爆発的な増加を目の当たりにしました。こうしたストレージ装置は従来型の回転するディスク装置よりも遥かに優れたパフォーマンスを提供する一方で、非常に高価でした。こうした時に問題になるのはVDIの展開が期待通りに進まなかった時にどうするのか?ということです。使われもしないで鎮座する高価なストレージが残り、仮想マシンごとのTCOは増加します。期待以上に早く展開が進んだら?今度は高価で複雑なストレージの入れ替えと廃棄を考えなくてはなりません。今はノンパーシステントデスクトップで要件が足りると思っていたけれども、最終的にはパーシステントデスクトップが必要になったら?もしも、コストを算出した時に期待していたレベルで、重複排除が動作しなかったら?このようなことが起こると、VDIのプロジェクトは墜落するか、情報システム部門がエンドユーザーの要求に見合うだけのパフォーマンスが得られる経済性を構築するまで速度を失ってしまいます。

VDIに求められるストレージ要件を理解する

ちょっと振り返って、、、もしVDIのためのストレージを購入しようとしているとして、どれだけのIOPSが実際に必要なのかを知る必要が無いとしたらどうでしょうか?答えはもちろん「YES」です、しかし、言葉以上に複雑です。もし、WindowsデスクトップOSがブートすると、Read:Writeは90:10の割合のI/Oアクティビティになるということはザラです。ですが、Windowsデスクトップにログインしようとすると、その数字は簡単に反転します。100もしくは1,000のWindowsデスクトップがブートアップし、ユーザーが次々とログインをはじめたと想像してください。これは「ブートストーム」と「ログインストーム」として知られています。全ての仮想マシンが出来るだけ自分のためにディスクのパフォーマンスを利用しようとして争い、共有ストレージ上に大惨事が起こります。ストレージ装置内のディスクコントローラーは過剰不可となり、ストレージネットワークはパンパン、ディスクはReadとWriteのリクエストにはついていけず、座っているエンドユーザーは何分も待って、ようやくデスクトップが利用可能になるのです。

Lakeside SysTrack

数年前、私はLakeside Softwareという会社を紹介されました。彼らはSysTrackという業界をリードするエンドユーザー監視と解析プラットフォームを提供し、エンドポイントの定量的なデータによって興味深いデータを提供しています。SysTrackはエージェントベースのソフトウェアソリューションで、継続的に数千種ものパフォーマンス計測値を物理PCから収集します。そして、(ストレージも含め、他のインフラストラクチャコンポーネントにおいて)どれだけのパフォーマンスが、環境を上手く仮想化する際に必要なのかというレポートを生成します。私がWindows OSがディスクに対してどれだけの要求を出しているのか、そしてそれが1日の中でどんなにも変動しているのかということを視覚的に見たのはこのアセスメントの最中が初めてでした。以下にこの概念をよく表したSysTrackのレポートのサンプルを掲載します:

一週間の統計

統計 ディスク I/O (IOPS) SAN ディスク Read (IOPS) SAN ディスク Write (IOPS) SAN
最小 0.00 0.00 0.00
最大 12,000.87 10,872.56 4,310.43
算術平均 836.58 512.57 352.29
分布平均 70.91 35.88 33.39
標準偏差 1,776.85 1,178.10 717.32
80% 1,085.26 581.76 500.45
90% 3,500.18 2,092.61 1,413.52
95% 4,751.86 2,879.40 2,120.55

IOPSのピークは12,000だということですが、95%の時間帯においては4,751 IOPSしか利用されていません。言い方を変えると95%もの時間はほぼ2/3の共有ストレージの能力は何もせず静かにしているだけということです。この典型的な顧客は大部分の時間には利用されもしないストレージのパフォーマンスのために60%も余分なパフォーマンスを、ユーザーエクスペリエンスの確保のために購入しないといけないということになるのです。

PernixData FVPの活用

ここで、PernixData FVPが輝きを放ちます。ホストサイドのスケールアウトパフォーマンスを利用することで情報システム部門はホストごとに数万のIOPSという設計を行うことが可能です。ストレージを過剰に購入するコストを抑制し、物理を超えるユーザーエクスペリエンスを提供し、デスクトップあたりのコストを抑えることが可能になります。しかも、仮想マシンや既存のストレージ装置への変更は一切なくこれが実現できるのです。仮想マシンやホストをVDI環境の成長に合わせて追加したい? FVPがあれば、vSphereクラスターがスケールアウトするのに合わせて、ストレージのパフォーマンスも追加が可能なのです。

Fig341_2FVPを利用することで、ホスト側でストレージのパフォーマンスを提供することができ、ストレージ装置は95%の分布でサイジングすることが可能です。全てのWindowsが要求するディスクアクティビティのバースト(ログオン/ログオフストーム、ブートストーム等)はFVPで簡単に取り回すことが可能です。ストレージネットワークと共有ディスク装置のIOPSとスループットの大部分はオフロードされるのです。

Fig342

PernixData FVP と Lakeside MarketPlace プログラム

PernixData FVPがLakeside SysTrack MarketPlaceプログラムに参画したことをご報告致します。SysTrackの顧客は自身の環境の実際の利用に基づいて生成されたMarketPlaceのデータによって、PernixData FVPがどれだけのコスト削減を実現できるのかの詳細レポートを受け取り、VDI環境に優れたパフォーマンスをもたらすことの保証にすることができます。

VDIの展開を成功させるための最初のステップは既存のエンドユーザーの要件を理解することです。それから、複雑にすることなく最高のユーザーエクスペリエンスを提供しながらそれを拡張できるインフラストラクチャをつくり上げることが続きます。Lakeside SysTrackとPernixData FVPはそれのお手伝いをできるのです。

PernixData FVPによるVDI顧客の成功体験はこちらをクリック、日本語はこちら

SysTrack管理製品の利用についてはこちらをクリックしてください。

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

2016/01/01

【連載】第6回 始めてみよう!CommVault Simpana データアーカイブ機能を活用してみませんか?

 

明けましておめでとうございます。本年も Simapan 関連の連載を続けて行きますので、どうぞよろしくお願いいたします。第5回では、Simpana の重複排除機能を利用した手法と、VMware 仮想マシンのリストア手法をご紹介しました。今回の第6回では、Simpana のデータアーカイブ機能をご紹介します。

 

今日、データの飛躍的な増大によって、企業は、いかにして日々増え続けるデータを管理するか様々な課題を抱えています。日々増加するデータに対して、従来の方法でバックアップを続けていけば、バックアップの取得に必要な時間と保管媒体の容量も同様に増え続けることは明らかです。

 

【データの増大に伴う管理者の課題】

  • 運用管理の複雑化
  • バックアップ時間の増加
  • データ復旧時間の増加
  • システム性能低下への懸念
  • コンプライアンス対策

 

増え続けるデータに対して、データ保護のために取得している定期的なフルバックアップは、更新頻度の低いデータを繰り返し保存することになり、非常に効率が悪いバックアップ運用を実施することになります。更新やアクセス頻度の低いデータに対して、アーカイブの仕組みを実装することによって、稼働系システム上のストレージからアーカイブ先となる 2次ストレージに対象データを移動し管理されますので、その結果、稼働系システム上のストレージ容量が削減されて、バックアップ時間の短縮が図れるようになります。

 

Simpanaのデータアーカイブ機能では、1つのタスク(ジョブ)の中で、バックアップおよびアーカイブの両方を定義することができます。保護対象のデータは、Simpanaの重複排除ディスクライブラリにバックアップされて、その後、アーカイブルールの条件に合致するデータが移動(削除)されます。アーカイブ後に生成される「スタブ」アイコンをダブルクリックすることにより、いつでもデータにアクセスすることができます。

 

【ストレージ有効活用のための Simpana データアーカイブ環境】

Archive002_3

 

【アーカイブデータにアクセスするための「スタブ」の表示】

Archive001_2

 

Simpana のアーカイブ対象には、ファイルシステム、メールボックス、及び VMware 仮想マシン等が含まれていますが、ここでは、NAS のデータアーカイブを説明させていただきます。NAS のアーカイブ方式としては、次の2種類が提供されています。

 

  • NAS ベンダー提供の API と連携した方式 (NetAppおよびEMC)
  • NAS ベンダー提供の API とは連携しない方式 (Isilon、HDS、等)

 

続きを読む »