[데이터베이스] ASM(Automatic Storage Management)의 구조와 동작 메커니즘

ASM ( Automatic Storage Management)

앞서 RAC 파트에서 클러스터링을 구현할 때는 DB 레이어뿐만 아니라 인프라 전반을 함께 고려해야 한다고 말씀드렸습니다. 그중에서도 가장 핵심적인 요소는 "데이터가 저장되는 스토리지" 입니다.

여러 대의 서버가 하나의 데이터를 동시에 공유해야 하는 RAC 환경에서는, 기존 단일 서버 중심의 스토리지 운영 방식으로는 한계가 있습니다. 이러한 구조를 그대로 적용할 경우 관리 포인트가 늘어나고, 동기화 및 장애 대응 복잡도가 기하급수적으로 증가하게 됩니다. RAC 환경에서는 단순히 DB 설정만이 아니라, 공유 스토리지 구조와 데이터 접근 방식까지 함께 설계하는 것이 필수적입니다.

그래서 이러한 구조적 문제를 해결하기 위해, Oracle은 RAC 환경에 최적화된 디스크 관리 기능인 Automatic Storage Management(ASM)를 제공합니다.

ASM은 단순한 파일 시스템이 아닙니다. RAC 환경에서 여러 노드가 동시에 동일한 데이터를 안정적으로 접근할 수 있도록 설계된 클러스터 친화적인 스토리지 관리 계층입니다. 기존 방식에서는 OS 레벨에서 파일 시스템을 구성하고, LUN을 나누고, 볼륨을 관리하고, 마운트를 설정하는 등 관리 포인트가 매우 많았습니다. ASM을 사용하면 이러한 복잡한 작업을 디스크 그룹 단위로 추상화하여 관리할 수 있습니다.

 

관리자 입장에서 ASM이 주는 이점은 명확합니다. 크게 세 가지로 요약할 수 있습니다.

첫째, 성능 튜닝의 자동화입니다. ASM은 모든 데이터를 골고루 나누어 저장 하는 정책을 사용합니다. 덕분에 특정 디스크에만 부하가 쏠리는 현상이 사라지고, 관리자가 일일이 I/O 성능을 튜닝할 필요가 없어졌습니다.

둘째, 유연한 확장성입니다. 데이터베이스 운영 중에 디스크를 추가하거나 제거하더라도 서비스 중단 없이 데이터가 자동으로 재배치 됩니다. 파일 이름을 정하거나 위치를 고민하는 번거로움도 ASM이 대신 처리합니다.

셋째, 업무 경계의 단순화입니다. 과거에는 디스크 하나를 추가할 때도 시스템 관리자의 작업이 끝날 때까지 기다려야 했지만, ASM 환경에서는 DBA가 주도적으로 스토리지 자원을 할당하고 관리할 수 있어 업무 효율이 비약적으로 향상됩니다.

 

ASM 상세 구조 살펴보기

 

오라클 DB 인스턴스를 기동할 때 SGA를 할당하고 여러 백그라운드 프로세스를 실행하듯이, ASM 역시 독립적인 인스턴스 구조를 가집니다.

 

ASM이 단순한 스토리지 설정 기능을 넘어 디스크 그룹을 관리하고 데이터 재배치 및 미러링을 수행하는 등 스토리지를 실시간으로 제어하는 관리 주체이기 때문에 ASM은 정적인 옵션 값이 아니라, 자체 메모리와 프로세스를 기반으로 동작하는 하나의 관리 할 수 있는 엔진이 필요합니다.

ASM 인스턴스는 데이터베이스 인스턴스와 유사한 구조를 가졌지만, 실제 데이터를 처리하는 것이 아니라 스토리지의 메타데이터를 관리하고 디스크 I/O를 제어하는 데 최적화된 특수 인스턴스입니다.

 

여기서 중요한 점은, 두 인스턴스가 하나로 묶여 있는 것이 아니라 서로 독립된 인스턴스로 나란히 기동된다는 사실입니다. DB 인스턴스는 오직 SQL 처리와 트랜잭션 수행, 즉 데이터 처리에만 집중합니다. 반면 디스크 그룹 관리, 파일 배치, 리밸런싱과 같은 스토리지 관련 작업은 전적으로 ASM 인스턴스가 담당합니다.

