REF-longhorn-engine-replica-architecture

원문 내용

Engine과 Replica 분리 구조

각 Longhorn 볼륨은 전용 Engine (controller)과 여러 Replica를 가진다.
Engine은 항상 Pod과 같은 노드에서 실행된다. (The Longhorn Engine always runs in the same node as the Pod that uses the Longhorn volume.)
Engine은 볼륨을 여러 노드에 분산된 Replica에 동기 복제 (synchronous replication)한다.
Engine과 Replica는 Kubernetes가 오케스트레이션한다.
볼륨마다 별도의 Engine을 생성하므로, 하나의 Engine이 실패해도 다른 볼륨에 영향 없음.

Pod이 다른 노드로 이동할 때

[Before] Node A
Pod ──iSCSI── Engine(A) ──네트워크── Replica(Node A)
                                  └── Replica(Node B)

        ↓ Pod이 Node B로 재스케줄링

[After] Node B
Pod ──iSCSI── Engine(B) ──네트워크── Replica(Node A)
                                  └── Replica(Node B)

기존 노드에서 Engine 종료 + iSCSI 언마운트 (detach)
새 노드에서 새 Engine 생성 + 기존 Replica들에 네트워크로 연결 + iSCSI 마운트 (attach)
Replica는 그대로 제자리에 있음 — 데이터를 옮기는 게 아니라 Engine만 이동

노드 장애 시 복구

장애 노드가 5-6분 내 복구: Kubernetes가 Pod 재시작, 볼륨 언마운트/재마운트. Longhorn이 Engine을 detach/re-attach하여 복구.
장애 노드가 5-6분 초과: Kubernetes가 Pod eviction 진행, 다른 노드에서 Pod 재생성. 기존 VolumeAttachment 정리 후 볼륨 re-attach/re-mount (1~7분 소요).

왜 Engine을 옮겨야 하는가 (iSCSI를 그냥 냅두면 안 되는 이유)

iSCSI는 노드에 로컬 블록 디바이스 (/dev/sdX)를 생성한다. Pod은 이 로컬 디바이스를 마운트하므로, Pod이 다른 노드로 옮겨가면 해당 디바이스가 존재하지 않아 마운트할 수 없다.

Node A 내부:
  Engine(iSCSI Target) → /dev/sdb (Node A에만 존재하는 로컬 디바이스)
                              ↓
                         ext4 mount → /var/lib/kubelet/.../mount
                              ↓
                         Pod (bind mount)

"Engine을 Node A에 그대로 두고, Node B의 Pod이 네트워크로 Node A의 iSCSI Target에 접속하면 되지 않나?"라는 의문이 생길 수 있다. 기술적으로 가능하지만 Longhorn이 그렇게 하지 않는 이유:

방법 1 (Longhorn 실제 방식 — Engine을 Pod과 co-locate):
  Pod(B) → 로컬 iSCSI → Engine(B) ──네트워크── Replicas

방법 2 (Engine을 안 옮기는 경우):
  Pod(B) ──네트워크── iSCSI ── Engine(A) ──네트워크── Replicas
           ↑ 불필요한 네트워크 홉 추가

성능: 방법 2는 Pod→Engine 사이에 불필요한 네트워크 홉이 추가됨.
가용성: 방법 2에서 Node A가 죽으면 Engine도 같이 죽어 Pod(B)이 데이터 접근 불가. Engine을 Pod과 같은 노드에 두면 Engine 장애 = Pod 장애로 범위가 동일해져 장애 도메인이 명확함.

왜 로컬 디스크 직접 마운트가 아닌 iSCSI를 쓰는가

로컬 디스크가 당연히 빠르지만, Longhorn이 iSCSI를 쓰는 이유는 Engine을 중간에 끼워서 복제를 투명하게 수행하기 위해서이다.

로컬 디스크 직접 마운트:
  Pod → /dev/sda (Node A 디스크)
        끝. 빠르지만 Node A 죽으면 데이터 사라짐.

Longhorn:
  Pod → /dev/sdb (iSCSI 가상 디바이스)
              ↓
         Engine (여기서 복제 수행)
              ├── 쓰기 → Replica (Node A 디스크)
              └── 쓰기 → Replica (Node B 디스크)  ← 동시에!

Pod 입장에서는 둘 다 /dev/sdX에 쓰는 것처럼 보이지만, Longhorn은 Engine이 중간에서 쓰기를 가로채서 여러 노드에 동시 복제한다. iSCSI는 이 "가로채기"를 가능하게 하는 배관.

비교	로컬 디스크 (local-path)	Longhorn (iSCSI)
성능	최고 (직접 I/O)	복제 오버헤드 있음
노드 장애 시	데이터 유실	Replica에서 복구
Pod 이동 시	데이터가 원래 노드에만 있어 접근 불가	Engine 재생성 후 Replica에서 제공

결론: 복제가 필요 없으면 로컬 디스크(local-path)가 맞고, 노드 장애 보호가 필요하면 Longhorn(iSCSI)이 맞다.

핵심 개념

Engine = iSCSI target을 Pod에 노출하는 프론트엔드. 가벼워서 빠르게 재생성 가능.
Replica = 실제 데이터가 있는 백엔드. 노드의 디스크에 고정, 이동하지 않음.
Engine이 Pod과 co-locate되므로 iSCSI가 단일 노드 마운트임에도 Pod 이동이 가능.

메타 정보

출처 유형: 공식문서

gonnux.com