Data Domain Restorer 및 클라우드에 장기간 보존: 자주 묻는 질문

이 문서에서는 DDR(Data Domain Restorer) 및 LTR(Long-Term Retention), 또는 클라우드 기능의 구성 및 사용과 관련하여 자주 묻는 질문에 대해 설명합니다.
 

LTR이란 무엇입니까?

• DDOS(Data Domain Operating System) 6.0부터 LTR이라는 새로운 기능이 도입되었습니다.
• LTR을 사용하면 DDR의 특정 모델이 지원되는 다양한 퍼블릭 또는 프라이빗 클라우드 공급업체에서 파일 또는 데이터의 하위 집합을 클라우드 계층이라고 하는 오브젝트 또는 클라우드 스토리지로 마이그레이션할 수 있습니다.
• 파일 또는 데이터를 오브젝트 스토리지로 물리적으로 마이그레이션하기 위해 DDR에서 데이터 이동 프로세스가 실행됩니다.
• 클라우드 계층에서 중복 데이터를 물리적으로 제거하기 위해 DDR에서 클라우드 계층 정리 프로세스가 실행됩니다.
• LTR은 라이선스가 부여된 기능으로, CLOUDTIER_CAPACITY license명령을 수행할 수 있는 충분한 공간이 있어야 합니다.
• LTR에는 클라우드 계층 메타데이터를 위한 일부 로컬 스토리지가 필요합니다.

LTR을 사용할 수 있는 DDR 시스템은 무엇입니까?
이는 시스템 모델 유형과 함께 설치된 DDOS 버전에 따라 달라집니다. 대부분의 모델에는 LTR을 구성하기 위해 미리 충족해야 하는 특정 하드웨어 요구 사항이 있습니다. 요구 사항은 DDOS 관리 가이드와 함께 특정 모델의 하드웨어 설치 가이드를 참조하십시오.

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 시스템에는 클라우드 계층이라고 하는 두 번째 스토리지 계층이 있습니다.

각 계층의 최대 크기는 지정된 하드웨어 구성 및 DDOS 버전에 대해 지원되는 제한에 따라 결정됩니다. 문제가 있는 특정 모델에 대한 DDOS 관리 가이드 및 하드웨어 가이드를 참조하십시오.

2계층, 1개 활성 및 1개의 클라우드, 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 관리 가이드를 참조하십시오.

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 내 파일을 검사합니다.
• 데이터 이동은 데이터 이동을 위해 구성된 모든 MTrees의 스냅샷을 생성하는 것으로 시작됩니다.
• 각 파일에는 파일이 마지막으로 기록된 시간을 저장하는 수정 시간이 있습니다.
• 파일이 이전에 클라우드 계층으로 마이그레이션된 경우 배치 시간이라는 추가 시간 필드가 설정됩니다. 배치 시간에는 파일이 클라우드 계층으로 마이그레이션된 날짜와 시간이 저장됩니다. 배치 시간이 설정되면 수정 시간 대신 사용됩니다. 이는 파일을 리콜해도 수정 시간이 변경되지 않으므로 파일이 리콜되면 클라우드 계층으로 계속 마이그레이션되는 것을 방지하기 위한 것입니다.
• 위에서 생성된 스냅샷은 데이터 이동을 통해 이동합니다.
• 검사 중인 파일이 해당 MTree에 대한 데이터 이동 정책에 설정된 정의된 임계값에 도달한 경우 해당 파일을 검사하여 해당 파일에 있는 어떤 데이터를 활성 계층에서 클라우드 계층으로 마이그레이션해야 하는지 확인합니다. 데이터 이동 정책은 MTree별로 설정됩니다.
• 선택한 파일의 고유 세그먼트가 클라우드 계층에 기록되거나 복제됩니다. 
• 고유 세그먼트들이 복제된 후에는 마이그레이션의 성공 여부를 확인하기 위해 파일을 다시 읽어 검증합니다.
• 파일이 확인되면 메타 데이터가 업데이트되어 이제 파일이 클라우드 계층에 상주함을 반영합니다.
• 데이터 이동 프로세스는 특정 빈도로 실행되도록 예약하거나 수동으로 시작할 수 있습니다.

데이터 이동이 시작될 때는 어떤 단계를 거치고 각 단계에서 무슨 작업이 수행됩니까?

