[인프라] OpenStack Ironic으로 베어메탈 서버 자동 프로비저닝 실전 사례

목차

• 1. 왜 베어메탈 자동화가 필요했는가
• 2. OpenStack Ironic 개념을 쉽게 풀어보면
• 3. 실전 사례: OpenStack Ironic 베어메탈 프로비저닝 구성 방식
• 4. OpenStack Ironic 베어메탈 프로비저닝 구현 단계
• 4-1. 네트워크와 부트 방식 먼저 정리
• 4-2. 노드 등록과 BMC 정보 입력
• 4-3. 포트 연결과 배포 이미지 지정
• 4-4. 상태 전환과 배포 실행
• 5. OpenStack Ironic 베어메탈 프로비저닝: 운영 기준과 설정 예시
• 6. ⚠️ 실제로 겪었던 문제와 해결 방법
• 6-1. PXE는 되는데 베어메탈 배포가 중간에 멈추는 문제
• 6-2. BMC 연결은 되는데 전원 제어가 불안정한 문제
• 6-3. 디스크 선택이 꼬여 OS가 원하지 않는 장치에 설치되는 문제
• 7. 검증과 결과: 서버 프로비저닝이 얼마나 달라졌나
• 8. 정리: OpenStack Ironic 도입 전에 꼭 체크할 것
• 9. 자주 묻는 질문
• Q1. Ironic은 꼭 OpenStack 전체를 다 써야 하나요?
• Q2. 베어메탈 자동화가 작은 환경에도 의미가 있나요?
• Q3. Ironic 베어메탈 프로비저닝 활용 사례에서 가장 먼저 검증할 것은 뭔가요?

[인프라] OpenStack Ironic으로 베어메탈 서버 자동 프로비저닝 실전 사례

OpenStack Ironic 베어메탈 프로비저닝을 처음 제대로 붙잡았던 이유는 단순했습니다. 가상머신은 너무 익숙했는데, 정작 성능이 중요한 워크로드는 결국 물리 서버에 올려야 했거든요. 문제는 여기서부터였습니다. 서버를 한 대씩 BIOS 확인하고, PXE 부팅 잡고, 운영체제 이미지 밀어 넣고, 네트워크 맞추고, 다시 검증하는 과정을 반복하다 보니 사람이 할 일이 너무 많아지더라고요. 특히 서버가 3대, 5대, 10대로 늘어나면 그때부터는 실수도 같이 늘어납니다. 그래서 저는 OpenStack Ironic(아이로닉, 베어메탈 프로비저닝 서비스)을 도입해서 베어메탈 자동화 흐름을 만들었고, 실제로 운영 편의성이 얼마나 달라지는지 체감했습니다.

혹시 이런 경험 있으신가요? 분명 같은 모델 서버인데도 한 대는 잘 올라오고, 한 대는 PXE에서 멈추고, 또 다른 한 대는 디스크 클리닝(cleaning) 단계에서 실패하는 상황이요. 저도 처음엔 이게 뭔가 싶었는데, 흐름을 한 번 제대로 잡고 나니까 서버 프로비저닝이 훨씬 예측 가능해졌습니다. 이번 글에서는 제가 직접 해보면서 정리한 OpenStack Ironic 베어메탈 프로비저닝 실전 사례를 기준으로, 개념부터 실제 등록과 배포, 그리고 삽질 포인트까지 차근차근 풀어보겠습니다.

OpenStack Ironic, PXE 네트워크, 이미지 서비스, 관리 네트워크, 물리 서버 간의 전체 흐름을 한눈에 보여주는 아키텍처 예시입니다.

1. 왜 베어메탈 자동화가 필요했는가

제가 처음 자동화를 검토했던 환경은 대규모 클라우드까지는 아니고, 홈랩과 소규모 사내 테스트 랙(rack, 서버 장비 거치대)이 섞인 형태였습니다. 쿠버네티스 워커 노드, 스토리지 노드, 네트워크 기능 테스트 장비가 계속 늘어나는데, 설치 방법은 여전히 수동이었죠. 이러면 반복 작업이 많아질 뿐 아니라, 누가 언제 어떤 이미지로 설치했는지 추적도 어려워집니다.

