EMC CLARiX SnapViewクローン

Transcription

1 EMC CLARiX SnapView クローン 詳細レビュー US ホワイトペーパー翻訳版 要約 このホワイトペーパーでは SnapView クローンについて説明します SnapView クローンは すべてのデータを含む LUN( 論理ユニット ) のポイント イン タイム コピーであり これによってソース LUN とターゲット LUN 間での部分同期が可能になります SnapView クローンの一般的な用途のほか 構成と管理に関する情報について説明します また 一般的なパフォーマンスの詳細についても説明します

2 2008 年 1 月

3 Copyright 2007, 2008 EMC Corporation. 不許複製 EMC Corporation は この資料に記載される情報が 発効日時点で正確であるとみなします 情報は予告なく変更されることがあります この資料に記載されている情報は 現状有姿 の条件で提供されます EMC Corporation は この資料に記載される情報に関する どのような内容についても表明保証条項を設けず 特に 商品性や特定の目的に対する適応性に対する黙示の保証はいたしません この資料に記載される いかなる EMC ソフトウェアの使用 複製 頒布も 当該ソフトウェア ライセンスが必要です 最新の EMC 製品名については EMC.com で EMC Corporation の商標を参照してください 他のすべての名称ならびに製品についての商標は それぞれの所有者の商標または登録商標です パーツ番号 H J EMC CLARiX SnapView クローン詳細レビュー 2

4 目次 詳細レビュー...0 エグゼクティブ サマリー...5 はじめに...5 対象読者...5 SnapView スナップショットとの比較...5 ソース LUN へのリストア...6 ハードウェア障害からの保護...6 パフォーマンス...6 容量の要件と可用性...7 MirrorView/Synchronous との比較...7 SnapView がサポートするビジネス オペレーション...10 バックアップおよびリカバリ...10 意思決定支援とアプリケーション テスト...10 データ ウェアハウジング...11 データ レポート作成...11 データ伝送...11 ユーザー トレーニング...11 他の CLARiX レプリケーション ソフトウェアでのクローンの使用...11 SnapView スナップショットとクローンの使用...12 SAN Copy とクローンの使用...12 MirrorView とクローンの使用...13 クローンの機能...14 クローンの基本的機能...15 クローン同期...15 クローン フラクチャ...15 クローンのリバース同期...16 クローンのリバース同期 保護されたリストア...17 フラクチャ ログのリセット...18 クローンの構成...18 クローン プライベート LUN...20 CLARiX 整合性操作...21 クローンのコンシステント フラクチャ操作...22 ストレージ システム ベースの整合性とサーバ ベースの整合性...22 クローンのコンシステント フラクチャ...23 SnapView のコンシステント フラクチャの制限...24 レポート作成機能...24 クローンに関するパフォーマンスの考慮事項...25 最初のクローン同期のパフォーマンス...25 初期同期の速さと差分再同期の速さ...26 EMC CLARiX SnapView クローン詳細レビュー 3

5 クローンにおける ATA ドライブの使用...27 初期同期処理時のサーバへの影響...27 クローン再同期およびリバース同期がサーバに与える影響 ( 他のクローン操作との比較考察 )...29 結論...32 関連資料...32 付録 : クローンの制限...33 EMC CLARiX SnapView クローン詳細レビュー 4

6 エグゼクティブ サマリー SnapView クローンは すべてのデータを含む LUN( 論理ユニット ) のポイント イン タイム コピーであり これによってソース LUN とターゲット LUN との間で差分同期が可能になります データのポイント イン タイム ビューを提供する SnapView スナップショットと組み合わせることで すべてのデータを含むポイント イン タイム コピーが得られ ストレージ環境を使用する際の柔軟性を最大限に高めることができます ユーザーは ポイント イン タイム コピーを使用することにより 本番データへの影響を最小限にとどめて 実行するストレージ管理タスクを追加することができます 以下のようなタスクがあります バックアップ / リカバリ アプリケーションのテスト ウェアハウジング データ移動これらすべてのタスクでデータのポイント イン タイム コピーを使用することで 本番サーバへの影響を最小限に抑えることができます はじめに SnapView クローンを使用することにより すべてのデータを含む LUN のバイナリ コピーを 1 つのストレージ システム内に作成することができます データが入力されたクローンは ソースから切り離し セカンダリ サーバに提示され データのポイント イン タイム レプリカを提供することができます クローンは もう 1 つの SnapView 機能であるスナップショットと いくつかの類似点があります 対象読者 このホワイトペーパーは SnapView クローンを説明または実装する必要があるすべての人を対象にしています クローンの一般的な知識のほか パフォーマンスに関する重要な情報も提供します クローンを実装して定期的に管理する予定がある読者は クローンに関する運用と手順の詳細について 製品のドキュメントを参照してください SnapView スナップショットとの比較 クローンとスナップショットは ソース LUN のポイント イン タイム ビューです スナップショットと同様に クローンは切り離すと読み取りおよび書き込みが可能です さらに クローンまたはスナップショット セッションのデータは ソースにリストアすることができます ( データが破損した際にソース データを復旧する場合など ) また スナップショットと同様に 各クローンのソースは最大で 8 つのクローンを持つことができます クローンとスナップショットの本質的な違いは スナップショットがポインタ ベースのモデルであり Copy on First Write のデータが予約済み LUN に格納されるのに対して クローンはソースのバイナリ コピーであり LUN のすべてのデータを含むということです この違いから クローンを使用することの 2 つの重要なメリットとして データ保護とパフォーマンスの向上が得られます これらの違いがクローンとスナップショットの容量要件や可用性の違いにも関係しているという点も 覚えておく必要があります EMC CLARiX SnapView クローン詳細レビュー 5

7 ソース LUN へのリストア データのポイント イン タイム ビューを提供してコンカレント アクセスを実現する以外に クローンとスナップショットのレプリカは ソース LUN でデータ破損が発生した場合にデータを復旧するための手段になります SnapView レプリカのデータを使用すると ソース LUN のコンテンツをほぼ瞬時に そのレプリカに関連づけられているポイント イン タイムにリストアすることができます リストア操作で最適な結果を得るには ソース LUN のリストアに使用するレプリカから意図したとおりのデータのビューを確実に得られるように レプリカが作成されたらすぐ プロアクティブにレプリカ内のデータの状態を確認します このような確認には 整合性チェックなど データの整合性を確保するためのアプリケーション固有の手段も含まれます SnapView におけるクローンおよびスナップショットのリストア操作は 標準的なデータ リカバリ プロセス ( ディスク ベースまたはテープ ベース ) よりもはるかに高速です これは リストアが差分処理によってバックグラウンドで実行されるので ソース LUN が瞬時にリストアされたように見えるためです ( この操作の詳細については クローンのリバース同期 のセクションで説明しています ) ハードウェア障害からの保護 ソース LUN で ソフトウェアではなくハードウェアに関係する 2 点障害が発生した場合は クローンによって新たに 追加の保護が提供されます クローンはソース LUN とは異なるドライブに定義されるため ソース LUN が使用できなくなってもクローンは引き続き使用できます ソース LUN で 複数ドライブの障害 バス障害 またはその他のストレージ システム障害が発生するという考えにくい状況でも 影響を受けるのがハードウェア コンポーネントの全体ではなく一部であれば クローンは引き続きアクセス可能です このとき ソース ボリュームが復旧不可能であると考えられる ( またはリカバリするよりも早く使用する必要がある ) 場合には クローンを本番環境に移すこともできます これは 同じストレージ システム内の別のデバイスへのフェイルオーバーと同じ意味を持ちます クローンの使用が必要になった場合 ユーザーが注意すべきことは クローンにはポイント イン タイムの参照点があり それはソースと異なる可能性が高いため クローンに反映されていないソース データは失われるということです パフォーマンス クローンはデータのポインタではなくデータの完全なコピーなので 切り離されるとバックアップなどのパラレル I/O が可能になり その際 ソース LUN にパフォーマンス上の影響を与えません これは ポインタ モデル ( セカンダリ サーバからの読み取りがソース LUN に向けられる ) が原因で発生するスピンドルの競合や Copy on First Write 動作 ( ソース LUN のオリジナル ブロックが予約済み LUN にコピーされる ) など スナップショットを使用した場合のパフォーマンスへの影響とは対照的です 1 クローンを使用する際は クローン向けの I/O リクエストによって本番 LUN ディスクへのアクセスが発生することがないように ソース LUN と異なる RAID グループに属するドライブにクローンが置かれていることを確認します 切り離されたクローンは ソース LUN のピア SP によって I/O サービスを受けることができるため スナップショットの場合よりもロード バランシングの柔軟性が高くなります 1 SnapView スナップショットの詳細については CLARiiON SnapView Snapshots and Snap Sessions Knowledgebook および SnapView の製品ドキュメントを参照してください EMC CLARiX SnapView クローン詳細レビュー 6

