처음 서버라고 불릴만한 기기들을 도입할 적에는
사양이 다르고 그 목적성이 조금씩 달라 파편화되고 다양했었으나,
2023년 7월 내/외부망을 전부 1GbE로 통일하게 되면서
1개 서버로 한정된 자원을 효율적으로 활용하여 다양한 기능을 할 수 있게 하자는 발상을 하게 되었다.
그리하여 Proxmox VE라는 하이퍼바이저 OS를 도입하게 되었고,
그렇게 Ryzen 5600G, 32GB 램의 사양을 가진 Deskmini X300에서
Proxmox VE를 구동하게 되었다.

하지만 당시 무중단 운영보단 중앙집중적 구성에만 집중했던 사정으로 인해
서버 자체가 1개, 다시 말해 단일 노드라는 한계를 가지고 있었다.
당연히 충분, 아니 차고 넘치는 사양이지만
결벽증으로 인해 방에 씻기 전엔 못 들어가는 버릇이 있는 고로(…)
장애 발생 시 대처가 하루를 넘기게 되는 불상사가 간혹 발생하게 되었다.

장애의 원인은 다양하다.
현재까지 발생한 이력이 있는 장애 원인은

  1. 정전
  2. 서비스 구성 실수로 네트워크 구성 오류
  3. 서버 이름 변경(…)
  4. 공유기 불량
  5. 공유기 설정 중 DHCP 미할당
  6. 디스크 불량
  7. OOM Killer

물론 정전조차 흔히 일어나는 일은 아니다.
그럼에도 장애란 것은 일어나면 큰 일이기 때문에(컴퓨터공학부 학생이 컴퓨터를 못하게 된다고 생각해보라!)
이러한 장애가 발생하는 것을 줄이기 위한 시도는 끊임없이 이어져 왔다.

가장 크리티컬한 장애 원인인 정전은
부실한 전력원이 아니라 동거자의 부주의로 발생한다.
용량이 안되는 멀티탭에 전열기기 등의 고출력 기기를 연결하거나
싸구려 멀티탭을 쇼트내면(…) 발생하는 일이기 때문에
장기적인 장애로 이어지지 않으며, 두꺼비집을 점검하는 순간 원상복구가 된다.
따라서 이 부분은 무정전 전원장치(UPS)로 보완하기로 하였다.

그 다음에 발생하는 장애 중 2, 3, 4, 5, 7 같은 경우,
메인프레임인 Proxmox VE가 다운된 것은 아니지만,
소프트웨어 상의 이유로 원격 접근이 불가능한 경우이다.
즉, 메인프레임에 접근할 수만 있다면 복구가 가능한 장애이다.
그러나 헤드리스 구성으로 창고에 처박은 서버에 손쉽게 접근하는 것은
쉬운 일도 아니거니와, 그리 내키는 일도 아니다.
다행히 KVM over IP를 지원하는 KVM들이 저렴하게 풀리기 시작하여(Nano KVM, Pi KVM)
원격으로 바이오스까지 점검할 수 있는 기틀이 마련되었다.
공유기가 정상작동하고, KVM이 죽지 않아야 한다는 전제가 필요하지만,
중앙집중식 구성에서 단일 장애 지점(SPOF)을 저렴하게 해소할 수 있다는 점에서
꽤나 매력적인 보험이라고 생각한다.

그러나 6번과 같은 상황은 꽤나 심각하며, 즉각적인 조치가 어렵다.
하드웨어 상에서 문제가 발생한 것이기 때문에 노드 자체가 죽었을 가능성이 크며,
Proxmox VE는 디스크 쓰기가 주로 일어나는 NAS 뿐만아니라 읽기/쓰기가 빈번하게 일어나는
상용 OS까지 VM으로 구동하고 있기 때문에 디스크 정보 자체의 손상을 수반하며,
이를 복구하는 것은 SSD라면 불가능에 가깝고, HDD여도 어렵다.
물론 Proxmox VE는 클러스터 구성이 되어 있다면 타 노드로 VM을 마이그레이션하는 것을 지원하고,
Proxmox Backup Server를 별도 구성하여 VM을 주기적으로 백업하게 만들 수도 있다.

