날씨 정보를 불러오는 중...

오라클 RAC ASM 이중화 구성 가이드 - 스토리지 2대로 Normal Redundancy 설정하기

2026-09-02 21:55 · IT기술 · 조회 43
Oracle RAC ASM 이중화

오라클 RAC ASM 이중화 구성 가이드 – 스토리지 2대로 Normal Redundancy 설정하기

오라클 RAC(Real Application Clusters) 환경에서 스토리지 장애에도 서비스를 멈추지 않으려면 ASM(Automatic Storage Management) 레벨에서 데이터를 이중화해야 합니다. 이 글에서는 서로 다른 스토리지 어레이 2대를 각각 Failure Group으로 묶어 ASM Normal Redundancy 디스크 그룹을 구성하는 개념부터, 실제 디스크 준비 → 디스크그룹 생성 → 장애 시뮬레이션 테스트까지 명령어 단위로 그대로 따라할 수 있게 정리했습니다.

1. ASM 이중화 개념부터 이해하기

개념 ASM Redundancy란?

ASM은 디스크그룹을 만들 때 세 가지 이중화 방식 중 하나를 선택합니다. 스토리지 자체 RAID로 이중화가 끝나 있다면 External, ASM이 직접 데이터를 복제하게 하려면 Normal 또는 High를 씁니다.

  1. External Redundancy – ASM은 미러링을 하지 않고, 스토리지 어레이의 RAID(예: RAID-5/6)에 이중화를 전적으로 위임합니다. Failure Group 개념이 필요 없습니다.
  2. Normal Redundancy – ASM이 모든 익스텐트(extent)를 2벌(2-way mirroring)로 복제해 서로 다른 Failure Group에 나눠 저장합니다. Failure Group 1개(=스토리지 1대) 전체가 죽어도 데이터는 살아있습니다.
  3. High Redundancy – 익스텐트를 3벌(3-way)로 복제합니다. Failure Group 2개가 동시에 죽어도 버틸 수 있지만 스토리지 3식이 필요해 비용 부담이 큽니다.

스토리지가 정확히 2대이고 예산상 3대를 구성하기 어렵다면, Normal Redundancy + Failure Group 2개(스토리지 A / 스토리지 B) 구성이 가장 현실적인 선택입니다.

2. Failure Group으로 스토리지 2대 이중화하는 원리

Failure Group Failure Group의 역할

Failure Group은 "동시에 장애가 날 가능성이 있는 디스크의 묶음"입니다. 스토리지 A에서 가져온 LUN들을 Failure Group A로, 스토리지 B에서 가져온 LUN들을 Failure Group B로 지정하면, ASM은 원본 익스텐트를 Failure Group A에 쓸 때 그 미러 사본을 반드시 Failure Group B에 씁니다. 그래야 스토리지 한 대가 통째로 내려가도 나머지 한 대에 모든 데이터의 사본이 남아있게 됩니다.

  1. 스토리지 A의 LUN 2~4개 → FAILGROUP STORAGE_A
  2. 스토리지 B의 LUN 2~4개 (A와 동일 개수/용량 권장) → FAILGROUP STORAGE_B
  3. ASM이 두 Failure Group 사이에서 자동으로 primary/mirror 익스텐트를 분산 배치

주의 Voting Disk를 올릴 그리드 디스크그룹이라면 주의

일반 데이터(DATA, RECO) 디스크그룹은 Failure Group 2개로 충분합니다. 하지만 OCR/Voting Disk를 담는 GRID 디스크그룹을 Normal Redundancy로 만든다면, 쿼럼(과반) 판정을 위해 최소 3개의 Failure Group이 필요합니다. 스토리지가 물리적으로 2대뿐이라면 데이터를 담지 않는 소용량 Quorum Failure Group(NFS/iSCSI 등으로 제공되는 3번째 위치)을 추가해 "2 스토리지 + 1 쿼럼 디스크" 형태로 구성하는 것이 정석입니다. 이 글은 DATA/RECO 디스크그룹 기준으로 설명하며, GRID 디스크그룹 쿼럼 구성은 별도로 검토하세요.

3. 사전 준비 사항 (체크리스트)

체크 작업 전에 아래를 모두 확인하세요

  1. 스토리지 A, 스토리지 B의 LUN이 RAC 모든 노드에 각각 공유 디스크로 인식되어 있을 것 (멀티패스 구성 시 multipath -ll로 두 경로 모두 Active 확인)
  2. 두 스토리지에서 가져오는 LUN 크기와 개수를 가급적 동일하게 맞출 것 (용량이 다르면 작은 쪽 기준으로 공간이 낭비되고 I/O 쏠림이 생길 수 있음)
  3. Grid Infrastructure(ASM) 소유자(grid) 및 asmadmin 그룹, 디스크 권한(660) 준비
  4. 디스크 디바이스 이름이 노드 재부팅 후에도 바뀌지 않도록 udev 규칙 또는 ASMLib/ASM Filter Driver(AFD) 준비
  5. 디스크그룹 생성 권한이 있는 SYSASM 계정으로 ASM 인스턴스 접속 가능할 것

