[클라우드] VMware ESXi에서 OpenStack으로 전환한 실제 사례

VMware OpenStack 마이그레이션을 고민하는 분들이 요즘 정말 많으시죠. 라이선스 정책 변화나 비용 구조, 그리고 운영 자동화 수준을 다시 점검해야 하는 시점이 오면 결국 한 번은 ESXi OpenStack 전환을 검토하게 되더라고요. 저도 처음엔 “하이퍼바이저(Hypervisor, 가상화 실행 계층)만 바꾸면 끝나는 거 아닌가?” 싶었는데, 실제로 해보니 전혀 아니었습니다. 컴퓨트(Compute), 네트워크(Network), 스토리지(Storage), 이미지(Image) 관리 방식이 다 바뀌거든요. 그래서 오늘은 제가 홈랩과 내부 테스트 환경에서 진행했던 흐름을 바탕으로, VMware 대안 OpenStack을 검토할 때 어디서 막히고 어떻게 풀어야 하는지 경험 위주로 정리해보겠습니다.

특히 이 글은 “OpenStack이 좋아 보이는데 실제 전환은 어떻게 하지?”, “클라우드 마이그레이션 사례를 봐도 다 추상적이던데 실무 감각이 있는 글이 없네” 하셨던 분들께 맞춰 썼습니다. 숫자 뻥튀기나 과장 없이, 제가 직접 부딪히며 정리한 포인트만 담아볼게요.

기존 ESXi 가상머신이 이미지 변환과 네트워크 재설계를 거쳐 OpenStack으로 이동하는 전체 흐름을 보여주는 개요 이미지입니다.

왜 VMware ESXi에서 OpenStack으로 옮기게 될까요

쉽게 말해서 ESXi는 가상화 플랫폼 중심의 운영 경험을 주고, OpenStack은 클라우드 운영체계에 가깝습니다. 둘 다 가상머신(VM, Virtual Machine)을 띄운다는 점은 같지만, 운영 철학이 꽤 다릅니다. VMware 환경은 관리 콘솔이 잘 정리되어 있고 초기 안정화가 쉬운 편이죠. 반면 OpenStack은 구성 요소가 많아서 처음엔 복잡해 보이지만, 자동화와 API(Application Programming Interface, 프로그램 제어 인터페이스) 중심 운영으로 넘어가면 확실히 강점이 있습니다.

제가 전환을 결심했던 이유도 단순했습니다.

• 비용 구조를 장기적으로 통제하고 싶었습니다.
• API 기반 자동화를 더 강하게 가져가고 싶었습니다.
• 네트워크를 더 세밀하게 분리하고 싶었습니다.
• 벤더 종속성(Vendor lock-in, 특정 벤더 의존)을 줄이고 싶었습니다.

다만 여기서 중요한 게 하나 있어요. VMware OpenStack 마이그레이션은 제품 교체가 아니라 운영 모델 전환이라는 점입니다. 이거 무시하면 중간에 꼭 한 번 크게 흔들려요. 저도 처음엔 VM만 잘 옮기면 될 줄 알았는데, 보안그룹(Security Group, 가상 방화벽), 네트워크 세그먼트, 스토리지 타입 설계에서 삽질 좀 했습니다 ㅎㅎ

핵심 개념 정리: ESXi와 OpenStack은 무엇이 다를까

이 부분은 꼭 짚고 넘어가야 해요. 독자분들이 제일 많이 헷갈려 하시는 부분이거든요.

쉽게 말해서 VMware에서는 사람이 콘솔에서 정리해주는 느낌이 강했다면 OpenStack은 “정책과 API로 자원을 선언적으로 다룬다”는 느낌이 더 강합니다. 그래서 클라우드 마이그레이션 사례를 볼 때도 VM 파일 이동만 보면 안 되고, 네트워크와 접근제어를 같이 봐야 합니다.

전환 전에 꼭 분류해야 할 워크로드

1. 상태 저장형(Stateful)인지 확인합니다. 데이터베이스처럼 디스크 의존도가 높으면 더 신중해야 합니다.
2. 정적 IP, MAC 의존성이 있는지 봅니다. 방화벽이나 라이선스 서버가 여기서 많이 걸립니다.
3. 운영체제 부팅 방식이 BIOS인지 UEFI인지 점검합니다.
4. 게스트 OS 안에 VMware Tools 의존 설정이 있는지 확인합니다.
5. 백업/복구 체계가 OpenStack 쪽에서도 유지되는지 따져봅니다.

