XtremIOの仮想コピーの概要

(1)

ホワイトペーパー要約このホワイトペーパーでは、書き込み可能でスペース効率が極めて高いインメモリコピーへの独自のアプローチとして XtremIO 仮想コピーを紹介します。ここでは XtremIO の仮想コピーテクノロジーの重要な要素とベストプラクティスについて説明します。 2016 年 3 月

XtremIO の仮想コピーの概要

(2)

Copyright © 2016 EMC Corporation. All rights reserved. （不許複製・禁無断転載） EMC Corporation は、この資料に記載される情報が、発行日時点で正確であるとみなしています。この情報は予告なく変更されることがあります。この資料に記載される情報は、「現状有姿」の条件で提供されています。EMC Corporation は、この資料に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、商品性や特定の目的に対する適応性に対する黙示の保証はいたしません。この資料に記載される、いかなる EMC ソフトウェアの使用、複製、頒布も、当該ソフトウェアライセンスが必要です。

最新の EMC 製品名については、EMC の Web サイトで EMC Corporation の商標を参照してください。

(3)

エグゼクティブサマリー ... 5 従来のスナップショット ... 6 従来のボリューム管理 ... 6 Copy-on-Write スナップショット ... 6 Redirect-on-Write スナップショット ... 8 その他のコピーテクノロジー ... 11 従来のスナップショット：効率性とパフォーマンス ... 11 レガシースナップショットのユースケース ... 12 XtremIO の仮想コピーの概要 ... 12 XtremIO の仮想コピーの作成 ... 13 機能 ... 14 比較 ... 15 アーキテクチャのメリット ... 16 複数ボリュームの相互一貫性のあるコピー ... 20 コンシステンシーグループ ... 21 スナップショットセット ... 21 存在ビットマップ ... 22 仮想コピーの削除 ... 23 ガベージコレクション不要... 24 ボリュームスナップショットグループ ... 24 シャドウ書き込みの削除 ... 25 機能の更新 ... 27 ガイドラインの更新 ... 29 タグ ... 29 ユースケース ... 30 バックアップ操作のオフロード ... 30 主なメリット ... 30 バックアップに使用する XVC の作成 - バックグラウンド ... 31 テストと開発のユースケース ... 33 主なメリット ... 36 論理データ保護 ... 36 オフロード処理とデータ解析 ... 38 主なメリット ... 39

(4)

VMFS（仮想マシンファイルシステム）で XVC を使用してバルク VM をプロビジョニング .. 40

(5)

エグゼクティブサマリー

XtremIO のアレイは、XVC（XtremIO 仮想コピー）テクノロジーを活用しています。XVC テクノロジーは、バックエンドメディアに影響を及ぼさない独自のインメモリメタデータ処理で、コピー操作を抽象化します。XVC では、ほぼあらゆる容量のあらゆるデータセットを、瞬時に高パフォーマンスでコピー可能です。インライン重複排除や圧縮などのデータサービスで、極めて高いスペース効率を達成し、本番環境やその他のコピーには影響しません。重要なビジネスプロセスでは、一般的に、開発、分析、運用、データ保護などの多様な目的で、それぞれ専用のデータベースインスタンスとアプリケーションデータのコピーが複数必要になります。組織の俊敏性、競争力を高める場合、「多ければ多いほど」（プロセスサイクル全体で運用のセルフサービスを増やし、より多くのコピーをより多くの頻度で作成すること）が望まれます。コピーデータ管理（ガートナーおよび IDC では CDM と記述）には複数のアプローチが存在しますが、このようなアプローチでは、ストレージの無秩序な増加、コピー回数の制限、パフォーマンスの制限、複雑な運用プロセスといった問題に根本的に取り組む必要があります。 XtremIO は強固で一貫した IOPS とレイテンシーで、アプリケーションのダウンタイムを発生させることなく、必要に応じてパフォーマンスをスケールアウトできるため、本番および非本番アプリケーションに優れたパフォーマンスを提供します。本番 SLA に影響を及ぼすことはありません。 XVC テクノロジーを利用すると、コピーが作成された特定のポイントインタイムとまったく同じ状態でデータを取得して、ボリュームデータのコピーイメージを瞬時に作成できます。XVC テクノロジーを使用すると、ユーザーはボリュームデータの状態を保存して、後で（必要に応じて）特定のボリュームデータにアクセスできます。ソースボリュームが変更された後でもアクセスできます。 XVC は、メタデータとデータの両方のコピー（書き込み可能と読み取り専用）について、初めてスペース効率を維持できる、ユニークな方法で実装されています。XtremIO 固有のインメモリメタデータアーキテクチャと組み合わせることで、XVC では、高パフォーマンス、低レーテンシーでの読み取り/書き込み可能なコピーを、多数持つことが可能になります。 XVC は、メタデータおよび物理スペースを効率的に使用し、瞬時の作成が可能で、パフォーマンスへの影響なく、クラスター内のその他のボリュームと同じデータサービス（シンプロビジョニングやインラインデータ削減など）を提供します。 XVC は、以下のようなさまざまなユースケースを可能にする、XtremIO の iCDM の主要な基盤です。  テストおよび開発環境の管理  データベースの分析とオフロード処理  データ保護  オペレーション  VM のバルクプロビジョニング

(6)

XVC は使いやすく、クラスター内の標準ボリュームと同様に表示され、管理されます。

従来のスナップショット

従来のスナップショットは、主に、スペース効率の高いデータ保護を提供するために考案されました。ボリュームまたはボリュームのグループのスナップショットを取得すると、必要に応じてロールバック可能な、元のデータセットのポイントインタイムコピーが作成されます。 従来のボリューム管理 従来のブロックストレージアレイでは、論理ボリュームはそのボリューム内の論理アドレスの範囲です。 図 1：従来のボリューム管理 論理アドレスは、ディスク上の物理データブロックにマッピングされます。実際のマッピング手順は、論理ボリュームマネージャーの責任です。この手順は、シンプロビジョニング、階層化、重複排除、圧縮、その他の要因に応じて、簡単な場合も複雑な場合もあります。 Copy-on-Write スナップショット スナップショットのレガシー実装は、「copy-on-first-write」というテクノロジーに基づいていました。このスキームでは、元データが格納されている領域に関するメタデータが、スナップショット作成時にコピーされ、そのスナップショット用にクラスター内に新しいストレージプールが定義されて確保されます。まだ物理コピーは作成されていません。新しい書き込みにより、本番ボリュームと予約済みスナップショットプール間のデータの移動操作がトリガーされます。 I/O フローは次のとおりです。 1. クラスターが新しい書き込みを受け取る。 2. システムが、本番ボリュームから元のデータを読み取る。 3. クラスターは、予約済みスナップショットプールに元のデータを書き込む。 4. クラスターは、新しいデータで本番データを上書きする。