4. 설정 가이드 – 명령어로 따라하기

설정 1단계. 공유 디스크 확인

모든 RAC 노드에서 두 스토리지의 LUN이 동일한 WWID로 잡히는지 먼저 확인합니다.

# 멀티패스 디바이스 목록 확인 (스토리지 A/B 각각의 LUN 구분)
multipath -ll

# 예시 출력 중 스토리지 A LUN
# mpatha (36000d310...A1) dm-2 ... size=200G
# 예시 출력 중 스토리지 B LUN
# mpathb (36000d310...B1) dm-3 ... size=200G

# 파티션 생성 (GPT, 파티션 라벨 없이 전체 디스크 사용 권장)
parted /dev/mapper/mpatha mklabel gpt
parted /dev/mapper/mpatha mkpart primary 0% 100%

디스크 2단계. udev 규칙으로 소유권/권한 고정

재부팅 후에도 /dev/sd* 이름이 바뀌는 것과 무관하게 grid:asmadmin 권한이 유지되도록 WWID 기반 udev 규칙을 작성합니다. (/etc/udev/rules.d/99-oracle-asmdevices.rules)

# 스토리지 A LUN (WWID는 multipath -ll 결과에서 확인)
ENV{DM_UUID}=="mpath-36000d310xxxxxxxxA1", OWNER="grid", GROUP="asmadmin", MODE="0660", SYMLINK+="asm-diskA1"
ENV{DM_UUID}=="mpath-36000d310xxxxxxxxA2", OWNER="grid", GROUP="asmadmin", MODE="0660", SYMLINK+="asm-diskA2"

# 스토리지 B LUN
ENV{DM_UUID}=="mpath-36000d310xxxxxxxxB1", OWNER="grid", GROUP="asmadmin", MODE="0660", SYMLINK+="asm-diskB1"
ENV{DM_UUID}=="mpath-36000d310xxxxxxxxB2", OWNER="grid", GROUP="asmadmin", MODE="0660", SYMLINK+="asm-diskB2"
# 규칙 반영 (모든 노드에서 실행)
udevadm control --reload-rules
udevadm trigger --type=devices
ls -l /dev/mapper/asm-disk*

디스크 3단계. (ASMLib 사용 시) 디스크 스탬핑

udev 대신 전통적인 ASMLib 방식을 쓴다면 각 노드에서 아래처럼 스탬핑하고, 나머지 노드는 스캔만 하면 됩니다.

# 대표 1개 노드에서만 실행 (스토리지 A)
oracleasm createdisk DATA_A1 /dev/mapper/mpatha1
oracleasm createdisk DATA_A2 /dev/mapper/mpathc1

# 대표 1개 노드에서만 실행 (스토리지 B)
oracleasm createdisk DATA_B1 /dev/mapper/mpathb1
oracleasm createdisk DATA_B2 /dev/mapper/mpathd1

# 나머지 모든 노드에서 실행
oracleasm scandisks
oracleasm listdisks

이중화 4단계. Failure Group을 지정해 디스크그룹 생성

grid 사용자로 ASM 인스턴스에 SYSASM 권한으로 접속해 디스크그룹을 생성합니다. 핵심은 FAILGROUP 절로 스토리지 A/B를 명확히 분리하는 것입니다.

export ORACLE_SID=+ASM1
sqlplus / as sysasm
CREATE DISKGROUP DATA NORMAL REDUNDANCY
  FAILGROUP STORAGE_A DISK
    '/dev/mapper/asm-diskA1' NAME DATA_A1,
    '/dev/mapper/asm-diskA2' NAME DATA_A2
  FAILGROUP STORAGE_B DISK
    '/dev/mapper/asm-diskB1' NAME DATA_B1,
    '/dev/mapper/asm-diskB2' NAME DATA_B2
  ATTRIBUTE
    'compatible.asm'  = '19.0.0',
    'compatible.rdbms'= '19.0.0',
    'au_size'         = '4M';

RECO(FRA) 디스크그룹도 같은 방식으로 별도 생성해 데이터그룹과 완전히 분리하는 것을 권장합니다.

5. 정상 구성 확인 (검증 명령어)

테스트 디스크그룹/디스크가 의도대로 붙었는지 확인

# 디스크그룹 요약 (REDUNDANCY 컬럼이 NORMAL인지 확인)
asmcmd lsdg

# 디스크별 Failure Group 배치 확인 – STORAGE_A / STORAGE_B로 정확히 절반씩 나뉘어야 함
asmcmd lsdsk -k -G DATA
-- SQL*Plus에서 확인 (SYSASM)
SELECT name, type, total_mb, free_mb, state
  FROM v$asm_diskgroup
 WHERE name = 'DATA';