• 반복 작업 제거: 동일 OS 이미지와 네트워크 정책을 여러 서버에 일관되게 적용
• 실수 감소: 수동 설치 중 IP, RAID, 부트 모드 입력 오류 감소
• 재현성 확보: 장애 후 재배포(re-deploy) 시간이 짧아짐
• 운영 표준화: 서버 모델이 달라도 등록 절차를 표준 흐름으로 묶기 쉬움

여기서 중요한 포인트가 있습니다. 베어메탈 자동화는 단순히 설치를 편하게 하는 수준이 아니라, 물리 서버를 가상 리소스처럼 다루기 시작하는 첫 단계라는 점입니다. 실제로 써보니까 운영 관점이 바뀌더라고요. 서버를 장비가 아니라 풀(pool, 자원 집합)로 보게 됩니다.

2. OpenStack Ironic 개념을 쉽게 풀어보면

쉽게 말해 Ironic은 물리 서버를 API로 관리해 주는 서비스입니다. 가상머신을 Nova(노바, 컴퓨트 서비스)로 다루듯이, 베어메탈 서버는 Ironic으로 전원 제어, 부팅 제어, 이미지 배포, 상태 전환을 처리합니다.

처음엔 용어가 좀 낯설 수 있습니다. 저도 처음엔 conductor가 뭐고 inspector가 뭐고 헷갈렸거든요. 실무에서는 아래 정도만 먼저 잡아도 흐름이 보입니다.

구성 요소	역할	현장에서 이해한 방식
Ironic API	베어메탈 요청 접수	사용자나 자동화 도구가 호출하는 입구
Ironic Conductor	실제 작업 실행	전원 제어, 배포, 상태 변경을 수행하는 엔진
PXE / iPXE	네트워크 부팅	로컬 디스크 없이 초기 부팅을 유도하는 통로
IPA	Ironic Python Agent	부팅 후 디스크 작업과 배포를 수행하는 에이전트
BMC	Baseboard Management Controller	IPMI나 Redfish로 원격 전원/부트 제어
Glance	이미지 저장소	배포할 운영체제 이미지를 보관하는 위치

Ironic 베어메탈 프로비저닝 활용 사례로는 쿠버네티스 노드 자동 공급, Ceph(세프, 분산 스토리지) 스토리지 노드 배포, 테스트 장비 재설치 자동화가 대표적입니다. 특히 성능 오버헤드가 민감한 데이터 처리 워크로드에서는 가상화보다 베어메탈이 낫다고 판단하는 경우가 꽤 있죠.

3. 실전 사례: OpenStack Ironic 베어메탈 프로비저닝 구성 방식

이번 사례는 특정 벤더 기능에 기대지 않는, 비교적 범용적인 구성입니다. 관리 네트워크(management network)와 프로비저닝 네트워크(provisioning network)를 분리하고, BMC는 Redfish(레드피시, 표준 하드웨어 관리 API) 또는 IPMI 기반으로 접근했습니다. 디스크는 로컬 SSD를 사용했고, 운영체제 이미지는 일반적인 리눅스 클라우드 이미지 계열을 기준으로 배포했습니다.

1. 서버 랙 장착 및 BMC IP 할당
2. Ironic에 노드 등록
3. 포트(MAC 주소) 연결
4. 하드웨어 introspection(인트로스펙션, 자동 탐지) 또는 수동 속성 입력
5. deploy image 연결
6. manageable → available 상태 전환
7. 베어메탈 서버 deploy 실행 및 부팅 검증

이 흐름을 한 번 만들어 두면 신규 서버 반입 때 정말 편합니다. 예전에는 체크리스트를 사람이 읽으면서 따라갔는데, 이제는 등록 정보만 맞으면 나머지는 훨씬 기계적으로 흘러갑니다. 드디어 됐다 싶었던 순간이 여기였네요.

