Data Domain Restorer (DDR)とクラウドへの長期保存(LTR)：よくある質問/FAQ

この記事では、Data Domain Restorer (DDR)および長期保存(LTR)またはクラウド機能の構成と使用に関するよくある質問への回答を提供します。
 

LTRとは？

• LTRは、Data Domain Operating System (DDOS) 6.0以降で導入された新しい機能です。
• LTRを使用すると、特定のモデルのDDRで、サポートされているさまざまなパブリック/プライベートクラウド プロバイダーから、ファイルまたはデータのサブセットをクラウド階層と呼ばれるオブジェクトストレージまたはクラウド ストレージに移行できます。
• ファイルまたはデータをオブジェクトストレージに物理的に移行するために、DDRでデータ移動プロセスが実行されます。
• クラウド階層から冗長データを物理的に解放するために、DDRでクラウド階層クリーニング プロセスが実行されます。
• LTRはライセンス機能で、使用するには CLOUDTIER_CAPACITY licenseの詳細を確認してください。
• LTRには、クラウド階層メタデータ用のローカル ストレージが必要です。

LTRはどのDDRシステムで使用できますか？
それは、ご利用のシステム モデル タイプとインストールされているDDOSのバージョンによって異なります。ほとんどのモデルには、LTRを構成するために事前に満たす必要がある特定のハードウェア要件があります。要件については、該当するモデルのハードウェア インストール ガイドと『DDOS Administration Guide』を参照してください。

LTRに必要なライセンスは何ですか？

• LTRはDDOS 6.x以降の新機能と見なされるため、eライセンスが必要です。 
• 必要なeライセンスのタイプは、 CLOUDTIER_CAPACITY licenseの詳細を確認してください。その CLOUDTIER_CAPACITY license の例を以下に示します。

Capacity licenses:
##   Feature              Shelf Model   Capacity     Mode        Expiration Date
--   ------------------   -----------   ----------   ---------   ---------------
1    CLOUDTIER-CAPACITY   n/a           136.42 TiB   permanent   n/a
--   ------------------   -----------   ----------   ---------   ---------------

各階層はどのように機能しますか？

• 通常のDDR（LTRライセンスなし）には、アクティブ階層と呼ばれる単一の階層があります。
• アクティブ階層は、すべての「標準」DDR上のストレージの従来の階層です。
• LTRシステムには、クラウド階層と呼ばれるストレージの第2階層があります。

各階層の最大サイズは、特定のハードウェア構成とDDOSバージョンでサポートされている制限によって決まります。『DDOS Administration Guide』および該当する特定のモデルのハードウェア ガイドを参照してください。

2層（アクティブとクラウド）のLTR構成の例を次に示します。   

Active Tier:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   --------   --------   ---------   ----   --------------
/data: pre-comp           -    36674.6           -      -                -
/data: post-comp    65460.3      585.4     64874.8     1%              0.1
/ddvar                 29.5       24.7         3.3    88%                -
/ddvar/core            31.5        1.1        28.8     4%                -
----------------   --------   --------   ---------   ----   --------------

Cloud Tier
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -       33.1           -      -               -
/data: post-comp      912.2       42.3       869.9     5%             4.1
----------------   --------   --------   ---------   ----   -------------

Total:
Resource           Size GiB   Used GiB   Avail GiB   Use%   Cleanable GiB
----------------   --------   --------   ---------   ----   -------------
/data: pre-comp           -    36674.6           -      -               -
/data: post-comp    65460.3      585.4     64874.8     1%             0.1
/ddvar                 29.5       24.7         3.3    88%               -
/ddvar/core            31.5        1.1        28.8     4%               -
----------------   --------   --------   ---------   ----   -------------

クラウド階層はどのように構成されていますか？

• クラウド階層は次の要素で構成されます。   
  • 物理DDRを使用する場合はエンクロージャに格納され、DDVEを使用する場合はLUNまたはデバイスに格納される、ローカル保存メタデータ。
  • オブジェクトストレージ プロバイダー
• 上記の両方がクラウド ユニットに統合されています。
• 複数のクラウド ユニットが構成されている場合は、ローカル保存メタデータを共有できます。
• システムごとに最大2つのクラウド ユニットを構成できます。各クラウド ユニットは、異なるオブジェクトストレージ プロバイダーからプロビジョニングできます。
• 各クラウド ユニットは、特定のDDRモデルでサポートされているアクティブ階層の最大サイズと同じ大きさにすることができます。詳細については、『DDOS Administration Guide』を参照してください。

