[인프라 공부] 나스 장비 업그레이드 — 구조를 어떻게 짤 것인가

지난 글(RAID 1 + HA는 왜 "백업"이 아닌가)에서 정리했듯, HA/RAID 구조는 가용성을 위한 것이지 백업이 아니다. 이 결론을 바탕으로 실제 하드웨어 업그레이드 구조를 어떻게 짤지 고민한 기록.

아이디어 — 기존 장비를 백업 대상으로 재활용하기

신규 NAS를 Active(운영)로 새로 들이고, 기존에 쓰던 구형 장비 2대를 은퇴시키지 않고 백업 대상으로 재활용하는 구조를 검토했다.

[신규 NAS (Active, 운영)]
   ↓ Snapshot Replication (시간차)
   ├──→ [기존 장비 #1] — 백업 대상 A (같은 사무실)
   └──→ [기존 장비 #2] — 백업 대상 B (별도 공간으로 이동 가능)

이 구조가 좋은 이유:

• 호스트 자체가 최신 장비로 교체됨 (노후 장비 은퇴)
• 기존 장비 2대를 버리지 않고 백업 대상으로 재활용 → 새로 안 사도 됨
• 백업이 1벌이 아니라 2벌이 됨 (기존 계획은 Passive 1대만 백업 대상이었는데, 이제 2대 다 활용 가능)
• 그중 한 대를 다른 공간(회의실 등)으로 옮기면, 물리적 분리를 통한 재해 대비까지 동시에 해결됨

베이 계산을 해보니, 신규 장비의 베이 수 안에서 필요한 풀 구성(RAID1 소용량 풀 + RAID6 대용량 풀)이 다 들어가서, 처음부터 확장유닛을 살 필요 없이 본체만으로 해결되는 것도 확인했다. 나중에 용량이 더 필요해지면 그때 확장유닛을 추가하는 식으로 미룰 수 있다.

기존 장비 2대는 각자 독립적으로 신규 Active로부터 Snapshot Replication을 받는 백업 대상으로 전환하고, 더 이상 HA로 서로 묶이지 않는 구조로 재구성했다.

이전 안(확장유닛 추가 방식)과 비교했을 때

• 호스트 노후화: 확장유닛만 추가하는 안은 해결이 안 됨 → 신규 장비 도입안은 해결됨
• 백업 벌수: 확장유닛 안은 1벌(Passive 1대) → 신규 장비 도입안은 2벌(기존 2대 다 활용)
• 물리적 분리: 확장유닛 안은 별도 검토 필요 → 신규 장비 도입안은 자연스럽게 포함 가능
• 마이그레이션 작업: 확장유닛 안은 상대적으로 단순 → 신규 장비 도입안은 호스트 전체 이전 작업 필요 (다운타임 큼)

구조만 보면 단순히 "리스크 하나 제거"를 넘어서 호스트 리프레시 + 이중 백업 + 물리적 분리까지 한 번에 정리되는 안이지만, 마이그레이션 작업 규모가 크고 예산도 기존 안들보다 확실히 커서 승인 난이도가 올라간다는 트레이드오프가 있었다.

드라이브 용량을 섞을 때 — RAID가 아니라 SHR

이후 세부 구성을 짜다가 짚고 넘어가야 했던 기술적 포인트: 서로 다른 용량의 드라이브를 한 풀에 섞으려면 일반 RAID(5/6)가 아니라 Synology의 SHR(Synology Hybrid RAID)을 써야 한다.

• 일반 RAID(5/6)는 가장 작은 드라이브 기준으로 전부 맞춰버려서, 큰 드라이브의 남는 용량이 낭비된다 (예: 소용량+대용량 드라이브를 섞으면 대용량도 소용량 기준으로 취급됨)
• SHR을 쓰면 용량 손실 없이 유연하게 섞을 수 있다

혼합 용량으로 구성하는 옵션들은 설정만 SHR로 잡으면 되니, 이 부분 자체는 큰 장벽은 아니었다.

핵심 체크포인트 — "손 안 대는 백업 서버"가 감당할 수 있나

세부안들을 짜다 보니 공통적으로 구형 서버 2대 중 1대만 드라이브를 보강하고, 나머지 1대는 기존 구성 그대로 방치하는 패턴이 나왔다. 이게 맞는 전략인지 점검이 필요했다.

• 방치되는 백업 서버 쪽 여유 용량과, 지금 Active의 실사용량을 비교해보면 지금 당장은 여유가 있음
• 다만 Active를 더 큰 구성(드라이브 수·용량 증설)으로 키우는 시나리오에서는, 방치된 백업 서버가 몇 년 안에 다시 부족해질 가능성이 있음 → 이건 이번 예산에는 포함하지 않고, 다음 사이클의 후속 과제로 남기기로 함

결론 — 단계를 너무 잘게 쪼개지 않기로 함

세부 옵션을 여러 단계(최소/중간/최대)로 쪼개서 다 보여주는 것도 고려했지만, 이미 앞선 안들까지 합치면 옵션이 너무 많아져서 오히려 의사결정자 입장에서 판단이 어려워질 수 있다고 판단했다. 그래서 "백업 서버 한 대만 보강해서 실질적인 이중 백업 체계를 완성하고, 나머지 한 대는 여유가 있는 동안은 그대로 두고 다음 사이클에 처리"하는 중간 단계 하나를 최종안으로 정리해서 품의서에 반영하기로 했다.