• 데이터 이동에는 복제 단계, 확인 단계 및 설치 단계의 세 가지 단계가 있습니다.
• 복제 단계에서는 클라우드에 복제해야 하는 세그먼트를 식별한 다음 이러한 세그먼트를 클라우드로 마이그레이션합니다.
• 복제 단계가 시작되면 클라우드 또는 오브젝트 스토리지이며 복제 단계에서는 활성 계층에서 식별된 세그먼트를 클라우드 계층으로 복제합니다.
• 확인 단계에서는 파일의 세그먼트가 클라우드로 성공적으로 마이그레이션되었는지 확인하는 역할을 합니다.
• 설치 단계에서는 마이그레이션된 파일과 관련된 메타데이터를 업데이트하여 해당 파일이 현재 클라우드 또는 오브젝트 스토리지에 상주함을 표시합니다.
• 각 파일은 해당 파일에 대한 데이터 이동이 성공한 것으로 간주되려면 세 단계를 모두 완료해야 합니다. 따라서 파일에 대한 설치 단계가 완료될 때까지 파일은 활성 계층에 유지됩니다.

어떤 데이터 이동 정책을 사용할 수 있습니까?

• 데이터 이동 정책은 다음 중 하나일 수 있습니다.   
  • 연령 임계값: 파일 배치 또는 수정 시간이 설정된 기간 범위를 초과하는 경우 클라우드 계층으로 마이그레이션하도록 선택됩니다.
  • 연령 범위: 파일 배치 또는 수정 시간이 특정 범위에 속하는 경우 클라우드 계층으로 마이그레이션하도록 선택됩니다.
  • 애플리케이션 정의됨: 백업 애플리케이션은 클라우드 계층으로 마이그레이션할 파일을 선택할지 여부를 지정합니다.
• 정책은 상호 배타적입니다. 따라서 MTree에는 한 번에 하나의 정책만 설정할 수 있습니다.

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

어떤 데이터 이동 정책이 이미 구성되어 있습니까?

• 아래 명령은 데이터 이동 정책이 할당된 MTrees의 목록을 제공합니다. 예:   

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
-----------------   ----------------------   ---------   -----------

앱 관리 데이터 이동 정책은 어떻게 작동합니까?

• 해당 MTree의 데이터 이동 정책이 앱 관리로 설정되어 있습니다. 이 작업은 수동으로 수행하거나 백업 애플리케이션이 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.

클라우드 유닛이 두 개 이상인 경우 두 클라우드 유닛으로 데이터 이동을 동시에 실행할 수 있습니까?

• 아니요. 기본적으로 데이터 이동은 한 번에 하나의 클라우드 유닛으로만 데이터를 마이그레이션할 수 있습니다.

LTR은 어떻게 구성됩니까?

• 개략적인 개요입니다. 자세한 프로세스는 DDOS 관리 가이드에서 확인할 수 있습니다.
• 적절한 CLOUDTIER_CAPACITY license명령을 수행할 수 있는 충분한 공간이 있어야 합니다.
• 시스템 비밀번호 문구가 아직 설정되지 않은 경우 설정합니다.
• 클라우드 기능을 활성화합니다.
• 클라우드 계층에 대한 메타데이터 스토리지를 추가합니다.
• 적절한 클라우드 또는 오브젝트 스토리지 공급업체에 대한 클라우드 프로파일 또는 프로파일을 구성합니다.
• 클라우드 유닛을 추가합니다.
• 클라우드에서 데이터를 저장해야 하는 MTree 또는 MTrees에 대한 데이터 이동 정책을 구성합니다.
• 데이터 이동을 수동으로 시작하거나 자동 또는 예약된 데이터 이동이 시작될 때까지 기다립니다.

클라우드 유닛을 삭제할 수 있습니까? 그렇다면 어떻게 해야 합니까?