(7)

このスキームを利用すると、元のデータが保存されている領域に関するメタデータのみが、スナップショット作成時にコピーされます。データの物理コピーは作成されません。その後ボリュームマネージャーは、元のボリュームに対する書き込みの実行時に、元のボリューム上で変更されているブロックをトラッキングします。書き込まれている元のデータは、元のデータが上書きされる前に、スナップショット用に確保された、指定済みストレージプールにコピーされます（そのため「copy-on-write」と呼ばれる）。これは、書き込みのたびに、追加で 2 回の I/O 動作のペナルティが課されることを意味します。SSD などの高パフォーマンスメディアを使用する場合にはアプローチが多少異なると思うかもしれません。それは必ずしも正しくありません。データ移動管理の面で、この方法論では依然としてかなりのオーバーヘッドが発生するためです。これは書き込み/読み取り処理の両方のレーテンシーに影響し、複雑なスナップショットトポロジー（スナップショットのスナップショットなど）の柔軟性とパフォーマンスを制限し、SSD メディアの耐久性にもマイナスの影響を与えます。 図 2：Copy-on-Write：ホスト書き込み 短所  スナップショットが取得されるときにメタデータがコピーされ、時間と容量が消費されるため、メモリ内で管理できない。  予約済みスナッププールは、使用率が不十分でも、多くの場合は前もって割り当て済みとしておく必要があり、スペースが不足する場合がある。  パフォーマンスは、特に書き込みの場合にかなり低下する。  複雑なスナップショットトポロジーにより、深刻なパフォーマンスの低下が発生する。

(8)

読み取り処理は、同様な方法で実行されます。本番ボリュームへの読み取り I/O は、常に本番データ予約済みプールから実行されます。スナップショットへの読み取りは、変更されていないブロックの本番プールと、変更されたブロックのスナップショット予約済みプールから実行されます。 図 3：Copy-on-Write：ホスト読み取り Redirect-on-Write スナップショット このスキームでは、スナップショット作成時のコピー対象は、元のデータが保存されている領域に関するメタデータのみです。データの物理コピーは作成されません。ボリュームマネージャーは、元のボリュームに対する書き込みが実行されている間に、元のボリューム上で変化するブロックをトラッキングします。ただし、新しいデータが本番ボリュームに書き込まれる場合は、データはストレージプールに直接書き込まれ、ボリュームマネージャーは新しい物理データ領域に本番ボリュームのメタデータを更新（リダイレクト）します（そのため「redirect-on-write」と呼ばれる）。 短所：  複雑なスナップショットトポロジーにより、深刻なパフォーマンスの低下が発生する。

(9)

図 4：Redirect-on-Write：ホスト書き込み 短所  一般的に、メタデータはスナップショットの作成時にコピーされるため、時間と容量が消費される。  場合によっては、スナップショットを読み取り/書き込み可能にするために、追加の操作が必要となる。  実装によっては、メタデータが読み取り専用であるため、スナップショットの取得時にメタデータがコピーされない。ただし、スナップショットが読み取り/書き込みでアクセスされると、メタデータがコピーされるため、時間とメモリが消費される。

(10)

スナップショットの作成時に、ボリュームマネージャー内で、本番ボリュームのメタデータとスナップショットボリュームのメタデータが、同じ物理ブロックをポイントします。本番ボリュームが新しい書き込みを受け取ると（ブロック B と D の LBA（論理ブロックアドレス）が上書きされると仮定）、メタデータポインターが新しいブロックの領域に更新されます。物理ブロックが存在する領域を判定するために、ボリュームマネージャー内のメタデータポインターを使用して読み取りが実行されます。 図 5：Redirect-On-Write：ホスト読み取り Redirect-on-write スナップショットは、データ効率は優れていますが、メタデータ効率は優れていません。この方法論では、スナップショット作成プロセス中に、元のボリュームのメタデータのセット全体をコピーする必要があるためです。 短所：  各スナップショットはメモリ内で大量のメタデータを消費するが、アレイ内のメモリの分量には限度があるため、メタデータを SSD にデステージする必要がある。これにより、オールフラッシュアレイでもパフォーマンスに影響が出る。

(11)

その他のコピーテクノロジー ボリュームのコピー作成では、その他のテクノロジーを利用できます。クローンは、通常、静的なスナップショットから取得され、データのフルコピーを提供します（クローンは通常、物理的に離れたハードディスクドライブまたは SSD に作成されるため）。クローンはクラスター内で本番ボリュームと同じパフォーマンスを実現できる可能性がありますが、クローンにデータがコピーされるため、クローンの作成には通常、非常に長い時間がかかります。SLA は、クローン操作の作成中に影響を受ける可能性があります。さらに、クローンは容量とメタデータを 2 倍消費するため非効率です。より効率のよいクローンを動的ソースから作成するために、スプリットミラーを使用します。本番ボリュームとクローンの間でミラーリングが確立されます（クローンが本番に追いつくまで、継続的に行われる同期化プロセスです）。完了すると、管理者はデータの独立したコピーを提供するためにクローンを分割できます。両方のテクノロジーとも、優れたパフォーマンスを提供します。ただし、いずれのオプションでも、作成時間と更新時間が非常に長くなります。クローンとスプリットミラーの両方とも、メタデータとデータ容量において非効率です。 従来のスナップショット：効率性とパフォーマンス スナップショットに書き込むとフラグメント化が発生します。redirect-on-write と copy-on-write の両方で同じ結果になります。また、複数のスナップショットが作成されるとき、元のデータへのアクセス、すべてのスナップショットのメタデータの変更のトラッキング、フラグメント化、スナップショット削除後の照合により、パフォーマンスが大幅に低下します。 redirect-on-write スナップショットを削除するには、スナップショットメタデータのスキャンと処理、スナップショットのみに属する対応データブロックの削除が必要なため、スナップショット予約済みプールから本番ボリュームプールへのデータの移行が必要となる可能性もあります。このプロセスを完了するためにかかる時間は、元のボリュームのサイズに比例しています。元のボリュームからの（スナップショットの作成後に）変更されたブロックの分量に比例するのではありません。 Copy-on-write スナップショットは、元のボリュームへの書き込みが効率的ではありません。copy-on-write スナップショットと redirect-on-write スナップショットは両方とも、一定時間にわたりデータのフラグメント化およびメタデータの大幅な変更に対応する必要があります。これは、スナップショットが取得されたら、元のボリューム上の I/O パフォーマンスに多くの場合マイナスの影響が及ぶことを意味します。このようなパフォーマンスに関する問題は、従来のデュアルコントローラーアーキテクチャでは軽減できません。アクティブ/パッシブアーキテクチャではなおさらです。この主な理由は、ボリュームまたはスナップショットの管理に関与できるのは、ボリュームまたはスナップショットあたり 1 台のコントローラーのみ（または最大でも 2 台のコントローラー）であるためです。拡張性がないため、スナップショットおよび本番ボリュームが多数

