격리된 BMC/IPMI 망에서 서버 하드웨어 원격 모니터링 구축기 — bastion·VLAN·채널·읽기전용 계정
온프레미스 베어메탈 클러스터의 서버 하드웨어 상태(전원·온도·팬·전력)를 외부 협력기관에 읽기전용으로 열어주는 작업을 하면서 겪은 개념·문제·해결 과정을 정리한다. 실제 IP·MAC·기관명 등 식별 정보는 문서용 대역/가명으로 바꿨다 — IPMI 관리망 10.20.0.0/24, 노드 내부망 10.10.0.0/24, 외부 협력망 203.0.113.0/29, 모니터링 계정 hwmon, 협력기관 “PartnerOrg”.
대상: 베어메탈 서버의 OOB(out-of-band) 관리 경로를 처음 구성하는 서버·인프라 엔지니어
[00] 배경 개념 — BMC·IPMI·in-band/OOB·bastion
작업을 이해하는 데 필요한 용어 네 개를 먼저 정리한다.
[00-1] BMC (Baseboard Management Controller)
서버 메인보드에 붙은 별도의 초소형 관리 컴퓨터다. 서버 본체(OS)와 독립적으로, 대기전원(standby)만 들어와도 항상 켜져 있다. 벤더별 상표명이 iDRAC(Dell), iLO(HPE), BMC(Intel/Supermicro) 등으로 다르지만 기능은 같다. 전원 on/off·리셋, 온도·팬·전압·전력 센서 읽기, 하드웨어 이벤트 로그(SEL), 원격 콘솔을 제공한다. OS가 정지해 있어도 이 기능이 모두 동작한다.
[00-2] IPMI (Intelligent Platform Management Interface)
BMC와 통신하는 표준 프로토콜이다. ipmitool이 사실상 표준 클라이언트다.
[00-3] in-band vs out-of-band(OOB) — BMC에 접근하는 두 경로
| 방식 | 경로 | 특징 |
|---|---|---|
| in-band | 그 서버 OS 안에서 메인보드 내부 버스(KCS)로 자기 BMC 접근 (/dev/ipmi0) |
IP·계정 불필요. 단 OS가 켜져 있어야 함 |
| out-of-band | 네트워크로 BMC의 IP에 접속 (RMCP+, UDP 623) | BMC IP·계정·경로 필요. 노드 OS가 꺼져 있어도 됨 |
여기서 중요한 점은 BMC가 OS 외부의 장치여서 리눅스 ip addr에 나타나지 않는다는 것이다. 전용 관리 NIC(데이터 NIC와 물리적으로 다른 포트)를 통해 자기만의 IP로만 접근된다.
[00-4] bastion(관문 호스트)
BMC들은 보통 외부와 분리된 전용망(IPMI 네트워크)에만 물려 있다. 보안·안정성 때문에 일부러 격리한 구성이라 외부에서 직접 접근할 수 없다. bastion은 그 격리망으로 통하는 유일한 관문 서버로, 사용자가 접속하는 망과 IPMI 격리망 양쪽에 인터페이스를 하나씩 둔다. 사용자는 bastion까지만 접속하고, bastion에서 ipmitool을 실행해 BMC를 조회한다.
IPMI/BMC가 전체 인프라에서 차지하는 위치(관리 경로 이중화)는 스위치 이중화 개념 글의 IPMI/BMC 절도 참고.
[01] 필요성 — BMC 모니터링이 필요한 이유
외부 협력기관(PartnerOrg)이 운영 중인 물리 노드의 하드웨어 상태를 직접 확인하기를 요청했다. VM/컨테이너 지표(k8s·OpenStack)는 이미 Prometheus로 노출되지만, 이는 소프트웨어 레벨 지표다. 필요한 것은 그 아래 계층인 물리 서버의 온도·팬·전력·전원 상태·하드웨어 이벤트였다.
이 정보의 출처가 바로 BMC다. 그리고 요구는 읽기전용이었다. 전원제어나 콘솔 같은 위험한 권한은 주지 않고, 센서 값만 보게 한다.
두 가지 방식이 가능했다.
- in-band exporter: 각 노드가 자기 BMC를 로컬로 읽어 Prometheus에 올림. BMC 네트워크·계정 불필요. 단 노드 OS가 꺼지면 끊김.
- out-of-band(원격): 수집기가 BMC IP로 접속해 읽음. 노드가 꺼져 있어도 수집. 대신 BMC망·계정 필요.
협력기관이 직접 ipmitool을 실행해 확인하기를 요청했기 때문에, OOB 경로와 읽기전용 계정을 준비하기로 했다. 이후 문제의 대부분은 이 결정에서 나왔다. OOB는 격리된 BMC망에 실제로 접근할 수 있어야 하기 때문이다.
[02] 현황 — 확인된 문제
계정을 만들고 IP를 할당하면 끝나는 작업으로 예상했지만, 실제로는 다음 다섯 가지 문제가 겹쳐 있었다.
(1) BMC IP가 제각각·중복이었다.
노드 15대의 BMC IP를 조사하니, 상당수가 같은 IP(중복) 로 설정돼 있거나 아예 미설정이었다. 서로 다른 서브넷(10.20.0.x와 10.30.0.x)이 섞여 있기도 했다. 이 상태로는 하나의 관리망으로 묶을 수 없다.
(2) 격리된 IPMI망에 접속할 호스트가 없었다. BMC들은 전부 전용(dedicated) 관리 NIC로 격리 스위치에만 연결돼 있었다. 그리고 그 격리망에 인터페이스를 가진 서버 OS가 하나도 없었다. 노드가 자기 BMC조차 ping이 되지 않았다(전용 NIC라 OS와 분리). BMC IP를 정확히 설정해도 어디서도 접근할 수 없는 상태였다.
(3) 스위치 VLAN 설정이 두 포트를 분리하고 있었다. bastion 후보 노드의 유휴 랜포트를 격리 스위치에 연결하고 IP를 설정했는데도 BMC에 전혀 접근되지 않았다. 링크 LED는 켜져 있었다. 원인은 스위치의 VLAN 격리 — 관문 포트와 BMC 포트가 서로 다른 VLAN에 있었다.
(4) 일부 서버는 BMC가 다른 채널에 연결돼 있었다. 대부분 노드는 BMC LAN이 채널 1에 있었는데, 한 서버(Intel 보드)는 케이블이 채널 3(전용 관리포트)에 연결돼 있었다. 채널 1에 IP를 설정해도 응답이 없다. 그리고 그 채널은 암호 스위트(cipher suite) 표준값(suite 3)이 비활성이라, IP를 정확히 설정해도 인증 세션이 생성되지 않았다.
(5) BMC 펌웨어가 정지한 노드도 있었다.
한 노드는 in-band ipmitool mc info조차 타임아웃이었다. /dev/ipmi0도 있고 커널모듈도 정상인데 BMC 칩이 응답하지 않았다. BMC 펌웨어 자체가 hang한 상태다. BMC는 대기전원으로 계속 동작하기 때문에, 서버를 재부팅해도 해소되지 않는다.
[03] 개선 1 — BMC IP 표준화 (in-band)
전 노드 BMC IP를 하나의 서브넷 10.20.0.0/24로 통일했다. 여기서 이용한 성질은 BMC IP 설정이 네트워크 없이 in-band로 가능하다는 점이다. 각 노드에서:
1
2
3
4
sudo ipmitool lan set 1 ipsrc static
sudo ipmitool lan set 1 ipaddr 10.20.0.1X # 노드별
sudo ipmitool lan set 1 netmask 255.255.255.0
sudo ipmitool lan set 1 access on
BMC망에 아직 접근할 수 없는 상태에서도, 서버 안에서(KCS) BMC 설정을 변경할 수 있다는 점이 핵심이었다.
[04] 개선 2 — bastion에 격리망 진입로(leg) 만들기
격리망에 접속할 호스트가 없다는 문제는, 관문 노드의 유휴 NIC 하나를 IPMI 스위치에 연결하고 그 인터페이스에 IP(10.20.0.254)를 설정해 해결한다. 이 leg가 유일한 진입 경로가 된다.
1
2
sudo ip addr add 10.20.0.254/24 dev <유휴 NIC> && sudo ip link set <유휴 NIC> up
# 재부팅 영속화는 netplan/systemd로
주의: 관문이 쿠버네티스 노드라면
ip_forward=0을 강제하지 말 것(파드 라우팅이 동작하지 않는다). 외부↔BMC 직접 라우팅 차단은 방화벽으로 한다.
[05] 진단 기법 — 링크는 연결됐는데 BMC에 접근되지 않을 때
leg를 연결했는데 BMC가 보이지 않을 때, 스위치가 내보내는 프레임으로 직접 확인하는 방법이다.
[05-1] 같은 L2 도메인의 장치 확인 — 패시브 캡처
1
sudo tcpdump -i <leg> -ne not stp
스위치 STP만 잡히고 BMC 프레임이 0이면, BMC가 같은 브로드캐스트 도메인에 없다는 뜻이다.
[05-2] 포트의 VLAN 확인 — LLDP
스위치는 30초마다 각 포트로 자기 이름·포트·PVID를 알린다.
1
sudo tcpdump -i <leg> -v ether proto 0x88cc
여기서 Port VLAN Id (PVID): 40 같은 값이 출력된다. 추측이 아니라 스위치가 직접 보고하는 값이다. 이 값으로 관문 포트가 VLAN 40이고 BMC는 다른 VLAN이라는 점을 확정했다.
[05-3] 케이블이 연결된 실제 채널 확인
BMC 전용 포트는 OS에 나타나지 않는다. 각 채널에 구분 IP를 임시로 설정하고 bastion에서 ARP로 확인하면, 응답이 오는 IP의 채널이 실제 케이블이 연결된 포트다.
VLAN 문제는 스위치에서 관문 포트와 BMC 포트를 같은 VLAN으로 맞춰 해결했고, 채널 문제는 IP를 실제 연결된 채널(3번)로 옮기고 그 채널의 cipher suite를 표준값으로 복구해 해결했다.
[06] 개선 3 — 읽기전용 계정과 권한 모델
ipmitool은 도구일 뿐, 실제 가능한 동작은 BMC 계정의 권한(privilege) 이 정하고 BMC 펌웨어가 강제한다.
| priv | 이름 | 가능 |
|---|---|---|
| 2 | USER | 센서·SDR·SEL·상태 읽기만 |
| 3 | OPERATOR | + 전원제어 |
| 4 | ADMIN | + 계정/채널 설정, 원격 콘솔 |
협력기관에는 USER(2) 계정 hwmon 을 각 BMC에 생성했다. 읽기전용이라 ipmitool로 접속은 되지만 chassis power off 같은 제어 명령은 BMC가 거부한다. 도구 실행은 가능하고 전원제어만 차단되는 구성이다. 추가로 무인증 암호 스위트(cipher 0)는 비활성 상태를 확인했다.
1
2
3
4
5
# 읽기전용 계정 생성 (각 노드 in-band)
sudo ipmitool user set name <slot> hwmon
sudo ipmitool user set password <slot> '<강한비번>' # 화면 노출 없이 파일에서 주입
sudo ipmitool user priv <slot> 2 1 # 2 = USER
sudo ipmitool user enable <slot>
사용 시 반드시 -L USER를 붙인다(안 붙이면 도구가 ADMIN 세션을 요청해 실패).
1
ipmitool -I lanplus -H 10.20.0.1X -U hwmon -f <비번파일> -L USER sdr type Temperature
[07] 개선 4 — 정지한 BMC 복구: AC 전원 차단
펌웨어가 hang한 BMC는 OS 재부팅으로 복구되지 않는다(BMC는 대기전원으로 계속 동작하기 때문이다). 유일한 방법은 AC 전원을 완전히 끊는 것 — 전원코드를 뽑거나(이중전원이면 둘 다) PDU에서 내려 대기전원까지 방전(30초~수 분)한 뒤 재투입한다. 그러면 BMC 펌웨어가 콜드 부팅으로 리셋된다.
이때 그 노드에서 동작 중인 서비스가 있으면 먼저 정상 종료해야 한다. 이 작업에서는 해당 노드에 게스트 클러스터 VM이 실행 중이어서, VM을 정상 종료하고 오케스트레이터(자동복구)를 일시중지한 뒤 전원을 내렸다. AC 리셋 후 BMC는 정상 응답했다.
[08] 결과와 교훈
- 대상 노드 전부 BMC IP를
10.20.0.0/24로 통일하고, 읽기전용 계정hwmon을 생성했다. - 관문(bastion)에 격리망 leg를 영속화해, 협력기관이 관문에 SSH로 들어와
ipmitool로 각 BMC의 온도·팬·전력·SEL을 조회할 수 있게 됐다. 권한은 읽기전용으로 고정되어 있다. - 상시 대시보드가 필요하면
prometheus-ipmi-exporter(원격 모드)를 leg가 있는 호스트에서 실행하고 target에 BMC들을 등록하면 된다. 수동 확인과 같은 데이터를 자동·주기화하는 것뿐이다.
정리하면 다음과 같다.
- IP 설정 성공이 도달 가능을 뜻하지 않는다. BMC IP가 맞아도 격리망에 연결된 호스트가 없거나, 스위치 VLAN이 다르거나, 케이블이 다른 채널에 연결돼 있으면 접근되지 않는다.
-
스위치가 보내는 LLDP를 먼저 확인한다. 링크는 연결됐는데 BMC에 접근되지 않을 때 LLDP(
0x88cc) 캡처 한 번으로 포트와 VLAN을 확정할 수 있다. 케이블을 하나씩 뽑아 확인하는 것보다 빠르다. - BMC 펌웨어도 hang한다. 대기전원으로 계속 동작하므로 OS 재부팅과 무관하고, AC 차단만이 리셋 수단이다.
-
읽기전용은 도구가 아니라 계정 권한으로 강제한다.
ipmitool을 제공해도 USER 권한이면 전원제어는 되지 않는다.
BMC/IPMI는 물리 인프라의 최하위 계층에서 하드웨어 상태를 직접 제공한다. 이 경로를 한 번 구성해 두면 노드 OS가 꺼져 있어도 온도와 팬 동작 상태를 확인할 수 있다.