되돌릴 길을 먼저 만든다 — LVM 스냅숏·파일시스템 선택·씬 프로비저닝

한 줄 요약

변경 직전에 뜬 LVM 스냅숏은 "되돌릴 수 있다" 를 몇 초 만에 만든다. 대신 스냅숏은 공간이 차면 쓸모가 없어지고, 백업이 아니며, 원본과 같은 디스크에 산다. 파일시스템은 처음 고를 때 줄일 수 있는가를 함께 봐야 하고, 씬 프로비저닝은 있지도 않은 공간을 약속하는 일이라 감시가 딸려 온다.

왜 이게 필요했나

패키지 업그레이드, 설정 파일 대량 수정, 스키마 변경 같은 작업은 "잘못되면 되돌린다" 를 전제로 승인된다. 그런데 되돌리는 방법이 "백업에서 복원" 뿐이면 한 시간이 걸리고, 그 사이 새로 들어온 데이터는 잃는다. 작업 직전에 볼륨의 모습을 순간적으로 고정해 두었다가 실패하면 그 순간으로 돌아가는 수단이 필요했다. 그것이 스냅숏이다.

또 하나. 볼륨을 넉넉히 잡았다가 다른 볼륨에 공간이 필요해지는 일은 흔하다. 그때 "줄일 수 없는 파일시스템" 을 골라 두었다면 선택지는 새로 만들고 옮기는 것뿐이다. 파일시스템 선택은 처음 한 번에 결정되고 오래 간다.

어떻게 동작하나

COW 스냅숏. lvcreate(8) 의 -s 는 원본 LV 의 스냅숏을 만든다. 만드는 순간에는 아무것도 복사하지 않는다. 이후 원본의 어떤 블록이 처음 바뀔 때 옛 내용을 스냅숏 공간으로 옮겨 두는 copy-on-write 방식이다. 그래서 스냅숏의 크기(-L)는 원본 크기가 아니라 "스냅숏을 두는 동안 바뀔 양" 에 맞춘다. lvs 의 Data% 열이 그 공간을 얼마나 썼는지 보여 주는데, 100% 에 닿으면 스냅숏은 무효가 되어 버려진다. 큰 작업 중에 스냅숏이 조용히 무효가 되면 되돌릴 길이 없어진 줄도 모르고 작업을 계속하게 된다.

되돌리기는 병합이다. lvconvert(8) 의 --merge 는 스냅숏의 내용을 원본에 되돌려 쓰고 스냅숏을 없앤다. 원본이 열려 있으면(마운트돼 있으면) 병합은 다음 활성화 때까지 미뤄지므로, 작업 계획서에는 "마운트 해제 → 병합 → 다시 마운트" 순서로 적는다. 병합이 끝나면 스냅숏 LV 는 목록에서 사라진다.

스냅숏은 백업이 아니다. 원본과 같은 VG, 대개 같은 디스크에 산다. 디스크가 죽으면 원본과 스냅숏이 함께 사라진다. 그리고 COW 스냅숏이 붙어 있는 동안 원본의 첫 쓰기마다 복사가 한 번 더 일어나 쓰기가 느려진다. 그래서 스냅숏은 작업 창 동안만 두고 끝나면 지운다.

파일시스템을 고를 때 볼 것. 둘 다 저널링 파일시스템이고 둘 다 마운트된 채로 늘릴 수 있다. 차이는 줄일 때 난다.

	ext4	XFS
온라인 확장	resize2fs	xfs_growfs (마운트 상태에서만)
축소	마운트 해제 후 resize2fs 로 가능	지원 범위 밖으로 보고 설계한다 — 새로 만들고 옮긴다
흔한 기본값	데비안·우분투	RHEL 계열

resize2fs(8) 는 마운트된 ext4 를 키울 수 있고, 줄이는 것은 마운트를 푼 상태에서만 한다. xfs_growfs(8) 는 이름 그대로 키우는 도구다. 최근 xfsprogs 에 마지막 할당 그룹의 빈 공간만 줄이는 실험 기능이 들어왔지만, 운영 설계에서는 "XFS 는 줄이지 못한다" 를 전제로 둔다.

줄일 때는 순서가 목숨이다. 파일시스템을 먼저 목표보다 작게 줄이고, 그다음 LV 를 줄이고, 마지막으로 파일시스템을 LV 크기에 다시 맞춘다. LV 를 먼저 줄이면 파일시스템의 끝부분이 잘려 나간다. lvreduce -r 은 이 과정을 fsadm 에 맡겨 한 번에 하지만, 무엇이 일어나는지 알고 써야 한다.

씬 프로비저닝. lvmthin(7) 의 씬 풀은 실제 공간을 가진 풀이고, 씬 볼륨은 그 풀에서 쓸 때 공간을 받는다. 그래서 400MiB 풀 위에 1GiB 씬 볼륨을 만들 수 있다. 이것이 과할당(overprovisioning)이다. 여러 볼륨이 전부 가득 차지는 않는다는 통계에 기대는 것이고, 가상화의 메모리 오버커밋과 같은 거래다. lvmthin(7) 은 풀이 가득 차면 쓰기가 멈추거나 오류가 된다고 경고하고, 풀 사용률을 감시하다 자동으로 늘리는 설정(thin_pool_autoextend_threshold)을 설명한다. 풀을 늘릴 VG 여유가 없다면 그 설정도 소용없다.

현장에서 만나는 모습

변경 작업 계획서의 "사전 작업" 칸에 스냅숏이 들어가는 팀이 많다. 좋은 계획서는 스냅숏 크기의 근거(작업이 바꿀 양의 추정)와 "스냅숏 사용률이 몇 %를 넘으면 중단" 이라는 기준까지 적는다. 작업이 끝나면 스냅숏을 지우는 줄도 적는다. 지우는 것을 잊은 스냅숏이 몇 주 뒤 100% 가 되어 무효가 되거나, 쓰기 성능을 계속 깎고 있는 경우가 흔하다.

"이 볼륨을 반으로 줄여 옆 볼륨에 주자" 는 요청이 XFS 앞에서 멈추는 일도 자주 본다. RHEL 계열 기본값이 XFS 라 설치할 때 아무 생각 없이 고르기 때문이다. 줄일 가능성이 있는 볼륨이라면 처음부터 ext4 로 가거나, 넉넉히 잡지 말고 작게 시작해 늘리는 쪽으로 설계한다.

다음 실습에서 할 것

3GiB 루프 장치로 VG vg_sto 를 세우고, XFS 볼륨 lv_app 에 설정 파일과 주문 파일을 둔다. 스냅숏을 뜬 뒤 일부러 틀린 변경을 하고, 스냅숏 사용률을 기록한 다음, 병합으로 되돌린다. 이어서 XFS 를 온라인으로 늘리고, ext4 볼륨을 만들어 데이터를 지키며 오프라인으로 줄인다. 마지막으로 400MiB 씬 풀 위에 1GiB 씬 볼륨을 만들어 과할당을 눈으로 본다.