(12)

ある場合は、コントローラー上でかなりのオーバーヘッドが発生して、スナップショット、本番ボリューム、またはその両方のパフォーマンスに影響します。 レガシースナップショットのユースケース スナップショットは、主に「ライブ」本番データのバックアップ用コピーを作成することを目的とし、本来は作成してから短期間使用するものでした。スナップショットを使用することで、管理者は短期間にわたり本番アプリケーションを凍結し、スナップショットを取得してから、通常の運用を再開することができました。こうした作業により、本番データの静的コピーが作成されました。これは通常読み取り専用モードでアクセスされ、外部のバックアップデバイスにバックアップできました。スナップショットが短期間のみ使用されていた理由には、パフォーマンスの問題、容量使用率に関する考慮事項、サポートされるスナップショット数の制限などがありました。 redirect-on-write テクノロジーが開発されてからは、主にテストや開発プロセスで、スナップショットが長期間使用されるようになりました。ただし、多くの場合パフォーマンスに影響を与えるため、スナップショットの使用は制限されていました。これは、copy-on-write スナップショットの実装による、本番環境のパフォーマンスの大幅な低下でも、 redirect-on-write スナップショットの実装による、読み取りレーテンシーの増大でも、アレイ内のリンクされたメタデータのデータスキャンや、コントローラーの CPU とデータフラグメント化に対するオーバーヘッドが起因しています。

XtremIO の仮想コピーの概要

XtremIO の仮想コピーは、書き込み可能または読み取り専用です。読み取り専用コピーでは、コピーの不変性を維持できます。本番ボリュームから、またはその他の本番ボリュームのコピーから仮想コピーを作成できます。 XVC は、次の例を含む多数のユースケースで使用されています。  論理的な破損の保護：頻度の高いポイントインタイムコピー（RPO の間隔により、数秒、数分、数時間）を作成し、論理データ破損からのリカバリに使用します。XVC は必要な期間、システムに保持できます。論理データ破損が発生した場合は、アプリケーションの以前の状態のスナップショット（論理データ破損の前）を使用して、既知の正常なポイントインタイムまでアプリケーションを復旧できます。また、バックアップのコピーから本番ボリュームの完全なリストアを実行できます。  バックアップ：バックアップサーバー/エージェントに提示する仮想コピーを作成します。コピーは、本番サーバーからバックアッププロセスをオフロードするために使用できます。  テストと開発：本番データの仮想コピーを作成し、本番システムの（スペース効率が高く、高パフォーマンスな）コピーを複数作成してから、それをテストや開発目的で使用できます。XtremIO 仮想コピーテクノロジーでは、無制限のコピー階層が使用できるため、複数のテストや開発プロセスに対応します。新規または更新された本番

(13)

データでテスト環境と開発環境を更新できます。更新操作は簡単かつ迅速です。テスト/開発サーバー用の SCSI エンティティは、更新中に基盤となるデータのみを変更して保存されるため、ホスト側の SCSI バスの再スキャンが回避されます。CLI または RESTful API を介して、すべての環境のスクリプトを容易に作成できます。  ほぼリアルタイムのデータ解析：ETL など、本番サーバーのデータ処理をオフロードする手段として、XVC テクノロジーを使用します。たとえば、データに対して（本番サーバーのパフォーマンスに影響を与える可能性がある）負荷の高いプロセスを実行する必要がある場合、XVC を使用すると、本番データの最新コピーを作成して別のサーバーにマウントすることができます。こうすることで、プロセスは本番サーバーのリソースを消費することなく、（別のサーバーで）実行されます。この機能は、ほぼリアルタイムの解析能力をオンデマンドで実現します。 XtremIO の仮想コピーの作成 ボリューム、ボリュームのセット、コンシステンシーグループから XVC を作成する方法 の詳細については、「XtremIO ストレージアレイユーザーガイド」を参照してください。

(14)

機能 XtremIO の仮想コピーは、次の機能を提供します。  コピーを即座に作成し、本番ボリュームの有効な書き込み可能コピーを提供。  コピーはソースボリュームの読み取り/書き込みまたは読み取り専用*_コピー。  コピーはクラスター内の通常のボリューム。  コピーがシステム内の任意のボリュームと同じデータサービスを備えているため、インライングローバル重複排除とシンプロビジョニング機能が絶えず動作。  メタデータとデータの両方で効率的なコピー。  コピーに予約済み領域は不要。  システムが複数のボリュームで一貫したコピーイメージをサポート（コンシステンシーグループ）。  任意の階層レベルまたは範囲で、あらゆるコピーからコピーを作成可能。  ボリュームまたはその XVC を削除しても、子コピーまたは親 VMC/ボリュームに影響しない。  システムで、本番ボリュームや任意のコピー上で、予測可能かつ一貫したパフォーマンスを提供。  本番ボリュームをバックアップコピーイメージのいずれかから簡単にリストア可能。  すべての SCSI 情報を保持（そしてホスト側 SCSI バスの再スキャンの必要性を排除）したまま、テスト/開発環境を簡単に更新、または新しい情報で更新可能。 * 読み取り専用で作成された XVC は変更不可です。読み取り専用コピーに書き込みアクセスするには、新しい読み取り/書き込みコピーをソースの読み取り専用コピーから作成する必要があります。

(15)

比較

表 1 では、さまざまなコピーテクノロジーと XtremIO 仮想コピーの主な相違点の一部を比較しています。 表 1：従来型コピーテクノロジー対 XtremIO 仮想コピー Copy-on-Write Redirect-on-Write フルクローン XtremIO の仮想 コピー スペース効率に 優れたデータ 可可 × 可 + インラインデータ削減スペース効率に 優れたメタ データ × × × 可ボリュームとスナップショットの メタデータ ディスクとメモリから提供されるメタデータディスクとメモリから提供されるメタデータディスクとメモリから提供されるメタデータメタデータは 100%メモリ内に常駐 Creation Time 即時即時長い時間即時本番へのパフォ ーマンスインパ クトインパクトが大きい中程度のインパクトクローンの完成後はインパクトなしインパクトなしスナップショット のパフォーマ ンス Degraded Degraded 本番と同じになる可能性がある本番と同じ 高速な削除 × × × 可 削除の制限 限られている限られている該当なし親や子に影響を与えずに階層ツリー内の任意のコピーを削除可能 トポロジーの 制限限られているスナップショットオンスナップショットのサポートスナップオンスナップのサポートなしあらゆるトポロジー事前のスペース の確保 可スペースの確保が必要可 × データサービス の制限 可データサービスに制限がある × いいえ。完全なデータサービスが利用可能 任意のコピー 階層の子同士で 瞬時にリストア/ 更新 × ごく限定的再同期が必要となる可能性、本番 SLA に影響を及ぼす可能性ありはい。トポロジー内の任意のコピー間で瞬時にリストア/更新