4. OpenStack Ironic 베어메탈 프로비저닝 구현 단계

4-1. 네트워크와 부트 방식 먼저 정리

여기서 가장 많이 꼬입니다. Ironic 자체보다 PXE 네트워크가 더 큰 함정일 때가 많거든요. DHCP 범위, TFTP 또는 HTTP 부트 경로, UEFI/Legacy BIOS 모드가 서로 안 맞으면 배포가 시작도 안 됩니다. 저는 가능하면 UEFI 기준으로 통일하려고 했고, 스위치 포트 VLAN도 먼저 점검했습니다.

openstack network list
openstack subnet list
openstack baremetal driver list
openstack baremetal node list

처음엔 단순히 노드만 등록하면 될 줄 알았는데, 실제로는 부팅 경로와 네트워크 경로가 먼저 안정화되어야 하더라고요. 특히 ToR(Top of Rack, 랙 상단 스위치) 쪽 포트 프로파일이 꼬여 있으면 증상이 굉장히 애매합니다.

프로비저닝 VLAN, DHCP, HTTP/TFTP 부트, Ironic Conductor, 대상 서버 사이의 실제 데이터 흐름을 설명하는 이미지입니다.

4-2. 노드 등록과 BMC 정보 입력

다음은 물리 서버를 Ironic에 등록하는 단계입니다. 아래 예시는 개념을 보여주기 위한 형태이고, 환경에 맞게 driver와 driver-info 항목은 조정하시면 됩니다.

openstack baremetal node create \
  --driver redfish \
  --name bm-node-01

openstack baremetal node set bm-node-01 \
  --driver-info redfish_address=https://192.0.2.10/redfish/v1/Systems/1 \
  --driver-info redfish_username=admin \
  --driver-info redfish_password='REDACTED' \
  --property cpus=16 \
  --property memory_mb=65536 \
  --property local_gb=480 \
  --resource-class baremetal-general

여기서 팁 하나요. 저는 초반에 서버 스펙을 전부 수동 입력했었는데, 장비가 늘어나면 이게 은근히 실수를 부릅니다. introspection을 쓸 수 있는 환경이라면 자동 탐지를 적극 활용하는 편이 낫습니다. 다만 자동 탐지 결과도 100% 맹신하면 안 되고, 디스크 수나 NIC 매핑은 꼭 눈으로 한 번 보셔야 합니다.

4-3. 포트 연결과 배포 이미지 지정

openstack baremetal port create aa:bb:cc:dd:ee:ff \
  --node bm-node-01

openstack baremetal node set bm-node-01 \
  --instance-info image_source=<IMAGE_UUID> \
  --instance-info root_gb=50

이미지 소스는 보통 Glance 이미지 UUID를 사용합니다. 저 같은 경우에는 운영체제 이미지 템플릿을 최소화해서 관리했는데, 이게 나중에 패치 기준점 맞추기가 편하더라고요. 이미지가 너무 많으면 자동화가 아니라 이미지 스파게티가 됩니다.

4-4. 상태 전환과 배포 실행

openstack baremetal node manage bm-node-01
openstack baremetal node provide bm-node-01
openstack baremetal node deploy bm-node-01

Ironic은 상태(state)가 중요합니다. manageable, available, active 같은 상태 전환을 이해하지 못하면 왜 명령이 거부되는지 감이 안 옵니다. 저도 처음엔 deploy가 왜 안 되나 한참 봤는데, 앞단 상태가 안 맞았던 적이 꽤 많았습니다. 이 부분은 로그와 상태를 같이 보면서 익숙해지는 수밖에 없어요.

5. OpenStack Ironic 베어메탈 프로비저닝: 운영 기준과 설정 예시

실전에서는 단순 명령 몇 줄보다 운영 기준이 더 중요합니다. 어떤 노드를 어떤 용도로 쓸지, cleaning(클리닝, 디스크 초기화) 정책을 어디까지 강제할지, RAID 구성은 수동으로 둘지 자동으로 둘지 같은 정책이 먼저 있어야 자동화가 깔끔해집니다.

