Data Domain: DDR(Data Domain Restorer)의 장기간 보존/클라우드 계층 정리/가비지 컬렉션 소개

DDOS(Data Domain Operating System) 6.0에는 클라우드 보존 또는 LTR(Long Term Retention)이라는 새로운 기능이 도입되었습니다. 이 기능을 사용하면 클라우드 공급업체가 프로비저닝한 오브젝트 기반 스토리지의 두 번째 계층을 관련 CLOUD_CAPACITY 라이선스와 함께 특정 DDR(Data Domain Restorer) 모델에 추가할 수 있습니다.

LTR을 사용하는 시스템에서 DDR에 의해 수집된 파일은 처음에 활성 계층(로컬에 연결된 스토리지)에 기록됩니다. 그런 다음 데이터 이동 정책/기간 임계값을 각 MTree 기준으로 구성하여 장기간 보존이 필요한 특정 파일이 나중에 데이터 이동 프로세스(정기적으로 예약된 작업)를 통해 활성 계층에서 클라우드 계층으로 마이그레이션되도록 합니다.

클라우드 계층의 파일은 정상적으로 삭제할 수 있지만 클라우드/오브젝트 스토리지의 관련 공간은 즉시 사용할 수 있도록 재확보되지 않습니다. 클라우드에서 불필요한 데이터를 제거하려면 클라우드 계층을 정리해야 합니다.

클라우드 계층의 구조:

클라우드 계층은 '클라우드 유닛'으로 세분화됩니다. 참고:

• 클라우드 계층에는 최대 2개의 클라우드 유닛이 포함될 수 있습니다.
• 각 클라우드 유닛은 지정된 DDR 모델에 대해 지원되는 최대 활성 계층 크기만큼 클 수 있습니다.
• 각 클라우드 유닛은 서로 다른 오브젝트 스토리지 공급자가 프로비저닝할 수 있습니다.

예시:

# cloud unit list
Name                      Profile        Status
-----------------------   ------------   ------
B-unit                    LTR-ECS-Ben    Active <=== ECS provider
cloud-unit-virtustream1   virtustream1   Active <=== Virtustream provider
-----------------------   ------------   ------

클라우드 정리의 기본 개념:

• 클라우드 정리는 각 실행 중에 단일 클라우드 유닛에 대해서만 작동합니다. 정리 중인 클라우드 유닛을 확인하기 위해 DDFS 로그(/ddr/var/log/debug/ddfs.info)에서 다음 메시지를 찾을 수 있습니다. 이 경우에는 cloud-unit-virtustream1 클라우드 유닛이 정리 중입니다.

• 시스템에 여러 클라우드 유닛이 구성된 경우 클라우드 정리는 이러한 유닛을 라운드 로빈 방식으로 정리하여 클라우드 정리가 실행될 때마다 단일 유닛을 정리하려고 시도합니다.
• 클라우드 정리는 일정에 따라 자동으로 또는 수동으로 시작할 수 있습니다. 수동으로 시작하려면 다음 명령을 사용합니다.

• 활성 계층 정리와 클라우드 정리를 동시에 실행할 수는 없습니다. DDFS 내에서 동일한 메모리 구조를 사용하기 때문입니다.
• 활성 계층 정리가 실행 중인 경우(수동으로 또는 일정에 따라 시작됨) 클라우드 정리를 시작하려고 하면 다음과 같은 오류가 발생합니다.

• 클라우드 정리가 자동으로(즉, 일정에 따라) 시작된 경우 활성 계층 정리가 시작되면 활성 계층 정리가 실행될 수 있도록 클라우드 유닛 정리가 중단됩니다. 이는 DDFS 로그에 다음과 같이 표시됩니다.

• 클라우드 정리가 수동으로 시작된 경우 활성 계층 정리를 시작하려고 하면 활성 계층 정리가 시작되지 않습니다. 클라우드 정리는 다음과 같이 완료될 때까지 실행됩니다.

• 클라우드 정리를 시작하려면 클라우드 유닛에서 최소 1%의 데이터 '이탈'이 발생해야 합니다. 즉, 현재 클라우드 유닛에 있는 데이터의 >= 1%가 불필요하여 제거 가능한 것으로 간주되어야 합니다. 그렇지 않은 경우 클라우드 정리를 수동으로 시작하면 명령줄에 다음이 표시됩니다.

• 시스템에 두 개의 클라우드 유닛이 포함되어 있고 어떤 이유로(예: 불충분한 이탈) 첫 번째 유닛의 예약된 정리가 실패하는 경우 두 번째 유닛에 대해 자동으로 정리 시작을 시도합니다(즉, 정리할 두 번째 유닛의 다음 예약된 클라우드 정리 실행을 기다릴 필요가 없음).
• 클라우드 정리는 시스템에 상당한 다른 워크로드(예: 수집/복원/복제)가 가해질 때 어떤 조치를 취해야 하는지 결정하기 위해 조절이 가능합니다(활성 계층 정리와 유사).

클라우드 정리 예약:

DDOS 6.0 이상에서는 활성 계층 정리가 예약되는 방식이 변경되지 않았습니다. 기본적으로 활성 계층 정리는 다음과 같이 일주일에 한 번 화요일 06:00에 실행되도록 예약됩니다.

# filesys clean show schedule
Filesystem cleaning is scheduled to run "Tue" at "0600".

클라우드 정리는 기본적으로 예약된 활성 계층 정리를 4회 호출할 때마다 실행되도록 예약됩니다. 클라우드 정리 일정을 표시하려면 다음 명령을 사용해야 합니다.

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