• 주의: 이렇게 하면 클라우드 유닛에 저장된 모든 데이터가 삭제되므로 데이터를 복구할 수 없으므로 주의해서 진행하십시오.
• 삭제할 클라우드 유닛에 상주하는 파일을 이해하려면 이 기술 자료 문서의 "사용자가 파일이 있는 계층을 확인하는 방법" 섹션을 참조하십시오.
• 이러한 파일은 더 이상 필요하지 않으면 삭제할 수 있지만, 보관해야 하는 경우에는 활성 계층으로 다시 호출하여야 합니다.
• 파일을 보관해야 하는 경우 계속하기 전에 모든 파일을 리콜해야 합니다.
• 삭제된 클라우드 유닛에 남아 있는 파일이 없어야 합니다.
• 이 클라우드 유닛을 사용하는 MTree 또는 MTrees의 데이터 이동 정책을 초기화하십시오.
• 다음을 수행하여 파일 시스템을 비활성화합니다.
• 클라우드 유닛을 삭제합니다. 이렇게 하면 클라우드 유닛이 설계된 바와 같이 DELETE_PENDING 상태로 표시됩니다.
• 파일 시스템을 활성화합니다.
• 파일 시스템이 시작되면 클라우드 또는 오브젝트 스토리지 제공자가 이 클라우드 유닛에 의해 사용된 모든 개체를 비동기적으로 삭제하기 시작합니다. 모든 오브젝트가 삭제되면 이 클라우드 유닛이 사용한 버킷도 삭제됩니다. 오브젝트가 많은 경우 클라우드 유닛이 장시간 DELETE_PENDING 상태로 유지될 수 있습니다.
• 모든 오브젝트와 버킷이 성공적으로 제거되면 클라우드 유닛이 클라우드 유닛 목록에서 사라집니다.

오브젝트 스토리지를 더 이상 사용할 수 없거나 연결 문제가 있어 클라우드 유닛을 삭제하지 못하면 어떻게 됩니까?

• 추가 지원이 필요한 경우 Dell 지원 부서에 문의하십시오.

동일한 시스템에서 LTR 및 ER(Extended Retention)을 구성할 수 있습니까?

• 아니요. ER 및 LTR은 상호 배타적인 기능입니다.

클라우드 계층에서 데이터를 확보하거나 정리하는 방법은 무엇입니까?

• 이는 활성 계층에 있는 파일과 유사한 방식으로 작동합니다.
• 파일이 보존 기간에 도달하면 파일 시스템 네임스페이스에서 삭제됩니다.
• 클라우드 계층 정리 실행이 예약됩니다. 기본적으로 클라우드 계층 정리는 4개의 활성 계층 정리 세션 후에 실행됩니다.
• 클라우드 계층 정리를 실행하려면 정리 중인 클라우드 유닛에 불필요하거나 정리 가능한 데이터가 1% 이상 있어야 합니다. 이는 DDR이 가능한 경우 네트워크 트래픽을 제한하려고 시도할 수 있도록 모든 클라우드 네트워크 트래픽에 비용이 청구될 수 있기 때문입니다.
• 클라우드 계층은 기본 설정으로 50%의 청소 스로틀로 실행됩니다.
• 클라우드 계층의 정리 일정과 정리 스로틀을 모두 변경할 수 있습니다.
• 활성 계층 및 클라우드 계층 정리를 동시에 실행할 수 없습니다.
• 자동 또는 예약된 클라우드 계층 정리가 실행 중인 경우 활성 계층 정리가 우선합니다.
• 수동 클라우드 계층 정리가 시작되면 클라우드 계층 정리가 완료될 때까지 활성 계층 정리를 시작할 수 없습니다.
• 클라우드 계층에 두 개의 클라우드 유닛이 있는 경우 예약된 클라우드 계층 정리 또는 자동 클라우드 계층 정리당 하나의 클라우드 유닛만 정리됩니다. 클라우드 유닛은 클라우드 계층 정리 관점에서 라운드 로빈 방식으로 운영됩니다. 클라우드 유닛이 2개인 경우 명령줄에서 실행할 때 정리할 클라우드 유닛을 지정해야 합니다(cloud clean start <unit-name>).
• 예를 들어 클라우드 계층 정리가 클라우드 유닛에서 시작되지 않고 현재 클라우드 유닛에 정리 가능한 데이터가 충분하지 않아 정리의 이점이 있다고 판단되지 않으면 시스템이 자동으로 다음 클라우드 유닛에서 정리를 시도합니다.
• 클라우드 계층 정리에 대한 자세한 내용은 다음 문서를 참조하십시오. Data Domain: DDR(Data Domain Restorer)의 장기간 보존, 클라우드 계층 정리 및 가비지 컬렉션 소개

수동 클라우드 계층 정리는 어떻게 시작합니까?