LTRが構成されている場合に一般的なバックアップ ライフ サイクルでは何が起こりますか？

• すべてのデータは最初にアクティブ階層に書き込まれ、その時点から経過時間に伴って古くなっていきます。
• 保存期限に達した有効期間の短いデータは、通常のDDRと同様に期限切れとなるか削除されます。
• ただし、長期保存が必要なデータのサブセットは、クラウド階層に移行されます。
• ファイル システムでは、すべての階層にわたって単一のネームスペースが維持されます。このため、ファイルをクラウドに移行してもネームスペースは変更されず、ユーザーまたはバックアップ アプリケーションに対して十分に透過的です。
• クラウド階層にすでに移行されたファイルが保存期限に達すると、他のファイルと同様に期限切れとなるか削除されます。
• クラウド階層でファイルが使用していた領域はすぐには再利用されず、代わりにクラウド階層のクリーニングを実行する必要があります。

階層間でのデータ重複排除はどのように行われますか？

• 各クラウド ユニットはスタンドアロン ボリュームであり、自己完結型の重複排除ユニットです。
• その結果、各クラウド ユニットに書き込まれたデータは、同じクラウド ユニット内のデータに対してのみ重複排除できます。

配置日時(ptime)とは何ですか？

• ファイルとディレクトリーには、さまざまなタイムスタンプが関連付けられています。
• 例えば、ファイルまたはディレクトリーには、作成日時、最終アクセス日時、および変更日時があります。
• DDOSでは、配置日時が追加され、この機能がさらに強化されています。配置日時は、ファイルがアクティブ階層からクラウド階層に移行された日時です。
• DDOSのバージョンによっては、ファイルが存在する階層を調べる際に配置日時を確認できます。ファイルがクラウド階層に移行された場合、配置日時が表示されます。例：  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-4        cloudunit2           Tue Sep 5 10:17:00 2017
/data/col1/mtree1/random-data-file-5        cloudunit2           Tue Sep 12 15:52:23 2017
/data/col1/mtree1/random-data-file-6        cloudunit2           Tue Sep 13 09:42:55 2017

• ptimeは上記の出力の最後のフィールドですが、フィールド ヘッダーは表示されません。

アクティブ階層からクラウド階層にデータはどのように移動されますか？

• データ移動と呼ばれるプロセスでは、アクティブ階層に存在するMTree内のファイルを調査する必要があります。
• データ移動は、データ移動用に構成されたすべてのMTreeのスナップショットを作成することから始まります。
• 各ファイルには、ファイルが最後に書き込まれた日時を格納する変更日時があります。
• ファイルが以前にクラウド階層に移行された場合は、配置日時と呼ばれる追加の時間フィールドが設定されます。配置日時には、ファイルがクラウド階層に移行された日時が格納されます。配置日時が設定されている場合は、変更日時の代わりに使用されます。これは、ファイルがリコールされた場合に、ファイルが継続的にクラウド階層にリコールされないようにするためです（ファイルをリコールしても変更日時は変更されないため）。
• 上記で作成されたスナップショットは、データ移動によってトラバースされます。
• 調査対象のファイルが、対象のMTreeのデータ移動ポリシーによって設定された定義済みの閾値に達した場合、そのファイルを評価して、ファイルに保持されているどのデータをアクティブ階層からクラウド階層に移行する必要があるかが決定されます。データ移動ポリシーはMTreeごとに設定されます。
• 選択したファイルの一意のセグメントが、クラウド階層に書き込まれるか、コピーされます。 
• 一意のセグメントがコピーされると、移行が成功したことを確認するために、ファイルを読み戻して検証します。
• ファイルの検証が完了すると、メタデータが更新され、ファイルがクラウド階層に存在することが反映されます。
• データ移動プロセスは、特定の頻度で実行するようにスケジュールすることも、手動で開始することもできます。

データ移動が開始されると、どのフェーズがあり、各フェーズはどのようなアクションを実行しますか？

