Comments
Description
Transcript
EMC CLARiXリザーブドLUNプールの構成に関する考慮事項
EMC CLARiX リザーブド LUN プールの構成に 関する考慮事項 ベスト・プラクティスのプランニング US ホワイトペーパー翻訳版 要約 このホワイト・ペーパーでは、グローバル・リザーブドLUNプールのサイズ設定と構成について、お よびCLARiX® CX3 およびCXシリーズのストレージ・システムでのSnapView™、SAN Copy™、 MirrorView™/Asynchronousとの組み合わせについて、ガイドラインと推奨事項を示します。 2008 年 9 月 Copyright © 2006, 2007 EMC Corporation.不許複製 EMC Corporation は、この資料に記載される情報が、発効日時点で正確であるとみなしています。 この情報は、予告なく変更されることがあります。 この資料に記載される情報は、「現状有姿」の条件で提供されています。EMC Corporation は、 この資料に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、 商品性や特定の目的に対する適応性に対する黙示の保証はいたしません。 この資料に記載される、いかなる EMC ソフトウェアの使用、複製、頒布も、当該ソフトウェア・ ライセンスが必要です。 最新の EMC 製品名については、EMC.com で EMC Corporation の商標を参照してください。 他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または登録商標です。 パーツ番号 H1585.1-J EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 2 目次 エグゼクティブ・サマリー................................................................................... 4 概要....................................................................................................................... 4 対象読者....................................................................................................................................... 4 リザーブドLUNとSnapView..................................................................................... 4 SnapViewセッション追跡 ............................................................................................................. 5 SnapViewにおけるリザーブドLUNのサイズ設定に関する考慮事項 .............................................. 6 リザーブドLUNにおけるSnapViewの使用のまとめ ....................................................................... 9 リザーブドLUNとSAN Copy..................................................................................... 9 SAN CopyとSnapViewの統合........................................................................................................ 10 SAN CopyにおけるリザーブドLUNのサイズ設定に関する考慮事項 ............................................ 11 リザーブドLUNにおけるSAN Copyインクリメンタルの使用のまとめ ........................................ 13 リザーブドLUNとMirrorView/Asynchronous........................................................ 13 MirrorView/AとSnapViewの統合................................................................................................. 13 MirrorView/AにおけるリザーブドLUNのサイズ設定に関する考慮事項..................................... 14 リザーブドLUNにおけるMirrorView/Aの使用のまとめ .............................................................. 15 リザーブドLUNに関するパフォーマンスの考慮事項 ........................................... 16 Copy on First WriteアクティビティとソースI/Oへの影響 ..................................................... 16 ATAドライブに関する考慮事項 .................................................................................................. 17 リザーブドLUNに関する推奨事項............................................................................................... 18 リザーブドLUNプールの構成 ............................................................................... 20 リザーブドLUNのサイズ設定戦略 ........................................................................ 22 リザーブドLUNの均一サイズ設定............................................................................................... 22 段階的構成 ................................................................................................................................. 24 結論..................................................................................................................... 25 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 3 エグゼクティブ・サマリー グローバル・リザーブド LUN プールは、SnapView™セッション、SAN Copy™インクリメンタル・ セッション、および MirrorView™/Asynchronous ミラーで使用されます。リザーブド LUN の総数 にはストレージ・システム固有の制限があるため、SnapView、SAN Copy、 MirrorView/Asynchronous の機能を最大限に引き出すには、適切なサイズとレイアウトを設定す ることが役立ちます。リザーブド LUN の構成に関する一般的なガイドラインは、コピー操作の変 更の予想される頻度と長さに依存します。パフォーマンスに関する考慮事項も、リザーブド LUN の適切な構成に影響します。 概要 リザーブドLUNは、SnapView™スナップショット・セッション、SAN Copy™インクリメンタル・ セッション、およびMirrorView™/Asynchronous（MirrorView/Aとも表記）ミラーの必須コンポ ーネントです。これらの製品は、それぞれが一貫性のあるポイント・イン・タイムのデータ参照 を保持します。リザーブドLUNの役割は、このポイント・イン・タイムの参照に対するリポジト リとなることです。 1 リザーブド LUN は、最初のセッションが始まるか、そのソース LUN に対して非同期ミラーが作成 されると、ソース LUN に割り当てられます。必要に応じて、追加のリザーブド LUN が割り当てら れます。割り当ては動的で、リザーブド LUN の使用状況は Event Monitor から追跡できます。あ るソース LUN に関して、すべてのセッションが終了するかミラーが破棄されると、割り当てられ ていたリザーブド LUN は、別のソース LUN に割り当てることができるようになります。 ストレージ管理者は、LUNをリザーブドLUNプールに割り当てることにより、どのLUNをリザーブ ドLUNとして使用するかを決定します。 2 一般的なガイドラインとしては、リザーブドLUNはソー スLUNの 20%のサイズにする必要があります。リザーブドLUNのサイズを設定する際に考慮する必 要がある要素は、多数存在します。それらの要素の中でも特に重要なものは、セッションの長さ と、そのセッション中に変更されるソース・データの量です。この後の説明では、リザーブド LUNのサイズ設定と構成に関するベスト・プラクティスを決定するのに役立つガイドラインを示 します。 対象読者 このホワイト・ペーパーが想定している読者は、お客様とやり取りを行う EMC フィールド・コミ ュニケーションのメンバーで、このホワイト・ペーパーで示されているリザーブド LUN の考慮事 項について理解する必要がある人たちです。また、お客様にも、リザーブド LUN の最適なサイズ と構成について直接的な理解を得るために読むことをお勧めします。 リザーブド LUN と SnapView SnapViewスナップショット・セッションでは、SnapViewのポインタ・アンド・コピー・ベースの 設計をサポートするためにリザーブドLUNが使用されます。SnapViewセッションが開始されると、 ソースLUN上のデータのチャンク（ブロックのグループ）のうち、セッション開始後に上書きさ 各製品の詳細については、以下のホワイト・ペーパーを参照してください。CLARiX SnapView 「Snapshots and Snap Sessions Knowledgebook - A Detailed Review, EMC CLARiiON SAN Copy - A Detailed Review, and MirrorView Knowledgebook」 1 2 SnapViewの初期リビジョンでは、リザーブドLUNのことをキャッシュLUNと呼んでいました。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 4 れたものがチャンク・マップに記録されます。ソースLUNに対する書き込みリクエストが発生す ると、プライベートLUN上の不揮発性領域であるリザーブドLUNにデータ・チャンクがコピーされ ます。このコピーが行われたら、ソースLUNのデータを上書きする書き込みリクエストを完了で きます。各チャンクがリザーブドLUNに正常にコピーされたら、それらのチャンクの新しい場所 を反映するようにチャンク・マップが更新されます。Copy on First Writeと呼ばれるこのプロ セスは、セッション開始後最初の書き込みリクエストがソースLUNのいずれかのチャンクに対し て行われるときにのみ発生します。オリジナル・データがリザーブドLUNに正常にコピーされた ら、データのオリジナルの内容（ビュー）を失うことなく、いくつでも書き込みを行うことがで きます。 オリジナルのチャンクはソースLUNまたはリザーブドLUNのどちらかに存在するので、ポイント・ イン・タイム・ビューはチャンクを指すポインタによって維持されます。このポイント・イン・ タイム・ビューをセカンダリ・サーバに認識させるために、ユーザーはスナップショットをアク ティベートすることができ、これにより、スナップショットはデータへのポインタを読み込むの で、仮想LUNとしてみなすことができます。図 1 に、ソースLUN、リザーブドLUN、およびスナッ プショットの関係を示します。 Source A B’ C D’ Reserved LUN B D A Snapshot B C D 図1：変更されていないソース・データとリザーブド LUN に保存されているデータから構成され る SnapView スナップショット 図 1 で、セッション開始後、ソースLUNへの書き込みはB'のようにダッシュ付きの文字で表され ます。この場合、オリジナルのチャンクBはリザーブドLUNにコピー済みです。 SnapView セッション追跡 SnapView は、ソース LUN を 64 KB のチャンクに分割します。そのため、あるサーバ・アプリケ ーションがソースに 4 KB の書き込みを行うと、それがセッション開始後このデータ・チャンク に対する最初の更新であれば、対応する 64 KB のチャンクがリザーブド LUN にコピーされます。 すでに説明したように、SnapView には、リザーブド LUN にコピーされたチャンクのチャンク・ マップが保持されています。チャンク・マップのエントリは、Copy on First Write 手順の中で リザーブド LUN にコピーされます。 このチャンク・マップはディスクに保存されてパーシステント・セッションが実現されるため、 SP のトレスパス、再起動、障害の際にもデータを保つことができます。リリース 24 から、すべ ての SnapView セッションはデフォルトでパーシステントになります。これらのチャンク・マッ プのエントリを格納するために必要な領域は、通常、ソース LUN のサイズの 0.02%ほどであり、 無視できます。したがって、セッションをパーシステントとして追加しても、サイズの追加はほ とんど不要です。その一方で、SP が使用できないときやシステムが再起動中であっても利用で きるという大きなメリットがあります。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 5 SnapView におけるリザーブド LUN のサイズ設定に関する考慮事項 SnapView セッション向けのリザーブド LUN の適切なサイズを設定する際は、以下を考慮する必 要があります。 SnapView のソース書き込みアクティビティ 図 1 に示したように、リザーブド LUN には、ソース LUN での Copy on First Write アクティビテ ィに対応可能な大きさが必要です。したがって、リザーブド LUN プールに割り当てるリザーブド LUN のサイズを設定する際は、ソース LUN の変更頻度を考慮する必要があります。この変更頻度 は、当然、環境によって変わるため、各ユーザーーがそれぞれの環境に応じて判断しなければな りません。一般的な経験則では、ソース LUN のサイズの 10%から 20%のリザーブド LUN があれば、 読み取りと書き込みの比率が 2：1 程度の OLTP 環境では十分です。これよりも変更頻度の高い環 境では、リザーブド LUN を大きくすることをお勧めします。 データ書き込みのパターンを考慮することが重要です。データの参照のローカル性が高い場合、 つまり、1 つのセッション中に同じデータ領域が何回も変更される傾向がある場合は、Copy on First Write設計によって 2 回目以降の書き込みではリザーブドLUNに再度書き込む必要がないこ とが有利に働きます。また、データがシーケンシャルに書き込まれる場合は、64 KB単位の追跡 が複数の連続した書き込みに対応するため、サーバ上で実際に変更されるデータ量と、ストレー ジ・システムがコピーする必要のあるデータ量とのずれが小さくなります。一方、書き込みが非 常に小さく（たとえば 4 KB程度）、きわめてランダムな場合、64 KB単位の追跡により、リザー ブドLUNに書き込まれるデータは、実際にサーバで変更されるデータよりも大幅に多くなると考 えられます。参照のローカル性が低い環境や、ランダムな書き込みが発生する環境では、リザー ブドLUNを大きくする必要があります。 SnapView セッションの長さ リザーブド LUN のサイズを設定する際は、SnapView セッション中のソース・ボリュームへの書 き込みアクティビティについて考慮するだけでなく、セッションの長さを考慮することも重要で す。スナップ・セッションはほぼ瞬時に作成できるため、ユーザーによっては必要に応じてスナ ップ・セッションを作成し、短時間のタスク（バックアップなど）に使用することもあります。 その場合、タスクが完了すると、そのスナップ・セッションは停止します。しかし、他の環境で は、スナップ・セッションをそれよりも長い時間、通常は 1 日やそれ以上の時間保持することが 望まれます。その場合はセッション時間のうちのかなりの間、Copy on First Write 操作が継続 することが考えられ、リザーブド LUN も追加の領域が必要です。 セッション中に書き込まれるデータの量を判断するには、図 2 に示すような統計（セッションの プロパティからアクセス）を参照します。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 6 図2：SnapView セッションでの Copy on First Write データ Navisphere® CLIでも、次のコマンドを入力することによってこの情報を表示できます。 naviseccli -h <SP> snapview -listsessions -name <名前> -totalwrites 図 2 に示したように、Copy on First Write が必要な総書き込みは、Writes from Reserved LUN Pool パラメータで確認できます。また、Writes from Snapshot Source LUN ではソース LUN から の書き込み数が表示されます。これは、ソース LUN からの書き込みのうち、Copy on First Write 操作を引き起こさなかったものです。この 2 つのパラメータの合計が Total writes in session です。 Writes Larger than Reserved LUN Pool Entry Size パラメータは、SnapView のチャンク・サイズ （64 KB）を超える I/O を示します。 SnapView 書き込みアクティビティ スナップショットは、セカンダリ・サーバに認識されれば読み取りおよび書き込みが可能です。 図 3 に示すように、スナップショットに対するすべての書き込みは、リザーブド LUN にも格納さ れます。ソース LUN への書き込みと同様に、スナップショットの書き込みデータのチャンク・サ イズは 64 KB です。 Source LUN A B’ C D’ Reserved LUN B B” C” D Snapshot A B” C” D 図3：リザーブド LUN に保存される SnapView スナップショット書き込み EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 7 図 3 は、スナップショット書き込みがリザーブドLUNに格納されるとき、オリジナル・データへ の追加として（代わりにではなく）格納されることを示しています。この例では、BとB''の両方 がリザーブドLUNに格納されます。つまり、オリジナル・データ（B）はソースLUN上で変更され ており、スナップショット（B''）上でも変更されています。スナップショットをデアクティベ ートすると、スナップショット書き込み（B''）は削除されますが、オリジナルのソース・デー タ（B）はリザーブドLUNの中で保持されます。これにより、セッションのオリジナルのポイン ト・イン・タイム参照が保存されるため、同じセッションでスナップショットをデアクティベー トしてから再度アクティベートするだけで、スナップショットへの書き込みを破棄することがで きます。セッションが停止すると、オリジナルのポイント・イン・タイム・データ（B）は削除 され、他のセッションがリザーブドLUNを使用していなければ、LUNはリザーブドLUNプールに返 されます。 ただし、オリジナル・データ（C）がソースLUN上で変更されていなくても、スナップショット上 でC''に変更されると、スナップショット書き込み（C''）はリザーブドLUNプールに書き込まれ ます。この場合も、セッションのオリジナルのポイント・イン・タイム参照は、同じセッション でスナップショットをデアクティベートしてから再度アクティベートするだけで保存されるため、 この場合はスナップショット書き込み（C''）が削除されます。 スナップショット書き込みは、そのチャンクに対応するオリジナル・データとともにリザーブド LUN に格納されるため、リザーブド LUN のサイズを設定する際は、スナップショットへの予期さ れる書き込みアクティビティを考慮する必要があります。たとえば、スナップショット書き込み がないリザーブド LUN の一般的なガイドラインは 10%から 20%なので、スナップショットのすべ てのブロックに書き込みがあると、リザーブド LUN はそれに対応するために 2 倍の領域を必要と します。書き込みが予定されるスナップショットのそれぞれについて、一般的なガイドラインの 2 倍を想定することをお勧めします。つまり、単一のスナップショットを用意する場合は、ソー スへの Copy on First Write アクティビティに対してソース LUN の 10%から 20%を見込み、スナ ップショットへの書き込みに対応するために 10%から 20%を加えて、合計でソース LUN のサイズ の 20%から 40%になります。 コンカレント・セッション SnapViewでは、1 つのサーバで最大で 8 つのセッションを実行できます。たとえば、図 4 に示す ように、曜日によって別のセッションを実行したい場合が考えられます。または、毎時間ごとに 別のセッションを開始して、8 時間後には再起動してt-1 からt-8 までのセッションを回転させ ていくことも考えられます。SnapViewのロールバック 3 機能を使用する場合は、複数のリカバ リ・ポイントを用意して、目的のポイント・イン・タイムに復旧できる可能性を高めることも望 まれます。 3 SnapViewのロールバック機能では、データ破損などのソフトウェア・エラーの際に、リザーブドLUNに保存されてい るオリジナル・データをソースLUNにコピーすることにより、データを復旧できます。詳細については、ホワイト・ペーパ ー「CLARiiON SnapView Snapshots and Snap Sessions Knowledgebook」を参照してください。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 8 Source LUN Monday View Tuesday View Backup Server ... Production Server Friday View Tuesday Session Selected for Backup 図4：コンカレント SnapView セッション 各セッションが開始されてから、ソース LUN の変更頻度に応じて、複数のセッションに対応する ために追加のリザーブド LUN 領域が必要になることがあります。図 4 に示すように、月曜のセッ ション開始から火曜のセッション開始まで（および同様にして金曜まで）のソース LUN の変更が ごくわずかならば、追加のリザーブド LUN 領域もそれに比例して小さくします。一方、月曜から 火曜まで（および同様にして金曜まで）の間にソース LUN のデータの大部分またはすべてが変更 される場合は、追加のリザーブド LUN 領域もそれに比例して非常に大きくする必要があります。 極端な場合、8 つのセッションが存在し、その Copy on First Write アクティビティが同じチャ ンク・セットに対して行われていると、つまり、同じチャンクを各セッションの新しいデータで 再書き込みする場合は、すでに説明した 10%から 20%というガイドラインを 8 倍に増やす必要が あることも考えられます。これは、8 つのセッションの Copy on First Write データがすべて完 全に異なる場合、80%から 160%というガイドラインを意味します。 リザーブド LUN における SnapView の使用のまとめ ここまで説明したガイドラインをまとめると、リザーブド LUN をどのように SnapView セッショ ンに割り当てるかを決定する際は、以下について考慮する必要があります。 • ソース LUN の合計サイズ • ソース LUN データの変更頻度 • SnapView セッションの予想される長さ • スナップショットの予想される長さと書き込み頻度 • ソース LUN とスナップショット書き込みのローカル性 • コンカレント・セッションの予想される数 • ソース LUN のサイズの変動範囲 リザーブド LUN と SAN Copy SAN Copyは、インクリメンタル・セッション機能をSAN Copyで使用できるようにするために、セ ッション、スナップショット、リザーブドLUN 4 といったSnapViewコンポーネントを使用します。 4 ストレージ・システムでSnapViewが有効なとき、SAN Copyが使用するSnapViewコンポーネントをユーザーは認 識できますが、使用することはできません。これらは、Navisphere UIでリザーブド・オブジェクトとして、つまり、 Navisphere内の対応するSnapViewノードの下に、リザーブド・スナップショットおよびリザーブド・セッションとして表 示されます。SnapViewが有効になっていないと、コンポーネントは表示されません。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 9 SnapViewとSAN Copyの統合により、変更追跡のメカニズムと、更新時に使用する一貫性のあるポ イント・イン・タイム・ビューを維持するメカニズムが実現します。 SAN Copy と SnapView の統合 SAN Copyインクリメンタル・セッションが作成されると、そのインクリメンタル・セッション内 での変更を追跡するためのSnapViewセッションが開始されます。すでに説明したように、リザー ブドLUNが割り当てられるのは、ソースLUNに対してSAN Copyセッションが初めて作成されるとき です。SnapViewのチャンク・マップと同様に、SAN Copyもビットマップを使用して更新と更新の 間の変更を追跡します。このビットマップは、追跡ビットマップおよび転送ビットマップと呼ば れます。名前から分かるように、1 つのビットマップは更新と更新の間の追跡を行い、もう 1 つ のビットマップは更新時のデータ転送先を示します。パーシステント・セッションのためにリザ ーブドLUNに格納されるSnapViewのメモリ・マップと同様に、この差分マップもリザーブドLUN内 に格納され、ソースLUNサイズの約 0.02%を消費する同じ構造に保存されます。 SAN Copyインクリメンタル・セッションによるリザーブドLUN領域の用途として、さらに重要な ものは、SAN Copyのインクリメンタル更新におけるCopy on First Writeアクティビティです。 SAN Copyインクリメンタル更新では、セッションに対してスナップショットがアクティベートさ れ、このスナップショットがデスティネーションLUNに対するデータ転送の一貫したソースにな ります。これにより、SAN Copyのソースはオンライン状態を保ったまま、SAN Copyインクリメン タル更新の間に入ってくる読み書きを受け入れることができます。書き込みが、転送するように マークされていてまだ転送先にコピーされていないSAN CopyソースLUNのチャンクに対して入っ てくると、Copy on First Writeオペレーションが発生します。SnapViewセッションの場合と同 様に、このアクションによってオリジナルのデータ・チャンクがリザーブドLUNに格納され、対 応するポインタがそのチャンクにリダイレクトします。これにより、スナップショットのビュー は、ソースLUNの更新操作が開始されたときと一貫性が維持されます。 5 Source A B’ C D’ Delta Set B’ D’ Destination A B C D 図5：SAN Copy インクリメンタル・セッションにおける差分セット 更新が完了すると、Copy on First Write アクティビティは終了し、スナップショットはデアク ティベートされ破棄されます。ただし、セッションは差分マップに関連づけられているため、継 続します。 5 ユーザーが明示的なマークを発行すると、直ちにCopy on First Writeアクティビティが開始されます。それに続い てコピーが開始されて完了するか、ユーザーがアンマークを発行しない限り、このCopy on First Writeは終了しま せん。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 10 SAN Copy におけるリザーブド LUN のサイズ設定に関する考慮事項 SAN Copy ソース LUN に割り当てられた初期状態のリザーブド LUN は、最初に SAN Copy セッショ ンを作成するために、少なくとも差分マップを格納できる大きさが必要です。セッションが正常 に作成され、更新が始まったら、必要に応じて追加のリザーブド LUN が割り当てられます。リザ ーブド LUN を追加できない場合は、関連する SnapView セッションまたはポイント・イン・タイ ム・コピーが停止され、それによって SAN Copy セッションがアンマークされます。この時点で、 リザーブド LUN に追加の領域を割り当ててから、SAN Copy セッションを開始する必要がありま す。このセッションは、新しいポイント・イン・タイム・コピーを作成し、SAN Copy セッショ ンをマークします。デスティネーション LUN へのフル・コピーは不要です。ただし、リザーブド LUN に対する割り当てが不足するのを避けるために、SAN Copy が使用するリザーブド LUN の適切 なサイズを設定するための参考として、以下の考慮事項を示します。 初期同期で行われる SAN Copy ソースへの書き込みアクティビティ 初期同期はソースLUN全体の内容をデスティネーションLUNにコピーするため、通常はインクリメ ンタル更新よりも時間がかかります。また、そのため大半のCopy on First Writeアクティビテ ィは初期同期時に発生します。SAN Copyセッションを開始すると、そのセッションによって SnapViewセッションが開始されます。このSnapViewセッションは、SAN Copyセッションが終わる まで実行されます。SAN Copyセッションに関連づけられ、割り当てられたリザーブドLUNは、そ のSAN Copyセッションが破棄されるまで解放されません。ほとんどのCopy on First Writeアク ティビティは初期同期時に発生するので、初期同期時のCopy on First Writeアクティビティの ために必要な追加のリザーブドLUNは、SAN Copyセッションが破棄されるまで維持されます。 この初期同期時の Copy on First Write アクティビティを避けるには、-nomark オプションを 使用して、初期コピーをコンシステント・スナップショットからではなくソース LUN から読み取 るようにします。この結果、実際のデータ転送速度が大きく向上します。ただし、その代わりに、 コピー中に入ってくる I/O によってデスティネーションにおけるデータの状態に不整合が発生す る可能性があります。そのため、-nomark を指定した初期コピーは、その後のマークされたイ ンクリメンタル・セッションによって、デスティネーションを整合性のある状態にする必要があ ります。 -nomark オプションは高度な機能であり、Navisphere CLI でのみ使用できます。 可能であれば、初期同期は、夜間や週末などの低負荷時に実行するようにスケジュールします。 これにより、ソース LUN に対するアクティビティがわずか、または存在しない間にコピーが行わ れ、更新時の Copy on First Write アクティビティを最小限に抑えたり、または完全になくすこ とができます。 インクリメンタル更新で行われる SAN Copy ソースへの書き込みアクティビティ SAN Copy インクリメンタル・セッション向けに適したリザーブド LUN のサイズを設定する際に 注意する必要があるのは、SAN Copy によって使用されるすべてのリザーブド LUN（差分マップの ために必要とされる無視可能な領域を除く）に本質的に影響するのは、SAN Copy インクリメン タル更新中の Copy on First Write アクティビティであるということです。SnapView セッショ ンと同様に、SAN Copy インクリメンタル更新で行われるソース LUN への書き込みアクティビテ ィ、具体的には変更頻度と書き込みのランダム性が Copy on First Write アクティビティを増や す要因であり、Copy on First Write データを保持するリザーブド LUN の必要サイズに影響しま す。ただし、SAN Copy の Copy on First Write アクティビティは、SnapView セッションとは異 なります。Copy on First Write オペレーションが実行される対象は、転送のマークが付けられ EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 11 ているチャンクのうち、ソース LUN に対して書き込みリクエストが発行された時点でまだコピー されていないチャンクです。 更新の際のソース LUN に対する書き込みアクティビティに加えて、このソース LUN に対して同時 に発生する関連アクティビティの内容を考慮することも重要です。SAN Copy インクリメンタ ル・セッションをサポートする SnapView セッションは、ソース LUN あたり 8 個という上限があ る SnapView セッションの一部としてカウントされます。したがって、これ以外に 7 個の SnapView セッション、7 個の SAN Copy インクリメンタル・セッション、またはその組み合わせ など、合計で 8 個のセッションを同時に持つことができます。すでに説明したように、異なる Copy on First Write アクティビティを持つ複数のセッションが 1 つのソース LUN に存在する場 合は、追加のリザーブド LUN 領域が必要です。 デスティネーション LUN に対する SAN Copy 更新の長さ 更新を完了するために必要な時間は、転送するデータの量と、選択された転送速度および帯域幅 に依存します。転送するデータの量を判断するには、図 6 に示すセッションを確認します。 図6：SAN Copy インクリメンタル・セッションで転送されるデータの追跡 Navisphere CLI でも、次のコマンドを入力することによってこの情報を表示できます。 naviseccli -h <SP> sancopy –info –counts 転送するデータを減らすには、更新間隔を短くして、転送回数を増やす代わりに転送時間を減ら します。一方、ソース・データの参照のローカル性が高い場合は、同じデータセットが複数の更 新で転送されるのを避けるために、更新間隔を長くする方が良いと考えられます。どちらの場合 も、ユーザーは、ソース LUN における変更頻度とその変更のローカル性、およびそれが転送する データ量に与える影響を理解する必要があります。これらの要因は、Copy on First Write アク ティビティをサポートする必要がある時間の長さに影響します。 また、転送に必要な時間の長さは、転送スロットル速度を上げたり転送速度を下げることによっ て変えることもできます。コピー・スロットルを増やすと、転送を短時間で完了させるためにス トレージ・プロセッサの CPU サイクルの消費が増え、コピー・スロットルを減らすと、ストレー ジ・プロセッサの CPU サイクルが解放されて他のタスクで使用できるようになり、転送は速度が 低下して長時間かかります。 最後に、サイト間の実際の帯域幅は、転送時間にとって重要な考慮事項です。SAN Copy では、 使用可能な帯域幅が使用されます。しかし、スロットルの設定と同様に、帯域幅の設定を下げる ことにより、SAN Copy が帯域幅の一部だけを使用できるようにすることができます。スロット ルの調整と同じように、この設定を使用すると、データ転送速度を制限して CPU リソースを節約 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 12 できます。データ転送速度を制限すると、データをデスティネーション LUN に転送するための時 間が長くなるので、Copy on First Write アクティビティが発生する時間も長くなります。 SAN Copyの使用と構成の詳細については、EMC.comおよびPowerlink（パスワードで保護されてい るEMCのお客様およびパートナー向けエクストラネット）にあるホワイト・ペーパー「 EMC CLARiiON SAN Copy - A Detailed Review」を参照してください。 リザーブド LUN における SAN Copy インクリメンタルの使用のまとめ SAN Copy インクリメンタル・セッションに対するリザーブド LUN の割り当てを決定するときは、 以下を考慮する必要があります。 • 「リザーブドLUNとSnapView」セクションで示されているSnapViewセッションのガイドライ ン • これまでに説明したさまざまな要因とパラメータに基づいて予想される、デスティネーショ ン LUN に対する SAN Copy 更新にかかる時間 SAN Copy 更新における Copy on First Write に対応するために必要な領域として、差分マップ によって増えるソース LUN のサイズは約 0.02%に過ぎません。したがって、リザーブド LUN のサ イズは、各 SAN Copy セッションにつきソース LUN のサイズの 10%から 20%にすれば（SnapView セッションの一般的な経験則）問題ありません。SnapView セッションを追加する場合は、リザ ーブド LUN 領域も追加する必要があります。 リザーブド LUN と MirrorView/Asynchronous SAN Copyインクリメンタル・セッションはSnapViewセッションの機能を利用します。 MirrorView/AミラーはSAN Copyの機能を利用するため、MirrorView/AもSnapViewを利用します。 6 SAN Copyインクリメンタル・セッションの場合と同様に、リザーブドLUNは更新時に追跡とCopy on First Writeを実現するために、MirrorView/Aプライマリ・イメージLUNに割り当てられます。 この機能に加えて、SnapViewがMirrorView/Aと統合されることで、更新時にMirrorView/Aセカン ダリ・イメージLUNが保護されます。つまり、非同期ミラーを作成するためには、リザーブドLUN をプライマリとセカンダリ両方のストレージ・システムに割り当てる必要があります。 MirrorView/A と SnapView の統合 「リザーブドLUNとSAN Copy」セクションで説明したSnapViewの統合に加えて、MirrorView/Aは 更新のたびにSnapViewを使用して、MirrorView/Aセカンダリ（リモート）イメージで保護スナッ プ・セッションを開始します（ゴールド・コピーとも言います）。これは、更新中にストレー ジ・システムとの接続が途切れた場合や、MirrorView/Aプライマリ・イメージLUNにエラーが発 生した場合にユーザーを保護するためのものです。この保護スナップ・セッションがない場合、 更新中に障害が発生すると、セカンダリ・ストレージ・システム上のデータが使用できなくなる ことが考えられ、プライマリ・ストレージ・システム上のデータも使用できなくなるおそれがあ ります。 6 ストレージ・システムでSnapViewとSAN Copyが有効なとき、MirrorView/Aが使用するSnapViewおよびSAN Copyコンポーネントをユーザーは認識できますが、使用することはできません。これらは、Navisphere UIでリザーブ ド・オブジェクトとして、つまり、Navisphere内の対応するSnapViewノードの下に、リザーブド・スナップショットおよび リザーブド・セッションとして表示されます。SnapViewとSAN Copyが有効になっていないと、コンポーネントは表示 されません。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 13 Source A B’ C D’ Delta Set B’ D’ Destination A B C D Gold Copy A B C D 図7：MirrorView/A 差分セットと保護スナップ・セッション セカンダリ・イメージに対する更新が途中で停止された場合、セカンダリ・イメージ上のデータ は更新が完了していないため、使用できなくなります。さらに、プライマリ・イメージにその後 の更新を適用できない場合は、どちらのイメージ上のデータも復旧させる手段がありません。し かし、保護スナップ・セッションを使用すると、セカンダリ・イメージをプロモートすることが できます。プロモートしたスナップ・セッションを使って、最後に成功した更新の時点までセカ ンダリ・イメージの内容をロールバックできます。 MirrorView プライマリ・イメージに割り当てられたリザーブド LUN が常に存在します。ただし、 リザーブド LUN がセカンダリ・イメージに割り当てられるのは、転送の間だけです。これは、リ ザーブド・スナップショット・セッションが転送のたびに明示的に開始および停止されるためで す。 MirrorView のプロモートが行われるときは、この関係が逆になります。つまり、セカンダリ・ イメージがプライマリになり、リザーブド LUN が新しいプライマリ・イメージに割り当てられま す。それまでのプライマリ（新しいセカンダリ）イメージには、更新中だけリザーブド LUN が割 り当てられます。 MirrorView/A におけるリザーブド LUN のサイズ設定に関する考慮事 項 MirrorView/A プライマリ・イメージに割り当てられた初期状態のリザーブド LUN は、最初に MirrorView/A ミラーを作成するために、少なくとも差分マップを格納できる大きさが必要です。 ミラーが正常に作成されたら、MirrorView/A セカンダリ LUN に割り当てられる最初のリザーブ ド LUN も同様に、少なくともプライマリ・イメージ LUN の 0.02%のサイズが必要です。 SAN Copy 更新の場合と同様に、MirrorView/A 同期が始まったら、必要に応じて追加のリザーブ ド LUN が割り当てられます。また、これも SAN Copy 更新と同じく、リザーブド LUN を追加でき ない場合は関連する SnapView セッションが停止され、それによって MirrorView/A ミラーは切り 離されます。このとき、追跡マップと転送マップは統合され、その SnapView セッションに関す るリザーブド LUN プールのデータは解放されます。この時点で、リザーブド LUN プールに追加の 領域を割り当て、MirrorView/A 更新を開始することが必要になります。追跡マップと転送マッ プの統合により、プライマリ・イメージとセカンダリ・イメージの間のデータの違いに関する情 報が維持されるため、完全な同期は不要です。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 14 ディスク領域の制約によってリザーブド LUN プールに追加のリザーブド LUN を割り当てることが できない場合は、現在よりも大きいリザーブド LUN を作成してプールに割り当てられるように、 MirrorView/A ミラーを破棄する必要があります。 このとき、セカンダリ・ストレージ・システムでは、必要に応じて追加のリザーブド LUN がセカ ンダリ・イメージに割り当てられます。セカンダリ・ストレージ・システムに対してリザーブド LUN を追加できない場合は、関連する SnapView セッションが停止され、それによってミラーは 切り離されます。この時点で、管理者は追加のリザーブド LUN を割り当て、同期を再開する必要 があります。 リザーブド LUN の割り当て不足を避けるには、以下の情報に基づいて、MirrorView/A の使用時 にプライマリおよびセカンダリ・イメージが消費するリザーブド LUN の適切なサイズを判断して ください。 コピー時における MirrorView/A プライマリ・イメージへの書き込みアクティビ ティ MirrorView/A プライマリ LUN のために必要なリザーブド LUN 領域に関しては、インクリメンタ ル SAN Copy セッションのために必要な領域の場合と同じガイドラインに従います。必要なリザ ーブド LUN 領域には、更新時の Copy on First Write アクティビティが影響します。Copy on First Write オペレーションには、更新時のソース LUN への書き込みアクティビティ（変更頻度 と書き込みのランダム性）が影響します。また、他の SnapView またはインクリメンタル SAN Copy セッションが存在すると、そのソース LUN について追加のリザーブド LUN 領域が必要にな ります。 セカンダリ・イメージに対する MirrorView/A 更新の長さ SAN Copyと同様に、MirrorView/A更新にかかる予想時間は、転送するデータの量と、選択された 転送速度および帯域幅に依存します。SAN Copyのスロットル設定と同様に、ユーザーは MirrorView/Aミラーの同期レートを選択できます。同期レートは、高、中、低から選択できます。 デフォルトは中です。同期レートを高くすると、データ転送は速くなり、プライマリ・イメージ に対してCopy on First Writeアクティビティが実行される時間は短縮されます。同期レートを 低くすると、データ転送は遅くなり、データ転送の時間は長くなって、Copy on First Writeが 発生する可能性は高まります。更新レートのガイドラインについては、EMC.comおよびPowerlink にあるホワイト・ペーパー「MirrorView Knowledgebook」を参照してください。 セカンダリ・イメージへの保護スナップ・セッション プライマリ・イメージ上のエラーで更新が失敗することがないと仮定した場合、ユーザーはリザ ーブド LUN のサイズを、1 回の更新でセカンダリ・イメージにコピーされるデータ量の予想に基 づいて設定できます。控えめな予想としては、更新が失敗（その後の更新は成功）した場合に備 えて、そのサイズを 2 倍します。極端な場合として、更新によって LUN のほぼ全体が変更される 可能性があるならば、LUN 上のすべての（またはほぼすべての）データ・チャンクに対する Copy on First Write オペレーションに対応するために必要な大きさとして、セカンダリ・イメージ LUN と同じサイズのリザーブド LUN を作成することも考えられます。 リザーブド LUN における MirrorView/A の使用のまとめ SAN Copy インクリメンタル・セッションに対するリザーブド LUN の割り当てを決定するときは、 以下を考慮する必要があります。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 15 • 「リザーブドLUNとSnapView」セクションで示されているSnapViewセッションのガイドライ ン • 「リザーブドLUNとSAN Copy」セクションで示されているSAN Copyセッションのガイドライ ン • 更新の際にセカンダリ・イメージにコピーされると予想されるデータ量 • セカンダリ・イメージに対する MirrorView/A 更新の予想される長さ 差分マップのための 0.02%、および MirrorView/A 更新時の Copy on First Write に対応するに は、MirrorView/A 用としてソース LUN の 10%から 20%（一般的な経験則）のサイズのリザーブド LUN が適切です。同じ LUN に対して追加の SnapView や SAN Copy インクリメンタル・セッション が実行されている場合は、そのための領域を追加する必要があります。 SAN Copy の場合と同様に、MirrorView/A プライマリ LUN に対するリザーブド LUN 領域が不足し、 追加のリザーブド LUN を割り当てることができない場合は、ミラーを破棄してから、それよりも 大きい 1 つまたは複数のリザーブド LUN を再作成して、ミラーに割り当てる必要があります。ミ ラーを破棄して再作成する場合は、完全な再同期が必要です。セカンダリ LUN の領域がなくなる と、更新は直ちに停止され、追加のリザーブド LUN 領域を割り当てられるようになると再開され ます。 リザーブド LUN に関するパフォーマンスの考慮事項 リザーブド LUN の適切なサイズについて考慮することに加えて、リザーブド LUN の適切な構成に ついて考慮することも重要です。リザーブド LUN を適切に構成するための参考として、パフォー マンスに関する以下の情報が提供されています。 Copy on First Write アクティビティとソース I/O への影響 スナップショットのポインタ・アンド・コピー設計は、ディスク領域を節約できる一方、一般的 にソース・ボリュームのパフォーマンスにも影響します。これは、ソース・ボリューム上で変更 されていないデータがアクセスされたとき、スナップショットの読み取りとソース・ボリューム の読み取りで同じスピンドルがアクセスされることが理由の一部です。さらに、ソースへの書き 込み要求によってオリジナル・データからリザーブド LUN へのコピーが開始されると、CPU はコ ピー操作を実行しなければならないため、ソース LUN への I/O を扱うための CPU 処理サイクルが 少なくなります。 それよりも大きな要因として考えられるのは、リザーブドLUNプールのディスクそのものに対す る負荷です。COFW（Copy on First Write）アクティビティでは、データをリザーブドLUNプール から読み取り、かつプールに書き込む必要があります。リザーブドLUNプール・ディスクが過負 荷になると、COFWオペレーションによる遅延が大きくなり、COFWの元になったホスト書き込みに 対する応答時間が長くなります。そのため、容量に加えて十分なディスク本数を持つLUNをリザ ーブドLUNプールにプロビジョニングするように注意する必要があります。これは、リザーブド LUNプール・ディスクそのものへの負荷がパフォーマンスに大きく影響するためです。 参照のローカル性が高いデータセットでは、Copy on First Write アクティビティは比較的短時 間で収束します。たとえば、あるデータベースで、更新のほとんどがいくつかのテーブルに集中 してる場合、最初にそれらのテーブルが更新されると、それ以上の Copy on First Write は実行 されません。図 8 に、この様子を示します。最初の Copy on First Write オペレーションによっ て I/O 応答時間が一時的に大きく上昇しており（グラフで応答時間が長くなっています）、ソー ス LUN のパフォーマンスに影響を与えています。しかし、一定の時間が経過すると、Copy on First Write アクティビティは目立って少なくなり、ソース LUN 応答時間はグラフの左端に示さ れたほぼ元の（セッション開始前の）水準に戻っています。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 16 OLTP Transaction Response Time Eight Sessions Response Time Duration 図8：SnapView セッションのリカバリ期間 ユーザーがスナップ・セッションをバックアップなど他の目的に使用している場合は、それによ って追加のスピンドル競合が発生します。リザーブド LUN プールのスピンドルはスナップショッ トの読み書きをのために使用されており、同時に Copy on First Write オペレーションも実行し ています。また、ソース LUN 上のブロックがリザーブド・プールに書き込まれていない状態では、 スナップショットの読み取りはソース LUN からの読み取りを引き起こします。そのため、セッシ ョン・データをセカンダリ・サーバの I/O で使用する前に、できるだけ Copy on First Write ア クティビティが収束するようにしてください。 ATA ドライブに関する考慮事項 ユーザーによっては、SnapView リザーブド LUN に ATA（Advanced Technology-Attached）ドライ ブの使用を選択することも考えられます。その場合は、ATA ドライブのパフォーマンスは一般的 に、使用可能な書き込みキャッシュに依存するという点に注意する必要があります。書き込みキ ャッシュが ATA ドライブへのすべての書き込みをキャッシングできる限り、ファイバ・チャネ ル・ドライブへの書き込みと ATA ドライブへの書き込みの間に目立ったパフォーマンスの違い はありません。ただし、書き込みキャッシュがいっぱいになると、この違いは表面に現れなくな ります。 図 9 に、1 つのソース LUN に 8 つの SnapView セッションが存在する場合の影響を示します。こ のグラフは、セッションの数が 4 つに達するまで、サーバにおけるソース LUN への I/O の応答時 間の違いはほとんど無視可能であることを示しています。セッションが４つ以上の場合は、ATA EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 17 ドライブ上のリザーブド LUN は、ファイバ・チャネル・ドライブ上のリザーブド LUN に比べて著 しく応答時間が長くなっています。 図9：SnapView セッションのリカバリ期間 応答時間が長くなるのは、複数のセッションが同じATAドライブの集合にアクセスして、アクセ スがマルチ・ストリーム・シーケンシャル、すなわちランダムになるからです。ATAドライブは、 ランダム・ワークロードの下では高いパフォーマンスを発揮しません。そのため、ソースからの 書き込みがシーケンシャルでも、ソースLUNの数、および同じATAドライブの集合にアクセスする セッションの数について考慮することが重要です。 ATA ドライブをリザーブド LUN として使用する場合は、もう 1 つ考慮事項があります。それは、 これらのセッションに対してスナップショットをアクティベートしたときに、ファイバ・チャネ ル上のリザーブド LUN と ATA 上のリザーブド LUN の違いが大きくなるということです。ATA ドラ イブは小さくてランダムな読み書きの効率が高くないため、パフォーマンスの違いが非常に大き くなります。ソース LUN 上のランダムな場所に存在する小さなブロックを読み取るスナップショ ットの場合、ソース LUN のパフォーマンスは大きく低下します。 したがって、リザーブド LUN に ATA ドライブを使用することが許容されるのは、ソース LUN とス ナップショット LUN のどちらでも I/O アクティビティがシーケンシャルで、大量の Copy on First Write オペレーションに対応する必要がない場合です。スナップショットでのアクティビ ティが小さくてランダムな I/O を必要とする場合に ATA ドライブを使用することは、お勧めでき ません。 リザーブド LUN に関する推奨事項 セッション中のスピンドルの競合をできるだけ抑えるためには、リザーブド LUN を適切な RAID グループに配置して使用する必要があります。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 18 リザーブド LUN はソース LUN 以外の RAID グループに リザーブド LUN は、ソース LUN を提供していない RAID グループにバインドする必要があります。 そうしない場合、１つのドライブの集合の中で、ディスクのある領域からの読み取りと同じディ スク上の他の領域への書き込みを実行しようとして、スピンドルの激しい競合が発生します。ま た、次に説明するように、リザーブド LUN がそのソース LUN と異なる RAID グループ上に存在す ると、いったん Copy on First Write オペレーションが発生した後ではスナップショットの読み 書きがソース LUN に与える影響が最小限に抑えられます。 リザーブド LUN は最初の 5 台のドライブに EMCは、応答時間が重要なデータをストレージ・システムの最初の 5 台に置かないことを推奨し ます。これは、これらのドライブにストレージ・システムの起動ドライブ、FLARE®データベース、 およびヴォールト・ドライブが置かれているからです。これらのドライブ上に構成されたLUNに 対するI/Oが多いと、Navisphereプログラムの応答時間が長くなるおそれがあります。また、こ れらのドライブ上にデータLUNがあると、ヴォールト・ドライブ障害の後で書き込みキャッシュ を再度有効にするための時間が長くなります。これは、交換用ドライブを挿入した後で、最初の 5 台のヴォールト・ドライブ上にあるすべてのユーザー・データを再構築してから、ドライブの 書き込みキャッシュを有効にしなければならないためです。そのため、最初の 5 台のドライブに は、グローバル・リザーブドLUNプールに割り当てられているLUNを置かないことを推奨します。 最初の 5 台のドライブの構成に関する詳細については、EMC.comおよびPowerlinkにあるホワイ ト・ペーパー「EMC CLARiiON Best Practices for Fibre Channel Storage」を参照してくださ い。 RAID グループ間でのリザーブド LUN の適切なバランス グローバル・リザーブド LUN プールの割り当てに対して専用の RAID グループを構成すると、管 理が容易になり、また、これらの専用スピンドルに対する I/O パターンを予測できるようになり ます。ただし、同じスピンドル・グループにアクセスが限定されるため、すべての SnapView セ ッションおよびスナップショットの Copy on First Write またはコンカレント書き込みアクティ ビティにより、スピンドルの競合およびキューイングが発生するおそれがあります。 このようにせず、リザーブド LUN プールに割り当てられた LUN を複数の RAID グループにまたが って分散させると、スピンドルの競合を最小限に抑えることができます。たとえば、ユーザー・ データ用として使用している RAID グループがリザーブド LUN の I/O アクティビティを処理でき、 含まれている LUN がスナップされないならば、その RAID グループにリザーブド LUN も配置する ことができます。ベスト・プラクティスとしては、このような RAID グループには 4 つから 5 つ を超えるリザーブド LUN を構成しないことをお勧めします。 100 台のディスクが 20 の RAID 5（4+1）グループに構成されているシステムの例を考えます。15 の RAID グループには定期的にスナップされる重要なデータが置かれ、残り 5 つの RAID グループ にはスナップされないユーザー・データが置かれています。この場合、この 5 つの RAID グルー プにリザーブド LUN を構成することが考えられます。 負荷を複数のRAIDグループに分散するためには、MetaLUNも使用できます。スナップされる 100 のソースLUNがあり、リザーブドLUNのために 5 つのRAIDグループが用意されている例を考えます。 5 つのRAIDグループのそれぞれに 100 のLUNを作成してから、ストライピングされた 100 の metaLUNを作成することで、I/Oの負荷を複数のRAIDグループに分散できます。この構成では、各 metaLUNのベースLUNを配置するRAIDグループを順番に使用します。metaLUNの構成の詳細につい ては、EMC.comおよびPowerlinkにあるホワイト・ペーパー「EMC CLARiiON Best Practices for Fibre Channel Storage」を参照してください。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 19 適切な RAID タイプのリザーブド LUN リザーブド LUN に対しては、そのリザーブド LUN への予期される書き込みアクティビティに応じ た RAID タイプを選択する必要があります。RAID 5 は多くの場合に汎用的な RAID タイプとして 適しており、リザーブド LUN が実行する Copy on First Write アクティビティの要求を満たすこ とができます。リザーブド LUN を ATA ドライブに配置する場合でも、ATA で使用されることの多 い RAID 3 ではなく、RAID 5 を使用してください。Copy on First Write オペレーションでは、 ほとんどの状況でドライブに対してランダム・アクセスが行われるため、RAID 3 では効率よく 実行できません。 リザーブド LUN プールの構成 図 10 に示すように、割り当てられていないLUNはリザーブドLUNプール向けに選択することがで きます。リリース 24 から、プールに割り当てられたリザーブドLUNはSP AとSP Bのどちらが所有 することもできるようになったため、リザーブドLUNプールはSP AおよびSP BのLUNを含む「グロ ーバルな」プールです。リザーブドLUNプールに割り当てられたLUNは、ソースLUNに割り当てら EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 20 れるまではFreeと表示され、割り当てられるとAllocatedと表示されます。 7 図10：リザーブド LUN プールの構成 Navisphere CLI でも、次のコマンドを入力することによってこの情報を表示できます。 naviseccli -h <SP> snapview –lunpool Target LUNs 13 10 9 Associated LUN Pool LUNs 700 701 LUN Pool LUN Used Percent 80.934419 11 12 14 702 7 8 48.228936 2 2.797160 snapview –lunpool の出力は、指定されたソース LUN に割り当てられているリザーブド LUN の数に 関する詳細を示します。この例では、SnapView によってソース LUN 13 に 2 つのリザーブド LUN （700 および 701）が割り当てられています。 ソース LUN で最初のセッションを開始すると、リザーブド LUN が割り当てられます。最初に使用 可能になったリザーブド LUN が、そのソース LUN に割り当てられます。セッションの実行中にリ ザーブド LUN がいっぱいになると、次に使用可能なリザーブド LUN が自動的にソース LUN に割り 当てられます。リザーブド LUN プール内で使用可能なリザーブド LUN がなくなると、リザーブド LUN がいっぱいになる原因となったセッションが自動的に停止します。そのセッションで使用さ れていたリザーブド LUN は、リザーブド LUN プールに戻され、他のセッションで使用できるよう になります。 リリース 24 から新しい CLI コマンド reserved –lunpool -list が追加されて、グローバ ル・リザーブド LUN プールに関する追加の統計情報が提供されるようになりました。次のコマン ドにより、以下に示す出力が得られます。 naviseccli -h <SP> reserved –lunpool -list Name of the SP: SP A Total Number of LUNs in Pool: 10 Number of Unallocated LUNs in Pool: 1 Unallocated LUNs: 15 Allocated LUNs: 700, 701, 11, 12, 14, 702, 7, 8, 2 Total size in GB: 22.256470 Unallocated size in GB: 9.999756 Used LUN Pool in GB: 5.996704 7 リザーブドLUNプールに割り当てられたLUNには、自動割り当てフラグが（LUNのプロパティで）設定されます。これ により、FLAREはソースLUNトレスパスを追跡する必要があるときに、リザーブドLUNをトレスパスできます。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 21 % Used of LUN Pool: Chunk size in disk blocks: 26.943645 128 reserved –lunpool list コマンドは、Used LUN Pool in GB パラメータで指定されたグローバル LUN プールのうち、すべての LUN が使用する領域の総量について概要を示します。 % Used of LUN Pool パラメータは、グローバル LUN プール全体に使用できる総領域のうち、リザ ーブド LUN が使用する領域のパーセンテージを示します。 リザーブド LUN の使用状況をユーザーが監視するためのサポートとして、特定のソース LUN によ るリザーブド LUN の使用率が 50%に達したとき、および 75%から 5%ごとに、SnapView は Event Monitor を通じて警告を送ります。 また、reserved –lunpool –list コマンドを使用することにより、グローバル LUN プール全 体の使用率を定期的にチェックできます。 ストレージ・システムあたりに許されているリザーブド LUN の指定された最大値が消費されると、 必要なときにリザーブド LUN を追加できません。その結果、追加のリザーブド LUN 領域が必要な セッションはその追加領域を取得できなくなります。したがって、セッションは割り当てられた リザーブド LUN 領域を超えた時点で停止されます。 リザーブド LUN のサイズ設定戦略 すでに説明したように、ソース LUN へのリザーブド LUN の割り当ては、そのソース LUN に対して 最初のセッションが始まるとすぐに行われます。リザーブド LUN に Copy on First Write データ を格納する領域がなくなると、そのリザーブド LUN プール内で次に使用可能なリザーブド LUN が 動的に割り当てられます。この自動割り当てのメリットは、リザーブド LUN を割り当てる際に、 手動による介入がまったく不要であるということです。 ただし、すべてのリザーブド LUN 割り当てが動的であるため、特定のリザーブド LUN が特定のソ ース LUN に割り当てられるように制御することはできません。その点で、SnapView セッション、 SAN Copy インクリメンタル・セッション、および MirrorView/A ミラーでリザーブド LUN を最適 な方法で使用するために、以下の推奨事項が参考になる可能性があります。 リザーブド LUN の均一サイズ設定 リザーブド LUN は自動的に割り当てられるため、ユーザーはリザーブド LUN がどのソース LUN で の使用にも適するように、均一なサイズを選択することが推奨されます。これは、SnapView、 SAN Copy インクリメンタル・セッション、または MirrorView/A セッションの使用形態が比較的 ランダムで流動性が高いとき、リザーブド LUN の動的な割り当てが最も効果を発揮するので、特 に該当します。 リザーブド LUN の最小サイズは、スナップする LUN のビットマップを保持できる大きさが必要で あることに注意してください。ビットマップの最小サイズは、ソース LUN のサイズの約 0.02%で す。したがって、リザーブド LUN を構成する際は、リザーブド LUN で必要とされるビットマップ のサイズを考慮する必要があります。 ソース LUN のサイズにばらつきがある環境では、均一の容量の基準を最小のソース LUN と最大の ソース LUN のどちらにするかを決定する必要があります。表 1 に示した例では、10 個の 100 GB の LUN と 2 個の 500 GB の LUN を持つ環境を使用します。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 22 小さいリザーブド LUN による領域の節約 ストレージ・システムの容量が問題になる場合は、最小のソース LUN を基準にした均一のサイズ を選択します。この場合、それよりも大きなソース LUN は複数のリザーブド LUN を必要とすると 考えられます。リザーブド LUN の割り当ては動的なので、SnapView が必要に応じて複数のリザ ーブド LUN の割り当てを処理します。 リザーブド LUN の使用量はソース LUN のサイズの 20%というガイドラインを使用し、その値を最 小のソース LUN に適用すると、リザーブド LUN は 20 GB になります。表 1 に、LUN 割り当ての見 積もりを示します。 表1：小さい均一のリザーブド LUN を使用する例 ソース LUN サイズ リザーブド LUN サイズ ソースあたりの リザーブド LUN ソース LUN の 合計 リザーブド LUN の合計 100 GB 20 GB 1 10 10 500 GB 20 GB 5 2 10 リザーブド LUN 20 × 20 GB この例で、小さいソース LUN が必要とするリザーブド LUN は 1 つだけ（リザーブド LUN はすべて 小さいソース LUN サイズの 20%であるため）であり、大きいソース LUN はその大きさのために複 数のリザーブド LUN を必要とします。合計のリザーブド LUN 使用量は、20 個のリザーブド LUN （12 個のソース LUN に対して）で、それぞれが 20 GB です。したがって、このソリューション では、実装されるリザーブド LUN の総数が多くなります。しかし、リザーブド LUN が小さいため、 合計の領域は 20 × 20 GB = 400 GB に最小化されます。 大きいリザーブド LUN による関係ソース LUN の最大化 同時に、ストレージ・システムあたりのリザーブドLUNの総数に制限があることにも注意が必要 です。 8 各ソースLUNには少なくとも 1 つのリザーブドLUNが必要なので、この制限は実質的にセ ッションを開始できるソースLUNの数を意味します。できるだけ多くのソースLUNでセッションを 開始したいと考えているユーザーは、大きいソースLUNによって複数のリザーブドLUNが消費され ていないようにすることが推奨されます。したがって、ユーザーがセッションを実行できるソー スLUNの数を最大化したいと考えている環境では、最大のソースLUNサイズを基準に均一のサイズ を設定します。これにより、各ソースLUNで必要なリザーブドLUNは 1 つだけになるので、より多 くのソースLUNでセッションを同時に実行できます。 8 CX3-80 では 512 個、CX3-40 では 256 個、CX3-20 では 128 個までのリザーブドLUNを使用できます。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 23 表2：大きい均一のリザーブド LUN を使用する例 ソース LUN サイズ リザーブド LUN サイズ ソースあたりの リザーブド LUN ソース LUN の 合計 リザーブド LUN の合計 100 GB 100 GB 1 10 10 500 GB 100 GB 1 2 2 リザーブド LUN の合計 12 × 100 GB この例では、リザーブド LUN が十分に大きいため、大きいソース LUN でも 1 つのリザーブド LUN しか必要としません。しかし、小さいソース LUN に対してソース LUN のサイズと同じ大きさのリ ザーブド LUN が用意されており、これは必要な領域を大幅に上回っていると考えられます。合計 のリザーブド LUN 使用量は、リザーブド LUN の数では 12 個ですが、使用される領域は 12 × 100 GB で 1200 GB です。このソリューションでは、使用されるリザーブド LUN の数は最小化さ れますが、前に示したソリューションよりも大幅に多くの領域が必要です。 これらの例で示したのは、リザーブド LUN の均一サイズ設定として考えられる範囲の両端です。 1 つ目の例では、リザーブド LUN の総数を多くする必要がありますが、リザーブド LUN によって 消費される領域は最小化できます。2 つ目の例はその逆で、必要なリザーブド LUN の総数は少な くなりますが、消費される領域は 3 倍です。ユーザーは、使用できるリザーブド LUN の総数と領 域の総量のどちらを制約事項とするかを判断する必要があります。 段階的構成 特定のリザーブド LUN がどのソース LUN に割り当てられるかをユーザーが明示的に制御すること はできませんが、環境によっては、リソースの段階的構成によって割り当てプロセスをある程度 制御することができます。これにより、実質的に意図したとおりの割り当てを実行できます。そ のような環境とは、ランダム性が非常に低く、使用パターン、およびそのパターンのために必要 な領域をユーザーがある程度調整できる環境です。 たとえば、ソース LUN に対して最初のセッションが開始されたときにリザーブド LUN が割り当て られるという前提があると、ユーザーは次の例のような手順を使用してリザーブド LUN の割り当 てを制御できます。 1. サイズを 2 GB として、LUN 101 をバインドします。 2. LUN 101 をリザーブド LUN プールに割り当てます。 3. サイズを 10 GB（5 つのリザーブド LUN）として、ソース LUN 1 でセッション 1 を開始します。 リザーブド LUN プールで使用可能な LUN はリザーブド LUN 101 だけなので、ソース LUN 1 にはこの リザーブド LUN 101 が割り当てられます。 4. サイズを 200 GB として、LUN 105 をバインドします。 5. LUN 105 をリザーブドLUNプールに割り当てます。 6. サイズを 1 TB（5 つのリザーブド LUN）として、ソース LUN 5 でセッション 1 を開始します。 リザーブド LUN プールで使用可能な LUN はリザーブド LUN 105 だけなので、ソース LUN 5 にはこの リザーブド LUN 101 が割り当てられます。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 24 この手順は、リザーブド LUN が解放されて他のセッションで使用されることのない、SAN Copy インクリメンタルまたは MirrorView/A の環境で特に有効です。一方、SnapView セッションはそ れよりも動的です。これは、セッションを繰り返し開始/停止していると、セッションが停止し たときにリザーブド LUN が解放されるためです。 環境が段階的構成のために必要な予測可能性を持っていると確信できない限り、リザーブド LUN の均一サイズ設定の方がはるかに複雑性が低く、通常は単純で一般的な実装であることに注意し てください。 結論 リザーブド LUN は、SnapView セッション、SAN Copy インクリメンタル・セッション、および MirrorView/A ミラーの Copy on First Write アクティビティをサポートして、データのポイン ト・イン・タイム・コピーの整合性を提供します。各製品には、リザーブド LUN の消費に関して、 一般的に同じガイドラインが存在します。ソース LUN のサイズ、ソース LUN 上のデータの変更頻 度、およびセッションの予想される長さです。同時に、リザーブド LUN のサイズを適切に設定す るために配慮する必要がある各種の具体的な考慮事項が製品ごとに存在します。 リザーブド LUN を動的に割り当てることにより、リザーブド LUN 領域がすべて消費されたときに、 必要に応じて（可能であれば）リザーブド LUN が割り当てられ、機能をサポートするために必要 な、サイズと量において十分なリザーブド LUN が確保されます。 EMC CLARiX リザーブド LUN プールの構成に関する考慮事項 ベスト・プラクティスのプランニング 25