ExaCC VM 발견한 비밀: 왜 /u02 파일시스템만 굳이 ext4일까?

ExaCC VM 파일시스템을 점검하다 생긴 기이한 의문

얼마 전 운영 중인 ExaCC(Oracle Exadata Cloud@Customer) 환경의 VM 파일시스템 구성을 점검할 일이 있었습니다. 평소처럼 df -Th 명령어를 치고 /etc/fstab 파일을 확인하는데, 문득 재미있는 의문점이 하나 눈에 밟히더군요.

루트 영역(/)이나 오라클 바이너리가 묵직하게 자리 잡고 있는 /u01 디렉토리는 현대 엔터프라이즈 리눅스의 표준이라고 할 수 있는 XFS로 예쁘게 포맷되어 있었습니다. 그런데 패치 파일이나 임시 스테이징 공간으로 자주 쓰이는 /u02 디렉토리만 홀로 구형처럼 느껴지는 ext4 파일시스템을 사용하고 있더라고요.

“성능 중심의 Exadata 아키텍처에서 왜 굳이 단일 VM 안에 두 가지 파일시스템을 쪼개서 혼용하도록 설계했을까? 그냥 예전 레거시 설정이 그대로 남은 걸까, 아니면 오라클의 정밀한 설계 의도가 숨어있는 걸까?” 궁금증이 발동해 백엔드 아키텍처를 깊게 파고들어 봤습니다. 알고 보니 여기에는 클라우드 인프라 운영의 무릎을 탁 치게 만드는 결정적인 기술적 이유가 숨어 있었습니다.

성격 급한 엔지니어를 위한 3초 요약: 핵심은 ‘온라인 축소’

결론부터 아주 명쾌하게 짚고 넘어가겠습니다. ExaCC 환경에서 /u02 영역이 오직 ext4 파일시스템이어야만 하는 결정적인 이유는 바로 “온라인 상태에서 파일시스템의 크기를 안전하게 축소(Scale Down / Shrink)하기 위함”입니다.

• XFS (/u01 등): 운영 중에 크기를 늘리는 것(Scale Up)은 자유롭지만, 구조상 크기를 줄이는 것(Scale Down)은 커널 레벨에서 원천적으로 불가능합니다.
• ext4 (/u02): resize2fs 명령어를 사용해 마운트된 상태(온라인)에서도 양방향 리사이징(확장과 축소 모두)을 안정적으로 지원합니다.

클라우드 인프라에서는 자원을 유연하게 늘렸다가 다시 회수하는 작업이 일상다반사로 일어납니다. 오라클은 자원 회수가 빈번하게 발생하는 ‘가변 영역’인 /u02에 철저히 계산된 의도로 ext4를 채택한 것입니다.

태생부터 달랐던 두 파일시스템의 구조적 차이

이 아키텍처적 선택을 제대로 이해하려면, 엔터프라이즈 리눅스 진영의 양대 산맥인 XFS와 ext4의 태생적 특성을 비교해 볼 필요가 있습니다.

1. 고성능 탱크 같지만 뒤로 갈 수 없는 XFS

XFS는 고성능 64비트 저널링 파일시스템으로, 대용량 파일과 대규모 I/O 환경에서 극강의 퍼포먼스를 자랑합니다. Allocation Group(AG)이라는 단위로 디스크 공간을 쪼개서 관리하기 때문에 멀티스레드 병렬 처리에 탁월하죠. RHEL이나 OEL(Oracle Enterprise Linux) 7 버전 이후부터 기본 파일시스템으로 자리 잡은 이유도 바로 이 대규모 데이터베이스 환경에 최적화되어 있기 때문입니다.