• データ移動には、コピー フェーズ、検証フェーズ、インストール フェーズの3つのフェーズが関連付けられています。
• コピー フェーズでは、クラウドにコピーする必要があるセグメントを特定し、これらのセグメントをクラウドに移行する必要があります。
• コピー フェーズが開始されると、クラウド ストレージまたはオブジェクトストレージが、コピー フェーズで特定されたセグメントをアクティブ階層からクラウド階層にコピーされる際に使用されます。
• 検証フェーズでは、ファイルのセグメントがクラウドに正常に移行されたことを確認する必要があります。
• インストール フェーズでは、移行されたファイルに関連するメタデータを更新し、そのファイルがクラウド ストレージまたはオブジェクトストレージ上に存在することを示す必要があります。
• 各ファイルのデータ移動が正常に完了したと判断されるには、3つのフェーズをすべて完了する必要があります。したがって、ファイルのインストール フェーズが完了するまで、そのファイルはアクティブ階層に留まります。

どのようなデータ移動ポリシーがありますか？

• データ移動ポリシーは、次のいずれかになります。   
  • age-threshold/経過年数の閾値：ファイルの配置日時または変更日時が設定された経過年数の閾値を超えると、クラウド階層への移行対象として選択されます。
  • age-range/経過年数の範囲：ファイルの配置日時または変更日時が特定の範囲内にある場合は、クラウド階層への移行対象として選択されます。
  • app-managed/アプリケーション定義：クラウド階層への移行対象となるファイルの選択は、バックアップ アプリケーションによって指定されます。
• ポリシーは相互に排他的です。つまり、MTreeでは一度に1つのポリシーしか設定できません。

MTreeにデータ移動ポリシーを設定する方法は？

• 次のコマンドを使用できます。例：   

data-movement policy set <policy name> <policy type values> totier cloud cloud-unit <cloud unit name> mtrees <mtree list>

sysadmin@dd4500 # data-movement policy set age-threshold 14 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set age-range min-age 14 max-age 100 to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1
sysadmin@dd4500 # data-movement policy set app-managed to-tier cloud cloud-unit cloudunit1 mtrees /data/col1/mtree1

すでに構成されているデータ移動ポリシーは何ですか？

• 次のコマンドを実行すると、データ移動ポリシーが割り当てられているMTreeのリストが表示されます。例：   

data-movement policy show

sysadmin@dd4500 # data-movement policy show
Mtree               Target(Tier/Unit Name)   Policy      Value      
-----------------   ----------------------   ---------   -----------
/data/col1/mtree1   Cloud/cloudunit1         age-range   14-100 days
-----------------   ----------------------   ---------   -----------

「app-managed」データ移動ポリシーはどのように機能しますか？

• 該当するMTreeのデータ移動ポリシーは「app-managed」に設定されています。これは手動で行うか、バックアップ アプリケーションによりData Domain REST APIインターフェイスを使用して実行します。
• バックアップ アプリケーションはLTR対応である必要があります。
• バックアップ アプリケーションはDD Boostを使用する必要があり、DD BoostのバージョンはLTR対応で互換性がある必要があります。
• バックアップ アプリケーションは、DD Boostライブラリ/APIを使用して、クラウド階層に移行する必要があるファイルの配置時間を、次回のデータ移動の実行時にファイルをクラウドに移行することを示す特別な値に設定します。
• Data Domainシステムでデータ移動を実行すると、配置日時がチェックされ、前述のように特別な値に設定されている場合は、ファイルがクラウドに移行されます。

データ移動を手動で開始する方法は？

• 例えば、次のコマンドを使用できます。例：   

data-movement start

sysadmin@dd4500 # data-movement start
Data-movement started.

データ移動を監視する方法は？

• 次のコマンドを使用して、データ移動のステータスを確認できます。例：   

data-movement status

sysadmin@dd4500 # data-movement status
Data-movement to cloud tier:
----------------------------
Data-movement is initializing..

Data-movement recall:
---------------------
No recall operations found. 

• データ移動が実行されている場合は、次のコマンドを使用できます。例：   

data-movement watch 

sysadmin@dd4500 # data-movement watch
Data-movement: phase 1 of 3 (copying)
   92% complete; time: phase  0:08:04, total  0:08:14
      Copied (post-comp): 3.35 GiB, (pre-comp): 3.29 GiB,B,
      Files copied: 7, Files verified: 3, Files installed: 3

データの移動を停止する方法は？

• 次のコマンドを使用できます。例：   

data-movement stop 