8 容量の要件と可用性 クローンはソース LUN の正確なレプリカであるため 常にソース LUN と同じ領域を占有するという点に注意する必要があります つまり 原則としてクローンは Copy on First Write データのみを格納する SnapView 予約済み LUN よりも多くの領域を必要とします 2 また このことから 初めて使用する際にはソースのデータとクローンの同期が完了するまで クローンを使用できません その後は クローンを差分再同期することができます 同期に関しては クローンによるパフォーマンス上のメリットが得られるのは クローンが切り離されて クローンの 1 回目の同期 および継続的な差分再同期にかかる時間が得られる場合のみであることに注意が必要です これらの操作は ソース LUN に対して多少のパフォーマンス上の影響があるため ピーク時間帯を避けて実行する必要があります 同期操作に関するパフォーマンスの考慮事項については パフォーマンスに関する考慮事項 のセクションで詳しく説明しています 表 1 に SnapView クローンと SnapView スナップショットの類似点と相違点をまとめます 表 1: スナップショットとクローンの特徴 特徴スナップショットクローン 読み書き可能 インスタント リストア 作成直後から使用可能 : あらかじめ同期が必要 破損したソース LUN のリスト アに使用可能 ソース LUN にハードウェア障害 ( 複数のドライブやバスの障害など ) が発生したときに使用可能 ソース LUN よりも少ない領域 レプリカ更新後のアクセスはソース LUN のパフォーマンスに影響しない : クローン コンポーネント (SP バス ドライブなど ) に影響しないハードウェア障害であることが条件 : わずかに少ない ( ソース LUN の変更量に依存 ) : 二重読み取りによるスピンドルの競合 Copy on First Write など MirrorView/Synchronous との比較 : ただし切り離し時 MirrorView について詳しいユーザーは クローンをストレージ システムにまたがるミラーと対比して ストレージ システム内部のミラーと考えることができます クローンとミラーの本質的な違いは 両者の設計目的にあります MirrorView は 主に災害復旧のために設計されており 通常の状態ではプライマリとミラーがアクティブにミラーリングを行う ( 同期状態 ) ようになっていますが クローンはそれよりも破損からの復旧に使用されるように設計されています このような意図された用途に基づき ミラーは通常 同期状態にあります これは その目的がデータ消失からの保護であるためです それとは対照的に クローンは通常 切り離されたポイント イン タイム コピーです これは その目的がデータ破損からの保護であるためです 言い換えると クローンによる保護の前提は その内容が以前のポイント イン タイムのもの 2 例外は ソース LUN のすべてのチャンクがスナップショット キャッシュに書き込まれ そのため このキャッシュにコピーする必要がある場合です つまり LUN 全体がコピーされる上に そのコピーおよびそれを記述する対応メタデータが加えられるので LUN に予約されたスナップの内容はソース LUN 自体よりも大きくなります EMC CLARiX SnapView クローン詳細レビュー 7

9 であるということです ユーザーは クローンによる以前のポイント イン タイムに 破損したソース LUN をリストアすることができます したがって リカバリ手順もクローンとミラーとでは異なります 災害によって LUN が使用できなくなった場合には 本番環境をミラーされた LUN にフェイルオーバーすることができます 一般的に クローンはデータ破損からの保護を行うため ソース LUN をデータの以前 ( 原則として破損が発生する前 ) のポイント イン タイム コピーの状態まで 差分リストアすることができます ただし 前のセクションで説明したように ソース LUN に影響するハードウェア障害がストレージ システムで二重に発生することも考えられます その場合は MirrorView を使用している場合にミラーされた LUN にフェイルオーバーするのと同様に 本番環境をクローンにリダイレクトすることができます ユーザーは 同期コピーとポイント イン タイム コピーの本質的な違いを認識しておく必要があります ポイント イン タイム コピーの内容は 最新のデータではありません したがって クローンを使用したリカバリでは 本番データは以前のポイント イン タイムにリストアされるので 一部のデータが失われます このようなケースでは 大きなデータセットを復旧するためには多少のトランザクションが失われることは許容できる という前提が置かれています 同期ポリシー つまりクローンを再同期し ベスト プラクティスとしてクローン上のデータの状態を確認する頻度を選択する際には このトレードオフを考慮する必要があります クローンとミラーのもう 1 つの違いは MirrorView の場合 ミラーされた LUN にサーバ I/O がアクセス ( 読み取りまたは書き込み ) することは SnapView スナップショットを経由するか ミラーされた LUN を本番用にプロモートしない限り 不可能であるということです 一方 クローンは 切り離されるとサーバからアクセス可能であり 読み取りおよび書き込みを実行できます クローンに対して書き込みが行われていた場合は 選択した同期オプションに基づいて ソース LUN からのデータをコピーしてその書き込みを上書きするか その書き込みをソース LUN にコピーするかを選択できます FLARE リリース 24 からは クローンをミラーと組み合わせて使用することで ソース LUN 上のデータ全体のコピーか リモート サイトにあるミラー データの読み取り / 書き込み可能な追加のデータを得ることができます この新しい機能により 特定のソース LUN に関して 両方のデータ保護方法のメリットを活かすことができます これで ( クローンを経由した ) すばやいリカバリ機能によって LUN をデータ破損から保護するとともに 災害復旧のためにミラーリングすることができます MirrorView と同様に ソースとクローンの物理サイズは同じでなければなりませんが RAID やディスクのタイプは異なっていてもかまいません さまざまな RAID タイプやディスク タイプにおけるパフォーマンスの考慮事項については クローンに関するパフォーマンスの考慮事項 のセクションで詳しく説明しています 表 2 に SnapView クローンと MirrorView/Synchronous の類似点と相違点をまとめます 表 2:SnapView クローンと MirrorView/Synchronous の比較 特徴クローンミラー コピーの場所 同じストレージ システム セカンダリ ストレージ システ ム コピーへのコンカレント アクセスソース LUN と同じ量の領域が ( コピーごとに ) 必要ソース LUN にハードウェア障害が発生したときに使用可能 : ただし切り離し時 : ミラーされた LUN が本番用にプロモートされた場合のみ可 : クローン コンポーネント (SP バス ドライブなど ) に影響しないハードウェア障害である : プライマリ ストレージ システム全体が使用不可能になった場合も含む EMC CLARiX SnapView クローン詳細レビュー 8

10 ことが条件 EMC CLARiX SnapView クローン詳細レビュー 9

