IPMI(Intelligent Platform Management Interface)의 역사와 현재

 (computer.rip)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 서버가 PC와 비슷한 범용 하드웨어로 수렴한 뒤에도, 장애·부팅·원격 설치를 다루는 대역 외 관리는 클라이언트와 서버를 가르는 핵심 기능으로 남아 있음
  • IPMI는 제품명이 아니라 명세이며, HP iLO와 Dell DRAC 같은 벤더별 관리 시스템은 IPMI와 겹치지만 각자 다른 역사와 확장 기능을 가짐
  • IPMI는 BMC에서 동작하며 네트워크·직렬 기반 대역 외 인터페이스와 운영체제 드라이버를 통한 인밴드 인터페이스를 함께 제공함
  • 실제 구현은 웹 UI, SSH, VNC, UDP 623 기반 명령, 원격 콘솔, 가상 미디어, 센서·전원·팬·워치독 제어를 제공하지만 보안 노출에 특히 취약함
  • Intel ME와 Intel AMT는 클라이언트 PC 쪽 유사 기술이지만, AMT와 vPro 조건 때문에 일반 소비자 장치에서 사이드밴드 네트워크 접근이 가능하다는 통념은 대체로 맞지 않음

서버가 “큰 컴퓨터”가 되기까지

  • 클라이언트-서버 컴퓨팅은 여러 터미널이 하나의 컴퓨터에 연결되던 시분할 컴퓨팅의 진화에서 출발함
  • 터미널은 컴퓨터와 같은 아키텍처를 가질 필요가 없었고, 이런 인식은 초기 클라이언트-서버 시스템에도 이어짐
  • 1990년대 중반 PC 혁명은 클라이언트 쪽에 WinTel 단일 문화를 만들었지만, 2000년대까지 서버는 별도 운영체제와 아키텍처를 쓰는 일이 흔했음
    • SPARC와 Solaris 조합이 서버에서 널리 쓰였음
    • IBM의 미니컴퓨터 아키텍처와 여러 운영체제도 중요한 서버 플랫폼이었음
    • Java는 Solaris/SPARC 백엔드와 Windows/x86 클라이언트 간 코드 재사용을 가능하게 해 엔터프라이즈 애플리케이션에 기여함
  • 시간이 지나며 서버 전용 아키텍처는 PC 아키텍처의 비용·성능 경쟁에서 점점 불리해짐
  • 서버 소프트웨어도 수직 확장과 높은 가동시간 중심에서 수평 확장과 완화된 신뢰성 요구로 이동하면서 엔터프라이즈급 컴퓨터의 이점이 줄어듦
  • 현재 서버의 차별점은 주로 다중 소켓 SMP·NUMA, 복잡한 스토리지 컨트롤러와 토폴로지, 그리고 대역 외 관리 기능에 있음

대역 외 관리는 무엇을 해결하나

  • 대역 외 관리는 운영체제나 범용 컴포넌트가 정상 동작하지 않아도 별도 관리 컴퓨터를 통해 서버에 접근하는 기능임
  • SSH는 운영체제 위 소프트웨어가 제공하는 인밴드 관리의 전형적인 예임
  • 대역 외 관리는 별도 하드웨어·소프트웨어 스택이 담당하며, 전통적으로 운영체제나 CPU의 협조가 필요하지 않았음
  • 오늘날 이 기능은 서버의 원격 콘솔에서 가장 잘 드러남
    • 내장 IP KVM처럼 동작해 로컬 모니터와 키보드가 연결된 것처럼 서버를 조작할 수 있음
    • “가상 미디어” 기능은 ISO 파일을 업로드해 물리 장치처럼 보이게 만들 수 있어 운영체제 설치에 유용함
  • 이런 기능은 새로운 개념이 아니며, 비즈니스 컴퓨팅 역사 전반에서 유사한 기능을 찾을 수 있음
  • 비교적 현대적인 서버에는 보통 여러 단계의 관리 기능이 함께 들어 있었음
    • 하드웨어 상태를 보여주는 LCD나 LED 같은 로컬 운영자 인터페이스
    • 초기 부트로더와 지속적인 저수준 관리 시스템에 접근하는 직렬 콘솔
    • 머신 워크로드를 원격 관리하는 더 높은 수준의 관리 시스템
  • 오늘날에도 전면 패널의 장애 표시와 직렬 관리 기능은 남아 있지만, 온라인 교체 가능한 중복 부품의 범위는 과거보다 줄어듦