sysadmin@dd4500 # data-movement stop
Data-movement stop initiated. Run the status command to check its status.

複数のクラウド ユニットがある場合、両方のクラウド ユニットへのデータ移動を並行して実行できますか？

• いいえ。基本的に、データ移動では、一度に1つのクラウド ユニットにのみデータを移動できます。

LTRの構成方法は？

• これは大まかな概要です。詳細なプロセスについては、『DDOS Administration Guide』を参照してください。
• 適切な CLOUDTIER_CAPACITY licenseの詳細を確認してください。
• まだ設定されていない場合は、システム パスフレーズを設定します。
• クラウド機能を有効化します。
• クラウド階層にメタデータ ストレージを追加します。
• クラウド プロファイルまたは適切なクラウドまたはオブジェクトストレージ ベンダーのプロファイルを構成します。
• クラウド ユニットを追加します。
• クラウドにデータを格納する必要があるMTreeのデータ移動ポリシーを構成します。
• データ移動を手動で開始するか、自動またはスケジュール設定されたデータ移動が開始されるまで待ちます。

クラウド ユニットを削除できますか？その方法は？

• 注意：これにより、クラウド ユニットに保持されているすべてのデータが破壊され、データが回復不能になるため、慎重に進めてください。
• 削除されるクラウド ユニットに存在するファイルを理解するには、このナレッジベース記事の「ファイルが配置されている階層を確認する方法は？」というタイトルのセクションを参照してください。
• これらのファイルは、不要になった場合は削除するか、保持する必要がある場合はアクティブ階層にリコールする必要があります。
• ファイルを保持する必要がある場合は、続行する前にすべてのファイルをリコールしてください。
• 削除されるクラウド ユニットにファイルが残っていない必要があります。
• このクラウド ユニットを使用するMTreeのデータ移動ポリシーをリセットします。
• ファイル システムを無効にします。
• クラウド ユニットを削除します。これにより、クラウド ユニットがDELETE_PENDING状態になります。これは、設計通りです。
• ファイル システムを有効化します。
• ファイル システムが起動すると、このクラウド ユニットによって使用されていたクラウドまたはオブジェクトストレージ プロバイダー内のすべてのオブジェクトが非同期的に削除され始めます。すべてのオブジェクトが削除されると、このクラウド ユニットが使用していたバケットも削除されます。オブジェクトが多数ある場合は、クラウド ユニットが長時間DELETE_PENDING状態のままになる可能性があります。
• すべてのオブジェクトとバケットが正常に削除されると、クラウド ユニットがクラウド ユニット リストから消えます。

オブジェクト ストレージが使用できなくなった場合や接続の問題が発生した場合に、クラウド ユニットの削除に失敗するとどうなりますか？

• その先のサポートについては、Dellサポートにお問い合わせください。

LTRとExtended Retention (ER)を同じシステムで構成できますか？

• いいえ。ERとLTRは相互に排他的な機能です。

クラウド階層からどのようにデータが解放またはクリーニングされますか？

• これは、アクティブ階層に存在するファイルと同様に動作します。
• ファイルが保存期限に達すると、ファイル システムのネームスペースから削除されます。
• クラウド階層のクリーニングを実行するようにスケジュール設定されています。デフォルトでは、クラウド階層のクリーニングは、4つのアクティブ階層のクリーニング セッションごとに実行されます。
• クラウド階層のクリーニングを実行するには、クリーニング対象のクラウド ユニットに、少なくとも1%の余分なデータまたはクリーニング可能なデータが含まれている必要があります。これは、クラウド ネットワーク トラフィックが課金対象になる可能性があるため、DDRが可能な限りネットワーク トラフィックを制限しようとするためです。
• クラウド階層は、デフォルトの50%のクリーニング スロットルで実行されます。
• クラウド階層のクリーニング スケジュールとクリーニング スロットルはどちらも変更できます。
• アクティブ階層とクラウド階層のクリーニングを並行して実行することはできません。
• 自動またはスケジュール設定されたクラウド階層クリーニングが実行されている場合は、アクティブ階層クリーニングが優先されます。
• 手動でクラウド階層のクリーニングを開始した場合は、クラウド階層クリーニングが完了するまでアクティブ階層クリーニングを開始できません。
• クラウド階層に2つのクラウド ユニットがある場合、スケジュール設定済みのクラウド階層クリーニングまたは自動クラウド階層クリーニングごとにクリーニングされるクラウド ユニットは1つのみです。クラウド ユニットは、クラウド階層クリーニングの観点からラウンドロビン方式で動作します。クラウド ユニットが2つある場合は、コマンド ラインから実行するときに、クリーニングするクラウド ユニットを指定する必要があります(cloud clean start <unit-name>)。
• クラウド ユニットでクラウド階層クリーニングの開始に失敗した場合（例えば、現在のクラウド ユニットにクリーニング可能なデータが十分にないため実行する価値がない場合）、システムは自動的に次のクラウド ユニットからクリーニングを試みます。
• クラウド階層のクリーニングの詳細については、次の記事「Data Domain: Data Domain Restorer (DDR)での長期保存/クラウド階層のクリーンアップ/ガベージ コレクションについて」を参照してください。

