COMPLETED · 2026.03

VMware vSphere 기반
Virtual Infrastructure

High Availability · Fault Tolerance · Shared Storage

Period 2026.03
Team 6명
Role Infrastructure Engineering
12
ESXi Hosts
4
Dedicated Networks
HA/FT
High Availability
iSCSI
Shared Storage

Project Overview

가상화 인프라 설계 목적

VMware vSphere 기반의 가상화 인프라를 구축하고, 장애 대응과 서비스 연속성을 고려한 고가용성 클러스터 및 운영 환경을 설계·구현한 프로젝트입니다.

단순한 기능을 넘어 관리, 스토리지, vMotion, FT 네트워크를 분리하여 실제 기업 환경과 유사한 인프라 구조를 구현하고 운영 기능을 검증했습니다.

Architecture

전체 아키텍처

전체 아키텍처
① Server ESXi
인프라 핵심 서비스와 12대의 가상 호스트(Nested ESXi)를 구동하는 기반 물리 서버
② Service VM
NTP, DNS, NAT 등 클러스터 운영에 필수적인 백엔드 서비스 가상머신
③ Shared Storage
클러스터 내 모든 호스트가 마운트하여 사용하는 공유 저장소
④ Cluster & Pool
고가용성을 묶고 자원을 논리적으로 분배하는 중앙 관리 체계
⑤ Network
Management, Storage, vMotion, FT 트래픽을 분리한 4개의 전용망 인프라

Timeline

Building Process

대규모 가상화 인프라를 체계적으로 쌓아 올린 구축 과정입니다.

Step 1
Server ESXi 설치

가상화를 위한 Bare-metal 하이퍼바이저 OS 설치 및 초기 세팅

↓
Step 2
vCenter 구축

다수의 ESXi를 중앙에서 통합 관리하기 위한 vCSA(Appliance) 배포 및 연동

↓
Step 3
Network 구성

vSwitch를 생성하고 용도별(Management, Storage, vMotion, FT) Port Group과 VMkernel 분리

↓
Step 4
Shared Storage 구축

Windows Server 기반 iSCSI Target을 구축하여 모든 ESXi 호스트에 데이터스토어 마운트

↓
Step 5
Cluster 생성

독립된 호스트들을 묶어 단일 리소스 풀로 융합하는 vSphere Cluster 생성

↓
Step 6
HA (High Availability)

클러스터 레벨의 고가용성 활성화 및 Host Failure 시나리오 검증

↓
Step 7
FT (Fault Tolerance)

서비스 연속성을 위한 Primary/Secondary 실시간 미러링 구성 및 장애 극복(Failover) 완벽 검증

Infrastructure Design

인프라 계층 설계

전체 가상화 인프라를 논리적이고 체계적인 계층 구조로 설계했습니다.

1
Server ESXi

인프라 핵심 컴포넌트와 가상 호스트들을 구동하는 기반 물리 서버

↓
2
vCenter

다수의 ESXi 호스트와 가상머신을 중앙에서 통합 관리하는 컨트롤 타워

↓
3
Cluster

여러 ESXi 호스트를 하나의 리소스 집합으로 묶어 고가용성과 자원 분배 적용

↓
4
Resource Pool

클러스터 내에서 운영/개발 등 목적에 맞게 CPU 및 Memory 자원을 논리적으로 분할

↓
5
Virtual Machine

최종적으로 할당된 리소스 풀 안에서 동작하는 서비스용 가상머신

Network Design

트래픽 분리 설계

성능과 안정성 확보를 위해 트래픽의 목적별로 전용 네트워크를 분리했습니다.

vSwitch 다이어그램
Management
172.16.10.x
호스트 관리 및 서비스 통신을 담당하는 기본 인프라 네트워크
Storage
172.16.40.x
iSCSI 기반의 Shared Storage 접근을 위한 대용량 I/O 전용 네트워크
vMotion
172.16.30.x
VM의 Live Migration 시 발생하는 대규모 메모리 데이터 전송 전용 망
Fault Tolerance
172.16.20.x
Primary ↔ Secondary VM 간의 실시간 데이터 동기화 로깅 전용 망