IPMI와 BMC의 관계

  • IPMI는 특정 제품이 아니라 Intel IPMI 명세임
  • 주요 서버 벤더는 대개 자체 IPMI 구현을 갖고 있으며, HP iLO와 Dell DRAC 같은 이름을 사용함
    • 이런 시스템은 IPMI보다 먼저 존재한 경우도 있어 “그냥 IPMI”라고 부르기에는 정확하지 않음
    • 신생 제조사는 펌웨어 벤더의 표준 제공물을 그대로 쓰며 IPMI라고 부르는 경우가 많음
  • IPMI 소프트웨어는 보통 BMC(Baseboard Management Controller) 라고 부르는 프로세서에서 실행됨
  • IPMI와 BMC라는 용어는 때때로 서로 바꿔 쓰임
  • LOM(Lights-Out Management)은 대체로 오래된 용어지만, HP(E)가 Integrated Lights-Out이라는 이름을 계속 쓰면서 남아 있음
  • BMC는 클라이언트 컴퓨터에서 팬 속도 제어 같은 작업을 맡는 SMC(System Management Controller)와 구분해야 함
    • 두 컴포넌트는 역사적으로 관련이 있음
    • 서버에서는 BMC가 이런 기능을 대부분 처리함
  • IPMI는 두 가지 접근 방식을 명세함
    • 네트워크나 직렬 연결을 통한 대역 외 인터페이스
    • 운영체제가 드라이버로 접근하는 인밴드 인터페이스
  • 인밴드 접근 덕분에 Linux의 ipmitool 같은 도구가 실행 중인 운영체제에서 IPMI와 상호작용할 수 있음
  • IPMI는 독립 관리 시스템이면서도 편의를 위해 운영체제에 로컬 인터페이스를 제공하므로, 이 구조를 알아야 용어 혼동이 줄어듦

실제 IPMI 사용 방식과 보안 제약

  • IPMI 제품은 점점 웹 애플리케이션 중심으로 기능을 제공함
  • 전용 클라이언트 소프트웨어가 있는 제품도 많지만, 기능이 내장 웹 앱으로 옮겨가는 흐름이 있음
  • 웹 인터페이스 품질은 구현마다 크게 다르며 대체로 좋지 않음
  • 대부분의 서버에는 IPMI 또는 management로 표시된 전용 이더넷 인터페이스가 있음
  • IPMI 관리 인터페이스는 보안과 신뢰성 때문에 전용 물리 네트워크에 두는 방식이 가장 바람직함
    • 주 네트워크에 성능이나 안정성 문제가 생겨도 IPMI에는 접근 가능해야 함
    • 전용 물리 네트워크는 시간, 공간, 비용이 듦
  • 관리 네트워크를 일반 네트워크 장비 위의 VLAN으로 구성하는 타협도 흔함
    • 독립 사설망처럼 동작하지만 실제 장비는 공유됨
    • 격리는 소프트웨어로 구현됨
  • 추가 케이블을 피하려고 IPMI는 사이드밴드 네트워킹도 제공함
    • BMC가 운영체제가 쓰는 같은 NIC와 직접 통신함
    • NIC는 서로 다른 두 인터페이스처럼 보이게 하며, IPMI 트래픽은 호스트 트래픽과 같은 패킷 스트림에 섞이지만 다른 MAC 주소를 사용함
    • IPMI와 애플리케이션 트래픽의 분리가 약해져 보안 고려가 필요함
  • 많은 IPMI 구현은 심각한 보안 문제를 보여왔으며, 신뢰할 수 없는 사용자에게 접근 가능하게 두면 안 됨
  • 네트워크 기능은 구현마다 다르지만, 공통적으로 UDP 623 기반 표준 인터페이스가 검색과 기본 명령에 쓰임
  • SSH와 웹 인터페이스가 흔하며, 원격 콘솔에는 VNC도 자주 쓰임
  • IPMI로 수행할 수 있는 기본 기능은 다음과 같음
    • FRU 또는 벤더 부품 번호 수준에서 하드웨어 모듈 목록 확인
    • 센서, 전원 상태, 팬 같은 기본 하드웨어 기능 제어
    • 표준 워치독 타이머 사용
  • 워치독 타이머는 운영체제 위 소프트웨어와 결합해 애플리케이션이 비정상 상태에 빠지면 서버를 재설정하게 만들 수 있음
  • 워치독 제한시간은 시스템 부팅과 접속 후 비활성화할 시간을 허용할 만큼 길게 잡아야 함