クラウド階層の手動クリーニングを開始する方法は？

• 次のコマンドを使用できます。例：   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean start cloudunit2
Cloud tier cleaning started for cloud unit "cloudunit2". Use 'cloud clean watch' to monitor progress.

クラウド階層のクリーニングを監視する方法は？

• 次のコマンドを使用して、クラウドのクリーニングが実行されているかどうかを確認できます。例：   

cloud clean start <cloud unit> 

sysadmin@dd4500 # cloud clean status
Previous cloud tier cleaning attempt was unsuccessful.
 Failure reason:
cloud unit "cloudunit2" did not have sufficient cleanable data.
Cloud tier cleaning finished at 2017/03/15 12:16:06.

• クラウドのクリーニングが実行されている場合は、次のコマンドを使用して監視できます。

cloud clean watch

アクティブ階層のクリーニングをクラウド階層のクリーニングと同時に実行できますか？

• いいえ。アクティブ階層のクリーニングとクラウド階層のクリーニングはどちらも、排他的なアクセスを必要とする同じ共通内部共有データ構造を使用します。

クラウド階層のクリーニング スケジュールを表示または変更する方法は？

• 次のコマンドを使用して、現在のクラウド クリーニング スケジュールを表示できます。例：   

cloud clean frequency show

sysadmin@dd4500 # cloud clean frequency show
Cloud tier cleaning frequency is set to run after every 4 active tier cleaning cycles.

• 次のコマンドを使用して、スケジュールを変更します。例：  

cloud clean frequency set <value>

sysadmin@dd4500 # cloud clean frequency set 3
Cloud tier cleaning frequency is set to run after every 3 active tier cleaning cycles.

クラウド階層のクリーニング スロットルを変更または表示する方法は？

• デフォルトでは、クラウド階層のクリーニング スロットルは50%に設定されています。次のコマンドを使用して、デフォルトのスロットル パーセンテージにリセットできます。

cloud clean throttle reset

• 次のコマンドを使用して、現在のクラウド クリーニング スロットルを表示できます。例：   

cloud clean throttle show

sysadmin@dd4500 # cloud clean throttle show
Cloud tier cleaning throttle is set to 28 percent

• 次のコマンドを使用して、クリーニング スロットルを変更できます。例：   

cloud clean throttle set <value> 

sysadmin@dd4500 # cloud clean throttle set 20
Cloud tier cleaning throttle set to 20 percent

クラウド階層のクリーニング スロットルは何を制御しますか？

• クラウド階層のクリーニング スロットルは、アクティブ階層のクリーニング スロットルと同様に動作します。そのスロットリングにより、クラウド階層クリーニングで使用できるI/OおよびCPUリソースが制限されます。
• ネットワーク転送はスロットリングされません。

クラウド階層のクリーニングで、期待した数のオブジェクトの解放/削除が行われないのはなぜですか？

• クリーニングは常に見積もりと見なされます。次のKB記事では、このトピックの側面について説明しています。これは、クラウド階層に存在するデータにも同様に適用されます。  

• これに加えて、クラウド階層の実装方法に関する具体的な詳細があります。
• 関連コストが発生する可能性があるため、クラウドまたはオブジェクトストレージ プロバイダーへのネットワーク トラフィックの量を制限するために、さまざまな方法が実装されています。
• 前述したように、クリーニングを実行するには、少なくとも1%のデータ チャーンが必要です。
• データ移動ポリシーを満たすファイルを検索するためにファイル システムをトラバースする場合、メタデータのローカル コピーのみが調べられます。
• クラウドまたはオブジェクトストレージに保持されているセグメントのうち、ユーザー データのみを保持していることが判明したセグメントは、非同期削除のマークが付けられます。
• 少なくとも1つのライブ セグメントを含むセグメントはスキップされます。これは、ネットワーク トラフィックが発生するため、DDOSは少量のデータを結合したくないためです。