제가 직접 해보니 이 분류 작업이 귀찮아 보여도 가장 중요했습니다. 이걸 대충 하면 나중에 전환 일정이 아니라 장애 대응 일정이 되어버립니다.

사전 준비: VMware OpenStack 마이그레이션 체크리스트

실전 들어가기 전에 제가 잡았던 기준은 아래와 같았습니다. 여기서 절반이 결정된다고 봐도 됩니다.

• 대상 VM 목록: 운영, 스테이징, 개발을 분리합니다.
• 종속성 매핑: DB, 외부 API, DNS, NTP, 라이선스 서버 연결을 정리합니다.
• 네트워크 설계: OpenStack 테넌트 네트워크와 외부 네트워크를 미리 정의합니다.
• 이미지 변환 절차: VMDK에서 QCOW2 또는 RAW로 갈지 정합니다.
• 전환 방식: 빅뱅(Big Bang)보다 단계적 전환을 권장합니다.
• 롤백 계획: 문제 생기면 다시 ESXi에서 기동할 수 있게 둡니다.

저는 처음에 네트워크를 나중에 맞추면 되겠지 하고 넘어갔다가, OpenStack의 포트(Port)와 보안그룹 정책 때문에 통신 확인에 시간을 꽤 썼습니다. VM 부팅보다 통신 성공이 더 어렵더라고요.

실전 구현 1: ESXi VM 추출과 디스크 변환

이제 본론입니다. 제가 많이 썼던 흐름은 VM 종료 – 디스크 추출 – 이미지 변환 – OpenStack 업로드 – 테스트 부팅 순서였습니다. 무중단 전환이 절대적으로 필요한 서비스가 아니라면, 이 방식이 가장 단순하고 예측 가능했습니다.

1. VMware 쪽 VM 상태 확인

govc vm.info -vm /Datacenter/vm/app-server-01

govc는 VMware vSphere 환경을 CLI(Command Line Interface, 명령행 인터페이스)로 다룰 때 꽤 유용합니다. 환경에 따라 vCenter를 쓰지 않고 직접 ESXi에서 파일을 꺼낼 수도 있습니다.

2. OVF 또는 VMDK 형태로 추출

ovftool vi://[email protected]@vcenter.example.local/Datacenter/vm/app-server-01 ./app-server-01

환경에 따라 OVA/OVF 패키지로 받거나 VMDK만 직접 확보해도 됩니다. 저는 처음엔 OVA가 편해 보여서 그렇게 했는데, 실제로는 디스크 변환만 필요할 때 VMDK 직취득이 더 단순한 경우도 있었습니다.

3. VMDK를 QCOW2로 변환

qemu-img convert -p -f vmdk -O qcow2 app-server-01-disk1.vmdk app-server-01.qcow2
qemu-img info app-server-01.qcow2

여기서 qemu-img는 거의 필수 도구라고 보시면 됩니다. 변환 후 qemu-img info로 포맷과 가상 크기를 꼭 확인하세요. 저는 한 번은 스냅샷 체인이 남은 VMDK를 잘못 잡아서 이미지가 이상하게 올라간 적이 있었습니다.

VMDK 추출, qemu-img 변환, Glance 업로드로 이어지는 실제 작업 흐름을 설명하는 이미지입니다.

실전 구현 2: OpenStack 이미지 업로드와 네트워크 구성

OpenStack으로 넘어오면 이제부터는 이미지와 네트워크가 핵심입니다. 이 구간에서 “드디어 됐다!” 싶다가도 보안그룹 하나 빠뜨리면 SSH도 안 붙고, 웹도 안 열리고, 괜히 이미지 탓하게 됩니다.

1. 이미지 등록

openstack image create "app-server-01" \
  --file app-server-01.qcow2 \
  --disk-format qcow2 \
  --container-format bare \
  --private

OpenStack의 Glance는 이미지 저장소 역할을 합니다. 템플릿 개념과 비슷하지만, API 중심 운영에 더 잘 녹아 있습니다.

2. 네트워크와 서브넷 준비

openstack network create prod-net
openstack subnet create prod-subnet \
  --network prod-net \
  --subnet-range 192.168.100.0/24 \
  --dns-nameserver 8.8.8.8

물론 실무에서는 외부 DNS를 그대로 넣기보다 내부 DNS 체계를 맞추는 경우가 많습니다. 여기서는 예시만 단순하게 보여드리는 거예요.

3. 보안그룹 생성