Core Features

핵심 인프라 기술

실제 운영 환경에서 필수적으로 요구되는 클러스터 기술에 대한 설명입니다.

HA (High Availability)
단일 ESXi 호스트 장애 발생 시 서비스 중단을 방지하기 위해 vCenter 기반 Cluster를 활용하여 가상머신을 다른 호스트에서 자동으로 재시작하는 복구 기술입니다.
FT (Fault Tolerance)
서비스 연속성을 확보하기 위해 Primary/Secondary VM 간 실시간 메모리 동기화 구조를 구축하여, 하드웨어 장애 발생 시 단 1초의 중단도 허용하지 않는 무중단 운영 기술입니다.
vMotion
무중단 환경에서 동작 중인 가상머신(VM)을 다운타임 없이 다른 물리적 ESXi 호스트로 실시간으로 마이그레이션(Live Migration)하여 하드웨어 유지보수 및 자원 밸런싱을 가능하게 합니다.
Shared Storage
모든 ESXi 호스트가 동일한 가상 디스크(VMDK)에 접근할 수 있도록 iSCSI 기반 통신망을 제공하여 vMotion, HA, FT 등 고급 클러스터 기능이 동작할 수 있는 근간을 마련합니다.

My Contributions

실제 수행한 구축 내역

팀 내 인프라 엔지니어로서 제가 직접 설계하고 구축, 테스트를 주도한 항목입니다.

vCenter HA Cluster 구성
  • 2대의 ESXi를 묶어 vCenter Server에서 Cluster 생성
  • 용량 관리를 위한 Admission Control 정책 설정
  • 물리 서버 전원 차단을 통한 Host Failure Test 수행
FT 환경 구축 및 검증
  • Primary 및 Secondary VM 간 동기화 세션 구성
  • 대역폭 보장을 위한 FT Logging Network 전용망 분리 설계
  • 무중단 장애 극복(Failover) 테스트 수행
네트워크 및 리소스 제어
  • vSwitch 생성 및 Management/Storage/vMotion VMkernel 분할
  • Windows Server 기반 iSCSI Target 스토리지 구축
  • 운영/개발 부서별 논리적 Resource Pool 할당 설정

Troubleshooting

Problem Solving

인프라를 구축하고 운영하는 과정에서 겪은 기술적 문제와 해결 과정을 기록했습니다.