(16)

アーキテクチャのメリット

XtremIO の仮想コピーアーキテクチャには次のようなメリットがあります。  書き込み処理とパフォーマンスが、本番ボリュームでもコピーでも同じ。  スペース効率の高いメタデータ：  仮想コピーを作成してもメタデータが消費されない。  グローバルに一意な新しいデータブロックにのみメタデータが消費される。  パフォーマンスインパクトなし：  仮想コピーの作成による影響なし。  すべてコピー階層レベルで読み取りパフォーマンスが同等。  高い拡張性：  多数のコピーをサポート。  多数のコンシステンシーグループをサポート。  インラインデータ削減機能を強化した方法である「redirect-on-unique-write」：  グローバルに一意な新しいデータブロックにのみスペースを消費。  新しい書き込みでは物理データの移動なし。  チューニングなし、最適化なし。一貫して均等に分散されたシステムリソース：  クラスターのすべてのストレージコントローラーは、エンティティタイプにかかわらず、絶えず I/O データフローとメタデータの管理に関与。  強化された CPU 処理能力およびメモリが引き続き利用可能（1 台のコントローラーを経由、対、複数のコントローラーを経由）。  一貫して均等なワークロードの分散を利用可能なリソース全体でプロビジョニング。  フラッシュメモリ向けに最適化：  XtremIO 仮想コピーは、最大のフラッシュ耐久性に最適化。  コピーの作成時や書き込み中はデータ移動なし。  インラインデータ削減は、容量の効率性とフラッシュの耐久性に付加価値を提供する。  フラッシュメディアで追加のメリット（パフォーマンス面）を提供。  システムは、効率的なメタデータと容量使用率を提供。

(17)

XtremIO の仮想コピーテクノロジーは、I/O を適切なデータタイムスタンプに誘導するユニークなメタデータツリー構造を使用し、アレイのコンテンツアドレス指定機能、インメモリメタデータ、システムの SSD メディアに最適化されたデュアルステージメタデータ（インラインデータ削減を実行）を活用することで実装されます。この活用によって、高パフォーマンスを維持する効率性に優れたコピーテクノロジーを実現しながら、複数のコピーを作成できる機能と、単一のコピーが対応できる I/O の量という両方の側面から、メディアの耐久性が最大化されます。 図 6：Address-to-Content マッピング 図 6 は、書き込まれたすべてのブロックのアドレスがフィンガープリントにマッピングされていることを示す論理ボリュームの図です。このマッピングは Address-to-Content マッピングと呼ばれます。さらに、コンテンツから、SSD に書き込まれている実際の一意の物理ブロックへの別個のメタデータマッピングがあります（つまり、デュアルステージメタデータ構造を形成）。すべての XtremIO ボリュームまたは仮想コピーはシンプロビジョニングされているため、書き込まれたことのないアドレスは空白のままになり、メタデータ（またはデータ）スペースを占有しません。したがって、XtremIO のシンプロビジョニングは、100%の設置効率を備えています。仮想コピー作成時に、システムはクラスターに含まれる実際のボリュームの親メタデータに対するポインターを生成します。このため、コピーの作成は非常に簡単な操作で、クラスターに影響を及ぼしません。また、物理容量や論理容量を消費しないため、本番 SLA に影響しません。仮想コピーの容量の消費は、変更で新しいブロックの書き込みが必要になった場合にのみ発生します。 図 7：XtremIO の仮想コピー

(18)

コピーが作成されるとき、ボリュームの既存のメタデータは、本番ボリュームとコピーで共有される「親」エンティティとなります。新しい空のコンテナーが、本番ボリュームと仮想コピーボリュームの両方に対する後続の変更のために作成されます。したがって、コピーを作成する作業は瞬間的に行われ、データまたはメタデータのコピーは必要ありません。新しいブロックが親に書き込まれると、新しい書き込みを反映するために親ボリュームのメタデータが更新され、ブロックがクラスターに格納されます。これは、標準の書き込みフロープロセスを使用して行われます。このブロックは、コピーと親ボリュームの間で共有されている限り、書き込みの後でクラスターから削除されることはありません。これは、ボリューム上の新しい場所への書き込み（未使用の LBA）と、すでに書き込まれている場所での再書き込みの両方に適用されます。クラスターは、ツリー構造経由でコピーのメタデータと親のメタデータの両方を管理します。図 8 では、コピーと親ボリュームがこの構造の「葉」に相当するものとして表現されています。 図 8：メタデータツリー構造 メタデータは、（コピー元の親から）変更されていない全コピー間で共有されます。コピーが、既存のデータと異なるデータブロックを持つ LBA 専用の独自のメタデータを維持することで、経済的なメタデータ管理を実現します。新しいコピーが作成されると、クラスターは常に、ソースとなったエンティティから 2 枚の葉（2 つの子エンティティ）を作成します。これらの葉の 1 枚はコピーを、もう 1 枚はソースエンティティを示します。ソースエンティティのメタデータコンテナーは、それ以降直接使用されることはなくなりますが、メタデータの管理目的で（のみ）クラスターに維持されます。

(19)

図 9 には、XtremIO システムの 16 ブロックのボリュームが表示されています。（A（t0）/ S（t0）とマークされた）1 行目は、最初の仮想コピーが作成されたときのボリュームを示します（t0）。t0 では、親（A（t0））とコピー（S（t0））が同じデータとメタデータを持っています。これは、S（t0）が A（t0）の読み取り専用コピーであるためです（親と同じデータを保有）。 図 9：コピーの作成 注：16 個あるブロックのうち、使用されているのは 8 ブロックのみです。ブロック 0 とブロック 4 は、重複排除の結果、物理容量の 1 ブロック分のみしか消費しません。ドット地の空白ブロックは、シンプロビジョニングされたブロックを表しています。これは、物理容量を消費しません。図 9 に示されているように、S（t1）で仮想コピーを作成する前に 2 つの新しいブロックが以下のとおり P に書き込まれます。  H8 は、LBA 3 で H2 を上書きする。

