새벽 3시, 디스크 용량 경고 알림에 식은땀 흘려본 적 있으신가요?
안녕하세요, 15년 차 서버 백엔드 개발자이자 인프라 엔지니어링 기술 서적 저자입니다. 오늘은 개발자나 시스템 관리자라면 누구나 한 번쯤 겪어봤을, 그리고 앞으로 반드시 겪게 될 '그 상황'에 대해 아주 깊이 있게 이야기해보려 합니다. 바로 서버 디스크 용량이 꽉 찼다는
Disk Full (No space left on device) 경고입니다.
솔직히 고백하자면, 저도 주니어 시절 이 알림을 무시했다가 뼈저린 경험을 한 적이 있습니다. "에이, 로그 좀 쌓인 거겠지, 내일 출근해서 지우면 돼"라고 안일하게 생각했었죠. 하지만 그 서버는 결제 DB가 연동된 메인 데이터베이스 서버였고, 디스크 사용량이 100%가 되는 순간 DB는 트랜잭션 로그를 기록할 공간이 없어 그 즉시 멈춰버렸습니다. 새벽 3시에 전화벨이 울리고, 비몽사몽 간에 터미널을 열었을 때 `df -h` 명령어가 보여준 `100%`라는 숫자의 공포감이란... 아마 겪어보지 않은 분들은 상상하기 힘들 겁니다. 회사의 매출이 멈추는 소리가 들리는 듯했죠. 😱
특히 서비스가 운영 중인 상태에서 서버를 끄지 않고(Zero Downtime), 안전하게 디스크 용량을 늘려야 하는 미션은 마치
'시속 100km로 달리는 자동차의 바퀴를 갈아 끼우는 것'과 같습니다. 잘못하면 데이터가 영구적으로 손실되거나 서비스 데몬이 꼬여버리니까요. 하지만 걱정 마세요. 리눅스의 축복과도 같은
LVM(Logical Volume Manager) 기술 덕분에 우리는 이 작업을 마법처럼 수행할 수 있습니다. 오늘은 제가 수많은 밤을 새우며 터득한,
서비스 중단 없이 디스크를 증설하는 실전 노하우를 아주 상세하게, 원리부터 트러블슈팅까지 완벽하게 가이드해 드리겠습니다.
1. LVM, 도대체 왜 쓰는 걸까요? (단순한 확장을 넘어서)
많은 분들이 리눅스(CentOS, Ubuntu, RHEL 등)를 처음 설치할 때 "LVM으로 설치하시겠습니까?"라는 질문에 무심코 "Yes"를 누르곤 합니다. 하지만 정작 문제가 터졌을 때 LVM이 무엇인지 몰라 당황하는 경우가 태반입니다. LVM을 이해하지 못하고 구글링한 명령어를 무작정 복사해서 붙여넣는 것은, 눈을 감고 고속도로를 운전하는 것과 다를 바 없습니다.
🧱 물리적 한계를 뛰어넘는 추상화 계층
예전의 전통적인 파티션 방식(Standard Partition)은 마치 '콘크리트 벽으로 된 방'과 같았습니다. 방이 좁아지면 벽을 부수고(포맷하고) 다시 지어야 했죠. 데이터를 다른 곳으로 옮기고, 파티션을 지우고, 다시 잡는 과정은 필연적으로
'서비스 중단(Downtime)'을 야기합니다.
하지만 LVM은 '이동식 칸막이'와 같습니다. 물리적인 하드디스크(HDD, SSD)가 여러 개 있어도, LVM은 이를 하나의 거대한 '스토리지 풀(Pool)'로 묶어서 관리합니다. 커널과 실제 디스크 사이에
논리적 계층(Abstraction Layer)을 하나 더 두는 것이죠.
제 경험상 LVM의 가장 큰 장점은 압도적인
유연성(Flexibility)입니다. 예를 들어, 1TB 하드디스크 3개를 묶어서 마치 3TB짜리 하나의 거대한 디스크처럼 쓸 수 있습니다. 반대로 3TB 공간을 잘게 쪼개서 DB용 500GB, 로그용 1TB, 웹서버용 200GB 등으로 마음대로 할당할 수도 있죠. 물리적인 디스크가 서버의 1번 슬롯에 꽂혀있든 5번 슬롯에 꽂혀있든 중요하지 않습니다. 운영체제 입장에서는 그저 '논리적인 공간'만 보일 뿐이니까요.
📊 실전 비교: LVM vs 일반 파티션
이해를 돕기 위해 제가 현장에서 겪은 수많은 사례를 바탕으로 상세 비교표를 만들어봤습니다. 왜 엔터프라이즈 환경에서 LVM이 선택이 아닌 필수인지 한눈에 보이실 겁니다.
| 구분 | 일반 파티션 (Standard Partition) | LVM (Logical Volume Manager) | 유연성 점수 | 추천 상황 |
|---|
| 용량 확장 | 매우 어려움 (인접한 물리 공간 필요, 보통 언마운트 필수) | 매우 쉬움 (물리 공간만 추가하면 온라인 상태에서 즉시 확장 가능) | ★★★★★ | 서비스 중단이 치명적인 상용 서버, DB 서버 |
| 디스크 관리 | 물리 디스크 단위로 용량이 고정됨 (1TB는 영원히 1TB) | 여러 물리 디스크를 하나의 그룹으로 묶어 대용량 볼륨 생성 가능 | ★★★★☆ | 데이터 증가량을 예측하기 힘든 로그 서버, 파일 서버 |
| 스냅샷 | 파일 시스템 레벨에서 지원하지 않으면 불가능 (매우 제한적) | LVM 자체 기능으로 특정 시점의 상태를 순간 백업(Snapshot) 가능 | ★★★★★ | OS 패치 전, 대규모 배포 전, DB 백업 시 |
| 데이터 이동 | 데이터를 복사(cp/rsync)해야 함 (시간 오래 걸림) | pvmove 명령어로 서비스 중단 없이 물리 디스크 간 데이터 이동 가능 | ★★★★☆ | 노후화된 디스크 교체 작업 시 |
| 성능 | 오버헤드가 거의 없음 (Raw Device에 가까움) | 아주 미세한 오버헤드 존재 (현대 CPU/SSD 환경에선 무시 가능 수준) | ★★★★☆ | 대규모 트래픽 처리가 필요한 모든 환경 |
2. LVM의 핵심 3총사: PV, VG, LV 완전 정복
LVM 작업을 하려면 반드시 알아야 할 세 가지 개념이 있습니다. 이 세 가지만 알면 LVM의 90%는 이해한 것입니다. 저는 이걸
'물류 창고 비유'로 설명하는 것을 좋아합니다. 이 비유를 이해하면 명령어가 저절로 외워질 것입니다.
1. PV (Physical Volume) - 원자재 (벽돌)
PV는 실제 물리적인 디스크(`/dev/sdb`)나 파티션(`/dev/sdb1`)을 LVM이 다룰 수 있는 형태로 초기화한 상태를 말합니다. 비유하자면
'규격화된 벽돌'입니다. 하드디스크를 사 오면 그냥 쓸 수 없고, LVM이라는 집을 짓기 위해 벽돌 형태로 다듬는 과정이 필요합니다. 헤더를 작성하고 메타데이터를 심는 과정이죠.
pvcreate 명령어가 바로 이 작업을 수행합니다.
2. VG (Volume Group) - 자재 창고
VG는 PV(벽돌)들을 한데 모아놓은
'거대한 창고'입니다. 디스크가 1개든 100개든, VG로 묶으면 하나의 거대한 저장 공간처럼 보입니다. 우리가 용량이 부족할 때 하는 작업은, 이 창고(VG)에 새로운 벽돌(PV)을 더 채워 넣는 것입니다. 실무에서는 보통 `vg_data`, `ubuntu-vg`, `VolGroup00` 같은 이름을 붙여서 관리합니다.
3. LV (Logical Volume) - 실제 방 (인테리어 전)
LV는 창고(VG)에서 필요한 만큼 벽돌을 꺼내서 만든
'실제 방'입니다. 운영체제가 "아, 여기에 데이터를 저장하면 되겠구나"라고 인식하는 블록 디바이스가 바로 LV입니다. `/home`, `/var`, `/data` 같은 디렉토리들이 각각의 LV로 할당되어 있는 경우가 많습니다. 우리는 최종적으로 이 LV의 크기를 늘려서 방을 넓히는 것이 목표입니다.
💡 시니어의 통찰: PE (Physical Extent)를 아시나요?
LVM은 데이터를 PE라는 아주 작은 조각(기본 4MB) 단위로 쪼개서 관리합니다. VG를 확장한다는 건 이 PE 조각들을 창고에 더 채워 넣는 것이고, LV를 늘린다는 건 창고에 있는 PE 조각을 가져와서 LV에 붙이는 것입니다. "No free extents" 에러가 난다면, 창고(VG)에 남은 PE(벽돌)가 없다는 뜻입니다.
3. 작업 전 필수 체크리스트 (돌다리도 두드려보고 건너라)
명령어를 입력하기 전에 반드시 현재 상태를 파악해야 합니다. 무턱대고 진행하다가 엉뚱한 디스크를 날려먹은 사례를 너무 많이 봤습니다. 다음 명령어로 현재 상태를 진단하세요.
현재 디스크 사용량 확인
df -hT
- -h: 사람이 읽기 편한 단위(GB, TB)로 표시
- -T: 파일 시스템 타입(xfs, ext4) 표시 (★매우 중요: 파일 시스템에 따라 확장 명령어가 다릅니다!)
LVM 구조 파악
lsblk
트리 구조로 디스크와 파티션, LVM 관계를 한눈에 보여줍니다. 내가 늘려야 할 대상이 /dev/mapper/vg_root-lv_root인지 명확히 확인하세요.
백업은 선택이 아닌 필수
경고: 파일 시스템을 건드리는 작업은 항상 데이터 손실 위험이 있습니다. 특히 운영 중인 DB 서버라면 반드시 스냅샷을 찍거나 중요 데이터를 별도 서버로 백업 후 진행하세요. "나는 전문가니까 괜찮아"라는 생각이 가장
댓글
댓글 쓰기