하지만 XFS에는 치명적인 제약이 하나 있습니다. 파일시스템의 크기를 하향 조정(Shrink)하는 코드가 아예 존재하지 않습니다. 메타데이터 구조상 한 번 늘려놓은 Allocation Group의 개수나 포인터를 다시 좁히는 메커니즘이 구현되어 있지 않기 때문입니다. 만약 XFS 파일시스템을 줄여야 한다면? 전체 데이터를 다른 저장소에 백업하고, 볼륨을 포맷(mkfs.xfs)한 뒤 데이터를 다시 밀어 넣는 엄청난 다운타임 작업을 감수해야 합니다.

2. 구관이 명관, 유연함의 끝판왕 ext4

반면 ext4는 오랜 기간 검증된 고전적인 블록 관리 기반 파일시스템입니다. 아주 대규모의 병렬 I/O나 메타데이터 스캔 속도 면에서는 현대적인 XFS보다 조금 밀릴지 몰라도, 오랜 성숙도 덕분에 관리 유틸리티가 극도로 안정적이고 유연합니다.

ext4의 가장 강력한 무기가 바로 양방향 리사이징(Bidirectional Resizing) 능력입니다. 마운트되어 서비스가 돌아가고 있는 온라인 상태에서도 resize2fs 명령어 한 줄이면 볼륨 크기를 늘릴 수도 있고, 남는 가용 블록들을 계산해 데이터 유실 없이 안전하게 공간을 깎아낼(Shrink) 수도 있습니다.

ExaCC 아키텍처에서 두 디렉토리가 사는 법

ExaCC 내부에서 /u01과 /u02 디렉토리는 담당하는 미션 자체가 완전히 다릅니다.

/u01 : “성능이 전부다” 고정형 영역

/u01은 Oracle Grid Infrastructure(GI)와 Oracle Database Engine 소프트웨어 바이너리(ORACLE_HOME)가 영구적으로 상주하는 심장부입니다. 이 공간은 시스템을 처음 구축하거나 대규모 버전 업그레이드를 할 때 한 번 크게 잡아두면, 운영 중에 중간에 자원을 야금야금 회수해서 줄여야 할 일이 거의 없습니다. 무조건 읽기/쓰기 성능과 확장 안정성이 중요하므로 XFS가 전적으로 배치되는 게 맞습니다.

/u02 : “유연함이 전부다” 클라우드 완충지대

반면 /u02는 오라클 클라우드 자동화 인프라(OCI Control Plane)와 엔지니어의 동적 자원 관리가 수시로 맞물리는 ‘가변 자원 공간’입니다. 주로 다음과 같은 굵직한 임시 작업들이 여기서 일어납니다.

• GI 및 DB 패치 세트 스테이징: 수십 기가바이트에 달하는 오라클 RU(Release Update) 패치 파일이나 이중화 ISO 이미지를 임시로 다운로드하고 압축을 푸는 공간입니다.
• 오라클 자가 진단 및 관리 로그: TFA(Trace File Analyzer) 로그, Exadata 전용 인프라 관리 도구인 patchmgr 실행 흔적 등 용량이 순간적으로 폭발했다가 정리가 일어나는 사이클을 탑니다.
• 사용자 임시 데이터: ASM 디스크 그룹에 넣기 애매한 비정형 덤프 파일이나 외부 텍스트 파일들이 잠시 머무르는 곳이기도 합니다.

클라우드의 핵심 가치 ‘동적 자원 조절(Elasticity)’과의 연결고리

ExaCC는 독특한 장비입니다. 우리 데이터센터 내부에 장비가 박혀있지만, 통제와 제어는 OCI(Oracle Cloud Infrastructure) 웹 콘솔을 통해 이루어지는 하이브리드 클라우드 서비스죠.

클라우드를 쓰면서 우리가 가장 유용하게 쓰는 기능이 무엇인가요? 바로 필요할 때 늘렸다가 안 쓰면 줄이는 ‘탄력성’입니다. 실제로 현업에서 이런 시나리오가 정말 자주 발생합니다.