아무튼 백업이라는 것은 자동화가 가능하며, 마이그레이션도 원격으로 수행할 수 있으니
이 정도면 홈랩 규모에서는 최대한의 보험을 구축했다고 볼 수 있다.
그러나 이 또한 비정규적인 조치가 필요하며, 당장 활용해야 하는 서버를 고쳐야 한다.
서버를 활용한다기보다 서버를 모시고 살게 되는 주객전도가 발생하게 되는 것이다.

자, 이렇게 디스크가 문제가 생기는 것에 대처하기 위해 무엇을 해야 하는가에 대한 고민이 시작되었다.

NAS와 같은 장비에서 활용되는 RAID 구성은 어떻게 구성하느냐에 따라 대역폭을 늘릴수도, 데이터 안정성을 늘릴 수 있다.
그래서 연식이 오래된 중고 HDD를 여러 개 사서 나스를 구성하는 경우가 많다.
그런데 이 경우 어떤 디스크에 문제가 생기면 반드시 관리자의 개입이 발생할 수 밖에 없다.
어떤 RAID 구성을 따르더라도 구성에 사용된 디스크에 문제가 발생하면 정도에 차이가 있긴 하지만 운영에 지장이 갈 수 밖에 없다.
RAID 0의 경우 안정성을 손해보고 대역폭을 늘린 무식한 구성이라 문제가 생기면 얄짤없이 모든 데이터가 손실된다.
RAID 1, 5, 6, 10의 경우 당장은 장애가 발생하지 않지만 시스템 성능이 저하된 채로 구동되어 성능을 요구하는 VM의 운영에 지장을 초래하며,
복구 이전에 또 다른 디스크에 문제가 생긴다면 이 역시 데이터 손실이 발생한다.
복구 과정 역시 번거롭다.
핫스왑을 지원하는 장비라면 운영 중 디스크를 교체할 수 있지만,
이 경우에도 관리자가 문제의 디스크를 직접 식별해야한다는 번거로움이 남는다.
핫스왑을 지원하지 않는다면 상황은 더 번거로워진다.
직접 시스템을 끄고 정비한 다음에 서비스를 활성화해야 하며,
정상적인 운영을 위해서 데이터 리빌드 과정을 거치게 된다.
이는 남은 디스크의 데이터와 패리티 정보를 이용하는 것이라 손실이 클수록 복원이 어려워지며
대체로 서버급 하드를 쓰지 않는 가정집의 사정 상, 관리자가 수동으로 리빌드를 진행해야 한다는
보험 사기에 가까운 수준의 상황이 벌어진다.

너무나 단점이 많은 RAID 구성에 엿을 날리고 보면 신기한 선택지가 나온다.
ZFS라는 파일 시스템과 볼륨 관리자를 통합한 기술이며, RAID에 비해 강력한 기능과 안정성을 제공한다.
ZFS는 데이터를 덮어쓰지 않고 항상 비어있는 공간에 기록한다.
그래서 전원 손실이나 시스템 오류로 인해 데이터가 손상되는 일을 방지한다. 모든 것이 기록되어 있으므로.
또한 모든 데이터 블록에 대해 체크섬을 부여하는데, 이를 통해 데이터 손상 여부를 RAID보다 민감하게 감지한다.
이러한 손실이 감지되면 RAID-Z나 복제본을 통해 해당 디스크의 데이터를 자동으로 복구하기도 한다.
즉 ZFS pool에 묶인 별도의 디스크가 존재한다면, VM과 같은 서비스는 그 디스크의 복제본 데이터로 정상 구동되며
고장난 디스크를 전원을 끄지 않은 채로 교체하기만 하면 자동적으로 복원이 이루어진다!
여러 개의 디스크를 수용할 수 있는 단일 노드라면 이만한 보험이 없다고 생각된다.