vCenter Boot 실패 문제 해결
Problem
서버 재부팅 후 vCenter Server Appliance가 정상적으로 부팅되지 않고 503 Service Unavailable 오류를 반환하며 접근이 불가능해지는 문제가 발생했습니다.
Background
클러스터를 관리하는 핵심 컴포넌트인 vCenter가 다운되면 전체 인프라 관리 및 HA/DRS 제어에 심각한 영향을 미치기 때문에 신속한 복구가 필요했습니다.
Cause
vCenter의 주요 스토리지 파티션 용량이 100% 꽉 차면서 핵심 서비스 데몬이 시작되지 못하는 현상이 주된 원인이었습니다.
Alternatives Considered
vCenter를 재설치하는 방법도 고려했으나, 기존 클러스터 설정과 분산 스위치 구성이 날아갈 위험이 있어 내부 쉘로 접근하여 원인을 직접 수정하기로 결정했습니다.
Why This Solution
CLI 환경에서 원인(로그 용량 초과)을 파악하고 해당 파티션을 정리하는 것이 가장 안전하고 빠른 복구 방안이었습니다.
Implementation
vCenter 관리자 콘솔로 접속하여 `df -h` 명령을 통해 가득 찬 아카이브 로그 파티션을 확인하고 불필요한 과거 로그를 삭제하여 용량을 확보했습니다. 이후 `service-control` 명령으로 데몬을 재시작했습니다.
Result
vCenter 서비스가 정상적으로 올라오며 클러스터 관리 콘솔에 다시 접근할 수 있게 되었습니다.
Lessons Learned
인프라 핵심 컴포넌트는 자체적인 스토리지 용량 관리와 주기적인 모니터링 체계가 필수적임을 깨달았습니다.
FT Resource 부족으로 인한 HA 구성 실패 해결
Problem
Fault Tolerance를 활성화하기 위해 Secondary VM을 생성하려 했으나, ESXi 호스트의 리소스 부족 경고가 발생하며 동기화가 실패했습니다.
Background
초기 실습 환경은 32GB 메모리를 가진 서버로 구성되었습니다. vCenter와 여러 가상 머신이 이미 구동 중인 상태에서 FT는 Primary VM과 동일한 메모리 및 CPU 예약을 요구했습니다.
Cause
FT 기능은 100% 무중단을 보장하기 위해 대상 VM의 메모리를 모두 Reservation(예약) 형태로 할당해야 합니다. 32GB 환경에서는 이 여유 공간이 부족하여 Secondary VM 생성이 거부된 것입니다.
Alternatives Considered
Primary VM의 사양을 최소한으로 낮추거나, 불필요한 다른 VM을 모두 종료하는 방법을 검토했습니다. 그러나 향후 다중 노드 및 고가용성 환경 테스트를 위해서는 근본적인 리소스 확장이 필요했습니다.
Why This Solution
물리적 장비의 한계를 소프트웨어적으로 우회할 수 없는 기능이므로, 인프라를 128GB 메모리를 보유한 상위 서버로 마이그레이션하기로 결정했습니다.
Implementation
128GB 대용량 서버에 ESXi를 새로 구축하고 기존 환경을 마이그레이션했습니다. 여유 리소스가 확보된 상태에서 다시 대상 VM에 대해 FT 기능을 켜서 구성했습니다.
Result
Secondary VM이 성공적으로 생성되고 Primary VM과 실시간 데이터 동기화가 이루어졌으며, 무중단 페일오버 테스트에 성공했습니다.
Lessons Learned
고가용성 기능은 그에 상응하는 리소스 오버헤드를 수반한다는 점을 체감했으며, 인프라 설계 시 용량 산정이 얼마나 중요한지 깊이 이해하게 되었습니다.

Retrospective

프로젝트 회고

배운 점
  • 운영 환경을 고려한 설계:
    단순히 ESXi를 설치하고 가상머신을 띄우는 것이 아니라, 네트워크 분리, 공유 스토리지, 클러스터, HA, FT가 서로 유기적으로 연결되어야 비로소 실제 운영 가능한 인프라가 된다는 점을 경험했습니다.
  • 인프라 컴포넌트 상호 의존성:
    DNS 기반의 이름 해석과 NTP 기반의 시간 동기화가 사소해 보이지만, 클러스터 구성과 시스템 정합성을 유지하는 데 필수적인 핵심 요소임을 깨달았습니다.
  • 장애 대비와 가용성:
    단일 장애 지점을 제거하기 위한 인프라 이중화 설계가 비즈니스 연속성에 미치는 막대한 영향을 직접 체감했습니다.
아쉬운 점
  • 퍼블릭 클라우드 연동 부재:
    온프레미스 내에서의 완벽한 고가용성 클러스터를 구축하는 데는 성공했지만, 외부 퍼블릭 클라우드 인프라와 네트워크를 연동하여 하이브리드 환경으로 확장해보지 못한 점이 큰 아쉬움으로 남았습니다.
향후 개선
  • 하이브리드 클라우드 환경 구현:
    이러한 아쉬움을 바탕으로, 이후 진행한 MoneyLog 프로젝트에서는 퍼블릭 클라우드와 온프레미스 환경을 Site-to-Site VPN으로 직접 연결하여, 완벽한 하이브리드 클라우드 아키텍처를 구축하며 당시의 한계를 성공적으로 극복했습니다.