“이번 달 오라클 정기 패치 작업을 해야 하는데 용량이 모자라네요. OCI 콘솔에서 클릭 몇 번으로 /u02 공간을 잠시 100GB에서 400GB로 넉넉하게 늘리겠습니다. 패치 작업 끝나고 백업본도 정리했으니, 다시 원래대로 100GB로 줄여서 남는 여유 용량을 다른 VM 디스크나 ASM 디스크 그룹으로 돌려놓을게요.”

이때 우리가 OCI 콘솔에서 ‘Storage Scale Down(스토리지 축소)’ 버튼을 누르면, 오라클 백엔드 자동화 프레임워크 스크립트가 VM 내부 커널에 파일시스템 축소 신호를 보냅니다.

만약 이때 /u02마저 XFS로 포맷되어 있었다면 어떻게 되었을까요? 축소 명령을 처리하지 못하고 커널 레벨에서 에러를 뿜어내며 자동화 프로세스가 멈춰 섰을 겁니다. 오라클은 사용자가 클라우드의 핵심 이점인 ‘자원 회수’를 콘솔 클릭만으로 매끄럽게 처리할 수 있도록, 기술적으로 리사이징 다운이 가능한 ext4를 신의 한 수로 도입한 것입니다.

오라클 백엔드 내부 메커니즘 엿보기

실제 용량 감소 이벤트가 클라우드 제어부로부터 들어올 때, ExaCC 게스트 VM 내부의 자동화 스크립트가 어떤 과정을 거치는지 리눅스 명령어로 쉽게 시뮬레이션해 볼 수 있습니다.

Bash

# [Oracle 백엔드 자동화 프레임워크 내부 메커니즘 의사코드 예시]

# 1. 파일시스템 내부의 데이터 무결성 및 실제 가용 여유 공간 사전 체크
e2fsck -f /dev/mapper/vg_main-lv_u02

# 2. 파일시스템 크기를 데이터 유실 없이 안전하게 타겟 용량으로 축소 (ext4이기에 가능!)
resize2fs /dev/mapper/vg_main-lv_u02 100G

# 3. 파일시스템 하위의 LVM 논리 볼륨을 축소하여 물리 디스크 영역 자원 확보
lvreduce -L 100G /dev/mapper/vg_main-lv_u02

# 4. 확보된 물리 디스크 자원을 하이퍼바이저와 OCI 인프라 풀로 반환

만약 이 영역이 XFS였다면 2번 단계(resize2fs에 매칭되는 XFS 축소 도구의 부재)에서 막히기 때문에 이러한 자동화 파이프라인 자체가 성립되지 않습니다.

성능과 유연성의 절묘한 하이브리드 설계

Oracle Exadata Cloud@Customer(ExaCC)의 파일시스템 구성을 파고들면서 오라클의 아주 지독하고 실용주의적인 엔지니어링 철학을 느낄 수 있었습니다.

엔진 소프트웨어가 상주하며 대용량 I/O와 성능 안정이 최우선인 /u01에는 현대적인 고성능 XFS를, 클라우드의 본질인 탄력적인 자원 조절(확장 및 회수)을 유연하게 받아내야 하는 완충 영역 /u02에는 축소가 가능한 ext4를 배치한 하이브리드 설계인 것이죠.

인프라를 운영하면서 이런 아키텍처적 디테일을 이해하고 있으면, 향후 VM 클러스터 가용 자원을 산정(Capacity Planning)하거나 예기치 못한 스토리지 할당 이슈를 마주했을 때 훨씬 더 정교하고 노련하게 트러블슈팅을 해나가는 엔지니어만의 강력한 무기가 될 것입니다.

전문가의 인사이트 : 함께 읽어 보세요.

[실무 가이드] 기업 DR 구축의 핵심, RTO와 RPO 관점으로 분석한 4가지 유형

참조 및 출처 URL:

https://docs.oracle.com/en-us/iaas/Content/Database/Concepts/exaoverview.htm