12. 중복제거_분류
중복제거 시기INLINE POST-PROCESS
적은 용량만 있어도
할당 가능
복구시 복원프로세
스 로 인하여 리소스
와 시간 소요
복구 시복구 데이터
가
랜딩존에 있으면 성
능이 좋지만 없으면
inline과 비슷한 낮은
성능
충분한 용량을 갖춘
35. VDO – UDS
Universal Deduplication Service
효율적인 중복 제거 색인을 위한 커널 모듈
4KB 단위 블록들을 해싱한 결과를 기반으로 각 블록들을 색인
논리 블록 번호(LBN)와 물리 블록 번호(LBN)를 매핑하는 블록 맵 페이지를
관리
키-값 쌍 기반의 로그 구조 데이터베이스를 블록 장치에서 관리
37. VDO – UDS 색인
크기를 설정할 수 있으며, 설정된 크기에 따라 필요한 총 메모리/디
스크의 크기가 달라짐
사용될 디스크 크기는 색인의 크기에 따라 자동으로 결정
38. VDO – UDS 색인
희소(Sparse) 색인
• 중복 제거 윈도우 내에서 블록당 약 1/10 바이트만큼의 용량을 요구
• 디스크 상에서 블록당 약 72 바이트만큼의 용량을 요구
밀집(Dense) 색인
• 희소 색인보다 10배 정도 메모리 효율성이 떨어짐
• 하지만 최소 디스크 공간 요구량은 10배 정도 적음
39. VDO – UDS 색인
일반적으로 VDO 볼륨의 물리적 크기의 1/4 정도 크기를 UDS 색
인으로 설정하는 것을 권장
42. VDO – KVDO
다수의 동시 I/O 요청에 대한 비용을 분할 상환하기 위해서 멀티 스레드 기반의 구조
를 사용
하나의 스레드가 I/O 요청을 처음부터 끝까지 처리하지 않음
I/O 요청이 파이프라인을 통과하는 과정에서 전달되는 메시지들을 각기 다른 단계에
있는 하나 이상의 스레드와 스레드 그룹들이 처리
I/O 명령을 처리할 때마다 전역 데이터 자료 구조의 잠금 및 해제를 하지 않고도 모든 접근을 직렬화
43. VDO – KVDO
튜닝이 잘 되어 있다면?
• 스레드가 요청된 처리 단계를 완료할 때마다 같은 처리를 필요로 하는 다른
요청이 대기하고 있게 됨
• 스레드들을 최대한 바쁘게 유지하는 것은 컨텍스트 스위칭/스케줄링의 오
버헤드를 감소시킴
• 블록 장치에 I/O 명령을 수행하거나 UDS로 메시지를 주고 받는 등의 블록
될 수 있는 운영체제 동작은 별도의 스레드에서 구동됨
44. VDO – 커널 스레드의 종류
여러 개일 수 있는 스레드
• 논리 구역 스레드 (Logical zone threads)
• 물리 구역 스레드 (Physical zone threads)
• I/O 제출 스레드 (I/O submission threads)
• CPU 처리 스레드 (CPU-processing threads)
• I/O 통지 스레드 (I/O Ack. threads)
단일로 실행되는 스레드
• 중복 제거 스레드 (Deduplication thread)
• 저널 스레드 (Journal thread)
• 패커 스레드 (Packer thread)
45. VDO – 논리 구역 스레드s
식별자: kvdo:logQ
VDO 장치 사용자에게 제공되는 LBN(Logical Block Number)들과 블록 장치의
PBN(Physical Block Number)들 사이의 매핑을 유지
동일 블록에 대한 쓰기가 동시에 이루어지지 않도록 I/O 명령 간의 잠금을 구현
LBN들은 청크들로 나뉘어지고, 이 청크들은 구역(Zone)으로 그룹화
각 구역은 스레드들이 나누어서 처리
# vdo --name=<NAME> --vdoLogicalThreads=<NUM>
46. VDO – 물리 구역 스레드s
식별자: kvdo:physQ
데이터 블록의 할당 관리와 참조 계수를 유지
PBN은 LBN과 마찬가지로 슬랩(Slab)이라고 불리우는 청크들로 나
뉘어지고, 이 슬랩들은 물리 구역으로 나뉘어져 처리 부하를 분산
시키는 스레드들에게 할당
# vdo --name=<NAME> --vdoPhysicalThreads=<NUM>
47. VDO – I/O 제출 스레드s
식별자: kvdo:bioQ
블록 I/O(bio) 명령을 VDO로부터 블록 장치에 제출
다른 VDO 스레드들이 큐에 삽입한 I/O 요청들을 가져와 블록 장치에 전달
블록 장치와 통신하여 연관된 자료 구조들을 갱신하거나 디바이스 드라이버의 커널 스레드가
처리할 요청들을 준비
블록 장치의 요청 큐가 꽉 차면 I/O 요청의 제출이 봉쇄될 수 있기 때문에, 이러한 처리 지연을
피하기 위해 전용 스레드에 의해서 수행
# vdo --name=<NAME> --vdoBioThreads=<NUM>
48. VDO – CPU 처리 스레드s
식별자: kvdo:cpuQ
해시 계산이나 데이터 블록 압축과 같이 봉쇄되지 않거나 다른 유
형의 스레드들과 연관된 자료 구조의 배타적인 접근을 필요로 하는
등의 CPU 집중적인(CPU-intensive) 작업을 수행
# vdo --name=<NAME> --vdoCpuThreads=<NUM>
49. VDO – I/O 통지 스레드s
식별자: kvdo:ackQ
VDO 위에 있는 모든 대상에게 I/O 요청 완료를 알리는 콜백을 호출
CPU 실행 점유와 메모리 경합은 다른 커널 수준의 코드들에 의존
적
# vdo --name=<NAME> --vdoAckThreads=<NUM>
50. VDO – 중복 제거 스레드
식별자: kvdo:dedupeQ
큐에 삽입된 I/O 요청들을 가져오고 UDS와 통신
서버가 충분히 빠르게 요청을 처리하지 못하거나 다른 시스템 활동
으로 인해 커널 메모리가 제약되면서 소켓 버퍼가 가득 찰 수 있기
때문에 독립적인 스레드로 동작
• 스레드가 봉쇄되더라도 다른 VDO 처리를 계속할 수 있도록 함
지연 시간이 길어지면(기본 5초) I/O 요청을 건너뛰는 만료 시간 메
커니즘이 적용
51. VDO – 저널 스레드
식별자: kvdo:journal
복구 저널을 갱신하고 쓰기를 위한 저널 블록을 스케줄
VDO 장치는 하나의 저널만을 사용하며, 따라서 이 작업은 여러 스
레드들이 수행될 수 없음
52. VDO – 패커 스레드
식별자: kvdo:packerQ
압축이 활성화 되었을 때에만 활성화
쓰기 명령 동안에 동작
공간 낭비를 최소화하기 위해 kvdo:cpuQ 스레드에 의해 압축된
데이터 블록들을 수집
VDO 장치 당 하나의 패커 스레드, 패커 자료 구조
53. A B A
VDO
Logical Volume
/dev/mapper/vdo
Physical Volume
/dev/sdaUDS
A
writeBlock
VDO – 흐름도
B
launchWriteDataVIO startIndexOperation launchAllocatedClientRequest
B
searchIndexZone
UDS
dispatchIndexRequest
B
finishIndexOperation
54. A B A
VDO
Logical Volume
/dev/mapper/vdo
Physical Volume
/dev/sdaUDS
A
VDO – 흐름도
A
launchWriteDataVIO startIndexOperation launchAllocatedClientRequest
B
searchIndexZone
UDS
dispatchIndexRequest
A
finishIndexOperation
73. 관련 이슈 – 성능 – 논리 구역 스레드
일부 접근 패턴에 대해서는 특정 스레드에게 부하가 집중될 수도
있음
• 특정 블록 맵 페이지에 있는 LBN들에 대한 반복적인 접근
논리 구역 스레드 중 하나가 전체 연산을 처리하게 됨
74. 관련 이슈 – 성능 – I/O 제출 스레드
스레드들이 D 상태로 보여진다면?
• VDO가 I/O 요청으로 블록 장치를 자주 사용하고 있음
• 해당 시점에서 스레드 CPU 사용률이 매우 낮다면 I/O 제출 스레드의 개수
를 줄일 수도 있음
CPU 사용과 메모리 경합은 VDO 아래에 있는 블록 장치의 디바이
스 드라이버에 따라 달라질 수 있음
• 더 많은 스레드들이 추가될 때 I/O 요청 당 CPU 사용률이 매우 낮다면 I/O
제출 스레드의 개수를 줄일 수도 있음
75. 관련 이슈 – 성능 – 중복 제거 스레드
만료 시간 설정
• # cat 1000 > /sys/kvdo/deduplication_timeout_interval
만료 시간 타이머의 최소 동작 주기
• # cat 100 > /sys/kvdo/min_deduplication_timer_interval
76. 관련 이슈 – 성능 – 캐시
블록 맵 페이지 캐시
• # vdo [create|modify] --name=<NAME> --
blockMapCacheSize=[128M-16T]
• # vdo [create|modify] --name=<NAME> --blockMapPeriod=[1-
16380]
• 읽기 캐시
• # vdo [create|modify] --name=<NAME> --
readCache=[enabled|disabled]
• # vdo [create|modify] --name=<NAME> --readCacheSize=[0-
<MAXMEM>]
• 읽기 캐시의 총 메모리 사용량은 --vdoBioThreads x --readCacheSize
77. 관련 이슈 – 서비스 종료
색인을 저장하는 과정으로 인해 종료가 느려질 수 있음
블록 장치의 속도/크기에 따라 종료 속도가 상이
• 볼륨은 UDS 색인의 1GiB마다 1GiB 정도를 디스크에 저장
• 희소 색인의 경우 블록 맵 페이지 캐시 크기 + 슬랩 당 8MiB를 디스크에 저장
78. 관련 이슈 – 결함 복구
동기 종료 직전까지 VDO가 저널링한 모든 쓰기가 다시 수행
비동기 가장 최근에 수행한 FLUSH/FUA 이전에 저널링한 모든 쓰기가 다시 수행
비정상 종료 후 복구 시
• 메타데이터의 일관성 유지를 위해 재구성을 수행하며 필요에 따라 복구를 수행
• 동기/비동기 모드에 따라 복구 기준이 다름
79. 관련 이슈 – 결함 복구
온라인 복구는 가능하지만 복구 중에 쓰여진 데이터들이 중복 제거가
되지 않을 수도 있음
• 복구 중에 쓰기 발생 시, 아직복구되지 않은 슬랩에 해당 데이터가 있다면
중복 제거가 되지 않을수도 있음
• 또한, 복구되지 않은 슬랩을 참조하는 입출력이 있다면 가용량이 정상일 때보다
증가할 수있음
80. 관련 이슈 – 결함 복구
복구가 실패할 경우에는 읽기 전용으로 마운트됨
• 이 경우, 오프라인 상태에서 강제로 메타데이터를 다시 빌드하여 온라인으로
전환 가능하지만 데이터 유실 위험이 있으므로 주의!
# vdo stop --name=vdo_name
# vdo start --name=vdo_name --forceRebuild
81. 관련 이슈 – 결함 복구
복구 중에는 아래와 같은 통계 정보를 확인할 수 없음
• 사용 중인 블록 개수
• 유휴 블록 개수
82. 관련 이슈 – 유휴 공간 회수
실시간(Inline) 회수
• 파일 시스템 마운트 옵션의 discard가 이에 해당
• 사용자가 파일을 삭제할 때마다 블록 장치 계층에 REQ_DISCARD를 요청
• 다른 색인에 대한 참조가 없다면 공간을 해제하여 유휴 공간으로 회수
일괄(Batch) 회수
• fstrim 유틸리티가 이에 해당
• 사용자 영역에서 ioctl의 FITRIM(Filesystem Independent TRIM) 명
령을 통해 파일 시스템이 사용되지 않는 블록 공간을 알리게 함으로써 시작됨.
파일 시스템 상에서 회수
83. 관련 이슈 – 유휴 공간 회수
파일 시스템 상에서 회수
• DISCARD/TRIM/UNMAP과 같은 명령을 지원하지 않는 파일시스템에 대해 수
동으로 유휴 공간을 회수하려면?
• 0으로 채워진 파일을 저장하고 난 뒤에 그 파일을 삭제
• /sys/block/<DEVICE>/queue/discard_max_bytes의 값이 0이 아니
라면 지원
84. 관련 이슈 – 유휴 공간 회수
blkdiscard ioctl(fd, {BLKZEROOUT|BLKSECDISCARD|BLKDISCARD}, &range)
REQ_DISCARD
LVM 등과 같이 REQ_DISCARD를 하위 계층으로 전달해주는 기능이 있는 볼륨 관
리자
UNMAP SCSI 장치 명령
TRIM ATA 장치 명령
파일 시스템을 사용하지 않는 경우의 회수
(예: 블록 스토리지 타겟, VDO 위에 LVM 등)
85. 관련 이슈 – 유휴 공간 회수
파이버 채널(Fibre Channel)이나 이더넷 네트워크(LIO 등) 상에서 회수
• UNMAP: SCSI 초기자(Initiator)
• SCSI 대상(Target)에서 명령 지원 여부를 알려줄 수 있어야 함
• 지원 여부 확인
# sg_vpd --page=0xb0 /dev/<DEVICE>
...
Maximum unmap LBA count: ??? < 0
잠시 본격적인 시작에 앞서
(흥미 유발)
코끼리를 냉장고에 넣는 방법 이라는 주제에 대해 들어보신적 있으신가요
여러학문에서 다양한 의견이 나온 주제였는데요
IT 계열이라면 코끼리 클래스를 만들어서 냉장고 클래스에 넣는 방법을 가장 많이 떠올린다고 합니다.
하지만 이런 이론적인 방법이 아니라
그런데 만약 코끼리를 냉장고에 넣을 수 있는 방법이 있다면 어떨까요
마찬가지로
2T 데이터를 1T 디스크에 넣을 수 있다면 어떨까요
그 방법은 중복제거라는 기술입니다.
중복제거는 데이터를 블록 단위나 데이터스트림단위로 분해하여 중복 되는 부분을 줄여 실제 저장되는 데이터를 줄일 수 있기 때문에
2T 데이터를 1T디스크에 넣는 방법이 가능해집니다.
중복제거에서는
개념, 분류, 활용 순서로 설명하겠습니다
먼저 원본 데이터가 들어오면 블록사이즈로 작게 분해합니다.
분해된 블록들 중에 같은 블록을 식별한 후에
유니크한 블록만 저장하는 기술입니다.
중복제거는 크게
위치 방식 단계 시기에 따라 분류합니다
위치에 따라
타겟과 소스
타겟 : 중복제거를 수행하는 곳이 백업스토리지 일경우 이고
소스 : 백업 데이터가 있는 공간에서 중복제거를 수행할 경우 입니다.
타겟은 소스와 관계 없이 같은 소프트웨어를 사용할 수 있다거나 대부분의 백업 소프트와 호환된다는 장점이 있지만
소스 중복제거에 비하여 많은 대역폭을 사용하게 됩니다.
소스는 타겟으로 전송되는 데이터양을 크게 감소 시킬 수 있지만 그만큼 소스의 CPU리소스를 많이 소모하고 복구속도가 느리다는 단점
방식에 따른 분류는 고정 블록과 가변블록
고정블록은 단순한알고리즘으로 상대적으로 빠른 속도의 성능을 지니고있지만 고정된 길이의 블록을 사용하기 때문에 데이터 유형에 따라 효율이 떨어질 수 있다
가변블록은 블록사이즈를 유연하게 조정하여 높은 중복제거율을 갖지만
그만큼 청크의 길이파악이나 해시계산등의 소요로 CPU와 메모리 리소스 부하가 높다
중복제거 단계에 따라 글로벌과 로컬로 분류
글로벌은 여러 개의 타겟이나 소스에 중복없이 백업을 한다
로컬은 각 장치 내에서만 중복제거를 하는 방식입니다.
글로벌은 여러 소스,타겟 장치에 중복되는 데이터 없이 나누기 때문에 높은 중복제거율을 보이지만
대용량 데이터를 필요로 하지 않는 경우에는 이점이 사라지게 됩니다
로컬은 쉬운 접근성으로 인하여 글로벌보다 높은 성능을 갖지만 상대적으로 낮은 중복제거율을 갖게됩니다.
중복제거가 되는 시점에 따라
인라인 : 데이터 전송시 중복 제거 후에 디스크에 기록
포스트 프로세스: 임시 영역에 보관하여 중복제거후 디스크에 기록
인라인 – 별도의 공간이 필요 없어서 적은 용량만 있어도 할당 가능하지만 복구시에 복원 프로세스로 리소스와 시간이 소요된다
포스트 프로세스 – 복구시 랜딩 존에 복구데이터가 있을 경우 좋은 복구성능이 나오지만 반대로 랜딩존에 없을 경우에는 Inline과 비슷한 낮은 성능이 나온다
중복제거 기술은 보통
아카이빙 스토리지나, 백업, 가상머신등에 많이 사용됩니다.
앞서 소개드린 중복제거를 보유한 많은 파일시스템 이나 소프트웨어등이 있겠지만 오늘은 그중에
VDO를 소개하려고합니다
중복제거는 앞에서 말씀드린 중복제거와 같지만 VDO에서는 4KB 고정 블록 사이즈와
Hash를 이용합니다
Hash는 murmur해시를 사용하는데
murmur해시는 어떤 해시입니다
씬프로비저닝은 스토리지를 유연하게 할당하여 실제 공간을 좀더 효율적으로 사용할수 있는 기능
압축은 블록 수준의 인라인 압축인 HIOPS압축을 지원하는데
병렬화된 알고리즘으로 다수의 압축 작업을 한번에 처리하는 압축입니다.
로그 파일 및 데이터베이스와 같이 블록 레벨 중복성을 나타내지 않는 구조적/비구조적 형식에 효율적
중복으로 식별되지 않은 블록에 대해 동작 (처음 중복으로 간주되지 않은 블록에 대해)
우선 저장 후에 요청 응답한 뒤 단일 블록 내에 들어갈 수 있는 블록들을 찾아서 일괄 압축하여 처리
압축에 대한 지연 시간 패널티를 최소화
VDO에서의 중복제거율은 데이터유형과 어떤작업인지에 따라 달라지는데
비디오나 오디오 같이 압축된 데이터 유형에서의 중복제거율은 낮지만
온라인 백업, 가상머신, 컨테이너 배포 등에서는 높은 중복제거율을 보입니다.
사용법에 앞서 VDO를 생성할 수 있는 일반적인 구조에 대해 설명드리겠습니다.
VDO는 기본적으로 Block device위에 생성합니다.
VDO를 생성한 후에 바로 Filesystem 포맷을 할 수도 있고,
저희가 평소에 사용하는 LVM 을 사용해서 pv, vg, lv형태로 구성할 수도 있습니다.
마찬가지로 LVM 위에 다른 파일시스템을 올리는것도 가능합니다.
멀티패스 DM-Crypt 소프트웨어레이드 위에 VDO를 구성하거나
VDO위에 씬프로비저닝, LVM 캐시, LVM스냅샷을 구성하는것도 가능합니다
하지만 구성을 하면 안되는 경우도 있는데요
방금 말씀드린 스냅샷이나 캐시 그리고 루프백장치 위에 VDO를 구성하는 경우에는
VDO 측에서 아직 명확한 테스트가 진행되지 않아서 구성을 권장하지 않고있습니다
씬프로비저닝 위에 VDO를 구성하는 경우에는
Discard 문제로 데이터중복제거를 못하기때문에 이득이 없기 때문에 권장하지 않고
비슷하게 VDO위에 DM-Crypt를 구성하는 방법도
암호화된 데이터는 공간절약에 대한 이득이 없기 때문에 지원하지 않습니다
VDO위에 LVM을 구성하고 또 다시 VDO를 구성하는 반복적인 구조에서는
공간 사용량 정보나 쓰레딩 문제로 지원하지 않습니다
VDO위에 레이드를 구성하거나 VDO볼륨을 파티션을 구성하면
정렬되지 않는 블록이 생기게 되고 그로인하여 공간을 절약하는데 큰영향을 줘서 지원하지 않습니다
VDO 구조
VDO는 kvdo uds vdo부분으로 나뉘는데
kvdo는 lvm이나 softwareRaid같이 D-M 레벨에서 핸들링
uds는 중복제거 색인 부분에 대해서 관리
vdo는 유저 스페이스에서 vdo장치를 관리 모니터링 한다.
VDO는 블록 저장 장치에서 볼륨을 생성 할 때 장치를 내부적으로 두 부분으로 나눕니다.
UDS 부분 : VDO 볼륨을 만들 때 추가 용량을 명시 적으로 지정하지 않으면이 부분의 크기가 고정됩니다. 중복 제거 권고가 VDO 장치에 의해 UDS 드라이버에 요청 된 것으로 보이는 각 블록의 고유 이름과 위치를 저장하는 데 사용됩니다.
VDO 부분 : VDO 부분은 VDO가 사용자 데이터 및 관련 메타 데이터를 추가, 삭제 및 수정하는 데 사용하는 공간입니다.
29.1.1. UDS 커널 모듈 ( uds)
UDS 색인은 VDO 제품의 기초를 제공합니다. 새로운 각 데이터에 대해 해당 데이터가 이전에 저장된 데이터와 동일한 지 신속하게 판별합니다. 인덱스가 일치하면 스토리지 시스템은 동일한 항목을 두 번 이상 저장하지 않도록 기존 항목을 내부적으로 참조 할 수 있습니다.
UDS 색인은 커널 내부에서 uds커널 모듈 로 실행됩니다 .
UDS는 효율적인 중복제거색인을 위한 커널 모듈이다
앞서 말씀드렸다싶이 4kb의 고정블록들을 해싱하여 색인을 만듭니다
또
색인을 사용하여 데이터를 관리하기 위해
LBN과 PBN을 맵핑하는 블록 맵페이지나 키밸류 쌍의 데이터베이스를 블록장치에서 관리합니다.
uds 내부구조
고유 블록당 최대 하나의 엔트리를 포함하는 메모리 자료구조 = delta master index
해당 색인과 연관되는 블록들의 이름을 기록하는 디스크 자료 구조 = uds volume
디스크상의 자료구조는 UDS에 전달된 데이터의 내역을 관리
uds index메모리 요구사항
최소 250M 의 메모리 필요
델타 마스터 인덱스
새로운 중복항목을 신속하게 감지
고유한 압축 양식은 활성항목당 오직 3바이트만 사용
희소 인덱싱으로 10의 미디어 적용
5 usec 평균 대기 시간
uds 볼륨
키-밸류의 로그 구조 디비
데이터 지역성을 위한 조직
캐시하지 않을 때 리커 버드를 찾기위한 최대 2 개의 읽기
빠른 조회를 위한 64k 페이지 캐시
작은 메모리케시에서 98%이상의 캐시 적중률
희소색인은 띄엄띄엄 존재해서 더 많은 블록을 관리하는 색인
밀집색인은 밀집되어 관리하는 색인인데
UDS의 구조 설명부분 추가
블록 맵 페이지: 약 3MB의 LBN들을 포함
모든 대상: 커널 페이지 캐시, 다이렉트 I/O를 하고 있는 애플리케이션 프로그램 스레드 등
B 흐름 생성 부분은 flash summit에 있는 자료 활용해서 어떤식으로 생성된다.
VDO 중복제거 흐름도를 간략하게 표현한것인데요
중복제거 부분에서는 ~~~~와 같이 동작합니다.
아래 플로우는 uds내부에서 수행되는 작업인데……
uds 부분에서 murmur 해시를 호출하는부분을 브리프하게 추적
알고리즘 파악
uds할때 코드 팝업느낌으로 출력
murmur 해시부분이 블록 디바이스로 들어가는 부분이 아닌것 같다???
생성 부분은 flash summit에 있는 자료 활용해서 어떤식으로 생성된다.
VDO 중복제거 흐름도를 간략하게 표현한것인데요
중복제거 부분에서는 ~~~~와 같이 동작합니다.
아래 플로우는 uds내부에서 수행되는 작업인데……
uds 부분에서 murmur 해시를 호출하는부분을 브리프하게 추적
알고리즘 파악
uds할때 코드 팝업느낌으로 출력
murmur 해시부분이 블록 디바이스로 들어가는 부분이 아닌것 같다???
사용법에 앞서 VDO를 생성할 수 있는 일반적인 구조에 대해 설명드리겠습니다.
VDO는 기본적으로 Block device위에 생성합니다.
VDO를 생성한 후에 바로 Filesystem 포맷을 할 수도 있고,
저희가 평소에 사용하는 LVM 을 사용해서 pv, vg, lv형태로 구성할 수도 있습니다.
마찬가지로 LVM 위에 다른 파일시스템을 올리는것도 가능합니다.
생성 구조
vdo를 생성구조입니다