(20)

 H2 は LBA D に書き込まれる。A（t0）の LBA 3 に格納されたデータとフィンガープリントが同一（H2）のため、物理容量をほとんど消費しない。 S（t1）は読み取り/書き込みコピーです。これには、親のソースエンティティとは異なる 2 つの追加ブロックが含まれます（LBA 2 と LBA 3 に）。従来のスナップショットの実装（変更されたブロックのスペースを確保して各スナップショットのメタデータの全コピーを確保）とは異なり、XtremIO では仮想コピーに専用の物理スペースを確保する必要はなく、メタデータの「膨張」も起こりません。仮想コピーは必要なときにこのようなリソースのみを使用し、リソースは、クラスターのグローバルリソースプールから消費されます。XtremIO にはプール管理はありません。ボリュームを表すコピーツリー内の（そのボリュームから作成されるすべてのコピーを含む）すべてのアクセス可能なエンティティは、VSG（ボリュームスナップショットグループ）と呼ばれるエンティティにより管理されます。 XtremIO の仮想コピーは、新しい書き込みのメタデータ（未共有ブロック）のみを消費し、具体的にはコピーの親エンティティからの共有メタデータを使用します。これにより、クラスターは、動的でエンティティの変更量に比例した極めて小さいストレージオーバーヘッドで、大量のコピーを効率的に管理できます。たとえば、t2、LBA の時点では、ブロック 0、3、4、6、8、A、B、D、F は親エンティティと共有されています。このコピーでは LBA 5（H6）のみが一意です。そのため、XtremIO の消費するメタデータユニットは 1 つだけです。残りのブロックは親と共有され、正確なボリュームデータと構造をコンパイルするために、親のデータ構造を使用します。 複数ボリュームの相互一貫性のあるコピー XtremIO は、ボリュームセット上の仮想コピー作成をサポートしています。セット内のボリュームからのコピーはすべて、相互一貫性があります。ボリュームセットでのコピーは、コピー操作用のボリュームセットを選択するか、ボリュームをコンシステンシーグループコンテナーに配置してコンシステンシーグループのコピーを作成することで、手動で作成できます。作成されたすべてのコピーと関連づけられたスナップショットセット（論理オブジェクト）が作成されます。クラスターは数マイクロ秒以内でボリュームを停止することで、新しく作成された仮想コピーの相互一貫性の維持を保証します。操作が短いインターバルで繰り返された場合でも、システムパフォーマンスへの影響はありません。ソースボリュームのみが、仮想コピーの作成操作中に停止されます。整合性を保証するために、クラスターは停止手順の実行中にソースボリュームへの書き込みに対するホストへの受信確認を一時的に保持することで、停止中にイニシエーターから新しい書き込みが生成されないようにします。このため、作成されたすべてのコピーで相互一貫性が保たれます。

(21)

コンシステンシーグループ XtremIO では、データ保護などの用途で複数のボリュームをグループにまとめることができます。複数のボリュームがまとめて 1 つのコンシステンシーグループに配置されると、コンシステンシーグループのすべてのメンバーで一貫したコピーを作成できます。複数のボリュームのコピーを作成する必要が繰り返し生じる場合には、複数のボリュームをまとめて配置することをお勧めします。コンシステンシーグループで仮想コピーを作成すると、コンシステンシーグループの各メンバーボリュームがコピーを作成します。作成されたすべてのコピーと関連づけられたスナップショットセット（論理オブジェクト）が作成されます。ボリュームがコンシステンシーグループに追加されると、そのボリュームに位置（オフセット）が割り当てられます。更新される適切なオブジェクトと関連づけられるように、リストアや更新の操作中、このオフセット位置が使用されます。このオフセットは、スナップショットセットオブジェクト内で維持されます。ボリュームは、複数のコンシステンシーグループのメンバーになることができます。コンシステンシーグループ番号とさまざまな制限事項に関する最新情報については、現行の「XtremIO リリースノート」ドキュメントを参照してください。 スナップショットセット 仮想コピーを作成するたびに、システムは、ポイントインタイムコピーを示す新しいスナップショットセットオブジェクトを作成します。これは、ソースオブジェクトが 1 つのボリュームか、ボリュームセット（ボリュームリストまたはコンシステンシーグループ）かとは無関係に発生します。スナップショットセットは特定のポイントインタイムの論理グループで、すべての新規作成ボリュームがそのポイントインタイムを示す条件を維持します。これは、同じコピー作成操作で作成された別のボリュームとの相互関連性を得るために使用できます。

(22)

存在ビットマップ XtremIO のストレージアレイには、存在ビットマップと呼ばれる追加のデータ構造があります。 図 10：XtremIO 仮想コピーツリー XtremIO の仮想コピーテクノロジーを導入すると、コピーのコピーを無制限に作成できます。このようなカスケードコピーを可能にするシステムでは、データの取得元の場所を見つけることが、読み取りパフォーマンスに影響する可能性がある課題となります。コピー内の各 LBA では、データはそのコピーボリューム自体（その LAB がスナップショットの取得後に作成された場合）か、その親の 1 つに見つかることがあります。スペース効率の高いコピーからの読み取りに使用するネイティブアルゴリズムは、データがコピーボリューム自体に書き込まれているかどうかをチェックします。そうでない場合は、その親をチェックし、次にその親をチェックする、というように進みます。その LBA への書き込みが一度もないなどの場合は、元の親の位置を検出する必要があり、検索に時間がかかります。このアルゴリズムは、読み取りに対して大幅なパフォーマンスの低下をもたらします。さらに、パフォーマンスはチェーンの長さに応じて異なるため、予測できません。さらに、ルートボリュームから遠く離れているコピーは、ルートに近いコピーよりもパフォーマンスが低下します。

(23)

存在ビットマップのデータ構造とアルゴリズムは、スペース効率の高いコピーで読み取り処理を最適化します。存在ビットマップは、ルートボリュームからの距離に関係なく、すべてのコピーで予測可能な均一のパフォーマンスを提供します。ビットマップを含む VSG（ボリュームスナップショットグループ）ごとに 1 つの構造があります。元のボリュームの LBA ごとに 1 つです。各ビットマップ内のビット数は、VSG ごとのボリュームの最大数に等しくなります。データがボリュームに書き込まれるたびに、元のボリュームであるか、スナップショットであるかに関係なく、LBA のビットマップ内でそのボリュームに対応するビットが設定されます。図 10（22 ページ）のマップ内のビットマップは LBA ごとに構成され、LBA はコピーごとに LBA が書き込まれています。ビットマップ内の各インデックスは、コピーを表します。たとえば、LBA 0 には A（t0）のみが書き込まれます。したがって、時間 t1 の後に作成されるコピー用のすべての LBA 0 の読み取りは、A(t0)に格納されているメタデータ情報により実行される必要があります。特定の LBA からデータを読み取るとき、クラスターは最初に特定の LBA に関連づけられているビットマップを読み取ります（通常、1 つのキャッシュ行に収まるので、非常に効率的）。その後、データを読み取るためにアクセスする必要があるビットマップ内ボリュームを見つけます。その後クラスターは、そのボリュームへ直接移動し、データを取得します。ビットマップの操作は、パフォーマンスの面で経済的であるため、コピーチェーン内のコピーの深さが、読み取りパフォーマンスや書き込みパフォーマンスに影響を及ぼすことはありません。 仮想コピーの削除 XVC の削除は、エンティティ間の変更済みブロックの量にのみ比例します。クラスターはコンテンツ対応機能によって、コピーの削除を処理します。一意のデータブロックにはそれぞれ、クラスター内にある対象ブロックのインスタンス数を示すカウンターがあります。ブロックが削除されると、カウンターの値は 1 つずつ減少します。このカウンターの値がゼロのブロック（クラスターのボリュームまたはスナップショット全体に、このブロックを参照する LBA が存在しないことを示している）は、新しい一意のデータがクラスターに入ってきた時点で、XDP（XtremIO のデータ保護）によって上書きされます。ツリー内でコピーを削除すると、削除されたエンティティの子のメタデータを、その孫のメタデータと統合するプロセスがトリガーされます。このプロセスにより、ツリー構造が断片化されることがなくなります。