SELECT group_number, disk_number, failgroup, name, mode_status, state, path
  FROM v$asm_disk
 WHERE group_number = (SELECT group_number FROM v$asm_diskgroup WHERE name='DATA')
 ORDER BY failgroup, disk_number;

failgroup 컬럼에 STORAGE_A, STORAGE_B 두 값만 나오고 각 그룹의 디스크 수/용량이 균등하면 정상입니다.

6. 장애 시뮬레이션 테스트

테스트 스토리지 한 대를 내렸을 때 DB가 살아있는지 검증

  1. 테스트 전 클러스터/DB 상태를 정상으로 확인: crsctl stat res -t, srvctl status database -d <DB_UNIQUE_NAME>
  2. 스토리지 B 쪽 경로를 인위적으로 차단 (테스트 환경에서 스토리지 B로 가는 SAN 스위치 포트 disable, 또는 multipath -ll에서 해당 경로 fault 처리)
  3. ASM 알림 로그($ORACLE_BASE/diag/asm/+asm/+ASM1/trace/alert_+ASM1.log)에서 디스크 오프라인 감지 메시지 확인
  4. 디스크 상태 재조회로 STORAGE_B 디스크들이 MISSING/OFFLINE으로, DATA 디스크그룹이 여전히 MOUNTED 상태인지 확인
SELECT name, failgroup, mode_status, state, repair_timer
  FROM v$asm_disk
 WHERE failgroup = 'STORAGE_B';

-- 디스크그룹 자체는 계속 살아있어야 함 (MOUNTED)
SELECT name, state FROM v$asm_diskgroup WHERE name='DATA';
  1. 이 상태에서 애플리케이션 트랜잭션이 정상 처리되는지 확인 (인위적으로 insert/update 반복 실행)
  2. 스토리지 B 복구 후 디스크를 다시 온라인시켜 변경분만 재동기화(Fast Mirror Resync)
-- disk_repair_time(기본 3.6h) 이내 복구라면 전체 재동기화 없이 변경된 익스텐트만 복사됨
ALTER DISKGROUP DATA ONLINE DISK ALL;

-- 재동기화/리밸런스 진행률 모니터링
SELECT group_number, operation, state, est_minutes, est_work, sofar
  FROM v$asm_operation;

disk_repair_time 속성 값을 넘겨서 디스크가 DROP 처리된 경우에는 재동기화가 아니라 전체 리밸런스가 발생하니, 장시간 유지보수 시에는 이 값을 미리 늘려두는 것이 좋습니다.

ALTER DISKGROUP DATA SET ATTRIBUTE 'disk_repair_time' = '8h';

7. 운영 중 주의사항

주의 실무에서 자주 놓치는 부분

  1. 용량 불균형 금지 – 스토리지 A/B의 여유 공간 차이가 커지면 리밸런스가 한쪽으로 쏠려 I/O 핫스팟이 생깁니다. asmcmd lsdg의 FREE_MB를 주기적으로 비교하세요.
  2. 디스크 추가/제거 시에도 Failure Group 지정 필수 – ALTER DISKGROUP ... ADD DISK 시 FAILGROUP 절을 빠뜨리면 기본 규칙(디스크 경로 기준 자동 판단)에 의존하게 되어 의도치 않게 같은 Failure Group으로 묶일 수 있습니다.
  3. 리밸런스 POWER 조절 – 운영 중 재동기화는 ALTER DISKGROUP DATA REBALANCE POWER 4;처럼 POWER 값을 낮춰 서비스 영향을 최소화하세요.
  4. 모니터링 자동화 – v$asm_disk.mode_status가 OFFLINE으로 바뀌는 순간을 감지하는 알림(Enterprise Manager, 자체 스크립트 등)을 반드시 구성해 두세요. Normal Redundancy는 "한 대까지만" 버틸 수 있으므로 첫 장애를 놓치면 두 번째 장애에 데이터가 손실됩니다.

마무리

ASM Normal Redundancy + 2개 Failure Group 구성은 별도의 스토리지 이중화 솔루션 없이도 "스토리지 한 대 완전 장애"를 버티는 가장 비용 효율적인 방법입니다. 다만 GRID(OCR/Voting) 디스크그룹까지 2대만으로 구성할 때는 쿼럼 디스크 이슈를 반드시 별도로 검토해야 하고, 운영 중에는 두 스토리지 간 용량/성능 균형을 꾸준히 모니터링해야 합니다. 실제 도입 전에는 반드시 사내 표준 및 벤더(Oracle) 최신 문서로 버전별 세부 사항(예: 19c 이후 AFD 권장, disk_repair_time 기본값 변경 등)을 다시 한 번 확인하시기 바랍니다.

댓글 0

로그인 후 댓글을 작성할 수 있습니다.