dHCI, 컴퓨트 하나 늘리려다 스토리지까지 통째로 사는 문제의 해법

HCI 클러스터에서 컴퓨트가 부족해 노드를 하나 늘리면, 그 노드에 딸린 스토리지 용량도 같이 늘어난다. 반대로 스토리지만 부족해도 마찬가지다. 컴퓨트와 스토리지가 노드 단위로 묶여 있는 구조의 필연적인 결과다. dHCI(Disaggregated HCI)는 이 둘을 물리적으로 떼어놓고, 대신 단일 관리 평면과 자동화로 HCI급의 운영 경험을 유지하려는 접근이다.

컴퓨트와 스토리지를 따로 사는 대신 따로 늘린다

dHCI는 컴퓨트(하이퍼바이저 호스트)와 엔터프라이즈 스토리지 어레이를 물리적으로 분리하되, 단일 관리 평면과 자동화 레이어로 HCI와 유사한 운영 경험을 제공하는 인프라 모델이다. 핵심 원리는 확장(Scale)을 컴퓨트와 스토리지로 나누고, 데이터 서비스는 전용 스토리지에 위임하며, 프로비저닝·라이프사이클은 API·오케스트레이션으로 일원화하는 것이다. 3티어(서버·네트워크·스토리지 분리) 대비로는 운영이 단순해지고, 전통 HCI 대비로는 예측성·고성능·독립 확장성이 강화된다.

구성 요소

분리형 확장성·라이프사이클 관리는 컴퓨트 노드와 스토리지 어레이를 독립적으로 증설·갱신하는 구조라, 워크로드 특성이 바뀔 때마다 세밀하게 CapEx를 집행할 수 있다. 펌웨어·드라이버·하이퍼바이저 패치는 오케스트레이터에서 검증하고 순차 적용하며, 변경이 실패하면 롤백을 자동화한다.

엔터프라이즈 스토리지 데이터 서비스는 스냅샷, 복제, QoS, 중복제거·압축, 동적 씬 프로비저닝 같은 고급 기능을 기본 제공해 예측 가능한 지연시간과 낮은 테일 레이턴시를 만든다. 데이터 경로를 오프로드해 호스트 CPU 오버헤드를 줄이고, 앱 일관성 스냅샷과 애플리케이션 복구 지향 보호정책도 붙이기 쉽다.

단일 관리 평면과 API 중심 자동화는 vCenter·SCVMM 같은 하이퍼바이저 콘솔 플러그인이나 전용 대시보드로 관리를 하나로 모으고, 템플릿 기반으로 LUN·볼륨·데이터스토어를 자동 프로비저닝한다. REST API와 Terraform·Ansible 모듈로 IaC를 구현하고 카탈로그·정책 기반으로 운영을 표준화한다.

고성능·일관성 중심 데이터 경로는 전용 어레이의 컨트롤러·캐시·NVMe 플래시를 활용하고 멀티패스·ALUA·큐뎁스를 최적화해 고부하에서도 안정적으로 처리한다. NVMe/TCP, FC, iSCSI 같은 다양한 패브릭을 선택할 수 있지만, 최신 프로토콜·기능 지원 여부는 벤더·모델별로 달라 최신 정보를 확인해야 한다.

장애 도메인 분리와 복구 탄력성은 호스트 장애와 스토리지 장애 도메인을 나눠 계획·비계획 다운타임의 상호 영향을 최소화하는 데서 나온다. 동기·비동기 복제와 오케스트레이션 기반 DR 자동화로 표준화된 RPO/RTO를 달성하기도 쉬워진다.

어떤 워크로드에 맞나

데이터베이스·트랜잭션 워크로드는 낮은 지연시간과 일관된 성능을 요구하는데, 스토리지 QoS와 스냅샷·복제로 보호와 테스트 복제본 운영을 동시에 해결한다. VDI·가상화 서버 팜은 세션이 폭증하면 컴퓨트를, 프로필·로그온이 폭증하면 스토리지를 위주로 확장해 비용·성능 균형을 맞출 수 있다. 프라이빗 클라우드 기반 IaaS는 카탈로그형 서비스와 자동화된 용량 확장, 정책형 보호로 멀티테넌시 격리를 강화한다. OLTP·백업·파일 서비스가 함께 도는 혼합 워크로드 환경에서는 스토리지 계층화와 QoS로 서로 간의 간섭을 최소화한다.

3-티어 vs HCI vs dHCI