ファイルが配置されている階層を確認する方法は？

• 以下のコマンドを使用して、このコマンドによって生成される出力の例を確認できます。  

filesys report generate file-location

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-1        Active
/data/col1/mtree1/random-data-file-2        Active
/data/col1/mtree1/random-data-file-4        cloudunit2
/data/col1/mtree1/random-data-file-5        cloudunit2
/data/col1/mtree1/random-data-file-6        cloudunit2

クラウド階層に移行されたファイルを直接読み取りまたはアクセスできますか？

• これは、使用されているDDOSのバージョンとクラウド プロバイダーによって異なります。   

• 最初にファイルをリコールしなくても、ファイルを直接リストアできます。これは「ダイレクト リストア」機能と呼ばれ、ECS（クラウドまたはオブジェクト プロバイダー）に限定されます。
• Avamarからの「ダイレクト リストア」の詳細については、『Avamar Granular or File Level Restore from Data Domain Cloud Tier』を参照してください。
• Avamar GLR/FLR（ダイレクト リストア）機能には、少なくともAvamar 18.1またはDDOS 6.1とECS（クラウド プロバイダー）の組み合わせが必要です。 

• 最初にファイルをリコールする必要があります。つまり、データはクラウド階層からアクティブ階層に戻されます。
• data-movement recallコマンドを使用してクラウド階層からアクティブ階層にファイルをリコールし、クラウド階層にあるファイルの読み取りまたは変更を許可する必要があります。
• ファイルが最初にリコールされないと、クラウド階層に存在するファイルの読み取りまたは変更を試行すると、ファイルを読み取ろうとするバックアップ アプリケーションにI/Oエラーが返されます。
• 一部のクラウド対応バックアップ アプリケーションでは、ファイルのリコールを開始できますが、開始できない場合は、ファイルを手動でリコールする必要があります。
• DDOS 7.7+以降の場合：
  • ダイレクト リストアを使用すると、非統合アプリケーションでも、アクティブ階層を経由せずにクラウド階層からファイルを直接読み取ることができます。
  • ダイレクト リストアを使用する際の主な考慮事項は次のとおりです。
  • ダイレクト リストアは、統合アプリケーションを必要とせず、非統合アプリケーションに対して透過的です。
  • クラウド階層からの読み取りでは、最初にアクティブ階層にコピーする必要はありません。
  • ヒストグラムと統計は、クラウド階層からの直接読み取りの追跡に使用できます。
  • ダイレクト リストアは、AWSおよびECSクラウド プロバイダーでのみサポートされています。
  • アプリケーションでは、クラウド階層のレイテンシーが発生します。
  • クラウド階層からの直接読み取りでは、帯域幅が最適化されていません。

並行して何個のファイルをリコールすることができますか？

• DDOS 6.0では、4つのファイルを並行してキューに登録し、リコールすることができます。
• DDOS 6.1では、1,000個のファイルをキューに登録し、リコール キュー内の4個のファイルを並列してリコールできます。

『DDOS Administration Guide 7.9』によると：

• 256 GB以上のメモリーを搭載したシステムでは、一度に最大16個のファイルをリコールできます。
• 256 GB未満のメモリーを搭載したシステムでは、一度に最大8個のファイルをリコールできます。
• DDVEインスタンスは、一度に最大4つのファイルをリコールできます。

ファイルをリコールする方法は？

• ファイルは、次のコマンドを使用してリコールすることができます。例：   

data-movement recall path <path-name> 

sysadmin@dd4500 # data-movement recall path /data/col1/mtree1/file1

MTree内のすべてのファイルをリコールする方法は？

• DDOSのバージョンによっては、次のような単一のコマンドを実行して、クラウド内のすべてのファイルをリコールできます。   

sysadmin@dd4500 # data-movement recall mtree /data/col1/mtree1

• 詳細については、お使いのDDOSバージョンの『Dell DDOSコマンド リファレンス ガイド』を参照してください。

リコール操作を監視する方法は？

