Oracle ExaCC에서 /u02 파일시스템만 ext4 타입을 사용하는 이유

운영중인 ExaCC VM 파일시스템 구성을 확인하는 도중에 fstab 에서 /u02 파일시스템만 ext4 타입을 사용하는것을 확인했습니다. 왜 해당 파일시스템만 다른 타입의 파일시스템을 사용하는지 궁금하여 확인해 보았습니다.

ExaCC 환경의 파일시스템 기이한 현상

Oracle Exadata Cloud@Customer (ExaCC) 혹은 Exadata Database Service on Dedicated Infrastructure (ExaDB-D) 환경을 운영하는 엔지니어라면, Linux 커널 내 파일시스템 마운트 정보를 담고 있는 /etc/fstab 파일이나 df -Th 명령어를 확인했을 때 한 가지 흥미로운 의문점을 발견하게 됩니다.

루트 영역(/)을 비롯해 오라클 바이너리가 위치하는 /u01 디렉토리는 현대 엔터프라이즈 Linux의 표준 파일시스템인 XFS로 포맷되어 있는 반면, 패치 파일 및 다양한 스테이징 공간으로 활용되는 /u02 디렉토리는 구형처럼 느껴지는 ext4 파일시스템으로 단독 구성되어 있기 때문입니다. 왜 오라클은 단일 VM 아키텍처 내에서 이 두 가지 파일시스템을 혼용하도록 설계했을까요? 단순한 레거시의 잔재일까요, 아니면 정밀하게 계산된 아키텍처적 의도일까요? 이 글에서 그 비밀을 명확히 풀어보겠습니다.

2. 구글 스니펫 대응 요약: /u02가 ext4인 결정적 이유

시간이 없는 엔지니어분들을 위해 결론부터 요약하면 다음과 같습니다.

Oracle ExaCC 환경에서 /u02 영역이 오직 ext4인 핵심 이유는 “온라인 상태에서 파일시스템의 크기를 안전하게 축소(Scale Down / Shrink)하기 위함”입니다.

• XFS (/u01 등): 온라인 상태에서 크기를 늘리는 것(Scale Up)은 자유롭지만, 크기를 줄이는 것(Scale Down)은 파일시스템 구조상 원천적으로 불가능합니다.
• ext4 (/u02): resize2fs 명령어를 통해 온라인 혹은 매우 짧은 순간 내에 양방향 리사이징(확장 및 축소)을 모두 안정적으로 지원합니다.

클라우드 인프라에서는 자원을 유연하게 늘렸다가 다시 회수하는 작업이 빈번하기 때문에, 오라클은 자원 회수가 필요한 가변 영역인 /u02에 의도적으로 ext4를 채택한 것입니다.

3. 파일시스템의 구조적 차이 심층 분석: XFS vs ext4

오라클의 아키텍처적 선택을 깊이 이해하기 위해서는 엔터프라이즈 리눅스 진영의 양대 산맥인 XFS와 ext4 파일시스템이 가진 태생적 특성과 한계를 기술적으로 비교해 보아야 합니다.

(1) XFS 파일시스템의 특징과 한계

XFS는 고성능 64비트 저널링 파일시스템으로, 대용량 파일과 대규모 파일시스템 환경에서 극도로 우수한 성능을 발휘하도록 설계되었습니다. Allocation Group(AG) 단위로 디스크 공간을 관리하므로 멀티스레드 및 병렬 I/O 처리에 탁월한 이점이 있어 엔터프라이즈 데이터베이스 시스템의 로컬 영역에 최적입니다. RHEL(Red Hat Enterprise Linux) 및 OEL(Oracle Enterprise Linux) 7 버전 이후부터 기본 파일시스템으로 채택된 이유이기도 합니다.

하지만 XFS에는 치명적인 제약이 존재합니다. 바로 “파일시스템의 크기를 하향 조정(Shrink)하는 코드가 커널 수준에서 제공되지 않는다”는 점입니다. XFS 메타데이터 구조상 한 번 확장된 Allocation Group의 개수나 포인터 구조를 다시 축소하는 메커니즘이 구현되어 있지 않습니다. 만약 XFS 파일시스템을 줄이려면 전체 데이터를 다른 곳에 백업한 뒤, 볼륨을 완전히 포맷(mkfs.xfs)하고 다시 데이터를 복구하는 극단적인 다운타임 작업이 수반되어야 합니다.

(2) ext4 파일시스템의 특징과 장점

ext4는 리눅스 환경에서 오랜 기간 검증된 블록 관리 기반 파일시스템입니다. 대용량 병렬 I/O 처리 및 메타데이터 스캔 속도 측면에서는 현대적인 XFS에 비해 대규모 환경에서 다소 불리할 수 있으나, 오랜 성숙도 덕분에 매우 유연한 관리 유틸리티들을 지원합니다.