(24)

ガベージコレクション不要 XtremIO では、ブロックの削除が必要になると直ちに解放済みとしてマークされます。そのため、SSD のガベージコレクションは存在せず、孤立ブロックを見つけて削除するためにクラスターがスキャンプロセスを実行する必要はありません。 XtremIO の仮想コピーの実施は完全にメタデータ中心で行われ、アレイのインラインデータ削減を活用するため、データがアレイ内にコピーされることはありません。そのため、多くのコンカレントコピーを維持できます。 ボリュームスナップショットグループ ボリュームスナップショットグループは、コピーツリーすべての外部エンティティ（マッピング可能なエンティティ）を表すエンティティです。1 つの親から発生するすべてのコピーは、同じボリュームスナップショットグループを共有します。これは、新しいボリュームがクラスター内で定義されるたびに作成されます。 VSG 情報は、GUI の［ボリュームプロパティ］ペインで表示できます。 図 11：GUI のボリュームプロパティペイン VSG 情報は、次の CLI コマンドの 1 つを使用して VSG インデックスの下に表示することもできます。  show-volumes  show-volume

xmcli (tech)> show-volumes sg-id=8 Volume-Name Index Cluster-Name Index Vol-Size LB-Size VSG-Space-In-Use Offset Created-From-Volume VSG-Index Small-IO-Alerts Unaligned-IO-Alerts CRM1 8 xbrickdrm353 1 750G 512 733.518G 0 CRM1 8 disabled disabled CRM1 1451292016546 131 xbrickdrm353 1 750G 512 733.518G 0 CRM1 8 disabled disabled CRM1 1451292325841 139 xbrickdrm353 1 750G 512 733.518G 0 CRM1 8 disabled disabled CRM1 1451292427812 147 xbrickdrm353 1 750G 512 733.518G 0 CRM1 8 disabled disabled xmcli (tech)

クラスター内のすべての既存のボリュームスナップショットグループ上で情報を一覧表示するには、次の CLI コマンドを使用します。

(25)

シャドウ書き込みの削除 ボリュームおよびそのコピー上の同じ LBA に書き込むと、エンティティの共有の親にある LBA データが解放されます。これにより、メタデータの消費と物理容量の消費の両方の面で、アレイの使用率が向上します。仮想コピーが作成されると、結果は次の 3 つのエンティティを含む簡単な構造となります。  親エンティティ  コピー（新しいエンティティ）  新しい本番エンティティ図 12 の例では、重複排除されていない一意のデータでボリュームが満杯になっており、すべての LBA にデータが含まれています。次のシナリオで、データとメタデータの管理に対する影響を観察します。コピーが LBA 4 に書き込まれ、しばらくすると本番ボリューム上の LBA 4 が上書きされます。

(26)

図 12：シャドウ書き込みの削除

最初に仮想コピーが作成されるとき、本番ボリュームとコピーのいずれにも一意のデータは含まれていません。読み取りはすべて、親エンティティのメタデータとデータを使用して実行されます。

(27)

後で LBA 4 への書き込みが、本番ボリュームとコピーの両方に書き込まれると仮定します。親 LBA 4 はこれで、コピーと本番ボリューム上で、LBA 4 への更新によりシャドウイングされます。したがって、親のデータは必要なくなり、クラスターからパージできます。クラスターは LBA 4 に関連するメタデータを解放し、LBA 4 に格納されたフィンガープリントの参照数を削減します。このフィンガープリントがクラスターの別の場所で使用されない場合は、クラスターからフィンガープリントと対応するコンテンツが削除され、物理容量と論理容量が解放されます。シャドウ書き込みの削除は、クラスターのパフォーマンスに影響することなく非同期に発生します。 機能の更新 XtremIO には、ツリー内の任意のエンティティに SCSI パーソナリティを接続する機能があります。XtremIO の更新は、新しいコピーを作成するコマンドから呼び出され、既存の SCSI パーソナリティに新しいコピーを接続します。そのため、インメモリコピーツリー内の任意のコピーにマッピングされたボリュームをこの操作で更新できます。 XtremIO の更新プロセスは、次の手順の実行で呼び出されます。 1. 更新する SCSI パーソナリティを選択。 2. 更新元にするエンティティを選択。 3. 更新されたソースエンティティを破棄する必要があるか、それともシステムに保持する必要があるかを設定。

(28)

次の図は、XtremIO が仮想コピーの 1 つからボリュームを更新するプロセスを示しています。ホストにボリュームが接続され、別のホストに仮想コピーが接続されていると仮定します。 1. 更新元とするコピーの新しいコピーを作成（元のコピーはシステム内に保持）。 2. 本番ボリュームの SCSI パーソナリティが、XtremIO のメモリに作成される新しいデータコンテナーに移動。 3. コピーの SCSI パーソナリティが他のメタデータが作成されたポイント（更新元エンティティに依存）に移動。 4. システムが、更新されたエンティティの古いデータを削除または保持。以上の方法を使用すると、仮想コピーツリーの任意のエンティティを任意のエンティティに無制限に更新できます。最終的には、SCSI パーソナリティが目的のエンティティのデータで更新され、マッピングやホスト側 SCSI バス設定の実行を必要とすることなく、データにアクセスできる結果となります。これにより、多くの管理作業と時間を節約できます。

(29)