11 SnapView がサポートするビジネス オペレーション SnapView では 特定のデータセットに対して データ アクセスの面で妥協することなく 一般的なビジネス環境で必要とされるさまざまなタスクを実行することができます 実際のクローンの実装はスナップショットとは大きく異なりますが クローンの用途は スナップショットと非常に似ており 本番アプリケーションのパフォーマンスに影響を与えることなく 並行処理が可能です これにより ユーザーは 本番オペレーションと並行して実行可能な補足的タスクを 本番処理のパフォーマンスについて妥協することなく実行できます これらのタスクには ディスク ベースの以下の処理が含まれます バックアップおよびリカバリ 意思決定支援とデータ テスト データ ウェアハウジング データ レポート作成 データ伝送 ユーザー トレーニング バックアップおよびリカバリ スナップショットによるポイント イン タイム ビューに加えて クローンによるポイント イン タイム コピーが存在することにより ユーザーはバックアップ環境に最適な機能を選ぶことができます スナップショットは瞬時に作成されるため 作成してすぐにバックアップ手順で使用できます しかし スナップショット ベースのバックアップは 原則として本番 LUN での読み取りが行われるため 通常 本番 LUN にパフォーマンス上の影響があります 一方 クローンでは 初めてデータ全体のコピーを作成するときには わずかながら余分に時間がかかります ( それ以降の同期は 差分処理されるので時間が短くなります ) コピーが作成され 本番 LUN から切り離されると バックアップ手順は完全に本番 LUN から独立して動作するため スナップショット ベースのバックアップで生じるパフォーマンスへの影響は排除されます ソース LUN のリカバリでは SnapView スナップショットまたはクローンを使用してリストアを実行できます しかし 状況によってはバックアップからのリカバリが必要です たとえば ファイルが 1 つだけ失われている場合 ファイル システム全体を以前のポイント イン タイムに復旧して 1 つのファイルだけを復旧することは カスタマーのリカバリ目的に合致していない可能性があります 別の方法では ソース LUN にアクセスするサーバ以外のサーバにスナップショットとクローン レプリカを提示し リストアする個別のファイルをネットワークで転送します または EMC Replication Manager を使用して ソース LUN および関連するクローンまたはスナップショットに対する単一のサーバからの同時アクセスを許可し リストアする個別のファイルをソース LUN にコピーします 意思決定支援とアプリケーション テスト クローンは スナップショットと同様に 意思決定支援およびデータベース テストで使用することができます ソース LUN 上のデータに影響を与えることなく 8 つまでのソース LUN を作成 使用 変更 さらに破棄することも可能です 意思決定支援およびアプリケーション テスト環境では I/O アクティビティが多いため クローンによるパフォーマンス上のメリットは特に顕著に現れます クローンのメリットが特に大きい意思決定支援テストの 1 つのタイプは クローンを使用したソフトウェア アップグレードと それに続く互換性およびパフォーマンスのテストを実行できる EMC CLARiX SnapView クローン詳細レビュー 10

12 ことです クローンにアップグレードをインストールすることで アップグレードに関して互換性またはパフォーマンス上の問題が発見されたとき 簡単にソースを元の状態に戻すことができます 同様に アップグレードに問題がない場合は クローンへのすべてのキャッシュ データがサーバによってフラッシュされたことを確認してから そのクローンをクローン グループから取り除き それをソースとして または単にクローン グループに関連づけられていない独立した LUN として使用できます データ ウェアハウジング クローンは データ ウェアハウジング アプリケーションや その他のサードパーティ製アプリケーションで使用することもできます データをクローンにコピーし ソースから切り離しすることで クローンからデータ ウェアハウス アプリケーションにデータを与えて 本番アプリケーションのパフォーマンスに影響するのを避けることができます 同様に 他のサードパーティ製アプリケーションで データをソースではなくクローンからインポートできることも クローンによって可能な並行処理の 1 つの例です データ レポート作成 多くのアプリケーションでは レポート作成を実行するには大量のシステム リソースが必要とされるので レポート対象の本番システムに与える影響を最小限にするためには 慎重にスケジュールを決定しなければなりません ただし 並行処理のもう 1 つの例として クローンからレポート作成を実行することができます レポートを作成する際に 影響を与える可能性が低い時間帯を選んで実行するのではなく 今までよりも戦略的に実行したり レポート作成のニーズに合わせて都合のよい回数だけ実行したりすることができます データ伝送 ユーザーはクローンを使用することによって簡単にデータのコピーを複数作成できるので 多くのことが実現可能になりました そのうちの 1 つが データ伝送です たとえば オペレーティング システムが環境に合わせて適切にカスタマイズされた 起動ディスクの複数のコピーが必要な場合を考えます クローンを使用すると サーバが要求に応じた動作を実行するために必要なすべての情報と設定を含むように LUN をカスタマイズできます 次に それをクローン グループのソースにして ゴールド マスター コピーとして使用します 最後に 他のサーバで使用するために この起動ディスクのクローンを作成することができます さらに クローン グループからクローンを取り除くことも 後から追加のクローンを作成することもできるので 運用環境全体で使用するために多くのコピーをゴールド マスターから派生させることも簡単です ユーザー トレーニング 本番データのパフォーマンスやデータの整合性に影響を与えることなく ユーザーが本番アプリケーションやデータについて学ぶために クローンを使用することもできます パフォーマンスへの影響や本番データに影響を与える危険がない状態でデータにコンカレント アクセスできるメリットは このシナリオにも当てはまります 他の CLARiX レプリケーション ソフトウェアでのクローンの使用 クローンは SnapView スナップショットおよび SAN Copy で使用できます リリース 24 では クローンは MirrorView/S および MirrorView/A でも使用できるようになりました ( 一部制約については MirrorView とクローンの使用 セクションで説明します ) EMC CLARiX SnapView クローン詳細レビュー 11

13 SnapView スナップショットとクローンの使用 同じソース LUN のクローンとスナップショットを作成できるだけでなく クローン自体のスナップショットを作成することもできます これにより 複数のレベルでデータのコピーを持つことが可能になります これが特に役立つのは さまざまなテスト状況にさまざまなデータベースを用意する場合です クローンではなく SnapView セッションをオンラインにすることができます データ破損 ( またはテストに悪影響を与える他の問題 ) が発生した場合は SnapView セッションを破棄して 変更されていないクローンをオリジナルの状態で残し 使用可能にしておくことが可能です これにより 同じベース レプリカでテストを継続して テスト リソースを作成する手間を最小限に抑えることができます また 複数のレベルのコピーをこの方法で実装して 本番データのコピーの総数を増やすこともできます 図 1 に示した実装では コピーの最初のレベルは週次のクローンで 第 2 レベルはクローンごとに週のそれぞれの日について作成された 日次のスナップ セッションです Production Clones Snap sessions Week 1 Week 2 Week 4 Day1 Day2 Day7 Day7 図 1: スナップショットとクローンの使用 スナップショット プロセスは スナップの対象がクローンであっても 通常の LUN であっても同様に動作します つまり スナップショットはクローンと LUN に同じマッピング機構を使用します SAN Copy とクローンの使用同じストレージ システム内にデータのコピーを持つだけでなく 別のストレージ システムにもデータのコピーを持つことが必要な場合があります 図 2では SAN Copyとクローンを組み合わせて使用しています この図から分かるように SAN Copyを使用してソースLUNをコピーするか またはクローンをコピーするかを選択できます EMC CLARiX SnapView クローン詳細レビュー 12

14 Production Server Source Copy from the Source SAN Copy OR Clone Copy from the Clone SAN Copy 図 2:SAN Copy とクローンの使用 パフォーマンスを重視するユーザーは SAN Copy を使用してクローンをコピーすることが多くなります これは 本番データにまったく影響を与えることなくコピーが可能だからです MirrorView とクローンの使用 すでに説明したように リリース 24 ではミラーをクローンする機能が加わりました MirrorView/S または MirrorView/A と SnapView は ソース サイトとリモート サイトのどちらでも同じソース LUN を共有することができます 以下のことが可能です 1. MirrorView プライマリ イメージのクローン作成 ( プライマリ イメージがローカル ストレージ システムでクローン ソースになる ) 2. MirrorView セカンダリ ( リモート ) イメージのクローン作成 ( セカンダリ イメージがリモート ストレージ システムでクローン ソースになる ) 3. MirrorView プライマリ イメージおよび MirrorView セカンダリ イメージのクローン作成 ただし 図 3 に示したように クローンをミラーリングすることはできません この図のように SAN Copy を使用してアレイ間でクローンをコピーする必要があります Production server MV/A or /S Primary Can clone a mirror MV/A or /S Secondary Clone Clone Cannot mirror a clone EMC CLARiX SnapView クローン詳細レビュー 13