• 아래 명령을 사용할 수 있습니다. 예:   

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%의 데이터 변경이 필요합니다.
• 파일 시스템을 탐색하여 데이터 이동 정책을 충족하는 파일을 검색하면 메타데이터의 로컬 복제본만 검사됩니다.
• 클라우드 또는 오브젝트 스토리지에 저장된 세그먼트 중 사용자 데이터만 보관하는 세그먼트는 비동기식 삭제로 표시됩니다.
• 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에서 ‘직접 복원’에 대한 자세한 내용은 "Data Domain Cloud Tier에서 Avamar 세분화 또는 파일 수준 복원" 백서를 참조하십시오.
• Avamar GLR/FLR(직접 복원) 기능을 사용하려면 Avamar 18.1 또는 DDOS 6.1 이상을 사용해야 하며 ECS를 클라우드 공급업체로 사용해야 합니다. 

• 파일을 먼저 리콜해야 합니다. 즉, 데이터가 클라우드 계층에서 활성 계층으로 다시 마이그레이션되었습니다.
• 클라우드 계층에 있는 파일을 읽거나 수정하려면 데이터 이동 리콜 명령을 사용하여 클라우드 계층에서 활성 계층으로 파일을 리콜해야 합니다.
• 클라우드 계층에 상주하는 파일을 읽거나 수정하려고 하면 먼저 리콜하지 않은 경우 백업 애플리케이션이 되는 파일을 읽으려는 사람에게 I/O 오류가 반환됩니다.
• 일부 클라우드 인식 백업 애플리케이션은 파일 리콜을 시작할 수 있으며, 그렇지 않은 경우 파일을 수동으로 리콜해야 합니다.
• DDOS 7.7 이후:
  • 직접 복원을 사용하면 통합되지 않은 애플리케이션이 Active Tier를 거치지 않고 Cloud Tier에서 직접 파일을 읽을 수 있습니다.
  • 직접 복원을 사용하도록 선택할 때 고려해야 할 주요 사항은 다음과 같습니다.
  • 직접 복원은 통합 애플리케이션이 필요하지 않으며 통합되지 않은 애플리케이션의 경우 영향을 받지 않습니다.
  • 클라우드 계층에서 읽는 경우 먼저 활성 계층에 복제할 필요가 없습니다.
  • 클라우드 계층에서 직접 읽기를 추적하는 데 히스토그램 및 통계를 사용할 수 있습니다.
  • 직접 복원은 AWS 및 ECS 클라우드 공급업체에 대해서만 지원됩니다.
  • 애플리케이션은 클라우드 계층 레이턴시를 경험합니다.
  • 클라우드 계층에서 직접 읽기는 대역폭이 최적화되지 않은 작업입니다.

얼마나 많은 파일을 동시에 리콜할 수 있습니까?

• DDOS 6.0은 4개의 파일을 대기열에 추가하고 동시에 리콜할 수 있도록 지원합니다.
• DDOS 6.1에서는 대기열에 1000개의 파일을 저장할 수 있고, 동시에 4개의 파일을 리콜 대기열에서 리콜할 수도 있습니다.

Data Domain 관리 가이드 7.9에 따르면:

• 256GB 이상의 메모리가 있는 시스템은 한 번에 최대 16개의 파일을 리콜할 수 있습니다.
• 메모리가 256GB 미만인 시스템은 한 번에 최대 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는 다음 클라우드 공급업체를 지원합니다.   
• AWS(Amazon Web Services)
• Microsoft Azure 클라우드
• Dell ECS(Elastic Cloud Storage)
• Virtustream
• 자세한 내용은 DDOS 관리 가이드를 참조하십시오.

클라우드 계층에서 암호화가 지원되며 라이선스가 있어야 합니까?

• 예. 클라우드 계층에서 암호화가 지원됩니다. 활성 계층 암호화와 달리 추가 라이선스가 필요하지 않습니다.
• 클라우드 기능을 활성화하거나 수정한 후에 구성할 수 있습니다. 
• 쓰기 시점에는 내장형 키 매니저만 클라우드 계층 암호화에 지원되며 하나의 암호화 알고리즘만 LTR 시스템 전체에 사용할 수 있습니다.

클라우드 공급업체 오브젝트 저장소에는 어떤 버킷이 생성됩니까?

• DDOS는 3가지 버킷을 생성합니다.
• 버킷은 다음 문자열로 끝납니다.

'-d0'

'-c0' 

'-m0'