따라서 기본 구성으로 설정된 시스템에서는 클라우드 정리가 4주마다 시작됩니다. 시스템에 클라우드 유닛이 2개인 경우 각 유닛은 8주마다 한 번씩 정리됩니다.

클라우드 정리 빈도를 변경하려면 다음 명령을 사용하면 됩니다.

# cloud clean frequency set 2
Cloud tier cleaning frequency is set to run after every 2 active tier cleaning cycles.

클라우드 정리를 기본 일정인 활성 계층 정리 4회마다로 재설정하려면 다음 명령을 사용하면 됩니다.

# cloud clean frequency reset
Cloud tier cleaning frequency is reset to default (every 4 active tier cleaning cycles).

수동으로 시작된 활성 계층 정리 주기는 클라우드 정리 일정에 포함되지 않습니다. 따라서 위의 시스템에서는 활성 계층 정리를 매일 수동으로 실행하더라도 클라우드 계층 정리는 4주에 한 번만 시작됩니다.

다음 명령을 사용하여 예약된 클라우드 정리를 완전히 비활성화할 수도 있습니다.

# cloud clean frequency set never
Cloud tier cleaning frequency is set to "never".

이 경우 클라우드 정리는 수동으로 시작할 때만 실행됩니다.

현재 실행 중인 클라우드 정리를 중지하려면 다음 명령을 사용하면 됩니다.

# cloud clean stop

클라우드 정리가 언제 마지막으로 실행됐는지 확인하려면 다음 명령을 사용하면 됩니다.

# cloud clean status
Cloud tier cleaning finished at 2016/08/01 20:54:43.

클라우드 정리 알고리듬:

클라우드 정리에는 활성 계층에 대해 구성된 것과 동일한 정리 알고리듬이 사용됩니다. DDOS 6.0 이상에서는 기본적으로 PPGC(Perfect Physical Garbage Collection)가 사용되지만 시스템 매개변수를 통해 PGC(Physical Garbage Collection)로 변경할 수 있습니다.

기존/전체 정리 알고리듬을 사용하여 클라우드 유닛을 정리하면 DDFS 패닉/재시작이 발생할 수 있으므로 물리적 가비지 컬렉션을 비활성화해서는 안 됩니다.

클라우드 정리에 사용되는 알고리듬은 정리가 시작될 때 다음과 같이 DDFS 로그에 표시됩니다.

06/28 10:51:56.960 (tid 0x7fc5bccb2d50): gc: gc_start_intern: Algorithm selected: Physical Cleaning <=== PPGC or PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): gc: gc_start_intern: Algorithm selected: Full Cleaning <=== Traditional GC

위의 출력에서는 PPGC와 PGC를 구별할 수 없습니다. 사용된 특정 알고리듬은 정리에서 실행되는 단계 수로 인해 명확해집니다. 일반적으로 다음과 같습니다.

기존/전체 GC: 10단계
PGC: 12단계
PPGC: 6단계

시스템에서 사용되는 정리 알고리듬 변경에 대한 자세한 내용은 계약된 지원 공급업체에 문의하십시오.

활성 계층 정리 단계와 클라우드 계층 정리 복제 단계 간의 차이점:

정리의 복제 단계는 DDR의 불필요한 데이터가 물리적으로 제거되고 공간이 재확보되는 단계입니다. 활성 계층과 클라우드 계층에 대해 복제 단계가 작동하는 방식에는 차이가 있습니다.

활성 계층:

• DDR의 활성 계층에 기록된 데이터는 4.5Mb 컨테이너 내에 포함됩니다.
• 기본적으로 컨테이너는 <= 92% '라이브'(즉, 적극적으로 참조되는) 데이터가 포함된 경우에만 정리를 통한 '복제' 대상으로 간주됩니다.
• 라이브 데이터는 컨테이너에서 추출되어 다른 복제된 컨테이너의 라이브 데이터와 함께 파일 시스템 끝에 있는 새 컨테이너에 기록됩니다.
• 디스크 인덱스는 라이브 데이터를 보관하는 새 컨테이너를 반영하도록 업데이트됩니다.
• 원래 컨테이너(라이브 데이터와 비활성 데이터를 모두 보관)는 삭제되고 기본 디스크 공간이 사용 가능하게 됩니다.

클라우드 계층:

• DDR의 클라우드 계층에 기록된 데이터는 다르게 구성됩니다. 4.5Mb 컨테이너 내에 배치되는 대신 개별 데이터 청크(64Kb 압축 영역)가 클라우드 유닛에 기록됩니다(참고: DDOS 6.1.2.0 이상에서는 클라우드 유닛에 저장된 오브젝트가 더 커집니다. 자세한 내용은 Data Domain: Large Object Size for Cloud Tier 참조).
• 기존 압축 영역에서 라이브 데이터를 추출하고 이를 복제하는 대신 클라우드 정리는 삭제할 비활성 데이터만 포함하는 압축 영역만 고려합니다.

이러한 차이는 클라우드 스토리지에서 대량의 데이터를 읽고 쓰는 데 드는 고유한 비용 때문에 발생하지만, 클라우드 유닛이 인위적으로 가득 차게 될 수 있습니다(즉, 각각 매우 적은 양의 라이브 데이터가 포함되어 있어 제거가 불가능한 많은 압축 영역이 포함됨).

이러한 상황이 클라우드 유닛의 '조각 모음 정리'를 강제로 실행하도록 시스템 매개변수를 설정할 수 있습니다. 이렇게 하면 기존 압축 영역의 라이브 데이터를 복사해 가능한 한 적은 압축 영역에 라이브 데이터를 통합하여 공간을 확보할 수 있습니다.

'조각 모음 정리' 실행에 대한 자세한 내용은 계약된 지원 공급업체에 문의하십시오.