ガイドラインの更新 更新のガイドラインは、次のとおりです。  個別ボリューム任意の個別ボリュームまたは仮想コピーは、ボリュームスナップショットグループの任意のボリュームまたは仮想コピーから無制限に更新できます。  コンシステンシーグループコンシステンシーグループから作成されたコピーをあらゆる組み合わせで更新またはリストアできます。  スナップショットセットリストアまたは更新の操作は、同じコンシステンシーグループから生成されたスナップショットセットで、あるいはそのコンシステンシーグループから作成された他のスナップショットセットでのみサポートされます。  ボリュームリストボリュームリストから作成されたスナップショットセットでは、リストアや更新の操作をサポートしていません。更新操作が開始されると、新しいスナップショットセットが作成され、更新済みの SCSI のエンティティに接続されます。新しいスナップショットセットは、システムで作成された新しいポイントインタイムを示します。固定ハンドラーの使用を意図した場合、または更新操作で使用するよう意図されたオブジェクトを参照した場合（毎日更新を実行する場合など）には、これで課題が提起される可能性があります。これを実現するには、更新操作で固定ハンドラーとしてタグを使用する方法を使用します。スナップショットセットでタグを作成してから、タグの「Refresh」オプションを使用します。更新された SCSI のエンティティは、スナップショットセットの名前を変更します。ただし、タグは、新たに作成されたスナップショットセットで更新するため、固定ハンドラーが有効になります。タグ XtremIO は、タグの使用をサポートしています。タグは、コンシステンシーグループ、スナップショットセット、ボリューム、イニシエーターグループ、スケジューラなど、ほぼあらゆるタイプのオブジェクトに割り当てることができます。大量のオブジェクトを使用する場合、または XtremIO の仮想コピーを操作する場合は、スナップショットセットでタグを使用することをお勧めします。

(30)

ユースケース

バックアップ操作のオフロード アプリケーションサーバーからバックアップまたはメディアサーバーにデータを転送すると、通常、バックアップ操作で多量の環境リソースが消費される可能性があるため、ネットワーク使用率が高まり、バックアップウィンドウが増大し、アプリケーションに甚大な影響を及ぼします。これらはすべてバックアップ管理者やストレージ管理者にはよく知られた問題です。 XtremIO の仮想コピーは、本番データのバックアップを外部バックアップデバイスにオフロードするために使用できます。バックアップは本番コピーの代わりにコピーから取得できるため、外部バックアップサーバーにデータを移動するプロセスがオフロードされます。 XVC の使用で実現されているもう 1 つのソリューションは、ProtectPoint です。効率を重視し、重複排除機能を使用して XtremIO から DataDomain に直接データをバックアップするために、RecoverPoint でコピーが活用されます。 主なメリット XVC をバックアップ操作に使用する主なメリットは次のとおりです。  以下を利用する、XVC の即時作成、更新、マッピング：  即時の最新状態への更新/更新機能より、バックアップサイクルの俊敏性をサポート。  HBA の再スキャンにかかる時間の節約。HBA の再スキャンでは数百台のデバイスのマウントに対応するため、すべてのバックアップまたはメディアサーバーで役立つ。  スペース効率の高いコピー：  物理容量または論理容量がまったく確保されていないか、使用されていない。  効率的な論理メモリの消費。  バックアップサイクル中のリソース節約：  アプリケーションサーバーから直接バックアップする必要がないため、本番 CPU リソースは使用されない。  アプリケーションサーバーから LAN 経由でバックアップセットが転送されないため、ネットワークリソースを削減。

(31)

図 13：バックアップ操作のオフロード - 00 バックアップコピーは即時更新されるか、日次または週次ベースで本番環境から更新されます。バックアップまたはマウントサーバーでは、HBA レベルでの再スキャンは不要です。バックアップサーバーは通常、組織内の何百ものデバイスをマウントするため、このアプローチで多大な時間を節約できます。 バックアップに使用する XVC の作成 - バックグラウンド このセクションでは、XtremIO の仮想コピーを使用してバックアップを作成する方法と、バックグラウンドの動作についての例を示します。 1. 図 14（32 ページ）に示すとおり、本番ホストは「Prod CG」からボリュームにマッピング。コピー作成操作は「Prod CG」から開始（バックアップ動作用のコピーを作成するために実行）。 2. 新しく作成されたスナップショットセットは、新しく作成されたコピーをホストした後、バックアップホストにマッピングされ、マウントされる。 3. バックアップスナップショットセットのタグが作成され、「BackupCopyTag」というラベルが付与される。このタグは、更新処理中に使用。

(32)

図 14：バックアップ操作のオフロード - 01

バックアップ操作は、ほとんどのお客様の環境で、日常的に実行されているタスクです。つまり、サイクルごとにバックアップコピーの更新が必要です。XtremIO の仮想コピーは、このような要件をネイティブにサポートします。この作業に使用するコマンドは、手動で実行するか、CLI で簡単にスクリプトを作成するか、RESTful API を使用して実行できます。

この例でバックアップ用 XVC を作成する CLI コマンドは次のとおりです。

create-snapshot-and-reassign from ProdCG to BackupCopyTag

図 15 には、社内の影響が示されています。

(33)

新しいスナップショットセットは作成されると同じボリュームをポイントします（ホストレベルでの再スキャンは不要）。新しい「SnapshotSet02」は、引き続き「BackupCopyTag」タグでマークされているため、作成した同じコマンドを次のサイクルでも実行できます。 XtremIO は更新されたボリュームの「バックアップ/元に戻す」コピーを自動的に保持します。これは万一、人的エラーが発生した場合に高速リカバリを提供するための措置です。この「バックアップ/元に戻す」コピーは、「SnapshotSet01」の例では古いスナップショットセット内に配置されています。このスナップショットセットは手動か、「no-backup」コマンドを使用して引数で削除します。 テストと開発のユースケース XtremIO の仮想コピーは、本番データのテストおよび開発コピーを提供するために活用できます。複数のマスターコピーを作成して、テストまたは開発のためにゴールデンイメージとして使用できるように、各コピーを処理（匿名化や浄化のプロセスなど）できます。その後は、各マスターコピーから複数のコピーを作成して、さまざまな開発チームに提供できます。多数のコピーのプロビジョニングを簡単かつ瞬時に処理し、プロビジョニングされたコピーからさらにコピーを作成することもできます。 XVC では、ストレージ容量やパフォーマンスの制限に基づくのではなく、ビジネス効率を最大化する要求に基づいたコピー作成が可能です。 図 16：テストと開発のユースケース

(34)

さらに、XtremIO の容易な更新プロセスで、開発環境の即時更新も可能となります。図 17 のツリーレイアウトは、「DevTeam1」が作成されるコピー（スナップショット）環境を示しています。本番の即時コピーが作成され、DevTeam1 サーバーにマッピングされます。 DevTeam1 サーバーで認識されるボリュームのコピーを含む「SnapshotSet01」が作成される間、本番環境はこの操作の影響を受けません。「DevTeam1」タグを使用して、SnapshotSet01 が新たに作成された開発コピーをポイントするようにタグ付けすることをお勧めします。 図 17：DevTeam1 の開発環境の作成 テスト/開発チームにとって更新操作は極めて有益です。マスターコピーからの開発コピーの更新を、これまでになく簡単かつ瞬時に実現できます。

