On-Premise 2026.10.20 5 min read

클라우드 대신 ESXi 두 대로 시작한 인프라 자동화 환경

처음 학습 문서에서는 Proxmox와 Harbor, HAProxy, Keepalived도 검토했다. 하지만 실제로 구축하며 선택한 구성은 달랐다. 최종 환경을 설명할 때 처음 그린 그림과 실제 설치한 제품을 섞지 않는 것부터 시작했다.

추가 프로젝트를 구상하면서 클라우드 비용을 고려했다. 이미 사용할 수 있는 물리 서버가 있었고, 이번에는 VM 생성부터 서버 구성, 애플리케이션 배포까지 직접 연결해보고 싶었다. 그래서 온프레미스에 ESXi 두 대와 vCenter를 놓는 것으로 기반을 잡았다.

처음 학습 문서에서는 Proxmox와 Harbor, HAProxy, Keepalived도 검토했다. 하지만 실제로 구축하며 선택한 구성은 달랐다. 최종 환경을 설명할 때 처음 그린 그림과 실제 설치한 제품을 섞지 않는 것부터 시작했다.

호스트 두 대를 vCenter에서 관리했다

ESXi 두 대를 설치하고 vCenter 설치의 Step 1과 Step 2를 마쳤다. vCenter 안에서 Datacenter와 클러스터를 만든 뒤 두 호스트를 등록했다. 이후 Terraform이 조회할 대상도 이 인벤토리를 기준으로 삼았다.

작업 환경은 ESXi 8과 vCenter 8 계열이었다. 초기에 갖고 있던 6.7 ISO를 사용할 수 있는지도 물었지만, 그 파일 문의와 실제 구축 버전은 구별했다. 이름이 비슷한 설치 파일을 갖고 있다는 사실만으로 실행 환경을 설명하면 이후 호환성이나 설정을 되짚을 때 기준이 어긋날 수 있었다.

물리 서버에는 1Gbps 포트가 여러 개 있었지만, 연결한 관리 스위치 구간은 100Mbps였다. 서버의 NIC 사양이 곧 전체 경로의 속도는 아니었다. 이 제약은 이후 vMotion과 NFS를 직결망으로 분리하는 이유가 됐다.

ESXi 두 호스트를 관리하는 Infra-Cluster 요약
Infra-Cluster의 HA 보호 상태와 vMotion 이동 기록.
ESXi01 모델과 버전·용량 요약
ESXi01: ProLiant DL360e Gen8, ESXi 8.0.3, 24 logical CPU, NIC 4개.

공유 저장소를 두고 VM을 올렸다

스토리지는 Ubuntu 서버의 NFS를 공유 datastore로 사용했다. ESXi 두 대가 같은 VM 파일에 접근할 수 있도록 구성하고, 이후 vCenter와 Kubernetes VM도 이 저장소를 사용했다. 가상화 호스트가 두 대여도 VM 파일이 한쪽 호스트의 로컬 디스크에만 있으면 다른 호스트에서 사용할 수 있는 범위가 달라졌다.

관리망은 기존 환경을 유지하고, 호스트 사이의 vMotion 경로와 NFS 접근 경로는 별도 NIC로 구성했다. 모든 네트워크를 한 번에 바꾸기보다 현재 환경의 제약을 기준으로 필요한 경로를 분리했다.

이때 공유 저장소는 NFS 서버 한 대였다. 호스트 두 대와 공유 datastore가 있다고 저장소까지 이중화한 것은 아니었다. 후속 실습에서 호스트 장애 시 VM을 다른 호스트에서 다시 시작하는 흐름을 확인하더라도, NFS 서버 자체는 계속 의존하는 대상이었다.

VM마다 맡길 역할을 나눴다

기반을 만든 뒤에는 자동화 서버와 CI 서버, Kubernetes 노드의 역할을 나눴다. 자동화 서버에는 Terraform과 Ansible, Jenkins Controller를 두었다. CI VM에는 Jenkins Agent와 사설 Registry를 배치하되 서로 다른 OS 계정으로 운영했다. 계정 분리와 VM 장애 영역 분리는 다른 범위로 봤다.

Kubernetes는 Control Plane 한 대와 Worker 두 대로 구성했다. 이 위에 기존에 개발하던 RCA Platform을 올리는 것이 후속 목표였다. VM을 생성하는 일, 게스트 OS를 준비하는 일, 클러스터를 구성하는 일, 애플리케이션을 배포하는 일을 각각 확인할 수 있는 구조로 잡았다.

처음부터 모든 제품을 넣는 것보다 각 도구가 맡을 대상을 정하는 편이 중요했다. Terraform은 vCenter의 인프라를, Ansible은 VM 안의 상태를 다루게 했다. 이후 Jenkins와 GitOps를 연결할 때도 이 역할 구분을 이어갔다.

관리·Kubernetes·CI VM을 함께 보여주는 클러스터 인벤토리
클러스터 VM 9개와 관리·Kubernetes·CI 역할 구성.

설치 뒤에는 연결 관계를 확인했다

vCenter에서 호스트가 보이는 것만으로 기반 작업이 끝나지는 않았다. 다음 단계에서는 실제 NIC 속도와 가상 스위치 uplink, 공유 저장소 용량, 호스트 장애 시 VM의 위치를 확인해야 했다. 화면에서 만든 논리 구성이 물리 연결과 맞지 않으면 VM을 옮기거나 파일을 읽는 단계에서 문제가 드러났다.

이 기반 위에서 VM 복제와 노드 구성을 자동화할 수 있었다. 다만 자동화가 다룰 환경을 먼저 이해해야 오류도 해석할 수 있었다. 뒤이어 겪은 vMotion 통신 실패와 NFS 용량 문제는 그 연결 관계를 하나씩 확인하는 과정이 됐다.

SEARCH JOURNAL

기록 검색

글 제목, 요약, 태그에서 찾습니다.

검색을 준비하고 있어요.

검색어를 입력해 주세요.

    Ctrl/⌘ K 검색 Esc 닫기 ↑ ↓ 결과 이동