Compute Platforms - 03. 베어메탈 프로비저닝

dongka · 2026. 7. 22. 19:11

USB 하나로 1000대를 설치할 수는 없다 — 베어메탈 프로비저닝

데이터센터에 서버 1000대가 배송됐다고 상상해 보자. 랙에 장착하고 전원을 넣는 건 사람이 한다. 그다음? 각 서버에 OS를 설치하고, 설정하고, 모니터링 에이전트를 깔고, 클러스터에 참여시켜야 한다. 클라우드의 "Launch Instance" 버튼 한 번이면 끝나는 일이 — 베어메탈 세계에선 수십 단계의 자동화 없이는 불가능하다. USB 하나씩 꽂아 설치하면 1000대에 몇 달이 걸리고, 그사이 일관성도 깨진다. 이 문제를 푸는 분야가 베어메탈 프로비저닝(bare-metal provisioning)이다. 물리 서버를 OS 설치부터 설정·클러스터 참여까지 자동화하는 일.

클라우드 시대에 "베어메탈 프로비저닝"은 구시대처럼 들린다. 하지만 여전히 쓰인다. foundations 05에서 본 37signals·Dropbox 같은 회사가 자체 인프라로 돌아간 이유는 — 베어메탈 비용이 클라우드보다 싸졌기 때문이다. 그 자체 인프라를 운영하려면 대규모 베어메탈 프로비저닝이 필수다. AWS·GCP·Azure도 자체 데이터센터엔 수십만 대의 베어메탈 서버를 두고, 그 위에 가상 머신을 띄워 우리에게 파는다. 클라우드의 밑바닥은 결국 베어메탈이다. 이 글은 그 밑바닥을 어떻게 자동화하는지 — PXE·IPMI·Redfish·cloud-init·Ironic을 다룬다.

베어메탈 프로비저닝이란

베어메탈 프로비저닝의 정의는 단순하다 — 물리 서버(bare metal)에 OS와 설정을 자동으로 설치하고 초기화하는 과정. "베어메탈"이라는 단어는 하이퍼바이저가 없는 순수한 물리 하드웨어를 가리킨다. 가상화 계층(VM·컨테이너)을 거치지 않고 하드웨어에 직접 OS를 올리는 것.

이 과정이 자동화돼야 하는 이유는 세 가지다.

첫째, 규모. 데이터센터 하나에 수천 ~ 수만 대의 서버가 있다. 한 대당 설치에 30분이 걸리면 만 대에 5개월이다. 사람이 못 한다.

둘째, 일관성. 서버마다 설정이 미세하게 다르면 (다른 패키지 버전, 다른 커널 파라미터, 다른 사용자 계정) — 나중에 디버깅이 지옥이 된다. foundations 06에서 본 "눈송이 서버" 문제가 여기서 발생한다.

셋째, 재현성. 한 서버가 고장 나서 교체할 때, 같은 설정으로 새 서버를 똑같이 만들 수 있어야 한다. 코드로 정의된 프로비저닝 절차가 없으면 — "저 퇴사한 관리자가 어떻게 설정했는지"를 알 수 없다.

flowchart TD
    RACK["랙에 서버 장착"] --> PWR["전원·네트워크 연결"]
    PWR --> BMC["BMC로 전원 인가<br/>(IPMI/Redfish)"]
    BMC --> PXE["PXE 부팅<br/>(DHCP + TFTP)"]
    PXE --> INSTALL["OS 자동 설치<br/>(kickstart/preseed)"]
    INSTALL --> CLOUDINIT["초기 설정<br/>(cloud-init)"]
    CLOUDINIT --> JOIN["클러스터 참여<br/>(Kubernetes, etc.)"]

이 흐름을 가능케 하는 기술 4개가 핵심이다 — PXE(네트워크 부팅), IPMI/Redfish(원격 제어), kickstart/preseed(OS 자동 설치), cloud-init(초기 설정). 순서대로 본다.

PXE — 네트워크로 부팅하기