1 つの RESTful API コールまたは 1 つの CLI コマンド（または GUI ウィザード）で、このタスクの実行が可能になります。

この例では、テスト/開発用に XVC を作成する CLI コマンドは次のようになります。

(35)

図 18：DevTeam2 用の追加の開発環境の作成 チーム 1 の開発環境は、本番コピーから即座に更新されます。この操作では、ホストレベルでの HBA の再スキャンを排除するために、すべての LUN 情報も保持されます。保護の観点から、「バックアップ/元に戻す」ボリュームは、万一人為的なエラーが発生した場合や、ユーザーがロールバックの実行を必要とする場合に備えて保持されます。バックアップのコピーは、常に古いスナップショットセット（上の例では「SnapshotSet01」）に保持されます。バックアップコピーは、不要の際は削除できます。 XtremIO は、本番ボリュームから約 512 個のコピーを保持できるため、最も要求の高いお客様の要件をもサポートします。 Devteam1 タグにより、この手順の繰り返しが簡単になり、作成したコマンドを自動的に使用できます。 QA、本番稼働前、テストなどの開発ライフサイクルで発生する他のあらゆるコピーにも、タグでラベルを付与できます。更新操作はタグ間でも、タグからコンシステンシーグループに対しても、簡単に実行できます。

(36)

主なメリット テストと開発の操作に XVC を使用する主なメリットは次のとおりです。  開発のライフサイクルをサポートする極めて高い俊敏性。  スペース効率の高いコピー：  リソースは、新しい書き込み用にのみ取得される。  物理容量または論理容量は確保されない。  多数のテスト/開発コピーを作成できるため、適格なエンジニア一人ひとりに高パフォーマンスサンドボックスを作成できて、しかも操作に時間がかからない。  テスト環境または開発環境のクイック更新。  重複排除、圧縮、シンプロビジョニングは常に有効化されている。  コピーのコピーがサポートされている。 論理データ保護 論理データの破損から保護するために、本番ボリュームのコピーを作成できます。定期的に RPO（目標復旧時点）を提供するために、複数のコピーを短いインターバルで作成できます（バックアップに対する優れた RPO）。たとえば、30 分ごとに 48 個のコピーを作成し、前回のコピーを削除できます。これにより、本番ボリュームが最後に変更された日の 30 分の RPO が用意されます。 図 19：論理データ保護用の複数のポイントインタイムコピー 柔軟な保存ポリシーは、明確に指定したインターバルから毎日/毎週の保存まで、 XtremIO の組み込み型スケジューラを使用して簡単に構成できます。デフォルトのバックアップコピーは、読み取り専用（変更不可）で作成されます。

(37)

これによってバックアップフィールドが自動化されて、外部スクリプト作成の必要がなくなります。組み込み型スケジューラを使用して作成される XVC は、クラッシュしても整合性を維持できるコピーのみです。アプリケーション対応型のコピーが必要な場合は、 EMC の AppSync がアプリケーション対応型のサポートでスケジュール設定機能を提供できます。 図 20：［Scheduler Configuration］ウィンドウ リストアフローは、スケジューラのテーマをサポートしており、リストア操作は「読み取り専用」コピーからのみ実行できます（更新フローではソースとしてのスナップショットセットの使用が有効化する）。

(38)

図 21：リストアのフロー オフロード処理とデータ解析 XtremIO の仮想コピーは、リアルタイム解析の提供にも使用できるため、それによってユーザーは次のアクションを実行できます。  外部のサーバーに処理をオフロードする。  データをデータウェアハウスへロードするための ETL（抽出、変換、ロード）プロセス。  BI（ビジネスインテリジェンス）レポートのほぼリアルタイムの分析を実行する。  OLTP（オンライントランザクション処理）とリアルタイムを 1 つのプラットフォーム上で統合する。 図 22：オフロード処理とデータ解析

(39)

主なメリット オフロード処理やデータ解析に XVC を使用する主なメリットには、次のようなものがあります。  ブルートフォース SAN コピーを作成する必要なしに、本番データのコピーを即座に更新  整合性と予測可能なパフォーマンスを備えた、1 つのオールフラッシュスケールアウトプラットフォームにさまざまなワークロードを統合  本番データの最新コピーに基づく正確なリアルタイム BI 分析  スペース効率の高いコピー：  物理容量または論理容量をまったく確保していないか、コピー内で使用していない  重複排除とシンプロビジョニングが常に可能  コピーのコピーは、常に一意のデルタのみを含んでいる  本番サーバーからの処理をオフロード：  SAN BW/IOPS を解放する  CPU リソースを解放する  ネットワークリソースを解放する  本番のコピーに対する高いパフォーマンス

(40)

VMFS（仮想マシンファイルシステム）で XVC を使用してバルク VM をプロビジ ョニング 多数の仮想マシンを含む VMFS ボリュームの XVC を取得することは、VM のクローン作成の最も速い方法であることが証明されています。この方法は、VAAI XCOPY など、どの代替方法よりもずっと高速です。 図 23：VM のネイティブクローンの作成 図 23 は、XVC 機能の使用を実行する VM 向けにネイティブクローンが作成され、操作時間を数秒にまで短縮している例を示しています。

VMware 管理者の負担を軽減するため、EMC は VMware Virtual Center の無料プラグイン（VSI）を提供しています。この VSI プラグインは、VC から XtremIO を統合管理できるようにすると同時に、以下のようなその他のメリットを追加します。  XtremIO の統合された管理とモニタリング  VM レベルとデータストアレベルでの自動リストア/更新操作  XtremIO のベストプラクティスを ESXi インフラストラクチャに適用  （Citrix と View 両方の）VDI 展開のサポート

(41)

 大規模 VM の高速なプロビジョニング  スペース効率の高い VM のクローン作成

(42)

まとめ

XtremIO の仮想コピー機能は、高パフォーマンス、低レーテンシーの、読み取り専用または書き込み可能なコピーを、多数提供します。 XtremIO の仮想コピーは、メタデータと物理スペースにおいて効率的で、瞬時に作成でき、パフォーマンスインパクトがなく、クラスター内のその他のボリュームと同じデータサービスを備えています（シンプロビジョニングやインラインデータ削減など）。 XVC は使用と管理が簡単で、フラッシュメディアに対する優れたサポートを提供する洗練されたメタデータ管理エンジンを活用しているため、高パフォーマンスのコピーが可能です。 XVC テクノロジーは、統合型のコピーデータ管理機能を実現する主要な基盤を導入することによって、お客様が、スケールアウトプラットフォームの本番や非本番の tier-1 ワークロードと、予想可能な一貫したパフォーマンスを統合できるようにします。 XVC はテストと開発、バックアップ、操作、データ保護、ほぼリアルタイムの解析に活用できます。