nodes:
  - name: bm-node-01
    driver: redfish
    resource_class: baremetal-general
    boot_mode: uefi
    bmc:
      address: https://192.0.2.10/redfish/v1/Systems/1
      username: admin
    network:
      provisioning_mac: aa:bb:cc:dd:ee:ff
    deploy:
      image: ubuntu-base
      root_gb: 50

저는 내부적으로 노드 인벤토리를 YAML 형태로 관리해 두고, 이후 등록 자동화 스크립트에서 읽어 쓰는 방식으로 정리했습니다. 이게 생각보다 큽니다. 사람이 콘솔에서 매번 입력하면 언젠가 오타가 나거든요.

• 리소스 클래스(resource class)를 미리 정의해 워크로드 분류를 단순화
• 부트 모드 통일로 장애 포인트 감소
• 이미지 수 최소화로 운영 복잡도 감소
• 인벤토리 코드화로 반복 등록 절차 표준화

노드 이름, 드라이버, BMC 정보, 포트, 상태 전환 흐름이 한 번에 보이도록 구성한 운영 화면 예시입니다.

6. ⚠️ 실제로 겪었던 문제와 해결 방법

이 섹션이 아마 제일 현실적일 겁니다. 문서만 보면 다 잘 될 것 같은데, 실제 현장에서는 작은 불일치가 줄줄이 터집니다. 삽질 좀 했습니다 ㅎㅎ

6-1. PXE는 되는데 베어메탈 배포가 중간에 멈추는 문제

증상은 간단했습니다. 서버가 네트워크 부팅까지는 들어오는데, 에이전트가 올라온 뒤 이미지 배포 단계에서 멈추는 겁니다. 처음엔 이미지 문제인 줄 알았는데, 실제 원인은 프로비저닝 네트워크의 MTU와 업링크 설정 차이였습니다. 패킷 손실이 눈에 띄게 보이지 않아서 더 헷갈렸습니다.

• 에이전트가 올라오는지 확인
• Conductor 로그에서 타임아웃 여부 확인
• 프로비저닝 VLAN 경로 MTU 점검
• 이미지 다운로드 경로의 HTTP 접근성 확인

6-2. BMC 연결은 되는데 전원 제어가 불안정한 문제

이건 장비별 구현 차이 영향이 컸습니다. 같은 표준을 써도 Redfish 구현이 미묘하게 다르더라고요. 그래서 저는 가능하면 펌웨어 상태를 먼저 맞추고, 드라이버 타입을 혼용하지 않도록 정리했습니다. 환경에 따라 IPMI보다 Redfish가 더 안정적일 때도 있었고, 반대 경우도 있었습니다. 결국 중요한 건 표준 이름보다 내 장비에서 실제로 일관되게 동작하느냐였습니다.

6-3. 디스크 선택이 꼬여 OS가 원하지 않는 장치에 설치되는 문제

NVMe와 SATA SSD가 같이 있는 서버에서 이 문제가 나왔습니다. 에이전트가 잡는 장치 순서와 사람이 기대한 순서가 다를 수 있거든요. 그래서 배포 정책에서 디스크 선택 기준을 명확히 정하고, 가능하면 장치 특성 기반으로 선택하도록 운영 기준을 잡았습니다. 여기서 중요한 포인트! 베어메탈 자동화는 결국 하드웨어 다양성을 어떻게 통제하느냐의 싸움입니다.

7. 검증과 결과: 서버 프로비저닝이 얼마나 달라졌나

배포 후에는 단순히 active 상태만 보면 안 됩니다. 저는 최소한 아래 항목은 꼭 확인했습니다.

1. Ironic 상태가 active로 전환되었는지 확인
2. 운영체제가 정상 부팅되고 SSH 접근이 되는지 확인
3. 의도한 NIC와 IP 정책이 적용되었는지 확인
4. 디스크 레이아웃과 파일시스템이 기대값과 맞는지 확인
5. 재배포 시 동일 절차가 반복 가능했는지 확인