• リコール操作は、次のコマンドを使用するか、特定のファイルが必要な場合に監視できます。例：   

data-movement status path all

data-movement status path /data/col1/mtree/file1

sysadmin@dd4500 # data-movement status path /data/col1/mtree1/file1
Data-movement recall:
---------------------
Data-movement for  /data/col1/mtree1/file1 : phase 2 of 3
(Verifying)
80% complete; time: phase XX:XX:XX total XX:XX:XX
Copied (post-comp): XX XX, (pre-comp) XX XX 

ファイル名を変更すると、クラウド階層からアクティブ階層にファイルがリコールされますか？

• いいえ。ファイル名を変更しても、現在の階層に残ります。

サポートされているクラウド プロバイダーは？

•  ご使用中のDDOSバージョンに応じて、DDOSは次のクラウド プロバイダーをサポートします。   
• Amazon Web Services (AWS)
• Microsoft Azure Cloud
• Dell Elastic Cloud Storage (ECS)
• Virtustream
• 詳細については、『DDOS Administration Guide』を参照してください。

クラウド階層で暗号化はサポートされていますか？また、ライセンスは必要ですか？

• はい、クラウド階層では暗号化がサポートされています。アクティブ階層の暗号化とは異なり、追加のライセンスは必要ありません。
• これは、クラウド機能の有効化時に構成したり、あとで変更したりできます。 
• この記事の作成時点では、クラウド階層の暗号化では組み込みキー マネージャーのみがサポートされており、システム全体でLTRに使用できる暗号化アルゴリズムは1つだけです。

クラウド プロバイダーのオブジェクト ストアにはどのようなバケットが作成されますか？

• DDOSは、3つのバケットを作成します。
• それらのバケットは、次の文字列で終わります。

'-d0'

'-c0' 

'-m0'

• 文字列「-d0」で終わるバケットは、データ セグメントに使用されます。
• 文字列「-c0」で終わるバケットは、構成データに使用されます。
• 文字列「-m0」で終わるバケットは、メタデータに使用されます。
• DDOS 6.1より前のバージョンでは、3つのバケットが作成されますが、「-d0」で終わるバケットのみが使用されます。ただし、3つのバケットすべてが必要であるため、削除されていないことを確認してください。

以前に作成された既存のバケット名を使用することはできますか？

• いいえ、それはできません。

ハードウェア要件に加えて、LTRを構成する前に必要な他の必須要件はありますか？

• Yes
• ECSを使用する場合、ロード バランサーは必須要件です。ロード バランサーがない場合、Data Domainは単一ノード上のECSと通信し、複数のリクエストが行われると切断されます。
• DDRとクラウド プロバイダー間に1Gbのネットワークが必要です。

証明書は必要ですか？必要な場合、どの証明書を使用する必要がありますか？

• これは、使用されているオブジェクト/クラウド プロバイダーと構成によって異なります。
• AWS、Virtustream、またはAzureには証明書が必要です。詳細については、『DDOS Administration Guide』を参照してください。
• ECSがhttpエンドポイントを使用して構成されている場合、証明書は必要ありません。
• ECSがhttpsエンドポイントを使用して構成されている場合は、証明書が必要です。ロード バランサーは必須要件であるため、必要な証明書はECSシステムではなくロード バランサー システムから取得されます。詳細については、ロード バランサーのプロバイダーにお問い合わせください。
• 証明書をインポートする場合は、PEM形式である必要があります。一部のプロバイダーは証明書をPEM形式で提供していないため、インポートする前に証明書の形式を変換する必要があります。

どのようなレプリケーション トポロジーがサポートされていますか？

• コレクション レプリケーションはサポートされていません。
• ディレクトリー レプリケーションはサポートされています。ただし、これは「/data/col1/backup」のMTreeでのみ使用できます（このMTreeはデータ移動をサポートしていません）。
• MTreeレプリケーションは完全にサポートされています。
• MFRまたはVSRレプリケーションは完全にサポートされています。

すでにLTRが構成されているシステムでレプリケーションを構成/初期化/再初期化する際に考慮すべきことは何ですか？