02 글에서 UEFI가 부트로더를 찾는 경로를 봤다. 보통 로컬 디스크에서 GRUB을 찾지만 — PXE(Preboot eXecution Environment) 는 네트워크에서 부트로더를 찾는다. 디스크에 OS가 없어도, 네트워크만 연결돼 있으면 부팅할 수 있다. Intel이 1998년 발표한 표준으로, 거의 모든 서버 NIC에 PXE ROM이 내장돼 있다.

PXE 부팅의 흐름은 두 단계다.

sequenceDiagram
    participant NIC as 서버 NIC (PXE ROM)
    participant DHCP as DHCP 서버
    participant TFTP as TFTP 서버
    participant HTTP as HTTP 서버 (옵션)

    NIC->>DHCP: DHCP Discover (PXE 요청)
    DHCP->>NIC: DHCP Offer (IP + TFTP 서버 주소 + 부트로더 파일명)
    NIC->>TFTP: TFTP GET 부트로더 (pxelinux.0 / ipxe.efi)
    TFTP->>NIC: 부트로더 바이너리
    NIC->>NIC: 부트로더 실행
    NIC->>HTTP: 커널 + initramfs 요청 (보통 HTTP)
    HTTP->>NIC: 컨테이너 이미지
    NIC->>NIC: 커널 부팅 → OS 설치 시작

첫 단계는 DHCP. 서버가 켜지면 NIC이 DHCP 요청을 보낸다. 일반 DHCP와 다른 점은 — PXE 옵션이 들어간다는 것. DHCP 서버는 IP를 할당함과 동시에 "TFTP 서버 주소"와 "부트로더 파일명"을 알려준다(next-server와 filename 옵션).

두 번째 단계는 TFTP(Trivial FTP). 서버가 TFTP 서버에서 부트로더 바이너리를 다운로드한다. 전통적으로 pxelinux.0(SYSLINUX 프로젝트의 PXE 부트로더)를 썼다. TFTP는 단순한 프로토콜이라 빠르지만 — 큰 파일을 전송하는 데는 비효율적이다. 그래서 현대에는 부트로더로 iPXE를 많이 쓴다.

iPXE — PXE의 오픈소스 확장 버전. HTTP·iSCSI·Wi-Fi·Script 지원. TFTP 대신 HTTP로 커널과 initramfs를 받을 수 있어 대규모 배포에 유리하다. 부팅 스크립트로 복잡한 조건 분기(서버 시리얼 번호별 다른 이미지)를 처리할 수 있다. 클라우드 벤더와 대규모 데이터센터의 사실상 표준이다.

DHCP와 TFTP 설정은 dnsmasq나 ISC DHCP 서버로 한다. 예를 들어 dnsmasq의 설정 한 줄로 특정 MAC 주소를 가진 서버에 특정 부트로더를 지정할 수 있다 — "이 서버는 데이터베이스 노드니까 DB 이미지를 받아라" 식으로.

OS 자동 설치 — kickstart와 preseed

PXE로 부트로더와 커널을 올렸으면, 이제 OS를 설치해야 한다. 보통 배포판 설치 프레임워크(Anaconda·debian-installer)를 "무인(unattended)" 모드로 돌린다. 설치 중 묻는 질문(언어·타임존·디스크 파티셔닝·root 비밀번호·설치할 패키지)을 미리 파일로 적어두면, 설치 프로그램이 그 파일을 읽고 자동으로 설치한다.

kickstart — Red Hat 계열(RHEL·CentOS·Rocky·Fedora)의 자동 설치 형식. .ks 파일에 설치 절차를 정의. Anaconda 설치 프로그램이 읽는다. 예:

# 예시 kickstart (요약)
lang en_US.UTF-8
keyboard us
timezone Asia/Seoul
rootpw --plaintext mypassword
clearpart --all --initlabel
part / --fstype=xfs --size=20000 --grow
%packages
@core
nginx
postgresql
%end
%post
systemctl enable nginx
%end