• 문자열 '-d0'으로 끝나는 버킷이 데이터 세그먼트에 사용됩니다.
• 문자열 '-c0'으로 끝나는 버킷은 구성 데이터에 사용됩니다.
• 문자열 '-m0'으로 끝나는 버킷이 메타데이터에 사용됩니다.
• DDOS 6.1 이전에는 3개의 버킷이 생성되지만 '-d0'으로 끝나는 버킷만 사용됩니다. 그러나 3개의 버킷은 모두 필요합니다. 따라서 제거되지 않도록 주의하여야 합니다.

이전에 생성된 기존 버킷 이름을 사용할 수 있습니까?

• 아니요. 불가능합니다.

하드웨어 요구 사항 외에 LTR을 구성하기 전에 필요한 다른 필수 요구 사항이 있습니까?

• 예
• ECS를 사용하는 경우 로드 밸런서는 필수 요구 사항입니다. 로드 밸런서가 없으면 Data Domain은 단일 노드에서 ECS와 통신하고 여러 요청이 수행되면 연결을 끊습니다.
• DDR과 클라우드 공급업체 간의 1Gb 네트워크

인증서가 필요합니까? 필요한 경우 어떤 인증서를 사용해야 합니까?

• 이는 사용 중인 오브젝트 또는 클라우드 공급업체와 구성에 따라 달라집니다.
• AWS, Virtustream 또는 Azure에는 인증서가 필요합니다. 자세한 내용은 DDOS 관리 가이드를 참조하십시오.
• http 엔드포인트를 사용하여 ECS를 구성하는 경우 인증서가 필요하지 않습니다.
• https 엔드포인트를 사용하여 ECS를 구성하는 경우 인증서가 필요합니다. 로드 밸런서는 필수 요구 사항이므로 필요한 인증서는 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 관점에서 현재 사용량/중복 제거 통계를 표시하는 방법을 개발해야 했습니다.
• 따라서 다음 두 가지 방법 중 하나가 사용됩니다.

1. 클라우드 계층의 크기는 다음과 같이 결정됩니다. CLOUDTIER_CAPACITY license
2. 클라우드 계층의 크기는 구성된 클라우드 유닛 수에 따라 해당 모델 유형에 대한 활성 계층 유닛 크기의 배수로 표시됩니다. 활성 계층 크기에 대한 자세한 내용은 해당 모델의 하드웨어 설치 가이드를 참조하십시오.

클라우드 유닛을 사용할 수 없는 경우 파일 시스템을 시작하려면 어떻게 해야 합니까?

• 파일 시스템이 비활성 상태인지 확인합니다.
• 아래 명령을 사용하여 사용할 수 없는 클라우드 유닛을 비활성화합니다.

cloud unit disable <cloud unit name>

• 파일 시스템을 활성화합니다.

클라우드 유닛이 비활성화된 경우 어떻게 활성화할 수 있습니까?

• 파일 시스템이 비활성 상태인지 확인합니다.
• 아래 명령을 사용하여 클라우드 유닛을 활성화합니다.

cloud unit enable <cloud unit name>

• 파일 시스템을 활성화합니다.

삭제된 클라우드 유닛에 상주하는 파일 시스템에 파일이 여전히 존재하는 이유는 무엇입니까?

•  클라우드 유닛이 삭제되기 전에 파일이 MTree에서 제거되지 않은 경우 해당 파일은 파일 시스템 네임스페이스 내부에 계속 존재합니다.
• 따라서 파일 위치 보고서는 파일이 삭제된 클라우드 유닛의 일부임을 보여줍니다. 예:  

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 Flexible 클라우드 공급업체의 프로토콜 엔드포인트 또는 포트를 변경할 수 있습니까?

• 예를 들어 http에서 https로 변경하거나 반대로 새 로드 밸런서로 마이그레이션하는 경우 이 작업이 필요할 수 있습니다.
• 작성 시점에는 Data Domain 관리자가 이 변경을 수행할 수 있는 방법이 없습니다. 이 기능은 향후 DDOS 릴리스에서 고려될 예정입니다.
• 그러나 지원 또는 엔지니어링 팀에서 이 작업을 수행할 수 있습니다.
• 이 변경을 수행하려면 파일 시스템을 비활성화해야 합니다.
• 이 작업이 필요한 경우 Data Domain 시스템 외부의 모든 구성이 먼저 수행됩니다. 변경된 후에는 파일 시스템이 활성화될 때 업데이트된 프로토콜 또는 포트를 사용하여 통신하고 이전과 같이 버킷 또는 오브젝트를 읽을 수 있어야 하기 때문입니다.