ASM 인스턴스가 왜 반드시 동작하고 있어야 하는지 이해했다면, 이제 한 단계 더 들어가 보겠습니다. 실제로 데이터베이스가 파일을 생성하거나 확장할 때, DB 인스턴스와 ASM 인스턴스는 내부적으로 어떤 과정을 거쳐 상호작용할까요?

겉으로 보기에는 단순히 “파일이 만들어졌다”로 보이지만, 그 뒤에서는 두 인스턴스 간의 협업이 실시간으로 이루어지고 있습니다.

1. 파일 생성 요청
데이터베이스(DB)가 ASM에게 "새 파일이 필요해!"라고 요청합니다.

2. 공간 할당 (ASM)
ASM 인스턴스가 디스크 그룹에서 공간을 찾아 할당하고, 작업 기록(COD)을 남깁니다.

3. 지도 전달
ASM이 ASMB 프로세스를 통해 DB 인스턴스에게 "이 위치에 데이터를 쓰면 돼"라는 지도를 전달합니다.

4. 직접 초기화 (DB)

지도를 받은 DB는 ASM을 거치지 않고 디스크에 직접 데이터를 기록하여 파일을 초기화합니다.

5. 커밋 요청
초기화가 끝나면 DB가 ASM에게 "다 만들었으니 확정해줘"라고 요청합니다. ASM은 작업 기록을 지우고 정식 파일로 등록합니다.

6. 마무리
파일 생성이 확인되면 암시적으로 닫히며, 이후 I/O가 필요할 때 다시 엽니다.

ASM은 여러 개의 물리 디스크를 논리적으로 통합하고, 데이터를 자동으로 분산/복제하여 성능과 안정성을 동시에 확보합니다.

디스크 그룹 (Disk Group)

디스크 그룹은 ASM 관리의 가장 큰 단위입니다.
여러 개의 물리 디스크를 하나로 묶은 논리적 저장소 풀이라고 보면 됩니다.

디스크 그룹 핵심 특징
     : 데이터는 디스크 그룹 내 모든 디스크에 자동 분산(Striping)
     : 필요 시 자동 미러링(Mirroring)
     : 관리자는 물리 디스크 대신 디스크 그룹만 관리

ASM 디스크 
     : 보통 스토리지에서 할당받은 Raw LUN
     : 다른 애플리케이션과 공유하지 않는 전용 디스크 권장
     : 디스크 헤더 기반 식별 → 노드마다 OS 장치명이 달라도 문제 없음

AU (Allocation Unit)

ASM이 공간을 나누는 최소 할당 단위입니다.
     : 기본 크기: 1MB
     : 핫스팟 방지 + 순차 I/O 효율의 균형점
     : 디스크 그룹 생성 시 설정 (이후 변경 불가)
     : VLDB 환경에서는 더 큰 AU가 유리할 수 있음

즉, ASM은 디스크 그룹을 AU 단위로 잘게 나눠 데이터를 고르게 뿌립니다.

ASM 파일 (ASM Files)

DB 관점에서 바라보는 실제 파일입니다.

ASM이 자동으로 고유 이름 생성합니다.

과거에는 DB 전용 파일만 저장 가능했지만, 현재는 추적 파일(Trace), Alert Log 등 거의 모든 유형의 파일 저장 가능합니다.

ASM은 여러 개의 물리 디스크를 하나의 디스크 그룹으로 통합하고, 이를 AU(기본 1MB) 단위로 분할하여 데이터를 자동으로 분산 및 복제 합니다.

관리자는 복잡한 파일 경로나 물리적 디스크 위치를 직접 관리할 필요 없이, 중복성 정책만 설정하면 됩니다. 이후의 데이터 배치, 리밸런싱, 성능 최적화 작업은 ASM이 자동으로 수행합니다. 결과적으로 ASM은 데이터베이스 운영 환경에서 성능과 가용성을 동시에 확보할 수 있도록 지원하는 효율적인 디스크 관리 메커니즘이라고 할 수 있습니다.

ASM은 단순 스토리지 설정이 아니라 DB 성능, 가용성, I/O 구조와 직결된 설계 영역이라 인프라 엔지니어의 영역 이라기보다는 DBA의 전문적인 영역이라고 볼 수 있습니다.