다중 경로 I/O (Multipath I/O) 커널 모듈 아키텍처
핵심 인사이트 (3줄 요약)
- 본질: 다중 경로 I/O (Multipath I/O)는 서버와 스토리지 장비(SAN) 사이에 존재하는 여러 개의 물리적 연결 경로(Path)를 논리적인 단일 가상 디바이스로 묶어, **무중단 페일오버(Failover)**와 **부하 분산(Load Balancing)**을 제공하는 고가용성 커널 아키텍처다.
- 메커니즘: 리눅스의
Device Mapper (DM)프레임워크를 기반으로 동작하며, 동일한 LUN(디스크)을 가리키는 여러 개의 SCSI 디바이스 경로(예:/dev/sda,/dev/sdb)를 가로채서(Hooking) 상위 계층에 하나의 가상 블록 디바이스(예:/dev/mapper/mpatha)로 추상화하여 제공한다.- 가치: 스위치, HBA 카드, 케이블 중 어느 하나가 끊어져도 I/O 에러(Timeout) 없이 0.1초 만에 살아있는 경로로 데이터를 자동 우회시켜 주므로, 엔터프라이즈 데이터베이스와 클라우드 인프라에서 스토리지 단절(SPOF)을 원천 차단하는 필수 인프라 기술이다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: 서버(Host)와 스토리지 스토리지(Array) 간의 물리적 케이블(Fibre Channel, iSCSI 등)을 2개 이상 이중화하여 연결했을 때, OS가 이를 2개의 독립된 디스크가 아닌 "하나의 디스크로 가는 2개의 길"로 인식하게 만들어주는 커널 블록 레이어의 드라이버 아키텍처. (리눅스 기준
dm-multipath) -
필요성 (단일 장애점 / SPOF 극복):
- 엔터프라이즈 환경에서 서버 1대에 외장 스토리지 장비를 선 1개로 연결하면, 그 선이 끊어지는 순간 서버 전체가 패닉(Kernel Panic)에 빠지거나 데이터베이스가 정지(Hang)된다.
- 그래서 선을 2개 꽂았더니, 이번엔 OS가 똑같은 1TB짜리 디스크를
/dev/sda와/dev/sdb두 개로 착각해서 마운트를 거부하거나 데이터를 양쪽에 엉망으로 써버리는 논리적 충돌 현상이 발생했다. - 해결책: OS 커널 내부 깊숙한 곳에서, 하위 물리 경로 여러 개를 투명하게 감싸서 위쪽(파일 시스템)에는 완벽한 가짜 단일 디스크 1개만 보여주는 영리한 스위칭 모듈이 필요했다.
-
💡 비유: 서울(서버)에서 부산(스토리지)으로 가는 화물을 보낼 때, 경부고속도로(경로 A) 하나만 있으면 사고가 났을 때 물류가 마비된다. 그래서 KTX(경로 B)도 뚫었다. 그런데 택배 기사(파일 시스템)가 경부선 창구와 KTX 창구 두 군데에 물건을 중복 접수하면 곤란하다. Multipath I/O는 "부산행 통합 접수처(가상 디바이스)"다. 기사는 여기다 짐을 던지면 끝이다. 접수처 직원은 경부선이 막히면 몰래 KTX로 짐을 돌리고, 둘 다 뚫려 있으면 반반씩 나눠서(로드밸런싱) 배송 속도를 2배로 높여준다.
-
발전 과정:
- 벤더 종속적 드라이버: 과거 EMC(PowerPath), Hitachi(PowerPath) 등 스토리지 제조사마다 독자적인 유료 드라이버 사용.
- Device Mapper 통합 (Linux 2.6): 리눅스 커널 진영이 LVM(논리 볼륨)과 암호화를 처리하던 Device Mapper 계층에 Multipath 기능을 오픈소스로 통합.
- ALUA / 최신 라우팅: 스토리지 컨트롤러의 상태(Active/Passive)를 실시간 감지하여 최적의 경로를 자동 탐색하는 비대칭 논리 유닛 접근(ALUA) 규격 완성.
-
📢 섹션 요약 비유: 두 개의 눈(경로)으로 하나의 사물(디스크)을 볼 때, 사물이 2개로 보이지 않게 뇌(Multipath 모듈)가 시각 정보를 완벽히 하나로 합성(추상화)해 주는 인지 보정 기술입니다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
구성 요소
| 요소명 | 역할 | 작동 방식 | 비유 |
|---|---|---|---|
| SCSI 미들 레벨 | 물리 장치를 감지 | 케이블 하나당 디바이스 파일 하나(/dev/sda, /dev/sdb) 생성 | 고속도로 진입로 A, B |
| Device Mapper (DM) | 리눅스 커널의 블록 추상화 계층 | 여러 물리 경로를 하나의 가상 경로(/dev/mapper/mpath)로 매핑 | 통합 톨게이트 |
| dm-multipath | DM 하위의 다중 경로 전용 커널 모듈 | I/O 요청을 받아 Round-robin 등으로 경로 분배 및 에러 시 우회 처리 | 교통 통제 경찰 |
| multipathd | 유저 스페이스(User Space) 데몬 스레드 | 경로의 헬스 체크(Ping) 수행 및 끊긴 경로 복구 시 커널에 통보 | CCTV 헬기 순찰대 |
| ALUA | Asymmetric Logical Unit Access (스토리지 표준) | 스토리지가 "이 경로가 주력(Active)이고 저건 예비(Passive)야"라고 OS에 알려줌 | 스토리지 자체 내비게이션 |
Multipath I/O 블록 레이어 아키텍처 흐름
리눅스 커널의 I/O 파이프라인에서 Multipath가 어떻게 패킷(BIO 구조체)을 가로채는지 보여준다.
┌───────────────────────────────────────────────────────────────────┐
│ Linux Device Mapper Multipath 아키텍처 │
├───────────────────────────────────────────────────────────────────┤
│ │
│ [User Space] Application (예: Oracle DB, KVM) │
│ │ (I/O 요청) │
│ ▼ │
│ File System (ext4, XFS) │
│ │ (블록 주소 계산) │
│ ▼ │
│ [Kernel Space] ┌───────────────────────────┐ │
│ │ 가상 디바이스 (mpatha) │ ◀(단일 디스크로 착각)│
│ │ /dev/mapper/mpatha │ │
│ └──────────┬────────────────┘ │
│ │ (BIO 전달) │
│ ▼ │
│ ┌───────────────────────────┐ │
│ │ dm-multipath 커널 모듈 │ ◀(경로 선택 / 헬스체크)│
│ └─┬───────────────────────┬─┘ │
│ (로드밸런싱) │ │ (경로 이중화) │
│ ▼ ▼ │
│ [SCSI 하위 계층] [SCSI 하위 계층] │
│ 물리 경로 1 (sda) 물리 경로 2 (sdb) │
│ │ │ │
│ ──────────────────┼───────────────────────┼────────────────────── │
│ [Hardware] ▼ ▼ │
│ HBA 카드 1 HBA 카드 2 │
│ │(Fibre Channel) │(iSCSI 등) │
│ ▼ ▼ │
│ SAN 스위치 A SAN 스위치 B │
│ │ │ │
│ └──────────┬────────────┘ │
│ ▼ │
│ [ 스토리지 어레이 (LUN 0) ] │
└───────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 파일 시스템은 오직 최상단의 가상 디바이스 /dev/mapper/mpatha에만 I/O를 내린다. 이 I/O 블록(BIO)은 커널의 dm-multipath 모듈에 도착한다. 이 모듈은 현재 설정된 정책(예: Round-robin)에 따라, 이번 I/O는 1번 길(sda)로, 다음 I/O는 2번 길(sdb)로 분배한다. 만약 1번 길로 보낸 I/O가 스토리지 스위치 고장으로 응답이 없으면(SCSI Timeout), dm-multipath 모듈은 즉시 커널 패닉을 내지 않고, 조용히 해당 패킷을 회수하여 살아있는 2번 길(sdb)로 재전송(Retry)한다. 파일 시스템 입장에서는 시간이 아주 살짝 지연됐을 뿐(Failover), I/O 에러(EIO)는 발생하지 않아 서버 운영이 완벽히 지속된다.
다중 경로 스토리지의 접근 정책 (ALUA)
스토리지 컨트롤러(디스크를 관리하는 두뇌)가 2개 꽂혀 있을 때(Active/Active vs Active/Passive)의 처리 방식이다.
- Active/Active: 두 스토리지 컨트롤러가 모두 디스크에 쓸 수 있다. 서버는 sda, sdb 두 경로 모두에 I/O를 날려(Load Balancing) 성능을 2배로 뽑아낸다.
- Active/Passive (ALUA): 하나의 컨트롤러(A)가 디스크 소유권을 쥐고 있고, 다른 컨트롤러(B)는 평소에 대기한다. 서버가 B로 I/O를 날리면 스토리지가 내부적으로 A에게 넘겨 처리하므로 오히려 느려진다(Trespass Penalty).
- 대응 (ALUA 규격): 스토리지가 OS에게 "A 경로가 최적(Optimized)이고 B 경로는 비최적(Non-optimized)이야"라고 상태를 전송한다.
dm-multipath는 이를 읽어 평소에는 A 경로만 쓰다가, A가 죽으면 그때 B 경로를 쓰도록 커널 내부 라우팅 테이블을 스스로 조율한다.
- 📢 섹션 요약 비유: 물류 창고(스토리지)에 정문과 후문이 있을 때, 정문 담당자가 일할 때 후문으로 짐을 넣으면 정문으로 가져가느라 오히려 느려집니다(비최적). 내비게이션(multipath)이 이 상황을 파악하고 평소엔 무조건 정문만 안내하는 것이 ALUA 기술입니다.
Ⅲ. 융합 비교 및 다각도 분석
경로 이중화(Redundancy) 기법 계층별 비교
| 계층 (Layer) | 이중화 기술 (명칭) | 목적 및 대상 | 장애 복구 속도 |
|---|---|---|---|
| 네트워크 (L2/L3) | NIC Teaming / Bonding | 이더넷 포트 2개를 1개로 논리적 결합 | 매우 빠름 (< 1초) |
| 블록 스토리지 (SAN) | Multipath I/O | 파이버 채널(FC), iSCSI 볼륨 경로 이중화 | 빠름 (수 초 내외, I/O 큐잉) |
| 소프트웨어 RAID | MD RAID 1 (미러링) | 아예 다른 물리 디스크 2개에 데이터 동시 복제 | 즉시 (디스크 자체 결함 대비) |
| 파일 시스템 | ZFS / Btrfs Mirror | 파일 시스템 단에서 데이터 복제(Self-Healing) 보장 | 즉시 |
Multipath는 "동일한 디스크(LUN)"로 가는 "길"을 묶는 것이고, RAID는 "서로 다른 디스크"를 묶는 것이다. 즉, Multipath는 케이블과 스위치의 결함을 막고, RAID는 디스크 원판 자체의 결함을 막는 것으로 서로 역할이 완전히 다르며 실무에서는 두 가지를 혼용(Multipath 위의 장비 자체 하드웨어 RAID)한다.
과목 융합 관점
-
시스템 (System / OS):
Device Mapper는 Multipath뿐만 아니라, LVM(논리 볼륨 관리자), Docker의 스토리지 드라이버(디바이스 맵퍼 씬 프로비저닝) 등 현대 OS 블록 스토리지 추상화의 절대적 근간을 이루는 프레임워크다. -
가상화 (Cloud): 하이퍼바이저가 수십 개의 LUN(디스크)을 SAN으로부터 받아올 때 Multipath 처리를 잘못하면, VM 100대가 일제히 I/O 에러를 뿜으며 커널 패닉을 일으키는 클라우드 대참사(Storage Brain-Split)가 발생한다.
-
📢 섹션 요약 비유: 랜카드 본딩(Bonding)이 인터넷 전화를 끊기지 않게 하는 와이파이 안테나 2개라면, Multipath는 심장 수술 장비의 산소 공급관을 2개로 만들어 하나가 막혀도 환자가 죽지 않게 하는 생명 유지 장치입니다.
Ⅳ. 실무 적용 및 기술사적 판단
실무 시나리오
-
시나리오 — 데이터베이스 서버 패닉 (All Paths Down 현상): Oracle RAC 클러스터에서 파이버 채널(FC) 스위치를 펌웨어 업데이트하기 위해 재부팅시켰다. 스위치가 2대 이중화되어 있어 안심했으나, 1대를 재부팅하는 순간 DB 서버가 I/O Error를 뱉으며 크래시 났다.
- 원인 분석: 커널의 Multipath 설정(
.conf)에서path_grouping_policy나no_path_retry파라미터가 잘못 설정된 경우다. 경로 하나가 죽었을 때 커널 SCSI 드라이버의 기본 타임아웃(30초~60초)이 찰 때까지 Multipath 모듈이 I/O를 쥐고 놓지 않아, 결국 DB의 자체 타임아웃(예: 15초)을 넘겨버려 DB 엔진이 스스로 자살(Suicide)한 것이다. - 대응 (기술사적 가이드): FC HBA의 드라이버 타임아웃(
dev_loss_tmo,fast_io_fail_tmo)을 5초 이내로 극단적으로 짧게 튜닝하여 죽은 경로를 즉시 포기(Fail Fast)하게 만들고, 멀티패스 데몬이 즉각 대체 경로로 I/O를 쏘도록 스토리지 벤더가 권장하는 최적화 값을 적용해야 한다.
- 원인 분석: 커널의 Multipath 설정(
-
시나리오 — LUN 증설 시 기존 디바이스 이름 혼선 (sda가 sdc로 바뀜): 서버 재부팅 시 OS가 SCSI 버스를 스캔하는 순서에 따라
/dev/sda가 가리키는 실제 디스크(LUN)가 어제와 오늘이 달라지는 현상 발생.- 대응: 절대로
/dev/sda,/dev/sdb같은 원시 물리 이름을 fstab 마운트나 애플리케이션에 하드코딩하면 안 된다. 스토리지 장비가 부여한 전 세계 유일 식별자(WWID: World Wide Identifier)를 기반으로 Multipath 설정을 통해 고정된 별칭(Alias, 예:/dev/mapper/mpath-db-data)을 생성하고, 시스템 전체가 이 논리 이름만 참조하도록 설계 구조를 강제해야 한다.
- 대응: 절대로
의사결정 및 튜닝 플로우
┌───────────────────────────────────────────────────────────────────┐
│ SAN 스토리지 Multipath 성능/안정성 튜닝 플로우 │
├───────────────────────────────────────────────────────────────────┤
│ │
│ [SAN 환경에서 스토리지 지연(Latency) 증가 또는 경로 단절 이벤트 발생] │
│ │ │
│ ▼ │
│ 스토리지가 Active/Active인가 Active/Passive(ALUA) 인가? │
│ ├─ Active/Active ──▶ [I/O 분배 알고리즘: round-robin 설정] │
│ │ (모든 경로로 부하를 균등 분산하여 성능 극대화) │
│ └─ ALUA (비대칭) ──▶ [I/O 분배 알고리즘: service-time 설정] │
│ │ (스토리지가 알려준 '가장 응답이 빠른' 경로만 │
│ │ 우선 사용하여 Trespass 병목 회피) │
│ ▼ │
│ 경로 단절 시, 상위 애플리케이션(DB/VM)의 타임아웃이 며칠인가? │
│ ├─ 짧음 (< 30초) ──▶ SCSI 하위 계층의 fast_io_fail_tmo 단축 │
│ │ │
│ └─ 긺 / 무제한 ──▶ queue_if_no_path 옵션 활성화 │
│ (모든 경로가 끊어져도 에러를 뱉지 않고 램에 │
│ I/O를 버퍼링하며 관리자가 복구할 때까지 무한 대기)│
└───────────────────────────────────────────────────────────────────┘
[다이어그램 해설] 초보자는 길이 하나 죽으면 무조건 남은 길로 갈 것이라 착각한다. 하지만 OS는 죽은 길이 잠시 아픈 것인지(재전송 대기), 진짜 죽은 것인지 판단하느라 수십 초를 멍때린다. 기술사의 핵심 역량은 이 '장애 인지 시간(Timeout)'과 '대체 경로 전환 시간'을 상위 애플리케이션의 인내심보다 짧게 조율하는 스택 간의 파라미터 매칭(Parameter Matching)에 있다.
도입 체크리스트
-
User-space 데몬 생존: 커널 모듈(
dm-multipath) 자체는 경로가 죽으면 우회만 시킬 뿐, 죽은 경로가 다시 살아났는지 지속적으로 찔러보는(Ping) 역할은 유저 데몬(multipathd)이 한다. 데몬이 OOM Killer 등으로 죽어있지 않은지 프로세스 모니터링이 필수다. -
I/O 스케줄러 일치: 개별 물리 디스크(
sda)의 스케줄러(예: mq-deadline)와 최상위 가상 디스크(mpatha)의 스케줄러(none)가 충돌하지 않도록, Device Mapper의 권고에 따라 하위 디스크 스케줄러를none으로 끄는 udev 룰이 제대로 적용되었는지 검증해야 한다. -
📢 섹션 요약 비유: 튼튼한 동아줄 2개(Multipath)로 짐을 묶었다고 안심하면 안 됩니다. 한 줄이 끊어졌을 때 나머지 한 줄로 무게 중심이 넘어가는 '찰나의 흔들림(Timeout)'을 DB가 버틸 수 있는지 계산하는 것이 진짜 설계입니다.
Ⅴ. 기대효과 및 결론
정량/정성 기대효과
| 구분 | 단일 경로 (Single Path) | 다중 경로 (Multipath I/O) | 개선 효과 |
|---|---|---|---|
| 정량 (가용성) | 케이블 단절 시 100% 장애 (Downtime) | 케이블 단절 시 즉시 우회 (무중단) | 스토리지 인프라 가용성 99.999% 달성 |
| 정량 (성능) | 10G FC HBA 1개 대역폭 한계 (1GB/s) | 4개 경로 라운드로빈 묶음 (4GB/s) | 스토리지 처리량(Throughput) 선형적 확장 |
| 정성 (운영) | OS 부팅 시마다 디스크 이름(sda) 변동 | WWID 기반 영구적인 디바이스 이름 보장 | 마운트 포인트 꼬임 방지 및 스크립트 자동화 안정성 |
미래 전망
- NVMe-oF (NVMe over Fabrics) 기본 다중 경로 (Native Multipath): 기존 SCSI 기반의 낡고 복잡한
dm-multipath데몬을 거치지 않고, NVMe 프로토콜 자체가 커널 NVMe 드라이버 내부에 다중 경로 라우팅 로직(ANA)을 아예 내장해 버린 'NVMe Native Multipath'가 대세로 자리 잡고 있다. 이로써 I/O 처리 지연이 극적으로 감소한다. - 클라우드 소프트웨어 정의 스토리지 (SDS): 클라우드 환경에서는 전통적인 물리 FC SAN 대신 Ceph 나 vSAN 같은 분산 스토리지가 쓰인다. 이때는 블록 레이어의 Multipath 대신, 분산 스토리지 클라이언트(RBD) 알고리즘 자체가 네트워크 해시 링을 통해 여러 노드로 분산 I/O를 직접 쏘는 방식으로 진화 중이다.
결론
Multipath I/O는 하드웨어의 물리적 한계와 장애를 운영체제 커널의 추상화(Abstraction)를 통해 완벽히 가려버린 시스템 소프트웨어의 걸작이다. 수백만 달러짜리 스토리지 장비의 고가용성 성능은 결국 OS 블록 레이어의 이 작은 경로 분배기(Device Mapper)가 얼마나 똑똑하게 타임아웃을 처리하고 큐(Queue)를 관리하느냐에 달려 있다. 이는 '시스템의 신뢰성은 가장 약한 고리가 아니라, 그 고리를 감싸는 소프트웨어 방어망에 의해 결정된다'는 원칙의 증명이다.
- 📢 섹션 요약 비유: 아무리 비싼 명품 스피커(스토리지)라도 선이 끊어지면 소리가 나지 않습니다. 무선 블루투스처럼 보이지 않는 여러 가닥의 연결망(Multipath)을 통해 절대 끊기지 않는 음악(데이터)을 보장하는 것이 현대 IT 인프라의 척추입니다.
📌 관련 개념 맵 (Knowledge Graph)
| 개념 명칭 | 관계 및 시너지 설명 |
|---|---|
| Device Mapper (DM) | 리눅스 커널 블록 레이어에서 논리적 디바이스를 생성하는 핵심 뼈대로, LVM, 암호화(LUKS)와 함께 Multipath의 토대가 됨 |
| WWID (World Wide Identifier) | 경로가 몇 개든, OS 재부팅 순서가 바뀌든 스토리지 볼륨을 절대적으로 헷갈리지 않게 식별해 주는 고유 지문 |
| ALUA (비대칭 논리 유닛 접근) | 스토리지 장비가 커널에게 '어느 경로가 빠른 진짜 길이고, 어느 경로가 예비용 느린 길인지' 상태를 알려주는 표준 프로토콜 |
| FC (Fibre Channel) / iSCSI | Multipath가 주로 적용되는 블록 스토리지 전용의 고속 물리 및 네트워크 통신 케이블 프로토콜 |
| NVMe Native Multipath | 기존 Device Mapper를 우회하고 NVMe 드라이버 자체에 경로 스위칭을 내장하여 오버헤드를 극소화한 차세대 아키텍처 |
👶 어린이를 위한 3줄 비유 설명
- 커다란 공장(스토리지)에서 물건(데이터)을 가져올 때 길이 하나뿐이면, 그 길에 트럭 사고가 났을 때 공장이 멈춰버려요.
- 그래서 길을 여러 개 뚫었는데, 초보 운전자(운영체제)는 똑같은 공장인데 주소가 두 개라고 착각해서 길을 잃어버렸죠.
- '멀티패스'라는 똑똑한 내비게이션을 달았더니, 모든 길을 하나로 묶어서 가장 안 막히는 길로 트럭을 요리조리 보내주고 사고가 나도 1초 만에 다른 길로 안내해 준답니다!