• ソース システムはMTreeのスナップショットを作成します（このスナップショットには、アクティブ階層とクラウド階層上のファイルの詳細が含まれます）。
• ソース システムは、ターゲット システムのアクティブ階層にスナップショットをレプリケートします。
• スナップショットが完全にレプリケートされた場合にのみ、ターゲット システム上に公開されます（その時点で、ターゲット システムのファイル システム ネームスペースでファイルが使用可能になります）。
• ファイルが公開されて初めて、ターゲットでデータ移動を実行できます（LTR用に構成されていることを前提とする）。
• したがって、ターゲットのアクティブ階層が、ソースからの完全なスナップショットを保持するのに十分なサイズでない場合、スナップショットは公開されず、レプリケーションは初期化を完了できません。

すでにLTRが構成されているシステムでMFR/VSRレプリケーションを構成する際に考慮すべきことは何ですか？

• ソースDDRのクラウド階層にすでに移行されているデータをレプリケートする必要がある場合は、ネットワーク経由で送信される前に、クラウド プロバイダーからアクティブ階層に自動的にリコールされます。
• クラウド階層からアクティブ階層にファイルをリコールすると、コストまたは遅延が発生する可能性があります。

Data Domainの「file system show space」コマンドの出力に、クラウド/オブジェクト ストレージの実際のサイズが反映されないのはなぜですか？

• クラウド/オブジェクトストレージ固有の仕組みにより、Data Domainシステムにはクラウド デバイスの物理サイズを照会する方法がありません。これは、一見無限にあるように見えるためです。
• ただし、DDOSは、DDOSの観点から現在の使用率/重複排除の統計情報を表示する方法を開発する必要がありました。
• したがって、次の2つの方法のいずれかが使用されます。

1. クラウド階層のサイズは、次によって決まります： CLOUDTIER_CAPACITY license
2. クラウド階層のサイズは、構成されているクラウド ユニットの数に応じて、そのモデル タイプのアクティブな階層ユニット サイズの倍数として表示されます。アクティブな階層のサイズに関する詳細については、該当するモデルのハードウェア インストール ガイドを参照してください。

クラウド ユニットが使用できない場合にファイル システムを起動する方法は？

• ファイル システムが無効になっていることを確認します。
• 次のコマンドを使用して、使用できないクラウド ユニットを無効にします。

cloud unit disable <cloud unit name>

• ファイル システムを有効化します。

クラウド ユニットが無効になっている場合に有効化する方法は？

• ファイル システムが無効になっていることを確認します。
• 次のコマンドを使用して、クラウド ユニットを有効にします。

cloud unit enable <cloud unit name>

• ファイル システムを有効化します。

削除されたクラウド ユニットに存在するファイル システムにファイルがまだ存在するのはなぜですか？

•  クラウド ユニットが削除される前にMTreeからファイルが削除されなかった場合、ファイルはファイル システム ネームスペース内に残ります。
• そのため、「file-location」レポートでは、それらのファイルが削除されたクラウド ユニットに含まれることが示されます。例：  

sysadmin@dd4500 # filesys report generate file-location
--------------------------------      ---------------------------
File Name                             Location(Unit Name)
--------------------------------      ---------------------------
/data/col1/mtree1/random-data-file-3  Deleted cloud-unit
/data/col1/mtree1/random-data-file-4  Deleted cloud-unit

• ファイルは、このMTreeのCIFS/NFS共有にアクセスすることで、ファイル システム ネームスペースで引き続き表示できます。
• ただし、ファイルが配置されていたクラウド ユニットが削除されているため、ファイルを読み取ることはできません。
• したがって、唯一のオプションは、参照したデータが存在しなくなったため、これらのファイルを削除するのみです。

クラウド ユニットの作成後に、ECSまたはS3フレキシブル クラウド プロバイダーのプロトコル エンドポイントまたはポートを変更することはできますか？

• この変更は、例えば、httpからhttpsに変更したり（またはその逆）新しいロード バランサーに移行したりする場合に必要になることがあります。
• この記事の作成時点では、Data Domain管理者がこの変更を実行する方法はありません。この機能は、将来のDDOSリリースで検討されています。
• ただし、この変更はサポートまたはエンジニアリングによって実行できます。
• この変更を実行するには、ファイル システムを無効にする必要があります。
• この変更が必要な場合は、Data Domainシステム外のすべての構成を最初に実行する必要があります。これは、一度変更すると、ファイル システムが有効化されたときに、更新されたプロトコルまたはポートを使用して通信し、以前と同様にバケットまたはオブジェクトを読み取ることができると想定されるためです。