Intel ME, AMD ST, AMT와 클라이언트 PC의 예외

  • IPMI는 엔터프라이즈 서버에서는 흔하지만, 일반 클라이언트 컴퓨터나 소형·저전력 컴퓨터에서는 드묾
  • Intel ME와 AMD ST는 거의 모든 Intel·AMD 프로세서에 있는 OOB 관리 컨트롤러에 가까운 예외적 존재임
  • Intel ME는 Intel AMT(Active Management Technology)를 가능하게 하는 구성요소임
  • AMT는 클라이언트 머신에 대역 외 관리를 보급하려는 시도였고, IPMI와 유사한 기능을 대부분 제공함
  • AMT는 크게 성공하지 못했으며, 주된 이유는 Intel이 대부분의 AMT 기능을 비싼 엔터프라이즈 관리 플랫폼과 함께 쓰도록 제한한 데 있음
  • 오픈소스 AMT 클라이언트는 있지만, 실제로 AMT를 사용할 수 있는 머신을 찾는 문제가 남아 있음
  • AMT의 사이드밴드 관리는 보안 커뮤니티의 우려를 낳았지만, 실제로는 다음 조건이 모두 맞아야 가능함
    • 프로세서가 AMT 가능해야 함
    • 메인보드 칩셋이 AMT 가능해야 함
    • NIC가 AMT 가능해야 함
    • 세 장치는 모두 vPro 배지가 붙은 Intel 제품으로 제한됨
  • 소비자 장치에서 Intel NIC가 인기가 없다는 점만으로도 사이드밴드 접근은 드문 편임
  • vPro는 비교적 고급 프로세서와 칩셋으로 제한됨
  • Intel ME가 소비자 장치에서 사이드밴드 네트워킹으로 접근 가능하다는 널리 퍼진 “사실”은 보통 맞지 않으며, 이유는 Intel 소프트웨어 라이선스만이 아님
  • Intel ME 자체는 AMT 없이는 대역 외 관리 기능을 거의 갖지 않지만, Secure Boot와 DRM 같은 신뢰 실행 컴포넌트를 호스팅하고 관리하는 편리한 기반으로 쓰이는 것으로 보임
  • Intel ME는 제3자가 감사할 수 없고 과거에 중요한 보안 취약점을 품은 적이 있음
  • 현대 소비자용 ARM SoC도 유사한 능력을 갖고 있어, 특정 x86 벤더만의 문제로 끝나지 않음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 최신 정보와 조금 다른 부분이 있음. Intel은 CPU/GPU 전반에서 AMD에 뒤처졌고, N100 계열처럼 저전력·팬리스 용도에 잘 맞는 예외만 돋보임
    그래서 Intel CPU는 기존 환경을 같은 제조사 CPU로 갱신해야 하는 조직에서 주로 사는 편이고, 예컨대 vSphere의 EVC처럼 새 프로세서를 같은 제조사의 구형 모델처럼 동작시켜 CPU 아키텍처 간 핫 마이그레이션과 하드웨어 교체 시 중단 최소화를 노릴 때 쓰임
    그 외에는 거의 모두 처리 성능 대비 더 좋고 싼 AMD CPU로 가는 분위기임. Intel NIC는 전반적으로 괜찮고, 소비자 기기에서도 점점 늘고 있음. 단 X710은 VMware 등 “엔터프라이즈” 호환 목록에 있으면서도 1년 넘게 드라이버 문제로 조용한 네트워크 장애나 크래시를 일으켰던 예외가 있음
    서버 구매 조직에는 Supermicro가 대체로 좋은 선택지일 수 있음. 더 싸고 폼팩터, 섀시, 부품, 슬롯 수 등 유연성이 높으며 대체로 신뢰할 만하지만, 지원은 Dell/HPE의 이론상 지원보다 덜 안정적이라 이중화 구성에서 가장 잘 맞음
    또한 IPMI 사양은 더 완전하고 안전하며 표준화되고 정상적인 API를 제공하는 Redfish로 대체되는 중임. 몇 년 전 이후의 주류 서버라면 IPMI와 함께 Redfish도 갖고 있을 가능성이 큼
    최근 공매도 리서치 회사 Hindenburg가 Supermicro의 수상한 부분을 폭로한 리포트를 냈지만, 하드웨어 자체는 여전히 최상급이고 대형 클라우드 사업자들도 사용함: https://hindenburgresearch.com/smci/

    • 워크스테이션용으로 Supermicro와 ASRock Rack 보드를 둘 다 만져봤는데, Supermicro 보드는 2024년 제품이 아니라 2005년에 만든 보드처럼 느껴짐
      ACPI 절전 미지원, 4핀/3핀 팬 지원 부족으로 3핀 팬은 항상 100% 속도, 2010년대 그대로인 IPMI 웹 인터페이스, 방열판을 못 쓰게 만드는 NVMe 배치, 보드 라벨도 없는 불투명한 점퍼가 잔뜩 있음
      반면 동급 ASRock Rack 보드는 비교가 안 될 정도로 좋았음
    • Supermicro의 문제는 공매도 리포트가 아니라 Secure Boot 키 유출임. 신뢰 루트가 깨져서 상당수 하드웨어를 안전하게 만들 수 없게 됨
      https://arstechnica.com/security/2024/07/secure-boot-is-comp...
    • 최근 Intel CPU는 스펙상으로는 나쁘지 않아 보이지만 실제로는 타버리는 문제가 있음
      공정이 미세화될수록 수명 문제가 커질 수밖에 없어서 크게 놀랍지는 않음. 이동성 결함 같은 문제가 더 쉽게 큰 trouble을 만들 수 있음. 마이크로코드가 메인보드에 과도한 전압을 요구한 문제라고들 하고 그 말도 맞지만, 칩이 환경 변화에 더 민감해지는 것도 사실임
      예전에는 Intel NIC의 성능과 Linux 호환성을 좋아했고, Intel SSD도 좋아했음. 다만 싼 경쟁 제품보다 P95~P99 구간 성능이 조금 더 좋다는 점을 읽어내야 했고, 컴퓨터가 느리다고 답답해지는 순간이 바로 그 P95~P99였음. Anandtech를 좋아하면서도 싫어했던 이유 중 하나가 이런 핵심을 자주 놓쳤기 때문임
    • Supermicro PSU가 독점 IPMI 유틸리티 없이 PMBus로 접근 가능했으면 좋겠지만 그렇지 않음. 게다가 x86 전용이라 ppc64el에서는 인터페이스할 방법이 없음
      오픈소스였다면 간단히 빌드할 수 있었을 것임
      https://www.supermicro.com/en/solutions/management-software/...
    • Redfish로 IPMI SSL 인증서를 최신 상태로 유지하도록 자동화하고 있는데, 새 인증서를 가져오는 과정이 벤더별 Redfish 구현마다 조금씩 다른 마법을 요구함
      인증서 이름, 인코딩 등 인증서 업로드와 교체만 해도 각 벤더의 괴상한 차이를 처리하는 Python 모듈 묶음을 갖고 있음. 원래는 어디서나 동작하는 표준 PUT 요청 몇 개면 끝나야 하고, Redfish API 문서도 그렇게 믿게 만들지만 현실은 아님
      그래서 표준화됐거나 사용 가능하다는 데에는 동의하기 어렵고, 웹 인터페이스를 직접 조작하던 시절만큼이나 짜증남

  • 컴팩트하거나 저전력 컴퓨터를 고집하면 IPMI 없이 살아야 한다는 말에 대한 한 가지 선택지는, Atom 기반 Supermicro MicroATX 보드에 IPMI를 얹고 짧은 깊이의 1U 섀시에서 작은 Noctua 팬으로 조용히 식히는 것임
    집에서 오래된 모델을 쓰고 있는데, 조용하고 작아서 봤던 Dell R2x0 모델보다 훨씬 매력적이었음. IPMI와 ECC RAM 같은 서버 기능이 있어 미니 PC보다 낫고, 허술한 RasPi보다 안정적이었음
    개인적으로 IPMI 포트를 메인 LAN에 꽂지는 않겠지만, 분리된 상태에서는 꽤 유용했고 가지고 놀기도 재미있었음

    • ASRock Rack에는 X470, X570, X670 같은 칩셋에 표준 AM4/AM5 칩을 쓰면서 IPMI와 ECC 같은 서버 기능을 많이 제공하는 보드가 있음. AMD 쪽에서는 ECC가 이미 흔한 편으로 보임
      내 보드에는 5950X를 넣었지만 한동안 5600G로도 잘 썼음. mATX/ATX라 일반 케이스와 일반 전원공급장치에 들어가고, 랙이 필요 없음
    • IPMI와 다른 관리 인터페이스는 별도 관리 VLAN으로 분리하고, 전용 VPN을 통해서만 접근하게 해둠
    • 그런 Atom 보드를 여러 대 갖고 있음. 글을 읽자마자 떠오른 첫 생각이었고, 글은 IPMI가 큰 장비를 뜻한다고 말하기까지 꽤 오래 걸림

  • IPMI 없는 장비에 원격 접근 기능을 추가하고 싶다면 30달러짜리 RISC-V NanoKVM 같은 것을 써볼 수 있음
    HDMI 캡처와 인코딩, Ethernet/Wi-Fi, ATX 전원 제어를 제공하고 일반 Linux 배포판을 실행함
    https://www.aliexpress.com/item/1005007369816019.html
    https://github.com/sipeed/NanoKVM

    • 지금 장난감 미니 PC에 풀 키트를 붙여서 써보는 중임. 몇 와트만 먹는 작은 RISC-V 장치이고, 아직 Wi-Fi는 없지만 HDMI 출력을 웹 UI로 캡처하면서 PC에 네 가지 장치로 에뮬레이션됨
      USB 키보드, USB 마우스, 부팅 ISO를 저장해 설치·복구에 쓰는 USB 플래시 드라이브, 그리고 꽤 훌륭한 USB NIC로 동작함
      이 USB NIC를 PC에서 관리용 SSH 포트만 노출하는 데 쓸 수 있어서, PC에 일종의 전용 IPMI 인터페이스가 생긴 느낌임. 최신 소프트웨어에는 WireGuard와 Tailscale 지원도 들어가 VPN으로 바로 붙을 수 있음
      아직 사소한 문제는 있지만 개발자들이 빠르게 고치는 중임
    • ATX 전원 제어 브레이크아웃을 쓰려면 60달러짜리 풀 버전이 필요함. 이 브레이크아웃은 ATX 신호를 담은 기묘한 물리 USB-C 커넥터에 붙음
      직접 만들 수도 있겠지만 USB-C 커넥터는 납땜하기 정말 별로임
    • AliExpress가 왜 이 장치를 미국 고객에게 판매하지 않는지 궁금함
    • 소프트웨어 쪽은 오픈소스가 아니라서 대안보다 나을 게 없음
      또 하나의 신뢰할 수 없는 KVM임

  • 1990년대 후반에 Intel이 만든 서버 여러 대를 설치한 적이 있음. Intel 레퍼런스 플랫폼을 “베어본” 컴퓨터로 출하하고 RAM과 스토리지는 통합업체가 넣는 방식이었고, LANDesk Server Manager Pro와 “Emergency Management Card”(EMC)로 lights-out 관리를 했음
    AP450GX, BB440FX, RC440FX 같은 Pentium Pro~초기 Pentium II 시기의 장비였음
    x86 플랫폼의 레퍼런스 코드는 죽지 않는다는 점을 생각하면, 지금 IPMI 구조물 중 얼마나 많은 부분이 이 하드웨어와 소프트웨어에서 이어졌는지 자주 궁금했음. Intel LANDesk Emergency Management Card의 기본 암호는 “calvin”이었고, 초기 Dell iDRAC를 다뤄봤다면 익숙한 암호일 것임. 우연은 아니라고 봄
    참고로 Intel 직원에게 EMC의 코드명이 “Hobbes”였다고 들었지만 문서화된 것은 찾지 못했음
    EMC 버전은 eBay에서 종종 보이고 ISA와 PCI 버전이 모두 있었음. 카드 위의 x86 PC였고, 일부 또는 전부에는 내장 UPS가 있었음. 대역 외 관리를 붙이기 위한 PCMCIA 슬롯, 외부 전원공급장치가 있었고 카드의 호스트 버스 인터페이스와 독자 커넥터를 통해 서버 메인보드에 연결됐음
    몇몇 EMC 버전의 펌웨어를 내려받아 살펴봤는데, 일부는 임베디드 DOS 머신처럼 보였음. 언젠가 해보려는 장난감 프로젝트로 남아 있어서 아직 코드를 역공학하거나 qemu에서 돌려보지는 못했지만 해보고 싶음
    Intel 레퍼런스 플랫폼을 팔던 Unisys, Fujitsu, ALR/Gateway, NCR 같은 서드파티도 이 카드를 제공했음. 판매 목록에서 이 카드를 보면 Intel 레퍼런스 플랫폼이라는 좋은 단서가 되고, “LDSM” 참조도 단서가 됨
    이 계보를 아는 사람이 있다면 정말 흥미로울 것임
    https://www.intel.com/pressroom/archive/releases/1998/ld1030...
    https://web.archive.org/web/20240903131630/https://www.ebay....

  • Intel ME와 AMD PSP는 CPU를 호스트 펌웨어가 실제로 실행될 수 있는 x86 PC 같은 상태로 만드는 데 큰 역할을 함
    초기화 복잡도가 너무 높아져서, 전통적인 초기 BIOS 시작 코드처럼 이상하게 제한된 어셈블리로 모든 로직을 쓰기보다, C로 프로그래밍 가능한 얌전한 별도 임베디드 코어에서 소프트웨어로 처리하는 편이 더 말이 됨
    일부 HPE ProLiant에서는 이 저수준 초기화의 일부를 실제로 iLO가 수행하는 것으로 보임. 그 부팅 단계에서는 iLO가 프레임버퍼도 직접 제어하고, G10에서는 “콘솔을 호스트에 넘긴다”는 식의 메시지가 잠깐 보인 뒤 디스플레이가 재초기화되어 기능키 안내가 뜸
    Dell도 비슷한 일을 할 것 같지만, 초기 단계에서는 “Please wait”와 큰 로딩 표시만 나오고 진행 상태는 보이지 않음

  • IPMI와 다른 해법도 좋지만, 원하는 것은 항상 실행 중인 UEFI 셸에 대한 표준 직렬 인터페이스임. 그 직렬 포트에 어떻게 접근할지는 내가 알아서 할 문제임

    • 셸이 의존하는 UEFI 부트 서비스는 부트로더나 운영체제가 ExitBootServices()를 호출한 뒤에는 사용할 수 없음
      코드는 말 그대로 RAM에서 빠지고 해당 영역은 운영체제에 반환되므로 구현이 쉽지 않음
    • Sun SPARC와 다른 Unix 시스템에서 그리운 점은 아주 낮은 수준에서 제대로 된 원격 접근이 가능했다는 것임
      BIOS/UEFI 원격 콘솔은 늘 까다롭고 성공 여부가 들쭉날쭉했음. 입출력을 맞추려면 GRUB이나 커널 설정을 자주 만져야 했음
    • 서버 하드웨어는 대개 직렬로 UEFI에 접근하게 해줌. 그래도 원격 전원 제어는 필요하지 않나 싶음

  • IPMI는 쓸모가 있지만, 상업 회사들이 하드웨어를 장기적으로 제대로 지원할 것이라고 믿을 수 없다는 사실을 분명히 보여줌
    IPMI에서 돌아가는 운영체제는 시스템이 새것일 때는 대체로 비교적 안전하지만, 새 CPU 소켓이 나오면 제조사는 오래된 시스템 업데이트에 점점 관심을 잃음. 같은 IPMI 하드웨어가 구형·신형 보드 양쪽에 있어도 마찬가지임
    IPMI 하드웨어에 자체 운영체제를 올릴 수 있다면 훨씬 유용할 것임. 그러면 인터넷에 바로 연결해도 안전할 수 있음. 지금은 VPN, SSH 포트 포워딩, 별도 네트워크 세그먼트 같은 사이드밴드 통신이 필요해서 IPMI를 지원하려고 추가 하드웨어와 설정이 많이 생김
    대규모 설치에서는 추가 비용이 잘 분산되지만, 소규모 설치에서는 꽤 큰 부담임. 단일 장비를 코로케이션하는 정도라면 가치가 없을 정도임
    IPMI를 인터넷에 직접 안전하게 노출할 수 없어서 결국 장비마다 어떤 형태의 Pi를 붙이게 됐음. 그렇게 하면 직렬 포트를 쓰는 것이 똑같이 쉽고, 오히려 더 쉬움. 결국 VAX, Sun, Alpha 시절부터 있던 표준 직렬 포트 제어로 돌아가는 셈이고, 생각할수록 불안전한 네트워크 인터페이스보다 훨씬 말이 됨

  • 더 작은 배포라면, 예컨대 코어 1만 개 정도 규모에서는 통합업체를 거쳐 직접 구축하겠음
    Gigabyte/ASRock Rack 메인보드, Epyc 9003 시리즈, RAM 384GB, 일반적인 이중 전원공급장치 구성이면 노드당 7천 달러 정도이고 전력 효율도 꽤 좋을 수 있음
    내장 IPMI도 꽤 괜찮고 ipmitool과 잘 맞으며, 보통 Redfish 관련 기능도 어느 정도 들어 있음

  • IPMI는 정말 좋아하지만 홈랩 용도에서 마음에 안 드는 점은 유휴 전력이 약 5W 더 든다는 것임
    Gigabyte MC12-LE0 보드와 Ryzen Pro 5650 조합은 홈 서버로 50달러 정도라 당연한 선택처럼 보이지만, 더 높은 전력 소비가 완전히 마음에 들지는 않음
    Dell T20/T30 같은 구형 장비에는 Intel AMT가 있는데 기능은 훨씬 약하고 보안 결함도 있지만, MeshCommander와 함께 쓰면 원격 관리를 할 방법은 최소한 생김. MeshCommander는 아쉽게도 중단됐고 릴리스가 여기저기서 사라졌지만, 운 좋게 MSI와 Node 패키지를 서버에 저장해뒀음
    Raspberry 4와 8달러짜리 단순 USB-HDMI 캡처 카드로 PiKVM V2를 시도해볼 계획임: https://docs.pikvm.org/v2/
    일부 기능이 없다는 점을 빼면, 원격 관리를 전혀 지원하지 않는 장치에도 더 범용적으로 쓸 수 있어 유망해 보임

    • 추가 전력 소모는 전원공급장치 품질에 크게 좌우됨. 높은 부하와 유휴 상태 모두에서 효율적인 전원공급장치를 만드는 것은 꽤 어려움
      BMC가, 때로는 NIC에 내장된 BMC가, 정말 그만큼 전력을 먹을지는 의심스러움. 게다가 Raspberry 4로 PiKVM을 쓰면 5W를 넘을 것임
    • 펌웨어가 공개된 지금은 NanoKVM을 알아보는 중임
      https://github.com/sipeed/NanoKVM
    • MeshCommander 릴리스는 아직 https://www.meshcommander.com/에서 받을 수 있고 NPM으로도 설치 가능함
      써보지는 않았지만 후속으로는 https://meshcentral.com/가 목표로 보임
    • MeshCommander 0.96은 웹사이트에서 다시 받을 수 있음. 개발자가 새 직장에 적응하느라 그랬다는 내용을 읽었음

  • IPMI에서 큰 질문은 기본 키가 무엇이냐는 점임
    공급망 어딘가에서 누군가 IPMI 키를 추가로 설치하거나 기본 키가 있다면, 그 사람은 컴퓨터를 원격 관리할 수 있음
    https://www.rapid7.com/blog/post/2013/07/02/a-penetration-te...

    • 해당 링크의 추가 인용처럼, IPMI 2.0 인증 과정은 클라이언트가 인증하기 전에 서버가 요청된 사용자의 암호에 대한 salted SHA1 또는 MD5 해시를 클라이언트에 보내도록 요구함
      IPMI는 암호 최대 길이도 20자임. 현실에서는 해시가 제한된 계약 기간 안에서 움직이는 알려진 모의침투 테스터에게만 비밀로 남는다고 기대할 뿐, 시간이 무제한인 실제 공격자에게는 그렇지 않다는 점을 봐야 함
      이 부분에는 매우 비판적임. 사양에 들어간 지 20년이 됐음. 소프트웨어의 장점은 하드웨어보다 바꾸기 쉽다는 것 아닌가. “VLAN에 넣어야 한다”고 말하기는 쉽지만, 평가를 나가보면 IPMI가 거의 항상 업무망에 붙어 있음
      기본값에 멍청한 것을 넣으면 전 세계에 멍청한 구성이 퍼지고, 지식 있는 보안 관리자가 없는 모든 회사가 “서버를 사는” 순간도 여기에 포함됨
    • 항상 물리적으로 분리된 네트워크에 있어야 하고, 시스템과 NIC를 공유하는 BMC는 피해야 함
답변달기