preseed — Debian·Ubuntu 계열의 자동 설치 형식. .preseed 파일에 d-i (debian-installer) 질문-답 형식으로 정의. kickstart와 목적은 같고 문법이 다르다.

두 형식 모두 — 파일 하나로 OS 설치 전체가 결정된다. 파일을 Git에 두면(foudations 06의 IaC 원칙), OS 이미지의 재현 가능성이 보장된다. 수천 대의 서버를 같은 kickstart 파일로 설치하면, 전부 같은 설정이다.

근래는 kickstart/preseed보다 이미지 기반 설치(image-based provisioning) 이 더 흔하다. 설치 프로그램을 돌리는 대신, 미리 만들어진 디스크 이미지(황금 이미지, golden image)를 복사하는 것. Packer(foundations 06에서 맛보기로 본 도구)로 이미지를 만들고, dd·qemu-img로 디스크에 복사. 설치 시간이 수 분에서 수십 초로 줄어든다. 클라우드 AMI도 같은 원리 — 이미 만들어진 이미지를 볼륨에 복사하는 것.

cloud-init — 첫 부팅 시 설정

OS 설치(또는 이미지 복사)가 끝나고 처음 부팅할 때, 추가 설정을 적용하는 표준 도구가 cloud-init다. 2010년 Canonical(Ubuntu)이 발표한 이후 AWS·GCP·Azure 모두 기본으로 채택했고, 2020년대 들어 CNCF 샌드박스 프로젝트가 됐다.

cloud-init이 하는 일은 — 첫 부팅 시 user-data라는 스크립트나 설정 파일을 읽고 적용하는 것. user-data는 보통 클라우드 API로 전달되거나, HTTP 서버(메타데이터 서비스)에서 받는다. 내용은 다양하다.

SSH 공개 키 추가 (사용자 접근 권한)
사용자 계정 생성
패키지 설치 (apt install, yum install)
파일 작성 (write_files 모듈)
임의 명령 실행 (runcmd 모듈)
호스트 이름 설정
네트워크 설정

예시 user-data (YAML 형식):

#cloud-config
hostname: web-server-01
users:
  - name: deploy
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3Nza...
packages:
  - nginx
  - postgresql-client
write_files:
  - path: /etc/nginx/conf.d/app.conf
    content: |
      server { listen 80; ... }
runcmd:
  - systemctl enable nginx
  - systemctl start nginx

cloud-init는 베어메탈·VM·클라우드 인스턴스 모두에서 동일하게 동작한다. 베어메탈 프로비저닝에서도 NoCloud 데이터 소스(로컬 파일·디스크)로 user-data를 전달하면, 클라우드와 동일한 흐름으로 설정을 적용할 수 있다. "한 번 짜면 어디서든"이 IaC 시대의 약속인데, cloud-init가 그 약속의 인프라 버전이다.

cloud-init는 로그를 /var/log/cloud-init.log와 /var/log/cloud-init-output.log에 남긴다. 실패 시 이 로그를 보면 어느 단계에서 막혔는지 알 수 있다.

IPMI와 BMC — 서버를 원격으로 제어

지금까지 PXE 부팅·OS 설치·cloud-init를 봤다. 전제는 "서버의 전원이 켜져 있고 PXE 부팅을 한다"는 것이었다. 그런데 — 전원을 누가 켜나? 1000대의 서버 랙을 일일이 걸어 다니며 전원 버튼을 누를 수는 없다. 이걸 원격으로 하는 장치가 BMC(Baseboard Management Controller) 다.

BMC는 메인보드에 별도로 장착된 작은 컴퓨터다. 메인 CPU와 독립적으로 동작하고, 서버가 꺼져 있어도 켜져 있다. 자체 네트워크 포트(또는 메인 NIC 공유)를 갖고, 자체 IP를 갖는다. BMC가 제공하는 핵심 기능은 세 가지다.