openstack security group create web-sec
openstack security group rule create --protocol tcp --dst-port 22 web-sec
openstack security group rule create --protocol tcp --dst-port 80 web-sec
openstack security group rule create --protocol tcp --dst-port 443 web-sec

여기서 중요한 포인트! VMware 쪽에서는 포트 그룹과 상위 방화벽 정책으로 어느 정도 익숙하게 처리되던 것이, OpenStack에서는 인스턴스 단위 정책으로 체감될 때가 있습니다. 처음엔 이게 뭔가 싶었는데, 익숙해지면 오히려 훨씬 명확합니다.

4. 인스턴스 기동

openstack server create app-server-01 \
  --flavor m1.medium \
  --image app-server-01 \
  --network prod-net \
  --security-group web-sec

이후 Floating IP(Floating IP, 외부 접근용 유동 IP)가 필요한 구조라면 외부 네트워크에 붙여줘야 합니다.

openstack floating ip create public-net
openstack server add floating ip app-server-01 203.0.113.10

⚠️ 실제로 많이 막히는 문제들: ESXi OpenStack 전환 트러블슈팅

여기가 제일 중요합니다. 성공 사례는 대부분 결과만 보여주는데, 실무에서는 이 구간이 진짜 본게임입니다.

1. 부팅은 되는데 네트워크가 안 붙는 경우

원인은 보통 세 가지였습니다.

• 게스트 OS 안에 VMware 네트워크 인터페이스 설정이 남아 있는 경우
• udev 규칙 때문에 NIC 이름이 바뀌는 경우
• OpenStack 보안그룹에서 필요한 포트가 안 열린 경우

리눅스는 부팅 후 인터페이스 이름을 먼저 확인했습니다.

ip addr
ip route
journalctl -b | grep -i network

특히 CentOS나 Ubuntu 구버전 계열은 예전 NIC 정보 때문에 인터페이스가 달라지는 일이 종종 있었습니다. 저는 이 문제를 몇 번 겪고 나서는 이미지 올리기 전에 네트워크 설정 파일을 먼저 정리하는 습관이 생겼습니다.

2. 디스크는 붙었는데 부팅이 불안정한 경우

이건 VirtIO(Virtual I/O, 가상 장치 고속 드라이버) 드라이버나 부팅 로더 문제일 때가 많았습니다. 윈도우 게스트는 VirtIO 드라이버 준비 여부를 꼭 점검하셔야 하고, 리눅스는 initramfs 안에 필요한 드라이버가 포함됐는지 보는 게 좋습니다.

3. 시간이 틀어지거나 애플리케이션이 이상 동작하는 경우

NTP(Network Time Protocol, 시간 동기화)와 DNS는 가볍게 보면 안 됩니다. OpenStack 쪽 인스턴스가 올라오고 서비스는 떠 있는데, 인증이나 토큰 검증이 계속 실패하면 시간 동기화부터 보셔야 합니다. 이거 진짜 자주 놓칩니다.

4. 스냅샷 의존 운영 습관

VMware에서 스냅샷을 임시 안전장치처럼 쓰던 습관이 있으면 OpenStack으로 넘어와서 운영 방식 자체를 다시 잡아야 합니다. 인스턴스 스냅샷, 볼륨 스냅샷, 이미지 버전 관리, 백업 정책을 분리해서 생각해야 하거든요. 저도 처음엔 “스냅샷 느낌이 왜 다르지?” 싶었는데, 클라우드식 운영으로 사고방식을 바꾸니까 정리가 되더라고요.

테넌트 네트워크, 라우터, 보안그룹, 플로팅 IP 관계와 함께 통신 장애 포인트를 표시하는 설명 이미지입니다.

검증 방법: 클라우드 마이그레이션 사례에서 놓치면 안 되는 체크

전환이 끝났다고 바로 운영으로 넘기면 안 됩니다. 저는 아래 순서로 검증했습니다.

1. 인스턴스 상태 확인: ACTIVE 상태인지, 콘솔 로그에 에러가 없는지 봅니다.
2. 네트워크 점검: 내부 통신, 외부 통신, DNS 해석을 확인합니다.
3. 애플리케이션 점검: 웹, API, 배치 작업, 데이터 연결을 확인합니다.
4. 성능 비교: 최소한 부팅 시간, 응답성, 디스크 지연 체감은 체크합니다.
5. 운영 도구 점검: 백업, 모니터링, 로그 수집이 붙는지 확인합니다.

openstack server list
openstack console log show app-server-01
ping -c 4 192.168.100.10
curl -I http://192.168.100.10