15 図 3:MirrorView とクローンの使用 ソース サイトでクローンを使用すると 高速リカバリ オプションによって既存の災害復旧の実装を拡張することができます 独立したドライブに全体のコピーを置き 切り離すと ソースに影響するハードウェア障害とデータ破損の両方のエラーに対する保護が可能です ソース サイトにクローンを実装すると 特定のソース LUN だけ ( システム全体ではなく ) が影響を受けた場合 リモートからリカバリを行う必要がなくなります ローカルでのリカバリの方がはるかに高速です リモート ミラーのクローンを保持することにより データ破損に対する MirrorView による保護がさらに強化されます MirrorView/S を使用すると ソースが受け取るすべての書き込みは直ちに DR サイトと同期するため そのデータの破損もコピーされます リモート デバイスのクローンがあり 切り離されると 特定の適切なポイント イン タイムへの高速リカバリが可能です リモート サイトにも全体のコピーがあると リモート MirrorView/S および MirrorView/A ターゲットに影響するハードウェア障害に対して保護が強化されます もう 1 つのメリットは リモート サイトのデータに読み取り / 書き込みアクティビティでアクセスする際に スナップショットに対してパフォーマンス上の影響がないということです ミラーされた LUN のクローンを実装すると プライマリ データのコピーを災害復旧用に使用できる状態を保ったまま リモート サイトで本番データのコピーに対して操作を実行できます CLARiX オペレーティング ソフトウェアによるいくつかの制限が存在します 制限の一部は 以下のとおりです セカンダリ ミラー イメージに対するリバース同期はできない プライマリに対する逆同期は可能だが ミラーが管理上 切り離されている場合のみ セカンダリ イメージは プライマリでリバース同期が行われている場合はプロモートできない プライマリがロールバックで使用される場合 リバース同期はできない ミラーのクローンがサポートされることで 新しい同期状態を導入できました リモート ミラー同期化中状態は このクローンが関連づけられているセカンダリ イメージが現在同期または更新の途中であることを示します MirrorView/A または MirrorView/S の状態が同期化中の場合 リモート ミラーと関連づけられているクローンの状態は リモート ミラー同期化中になります MirrorView/A のペアが更新中の場合は セカンダリのクローンもリモート ミラー同期化中状態になります ミラーのクローンの詳細については すべての制約 ベスト プラクティス 使用例 パフォーマンスも含めて EMC Powerlink ( にあるホワイトペーパー MirrorView Knowledgebook で説明されています クローンの機能 このセクションでは 切り離しと再同期 クローン グループを構成するプロセスなど クローンの機能について説明します リリース 24 から Configure SnapView Clones ウィザードによって初期構成プロセスがガイドされます クローン グループの設定 およびクローンへのプライベート LUN の割り当ての基礎になる方針を作成して管理できますが このタスクに関係するステップの多くは自動化され ユーザーが初期設定を行う際に処理されます 初期構成が完了したクローンは Navisphere Manager または NaviCLI から操作します EMC CLARiX SnapView クローン詳細レビュー 14

16 クローンの基本的機能 データはソースからクローンにコピーすることができ これを同期と呼びます 反対方向のクローンからソースにコピーすることもでき これをリバース同期と呼びます 初期同期が完了したクローンは 通常は切り離されてセカンダリ サーバに提示されます クローンを切り離しすると クローンの切り離し後にクローンとそのソースのいずれかで変更された領域 ( エクステント ) は フラクチャ ログに記録されます フラクチャ ログはディスク上に置かれたビットマップであり クローン プライベート LUN として参照される領域です したがって この記録は電源が切れても保持され 保護と高可用性が確保されます 初回以降の同期またはリバース同期は ソースまたはクローン上で変更されたエクステントのみをコピーするという点で 差分同期の性質を持ちます 同期とリバース同期の両方で ソースへのサーバ I/O( 読み取りおよび書き込み ) を続行できます しかし セカンダリ サーバ I/O のためにクローンにアクセスすることはできません 同期またはリバース同期を開始する前に クローンへのすべてのサーバ アクセスが停止されていることを ( サーバでキャッシュされたすべてのデータをクローンにフラッシュすることも含めて ) 確認する必要があります アクセスが行われると サーバで書き込みエラーが発生したり 場合によってはパニックが発生したりします ( 特に クローンがサーバ起動デバイスとして使用されている場合 ) ユーザーは データをクローンに同期する ( またはクローンからデータにリバース同期する ) 速度を選択できます これにより ストレージ システムの CPU サイクルを同期操作に向けるか他の I/O 処理タスクに向けるかの間で優先順位を付けることができます クローン同期のパフォーマンス情報は クローンに関するパフォーマンスの考慮事項 のセクションで説明されています クローン同期同期は データをソース LUN からクローンにコピーするプロセスです クローンと特定のソースの関連づけを作成すると フル同期が行われます ソース LUN のすべてのエクステントがクローンにコピーされて 完全な冗長性を持つレプリカが作成されます その後の同期では 前回の同期以降にソースで変更されたすべてのデータがコピーされます クローンが切り離しされている間にセカンダリ サーバからクローンに直接行われた書き込みがあると それらは上書きされます これは 本質的にはクローンに対する更新です ソース LUN からの差分の更新と同期が完了すると クローンを再び切り離して 適切なポイント イン タイムの参照を維持することができます クローンの状態が同期化中であるときに切り離し操作が実行され 初期同期が完了していないと その次の同期ではソース LUN からの完全なコピーが必要になります しかし クローンの初期同期が完了している場合は その次の同期では差分変更のみがコピーされます クローン LUN は ソース LUN の代替 SP に割り当てることができます しかし クローン LUN は同期プロセス時にはトレスパスされ 切り離しされると元の SP に戻ります たとえば ソース LUN が SPA に属し クローンが SPB に属している場合 クローンは 同期中は SPA にトレスパスされ 切り離されると SPB に戻ります クローン フラクチャユーザーが取得しようとしているデータについて ポイント イン タイムの状態を作成し クローンをセカンダリ サーバでアクセスできるようにするには クローンをソースLUNから切り離しする必要があります 図 4に クローンの切り離し 同期 リバース同期のほか クローン グループからのクローンの削除 およびクローンのプロパティの表示のメニュー オプショ EMC CLARiX SnapView クローン詳細レビュー 15

17 ンを示します すべての機能は アクションの対象となるクローンのアイコンを右クリックすることにより Navisphere ツリーからアクセスできます 図 4: クローンの切り離し 切り離しされたクローンは セカンダリ サーバに提示して読み取りおよび書き込み I/O で使用できます 通常 この場合の書き込みは テストなどによるものであり 破棄されることが前提です ソースからクローンへの次回の同期で クローンへの書き込みは破棄され クローンが切り離されている間にソース LUN に書き込まれたデータはコピーされます クローンに対して行われた書き込みをソース LUN にコピーするには リバース同期を使用します クローンのリバース同期リバース同期は データをクローンからソースにコピーするプロセスです リバース同期は 通常 クローンの切り離し後に発生したデータ破損の後で ソースをリストアするために使用します 前述したように リストアを成功させるには ベスト プラクティスに従ってクローン上のデータの状態をプロアクティブに確認する必要があります リバース同期の開始前に サーバでキャッシュされたすべてのデータがフラッシュされ サーバのすべてのバッファが破棄されていることを確認しなければなりません 詳細については Navisphere Manager Help を参照してください クローン グループ内の他のクローンは リバース同期プロセスの開始前に自動的に切り離されます これは リストア プロセスが成功したとき リストアされたデータ変更がその後の同期によって他のクローンに反映される前に リストア プロセスの成功を確認できるようにするためです さらに リバース同期操作の実行に使用されたクローンは オフラインでなければなりません 図 5 に示すように 火曜日のレプリカを使ってリストア操作が開始されますが 他のセッションはそのまま中断なしで続行されます EMC CLARiX SnapView クローン詳細レビュー 16

18 Monday view X Source LUN [Saturday view] X Source LUN instantly appears to have Tuesday view of data Production server X Tuesday view... Friday view Backup server Tuesday replica selected for restore 図 5: リストア操作で使用するレプリカの選択 リバース同期の際は コピー機構により 同期が直ちに始まってすぐ ソースはクローンと同一であるように見えます これは ソースへの書き込みリクエストをクローンにミラーすること および読み取りリクエスト ( まだソース LUN にコピーされていないエクステントに対するもの ) を直接クローンにリダイレクトすることによって実現されます 図 6 に このプロセスを示します ここでは クローンに保存されているオリジナルのデータにソース LUN 上の変更データが上書きコピーされます リバース同期の間 本番サーバからの書き込みはソース LUN に書き込まれ クローンにミラーリングされます そのため リバース同期が完了した時点で クローンとソースはバイト単位で一致します Writes Source A B C D Writes mirrored to clone Production server Reads Clone A B C D 図 6: クローンのリバース同期 リバース同期が完了すると クローンの状態は Synchronized( 同期 ) に移行し クローンはユーザーが明示的に切り離しするまで切り離されません ( 次に説明する保護されたリストアのシナリオとは対照的です ) リバース同期が始まる前に切り離された他のクローンは 再同期するようにユーザーが指定するまで切り離されたままです クローンのリバース同期 保護されたリストアリバース同期における保護オプションの拡張として クローンの保護されたリストア オプションを有効にすることができます 保護されたリストア オプションでは リバース同期が始まると そのときのクローンの状態が維持されることが保証されます つまり ソースLUNへの書き込みを受け取っても それは保護されたクローンにはミラーリングされません 代わりに クローンがソースにリバース同期されている間 サーバがソースとの間で行う読み書きはコピー オン デマンド機構 (SnapViewスナップショットとの関係で知られているCopy on First Writeを逆方向にしたもの ) を使って管理されます 図 7に このプロセスを示します 受け取ったI/Oが読み EMC CLARiX SnapView クローン詳細レビュー 17

19 取りまたは書き込みの対象とする領域が 直ちにクローンからコピーされています ソースへのコピーが完了すると 本番サーバからの I/O が受け入れられます Writes and reads Source A B C D Writes NOT mirrored to clone Production server Clone A B C D 7: 保護されたリストア オプションを有効にした状態でのクローンのリバース同期 クローン上にポイント イン タイム データを維持するという目的を守るために 保護されたリストアを有効にした状態でリバース同期が完了すると クローンは切り離されます ソース LUN が有効にされて リストアが意図したとおりに行われたことと クローンのポイント イン タイム コピーを維持する必要がなくなったことが確認されたら 必要に応じてクローンを再同期することができます 保護されたリストア操作によるソースのリバース同期で使ったクローンは 再びソースにリバース同期するために使用できるため リカバリを複数回試行することができます 保護されたリストア機能は 最初にストレージ システムのレベルで有効にする必要があります ( この次に説明 ) その後 任意のリバース同期操作で選択できるようになります 図 フラクチャ ログのリセット FLAREリリース26では ソースまたはクローンLUNが破損した場合に ソースとクローンの間でデータの同一性を再確立するために フル同期機能が追加されました Navisphere CLIで使用可能なclone resetfracturelogコマンドは ソースまたはクローンLUNのすべてのデータ チャンクを変更済みとマークします これにより ユーザーはフル同期もリバース同期も実行することができます このスイッチは クローンが管理的に切り離され 状態が非同期またはリバース非同期の場合にのみ使用できます このスイッチを実行した後は フル同期およびリバース同期操作を実行できます このコマンドの使用方法の詳細については Powerlink にある EMC SnapView Command Line Interface (CLI) Reference を参照してください クローンの構成 ソース LUN および関連するクローンは クローン グループとしてグループ化されます クローン グループを作成するには まずソースを特定します このソースにクローンが追加されると 追加されたクローンがクローン グループのメンバーになります クローン グループに追加されたクローンは 初期同期が行われて ソース LUN の内容を含むようになります クローンは 切り離されるまでソース LUN の内容で継続的に更新され 通常は 前述した各種のコンカレント アクティビティのためにセカンダリ サーバに提示されます ユーザーは定期的にクローンを再同期してソース LUN の内容で更新し その後でクローンを切り離して 再びセカンダリ サーバに提示することができます リリース 24 から クローン グループの構成は [Navisphere] タスクバーから Clone Configuration ウィザードを使用して実行できるようになりました このウィザードは 図 8 に示すように [Configure SnapView Clones] オプションを選択することによって起動できます EMC CLARiX SnapView クローン詳細レビュー 18

20 図 8:Navisphere Clone Configuration ウィザード Navisphere Clone Configuration ウィザードは クローン グループを構成するために必要なすべてのステップを その選択から同期までまとめて扱います 今までは 最初にクローン プライベート LUN を構成して割り当てる必要がありました 次に クローン グループを作成します 最後にクローンを個別のクローン グループに追加します これらの各ステップが独立したタスクとして行われていました 今回 Clone Configuration ウィザードは これらすべてのタスクをまとめる 1 つのウィザードとして クローンのセットアップ ステップを容易にしています Clone Configuration ウィザードは 以下のタスクを行います 1. クローン プライベート LUN をバインドし 割り当てる ( 必要な場合 ) 2. 指定されたソース LUN でクローン グループを作成する 3. クローンを作成し クローン グループに追加する 4. 必要に応じて クローンをセカンダリ サーバのストレージ グループに割り当てる 5. 同期を開始する また このウィザードでは 同期レートを [Medium] [Recovery Policy] を [Automatic] に設定し [Protected Restore] を無効にしています これらは自動的に設定されるため ユーザーが実行しなければならないステップは少なくて済みます これらの設定の詳細については Powerlink の Navisphere Manager Help を参照してください 複数の操作の場合 特に他の使用しやすい Replication and Storage Management ウィザードとともに使用する場合 これはストレージ システムを設定する上で貴重な時間の節約になります EMC CLARiX SnapView クローン詳細レビュー 19

21 クローン グループおよびプライベート LUN を作成する以前の方法に慣れているユーザー または構成を細部まで制御する必要がある場合は 引き続き標準の Navisphere ツリー インタフェースと CLI を使用できます 図 9 に クローンをクローン グループに追加するための 従来型のダイアログ ボックスを示します この方法では クローン同期レートなど ウィザードでは省略されるいくつかのプロパティを細かく制御することができます これらの制御については この後のセクションで詳しく説明します 図 9: クローン グループへのクローンの追加 (Navisphere ツリー ) 特定のソース LUN についてポイント イン タイム クローンが不要になったら クローン グループからクローンを取り除くことができます クローン グループから取り除かれたクローンは 取り除かれる前に持っていたデータは保持しますが クローンに関連づけられたメタデータは含みません そのため その時点における独立した LUN として機能します SnapView スナップショットでは各ソース LUN に 8 つのクローンを関連づけることができるため 各クローン グループでは最大 8 つのクローンを扱うことができます クローン グループの数とストレージ システムあたりのクローンの数は ストレージ システム モデルおよび FLARE リリースによって変わります クローンの制限の詳細については 付録 : クローンの制限 セクションを参照してください クローン プライベート LUN クローンのフラクチャ ログは クローン プライベート LUN に格納されます Clone Configuration ウィザードは これらのプライベート LUN が構成されていなければ 自動的にバインドし 割り当てます 図 10 に 手動での構成を行うことを選択し ウィザードを利用していないユーザー用の クローン プライベート LUN を割り当てるためのウィンドウを示します EMC CLARiX SnapView クローン詳細レビュー 20

22 図 10: クローン プライベート LUN の割り当て クローン プライベート LUN は SP ごとに割り当てる必要があり それぞれが 128 MB( 全体で 256 MB) である必要があります 128 MB を超える LUN をクローン プライベート LUN として使用することもできますが 128 MB を超える部分は使用されません また この同じウィンドウで SnapView に対する保護されたリストア機能をストレージ システム レベルで有効にすることもできます ストレージ システム レベルで有効にすると リバース同期操作でも必要に応じて有効にすることができます CLARiX 整合性操作 FLARE リリース 19 では クローンの整合性機能など ストレージ システム ベースの整合性が SnapView 機能に追加されました 整合性機能により 相互依存書き込み順序の整合性が維持されるレプリカのポイント イン タイム セットが得られ それによって複数 LUN データセットの再起動可能なポイント イン タイム レプリカが得られます 一般的に 相互依存書き込み順序の整合性が最も重要なのは データベースとログの LUN など 関連するデータを含む複数の LUN が存在するデータベース環境で その間に書き込み順序の依存関係がある場合です さまざまなレプリカ メンバー間におけるデータの論理的な整合性を維持するには 相互の書き込み順序の依存関係を保つ必要があります たとえば データベースの各エントリには 対応するログ エントリが必要です これが存在しない場合 データの破損や削除が発生するおそれがあります これらの考慮事項は ボリューム マネージャを使用して複数 LUN ボリュームやファイル システムを作成する場合にも適用されます FLARE リリース 19 では整合性操作が追加されたため SnapView を使用して整合性のとれたローカル レプリカを作成できます EMC CLARiX のコンシステンシ テクノロジーにより レプ EMC CLARiX SnapView クローン詳細レビュー 21

23 リカはどちらの SP でも所有することができます ソース LUN およびそれに対応するレプリカは 同じ CLARiX ストレージ システム内に存在しなければなりません クローンのコンシステント フラクチャ操作 SnapView のコンシステント フラクチャ機能は ストレージ システム ベースの整合性のとれたレプリカをユーザーに提供します 他の SnapView 操作と同様に 整合性操作は Navisphere Manager GUI と Navisphere CLI のどちらからも開始できます そのため 整合性操作を手動で管理する (Navisphere GUI または CLI を使用 ) ことも Navisphere CLI を使用して整合性操作をスクリプトに組み込むことも可能な柔軟性が得られます SnapView のコンシステント フラクチャでは グループ という概念や関連づけは定義されていません 操作の対象となるオブジェクトのセットは 操作が実行された瞬間に存在する ( したがって さまざまなクローンが切り離される ) だけであり その後 関連づけは存在しません そのため 操作ごとの柔軟性が得られ 必要に応じて異なるオブジェクトに対する操作が可能になります ストレージ システム ベースの整合性とサーバ ベースの整合性今回 ユーザーには データを複製する際に ストレージ システム ベースまたはサーバ ベースの整合性のいずれかを採用するオプションが与えられました それぞれの方法のプロセスは異なりますが どちらもレプリカ間における書き込み順序の整合性を維持する上で有効です ストレージ システム ベースの整合性は サーバ アプリケーションには依存しません つまり アプリケーションを停止する必要はありません その代わりに 整合性のとれたレプリカ セットの作成プロセスの間 ストレージ システムは アプリケーションではなく依存する書き込みを一時的に停止します このプロセスはサーバおよびアプリケーションに依存しないため ストレージ システム ベースのレプリカは サーバの電源が突然切れた ( またはクラッシュした ) 場合と同様の状態になります そのため レプリカをセカンダリ サーバで使用可能な状態にするためには 通常 標準的なデータベース ソフトウェアのリカバリ機能 すなわち電源オフと再起動の後に再開するというシナリオと同等の操作を実行する必要があります さらに SnapView は サーバ アプリケーション レベルではなくストレージ システム レベルで動作するため 複数のアプリケーション間で書き込み順序の依存関係がある環境では特に有効です そのような連携した環境の一般的な例として データ ウェアハウスがあります しかし ポイント イン タイム レプリカを作成する前に 一時的にアプリケーションを停止状態にすることが必要な場合もあります そのような場合は サーバ ベースの整合性を選択できます たとえば Replication Manager を利用します Replication Manager は 整合性のとれたレプリカ セットを同期する際に 特定のアプリケーション内でネイティブの停止機能を利用します たとえば Exchange 2003 では VSS Oracle ではホット バックアップ モードを使用します これらのレプリカはデータの有効なバックアップ コピーであり セカンダリ サーバで直ちに使用できます さらに Replication Manager はサーバおよびアプリケーション レベルで動作するため さまざまな CLARiX ストレージ システムに所属するソース LUN のレプリカを調整できます したがって SnapView 整合性操作を使用して作成されたレプリカでは サーバやアプリケーションの停止は不要ですが セカンダリ サーバで使用する前には追加のリカバリ手順が必要になる可能性が高いと考えられます ( 関係するすべての LUN が 1 つのストレージ システム上に存在することが前提 ) 一方 Replication Manager( または他のサーバ ベースの整合性ツール ) を使用して作成されたレプリカでは 本番アプリケーションを短時間停止させることが必要になりますが セカンダリ サーバでの使用に対する準備の程度は高まります EMC CLARiX SnapView クローン詳細レビュー 22

24 EMC RM(Replication Manager) は RM がアプリケーションを停止させるための API と連携していない場合 アプリケーションが置かれるファイル システムの複製をサポートします その場合 複製の前にアプリケーションを停止させる CLI 機能を Replication Manager の呼び出しスクリプトに組み込むことができます また Replication Manager は クローンの整合的な切り離し操作もサポートしており CLARiX ストレージ システム全体にわたってレプリカを管理できます ストレージ システム ベースの整合性では ソースとそのレプリカが同一の CLARiX ストレージ システムに存在していることが必要です クローンのコンシステント フラクチャクローンのコンシステント フラクチャとは 書き込み順序が相互に依存するソースLUNに属する一連のクローンを切り離しすることです つまり 関係するソースLUNはクローンごとに一意である必要があります ( 同じソースLUNに属する複数のクローンに対してコンシステント フラクチャを実行することはできません ) Navisphere Manager GUIでコンシステント フラクチャを実行するには 図 11に示すように 標準の複数選択キー (Ctrlキーなど) を使って目的のクローンを選択してから メニューの [Fracture] を選択します 複数のクローンを選択するこのシナリオでは フラクチャの整合性が指定されます 図 11:Navisphere Manager によるクローンのコンシステント フラクチャ Navisphere CLI でコンシステント フラクチャを実行するには 次のスイッチを指定する必要があります -consistentfractureclone 前述の例では コマンド全体は次のようになります EMC CLARiX SnapView クローン詳細レビュー 23

25 snapview -consistentfractureclones -CloneGroupNameCloneId Exchange Log Clone LUN4_CloneGroup LUN18_CloneGroup ユーザーが開始した他の切り離しと同様に コンシステント フラクチャを実行したクローンも クローンのプロパティで [Administratively Fractured] と表示されます コンシステント フラクチャの途中で障害が発生してクローンの 1 つを切り離しできない場合 他のすべてのクローンは再同期のためにキューに入れられます クローンの状態が切り離し済み ( 管理 またはシステム ) である場合 コンシステント フラクチャを実行するクローンのセットに含めることはできません SnapView のコンシステント フラクチャの制限表 3 に SnapView の整合性操作に関する制限を示します 表 3:SnapView のコンシステント フラクチャ ストレージ システム CX3-80 CX3-40 CX700 CX500 CX3-20 CX3-10c CX300 クローンのコンシステント フラクチャ 分離するクローンの数 16 8 注意 :1 つのコマンドで指定できるオブジェクトの数には制限があります 1 つの整合性操作が Navisphere に送られてから次に送られるまでの時間は レプリケーション ポリシーに応じて一瞬であることも数時間であることもあります レポート作成機能 [Navisphere] タスクバーが追加されたことにより ストレージ システムの構成についてカスタマイズされたレポートを作成することができます システム上のすべてのクローンとその状態 および関連する LUN 数を示した クローン固有のレポートを作成することができます [Reporting] タブの [Generate Report] オプションを選択することにより Report ウィザードを起動できます レポートを生成するには 作成可能なレポートの一覧から [Storage Applications] の下の [SnapView Clones] を選択します 図 12 に例を示します EMC CLARiX SnapView クローン詳細レビュー 24

26 図 12:SnapView クローン レポート Report ウィザードでは 現在ストレージ システム上で行われているすべてのクローン操作の簡単な概要が分かります このレポートを使用して 必要に応じてストレージ システム内の複数のクローンを追跡したり その状態を確認したりすることができます クローンに関するパフォーマンスの考慮事項 以下の情報は クローンを使用する際のパフォーマンスに関するさまざまな考慮事項の一般的な概要です 具体的な環境において予想されるパフォーマンスの詳細については アカウント チームおよび専門の CLARiX C-Speed 担当者に連絡して その環境に関連するすべての要素を考慮してください 以下のセクションで取り上げているテストは CX3-80 で実施されました 最初のクローン同期のパフォーマンス ユーザーは同期レートを高 中 低から選択できます デフォルトは中です 同期レートが高の場合は 同期をできるだけ早く完了するように CLARiX の CPU の使用率が高くなり 同期レートが低および中の場合は 同期の間も多数の他の動作を実行できます その場合 同期レートは遅くなりますが 同期が与える影響も小さくなります ( 説明したように デフォルトは中であり このレートは同期の進行中でも変更できます ) 図 13 に 高 中 低の設定で行われた同期による帯域幅を示します このテストでは すべてのドライブは 73 GB 15k rpm 4 Gb/ 秒の RAID 5(4+1) で 同じ SP に属していました 図 13 には SP CPU レートが直接示されていないため さまざまな同期レートの下での帯域幅の説明と合わせて示されます 同期中 ソース LUN へのアクティブな I/O はありませんでした EMC CLARiX SnapView クローン詳細レビュー 25

27 MB/Sec High Sync Rate Multiple 1 Source 1 Clone Pairs Medium Sync Rate Low Sync Rate Number of Target LUNs 図 13:CX3-80 における初期同期レート : ファイバ チャネル ドライブ上のソースとクローン 複数のソース対クローンのペアを高速度で (CX3-80 で ) 同期した場合 以前のリリースの FLARE では 2 ペアで CPU 使用率がいっぱいになっていましたが 現在では 8 ペアまで処理できます これは FLARE リリース 26 のコードにおける変更によるもので FLARE リリース 24 に比べて同期中の CPU リソース消費が少なくなりました 本番データへの影響を抑えてクローン同期を実行する必要がある場合は 低い同期レートを選択してください このテストでは 8 つのクローンの同期レートを中にして同期した場合の影響はかなり小さいものでした 同じく 同期レートを低にして同期した場合は 高の場合に比べてさらに低くなりました 実際の影響は それぞれに固有の負荷に依存することに注意してください すでに説明したように このテストは 1 つの SP を使用して実行されました 両方の SP を使用すると 低速度および中速度で同期した場合の帯域幅は基本的に 2 倍になります しかし 高速度の同期では 2 つ目の SP を使用しても帯域幅は 2 倍になりません これは 書き込みキャッシュのミラーリングによって負荷が増えるためです 速度を選択する際は 実行する時間帯と ストレージ システムへの負荷を考慮してください 初期同期の速さと差分再同期の速さ初期同期は シーケンシャルなフル読み取り / 書き込み操作であり すべてのエクステントが連続しています この操作における帯域幅は 一般的にその後の再同期よりもかなり高くなります これは 再同期ではデータが不連続のエクステントに存在しているためです この 2 つの同期の違いがどの程度であるかは 更新されるエクステントがどの程度不連続であるかにのみ依存します また 個別のサーバ I/O ごとにフラクチャ ログを維持するオーバーヘッドを最小化するために 変更が追跡されるクローン エクステントのサイズは 実際のサーバ I/O よりもかなり大きくな EMC CLARiX SnapView クローン詳細レビュー 26

28 るのが一般的です ( エクステントの実際のサイズはソース LUN のサイズに比例 ) ここで重要な点は 再同期はエクステント レベルのものであり 個別の I/O レベルで行われるのではないということです 最後に パフォーマンス チャートはソース LUN 上で何もアクティビティがない期間に生成されたものであるという点に注意する必要があります 初期同期または差分再同期の間に ソース LUN 上で大きな I/O アクティビティがあると クローンで使用可能な帯域幅は減少します クローンにおける ATA ドライブの使用 ATA(Advanced Technology-Attached) ドライブをクローンとして使用できるかという質問がよく出されます 一般的に ATA ドライブのパフォーマンスは使用可能な書き込みキャッシュに依存します 書き込みキャッシュが ATA ドライブへのすべての書き込みをキャッシングできる限り ファイバ チャネル ドライブへの書き込みと ATA ドライブへの書き込みの間に目立ったパフォーマンスの違いはありません しかし 書き込みキャッシュがいっぱいになり データを ATA ドライブにフラッシュする必要が出てくると ATA ドライブの処理速度が追い付かない可能性があります この場合は ファイバ チャネル ドライブと ATA ドライブの間で違いが顕著になります ATA ドライブをクローンに使用する場合は それが ATA と SATAII のどちらであっても クローンの同期中に ATA ドライブが書き込みキャッシュからのフラッシュ要求を十分な速さで処理できないと ATA ドライブでの同期操作に時間がかかってしまうという点 そしてそれがアレイへの書き込み操作にとって マイナスの影響を与えるという点に注意する必要があります ATA ドライブは通常 CPU 使用率への影響が大きく ランダム書き込みの負荷に対する帯域幅が低いため これは特に考慮が必要な点です さらに いったんクローンが同期すると それが切り離されるまで ソース LUN へのすべての書き込みは同時にクローンにも書き込まれます このとき 書き込みキャッシュがいっぱいになると クローンへの書き込みは速度の遅い ATA の処理速度で処理されるため サーバの応答時間に影響します 最後に 本番 LUN に何らかのハードウェア障害が発生したときに使用可能であることがクローンの主要なメリットであることを考えると ATA LUN は本番 LUN の代替として適しているとは言いがたいということを認識する必要があります これらの理由から ファイバ チャネルのソース LUN に対して ATA クローンを実装することは一般的に推奨されません 他の ATA ドライブのクローンに限れば 推奨できます このことを考慮して パフォーマンスに関するこの後のすべての説明では クローンはファイバ チャネル ドライブ上に作成されていることを前提にします これらのパフォーマンス特性は ATA ドライブにクローンを実装すると大きく変わる可能性があることに注意してください 初期同期処理時のサーバへの影響 同期操作時の本番 LUN におけるパフォーマンスへの影響も 重要な考慮事項です すでに説明したように クローンはスピンドルの競合を避けるために ソース ボリュームとは別のドライブに配置する必要があります これに従っていることを前提にすると ソースの読み取りとソースへの書き込みは クローンの読み書きとは別のスピンドルになります したがって クローンがソースのパフォーマンスに影響するのは クローンを同期するときだけです この影響を解消するために クローンを再同期する時間帯を戦略的に選んで ソース ボリュームのパフォーマンスに対する影響を最小化することが望まれます さらに すでに説明したように 同期レートは環境に最適になるように選ぶことができます これは 基本的には ストレージ システムのリソースをより多く割り当ててコピーを短時間で完了させるか コピー プロセスをバックグラウンドで実行してコピー時間を長くするかの選択です EMC CLARiX SnapView クローン詳細レビュー 27

29 図 14 は CX3-80 でクローンの初期同期を行う際に 同期レートとして低 中 高を選んだ場合のサーバ I/O の効果を比較しています このテストでは 36 組のソースとクローンのペアを SP 間で均等に配置しました OLTP シミュレータが使用され 条件は中および高ユーザ負荷 21 件の読み取りと 9 件の書き込みから構成されるトランザクション トランザクション ログへの 1 件の書き込みでした Medium Workload Heavy Workload Transaction Response Time (ms) Baseline Low Initial Medium Initial High Initial 14: 初期同期における OLTP の平均レスポンス タイム : ファイバ チャネル アプリケーションのレスポンス タイムは クローンが高い同期レートで同期されると急激に増加する傾向があります 同期レートを低または中で使用した場合 OLTP 負荷への影響はほぼ無視できます 同期レートを高くすると ミラーされる書き込みキャッシュのリンクがいっぱいに近くなり SP CPU の使用率が 100% に近づくにつれて レスポンス タイムは急速に増加します また 同期レートが高い場合は システムへの負荷 ( ユーザ数を反映 ) が中から高に変わるとトランザクションのレスポンス タイムが急速に増加します 図 15 では 同じテスト パラメータを使用していますが パフォーマンスを TPM(1 分あたりトランザクション数 ) で評価することに慣れているユーザー向けに レスポンス タイムではなく TPM の値を示しています 図 EMC CLARiX SnapView クローン詳細レビュー 28

30 Medium Workload Heavy Workload Transactions per minute (TPM) Baseline Low Initial Medium Initial High Initial Clone Sync Rate 図 15: 初期同期における OLTP の TPM( トランザクション数 / 分 ): ファイバ チャネル 予想どおり 図 15 で示したトレンドは図 14 で示したものと整合性があります ベースラインと比較すると 同期レートが低い場合は TPM(1 分あたりトランザクション数 ) に与える影響はほぼ無視できます 同様に ファイバ チャネル クローンで同期レートが高くなると ソースでのパフォーマンスの影響は増大します ただし FLARE リリース 26 における変更によって SP CPU 使用率が大幅に低下したため 同期レートが高い場合の TPM 値は FLARE リリース 24 の 1.5 倍に増えました この情報を考慮して 維持する必要があるアプリケーション パフォーマンスを満たす同期レートおよび 1 日のうちで同期を実行する時間帯を選択してください すべてのアプリケーションのパフォーマンスを常に最大に保つ必要がある場合は 最も作業の少ない時間帯を初期同期実行のために選択し 同期レートはデフォルトの中ではなく低を選びます クローン再同期およびリバース同期がサーバに与える影響 ( 他のクローン操作との比較考察 ) クローンが以下の状態のときに クローンが受けるパフォーマンスの影響を考慮することが重要です ベースライン ( 定義されたクローンがない ) 切り離し済み ( 同期またはミラーされる書き込みが発生しない ) 同期中 ( クローンがソースから更新される ) リバース同期中 ( ソースがクローンによってリストアされる ) 同期済み ( 同期が完了し サーバからソースへの書き込みはクローンにミラーリングされる ) クローンによるメリットの 1 つは クローンが切り離されるとソースのパフォーマンスに対して認識可能な影響はなくなるということです つまり クローンはバックアップ操作や読み取りまたは書き込み集中型の任意のアクティビティに使用でき その際ソース LUN は影響を受けませ EMC CLARiX SnapView クローン詳細レビュー 29

31 ん SnapView スナップと SnapView クローンのどちらを導入するかを決定する際は この点が重要な考慮事項です 切り離された状態のクローンは ソースのパフォーマンスに対して認識可能な影響を与えないため 切り離された状態はベースライン状態とほぼ同じであり 次の 2 つのグラフでは示されていません 図 16 および図 17 は クローンが前述の状態のどちらである場合についても結果を示しています テスト パラメータは 図 14 および図 15 で示したものと同じであり それぞれの同期レートは高に設定されていました Medium Workload Heavy Workload Transaction Response Time (ms) Baselin Fracture In Re-sync Reverse Sync 図 16: 高同期レートにおけるさまざまな状態でのOLTPレスポンス タイム : ファイバ チャネル 図 16 は 同期されたクローン または再同期されたクローンが高同期レートの条件下で 本番サーバにレスポンス タイムの点で与える可能性がある効果を示しています 図 17 は これと同じ情報を TPM で表したものです EMC CLARiX SnapView クローン詳細レビュー 30

32 Medium Workload Heavy Workload Transactions per minute (TPM) Baseline Fractured Insync Resync Reverse Sync Clone State 図 17: 高同期レートにおけるさまざまな状態での OLTP の TPM( トランザクション / 分 ): ファイバ チャネル 予想どおり どちらの図からも 高同期レートでの再同期操作がサーバ処理に最も大きな影響を与えることが示されています いったんクローンが同期された ( 同期状態になった ) 後 切り離しされるまでの間は サーバ I/O に軽微な影響を与える可能性があります この影響は サーバ書き込みがクローンにミラーリングされ 各 I/O について実質的に 2 つの書き込みが実行されてから ACK が返されることによるものです クローンが同期したら直ちに切り離しする必要があるのは このことが理由です これはパフォーマンスにとって有利であるだけでなく ポイント イン タイム コピーを確実に保存することにもなり ソースでのハードウェアまたは論理エラーからデータを保護することができます クローンを使用する際のパフォーマンスに関して 主な考慮事項は以下のとおりです 切り離されたクローンがサーバ I/O に与える影響は ほぼゼロである 同期レートを調整して 同期操作時のサーバへの影響を最小限に抑えることができる ファイバ チャネル ドライブのクローンとして ATA ドライブを使用することは推奨されない 同期されたクローンは サーバへの影響を最小限に抑えるため また データの有効なポイント イン タイム コピーを提供するために 切り離しする必要がある これらの考慮事項を前提にした上で ソース データへの影響を最小限に抑えるために 以下を行うことが推奨されます クローンの同期は できるだけ低負荷時に行う クローンはソース LUN と同じ種類のドライブに置く o ソース LUN がファイバ チャネル ドライブに置かれる場合は クローンもそれに合わせる必要がある EMC CLARiX SnapView クローン詳細レビュー 31

33 o ソース LUN が ATA ドライブに置かれる場合は クローン LUN も ATA ドライブに置いてかまわない これらは絶対的な要件ではなく クローンを扱う際にソース LUN の最適なパフォーマンスを確保するためのベスト プラクティスです 結論 SnapView クローンを使用すると すべてのデータを含む LUN のポイント イン タイム コピーを作成して 本番処理に影響を与えることなく並行操作に利用できます さらに SnapView クローンではソースからクローンに またはその逆方向に変更をコピーする機能があるため データの保護と保存に関して高い柔軟性が得られます SnapView によって実現されたデータのインスタント スナップショット および MirrorView によって実現されたデータのリモート複製と組み合わされた SnapView クローンは ビジネス継続性ソリューションの堅牢な EMC ソフトウェア製品ファミリの完成度を高める存在です 関連資料 以下のタイトルは 特に明記しない限り Powerlinkから入手できます Navisphere Manager Help ホワイトペーパー CLARiiON SnapView Snapshots and Snap Sessions Knowledgebook ホワイトペーパー EMC CLARiiON Reserved LUN Pool Configuration Considerations EMC CLARiiON Best Practices for Fibre Channel Storage: CLARiiON Release 26 Firmware Update - Best Practices Planning :CLARiX のパフォーマンスを最適化するための一般的なガイドラインおよびベスト プラクティスを説明します EMC.comのE-Lab Navigator EMC CLARiX SnapView クローン詳細レビュー 32

34 付録 : クローンの制限 クローンおよびクローン グループの数は モデルと FLARE のリリースによって異なります 表 4 および表 5 に この数をまとめます ストレージ システムごとのクローンの総数も示してあります この表で イメージとは SnapView クローンとして使用される LUN のことです ソース LUN は サポートされている総イメージ数には含まれていません 表 4: リリース 24 および 26 におけるストレージ システム モデルあたりのクローン数の制限 プラットフォーム CX3-80 CX3-40 CX3-20 CX3-10 クローン ソース ストレージ システムあたり [1] クローン イメージ ストレージ システムあたり [2] ソースあたりクローン数最大 8 1. クローン ソースは 総イメージ数に関してクローンでもミラーでもカウントされなくなりました 2. リリース 24 から SnapView クローンの制限と MirrorView/Synchronous LUN の制限は別々に扱われるようになりました これらの制限は SnapView によって適用されます つまり CX3-40 では合計で 512 のクローン イメージを使用できますが ストレージ システムの 256 ずつのクローン ソースにグループあたり 8 つのクローンを割り当てることは 総クローン イメージ数が 2,000 を超えるため不可能です 同様に CX3-20 および CX3-80 上のクローンは すべてがクローンの最大数を持つことはできません この場合も ストレージ システムあたりの制限が先に適用されるためです これらの制限を考慮すると 各ソース LUN には平均して 2 つのクローンを構成できることになります 各クローン グループには 1 つのソース LUN が存在するため クローン グループの数は基本的に クローンを持つことができるソース LUN の数と同じです 表 5: リリース 19 および 22 におけるストレージ システム モデルあたりのクローン数の制限 EMC CLARiX SnapView クローン詳細レビュー 33

35 プラットフォーム CX3-80 CX3-40 CX700 CX3-20 CX500 CX300 クローン ソース ストレージ システムあたり [1] クローン イメージ ストレージ システムあたり [2] ソースあたりクローン数最大 8 1. クローン ソースは 総イメージ数に関してクローンでもミラーでもカウントされなくなりました 2. SnapView クローンの制限と MirrorView/Synchronous LUN の制限はまとめて扱われます リリース 24 より前は ストレージ システムあたりのクローンの総数は MirrorView/S とまとめられていたため 合計で以下の値でした CX3-80( リリース 22) または CX700( リリース 19) で 200 イメージ ( ミラーおよびクローン ) CX3-40 または CX500 で 100 イメージ CX3-20 で 100 この総数には 両方の本番 LUN と MirrorView のためにミラーされた LUN が含まれます ただし FLARE リリース 19 からは クローン LUN だけが含まれるようになりました ( そのソースは含まず ) クローン数の最新の制限は EMC CLARiiON Open Systems Configuration Guide に記載されています サポートされている CLARiX モデルおよびその制限の最新リストについては このガイドを参照してください EMC CLARiX SnapView クローン詳細レビュー 34