전원 제어 — 켜기, 끄기, 강제 재부팅. 운영체제가 멈췄을 때도 동작한다.
원격 콘솔 — 직렬 콘솔·KVM over IP. 서버가 부팅 중일 때 화면을 원격으로 본다.
가상 미디어 — 원격 ISO·USB 이미지를 마운트. 원격에서 OS 재설치 가능.

BMC를 제어하는 인터페이스가 IPMI(Intelligent Platform Management Interface) 다. Intel이 1998년 발표, v2.0(2004)이 현재 표준. IPMI는 직렬 프로토콜(Modbus over LAN 같은 형식)을 쓰고, ipmitool이라는 명령으로 제어한다.

# BMC 전원 켜기
ipmitool -I lanplus -H 192.0.2.100 -U admin -P password chassis power on
# 전원 상태 확인
ipmitool -I lanplus -H 192.0.2.100 -U admin -P password chassis power status
# 원격 콘솔 (직렬)
ipmitool -I lanplus -H 192.0.2.100 -U admin -P password sol activate

IPMI의 치명적 단점은 보안이다. 암호화가 약하고(기본 MD5), 기본 자격증명(admin/admin)이 흔하고, 취약점이 자주 발견된다. 2022년 BMC를 노린 랜섬웨어 공격 사례가 여럿 보고됐다. 그래서 IPMI 네트워크는 절대 인터넷에 노출하면 안 되고, 관리망(management network)으로 분리해야 한다. infra security 영역에서 다시 다룬다.

Redfish — IPMI의 현대적 후계

IPMI의 한계를 넘어 2014년 DMTF가 발표한 차세대 표준이 Redfish다. IPMI의 직렬 프로토콜 대신 RESTful API(JSON over HTTPS) 를 쓴다. 현대 웹 개발자에게 익숙한 형태여서 자동화 스크립트 작성이 훨씬 쉽다.

# Redfish로 서버 정보 조회 (curl 예시)
curl -k -u admin:password https://192.0.2.100/redfish/v1/Systems/1

# 응답 예시 (JSON)
{
  "@odata.id": "/redfish/v1/Systems/1",
  "Name": "PowerEdge R760",
  "PowerState": "On",
  "ProcessorSummary": { "Count": 32, "Model": "Intel Xeon Gold" },
  "MemorySummary": { "TotalSystemMemoryGiB": 256 },
  "Boot": {
    "BootSourceOverrideTarget": "Pxe",
    "BootSourceOverrideEnabled": "Once"
  }
}

Redfish는 단순 조회를 넘어 — 부팅 순서 변경, 전원 제어, 펌웨어 업데이트, 이벤트 구독(webhook)까지 API로 처리한다. 주요 서버 벤더가 모두 지원한다 — Dell iDRAC9+·HP iLO5+·Lenovo XClarity·Supercloud BMC·AMI MegaRAC. 2026년 현재 새 서버는 Redfish를 기본 제공하고, IPMI는 호환성 유지용으로 남는 추세다.

OpenBMC(LinkedIn·Google·Facebook이 주도한 오픈소스 BMC 펌웨어)도 Redfish API를 지원한다. OCP(Open Compute Project) 하드웨어와 짝을 이뤄 — 벤더 종속 없이 표준화된 베어메탈 관리를 가능케 하는 생태계가 만들어지고 있다.

대규모 프로비저닝 — Ironic과 클라우드 베어메탈

PXE·IPMI·kickstart·cloud-init는 단일 서버를 프로비저닝하는 도구들이다. 이걸 수천 ~ 수만 대 규모로 orchestration하는 플랫폼이 필요하다.

OpenStack Ironic — OpenStack의 베어메탈 프로비저닝 서비스. 2013년 발표. 가상 머신을 프로비저닝하듯 API로 베어메탈 서버를 프로비저닝한다 — "이 노드에 이 이미지를 배포해라"고 API를 부르면, Ironic이 PXE 부팅을 설정하고 이미지를 설치하고 상태를 추적한다. CERN·Verizon·Godaddy 같은 대규모 자체 데이터센터에서 쓴다.