실제로 포스팅을 쓰는 기준(2025년 8월 5일) 운영하고 있는 서버는 ZFS pool을 만들고 모든 VM을 ZFS위에 올려 안정성을 꾀하고 있다.
그런데 ZFS조차 무중단 운영의 정답이 될 수 없다. 왜일까?

ZFS가 무중단 운영에서 고려될 수 없는 이유는 크게 2가지가 있다.

  1. 데이터 복제 주기 문제
  2. 디스크 제거 및 변경의 난점

아니, 뛰어난 파일 시스템이라면서 데이터 복제 주기에서 문제가 발생한다는 것은 뭘까?
사실 데이터 복제 주기 문제는 단일 서버에서 구성된 경우 크게 신경 쓸 만한 사항이 아니다.
클러스터링을 염두에 둔 다중 서버에서 ZFS를 활용하는 경우 문제가 될 수 있는 것인데,
이유는 근본적으로 인위적이든 자동이든 복제를 통해 다른 노드에 데이터를 동기화해야 한다.
문제는 각 노드마다 복제 주기가 맞지 않는 경우가 발생하는 것에 있으며,
복제 자체가 네트워크 구성에 영향받기도 한다.
또한 이런 보험을 마련하는 목적성 자체는 데이터 안정성보다 무중단 운영에 있는데,
고가용성의 확보를 위해 클러스터링을 하는 경우 이 단점이 치명적이게 된다.
ZFS에서 고가용성을 구현하는 방법(HA Cluster, ZFS Replication)이 존재하기는 하나,
하나 같이 실시간 동기화가 아니라 특정 시간대에서의 복제를 기반으로 구현되어
장애 발생 시 파일 시스템에 손상이 가기 쉬워지거나 장애 발생 시점보다 더 이전의 스냅샷으로 복원이 된다.
RAID 구성보단 확실히 다운타임을 줄이는 방법이지만, 클러스터를 구성할 입장에서는 그리 매력적인 선지가 못 된다.

그러던 와중에 Proxmox VE 클러스터에서 Ceph를 구현한 글을 보게 되었다.
이 글에서 등장하는 Ceph는 오픈소스 분산 스토리지 시스템으로, 여러 대의 서버와 디스크를 하나로 묶어 거대한 단일 스토리지 장비처럼 사용할 수 있게 해주는 기능이다.
그럼 기존의 단일 스토리지 장비(단일 노드 Proxmox VE, NAS)와의 차이는 무엇일까?

우선 Ceph는 데이터를 한 곳에 저장하지 않고, 클러스터를 구성하는 노드들의 디스크에 분산하여 저장한다.
또한 데이터에 파일이나 블록 단위로 저장하지 않고, 고유한 ID를 가지는 객체(Object)로 변환하여 저장한다.
이렇게 저장되는 데이터는 노드마다 저장될 복제본이며, 각 클러스터마다 같은 방식으로 복제되어 저장된다.
그렇기 때문에 어떤 노드에 장애가 생길 때, 장애가 일어나지 않은 정상 노드에서 VM의 구동을 보장하며,
장애 노드가 정상화될 때 타 노드에서 데이터를 복제하여 VM을 복원한다.
이것이 Ceph가 지향하는 고가용성(HA)의 구현 방식이다.
즉, 이와 같은 구성에서는 노드 전체가 장애가 발생하지 않는 한 VM의 무중단 운영을 위해서 관리자가 물리적으로 개입하지 않아도 된다.
여러 노드를 구성하는 것에서 멈추지 않고, 특정 노드에 장애가 생기더라도 VM이 지장없이 실행되게 할 수 있다는 나에게 있어서는 꿈의 개념인 셈이다.

이 Ceph라는 기능을 구현하기 위해서 어떤 것을 할지에 대해서는 다음 포스트에 적어보도록 하겠다.