인프라 일기 : FileSystem (ZFS vs LVM-thin)
개발 일기 1편
[ 파일 시스템의 가상화 ]
일반적인 파일 시스템은 디스크와 1:1 이다!
기본적인 구조는
- 물리적 파티션 (/dev/sda1)
- 파일 시스템 (XFS)
즉 책장 하나에, 그 책장에 대한 설명서이자 검색 시스템이 하나만 존재하는 구조
그럼 뭐가 문제냐
- Silent Data Corruption (데이터 오염)
파일 시스템은 “aaa책이 책장 1열 4번째 칸에 있다”라는 정보를 갖고 있지만
실제 동작은 디스크 컨트롤러에서 하기 때문에 손상 여부를 알 수 없음
⇒ 즉 해당 파일을 가져와 열기 전까지, 하드디스크의 자성 문제 등으로 인해, 0이어야 하는 값이 1이 되어있을 지 등에 대한 내부 데이터 손상 정보는 모름!
- Storage Pooling 불가능
1:1 구조이기 때문에, 여러 물리적 파티션을 묶어 더 큰 공간을 사용하려고 하면, 별도의 시스템 컨트롤러 자원이 필요 (like RAID)
RAID는 복구 시스템 아닌가?
해당 동작을 위해서는 여러 물리적 파티션에 대한 복합 처리가 가능해야 하므로,
실제 파일시스템에는 3GB의 큰 책장이라고 알려주고, RAID에서 3개의 큰 책장에 대한 분할 관리를 함 그래서 여유 공간이 1GB 1GB 1GB인 3개의 책장에 2GB의 데이터가 들어와도 처리가 가능
추가로, 3GB를 4GB로 늘리려면 파일 시스템을 재조정 필요
= 실시간으로 용량을 늘리고 줄이는 과정이 불가능
[ 가상화 기술 LVM vs ZFS]
LVM (Logical Volume Manager)은 가상 메모리와 너무 유사하다
⇒ 물리 HW - LVM - 파일시스템의 Layered 구조이다!
따라서 표로 정리한 부분만 남겨 놓도록 하겠다
| 항목 | 가상 메모리 (RAM 관리) | LVM (디스크 관리) |
| 실제 물리 공간 | PA (Physical Address) | PV (Physical Volume) |
| 최소 분할 단위 | Page (페이지) | PE (Physical Extent) |
| 번역/매핑 장치 | Page Table | Device Mapper |
| 가상/논리 공간 | VA (Virtual Address) | LV (Logical Volume) |
LVM-thin : 오버부킹!
더 많은 영역을 할당 → 조정을 용이하게!
ZFS (Zettabyte File System)는 뭘까?
기존 LVM은 (물리 디스크 - Logical Volume)을 고정크기로 할당하는 방식이다!
따라서 수정 과정이 복잡하다
(/home , /db) ⇒ home을 줄이고, db를 더 많이 할당하고 싶을 때
/home파일 시스템을 줄이고
- LVM 볼륨을 줄인 뒤
- 다시
/db볼륨을 늘리고
/db파일 시스템을 확장
⇒ 위험하고 번거로운 작업
ZFS는 디스크를 묶어 zpool(거대한 스토리지 풀) [쪼개지 않음]
가상파티션을 만들지 않고, dataSet을 형성
- dataSet은 크기가 0
- 하나의 dataSet이 1TB를 사용하고자 하면
- zpool의 크기가 1TB 감소
- 남은 공간은 자연스럽게 공유
⇒ Linux의 sharedMemory와 유사한 개념!
결과적으로 ZFS는 (파일시스템 + 볼륨 매니저)가 합쳐진 형태!
- CoW중에 문제가 발생하면? → 그래도 데이터 손상이 없다
- ZFS는 A구역 데이터 중 수정이 필요한 데이터를 B구역에 복사하고, 수정을 시작
- 이후에 UberBlock(최상위 장부)이 주소를 A → B로 수정 (1 Tr)
- 따라서 마지막 과정이 정상적으로 끝나지 않으면 공간은 소비될 지 언정 포인터가 바뀌지 않아 기존 파일 시스템 유지