Equinix Metal(구 Packet) — 베어메탈을 API로 제공하는 클라우드 서비스. 2014년 Packet 창업, 2020년 Equinix 인수. 사용자가 베어메탈 서버를 시간당·월별로 빌릴 수 있고, 프로비저닝부터 네트워크·운영까지 Equinix가 관리. 클라우드의 편리함 + 베어메탈의 성능.

AWS EC2 Bare Metal (2017년 발표) — AWS의 베어메탈 인스턴스(.metal 접미사). 하이퍼바이저 없이 물리 서버를 그대로 빌려준다. 하이퍼바이저를 직접 설치하거나(자체 클라우드 구축), 라이선스 문제로 베어메탈이 필요한 워크로드에 쓴다. EC2의 다른 인스턴스와 같은 API로 제어된다.

이런 서비스들은 — 베어메탈 프로비저닝의 복잡함을 클라우드 API 뒤로 숨긴다. 사용자는 "베어메탈 인스턴스 100개 만들어라"고 API를 부를 뿐이고, 뒤에서는 PXE·IPMI·Redfish·이미지 배포가 자동으로 돈다. foundations 05의 "build vs buy" 관점에서 — 베어메탈 프로비저닝 자동화는 "buy"의 영역으로 넘어가고 있다.

프로비저닝 전체 흐름 — 종합

지금까지 본 요소들을 실제 시퀀스로 엮어본다.

sequenceDiagram
    participant OP as 운영자/IaC
    participant IR as Ironic/프로비저닝 시스템
    participant BMC as 서버 BMC
    participant SRV as 서버 (CPU/OS)
    participant DHCP as DHCP/TFTP 서버

    OP->>IR: API: 노드 N에 이미지 X 배포
    IR->>BMC: Redfish: BootSource=Pxe, Power=On
    BMC->>SRV: 전원 인가, PXE 부팅
    SRV->>DHCP: DHCP Discover (PXE 옵션)
    DHCP->>SRV: IP + iPXE 부트로더 위치
    SRV->>DHCP: TFTP/HTTP GET iPXE + 커널 + initramfs
    DHCP-->>SRV: 바이너리 전송
    SRV->>SRV: 커널 부팅, OS 설치 (kickstart)
    Note over SRV: 재부팅 후 첫 부팅
    SRV->>SRV: cloud-init 실행 (user-data 적용)
    SRV->>IR: 상태 보고 (provisioned)
    IR->>OP: 완료 알림

이 흐름이 자동화돼 있으면 — 운영자는 API 한 번 부르고, 수십 초 ~ 수 분 뒤에 사용 가능한 서버가 생긴다. 클라우드 EC2·GCE가 내부적으로 하는 일이 바로 이것 (가상 머신이냐 베어메탈이냐의 차이만 있을 뿐). 사용자가 보는 "Launch Instance" 버튼 뒤의 복잡함이 드러난다.

실습 — 베어메탈 관련 상태 직접 확인

단일 서버에서 실행 가능한 기본 명령들. 실제 베어메탈 환경(BMC·DHCP 서버)이 있어야 하는 것은 클라우드/실습 한계상 생략한다.

1. cloud-init 상태와 로그

# cloud-init 상태 (성공/실패)
cloud-init status
# 상세 로그
tail -50 /var/log/cloud-init.log
# 실행 결과 (runcmd 출력 등)
tail -30 /var/log/cloud-init-output.log

확인할 것: status: done이면 정상. status: error면 로그를 봐서 어느 모듈에서 실패했는지. user-data 스크립트 문법 오류가 흔한 원인.

# 예상 출력 (status)
status: done

2. user-data가 어디서 왔는지 확인

# 메타데이터 소스 (클라우드라면 metadata service, 베어메탈이라면 NoCloud)
cloud-init query --all 2>/dev/null | head -20
# 인스턴스 ID
cat /var/lib/cloud/data/instance-id 2>/dev/null