항목	3-티어	HCI	dHCI
성능	고성능 가능, 튜닝 복잡	노드 내 자원 경합, 예측성 낮음	전용 어레이로 예측 가능한 고성능·낮은 테일 레이턴시
확장성	개별 확장 가능, 계획 복잡	노드 단위 동시 확장	컴퓨트/스토리지 독립 확장, 세밀한 CapEx
일관성	이질 구성, 정책 일관성 낮음	SDS 정책 일원화	스토리지 정책 일원화 + 하이퍼바이저 통합
안정성	도메인 분리 양호, 변경 리스크	노드 장애 영향 큼	장애 도메인 분리 + 멀티패스·컨트롤러 이중화
운영 편의	도메인별 전문 운영 필요	매우 단순, 어플라이언스형	단일 관리·API 자동화, 네트워크 구성 요구

프로비저닝 요청 하나가 지나가는 경로

⤢✕

용량이 부족하면 오케스트레이터가 관리자에게 확장·정책 변경을 제안하고, 경로 장애가 나면 멀티패스 페일오버로 대체 경로를 통해 I/O를 계속 이어가는 두 예외 흐름이 정상 흐름과 나란히 정의돼 있다.

도입하면 무엇이 바뀌나

스토리지 집약 워크로드에서 데이터 절감이 2:1 이상 적용된다는 가정 아래, CapEx는 불균형 확장을 억제해 1025% 절감될 수 있고 OpEx는 프로비저닝·패치 자동화로 3060% 줄어들 수 있다. 성능·예측성 측면에서는 99퍼센타일 지연시간이 1535% 개선되고 호스트 CPU 오프로드로 VM 밀도가 1025% 향상될 수 있다. 가용성·복구 측면에서는 애플리케이션 일관 스냅샷과 DR 오케스트레이션으로 RPO는 분 단위, RTO는 수분~수십 분 수준까지 달성할 수 있다. 패치·펌웨어 변경이 실패해도 자동 검증·롤백이 돌고 장애 도메인이 분리돼 있어 서비스 연속성도 올라간다.

다만 이 수치 범위는 워크로드·벤더·구성에 따라 상이하며, PoC 기반 검증과 최신 제품 스펙 확인이 권장된다.

설계에서 따져야 할 것과 트레이드오프

네트워크·패브릭은 FC(성능·지연 우수, 비용은 높음), iSCSI(유연하고 비용은 낮음), NVMe/TCP(차세대, 도입 성숙도는 확인 필요) 중에서 고르고, 이중화 패브릭과 MTU·PFC 같은 성능 튜닝을 함께 적용한다. 멀티패스 활성화, 경로 헬스 모니터링, VLAN/VSAN 분리, CHAP·암호화도 기본 모범사례다.

확장·용량 계획은 컴퓨트와 스토리지를 독립적으로 늘리되 핫스팟을 막기 위해 균등 배치하고 QoS 정책을 미리 정의해야 하며, 버전 호환성 매트릭스를 지키고 롤링 업그레이드 계획을 세워야 한다. 데이터 보호·보안은 스냅샷 보존 정책, 불변 스냅샷(Immutable)·WORM 적용, 원격 복제·격리된 복구망을 권장하고, 저장·전송 구간 암호화와 RBAC·감사 로깅, HSM/KMS 기반 키 관리를 통합한다. 운영 자동화는 IaC로 인프라 상태를 선언적으로 관리하고 표준 템플릿·정책 카탈로그를 운영하며, 지연·IOPS·큐뎁스·리드앰프 지표를 관측해 SLO·에러버짓 기반으로 용량·성능을 조정한다.

트레이드오프는 분명하다. HCI 대비 네트워크·스토리지 지식 요구가 늘고 장비 간 호환성·벤더 종속성을 따져야 한다. 3-티어 대비로는 단일 관리·자동화라는 장점이 있지만 특정 벤더 생태계에 종속될 위험이 있어 도입 전에 운영 성숙도를 평가해야 한다. 대표 구현으로는 HPE dHCI, Pure Storage + vSphere 플러그인, NetApp + vCenter 통합 등이 있으나 제품 라인업은 계속 바뀔 수 있어 최신 정보를 확인해야 한다.

도입 절차는 요구사항 정의(성능·보호·SLO)에서 시작해 PoC로 지연·테일·복구를 검증하고, 네트워크·호환성 매트릭스를 확인한 뒤 IaC·운영 표준화를 설계하는 순서가 실용적이다. 벤더별 기능·지원 범위 차이가 있으니 최신 정보 확인과 파일럿 검증은 필수다.