ext4의 가장 강력한 무기는 바로 양방향 리사이징(Bidirectional Resizing) 능력입니다. ext4 파일시스템은 온라인 상태(마운트된 상태)에서 resize2fs 명령어를 통해 볼륨의 크기를 손쉽게 늘릴 수 있을 뿐만 아니라, 남는 가용 블록들을 계산하여 안전하게 공간을 축소(Shrink)한 뒤 하위 스토리지 볼륨에 자원을 반환할 수 있습니다. 이 과정에서 데이터의 유실 없이 메타데이터 포인터가 정교하게 재조정됩니다.

4. Oracle ExaCC 환경에서 /u02의 독특한 역할

ExaCC 아키텍처 내부에서 /u01과 /u02 디렉토리는 완전히 서로 다른 목적성을 가지고 관리됩니다.

/u01: 고정적인 성능 최우선 영역

/u01은 Oracle Grid Infrastructure(GI) 및 Oracle Database Engine 소프트웨어 바이너리(ORACLE_HOME)가 영구적으로 설치되는 영역입니다. 이 공간은 시스템 구축 시점이나 대규모 업그레이드 시점에 한 번 크기를 결정하면 성능 안정성을 위해 지속적으로 크기를 늘릴지언정, 운영 중에 중간에 자원을 회수하여 줄여야 할 상황이 거의 발생하지 않습니다. 따라서 읽기/쓰기 성능과 확장 속도가 뛰어난 XFS가 전적으로 배치됩니다.

/u02: 클라우드 자동화 하에 제어되는 ‘가변 가상화 영역’

반면 /u02는 오라클 클라우드 자동화 인프라(OCI Control Plane)와 사용자의 동적 자원 관리가 수시로 교차하는 ‘완충 및 가변 자원 공간’입니다. 구체적으로 다음과 같은 용도로 사용됩니다.

1. GI 및 DB 패치 세트 스테이징: 수십 기가바이트에 달하는 오라클 RU(Release Update) 패치 파일이나 이중화를 위한 ISO 이미지가 일시적으로 다운로드되고 풀리는 임시 공간입니다.
2. 오라클 자가 진단 및 관리 로그: TFA(Trace File Analyzer) 로그, Exadata 전용 인프라 관리 도구인 patchmgr의 대규모 실행 흔적, 업그레이드 전후의 바이너리 임시 백업 등 용량이 급증했다가 정리가 일어나는 사이클을 가집니다.
3. 사용자 임시 데이터 수용: ASM(Automatic Storage Management) 디스크 그룹에 들어가지 않는 비정형 덤프 파일이나 외부 텍스트 파일들이 보관됩니다.

5. 클라우드 “동적 자원 조절(Elasticity)” 아키텍처와의 연계

ExaCC는 단순한 온프레미스 장비가 아닙니다. 고객의 데이터센터 내부(On-Premises)에 물리적으로 설치되지만, 통제 및 제어는 공용 클라우드인 OCI(Oracle Cloud Infrastructure) 웹 콘솔과 API를 통해 수행되는 하이브리드 클라우드 엔터프라이즈 서비스입니다.

클라우드 서비스의 핵심 가치는 자원의 탄력성(Elasticity)입니다. 특정 게스트 VM(Guest VM) 클러스터를 운영하다 보면 다음과 같은 시나리오가 매우 자주 발생합니다.

“이번 달 오라클 정기 패치 작업을 위해 임시 가용 공간이 필요합니다. OCI 콘솔에서 클릭하여 /u02 공간을 기존 100GB에서 400GB로 잠시 늘리겠습니다. 패치 작업과 검증이 끝났으니 다시 원래대로 100GB로 줄여서 남는 여유 용량을 다른 VM 디스크나 ASM 디스크 그룹으로 환원하겠습니다.”

이때 OCI 콘솔이나 API를 통해 “Storage Scale Down(스토리지 축소)” 명령을 내리면, 오라클 백엔드 자동화 프레임워크 스크립트가 VM 내부 커널에 파일시스템 축소 신호를 보냅니다.

만약 이때 /u02가 XFS로 포맷되어 있었다면 어떻게 되었을까요? 축소 명령을 처리하지 못하고 커널 레벨에서 에러를 반환하게 되며, 자동화 프레임워크 전체가 마비될 것입니다. 오라클은 사용자가 클라우드 환경의 장점인 ‘자원 회수’를 콘솔 클릭 몇 번만으로 가능하게 만들기 위해, 기술적으로 리사이징 다운이 가능한 ext4 파일시스템을 유일하게 도입한 것입니다.

6. 리눅스 레벨에서의 기술적 검증 (오라클 백엔드 엿보기)

오라클 ExaCC 게스트 VM 내부에서는 LVM(Logical Volume Manager) 혹은 그에 준하는 가상화 블록 장치 위에서 해당 마운트 포인트들이 관리됩니다. 용량 감소 이벤트가 클라우드 제어부로부터 유입될 때, 내부 자동화 스크립트가 실행하는 메커니즘을 Linux 명령어로 표현하면 다음과 같은 파이프라인을 거치게 됩니다.

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