확인할 것: AWS면 instance-id가 i-xxx, GCP면 숫자 ID. 베어메탈(NoCloud)이면 iid-localdata 같은 형태.

3. ipmitool로 BMC 정보 조회 (BMC가 있는 베어메탈만)

# BMC 설정 조회 (로컬, root)
sudo ipmitool lan print 1 2>/dev/null | head -10
# 센서 (온도·팬·전압)
sudo ipmitool sensor list 2>/dev/null | grep -E 'Temp|Fan' | head -5
# 시스템 이벤트 로그 (SEL)
sudo ipmitool sel list 2>/dev/null | tail -10

확인할 것: BMC IP 주소, MAC. 센서에서 온도·팬 RPM. SEL(System Event Log)에 하드웨어 장애 기록. 클라우드 VM은 BMC가 없어서 동작 안 함 — 이 명령은 베어메탈 전용.

4. PXE 부팅 설정 흔적

# UEFI 부팅 순서에 PXE가 있는지
efibootmgr 2>/dev/null | grep -iE 'boot|pxe|ipv4'
# 부팅 시 전달된 파라미터 (02 글 참조)
cat /proc/cmdline

확인할 것: BootOrder에 PXE 또는 IPv4/IPv6 항목이 있으면 PXE 부팅 가능 상태. 실제 PXE 부팅 흔적은 /proc/cmdline이나 journalctl -b | grep -i pxe로 확인.

5. DHCP 서버 설정 (DHCP 서버가 있는 경우)

# dnsmasq의 PXE 설정 예시 (DHCP 서버에서)
grep -A 3 -E 'dhcp-boot|pxe-service|dhcp-option=option:next-server' /etc/dnsmasq.conf 2>/dev/null
# ISC DHCP 서버의 PXE 설정
grep -A 2 -E 'next-server|filename' /etc/dhcp/dhcpd.conf 2>/dev/null

확인할 것: next-server가 TFTP 서버 IP, filename이 부트로더 경로(pxelinux.0, ipxe.efi).

미검증: 위 명령의 정확한 출력은 환경에 따라 다르다. 클라우드 VM은 BMC가 없어 ipmitool이 안 됨. DHCP 서버 설정은 해당 서버가 있어야 확인 가능. cloud-init는 거의 모든 클라우드 인스턴스와 베어메탈 Ubuntu·RHEL에서 동작.

판단 표 — 베어메탈 vs VM 프로비저닝

베어메탈 프로비저닝과 VM 프로비저닝의 차이를 표로 정리한다. 04 글부터 다룰 가상화의 맥락을 미리 본다.

특성	베어메탈 프로비저닝	VM 프로비저닝
부팅 방식	PXE 또는 이미지 복사	하이퍼바이저가 VM 이미지 로드
전원 제어	BMC (IPMI/Redfish)	하이퍼바이저 API (vSphere, libvirt)
프로비저닝 시간	수 분 ~ 수십 분	수 초 ~ 수 분
하드웨어 의존	드라이버·NUMA 등 물리 의존	가상 하드웨어로 추상화
멀티테넌시	한 서버 한 워크로드	한 서버에 여러 VM
성능 오버헤드	없음 (직접 하드웨어)	하이퍼바이저 오버헤드 (작지만 있음)
실패 복구	물리적 교체 필요	새 VM으로 교체
비용 구조	자본 지출(capex) 중심	운영 지출(opex) 중심

이 표는 foundations 05의 build vs buy와 연결된다. "베어메탈을 직접 프로비저닝한다"는 건 — 자본을 들여 하드웨어를 사고, 그 위에 자체 자동화를 구축하는 길이다. 비용이 크지만 단위당 성능은 가장 좋고 통제력도 가장 강하다. 클라우드 VM은 그 반대 — 자본은 적지만 단위당 비용은 비싸고, 벤더 인프라에 의존한다. 둘 중 어느 쪽이 이기는가는 — 서비스 규모·트래픽 패턴·규제·핵심 역량에 달렸다. foundations 05에서 본 다섯 질문이 이 표에서 다시 살아난다.