여기서 제가 제일 강조하고 싶은 건, VM이 떠 있는 것과 서비스가 정상인 것은 다르다는 점입니다. 실제로는 애플리케이션 레벨 체크가 마지막 문턱이었습니다.

마이그레이션 이후 인스턴스 상태, 네트워크 연결, 서비스 응답을 한눈에 확인하는 검증 대시보드 이미지입니다.

전환 결과: 제가 얻은 것과 예상 밖의 변화

결론부터 말씀드리면, 제 경우엔 VMware OpenStack 마이그레이션 자체는 성공이었습니다. 특히 개발/스테이징 계열 워크로드에서는 OpenStack의 장점이 빨리 보였습니다. API로 인스턴스를 만들고, 네트워크를 분리하고, 이미지 기반으로 재현 가능한 환경을 만드는 흐름이 아주 좋았거든요.

반대로 예상보다 시간이 더 걸린 부분도 있었습니다.

• 운영팀의 사고방식 전환: 가상머신 관리에서 클라우드 자원 관리로 바뀝니다.
• 네트워크 설계: OpenStack Neutron 이해도가 없으면 초반에 막힙니다.
• 표준 이미지 전략: 아무 VM이나 옮기는 방식은 오래 못 갑니다.

즉, VMware 대안 OpenStack은 충분히 현실적인 선택지이지만, “기존 VM을 그냥 다른 데 올린다”는 접근으로는 만족도가 떨어질 수 있습니다. 반대로 이미지 표준화, 자동화, 셀프서비스 포털, IaC(Infrastructure as Code, 코드형 인프라)까지 연결하면 진가가 나옵니다.

정리와 다음 단계: 이런 순서로 접근하면 덜 흔들립니다

혹시 지금 전환을 검토 중이시라면, 제가 추천하는 순서는 이렇습니다.

1. 가장 덜 중요한 개발 VM부터 파일럿으로 옮깁니다.
2. 이미지 변환 절차를 문서화합니다.
3. 네트워크와 보안그룹 템플릿을 먼저 만듭니다.
4. 백업, 모니터링, 로그 수집을 붙인 뒤 운영계로 확장합니다.
5. 마지막에 표준 이미지와 자동 배포 흐름까지 정리합니다.

사실 저도 처음엔 OpenStack이 너무 많은 조각으로 보였는데, 하나씩 이해하고 나니 왜 다들 클라우드 운영체계라고 부르는지 알겠더라고요. 반대로 VMware에서 익숙했던 편의 기능이 사라진 듯 느껴지는 순간도 있었는데, 그건 “없다”기보다 “다른 방식으로 설계해야 한다”에 가까웠습니다.

이전 글에서 다뤘던 가상화 스토리지 설계 내용과도 연결되는 부분이 있고, 다음 글에서는 OpenStack에서 표준 이미지와 cloud-init(cloud-init, 초기 부팅 자동 설정)를 묶어 운영하는 방법도 다뤄볼 예정입니다. 여기까지 정리해보니, 결국 성공 포인트는 기술 하나가 아니라 운영 모델의 재설계였습니다.

운영 모델, 네트워크, 스토리지, 자동화 관점에서 VMware와 OpenStack의 차이를 요약한 마무리 인포그래픽입니다.

자주 묻는 질문

Q1. ESXi에서 OpenStack으로 무중단 전환이 가능한가요?

가능 여부는 애플리케이션 구조에 달려 있습니다. 일반적인 단일 VM 서비스는 점검 시간을 잡고 이미지 기반으로 옮기는 편이 더 현실적이었습니다.

Q2. 모든 VMware VM이 그대로 OpenStack에서 잘 동작하나요?

아닙니다. 네트워크 설정, 드라이버, 부팅 방식, 에이전트 의존성에 따라 손봐야 할 부분이 꽤 있습니다. 특히 오래된 VM일수록 사전 점검이 중요합니다.

Q3. OpenStack이 무조건 비용 절감으로 이어지나요?

단순히 플랫폼만 바꾼다고 바로 그렇진 않습니다. 운영 역량, 자동화 수준, 표준화 정도가 함께 따라와야 의미 있는 효과가 납니다.

Q4. 가장 먼저 테스트할 워크로드는 무엇이 좋을까요?

개발 또는 스테이징 환경의 웹 애플리케이션부터 권장합니다. 네트워크와 이미지 변환 절차를 검증하기에 적당하고, 실패했을 때 영향도 상대적으로 적습니다.