openstack baremetal node show bm-node-01
openstack baremetal node validate bm-node-01

실제로 써보니까 가장 큰 변화는 속도보다도 예측 가능성이었습니다. 예전에는 "이번에도 잘 되겠지"에 가까웠다면, 자동화 이후에는 "어디가 실패하면 무엇을 보면 된다"로 바뀌었습니다. 운영자는 이 차이를 굉장히 크게 느낍니다. 장애 대응 시간도 줄고, 신규 서버 투입 부담도 확실히 낮아졌습니다.

active 상태 전환, 배포 성공, 네트워크 연결, 운영체제 부팅 검증 결과를 시각적으로 요약한 이미지입니다.

8. 정리: OpenStack Ironic 도입 전에 꼭 체크할 것

OpenStack Ironic 베어메탈 프로비저닝은 분명 강력합니다. 하지만 설치 툴 하나 추가하는 수준으로 보면 실망할 수 있습니다. 이건 물리 서버 운영 체계를 재정리하는 일에 가깝거든요. 제가 직접 해보니 아래 네 가지가 성공 확률을 많이 좌우했습니다.

• 네트워크 표준화: 프로비저닝 경로와 VLAN 정책을 먼저 안정화할 것
• 하드웨어 편차 관리: 서버 모델, NIC, 디스크 구성을 가능한 한 단순화할 것
• 상태 기반 운영: node state와 로그를 함께 보는 습관을 들일 것
• 인벤토리 자동화: 등록 정보를 코드처럼 관리할 것

도입 전 방식	Ironic 도입 후 방식
서버별 수동 설치	API 기반 반복 배포
작업자 숙련도 의존	절차 표준화
문제 원인 추적 어려움	상태와 로그 기반 추적
재설치 시간 편차 큼	재현성 높은 서버 프로비저닝

혹시 지금 물리 서버를 계속 수동으로 설치하고 계시다면, 작은 랩 환경에서라도 먼저 시도해 보시는 걸 권합니다. 처음엔 헷갈립니다. 저도 그랬습니다. 근데 한 번 흐름을 이해하고 나면 이거 진짜 편하더라고요. 다음 글에서는 Ironic과 Inspector(인스펙터, 하드웨어 자동 탐지)를 엮어서 장비 등록을 더 줄이는 방향도 다뤄볼 예정입니다. 이전 글에서 다뤘던 PXE 네트워크 설계와 함께 보시면 훨씬 연결이 잘 되실 겁니다.

수동 설치와 자동화된 베어메탈 프로비저닝의 차이, 그리고 도입 전 체크리스트를 한 장으로 정리한 요약 이미지입니다.

9. 자주 묻는 질문

Q1. Ironic은 꼭 OpenStack 전체를 다 써야 하나요?

반드시 그렇지는 않습니다. 다만 실제 운영에서는 네트워크, 이미지, 인증 체계와의 연동이 중요해서 보통은 OpenStack 구성 요소와 함께 보는 편이 자연스럽습니다.

Q2. 베어메탈 자동화가 작은 환경에도 의미가 있나요?

의미 있습니다. 특히 재설치가 잦거나, 쿠버네티스 노드를 자주 교체하는 환경이라면 규모가 작아도 체감이 큽니다.

Q3. Ironic 베어메탈 프로비저닝 활용 사례에서 가장 먼저 검증할 것은 뭔가요?

저는 네트워크 부팅 경로와 BMC 안정성을 먼저 봅니다. 이 두 가지가 흔들리면 나머지 자동화가 전부 불안정해지거든요.

📚 함께 읽으면 좋은 글

• OpenStack Swift vs Ceph 선택 기준 심층 비교
• 오픈스택 플레이버 최적화로 유휴 자원 줄이기
• OpenStack Cinder 볼륨 생성 실패? 흔한 원인과 해결책
• Terraform Proxmox Provider 활용: VM 자동 프로비저닝 심층 분석