베어메탈은 사라지지 않았다, 다만 변했다

도입의 "USB로 1000대 설치" 질문으로 돌아가자. 2026년에도 베어메탈은 사라지지 않았다. 변했다. USB 대신 PXE가, 손으로 누르는 전원 대신 BMC·Redfish가, 설치 CD 대신 이미지·cloud-init가, 담당자의 머릿속 대신 Ironic·IaC가 자리 잡았다. 클라우드의 화려한 "Launch Instance" 버튼 뒤에는 — 이 베어메탈 자동화의 묵묵한 층이 있다. AWS·GCP·Azure가 자체 데이터센터에서 매일 수만 대의 베어메탈을 프로비저닝하고, 그 위에 우리가 쓰는 가상 머신을 띄운다.

이해하면 다른 질문에도 답이 보인다. "왜 EC2 베어메탈 인스턴스(.metal)가 비싸나" → 물리 서버 한 대를 통째로 점유하니까. "왜 오토스케일링이 느린가" → 가상 머신이지만 결국 어딘가의 베어메탈을 프로비저닝해야 하니까. "왜 클라우드 벤더가 ARM 자체 칩(Graviton·Axion)을 만드나" → 베어메탈 단가를 낮추는 게 곧 클라우드 마진이니까. 베어메탈은 인프라의 밑바닥이고, 밑바닥을 이해하면 위층이 다르게 보인다.

다음 글에서는 이 베어메탈을 여러 워크로드로 나눠 쓰는 추상화 계층을 다룬다 — 가상화. 하이퍼바이저가 한 물리 서버를 여러 가상 머신으로 쪼개는 원리, KVM·ESXi·Hyper-V가 어떻게 동작하는지. 베어메탈이 "한 대 한 용도"라면, 가상화는 "한 대 여러 용도"의 시대를 연 기술이다.

참고

Intel Corporation, "Preboot Execution Environment (PXE) Specification 2.1", 1999 — PXE 표준. 접근 2026-07-21
iPXE Project, "iPXE Open Source Bootloader" — PXE 확장, HTTP/iSCSI 지원. 접근 2026-07-21. URL: https://ipxe.org/
Intel Corporation, "IPMI v2.0 Specification 1.1", 2015 — IPMI 최종 표준. 접근 2026-07-21
DMTF, "Redfish Specification 2024.1" — Redfish RESTful API 표준. 접근 2026-07-21. URL: https://www.dmtf.org/standards/redfish
Canonical, "cloud-init Documentation" — 클라우드 인스턴스 초기화 표준. 접근 2026-07-21. URL: https://cloudinit.readthedocs.io/
Red Hat, "Anaconda and Kickstart Documentation" — RHEL 자동 설치. 접근 2026-07-21
OpenStack Ironic Project, "Bare Metal Provisioning" — 대규모 베어메탈 프로비저닝. 접근 2026-07-21. URL: https://docs.openstack.org/ironic/
OpenBMC Project, Linux Foundation — 오픈소스 BMC 펌웨어. 접근 2026-07-21. URL: https://www.openbmc.org/
Open Compute Project, "Hardware Design Specifications" — OCP 표준 하드웨어. 접근 2026-07-21. URL: https://www.opencompute.org/
AWS, "Amazon EC2 Bare Metal Instances" — .metal 인스턴스 문서. 접근 2026-07-21
Equinix Metal, "Bare Metal as a Service" — API 기반 베어메탈 서비스. 접근 2026-07-21
Hansson, D. H. "Why we're leaving the cloud", 37signals, 2022-10 — 베어메탈 회귀 사례. 접근 2026-07-21

'Infra Architecture > Compute Platforms' 카테고리의 다른 글

Compute Platforms - 04. 가상화 기초와 하이퍼바이저 (1)	2026.07.22
Compute Platforms - 02. 서버 부팅 과정 (0)	2026.07.22
Compute Platforms - 01. 서버 하드웨어 기초 (0)	2026.07.22