vulcan Blog

Proxmox에서 linux bridge 속도 테스트하기 01

Sat, 12 Apr 2025 00:00:00 GMT

시작

Proxmox에서 보통 VM이나 CT에 네트워크를 할당할 때는 linux bridge를 사용한다. nic의 포트를 linux brige에 할당해서 사용하거나 같은 linux bridge에서 여러 VM이 통신을 할 수 있다. 여기서 nic의 포트 밖으로 나가지 않는 트래픽은 linux bridge에서 처리하는데 이 경우 host의 cpu가 처리하게 된다. 이 cpu는 네트워크 브릿징에 최적화된 칩이 아니기 때문에 속도에 제약이 발생할 수밖에 없다. 이 글에서는 proxmox의 linux bridge에서 내부적으로 낼 수 있는 최대 대역폭이 얼마인지를 테스트해 보려고 한다. (이 속도는 사용하는 cpu의 종류, 클럭에 따라 다를 수 있다.)

환경

하드웨어 : AMD EPYC Milan 7T83, 2933Mhz 채널당 2 dimm
proxmox version : proxmox-ve: 8.4.0 (running kernel: 6.8.12-9-pve)
Test VM : 42 core, 128GB
MTU : 9000

아래와 같이 MTU가 바르게 설정됐는지 확인할 수 있다.

1. 테스트 개요

테스트의 주요 목표는 다음과 같다:

vmdr Multiqueue 값 조정: Proxmox VM 내 네트워크 인터페이스의 multiqueue 수를 1, 2, 4, 8, 16, 32, 40으로 순차적으로 변경하여 테스트 진행
iperf3 병렬 채널 구성: 각 multiqueue 값에 대해 iperf3 테스트 채널 수를
- 기본 (1배): 현재 queue 수와 동일
- 2배: 현재 queue 수의 두 배
- 4배: 현재 queue 수의 네 배
  
  로 설정하여 성능 비교
성능 분석: 각 테스트 단계별로 네트워크 throughput, 지연 시간, 패킷 손실 및 CPU 부하 등을 측정하여 최적의 설정을 도출

2. 테스트 스크립트

#!/bin/bash
if [ "$#" -ne 1 ]; then
    echo "Usage: $0 <queue_number>"
    exit 1
fi

QUEUE="$1"
SERVER_IP="192.168.0.84"
TEST_TIME=30
OUTPUT_FILE="queue_${QUEUE}.txt"

if [ -f "$OUTPUT_FILE" ]; then
    rm -f "$OUTPUT_FILE"
fi

for MULT in 1 2 4; do
    CHANNELS=$(( QUEUE * MULT ))
    echo "==========================" | tee -a "$OUTPUT_FILE"
    echo "채널 수: ${CHANNELS} (입력 queue: ${QUEUE}, multiplier: ${MULT})" | tee -a "$OUTPUT_FILE"
    echo "테스트 시작: $(date)" | tee -a "$OUTPUT_FILE"
    echo "--------------------------" | tee -a "$OUTPUT_FILE"

    iperf3 -c "$SERVER_IP" -P "$CHANNELS" -t "$TEST_TIME" >> "$OUTPUT_FILE" 2>&1

    echo "테스트 종료: $(date)" | tee -a "$OUTPUT_FILE"
    echo "" | tee -a "$OUTPUT_FILE"
    echo "" | tee -a "$OUTPUT_FILE"

    sleep 5
done

echo "테스트 완료. 결과는 ${OUTPUT_FILE} 파일을 확인하세요."

3. 테스트 결과

자세한 결과는 여기의 파일을 확인하자.

Queue	채널 수	대역폭 (Gbit/sec)	Server VM CPU (%)	Proxmox CPU (%)	Client VM CPU (%)
1	1	12.7	1	3	2
1	2	25.8	4	5	5
1	4	28.5	4	4	2
2	2	27.8	4	4	2
2	4	27.7	4	4	2
2	8	28.7	4	4	2
4	4	27.1	4	4	2
4	8	29.1	2	5	2
4	16	56.2	9	10	6
8	8	52.6	8	10	6
8	16	64.1	12	15	9
8	32	66.6	23	29	16
16	16	71.4	12	19	13
16	32	74.4	41	48	30
16	64	71.0	39	44	26
32	32	76.4	65	50	30
32	64	72.7	78	65	30
32	128	75.8	55	53	30
40	40	77.2	40	40	26
40	80	69.2	96	30	13
40	128	70.7	96	44	18

40 * 4의 경우 160으로 iperf3의 최대 채널 수 128을 초과하기에 128로 낮춰서 테스트했음.

4. 테스트 분석

그래프 분석 그래프는 각 Queue 및 iperf3 채널 수에 따른 대역폭과 CPU 사용량 변화를 보여준다.

대역폭

Queue 값이 증가할수록 대역폭이 증가하였으나, Queue가 16을 넘어서면 약 70~77Gbps 수준에서 포화 상태를 보인다.

특히 Queue 8에서 16채널(64.1Gbps)을 사용할 때 가장 효율적으로 대역폭이 증가하는 구간을 확인할 수 있다.

CPU 사용량

Proxmox와 VM의 CPU 사용률은 Queue 및 채널 수 증가와 함께 급격히 증가한다.

특히 Queue 32 이상, 채널 수가 Queue의 2~4배인 경우 VM 및 Proxmox CPU 부하가 상당히 높아졌다.

결과적으로 multiqueue를 너무 높이 설정하면 얻는 성능 증가 대비 CPU 자원 소모가 너무 높아진다. 특히 multiqueue가 8인 설정에서 좋은 성능과 적절한 CPU 자원 활용률을 보였다.

나는 multiqueue를 조정해서 VM에 올린 TrueNAS와 proxmox간의 NFS연결에서 충분한 대역폭을 확보하고 싶었다. NFS의 마운팅 옵션에서 최대 16개의 커넥션을 설정할 수 있으므로 multiqueue를 8 ~ 16 정도로 설정하면 적당할 것 같다. 다음 글에서는 VM간의 실질적인 NFS 속도를 테스트해 보려고 한다.

이 글이 Proxmox를 운영하거나 네트워크 성능을 최적화하려는 사용자들에게 좋은 참고 자료가 되길 바란다.

잘못된 설명이나 추가로 설명했으면 좋겠는 부분, 오타, 맞춤법에 대한 지적은 언제나 환영합니다.

이 글을 홈서버 사용자를 위한 것입니다. 틀린 내용이 있을 수 있고, 각자의 상황에 따라 데이터가 달라질 수 있습니다.
이 글을 포함해 인터넷에 존재하는 코드, 스크립트를 복사해 사용할 때는 코드, 스크립트를 충분히 읽고, 분석하여 문제가 없는지 확인하시기를 바랍니다. 최소한 ChatGPT 같은 AI에 해당 코드, 스크립트가 정말 안전하고 사용해도 되는지 확인받으시길 권장합니다.

홈서버 2년간의 회고

Sat, 15 Mar 2025 00:00:00 GMT

시작

2022년 11월경부터 본격적으로 홈서버를 운영한 지 벌써 2년하고도 반 정도가 지났다. 현재 홈서버의 구성에 대해서 살펴 보며 분석한 내용과 겪었던 실질적인 문제들을 바탕으로 새로운 서버 구성에 대한 큰 그림을 그려보고 지금까지의 경험을 정리해 보고자 한다.

1. 현재 구성과 문제점

서버의 보다 자세한 구성에 대한 설명은 bbconf에서 발표했던 내용에 보다 자세히 적혀있다. 지금은 추가된 부분이 있지만 대략적인 부분은 큰 차이가 없다.

현재의 구성은 아래와 같다. 많은 VM, CT들을 운영하고 있는 메인 노드와 네트워킹, 모니터링, 관리 도구 등 운영에 꼭 필요하거나 서비스가 죽었을 때 치명적인 부분들을 담당하는 서브 노드 총 2개의 노드로 구성돼 있다. 이제부터 문제점을 하나씩 파악해 보자.

1.1. 단일 게이트웨이

지금까지 가장 많은 문제를 일으킨 SPOF이다. 서버 전체의 게이트웨이, 방화벽, DNS, DHCP, reverse proxy, VLAN등 대부분의 네트워크를 pfsense가 담당하고 있다. 때문에 pfsense VM이나 해당 VM이 구동되는 서브 노드가 다운되면 외부에서 서버 전체에 대한 접근 방법이 없어지고, 내부에서도 인터넷에 접속이 불가능해진다. pfsense자체를 업데이트할 때도 다운타임이 발생하지만, 이는 비교적 짧다. 문제는 pfsense는 호스팅하고있는 하이퍼바이저인 proxmox를 업데이트할 때다. proxmox의 업데이트 이후 재부팅은 비교적 오래 걸리고, 매끄럽게 진행되지 않을 경우 다운타임은 무제한으로 길어진다. 때문에 이 문제를 해결해야 하는데, 방법은 두 가지가 있다.

pfsense의 HA 기능을 이용하는 것
proxmox의 HA 기능을 이용하는 것

여기서 중요한 것은 두 방법 모두 2개 이상의 proxmox node가 필요하다는 것이다. pfsense의 HA 기능을 적절하게 활용하기 위해선 결국 서로 다른 proxmox node가 필요하고, 본격적인 proxmox HA 기능을 위해선 3개 이상의 node가 권장된다. 그럼 각각의 장단점에 대해서 살펴보자.

pfsense의 HA 기능을 이용하는 것
- 장점
  - 두 pfsense가 vrrp 패킷으로 서로의 생존을 확인하고 만약 active pfsense가 죽었을 때 standby pfsense가 바로 역할을 대신해서 다운타임을 최소화할 수 있다.
  - 대부분의 방화벽이나 게이트웨이가 이 방법을 사용한다.
- 단점
  - 2개의 공인 IP가 필요하다. 보통의 통신사의 정책에선 추가 비용을 내지 않으면 공인 IP는 1개가 원칙이다. 그리고 내가 아직은 알지 못하는 DDNS에 대한 지식이 필요할 수 있다.
  - 더블 NAT이 될 수 있다. 이는 구성의 불편함을 초래할 수 있다.
proxmox의 HA 기능을 이용하는 것
- 장점
  - pfsense의 HA 기능을 이용할 때의 단점을 생각하지 않아도 된다.
  - 다른 VM에도 proxmox HA 기능을 적용할 예정이기에 추가로 pfsense HA에 대해서 신경 쓰지 않아도 된다.
  - 조사에 따르면 ceph 스토리지를 바탕으로 적절한 HA구성을 한다면 live migration을 proxmox에서 지원하기 때문에 이 방법도 다운타임이 거의 없다.(ping 기준 1~5 ping 정도가 드랍된다는 영상을 발견했다.)
- 단점
  - pfsense를 업데이트할 경우에 발생하는 다운타임은 해결할 수 없다.
  - proxmox HA 구성이 복잡하다.

이미 proxmox에 ceph를 이용해 HA가 제대로 작동하는 3 node cluster를 구축할 계획을 세웠기 때문에 사실상 가장 큰 단점이 없는 셈이나 마찬가지다. 그리고 pfsense의 업데이트로 인한 다운타임은 경험상 1분 이내이다. 때문에 들어오는 WAN을 단순한 스위치에 연결하고 이걸 다시 3개의 노드에 연결해 준다. pfsense VM이 migration되면서 같은 MAC 주소를 유지하기 때문에 같은 공인 IP로 연결되게 된다. 때문에 proxmox의 HA 기능을 이용해 게이트웨이의 다운타임을 최소화하기로 결정했다. 1년에 2~4회 정도 업데이트를 진행한다고 생각하면 연간 다운타임을 5분 이하로 유지할 수 있을 것으로 기대한다.

추가로 pfsense를 사용하면서 최신 드라이버에 대한 지원이 굉장히 느리다는걸 알았다. 최신 데비안 버전에도 올라간 드라이버가 이후에 진행된 pfsense의 업데이트에 포함되지 않는 경우도 있다. 때문에 비교적 업데이트가 빠른 opnsense로 migration하기로 결정했다.

1.2. 단일 스위치

현재는 10Gbps 8port switch를 사용하고 있다. 네트워크 케이블을 재배치하거나, 스위치를 업데이트할 때 필연적으로 다운타임이 발생할 수밖에 없다. 이것을 해결하고자 mikrotik switch를 이용해 multi chassis link aggregation을 구성하고, 각 노드에서 backup bond를 하나 더 구성해 각 switch의 실패뿐만 아니라 특정 nic의 다운에도 대응할 수 있게 구성하려고 한다.

1.3. 모니터링 부족

기존의 grafana를 구성할 때 InfluxDB를 이용해 모든 메트릭 데이터를 여기로 통합하려했는데 잘 되지 않았다. 때문에 InfluxDB와 Prometheus와 병용하고, 서버 전체로 흩어져있는 로그 또한 수집해서 모니터링 할 수 있도록 loki를 이용해서 로그도 수집할 예정이다.

1.4. 서비스의 파편화

ansible semaphore, zitadel, nextcloud, netbird, blog, immich, grafana, plex, open web ui, pihole 등 많은 서비스들을 운영하고 있다. 하지만 일부는 stand alone, 일부는 docker compose로 여러 VM에 걸쳐 분리돼서 관리되고 있다. 이를 최대한 하나의 노드에서 docker compose를 이용해 관리하는 방식으로 migration하고, 가능하다면 RKE2로 쿠버네티스를 구성해서 쿠버 클러스토로 이전하는 게 목표이다.

1.5. 단일 전원

기존의 구성에서는 1개의 UPS에 모든 기기들이 연결돼 있었다. 이는 UPS가 실패하거나, PDU가 실패하거나, 각 케이블에 문제가 생겼을 때 전체 시스템을 죽일 수 있다. 그리고 기존의 납축전지를 이용한 UPS의 경우 2~3년마다 배터리를 교체해야 하고 매우 무겁고 비싸다. 하지만 최근에 ecoflow에서 river 3, delta 3 시리즈부터 10ms 이내의 전환 시간을 가진 UPS기준에 부합하는 파워뱅크를 출시했고, NUT최신버전에서 해당 기기에 대한 지원을 시작했다. 그래서 이 기기를 이용해 2개의 UPS를 구성하고, 포트별 on/off 조절이 가능한 PDU를 사용해서 강제 전원 on/off 기능도 추가할 예정이다.

1.6. 단일 WAN

단일 게이트웨이도 문제지만 WAN이 하나라는 건 치명적이다. 내가 외부에 있을 때 문제가 생기면 접근할 수 있는 수단이 전혀 없기 때문이다. 그리고 새로운 메인 노드는 mz32-ar0보드를 사용해 내장 BMC가 있고, 서브 노드로 구매 예정인 기기들도 Intel vpro 기능을 지원해서 BIOS레벨에 원격으로 접근이 가능하다. 하지만 여전히 네트워크는 필요하고, vpro나 BMC에 문제가 생겼을 경우 원격 접속이 불가능해진다. 때문에 pikvm을 이용해 모든 노드에 2가지 수단으로 BIOS레벨에 원격 접속이 가능하게 설정하고, 4G 모뎀을 이용해서 완전히 분리된 관리망을 구성할 예정이다.

2. 새로운 구성

아래와 같이 새로운 구성을 할 예정이다.

2.1. 네트워크

맨 오른쪽은 메인 스토리지 서버이고 공유스토리지를 위한 NFS전용으로 40Gbps 2포트를 LAG해서 사용하고 10Gbps를 각각 2포트씩 LAG해서 한개는 대용량 스토리지 전용으로, 나머지는 LAN으로 사용한다. 3개의 서브 노드는 10Gbps 2포트를 LAG해서 사용하고 1개의 2.5Gbps는 백업 bond로 나머지 1개는 WAN으로 연결된다. 흰색으로 표시된 USB4 연결은 ceph 데이터 이동을 위한 ring network를 구성해 사용할 예정이다.

2.2. 스토리지

모든 노드는 일반적인 nvme ssd 2장을 mirror구성으로 부트드라이브로 사용한다. 서브 노드의 경우 ceph와 VM을 위해 높은 iops를 확보하고 내구성을 위해 intel optane을 달아줄 예정이다. 메인 노드는 대용량 스토리지로 18TB 14장을 6장씩 RAIDZ2로 묶고 묶인 풀 2개를 stripe해서 사용하고 남는 2개는 hot spare로 사용할 예정이다. 이렇게 구성하면 14개 중 8개가 가용량이고 252TB중 144TB를 사용할 수 있다. 이 하드디스크 풀의 메타데이터용으로 역시 intel optane 2장을 mirror로 구성하고 이 optane 풀의 일부를 하드디스크 풀의 SLOG로 사용해 풀 내부의 ZIL을 둬서 속도가 저하되는 걸 방지한다. 그리고 공유스토리지용으로 micron 7450 MAX 4장을 stripe mirror로 구성해 속도와 안정성 모두 확보할 예정이다. 이 SSD 풀은 HDD 풀에 백업하고 HDD풀은 현재 사용 중인 메인 서버에 하이퍼백업을 해서 중요한 데이터의 경우 321백업 원칙을 지킬 수 있도록 했다.

2.3. 소프트웨어

하이퍼바이저로는 proxmox를 그대로 사용하고, grafana를 비롯해 기존에 사용하던 것들을 migration해줄 예정이다. pfsense의 경우 상기한 이유로 opnsense로 변경할 예정이고, 추가로 uptimekuma, speed tester등을 도입해서 업타임이나 인터넷 속도 등도 모니터링 할 예정이다.

결론

2년 반 동안 현재의 서버에서 많은 서비스들을 운영해 보고 정말정말 많은 트러블슈팅을 하면서 많은 것을 배웠다. 이 지식을 바탕으로 더욱 발전된 홈서버를 설계하고 운영하면서 지금까지보다 더 많은 것을 배우고 성장할 수 있었으면 좋겠다. 그리고 새로운 서버를 구성하면서 지금까지 한번 했던 과정들을 반복하는 것들이 많다. 이것들을 튜토리얼로 정리해서 더 많은 사람이 홈서버에 쉽게 입문해서 같이 성장하고 재미를 느꼈으면 한다.

운영중인 외부 서비스

지인이나 bbonf를 위해 구동되고 있는 서비스들의 목록

https://panty.run/

https://poptile.firekann.dev/

https://bbconfwebdav.vulcan.site/bbconf/

http://ramzida.com/

이사

2월 초에 본가로 이사하면서 서버도 이사했다. 아래와 같은 배선을 모두 제거하고 이사해서 24시간 이내에 복구했다.

이사 전

이사 후

Terraform으로 proxmox에 VM 생성하기

Tue, 11 Mar 2025 00:00:00 GMT

시작

이전 글에서 Packer를 이용해서 proxmox에 ubuntu server Template를 만들어봤다. Template를 clone 해서 VM을 생성함으로서 편하게 설정이 완료된 VM을 만들 수 있었다. 하지만 쿠버클러스터같이 같은 패키지를 설치한 비슷한 설정의 VM을 동시에 수십 혹은 수백 개를 생성해야 한다면, 이것을 모두 수동으로 clone하는 것은 쉽지 않을뿐더러 어리석은 짓이다. 그 때문에 이 글에서는 Terraform을 이용해서 k8s클러스터를 위한 VM 여러 개를 띄우는 과정을 자동화해 보겠다.

1. Terraform이란?

Terraform은 HashiCorp에서 개발한 인프라스트럭처를 코드로 관리(IaC, Infrastructure as Code)하는 도구다. 즉, 서버, 네트워크, 데이터베이스, 클라우드 리소스 등 다양한 인프라스트럭처를 선언적(configuration) 파일로 정의하고, 이를 기반으로 일관되고 자동화된 방식으로 배포, 수정, 삭제할 수 있다. Terraform은 이러한 특징들 덕분에 클라우드 인프라 운영 자동화와 관리의 복잡성을 크게 줄여준다.

2. install Terraform

기본적으로 Terraform의 설정에 관한 문서는 여기에 아주 잘 정리돼 있다. ubuntu server noble에 설치할 거기 때문에 이 튜토리얼을 따라 하자.

wget -O - https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

설치가 완료되고 terraform --version을 입력했을 때

~$ terraform --version
Terraform v1.10.5
on linux_amd64

이런 식으로 나온다면 설치가 완료된 것이다.

3. directory configuration

Terraform을 이용해서 proxmox에 VM을 생성하기 위해서는 Terraform코드(vm-qemu-kube.tf)와 proxmox에 접속하기 위한 credentials를 저장할 파일(credentials.auto.tfvars)과 proxmox provider정보 파일(provider.tf)이 필요하다. 그리고 각 VM마다 다른 정보를 변수화해 저장하기 위한 파일(kube-cluster-config.auto.tfvars)이 필요하다.

terraform/
└── kube-cluster
    ├── credentials.auto.tfvars
    ├── kube-cluster-config.auto.tfvars
    ├── provider.tf
    └── vm-qemu-kube.tf

4. file configuration

ubuntu server noble(24.04.x)를 기준으로 진행하겠다.

4.1. provider.tf

Terraform이 proxmox와 상호작용 할 수 있도록 proxmox provider를 설정하는 파일이다. Terraform이 어떤 클라우드 서비스와 상호작용 해서 코드를 실행하기 위해선 클라우드 서비스 제공자(provider)에 대한 정보가 필요하다. 이 경우엔 proxmox가 클라우드 서비스 제공자이고, AWS, GCP 등 사용하는 클라우드 서비스에 따라 다를 수 있다.

terraform {
  required_version = ">= 0.13.0"

  required_providers {
    proxmox = {
      source = "telmate/proxmox"
      version = "3.0.1-rc6"
    }
  }
 }

variable "proxmox_api_url" {
  type = string
}

variable "proxmox_api_token_id" {
  type = string
  sensitive = true
}

variable "proxmox_api_token_secret" {
  type = string
  sensitive = true
}

variable "PUBLIC_SSH_KEY" {
  type = string
  sensitive = true
}

variable "USER" {
  type = string
}

variable "PASSWORD" {
  type = string
  sensitive = true
}

variable "vm_configs" {
  type = map(object({
    vmid = number
    ip   = string
    mac  = string
  }))
}

provider "proxmox" {
  pm_api_url          = var.proxmox_api_url
  pm_api_token_id     = var.proxmox_api_token_id
  pm_api_token_secret = var.proxmox_api_token_secret
  pm_tls_insecure     = true  #proxmox가 적절한 tls 인증서를 보유하고 있지 않을 경우 true로 해줘야한다.
}

proxmox_api_*변수들은 모두 proxmox에 접속하기 위한 값들이다. 이전에 Packer글에서 사용했던 credentials과 유사하다.
PUBLIC_SSH_KEY, USER, PASSWORD는 cloud-init을 통해 생성될 계정의 ssh key, username, password이다.
vm_configs는 VM들을 생성할 때 각 VM마다 달라야 할 정보들을 변수로 지정하기 위함이다.

4.2. credentials.auto.tfvars

앞서 설명한 provider.tf에서 vm_configs을 제외한 변수의 값들을 저장하는 파일이다, 민감한 정보가 포함돼 있으니, 관리에 유의하도록 하자.

proxmox_api_url             = "https://YOUR_PROXMOX_IP:8006/api2/json"
proxmox_api_token_id        = "YOUR_USERNAME@REALM_NAME!tokenid"
proxmox_api_token_secret    = "TOKEN_SECRET"
USER     = "YOUR_USERNAME"
PASSWORD = "YOUR_PASSWORD"
PUBLIC_SSH_KEY = "YOUR_SSH_KEY"

4.3. kube-cluster-config.auto.tfvars

여러 VM을 생성하면 vmid, VM이름, vmbr의 MAC주소, IP주소 등 달라야 하는 값들이 있다. 그리고 여러 개의 VM을 한 번에 생성하려면 vm-qemu-kube.tf을 이 값들을 바꿔가며 여러 번 실행해야 한다. 이런 방식은 매우 번거롭고 Packer나 Terraform과 같은 IaC툴의 장점인 일관성 유지에 좋지 않은 방법이다. 때문에 이것들도 변수로 만들어 관리하는게 좋다.

vm_configs = {
  control01 = {
    vmid = 811
    ip   = "ip=192.168.80.11/24,gw=192.168.80.1"
    mac  = "bc:24:11:00:08:11"
  },
  control02 = {
    vmid = 812
    ip   = "ip=192.168.80.12/24,gw=192.168.80.1"
    mac  = "bc:24:11:00:08:12"
  },
  control03 = {
    vmid = 813
    ip   = "ip=192.168.80.13/24,gw=192.168.80.1"
    mac  = "bc:24:11:00:08:13"
  },
  worker01 = {
    vmid = 831
    ip   = "ip=192.168.80.31/24,gw=192.168.80.1"
    mac  = "bc:24:11:00:08:31"
  },
  worker02 = {
    vmid = 832
    ip   = "ip=192.168.80.32/24,gw=192.168.80.1"
    mac  = "bc:24:11:00:08:32"
  },
  worker03 = {
    vmid = 833
    ip   = "ip=192.168.80.33/24,gw=192.168.80.1"
    mac  = "bc:24:11:00:08:33"
  },
  worker04 = {
    vmid = 834
    ip   = "ip=192.168.80.34/24,gw=192.168.80.1"
    mac  = "bc:24:11:00:08:34"
  },
  worker05 = {
    vmid = 835
    ip   = "ip=192.168.80.35/24,gw=192.168.80.1"
    mac  = "bc:24:11:00:08:35"
  },
  worker06 = {
    vmid = 836
    ip   = "ip=192.168.80.36/24,gw=192.168.80.1"
    mac  = "bc:24:11:00:08:36"
  }
}

나의 경우에는 kubernetes control plane 3개, worker node 6개 총 9개의 VM을 생성했다. 각각의 control01, control02, …, worker06은 VM의 이름이 되고, vmid, ip, mac주소를 지정해 줬다. 나는 pfsense 를 쓰고 있기 때문에 VLAN tag 80번에 192.168.80.0/24인 VLAN을 만들고, 192.168.80.1 ~ 192.168.80.100까지를 static IP대역으로 지정하고, 미리 static IP table에 IP와 MAC 주소를 맵핑해줬다. 사용하고 있는 라우터의 종류에 따라 미리 설정해줘야한다.

4.4. vm-qemu-kube.tf

여기서 사용되는 값들에 대한 상세는 여기를 참고하자. 그리고 여기서 사용하는 대부분의 값들은 proxmox VM의 Hardware나 Option의 특정 값과 매칭되는 부분이 많으니 어떤 값으로 설정해야 할지 모르겠다면 기존에 사용하고 있던 VM의 값들을 참고하면 좋다. vm-qemu-kube.tf는 qemu VM을 띄우기 위한 설정 파일이다. kube-cluster-config.auto.tfvars에 있는 vm_configs를 하나씩 순회하면서 반복 실행하기 위해 for_each를 이용했다.

resource "proxmox_vm_qemu" "kube" {

  for_each = var.vm_configs
  
  # -- General settings

  name        = each.key
  desc        = "kubernetes cluster"
  agent       = 1  # <-- (Optional) Enable QEMU Guest Agent
  target_node = "pve"  # <-- Change to the name of your Proxmox node (if you have multiple nodes)
  tags        = "ubuntu_noble,kubernetes"
  vmid        = each.value.vmid
  #pool        = ""

  # -- Template settings

  clone_id   = 800  # <-- Change to the name of the template or VM you want to clone
  full_clone = true  # <-- (Optional) Set to "false" to create a linked clone

  # -- Boot Process

  onboot           = true
  startup          = ""  # <-- (Optional) Change startup and shutdown behavior
  automatic_reboot = false  # <-- Automatically reboot the VM after config change

  # -- Hardware Settings

  #qemu_os  = "l26"
  #bios     = "ovmf"
  #machine  = "q35"
  cores    = 2
  sockets  = 1
  #cpu_type = "host"
  memory   = 4096
  balloon  = 0  # <-- (Optional) Minimum memory of the balloon device, set to 0 to disable ballooning
  numa     = false

  # -- Network Settings

  network {
    id       = 0  # <-- ! required since 3.x.x
    bridge   = "vmbr0"
    model    = "virtio"
    firewall = false
    tag      = 80
    macaddr  = each.value.mac
  }

  # -- Disk Settings
  
  scsihw = "virtio-scsi-single"  # <-- (Optional) Change the SCSI controller type, since Proxmox 7.3, virtio-scsi-single is the default one         
  
  disks {  # <-- ! changed in 3.x.x
    ide {
      ide0 {
        cloudinit {
          storage = "local-zfs"
        }
      }
    }
    virtio {
      virtio0 {
        disk {
          storage   = "local-zfs"
          size      = "20G"  # <-- Change the desired disk size, ! since 3.x.x size change will trigger a disk resize
          iothread  = true  # <-- (Optional) Enable IOThread for better disk performance in virtio-scsi-single
          replicate = false  # <-- (Optional) Enable for disk replication
        }
      }
    }
  }

  # -- Cloud Init Settings

  ipconfig0  = each.value.ip  # <-- Change to your desired IP configuration
  nameserver = "192.168.80.1"  # <-- Change to your desired DNS server
  ciuser     = var.USER
  cipassword = var.PASSWORD
  ciupgrade  = false
  sshkeys    = var.PUBLIC_SSH_KEY  # <-- (Optional) Change to your public SSH key
}

General settings
- name : VM의 이름이다. 여기서는 vm_configs의 key값을 사용한다.
- desc : VM의 디스크립션이다.
- agent : proxmox option의 QEMU Guest agent를 true로 할지 여부이다.
- target_node : 만약 proxmox cluster를 구성해서 proxmox node가 여러 개이면 target_node로 원하는 proxmox node의 이름을 적어준다
- tags : proxmox의 tag를 지정해 준다. 여러 개 tag를 지정하려면 ,로 구분해 준다.
- vmid : 생성될 VM의 vmid이다. vmid는 유니크해야 한다. 여기서는 vm_configs의 value.vmid값을 사용한다.
- pool : 해당 VM이 생성되길 원하는 pool이 있다면 그 이름을 적어준다. pool 구성을 한 기억이 없다면 생략해도 된다.
Template settings
- clone_id : clone할 VM의 vmid이다. 이전 글을 참고해 만든 Packer로 생성한 VM의 vmid를 적어준다.
- full_clone : proxmox에는 clone옵션이 full clone과 linked clone이 있다. 이 부분은 주의할 필요가 있다. proxmox cluster를 운영 중이라면 분명 migration기능을 이용했을 것이다. migration기능을 이용하려면 linked clone을 해서는 안 된다. linked clone을 하게되면 clone된 VM의 디스크가 원본 VM의 디스크 위치에 종속되기 때문에 별개로 다른 node로 이동이 불가능하다. 또한 원본 VM의 수정 또한 불가하다. 다만 linked clone은 full clone에 비해서 clone 속도가 굉장히 빠르고 디스크 소모 또한 적다. 때문에 테스트 용으로는 false로 해서 linked clone을 사용하고 실질적으로 배포해야 할 땐 full clone을 이용하기를 개인적으로 권장한다.(이 부분은 개인적인 경험을 바탕으로 작성됐다. 옳지 않은 부분이 있을 수 있다.)
Boot Process
- onboot : 생성하고 부팅할 건지 여부이다.
- startup : 여길 참고하자.
- automatic_reboot : VM 설정에 변경이 생겼을 때 자동으로 reboot 해주는 기능. (e.g. cpu core 수 변경, 메모리 용량 변경 등)
Hardware Settings
- qemu_os : QEMU os type
- bios : bios type
- machine : machine type
- cores : CPU 코어 수
- sockets : CPU 소켓 수
- cpu_type : CPU type
- memory : 메모리 용량(MiB)
- balloon : 메모리 balloon 최소 용량. 0으로 하면 ballooning이 비활성화됨
- numa : numa 활성화
Network Settings
- id : 문서에는 불분명하게 적혀있으나 Network Device의 id(e.g. net0, net1, …)을 지정하는 것으로 보인다. 문서에는 순서에 따라 id가 정해진다고 돼 있으나 3.x.x버전 이후로 명시하도록 변경된 것 같다.
- bridge : proxmox의 network bridge의 이름을 적어주면 된다. network bridge를 생성한 적이 없다면 기본으로 vmbr0가 있을 것이다.
- model : 생성될 Network Device의 model을 입력한다. 문서를 참고하자.
- firewall : 방화벽 적용 여부이다. proxmox에서 방화벽을 설정하지 않고 pfsense나 opnsense같은 소프트웨어로 관리하고 있다면 false로 해도 문제없다.
- tag : VLAN tag의 번호이다. VLAN을 사용하고 있지 않다면 -1로 하거나 주석 처리해 준다.
- macaddr : Network Device의 MAC주소이다. 지정하지 않으면 랜덤으로 설정되기 때문에 static IP를 설정하기에 적절하지 않다. 사용하고 있는 DHCP서버에서 미리 static IP설정을 완료해 주고 설정한 MAC주소를 vm_configs의 mac에 적어준 다음 여기서 each.value.mac으로 불러와 준다.
Disk Settings
- scsihw : SCSI 컨트롤러 type을 지정해 준다.
- disks : 어떤 디스크 Bus/Device로 디스크를 생성해 줄 건지 정한다.(ide, sata, virtio, scsi)
  - ide0 : ide0으로 cloudinit을 위한 디스크를 생성해 준다.
    - storage : proxmox의 어떤 스토리지에 생성할지를 정한다. 생성할 스토리지는 proxmox storage content에서 Disk image를 포함해야 한다. 기본적으로는 local-zfs나 local-lvm이 있을 것이다. 처음에 zfs로 생성했다면 local-zfs를 ext4로 생성했다면 local-lvm을 사용하면 된다.
  - virtio0 : virtio0로 부팅할 디스크를 생성해 준다.
    - storage : 위의 ide0의 설명과 같다. 디스크가 생성되길 원하는 다른 storage가 있다면 해당 storage의 content를 확인하고, 해당 storage의 이름을 적어주면 된다.
    - size : 생성될 디스크의 크기를 지정한다. regex \d+[GMK]를 따라서 원하는 용량으로 생성해 준다.
    - iothread : IOThread 사용 여부이다. scsihw가 virtio-scsi-single이고, disks의 type이 virtio나 scsi일 때만 유효하다.
    - replicate : replication 사용 여부이다.
Cloud Init Settings
- ipconfig0 : 설정할 IP 주소이다. 위의 Network에서의 MAC주소와 같이 vm_configs의 each.value.ip로 불러와 준다.
- nameserver : 사용할 DNS 서버의 주소를 적으면 된다.
- ciuser : 생성할 USER의 이름이다. var.USER로 credentials.auto.tfvars에서 설정한 USER를 불러와 준다.
- cipassword : 생성할 PASSWORD이다. var.USER로 credentials.auto.tfvars에서 설정한 PASSWORD를 불러와 준다.
- ciupgrade : 부팅할 때 패키지 업그레이드를 할지 여부이다.(apt upgrade)
- sshkeys : 생성할 PUBLIC_SSH_KEY이다. var.USER로 credentials.auto.tfvars에서 설정한 PUBLIC_SSH_KEY를 불러와 준다.

5. plan and apply

Terraform에선 Packer와 다르게 plan과 apply가 있다. plan은 현재 구성돼있는 인프라 구성과 적용할 구성을 비교해서 차이를 출력해 준다. apply는 현재 구성을 적용해 준다. 기본적으로 apply를 하기 전에 plan으로 변경되는 부분을 확인하는 편이 바람직하다. 먼저 terraform plan을 해준다.

~$ terraform plan
proxmox_vm_qemu.kube["worker05"]: Refreshing state... [id=pve/qemu/835]
proxmox_vm_qemu.kube["worker06"]: Refreshing state... [id=pve/qemu/836]
proxmox_vm_qemu.kube["worker02"]: Refreshing state... [id=pve/qemu/832]
proxmox_vm_qemu.kube["worker01"]: Refreshing state... [id=pve/qemu/831]
proxmox_vm_qemu.kube["control02"]: Refreshing state... [id=pve/qemu/812]
proxmox_vm_qemu.kube["worker03"]: Refreshing state... [id=pve/qemu/833]
proxmox_vm_qemu.kube["worker04"]: Refreshing state... [id=pve/qemu/834]
proxmox_vm_qemu.kube["control01"]: Refreshing state... [id=pve/qemu/811]
proxmox_vm_qemu.kube["control03"]: Refreshing state... [id=pve/qemu/813]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

한번 적용하고 다시 plan을 했다면 위와 같이 표시될 것이다. 처음이라면 변경되는 부분이 표시된다.

이제 apply를 해보자.

~$ terraform apply -auto-approve
proxmox_vm_qemu.kube["worker03"]: Refreshing state... [id=pve/qemu/833]
proxmox_vm_qemu.kube["worker01"]: Refreshing state... [id=pve/qemu/831]
proxmox_vm_qemu.kube["worker04"]: Refreshing state... [id=pve/qemu/834]
proxmox_vm_qemu.kube["control01"]: Refreshing state... [id=pve/qemu/811]
proxmox_vm_qemu.kube["control03"]: Refreshing state... [id=pve/qemu/813]
proxmox_vm_qemu.kube["worker06"]: Refreshing state... [id=pve/qemu/836]
proxmox_vm_qemu.kube["control02"]: Refreshing state... [id=pve/qemu/812]
proxmox_vm_qemu.kube["worker05"]: Refreshing state... [id=pve/qemu/835]
proxmox_vm_qemu.kube["worker02"]: Refreshing state... [id=pve/qemu/832]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # proxmox_vm_qemu.kube["control01"] will be created
  + resource "proxmox_vm_qemu" "kube" {
      + additional_wait        = 5
      + agent                  = 1
      + automatic_reboot       = false
      + balloon                = 0
      + bios                   = "seabios"
      + boot                   = (known after apply)
      + bootdisk               = (known after apply)
      + cipassword             = (sensitive value)
      + ciupgrade              = false
      + ciuser                 = "kube"
      + clone_id               = 800
      + clone_wait             = 10
      + cores                  = 2
      + cpu_type               = "host"
      + default_ipv4_address   = (known after apply)
      + default_ipv6_address   = (known after apply)
      + define_connection_info = true
      + desc                   = "kubernetes cluster"
      + force_create           = false
      + full_clone             = false
      + hotplug                = "network,disk,usb"
      + id                     = (known after apply)
      + ipconfig0              = "ip=192.168.80.11/24,gw=192.168.80.1"
...
proxmox_vm_qemu.kube["worker01"]: Still creating... [2m20s elapsed]
proxmox_vm_qemu.kube["worker01"]: Creation complete after 2m21s [id=pve/qemu/831]
proxmox_vm_qemu.kube["worker05"]: Still creating... [2m30s elapsed]
proxmox_vm_qemu.kube["worker03"]: Still creating... [2m30s elapsed]
proxmox_vm_qemu.kube["worker05"]: Still creating... [2m40s elapsed]
proxmox_vm_qemu.kube["worker03"]: Still creating... [2m40s elapsed]
proxmox_vm_qemu.kube["worker03"]: Creation complete after 2m41s [id=pve/qemu/833]
proxmox_vm_qemu.kube["worker05"]: Still creating... [2m50s elapsed]
proxmox_vm_qemu.kube["worker05"]: Still creating... [3m0s elapsed]
proxmox_vm_qemu.kube["worker05"]: Creation complete after 3m0s [id=pve/qemu/835]

Apply complete! Resources: 9 added, 0 changed, 0 destroyed.

-auto-approve를 하면 자동으로 과정이 진행돼 위와 같이 끝날 것이다. 그냥 terraform apply를 하면 변경되는 부분을 보여주고, approve 할건지를 알려준다. approve 하게 되면 과정이 진행돼 똑같이 VM이 생성되면 종료된다. 나의 경우 linked clone으로 하면 3분 정도, full clone으로 하면 8분 30초 정도가 소요됐다. 사용하는 디스크의 속도에 따라 다를 수 있다.

결론

이전 글에서 Packer를 이용해 proxmox에 VM Template를 생성하는 방법에 대해서 다뤘다. 그리고 이번 글에서 Terraform으로 생성된 VM Template를 이용해 여러 개의 VM을 일관적으로 손쉽게 생성하고 관리하는 방법에 대해서 소개했다. 이 두 가지 IaC 도구를 사용해 proxmox에서 VM을 쉽게 생성하고 관리할 수 있고, 일관적이고 빠른 배포를 할 수 있게 됐다. proxmox를 사용하는 많은 사람들에게 도움이 됐으면 한다.

다음 글에서는 생성된 VM에 ansible을 이용해 kubernetes cluster를 구성하고, kubernetes 대시보드를 생성하고, worker node를 추가, 제거할 수 있는 방법을 소개하려고 한다.

잘못된 설명이나 추가로 설명했으면 좋겠는 부분, 오타, 맞춤법에 대한 지적은 언제나 환영합니다.

이 글을 홈서버 사용자를 위한 것입니다. 실제 환경에서 사용할 때는 credential을 Vault나 환경 변수 등으로 좀 더 엄격하게 관리하시기를 바랍니다.
이 글을 포함해 인터넷에 존재하는 코드, 스크립트를 복사해 사용할 때는 코드, 스크립트를 충분히 읽고, 분석하여 문제가 없는지 확인하시기를 바랍니다. 최소한 ChatGPT 같은 AI에 해당 코드, 스크립트가 정말 안전하고 사용해도 되는지 확인받으시길 권장합니다.

참고

ChristianLempa github/boilerplates

https://github.com/ChristianLempa/boilerplates/tree/main/terraform/proxmox

HashiCorp Terraform

https://registry.terraform.io/providers/Terraform-for-Proxmox/proxmox/latest/docs

Packer로 proxmox에 VM 이미지 생성하기

Tue, 18 Feb 2025 00:00:00 GMT

시작

proxmox를 벌써 3년 정도 사용하면서 많은 vm을 생성하고 삭제했다. 하지만 매번 vm을 생성할 때마다 같은 설정들을 반복했다는 걸 느꼈다. ssh key를 넣어주고, apt 저장소를 kakao mirror로 바꾸고, 필요할 경우 고정 ip를 할당하는 등의 것들이다. 하지만, 이 세팅들을 매번 하는 것도 질렸고, 무엇보다 이번에 k8s 클러스터를 구축하면서 동일한 설정과 동일한 패키지를 가지는 여러 vm을 생성해야 했다. 1n 개 이상의 vm을 이런 식으로, 수동으로 설정하는 것은 바보 같은 짓이라는 생각이 들었다.

물론 proxmox에도 Template라는 기능이 존재한다. Packer도 결과적으로 Template를 만드는 것이지만, proxmox만으로 이것을 하려면 직접 VM을 설치하고 세팅하여 이후에 이것을 Template으로 전환해야 하고, 만약 실수한다면 이 고정을 다시 해야 한다. 그 때문에 IaC도구의 힘을 빌리기로 했다. HashiCorp의 Packer와 Terraform, 그리고 Ansible을 사용하여 이 과정을 자동화하고자 한다. 이 글을 그 과정 중 첫 번째인 Packer에 대해서 간단하게 설명하고, proxmox에서 Packer로 기본적인 설정이 완료된 ubuntu 24.04, 22.04이미지를 만들어보고자 한다.

1. Packer란?

Packer는 이미지 빌드를 자동화해 주는 오픈소스 소프트웨어이다. 서버나 가상머신, 클라우드 인스턴스와 같은 환경에서 일관되고, 반복적인 배포를 할 때 유용하다. Template를 이용해서 항상 같은 이미지를 빌드하기 때문에 개발, 테스트, 프로덕션 환경을 일관적으로 유지할 수 있다. 또한 반복적인 작업을 줄일 수 있다. 만약 각 vm에 k8s 관련 패키지를 Ansible로 설치한다고 생각하면, 각 VM에 SSH로 접속해서 설치 스크립트를 실행할 것이고, 더 높은 네트워크 사용과 미리 설치해 둔 패키지를 설치하는 것보다는 당연히 클러스터의 배포가 느려질 것이다.

이처럼 Packer는 DevOps 파이프라인의 가장 앞에서 가장 필수적이고 공통적인 패키지를 포함한 이미지를 미리 만들어둠으로써 배포 시간을 줄이고, 일관성을 유지할 수 있게 해준다. 이는 홈서버를 운영하는 입장에서도 매우 편리하다. 앞서 말한 ssh key, kakao mirror etc…들을 매번 세팅하는 건 매우 귀찮은 일이다. 특히 지인들과 서버를 공유하고 있다면 더욱 귀찮은 일이다. 이제 이 귀찮음을 해결해 보자.

2. install Packer

기본적으로 Packer의 설정에 관한 문서는 여기에 아주 잘 정리돼 있다. ubuntu server noble에 설치할 거기 때문에 이 튜토리얼을 따라 하자.

wget -O - https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install packer

설치가 완료되고 packer --version을 입력했을 때

~$ packer --version
Packer v1.12.0

이런 식으로 나온다면 설치가 완료된 것이다.

3. directory configuration

Packer를 이용해서 proxmox를 빌드하기 위해서는 packer Template에 사용될 폴더와 proxmox에 접속하기 위한 credentials를 저장할 파일이 필요하다. 그리고 이미지를 생성할 템플릿, ssh user의 credentials 파일, 설치 시 전달한 user data가 필요하다. 때문에 아래와 같이 폴더를 구성해서 jammy와 noble을 위한 Template를 작성할 것이다.

packer/
├── credentials.pkr.hcl
├── ubuntu-server-jammy
│   ├── files
│   │   └── 99-pve.cfg
│   ├── http
│   │   ├── meta-data
│   │   └── user-data
│   ├── run-packer.sh
│   ├── ssh-user-credentials.pkr.hcl
│   └── ubuntu-server-jammy.pkr.hcl
└── ubuntu-server-noble
    ├── files
    │   └── 99-pve.cfg
    ├── http
    │   ├── meta-data
    │   └── user-data
    ├── run-packer.sh
    ├── ssh-user-credentials.pkr.hcl
    └── ubuntu-server-noble.pkr.hcl

run-packer.sh는 validate와 build를 편하게 하기 위해서 작성했다.

4. file configuration

ubuntu server noble(24.04.x)를 기준으로 진행하겠다.

4.1. credentials.pkr.hcl

Packer가 proxmox에서 VM을 생성하고, 설정값을 입력하고, 이것을 template로 바꾸기 위해서는 어떤 방법으로든 proxmox의 쉘에 접속할 수밖에 없다. 이를 위해서 proxmox의 api_url, username과 password 혹은 token이 필요하다.(passward나 token 중 하나만 있어도 된다.) 이는 모든 template 파일에 포함돼야 하는데, 편의를 위해서 root 권한을 그대로 사용한다. 그 때문에 credentials 파일에서 username, password, token, api_url을 변수로 저장하고, 일관적으로 관리하려고 한다.(Packer를 위한 proxmox의 권한에 관련된 문서는 찾지 못했지만, 권한과 관련된 보안 이슈를 해결할 만한 솔루션을 발견했다. 해당 이슈에 따라 pool, group, user를 생성하고 적절히 권한을 주고 Packer가 proxmox Template를 완전히 생성한 뒤 root 권한으로 원하는 pool로 생성된 Template를 이동시키면 될 듯하다.) 아래와같이 credentials 파일을 작성해 준다.

# proxmox API credentials
proxmox_api_url             = "https://YOUR_PROXMOX_IP:8006/api2/json"
proxmox_api_token_id        = "YOUR_USERNAME@REALM_NAME!tokenid"
#token을 사용할거면 !tokenid를 뒤에 붙여줘야함 e.g. root@pam!packer
proxmox_api_password        = "YOUR_PASSWORD"   #token을 사용할거면 비워도도 됨
proxmox_api_token_secret    = "TOKEN_SECRET"    #password를 사용할거면 비워도도 됨

되도록 token을 사용하도록 하자.

4.2. ssh-user-credentials.pkr.hcl

Packer가 VM을 생성하고, 이후에 VM에 접속해서 provisioner로 필요한 패키지를 설치하기 위해서는 해당 VM에 ssh로 접속해야 한다. 이를 위해서 user-data에 입력한 user와 동일한 데이터가 필요하다. 이 값도 예제 아래에 작성한 이유로 Template에서 유일하게 자주 변경해야 할 수도 있기 때문에 변수로 분리했다. 아래와같이 ssh-user-credentials 파일을 작성해 준다.

# ssh credentials
ssh_username                = "YOUR_USERNAME"   #e.g. packer
ssh_password                = "YOUR_PASSWORD"   #ssh key를 사용한다면 비워도도 됨
ssh_private_key_file_path   = "YOUR_PRIVATE_SSH_KEY_PATH"   #Packer가 설치돼있는 host의 path임 e.g. ~/.ssh/packer

이때 빌드를 위한 packer user와 ssh key를 입력해 두고, 나중에 Terraform 등을 이용해서 지워도 된다. 하지만 많은 VM을 생성하지 않을 때는 수동으로 clone 하므로, 이 user가 거슬릴 수 있다. 예제에서는 packer라는 user로 진행했지만, 이를 자주 사용하는 user와 ssh key로 변경해도 된다.

문서대로라면 ssh_password를 이용해서도 접속할 수 있어야 하지만 나의 경우 오직 ssh key로만 접속할 수 있었다.

4.3. user-data

이 user-data에 관해서 설명하려면 먼저 cloud-init에 대해서 알아야 한다. cloud-init은 VM 혹은 클라우드 인스턴스의 초부팅 시 사용자 지정 스크립트/환경 설정을 자동 적용해 주는 툴이다. proxmox에도 cloud-init을 설정해서 부팅 시 적용할 수 있는 옵션이 있다. 하지만 Packer는 이 방식을 사용하지 않고, 직접 임시로 HTTP 서버를 구동한다. 그리고 아래에서 작성할 template 코드에서 부팅시 옵션을 입력하는데, 이것이 Packer가 임시로 구동한 HTTP 서버에 접속해 user-data와 meta-data를 가져온다. 여기서는 http 폴더 아래에 있는 두 파일이 된다. 이 과정을 거치면서 VM은 설치 시에 user-data에 기술된 user를 생성하게 되고, 이후에 부팅했을 때 ssh로 접속하는 것이다. 위에서 작성한 ssh-user-credentials로 ssh 접속을 시도하기 때문에 대응하는 값으로 user-data파일을 작성해 준다.

#cloud-config
autoinstall:
  version: 1
  locale: en_US
  keyboard:
    layout: us
  ssh:
    install-server: true
    allow-pw: true
    disable_root: true
    ssh_quiet_keygen: true
    allow_public_ssh_keys: true
  packages:
    - qemu-guest-agent
    - sudo
  storage:
    layout:
      name: direct
    swap:
      size: 0
  user-data:
    package_upgrade: false
    timezone: Asia/Seoul
    users:
      - name: YOUR_USERNAME
        groups: [adm, sudo]
        lock-passwd: false
        sudo: ALL=(ALL) NOPASSWD:ALL
        shell: /bin/bash
        #passwd: YOUR_PASSWORD
        # - or -
        ssh_authorized_keys:
          - YOUR_SSH_PUBLIC_KEY

위에서 작성한 ssh-user-credentials의 YOUR_USERNAME과 같은 username을 적어주고, YOUR_PRIVATE_SSH_KEY_PATH에 대응하는 public key를 적어주면 된다. 부팅하면서 최신 패키지를 적용하고 싶다면 package_upgrade를 true로 바꿔주면 된다.

4.4. ubuntu-server-noble.pkr.hcl

가장 핵심이 되는 template 파일이다. proxmox에서 VM을 실행하고 빌드하고 템플릿으로 바꿔주는 파일이다. 파일에서 사용한 값에 대한 상세나, 추가 값들은 여기에서 확인하면된다. 이 파일은 상당히 길기 때문에 나눠서 진행하겠다.

4.4.1. Variable 정의

앞서 작성한 credentials, ssh-user-credentials 두 파일에서 작성한 variable들에 대한 정의를 해줘야 한다. 각 type은 여기에 적혀있는 type에 따라서 작성하면 된다. password는 사용하지 않는다면 이 부분과 아래에서 이 변수를 사용하는 부분 모두를 지워줘도 된다.

# Variable Definitions
variable "proxmox_api_url" {
    type = string
}
variable "proxmox_api_token_id" {
    type = string
}
variable "proxmox_api_password" {
    type = string
    sensitive = true
}
variable "proxmox_api_token_secret" {
    type = string
    sensitive = true
}
variable "ssh_username" {
    type = string
}
variable "ssh_password" {
    type = string
    sensitive = true
}
variable "ssh_private_key_file_path" {
    type = string
}

4.4.2. Resource 정의

여기서 사용되는 값들에 대한 상세는 다시 말하지만 여기를 참고하자.

source의 proxmox-iso는 type이기 때문에 그대로 작성해야 한다.
Proxmox Connection Settings는 앞에 서술했듯이 proxmox에 접속해서 VM을 생성하고 설치 과정을 진행하기 위해서 선언해야 하는 값이다.
- insecure_skip_tls_verify의 경우 valid한 TLS인증서가 달려있는 proxmox_url를 사용한다면 생략해도 된다.
ssh Settings는 생성된 VM에 접속해서 빌드 과정을 진행하기 위해서 ssh 접속을 위해서 선언해야 하는 값이다.
VM General Settings는 VM을 생성할 때 사용되는 기본적인 값이다.
- node의 경우 클러스터 구성이 아니라면 지정해 줄 필요는 없다.
- bios값의 경우 default는 seabios이다. 그런데 이 값을 ovmf로 할 경우 efi_config로 efi disk를 지정해 줘야 하는데, 이 경우 proxmox에서 live migration을 진행할 수 없게 되니 주의해야한다.(이 스레드를 보면 해당 이슈가 아직도 존재하는것으로 보이고, 실제로 나도 실패했다.)
VM OS Settings는 proxmox에서 OS가 저장된 저장소의 위치를 정의한다. 추가적인 디스크를 추가하지 않았다면 아마도 local일 것이다. 이 경우라면 YOUR_ISO_STORAGE_POOL를 local로 하면 된다. 그리고 ubuntu-24.04.1-live-server-amd64.iso를 해당 저장소에 받아둬야 한다.
VM Hard Disk Settings는 VM의 디스크 설정이다.
VM Network Settings는 네트워크 설정이다. vlan_tag의 경우 해당 VLAN과 Packer host 사이에 방화벽이 있어서 ssh 접속이 불가능하진 않은지 확인해야한다.
VM Cloud-Init Settings는 다음에 Terraform이나 직접 cloud-init 값을 입력하기 위해서 필요한 proxmox용 cloud-init disk를 생성하는 과정이다.
PACKER Boot Commands는 앞서 설명했듯이 부팅 시에 Packer host의 임시 http 서버에 접속해서 cloud-init 정보를 가져오기 위한 커맨드이다.
PACKER Autoinstall Settings는 방금 설명한 임시 http 서버에 대한 설정이다. 여기서 만약 http_port_min, http_port_max가 똑같이 설정된 여러 Packer template를 동시에 build 한다면 문제가 발생할 수 있다.

# Resource Definiation for the VM Template
source "proxmox-iso" "ubuntu-server-noble" {

    # Proxmox Connection Settings
    proxmox_url = "${var.proxmox_api_url}"
    username    = "${var.proxmox_api_token_id}"
    password    = "${var.proxmox_api_password}"
    token       = "${var.proxmox_api_token_secret}"
    insecure_skip_tls_verify = true # (Optional) Skip TLS Verification

    # ssh Settings
    ssh_username                = "${var.ssh_username}"
    # (Option 1) Add your Password here
    #ssh_password                = "${var.ssh_password}"
    # - or -
    # (Option 2) Add your Private SSH KEY file here
    ssh_private_key_file        = "${var.ssh_private_key_file_path}"
    ssh_clear_authorized_keys   = true
    ssh_timeout                 = "30m"
    ssh_handshake_attempts      = 50
    ssh_pty                     = true

    # VM General Settings
    template_description = "Ubuntu Server Noble Image"
    node        = "pve"
    vm_id       = "9000"
    vm_name     = "ubuntu-server-noble"
    #pool        = ""
    tags        = "ubuntu_noble"
    os          = "l26"
    machine     = "q35"
    qemu_agent  = true
    cores       = "2"
    memory      = "4096"
    #bios        = "ovmf"
    #efi_config {
    #    efi_storage_pool    = "YOUR_STORAGE_POOL" #e.g. local-lvm
    #    efi_type            = "4m"
    #    pre_enrolled_keys   = true
    #}

    # VM OS Settings
    boot_iso {
      type              = "scsi"
      iso_file          = "YOUR_ISO_STORAGE_POOL:iso/ubuntu-24.04.1-live-server-amd64.iso"  #iso file name
      iso_storage_pool  = "YOUR_ISO_STORAGE_POOL" #local
      unmount           = true
    }

    # VM Hard Disk Settings
    scsi_controller     = "virtio-scsi-pci"
    disks {
        disk_size       = "20G"
        format          = "raw"
        storage_pool    = "YOUR_STORAG_POOL"  #e.g. local-lvm
        type            = "virtio"
    }

    # VM Network Settings
    network_adapters {
        model       = "virtio"
        bridge      = "vmbr1"
        #vlan_tag    = "100"
        firewall    = "false"
    }

    # VM Cloud-Init Settings
    cloud_init              = true
    cloud_init_storage_pool = "YOUR_STORAG_POOL"  #e.g. local-lvm

    # PACKER Boot Commands
    boot_command = [
        "<esc><wait>",
        "e<wait>",
        "<down><down><down><end>",
        "<bs><bs><bs><bs><wait>",
        "autoinstall ds=nocloud-net\\;s=http://{{ .HTTPIP }}:{{ .HTTPPort }}/ ---<wait>",
        "<f10><wait>"
    ]
    boot                    = "c"
    boot_wait               = "10s"
    communicator            = "ssh"

    # PACKER Autoinstall Settings
    http_directory          = "http"
    # (Optional) Bind IP Address and Port
    http_bind_address       = "YOUR_PACKER_HOST_IP" #packer host IP
    http_port_min           = 8802
    http_port_max           = 8902
}

4.4.3. Build 정의

VM생성 이후 ssh로 접속해서 실행할 커맨드이다. 여기서 sources는 위의 template에서 source와 대응하게 작성해야 한다. 여기서는 이후에 proxmox의 cloud-init 저장소를 활용하기 위한 준비와, 나의 경우 apt 저장소를 kakao로 변경하는 작업을 추가했다.

# Build Definition to create the VM Template
build {

    name    = "ubuntu-server-noble"
    sources = ["source.proxmox-iso.ubuntu-server-noble"]

    # Provisioning the VM Template for Cloud-Init Integration in Proxmox #1
    provisioner "shell" {
        inline = [
            "while [ ! -f /var/lib/cloud/instance/boot-finished ]; do echo 'Waiting for cloud-init...'; sleep 1; done",
            "sudo rm /etc/ssh/ssh_host_*",
            "sudo truncate -s 0 /etc/machine-id",
            "sudo apt -y autoremove --purge",
            "sudo apt -y clean",
            "sudo apt -y autoclean",
            "sudo cloud-init clean",
            "sudo rm -f /etc/cloud/cloud.cfg.d/subiquity-disable-cloudinit-networking.cfg",
            "sudo rm -f /etc/netplan/00-installer-config.yaml",
            "sudo sync"
        ]
    }

    # Provisioning the VM Template for Cloud-Init Integration in Proxmox #2
    provisioner "file" {
        source      = "files/99-pve.cfg"
        destination = "/tmp/99-pve.cfg"
    }

    # Provisioning the VM Template for Cloud-Init Integration in Proxmox #3
    provisioner "shell" {
        inline = [ "sudo cp /tmp/99-pve.cfg /etc/cloud/cloud.cfg.d/99-pve.cfg" ]
    }

    # Change apt repo to kakao mirror
    provisioner "shell" {
        inline = [
            "sudo sed -i 's|http://kr.archive.ubuntu.com/ubuntu/|http://mirror.kakao.com/ubuntu/|g' /etc/apt/sources.list.d/ubuntu.sources"
        ]
    }

    # Add additional provisioning scripts here
    # ...
}

ubuntu server noble과 jammy 모두 지금까지의 값들은 당연한 이름 같은 것을 제외하면 모두 동일하다. 하지만 ubuntu 24.04버전으로 오면서 apt 저장소 리스트를 저장하는 위치가 약간 바뀌었다. /etc/apt/sources.list -> /etc/apt/sources.list.d/ubuntu.sources 때문에 jammy의 경우 아래와같이 apt 저장소를 바꾸는 코드만 수정해 주면 된다.

    # for ubuntu server jammy
    # Change apt repo to kakao mirror
    provisioner "shell" {
        inline = [
            "sudo sed -i 's|http://kr.archive.ubuntu.com/ubuntu/|http://mirror.kakao.com/ubuntu/|g' /etc/apt/sources.list"
        ]
    }

4.5. 나머지

meta-data의 경우 필요하다면 사용하면 된다. 여기서는 아무것도 작성하지 않아도 된다. 99-pve.cfg에는 datasource_list: [ConfigDrive, NoCloud] 한 줄만 있으면 되는데, 이것은 부팅 시에 cloud-init이 ConfigDrive를 먼저 진행할지, NoCloud로 먼저 진행할지를 정의하는 부분이다. proxmox의 경우 NoCloud방식을 사용한다. ConfigDrive를 먼저 확인하고 없다면 proxmox의 설정을 따르게 된다.

4.6. run-packer.sh

#!/bin/bash

ACTION=$1
TEMPLATE_FILE=$2

if [ -z "$TEMPLATE_FILE" ]; then
    echo "Usage: $0 {validate|build|-v|-b} <template-file>"
    exit 1
fi

if [ "$ACTION" == "validate" ] || [ "$ACTION" == "-v" ]; then
    packer validate -var-file ../credentials.pkr.hcl -var-file ./ssh-user-credentials.pkr.hcl "$TEMPLATE_FILE"
elif [ "$ACTION" == "build" ] || [ "$ACTION" == "-b" ]; then
    packer build -var-file ../credentials.pkr.hcl -var-file ./ssh-user-credentials.pkr.hcl "$TEMPLATE_FILE"
else
    echo "Usage: $0 {validate|build|-v|-b} <template-file>"
    exit 1
fi

빌드의 편의를 위해 작성한 파일이다. 앞서 작성된 Packer 파일들을 빌드하기 위해서는

packer build -var-file ../credentials.pkr.hcl -var-file ./ssh-user-credentials.pkr.hcl ubuntu-server-noble.pkr.hcl

를 입력해야 한다고 했다. 이 스크립트는 반복되는 variable 파일을 이미 넣어둬서

./run-packer.sh -b ubuntu-server-noble.pkr.hcl

로 진행할 수 있다. validate의 경우

./run-packer.sh -v ubuntu-server-noble.pkr.hcl

5. validate and build

위의 run-packer 스크립트를 이용해서 빌드해도 되지만, 일단은 정석적인 방법으로 빌드하려고 한다. 일단 Packer의 proxmox plugin을 설치해 준다.

~$ packer plugins install github.com/hashicorp/proxmox
Installed plugin github.com/hashicorp/proxmox v1.2.2 in "/home/user/.config/packer/plugins/github.com/hashicorp/proxmox/packer-plugin-proxmox_v1.2.2_x5.0_linux_amd64"

위와 같이 뜬다면 성공적으로 설치된 것이다.

packer build를 하기 이전에 validate 과정을 거쳐서 template 코드가 정상적으로 작성됐는지 확인해야 한다.

~$ packer validate -var-file ../credentials.pkr.hcl -var-file ./ssh-user-credentials.pkr.hcl ubuntu-server-noble.pkr.hcl
The configuration is valid.

위와 같이 뜬다면 성공적으로 validate 된 것이다.

validate가 성공했다면 비슷한 명령으로 build를 해준다.

~$ packer build -var-file ../credentials.pkr.hcl -var-file ./ssh-user-credentials.pkr.hcl ubuntu-server-noble.pkr.hcl

빌드를 하면 proxmox웹에서 지정한 vmid로 VM이 생성되고 부팅되는 걸 확인할 수 있다. 이때 아래와 같은 화면에서 절대 다른 조작을 해서는 안 된다. 이 화면에서 Packer가 proxmox에 키보드 입력을 통해 Packer가 띄운 http서버에서 cloud-init 정보를 가져오기 위한 커맨드를 입력하는데, 오조작으로 바로 설치 환경으로 들어가게 되면 Packer가 이후 프로세스를 진행할 수 없게 된다. 성공적으로 빌드가 완료되면 아래와 같이 proxmox Template가 생성된 것을 확인할 수 있다.

6. clone

이제 proxmox에 생성된 이미지를 clone 해보자. clone 하기에 앞서 proxmox에서 cloud-init 설정을 해줘야 한다. 위와 같이 User, Password, SSH public key를 넣어주고, IP Config는 기본으로 dhcp로 설정해 주면 된다. 이후에 다룰 Terraform으로 VM 여러 개 배포하기에서 고정 IP로 생성하는 방법에 대해서 자세히 다루겠다. 값을 다 넣었다면 VM을 우클릭하거나 우측 상단의 more에서 clone을 찾아서 clone을 진행한다. 위와 같은 창이 뜰 것이다. 여기서 VM ID, Name 등을 넣어주고, Mode를 지정해 줘야 한다. 여기서 Linked Clone과 Full Clone이 있는데, Linked Clone은 원본 이미지에 의존해서 VM을 생성하기 때문에 디스크 공간을 절약하고 더 빠른 Clone을 할 수 있지만, 원본 이미지의 안정성이 보장돼야 한다. 또한 Linked Clone을 하면 link 돼 있는 이미지(예제에선 VM ID 9000)와 같은 디스크에 clone 된 VM이 존재해야 한다. replication을 적용한 상태의 서로다른 proxmox 노드로의 migration은 시도해 보진 않았지만, replication 없이 migration을 진행했을 때는 실패했으니 다른 노드로 migration 할 계획이 있다면 Full Clone을 권장한다. 보통의 경우라면 테스트할 때는 linked로 장기간 사용할 계획이라면 full을 추천한다.

결론

앞으로는 생성된 이미지를 가지고 편하게 초기 세팅이 완료된 VM을 clone으로 생성해서 바로 사용할 수 있을 것이다. Packer를 이용해서 이미지를 만들고 이 이미지로 VM을 생성하는 방식은 그냥 OS 이미지로 부팅하고 생성하는 것보다 훨씬 편하고 일관적이다. proxmox를 사용을 굉장히 편리하게 해줘서 이 경험을 최대한 자세히 공유하고자 노력했고, 많은 사람들에게 도움이 됐으면 한다.

다음 글에서 Terraform으로 같은 이미지를 사용해서 k8s cluster를 위한 VM 여러 개를 배포하는 과정을 설명하려고 한다.

잘못된 설명이나 추가로 설명했으면 좋겠는 부분, 오타, 맞춤법에 대한 지적은 언제나 환영합니다.

이 글을 홈서버 사용자를 위한 것입니다. 실제 환경에서 사용할 때는 credential을 Vault나 환경 변수 등으로 좀 더 엄격하게 관리하고, dedicate 한 proxmox user, pool, token 사용을 고려하기를 바랍니다. Packer가 설치된 host의 보안에 충분한 주의를 기울이기를 바랍니다.
이 글을 포함해 인터넷에 존재하는 코드, 스크립트를 복사해 사용할 때는 코드, 스크립트를 충분히 읽고, 분석하여 문제가 없는지 확인하시기를 바랍니다. 최소한 ChatGPT 같은 AI에 해당 코드, 스크립트가 정말 안전하고 사용해도 되는지 확인받으시길 권장합니다.

참고

ChristianLempa github/boilerplates

https://github.com/ChristianLempa/boilerplates/tree/main/packer/proxmox

HashiCorp Packer developer docs

https://developer.hashicorp.com/packer/integrations/hashicorp/proxmox

Proxmox Admin Guide 살펴보기

Mon, 29 Jul 2024 00:00:00 GMT

version 8.2.2, Thu Apr 25 09:24:16 CEST 2024

목적

지난 2년 동안 Proxmox를 홈서버에서 정말 잘 사용해 왔다. 하지만 한 번도 제대로 공식 가이드를 읽어본 적이 없고, 전부 영어로 돼 있어 번역도 함께 진행해 보고자 한다.

1. 소개

Proxmox VE는 가상 머신과 컨테이너를 실행하기 위한 플랫폼입니다. Debian Linux를 기반으로 하며, 완전한 오픈 소스입니다. 최대의 유연성을 위해 두 가지 가상화 기술을 구현했습니다 - 커널 기반 가상 머신(KVM)과 컨테이너 기반 가상화(LXC)입니다.

주요 설계 목표 중 하나는 관리를 최대한 쉽게 만드는 것이었습니다. Proxmox VE는 단일 노드에서 사용할 수 있으며, 여러 노드로 클러스터를 구성할 수도 있습니다. 모든 관리 작업은 웹 기반 관리 인터페이스를 통해 수행할 수 있으며, 초보자도 몇 분 안에 Proxmox VE를 설치하고 설정할 수 있습니다.

1.1. 중앙 관리

많은 사람들이 단일 노드로 시작하지만, Proxmox VE는 대규모 클러스터 노드 집합으로 확장할 수 있습니다. 클러스터 스택은 완전히 통합되어 있으며 기본 설치와 함께 제공됩니다.

독특한 멀티 마스터 설계

통합된 웹 기반 관리 인터페이스는 모든 KVM 게스트와 Linux 컨테이너는 물론 전체 클러스터에 대한 명확한 개요를 제공합니다. GUI를 통해 VM과 컨테이너, 스토리지 또는 클러스터를 쉽게 관리할 수 있습니다. 별도의 복잡하고 비용이 많이 드는 관리 서버를 설치할 필요가 없습니다.
Proxmox 클러스터 파일 시스템 (pmxcfs)

Proxmox VE는 구성 파일을 저장하기 위한 데이터베이스 기반 파일 시스템인 Proxmox 클러스터 파일 시스템 (pmxcfs)을 사용합니다. 이를 통해 수천 대의 가상 머신 구성을 저장할 수 있습니다. corosync를 사용하면 이러한 파일은 모든 클러스터 노드에서 실시간으로 복제됩니다. 파일 시스템은 디스크의 영구 데이터베이스 내부에 모든 데이터를 저장하지만, 데이터 복사본은 최대 30MB의 저장 용량을 제공하는 RAM에 저장됩니다. 이는 수천 개의 VM을 저장하기에 충분합니다.

Proxmox VE는 이 독특한 클러스터 파일 시스템을 사용하는 유일한 가상화 플렛폼입니다.
웹 기반 관리 인터페이스

Proxmox VE는 사용하기 쉽습니다. 관리 작업은 포함된 웹 기반 관리 인터페이스를 통해 수행할 수 있습니다. 별도의 관리 도구나 대용향 데이터베이스가 있는 추가 관리 노드를 설치할 필요가 없습니다. 멀티 마스터 도구를 사용하면 클러스터의 모든 노드에서 전체 클러스터를 관리할 수 있습니다. JavaScript 프레임워크(ExtJS)를 기반으로 하는 중앙 웹 기반 관리를 통해 모든 기능을 GUI에서 제어하고 각 노드의 기록 및 시스템 로그를 관리할 수 있습니다. 여기에는 백업 또는 복원 작업 실행, 실시간 마이그레이션 또는 고가용성(HA) 트리거 활동이 포함됩니다.
커맨드라인

Unix 셸이나 Windows Powershell에 익숙한 고급 사용자를 위해 Proxmox VE는 가상 환경의 모든 구성 요소를 관리할 수 있는 커맨드라인 인터페이스를 제공합니다. 이 커맨드라인 인터페이스에는 지능형 탭 완성 기능과 UNIX 메뉴얼 페이지 형식의 전체 문서를 제공합니다.
REST API

Proxmox VE는 RESTful API를 사용합니다. 기본 데이터 형식으로 JSON을 선택했으며, 전체 API는 JSON Schema를 사용하여 정의됩니다. 이를 통해 맞춤형 호스팅 환경과 같은 타사 관리 도구를 빠르고 쉽게 통합할 수 있습니다.
역할 기반 관리

역할 기반 사용자 및 관리를 사용하여 모든 객체(VM, 스토리지, 노드 등)에 대한 세부적인 접근 권한을 정의할 수 있습니다. 이를 통해 권한을 정의하고 객체에 대한 접근을 제어할 수 있습니다. 이 개념은 접근 제어 목록(ACL)으로도 알려져 있습니다. 각 권한은 특정 경로에 대한 사용자(또는 그룹)와 역할(권한 집합)을 지정합니다.
인증 영역

Proxmox VE는 Microsoft Active Directory, LDAP, Linux PAM 표준 인증 또는 내장된 Proxmox VE 인증 서버와 같은 다양한 인증 소스를 지원합니다.

1.2. 유연한 스토리지 옵션

Proxmox VE의 스토리지 모델은 매우 유연합니다. 가상 머신 이미지는 하나 이상의 로컬 스토리지나 NFS와 같은 공유 스토리지 또는 SAN에 저장할 수 있습니다. 제한이 없으며, 원하는 만큼 많은 스토리지 정의를 구성할 수 있습니다. Debian Linux에서 사용 가능한 모든 스토리지 기술을 사용할 수 있습니다.

가상 머신을 공유 스토리지에 저장하는 주요 이점 중 하나는 클러스터의 모든 노드가 VM 디스크 이미지에 직접 접근할 수 있어, 실행 중인 머신을 다운타임 없이 라이브 마이그레이션 할 수 있다는 점입니다.

현재 지원하는 네트워크 스토리지 유형은 다음과 같습니다:

LVM Group (iSCSI target을 통한 네트워크 백업)
iSCSI target
NFS Share
CIFS Share
Ceph RBD
Directly use iSCSI LUNs
GlusterFS

지원하는 로컬 스토리지 유형은 다음과 같습니다:

LVM Group (블록 디바이스, FC 디바이스, DRBD 등과 같은 로컬 백업 장치)
Directory (기존 파일 시스템 저장소)
ZFS

1.3. 통합 백업 및 복원

통합 백업 도구 (vzdump)는 실행 중인 컨테이너와 KVM 게스트의 일관된 스냅샷을 생성합니다. 기본적으로 VM 또는 CT 데이터의 아카이브를 생성하며, 여기에는 VM/CT 구성 파일도 포함됩니다.

KVM 라이브 백업은 NFS, CIFS, iSCSI LUN, Ceph RBD에 있는 VM 이미지 등 모든 스토리지 유형에서 작동합니다. 새로운 백업 형식은 VM 백업을 빠르고 효율적으로 저장할 수 있도록 최적화되어 있습니다.(희소 파일, 비순차 데이터, 최소화된 I/O)

1.4. 고가용성 클러스터

멀티 노드 Proxmox VE HA 클러스터는 고가용성 가상 서버를 정의할 수 있게 해줍니다. Proxmox VE HA 클러스터는 검증된 Linux HA 기술을 기반으로 하여 안정적이고 신뢰할 수 있는 고가용성 서비스를 제공합니다.

1.5. 유연한 네트워킹

Proxmox VE는 브릿지 네트워킹 모델을 사용합니다. 모든 VM은 각 게스트의 가상 네트워크 케이블이 모두 같은 스위치에 연결된 것처럼 하나의 브릿지를 공유할 수 있습니다. VM을 외부와 연결하기 위해 브릿지는 물리적 네트워크 카드에 연결되고 TCP/IP 구성이 할당됩니다.

추가적인 유연성을 위해 VLAN(IEEE 802.1q) 및 네트워크 본딩/집계가 가능합니다. 이를 통해 Proxmox VE 호스트를 위한 복잡하고 유연한 가상 네트워크를 구축하여 Linux 네스워크 스택의 모든 기능을 활용할 수 있습니다.

1.6. 통합 방화벽

통합 방화벽을 통해 VM 또는 컨테이너 인터페이스에서 네트워크 패킷을 필터링할 수 있습니다. 일반적인 방화벽 규칙 세트를 “보안 그룹”으로 그룹화할 수 있습니다.

1.7. 하이퍼 컨버지드 인프라(HCI)

Proxmox VE는 컴퓨팅, 스토리지 및 네크워킹 자원을 긴밀하게 통합하고, 고가용성 클러스터, 백업/복원 재해 복구를 관리하는 가상화 플랫폼입니다. 모든 구성 요소는 소프트웨어 정의이며 서로 호환됩니다.

따라서 중앙 웹 관리 인터페이스를 통해 이들을 단일 시스템처럼 관리할 수 있습니다. 이러한 기능들은 Proxmox VE를 오픈 소스 하이퍼 컨버지드 인프라를 배포하고 관리하기 위한 이상적인 선택으로 만듭니다.

1.7.1. Proxmox VE를 통한 하이퍼 컨버지드 인프라(HCI)의 이점

하이퍼 컨버지드 인프라(HCI)는 인프라 수요는 높지만 관리 예산이 적을 때의 배포 환경, 원격 및 지사 환경과 같은 분산 설정, 또는 가상 사설 및 공용 클라우드에 특히 유용합니다.

HCI는 다음과 같은 장점을 제공합니다:

확장성: 컴퓨팅, 네트워킹 및 스토리지 장치를 원활하게 확장할 수 있습니다.(예: 서버와 스토리지를 서로 독립적으로 빠르고 쉽게 확장 가능)
저비용: Proxmox VE는 오픈 소스이며, 컴퓨팅, 스토리지, 네트워킹, 백업 및 관리 센터와 같은 필요한 모든 구성 요소를 통합합니다. 이는 비용이 많이 드는 컴퓨팅/스토리지 인프라를 대체할 수 있습니다.
데이터 보호 및 효율성: 백업 및 재해 복구와 같은 서비스가 통합되어 있습니다.
단순성: 간편한 구성과 중앙 집중식 관리가 가능합니다.
오픈 소스: 벤더에 종속되지 않습니다.

1.7.2. 하이퍼 컨버지드 인프라: 스토리지

Proxmox VE는 하이퍼 컨버지드 스토리지 인프라를 배포하기 위한 통합 지원을 제공합니다. 예를 들어, 웹 인터페이스만을 사용하여 다음 두 가지 스토리지 기술을 배포하고 관리할 수 있습니다:

Ceph: 자가 치유 및 자가 관리가 가능한 신뢰할 수 있고 고도고 확장 가능한 공유 스토리지 시스템입니다. Proxmox VE 노드에서 Ceph 서비스를 관리하는 방법을 확인하십시오.
ZFS: 데이터 손상에 대한 광범위한 보호 기능, 다양한 RAID 모드, 빠르고 저렴한 스냅샷 등의 기능을 제공하는 통합된 파일 시스템 및 논리적 볼륨 관리자입니다. Proxmox VE 노드에서 ZFS의 강력한 기능을 활용하는 방법을 알아보십시오.

이 외에도 Proxmox VE는 다양한 추가 스토리지 기술을 통합할 수 있는 지원을 제공합니다. 이에 대한 자세한 내용은 스토리지 관리자 챕터에서 확인할 수 있습니다.

1.8. 왜 오픈 소스인가

Proxmox VE는 Linux 커널을 사용하며 Debian GNU/Linux 배포판을 기반으로 합니다. Proxmox VE의 소스 코드는 GNU Affero General Public License, 버전 3에 짜라 공개됩니다. 이는 언제든지 소스 코드를 검사하거나 프로젝트에 직접 기여할 수 있음을 의미합니다.

Proxmox에서는 가능한 한 오픈 소스 소프트웨어를 사용할 것을 약속합니다. 오픈 소스 소프트웨어를 사용하면 모든 기능에 완전히 접근할 수 있으며, 높은 보안성과 신뢰성을 보장합니다. 우리는 모든 사람이 소프트웨어의 소스 코드에 접근하여 실행하고, 이를 기반으로 빌드하거나, 프로젝트에 변경사항을 제출할 권리가 있어야 한다고 생각합니다. 모든 사람이 기여하도록 권장되며, Proxmox는 제품이 항상 전문적인 품질 기준을 충족하도록 보장합니다.

오픈 소스 소프트웨어는 또한 비용을 낮추고 핵심 인프라를 단일 벤더에 종속되지 않게 합니다.

1.9. Proxmox VE의 이점

오픈 소스 소프트웨어
벤더 종속 없음
Linux 커널
빠른 설치와 쉬운 사용
웹 기반 관리 인터페이스
REST API
활성화된 큰 커뮤니티
낮은 관리 비용 및 간단한 배포

1.10. 도움 받기

1.10.1. Proxmox VE 위키

주요 정보 출처는 Proxmox VE 위키 입니다. 이 위키는 참고 문서와 사용자 기여 콘텐츠를 결합하여 제공합니다.

1.10.2. 커뮤니티 지원 포럼

Proxmox VE는 완전히 오픈 소스이므로, 사용자들이 Proxmox VE 커뮤니티 포럼을 통해 지식을 공유하고 토론할 것을 항상 권장합니다. 포럼은 Proxmox 지원팀이 관리하며, 전 서계의 많은 사용자 기반을 보유하고 있습니다. 이러한 대규모 포럼은 정보를 얻기 위한 훌륭한 장소입니다.

1.10.3. 메일링 리스트

메일링 리스트를 통해 Proxmox VE 커뮤니티와 이메일로 빠르게 소통할 수 있습니다.

사용자 메일링 리스트: Proxmox VE User List

Proxmox VE는 완전히 오픈 소스이며 기여를 환영합니다! 개발자들의 주요 소통 채널은 다음과 같습니다.

개발자 메일링 리스트: Proxmox VE Development Discussion

1.10.4. 상업적 지원

Proxmox Server Solutions GmbH는 Proxmox VE 구독 서비스 플랜으로 이용할 수 있는 엔터프라이즈 지원도 제공합니다. 구독한 모든 사용자는 Proxmox VE 엔터프라이즈 저장소에 접근할 수 있으며, 기본, 표준 또는 프리미엄 구독을 통해 Proxmox 고객 포털에도 접근할 수 있습니다. 고객 포털은 Proxmox VE 개발자로부터 보장된 응답 시간을 제공하는 도움말과 지원을 제공합니다.

대량 할인 또는 일반적인 추가 정보가 필요하다면 sales@proxmox.com으로 문의하십시오.

1.10.5. 버그 트래커

Proxmox는 공개 버그 트래커를 운영합니다. 문제가 발생하면 그곳에 보고서를 제출하십시오. 문제는 버그일 수도 있고 새로운 기능이나 개선 사항 요청일 수도 있습니다. 버그 트래커는 문제를 추적하는 데 도움을 주며, 문제가 해결되면 알림을 보냅니다.

1.11. 프로젝트 역사

이 프로젝트는 2007년에 시작되었고, 2008년에 첫 번째 안정 버전이 출시되었습니다. 당시 우리는 컨테이너를 위해 OpenVZ를, 가상 머신을 위해 KVM을 사용했습니다. 클러스터링 기능은 제한적이었고, 사용자 인터페이스는 간단한 서버 생성 웹 페이지였습니다.

그러나 우리는 빠르게 새로운 기능을 개발하였으며, Corosync 클러스터 스택을 사용하고 새로운 Proxmox 클러스터 파일 시스템(pmxcfs)을 도입한 것은 큰 진전이었습니다. 이로 인해 사용자는 클러스터의 복잡성을 완전히 숨길 수 있었습니다. 16개의 노드 클러스터를 관리하는 것이 단일 노드를 관리하는 것만큼 간단해졌습니다.

또한 우리는 JSON-Schema로 작성된 완전한 선언적 명세를 가진 새로운 REST API를 도입했습니다. 이를 통해 다른 사람들이 Proxmox VE를 그들의 인프라에 통합할 수 있었으며, 추가적인 서비스를 제공하는 것이 쉬워졌습니다.

새로운 REST API 덕분에 기존 사용자 인터페이스를, JavaScript를 사용하는 현대적인 HTML5 어플리케이션으로 교체할 수 있었습니다. 또한, 오래된 Java 기반 VNC 콘솔 코드를 noVNC로 교체했습니다. 이제 웹 브라우저만 있으면 VM을 관리할 수 있습니다.

다양한 스토리지 유형에 대한 지원도 또 다른 큰 과제였습니다. 특히, Proxmox VE는 2014년에 기본적으로 ZFS on Linux를 제공한 첫 번째 배포판이었습니다. 또 다른 이정표는 하이퍼바이저 노드에서 Ceph 스토리지를 실행하고 관리할 수 있는 기능이었습니다. 이러한 설정은 매우 비용 효율적입니다.

우리가 시작할 때는 KVM에 대한 상업적 지원을 제공하는 최초의 회사 중 하나였습니다. KVM 프로젝트 자체는 지속적으로 발전했으며, 현재는 널리 사용되는 하이퍼바이저입니다. 각 릴리즈마다 새로운 기능이 추가됩니다. 우리는 모든 스토리지 유형에서 스냅샷 백업을 생성할 수 있는 KVM 라이브 백업 기능을 개발했습니다.

버전 4.0에서 가장 눈에 띄는 변화는 OpenVZ에서 LXC로의 이동이었습니다. 이제 컨테이너는 깊이 통합되어 있으며, 가상 머신과 동일한 스토리지 및 네트워크 기능을 사용할 수 있습니다.

1.12. Proxmox VE 문서 개선

Proxmox VE 문서에 대한 기여와 개선은 항상 환영합니다. 기여하는 방법에는 여러 가지가 있습니다.

문서에서 오류를 발견하거나 개선할 부분이 있다고 생각되면, Proxmox 버그 트래커에 버그를 등록하여 수정 제안을 해주십시오.

새로운 콘텐츠를 제안하고 싶다면, 다음 옵션 중 하나를 선택하십시오:

위키: 특정 설정, 사용 방법 가이드, 또는 튜토리얼에 대한 기여는 위키가 적절한 옵션입니다.
참고 문서: 모든 사용자에게 도움이 될 일반적인 콘텐츠는 참고 문서에 기여하는 것이 좋습니다. 여기에는 Proxmox VE 기능의 설치, 구성, 사용 및 문제 해결 방법에 대한 모든 정보가 포함됩니다. 참고 문서는 asciidoc 형식으로 작성됩니다. 문서를 편집하려면 git 저장소를 클론해야 합니다. git://git.proxmox.com/git/pve-docs.git; 그런 다음 README.adoc 문서를 따르십시오.

Proxmox VE 코드베이스 작업에 관심이 있다면, 개발자 문서 위키 글이 시작하는 방법을 안내해 드릴 것입니다.

1.13. Proxmox VE 번역

Proxmox VE 사용자 인터페이스는 기본적으로 영어로 제공됩니다. 그러나 커뮤니티의 기여 덕분에 다른 언어로의 번역도 가능합니다. 새로운 언어 추가, 최신 기능 번역, 불완전하거나 일관성이 없는 번역 개선에 대한 지원을 환영합니다.

번역 파일 관리를 위해 gettext를 사용합니다. Poedit과 같은 도구는 번역 파일을 편집하기 위한 멋진 사용하 인터페이스를 제공하지만, 사용하기 편한 편집기를 사용해도 됩니다. 번역에는 프로그래밍 지식이 필요하지 않습니다.

1.13.1. git을 사용한 번역

언어 파일은 git 저장소로 제공됩니다. git에 익숙한 경우, 개발자 문서에 따라 기여하십시오.

새 번역을 만들려면 다음을 수행하십시오.(을 언어 ID로 대체):

git clone git://git.proxmox.com/git/proxmox-i18n.git
cd proxmox-i18n
make init-<LANG>.po

기존에 있던 언어를 편집하려면 원하는 편집기를 사용하여 다음을 수행하십시오.

poedit <LANG>.po

1.13.2 git 없이 번역

git에 익숙하지 않아도 Proxmox VE 번역에 기여할 수 있습니다. 시작하려면 여기에서 언어 파일을 다운로드하십시오. 개선하고자 하는 언어를 찾아 해당 언어 파일의 “raw” 링크를 우클릭하고 “다른 이름으로 저장…”을 선택하십시오. 파일을 변경한 후 최종 번역을 서명된 기여자 라이센스 계약서와 함께 office(at)proxmox.com으로 직접 보내십시오.

1.13.3 번역 테스트

번역을 Proxmox VE에서 사용하려면 먼저 .po 파일을 .js 파일로 변환해야 합니다. 같은 저장소에 있는 다음 스크립트를 호출하여 이 작업을 수행할 수 있습니다:

./po2js.pl -t pve xx.po >pve-lang-xx.js

생성된 파일 pve-lang-xx.js를 Proxmox 서버의 /usr/share/pve-i18n 디렉토리에 복사하여 테스트할 수 있습니다.

또는 저장소의 루트에서 다음 명령을 실행하여 deb 패키지를 빌드할 수 있습니다.

make deb

중요: 이러한 방법 중 어느 것이든 작동하려면 시스템에 다음 perl 패키지가 설치되어 있어야 합니다. Debian/Ubuntu에서는 다음과 같이 설치할 수 있습니다:

apt-get install perl liblocale-po-perl libjson-perl

1.13.4. 번역 보내기

완성된 번역(.po 파일)을 서명된 기여자 라이센스 계약서와 함께 office(at)proxmox.com으로 Proxmox 팀에 보낼 수 있습니다. 개발 경험이 있는 경우, 패치로 작성하여 Proxmox VE 개발 메일링 리스트에 보낼 수도 있습니다. 자세한 내용은 개발자 문서를 참조하십시오.

후기

지금까지는 1.2.에서 ZFS 로컬 스토리지에 VM 디스크 이미지를 올려서 사용했고, 큰 문제는 없었다. 하지만 최근에 인텔 N100 노드를 하나 추가하면서 클러스터링 작업을 진행하면서 마이그레이션 기능도 잘 사용하고 있다. 마이그레이션 작업은 VM/CT를 중단시키는 과정이 필수적인데, 작은 크기의 VM/CT를 마이그레이션 할때야 금방 가능하지만, 용량이 커진다면 문제가 발생할 것 같다. 그리고 이 방식은 양쪽 노드의 디스크 공간에 여유가 있어야 할 것이다. 하지만 CIFS 스토리지를 VM 이미지, CT에 사용한다면 이러한 다운타임을 해결할 수 있다고 하니 TrueNAS에 SSD만으로 구성된 전용 스토리지를 만들고 이것을 이용해 VM 이미지, CT를 저장하는 방법을 적용해봐야 겠다.

또한 현재 여러 지인에게 Proxmox 계정을 생성해 주고, 서버를 사용할 수 있게 해줬는데, 결국에 reverse proxy나 제대로 된 네트워크 셋팅을 하려면 pfsense로의 접근도 필요하다, 하지만 이때 적절한 권한을 매번 생성하고 관리해 주는 것이 굉장히 귀찮고 어려웠다. Proxmox가 REST API를 사용하여 다른 관리 도구로 쉽게 통합될 수 있다고 하니, pfsense의 API도 적절히 사용하고 Terraform을 이용해서 종합적으로 제어할 수 있는 환경을 만들어보고 싶다.

참고

Proxmox VE Administration Guide

글의 저작권과 관련된 사항은 Proxmox의 라이센스를 따릅니다.

pfSense 2.7 업그레이드 후 Telegraf 오류 해결 방법

Sun, 28 Jul 2024 00:00:00 GMT

1 오류

pfSense CE 2.6 버전에서 2.7버전으로 업그레이드 한 이후로

PHP Fatal error: Uncaught TypeError: implode(): Argument #1 ($pieces) must be of type array, string given in /usr/local/pkg/telegraf.inc:132
Stack trace:
#0 /usr/local/pkg/telegraf.inc(132): implode(',', NULL)
#1 /etc/inc/pkg-utils.inc(709) : eval()'d code(1): telegraf_resync_config()
#2 /etc/inc/pkg-utils.inc(709): eval()
#3 /etc/rc.start_packages(66): sync_package('Telegraf')
#4 {main}
thrown in /usr/local/pkg/telegraf.inc on line 132

위와 같은 에러가 지속적으로 발생하는 것을 발견했다. 그리고 원래 상단바 Service -> Telegraf를 선택해서 telegraf 설정을 GUI로 관리할 수 있었는데, 이 Telegraf 선택지가 사라졌다. Telegraf는 pfSense에서 수집 정보들을 DB로 전송해 주는 역할을 한다. 하지만 이 오류가 발생하면 더 이상 telegraf가 작동하지 않는다. 하지만 telegraf를 한번 삭제한 이후에 pfSense를 재시작하고 재시작 직후 teletraf는설치하면 이전 설정대로 telegraf가 작동한다. 하지만 오류는 여전하고 GUI에의 접근 또한 불가능하다.

2 왜 이런 오류가 생겼을까?

2.1 오류가 발생한 코드

telegraf.inc파일에서 발생했다. 이 파일을 살펴보면 telegraf_resync_config작업을 수행하는데, 이는 설정값대로 /usr/local/etc/telegraf.conf 파일을 다시 동기화 해주는 코드가 작성돼 있다. 이 작업은 GUI에서 telegraf 설정값을 바꿨을 때, telegraf를 재설치 했을 때 동작한다. (추가로 다른 조건이 있을 수 있지만 이 두 조건은 확실하다.)

먼저 error가 발생한 코드를 살펴보도록 하자. pfSense의 Edit File을 통해 살펴볼 수 있다.

//      /usr/local/pkg/telegraf.inc
        /* Ping Monitor Configuration */
        if ($telegraf_conf["ping_enable"]) {
                if (!empty($telegraf_conf['ping_host_1'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_1"] . '"';
                }
                if (!empty($telegraf_conf['ping_host_2'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_2"] . '"';
                }
                if (!empty($telegraf_conf['ping_host_3'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_3"] . '"';
                }
                if (!empty($telegraf_conf['ping_host_4'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_4"] . '"';
                }

                $monitor_hosts = implode(",", $monitor_hosts);      // line 132

                $cfg .= "\n[[inputs.ping]]\n";
                $cfg .= "\turls = [" . $monitor_hosts . "]";
                $cfg .= "\n\tdeadline = 0\n\n"; /* deadline (-w) function not supported in BSD ping */
        }

오류가 발생한 라인의 코드를 살펴보면 $telegraf_conf에서 ping_host_*의 값들을 가져와서 아래와 같은 형태로 만들어준다.

[[inputs.ping]]
	urls = ["host.1.ip.addr","host.2.ip.addr","host.3.ip.addr","host.4.ip.addr"]
	deadline = 0

이 부분은 telegraf가 ping메세지를 지정된 IP로 보내고 결과를 받아 목표로하는 서버가 살아있는지 확인할 수 있게 해준다. 필수적인 사항은 아니고, pfSense의 telegraf 설정에서 비활성화할 수 있다.

2.2 오류가 발생한 곳

error 메시지에서는 telegraf.inc의 line 132에서 implode(',', NULL)때문에 error가 발생했음을 알 수 있다. telegraf.inc파일의 line 132를 보면 $monitor_hosts = implode(",", $monitor_hosts);라는 코드가 있는데, 여기서 $monitor_hosts가 NULL이라는 것이다. 왜 그럴까? 먼저 line 132 이전에 if 문에서 ping_host_*값들을 $monitor_hosts array에 추가해 주는 것을 알 수 있다. 그런데 만약 telegraf_conf에 ping_host_*값이 없다면? $monitor_hosts에는 아무것도 들어가지 않을 것이다. PHP에서는 변수가 명시적으로 초기화되지 않아도 사용될 때 자동으로 생성된다. 그러나 변수가 명시적으로 초기화되지 않은 경우 해당 변수는 NULL 값을 가질 수 있다. 때문에 if문을 지나면서 한 번도 조건을 만족하지 못했다면 $monitor_hosts는 NULL이 될 수 있다.

pfSense CE 2.7은 PHP 8버전을 사용한다. PHP 8버전에서는 implode를 NULL 값과 함께 호출하는 것이 허용되지 않는다. 때문에 implode(',', NULL)과 같은 형식은 error를 발생시킨다.

2.3 왜 업그레이드 이후에 에러가 발생했을까?

pfSense CE 2.7 업그레이드 노트를 살펴보면 PHP 버전이 7.4.X 버전에서 8.2.6 버전으로 업그레이드된 것을 알 수 있다. PHP 7버전에서는 implode를 NULL 값과 함께 호출하는 것이 허용됐다. 구현에 따라 implode의 반환 값이 NULL 또는 빈 문자열이 된다. 때문에 $monitor_hosts에 아무것도 들어가지 않았다고 하더라도 error가 발생하지 않는다.

하지만 위에서 설명한 것과 같이 PHP 8버전에서는 더 엄격한 type검사를 시행하고, 때문에 implode를 NULL 값과 함께 호출하면 error가 발생한다. 그 때문에 pfSense 2.6에서 2.7버전으로 업그레이드를 하면서, PHP 버전이 8버전으로 업그레이드됐고, 이것이 문제를 일으킨 것이다.

2.4 이것은 왜 방지되지 않았을까?

우선 telegraf는 urls가 비어있다고 하더라도 아무런 문제 없이 동작한다. telegraf/plugins/inputs/ping/ping.go을 보자.

func (p *Ping) Gather(acc telegraf.Accumulator) error {
	for _, host := range p.Urls {
		p.wg.Add(1)
		go func(host string) {
			defer p.wg.Done()

			switch p.Method {
			case "native":
				p.pingToURLNative(host, acc)
			default:
				p.pingToURL(host, acc)
			}
		}(host)
	}

	p.wg.Wait()

	return nil
}

여기서 ping을 시도한다. 여기서 p.Urls가 비어있다고 하더라도, ping작업을 수행하지 않을 뿐 문제는 생기지 않는다. p.wg.Add(1)과 p.wg.Done()역시 호출되지 않기에 p.wg.wait()이 즉시 호출된다. 그 때문에 동기화 문제도 발생하지 않는다.

지금은 pfSense의 Telegraf 설정에서 Enable Ping Monitor옵션을 켜고 Ping Host에 아무것도 적지 않고 저장하면 아래와 같은 Crash Report를 내보낸다.

PHP Fatal error:  Uncaught TypeError: implode(): Argument #1 ($array) must be of type array, string given in /usr/local/pkg/telegraf.inc:132
Stack trace:
#0 /usr/local/pkg/telegraf.inc(132): implode()
#1 /usr/local/www/pkg_edit.PHP(245) : eval()'d code(1): telegraf_resync_config()
#2 /usr/local/www/pkg_edit.PHP(245): eval()
#3 {main}
  thrown in /usr/local/pkg/telegraf.inc on line 132

하지만 이것은 위에서 서술한 PHP error가 발생해서 나온 Crash Report일 뿐이지, pfSense에서 Telegraf 설정 GUI에서 Save를 눌렀을 때 pfSense가 자체적으로 format을 검증하고 에러를 내는 것이 아니다. 그 때문에 pfSense CE 2.6버전에서는 Crash Report 없이 정상적으로 저장됐을 것이다.

Ping Host는 입력하는 창은 아래와 같이 돼 있다.

여기서 분명 Ping Host 1은 (optional)표시가 없다. 그런데 비우고 저장해도 pfSense에서는 경고를 보내지 않는다. pfSense 2.7버전 이전에서 Enable Ping Monitor 옵션을 켜고 Ping Host에 아무것도 적지 않고 저장한 사람들은 모두 같은 오류가 발생했을 것이다. 또한 이 오류에 대해서 여러 버그 리포트를 봤는데, 많은 사람들은 해당 문제를 재현하지 못했다고 말하고 있었다. 이것은 아마도 Enable Ping Monitor 옵션이 꺼진 상태에서 pfSense 2.6에서 2.7버전으로 업그레이드했기 때문에 문제가 발생하지 않았을 것으로 생각된다.

3 어떻게 해결할까?

3.1 Ping Host에 IP 추가

위에서 설명했듯이 Ping Host에 IP가 하나도 들어있지 않아서 발생하는 문제다. 때문에 Ping Host에 한 개 이상 IP를 추가하면 오류를 해결할 수 있다. 그런데 앞서 1 오류에서 “GUI로 관리할 수 있었는데, 이 Telegraf 선택지가 사라졌다.”라고 했다. 그럼 어떻게 설정을 수정할 수 있을까?

pfSense는 /conf/config.xml이 모든 package들의 configuration이 저장된다. 이 파일을 열어보면 <telegraf>에 <ping_host_1></ping_host_1>항목이 있다. 여기에 아래와 같이 IP를 추가하고 저장해주면 된다.

<ping_host_1>db.server.ip.addr</ping_host_1>

3.2 Ping Monitor 옵션 비활성화

위에 코드를 살펴보면 if ($telegraf_conf["ping_enable"]) {여기에 ping_enable옵션이 켜져 있는지 확인하는 코드가 있다. 만약 Ping Monitor 옵션이 커져있다면, 문제가 되는 line 132 또한 실행되지 않을 것이다. 이 또한 /conf/config.xml에 <ping_enable>on</ping_enable>항목이 있다. 여기서 아래와 같이 on을 지워주면 Ping Monitor 옵션을 비활성화한 것이다.

<ping_enable></ping_enable>

이것으로 오류를 해결할 수 있다.

3.3 telegraf.inc 변경

처음에는 문제의 근본적인 원인인 telegraf.inc 파일을 변경해서 해결할 수 있다고 생각했다. 하지만 telegraf.inc 파일은 package를 재설치하거나 pfSense를 재부팅할 때 다시 서버에서 가져온다. 그 때문에 수정은 영구적이지 않다. 또한 telegraf.inc 파일을 수정하고 해당 패키지를 재실행할 방법 또한 마땅치 않다. 하지만 근본적으로는 이 부분이 해결돼야 한다.

        /* Ping Monitor Configuration */
        if ($telegraf_conf["ping_enable"]) {
                $monitor_hosts = array();
                if (!empty($telegraf_conf['ping_host_1'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_1"] . '"';
                }
                if (!empty($telegraf_conf['ping_host_2'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_2"] . '"';
                }
                if (!empty($telegraf_conf['ping_host_3'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_3"] . '"';
                }
                if (!empty($telegraf_conf['ping_host_4'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_4"] . '"';
                }

                if (!empty($monitor_hosts)) {
                    $monitor_hosts = implode(",", $monitor_hosts);      // line 132

                    $cfg .= "\n[[inputs.ping]]\n";
                    $cfg .= "\turls = [" . $monitor_hosts . "]";
                    $cfg .= "\n\tdeadline = 0\n\n"; /* deadline (-w) function not supported in BSD ping */
                }
        }

위와 같이 $monitor_hosts를 array()로 초기화하고 빈 배열인지 확인하고 다음 과정을 진행하면 될 것이다.

이 해결 방법을 떠올리고 해당 패키지에 기여를 하고 싶어서 검색하다 pfSense package 저장소를 발견했는데, 완전히 같은 방법으로 이미 해결돼 있어서 놀랐다. 조금 더 관심을 두고 빨리 해결하고자 했으면 좋았을 것 같다. 또한 pfSense CE 2.8.0, pfSense Plus 24.08버전에서는 해당 패치가 포함돼 문제가 해결될 것 같다.

후기

이 문제는 pfSense CE 2.7버전 업데이트 직후 부터 보고됐었다. 하지만 그동안 해결 방법이 알려지지 않았고, 최근에 발견한 이 문서 이외에는 해결 방법을 찾을 수 없었다. 그리고 해당 문서에서 또한 친절한 해결 절차에 대해서는 쓰여있지 않았다. 때문에 이 글을 작성하게 됐다. 같은 오류로 많은 스트레스를 받은 사람들이 이 글로 오류를 해결했기를 바란다.

이 글에는 표현이 이상하거나 틀린 내용이 있을 수 있습니다. 모든 지적은 환영합니다.

참고

How to Fix Telegraf Errors After Upgrading to pfSense 2.7

Sun, 28 Jul 2024 00:00:00 GMT

1 Error

After upgrading from pfSense CE version 2.6 to version 2.7, I encountered the following error continuously:

PHP Fatal error: Uncaught TypeError: implode(): Argument #1 ($pieces) must be of type array, string given in /usr/local/pkg/telegraf.inc:132
Stack trace:
#0 /usr/local/pkg/telegraf.inc(132): implode(',', NULL)
#1 /etc/inc/pkg-utils.inc(709) : eval()'d code(1): telegraf_resync_config()
#2 /etc/inc/pkg-utils.inc(709): eval()
#3 /etc/rc.start_packages(66): sync_package('Telegraf')
#4 {main}
thrown in /usr/local/pkg/telegraf.inc on line 132

Additionally, I noticed that the option to manage Telegraf settings through the GUI, which was previously accessible under Service -> Telegraf, has disappeared. Telegraf in pfSense is responsible for sending collected information to a database. However, with this error, Telegraf no longer functions.

By uninstalling Telegraf, restarting pfSense, and then reinstalling Telegraf immediately after the restart, it resumes working with the previous settings. Despite this, the error persists and GUI access remains unavailable.

2 Why Does This Error Occur?

2.1 Code Causing the Error

The error occurs in the telegraf.inc file. This file contains the code responsible for performing the telegraf_resync_config task, which resynchronizes the /usr/local/etc/telegraf.conf file according to the configuration values. This task is executed when Telegraf settings are changed via the GUI or when Telegraf is reinstalled (there might be additional conditions, but these two are confirmed).

First, let’s examine the code where the error occurs. You can view this using pfSense’s Edit File feature.

//      /usr/local/pkg/telegraf.inc
        /* Ping Monitor Configuration */
        if ($telegraf_conf["ping_enable"]) {
                if (!empty($telegraf_conf['ping_host_1'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_1"] . '"';
                }
                if (!empty($telegraf_conf['ping_host_2'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_2"] . '"';
                }
                if (!empty($telegraf_conf['ping_host_3'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_3"] . '"';
                }
                if (!empty($telegraf_conf['ping_host_4'])) {
                        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_4"] . '"';
                }

                $monitor_hosts = implode(",", $monitor_hosts);      // line 132

                $cfg .= "\n[[inputs.ping]]\n";
                $cfg .= "\turls = [" . $monitor_hosts . "]";
                $cfg .= "\n\tdeadline = 0\n\n"; /* deadline (-w) function not supported in BSD ping */
        }

Examining the code at the line where the error occurs, the values of ping_host_* are fetched from $telegraf_conf and formatted as follows:

[[inputs.ping]]
	urls = ["host.1.ip.addr","host.2.ip.addr","host.3.ip.addr","host.4.ip.addr"]
	deadline = 0

This section allows Telegraf to send ping messages to specified IP addresses and receive results to verify if the target servers are alive. It is not a mandatory feature and can be disabled in the pfSense Telegraf settings.

2.2 Location of the Error

The error message indicates that the error occurs at line 132 of telegraf.inc due to implode(',', NULL). When examining line 132 of the telegraf.inc file, the code $monitor_hosts = implode(",", $monitor_hosts); is found, implying that $monitor_hosts is NULL. Why does this happen? Before line 132, the if statements attempt to add ping_host_* values to the $monitor_hosts array. If there are no ping_host_* values in telegraf_conf, $monitor_hosts remains empty.

In PHP, variables are automatically created when they are first used, even if they are not explicitly initialized. However, if a variable is not explicitly initialized, it can have a NULL value. Therefore, if none of the conditions in the if statements are satisfied, $monitor_hosts can end up being NULL.

pfSense CE 2.7 uses PHP version 8. In PHP 8, calling implode with a NULL value is not allowed. As a result, the format implode(',', NULL) will trigger an error.

This change in PHP’s behavior means that the previously acceptable code now results in an error in pfSense 2.7. The solution involves ensuring that $monitor_hosts is always initialized as an array before it is used in the implode function. This can be done by initializing $monitor_hosts as an empty array before the if statements.

2.3 Why Did the Error Occur After the Upgrade?

Reviewing the pfSense CE 2.7 upgrade notes, it becomes clear that the PHP version was upgraded from 7.4.X to 8.2.6. In PHP 7, it was permissible to call implode with a NULL value. Depending on the implementation, the return value of implode could be either NULL or an empty string. Therefore, even if $monitor_hosts contained nothing, no error would occur.

However, as previously explained, PHP 8 enforces stricter type checking. As a result, calling implode with a NULL value triggers an error. Consequently, when upgrading from pfSense 2.6 to 2.7, the PHP version was also upgraded to version 8, which introduced this issue.

The change in PHP’s behavior due to the version upgrade directly caused the problem. The code that worked correctly in PHP 7.4.X no longer functions as expected in PHP 8.2.6 because of the stricter type enforcement, leading to the observed error.

2.4 Why Wasn’t This Prevented?

First, it’s important to note that Telegraf functions without any issues even if the URLs are empty. Let’s look at the relevant code in telegraf/plugins/inputs/ping/ping.go.

func (p *Ping) Gather(acc telegraf.Accumulator) error {
	for _, host := range p.Urls {
		p.wg.Add(1)
		go func(host string) {
			defer p.wg.Done()

			switch p.Method {
			case "native":
				p.pingToURLNative(host, acc)
			default:
				p.pingToURL(host, acc)
			}
		}(host)
	}

	p.wg.Wait()

	return nil
}

In this code, the ping operation is attempted. Even if p.Urls is empty, no issues arise; the ping task simply doesn’t execute. Since p.wg.Add(1) and p.wg.Done() aren’t called, p.wg.Wait() is invoked immediately, avoiding any synchronization issues.

Currently, if you enable the “Enable Ping Monitor” option in pfSense’s Telegraf settings and save without specifying any “Ping Host,” you get a crash report like the following:

PHP Fatal error:  Uncaught TypeError: implode(): Argument #1 ($array) must be of type array, string given in /usr/local/pkg/telegraf.inc:132
Stack trace:
#0 /usr/local/pkg/telegraf.inc(132): implode()
#1 /usr/local/www/pkg_edit.PHP(245) : eval()'d code(1): telegraf_resync_config()
#2 /usr/local/www/pkg_edit.PHP(245): eval()
#3 {main}
  thrown in /usr/local/pkg/telegraf.inc on line 132

However, this crash report is generated by the PHP error described earlier and is not a result of pfSense’s internal format validation upon saving the Telegraf settings via the GUI. This means that in pfSense CE 2.6, it would have saved without any crash reports.

The “Ping Host” input fields are displayed as follows:

Here, “Ping Host 1” does not have an (optional) label. Even so, pfSense does not issue a warning if left blank and saved. Therefore, anyone who enabled the “Enable Ping Monitor” option and saved without specifying a “Ping Host” prior to version 2.7 would have encountered the same error after upgrading.

Various bug reports on this issue indicate that many users could not reproduce the problem. This is likely because they upgraded from pfSense 2.6 to 2.7 with the “Enable Ping Monitor” option disabled, preventing the issue from occurring.

3 How to Fix It?

3.1 Add an IP to Ping Host

As explained earlier, the issue arises because there are no IP addresses specified in Ping Host. Adding at

least one IP address to Ping Host will resolve the error. However, as noted in 1 Error, the option to manage Telegraf settings via the GUI has disappeared. So, how can we modify the settings?

pfSense stores the configuration for all packages in /conf/config.xml. Opening this file, you’ll find an entry for <telegraf> that includes <ping_host_1></ping_host_1>. You can add an IP address to this entry as follows:

<ping_host_1>db.server.ip.addr</ping_host_1>

Save the changes, and this should resolve the error by ensuring that at least one IP address is specified.

3.2 Disable Ping Monitor Option

In the code examined in 2.1 Code Causing the Error, there is a check if ($telegraf_conf["ping_enable"]) { that verifies whether the ping_enable option is turned on. If the Ping Monitor option is disabled, line 132, which causes the issue, will not be executed. This option is also present in /conf/config.xml as <ping_enable>on</ping_enable>. Removing the on value will disable the Ping Monitor option.

To disable it, modify the entry to:

<ping_enable></ping_enable>

This will turn off the Ping Monitor option and prevent the error from occurring. Save the changes, and the issue should be resolved.

3.3 Modify telegraf.inc

Initially, it seemed that modifying the telegraf.inc file to fix the root cause of the problem would be a viable solution. However, the telegraf.inc file is re-downloaded from the server whenever the package is reinstalled or pfSense is rebooted. This means any changes made to the file are not permanent. Additionally, there is no straightforward way to restart the package after modifying the telegraf.inc file. Nonetheless, addressing the issue at its core is essential.

Here is the modified code:

/* Ping Monitor Configuration */
if ($telegraf_conf["ping_enable"]) {
    $monitor_hosts = array();
    if (!empty($telegraf_conf['ping_host_1'])) {
        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_1"] . '"';
    }
    if (!empty($telegraf_conf['ping_host_2'])) {
        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_2"] . '"';
    }
    if (!empty($telegraf_conf['ping_host_3'])) {
        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_3"] . '"';
    }
    if (!empty($telegraf_conf['ping_host_4'])) {
        $monitor_hosts[] = '"' . $telegraf_conf["ping_host_4"] . '"';
    }

    if (!empty($monitor_hosts)) {
        $monitor_hosts = implode(",", $monitor_hosts); // line 132

        $cfg .= "\n[[inputs.ping]]\n";
        $cfg .= "\turls = [" . $monitor_hosts . "]";
        $cfg .= "\n\tdeadline = 0\n\n"; /* deadline (-w) function not supported in BSD ping */
    }
}

By initializing $monitor_hosts as an array and checking if it is empty before proceeding, the issue can be resolved.

Upon thinking of this solution and wanting to contribute to the package, I discovered the pfSense package repository. To my surprise, the issue was already resolved using this exact method. Additionally, it seems that this patch will be included in pfSense CE 2.8.0 and pfSense Plus 24.08, resolving the problem in future versions.

Conclusion

This issue was reported immediately after the pfSense CE 2.7 update. However, no solution was widely known until recently, apart from this document, which did not provide a detailed resolution process. Hence, I decided to write this post. I hope this guide helps others who have been stressed by the same error to resolve it successfully.

Please note that there may be awkward expressions or inaccuracies in this post. All constructive feedback is welcome.

References

우분투 lvm 확장하기

Mon, 02 Oct 2023 00:00:00 GMT

0 환경

proxmox 7.4
ubuntu 20.04 VM
확장하기 전 상태는 아래와 같다.

1 과정

우분투 머신에 디스크를 추가해준다.

sudo su
fdisk -l | grep "/dev/sd"

추가한 디스크 확인

pvscan해서 확인 후 pvcreate로 추가한 디스크를 볼륨에 추가한다.

pvscan
pvcreate /dev/sdb
pvscan

이후 vgextend로 VG에 추가해줍니다.

vgextend ubuntu-vg /dev/sdb

lvscan으로 용량을 확장할 lvm의 경로를 확인합니다.

lvscan

lvextend -l +100%FREE -n [lvm 경로]로 확장.

lvextend -l +100%FREE -n /dev/ubuntu-vg/ubuntu-lv

resize2fs로 확장.

resize2fs /dev/ubuntu-vg/ubuntu-lv

df -h로 확장됐는지 확인.

df -h

참고

https://nirsa.tistory.com/232

10분만에 우분투 커널 컴파일하기

Tue, 19 Sep 2023 00:00:00 GMT

0 시작하기에 앞서

이 글을 쓰게 된 이유는 학교에서 현재 “리눅스 시스템 응용 설계”라는 과목을 수강하고 있기 때문이다. 이 과목에서는 당연히 수없이 많은 커널 컴파일을 해야 할 수 있고, 때문에 그 과정을 간단하게 정리하고자 글을 썼다.

블로그 첫 글을 보면 알겠지만 나는 44core 시스템을 보유하고 있다. 보통의 경우 커널 컴파일은 굉장히 오래 걸릴 수도있으니, 여유를 가지고 진행하자.

1 우분투 설치

VirtualBox나 듀얼부팅으로 ubuntu 서버 버전 혹은 데스크탑 버전을 설치해준다. 이외에 본인이 편한 환경에 설치해주면 된다.
디스크 용량은 40GB 이상으로 설정해주자.
작업을 편하게 하기 위해 SSH 접속 환경을 셋팅해준다.
커널을 설치하기 이전에 업데이트를 해준다.
이후 현재 커널 버전을 확인해준다.

sudo apt update && upgrade      #업데이트
uname -a                        #커널 버전 확인

2 커널 다운로드

https://mirrors.edge.kernel.org/pub/linux/kernel/ 해당 사이트에서 원하는 버전의 커널을 다운받는다.
강의에서 5.4.214버전을 사용하기 때문에 해당 버전으로 진행하겠다.

cd /usr/src/
sudo wget https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.4.214.tar.gz    #다운로드
sudo tar -xzvf linux-5.4.214.tar.gz     #압축 해제
sudo cp linux-headers-5.4.0-162-generic/.config linux-5.4.214   #config 파일 복사

config 수정

cd linux-5.4.214/
sudo nano .config   #config 파일 수정
#아래 두 줄을 수정해준다.
#CONFIG_SYSTEM_TRUSTED_KEYS="debian/canonical-certs.pem" -> CONFIG_SYSTEM_TRUSTED_KEYS = ""
#CONFIG_SYSTEM_REVOCATION_KEYS="debian/canonical-certs.pem" -> CONFIG_SYSTEM_REVOCATION_KEYS=""

필요 패키지 설치

sudo apt install build-essential libncurses5 libncurses5-dev bin86 kernel-package libssl-dev bison flex libelf-dev dwarves  #필요 패키지 설치
sudo reboot     #재부팅

menuconfig

cd /usr/src/linux-5.4.214/
sudo make menuconfig

load -> ok -> exit -> yes

커널 이름 변경 (optional)

sudo nano Makefile

3 커널 컴파일

코어 수 확인

grep -c processor /proc/cpuinfo     #176

compile

sudo make -j176
sudo make modules_install
sudo make install

4 kernel 변경

Boot kernel 순서 확인

awk -F\' '/menuentry / {print $2}' /boot/grub/grub.cfg

test@test:/usr/src/linux-5.4.214$ awk -F\' '/menuentry / {print $2}' /boot/grub/grub.cfg
Ubuntu                                                  ---->> 1
Ubuntu, with Linux 5.4.214.test                         ---->> 1>0
Ubuntu, with Linux 5.4.214.test (recovery mode)         ---->> 1>1
Ubuntu, with Linux 5.4.0-162-generic                    ---->> 1>2
Ubuntu, with Linux 5.4.0-162-generic (recovery mode)    ---->> 1>3

sudo nano /etc/default/grub     #grub 파일 수정

sudo update-grub                #grub 업데이트
sudo reboot                     #재부팅

5 kernel 변경 확인

uname -a

커널 버전이 잘 변경된 것을 확인할 수 있다.

Proxmox VM에 GPU 패스쓰루(Passthrough)하기

Mon, 18 Sep 2023 00:00:00 GMT

0 환경

자세한 서버의 하드웨어는 블로그 첫 글을 참고하시기 바랍니다.
PVE 7.4-16버전, 가상머신은 ubuntu-server 20.04버전입니다.
nvidia GPU로 테스트했습니다. 다른 제조사의 GPU의 경우 방법이 다를 수 있습니다.
메인보드의 BIOS에서 Passthrough와 관련된 셋팅이 돼있어야 합니다.

1 PVE 설정

nano /etc/default/grub      #grub 파일 수정

아래의 내용을 추가해 준다.

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction nofb nomodeset video=vesafb:off,efifb:off,pci=noaer,pci=nommconf"

update-grub                 #grub 업데이트
nano /etc/modules           #modules 파일 수정

아래 내용을 추가해 준다.

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

nano /etc/modprobe.d/blacklist.conf     #blacklist.conf 파일 수정

아래 내용을 추가해 준다.

blacklist nouveau
blacklist nvidia
blacklist radeon

vfio 정보를 등록해준다.

lspci -v | grep NVIDIA              #00:00 형식의 값을 찾는다.
lspci -n -s 00:00                   #xxxx:xxxx 형식의 값을 찾는다.
nano /etc/modprobe.d/vfio.conf      #vfio.conf 파일 수정

아래 내용을 추가해 준다.

options vfio-pci ids=xxxx:xxxx,xxxx:xxxx disable_vga=1

update-initramfs -u     #initramfs 업데이트
reboot                  #재부팅

2 VM 설정

부팅 전 설정

Create VM 창을 기준으로 설명

System
- Machine : q35
- BIOS : OVMF (UEFI)
- EFI Storage를 설정해준다.

Disks
- Bus/Device : SATA

Hardware - Add - PCI Device - 원하는 GPU를 선택
- All functions : 체크
- Primary GPU : 체크 해제
- ROM-Bar : 체크
- PCI-Express : 체크

이후 우분투 서버를 설치해주고 SSH에 접속할 수 있는 환경을 만들어두고 IP를 기억해두자.

부팅 후 설정

먼저 VM을 꺼준다.

nano /etc/pve/qemu-server/000.conf      #000.conf 파일 수정 000은 VM ID이다.

아래 내용을 추가해 준다.

cpu: host,hidden=1

GPU ROM dump

cd /sys/bus/pci/devices/0000:00:00.0/   #0000:00:00.0에서 00:00부분에 이전에 lspci에서 썼던 번호를 쓴다.
echo 1 > rom
cat rom > /tmp/image00.rom              #image00.rom에서 00부분에 이전에 lspci에서 썼던 번호를 쓴다.
echo 0 > rom
cd ~/NVIDIA-vBIOS-VFIO-Patcher
python nvidia_vbios_vfio_patcher.py -i /tmp/image00.rom -o /tmp/image00.patched.rom --disable-footer-strip
#image00.rom에서 00부분에 이전에 lspci에서 썼던 번호를 쓴다.

ROM 파일 복사

cp /tmp/image00.pached.rom /usr/share/kvm/gpu00.pached.rom  #00부분에 이전에 lspci에서 썼던 번호를 쓴다.
nano /etc/pve/qemu-server/000.conf      #000.conf 파일 수정 000은 VM ID이다.

아래 내용을 추가해 준다.

00부분에 이전에 lspci에서 썼던 번호를 쓴다.

hostpci0: 0000:00:00,pcie=1,x-vga=1,romfile=gpu00.patched.rom

Hardware - PCI Device
- All functions : 체크
- Primary GPU : 체크
- ROM-Bar : 체크
- PCI-Express : 체크

드라이버 설치

VM을 켜준다.

sudo apt update && upgrade
lshw -C display     #GPU확인
sudo apt install nvidia-driver-535      #GPU에 맞는 버전의 드라이버 설치
sudo apt update && upgrade
sudo reboot         #재부팅
nvidia-smi

아래의 이미지가 뜬다면 성공한것이다.

오류

오류가 나면 아래 스크립트를 실행하고 위의 내용을 진행해준다.

echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/remove     #0000:00:00.0에서 00:00부분에 이전에 lspci에서 썼던 번호를 쓴다.
echo 1 > /sys/bus/pci/rescan

Plex Media server 마이그레이션하기

Sun, 17 Sep 2023 00:00:00 GMT

0. 마이그레이션을 하게 된 이유

지금까지 Plex 미디어 서버를 영상, 노래 스트리밍 용도로 잘 활용해 왔다. 다만 서버의 CPU는 Xeon이기 때문에 내장그래픽은 당연히 없고 설치되어 있는 QUADRO® P4000은 주로 Stable Diffusion이나 기타 작업을 할 때 여러 가상머신에서 사용하기 때문에 Plex의 하드웨어 트랜스코더로 사용하기에는 적절하지 않다. 그리고 보유하고 있는 미디어들이 점점 증가하면서 메타데이터의 용량이 늘어나게 되었고, 기존에 Plex가상머신에 할당해 두었던 20GB가 가득 차게 되었다. 때문에 중고 QUADRO® P2000을 구매하여 이를 이용해 하드웨어 트랜스코더로 이용해서 Plex서버를 마이그레이션 해보고자 한다.

나는 proxmox 위에서 돌아가는 ubuntu 20.04가상머신에서 해당 내용을 진행했다. 하지만 다른 OS도 진행은 크게 다르지 않다.

1. 준비

먼저 구동되고 있던 Plex 서버의 웹 gui에서 설정 > 라이브러리 > “변경사항이 발견될때 부분적인 스캔 실행”을 체크 해제해 준다.
로그아웃 해줍니다.
Plex 미디어 서버가 구동되고 있는 머신에서 Plex를 종료해 준다.

sudo systemctl stop plexmediaserver.service         #서비스 종료
sudo systemctl status plexmediaserver.service       #종료 상태 확인

active상태가 아니면 종료된 상태이다.

2. 새로운 Plex Media 서버 설치

마이그레이션 할 대상 서버에 Plex Media 서버를 설치해 준다.

echo deb https://downloads.plex.tv/repo/deb public main | sudo tee /etc/apt/sources.list.d/plexmediaserver.list
curl https://downloads.plex.tv/plex-keys/PlexSign.key | sudo apt-key add
sudo apt update && upgrade
sudo apt install plexmediaserver

설치가 되었는지 확인한다. 위의 이미지처럼 active상태면 설치가 된 상태이다.

sudo systemctl status plexmediaserver.service       #서비스 상태 확인

서버에 로그인만 해주고 로그아웃하고 종료해 줍니다.

sudo systemctl stop plexmediaserver.service         #서비스 종료
sudo systemctl status plexmediaserver.service       #종료 상태 확인

3 서버 데이터 복사

마이그레이션 할 대상 서버에 기존 서버와 똑같은 위치에 미디어들을 이동시켜 줍니다. cifs같은 경우라면 같은 위치에 마운트 해줍니다.
이후에 Plex Media Server를 기존 서버에서 대상 서버로 이동시켜 줍니다.

sudo rsync -avzhP USERNAME@기존_서버_IP:/var/lib/plexmediaserver/Library/Application\ Support/Plex\ Media\ Server /var/lib/plexmediaserver/Library/Application\ Support/

전송이 완료되면 재부팅해 줍니다.

sudo reboot                                         #서비스 시작
sudo systemctl status plexmediaserver.service       #active상태 확인

4 최종 확인

Plex 서버의 웹 gui에 로그인해서 라이브러리 스캔을 해줍니다.
마이그레이션 완료!

참고

https://support.plex.tv/articles/201370363-move-an-install-to-another-system/

gatsby로 블로그 만들기

Sun, 09 Jul 2023 00:00:00 GMT

0. 시작하기에 앞서

이 블로그는 이창희님이 만든 gatsby-starter-lavender 블로그 테마와 김성현님의 gatsby-starter-lavender를 기반으로 작성되었다.

다른 블로그의 글들을 참고하면서 항상 리눅스 커맨드의 의미에 대해서 잘 모르고 무지성으로 ctrl CV를 해왔던 것 같다. 어느 정도 심도 있는 글이 아닌 이런 튜토리얼에 가까운 글에서는 커맨드의 의미에 대해서 간단하게라도 설명하는 부분이 있었으면 좋을 것 같다고 언제나 생각해 왔다. 적어도 이번 튜토리얼에서는 그동안 생각해 왔던 것을 실천할 예정이다.

1. 환경

블로그 첫 글을 보면 알 수 있듯이 나는 집에서 proxmox가 올라간 서버를 굴리고 있다. 때문에 proxmox에서 제공하는 ubuntu-20.04-standard_20.04-1_amd64 템플릿에서 진행하였다. lxc container는 unprivileged mode로 생성하였다. 아마 대부분의 linux 환경에서 동작하는데 문제는 없을 것이라고 생각한다. 로컬서버가 있다면 활용해도 되고, 클라우드 서비스를 이용해도 된다.

이 글에서는 Vercel, Netlify, Gatsby Cloud등을 활용해서 Deploy하는 방법에 대해선 소개하지 않는다. 추후에 기회가 된다면 이 방법들도 소개해 보도록 하겠다.

2. 설치

아래 커맨드를 따라가면 된다.

adduser USERNAME                    #유저 추가
usermod -aG sudo USERNAME           #sudo 그룹에 추가(이 아래는 추가한 유저로 진행)

“USERNAME”은 유저 이름이다.

sudo apt update && sudo apt upgrade
sudo apt install git                #깃 설치
git clone YOUR_GIT_URL              #git repo에서 git clone
cd MY_BLOG_STARTER/                 #clone한 repo로 이동
sudo apt install npm                #npm 설치
sudo npm install -g n               #nodejs 버전관리 플러그인
sudo n lts                          #lts 버전
sudo n prune                        #이전 버전 삭제
sudo npm install                    #패키지 설치
sudo npm install -g npm@latest      #npm 최신 버전
sudo npm install -g gatsby-cli      #gatsby 설치
gatsby build                        #gatsby build

“YOUR_GIT_URL”은 생성한 깃 레포지토리의 주소이다.

“MY_BLOG_STARTER”는 클론된 디렉토리이다.

사용된 버전

아래와 같이 빌드되면 성공이다

빌드가 성공하면 해당 디렉토리에 public 디렉토리가 생성된다.

3. nginx 설정

웹서버로 nginx를 사용해서 정적 웹페이지를 띄워준다.

sudo apt install nginx                              #nginx 설치
sudo nano /etc/nginx/sites-available/static.site    #설정파일 편집

아래 설정을 복붙해준다.

server {
        listen       YOUR_PORT_NUMBER;
        server_name  0.0.0.0;
        charset      utf-8;
        index        index.htm index.html;
        root         YOUR_PUBLIC_FILE_PATH;
}

“YOUR_PORT_NUMBER”를 원하는 포트 번호로, YOUR_PUBLIC_FILE_PATH를 빌드된 public 디렉토리 경로로 바꿔야한다.

sudo ln -s /etc/nginx/sites-available/static.site /etc/nginx/sites-enabled/     #링크
sudo nginx -t                                                                   #테스트
sudo service nginx reload                                                       #nginx reload

ip a

위 커맨드를 쳐서 나오는 아이피 + 위에 설정한 포트 번호로 접속하면 된다.

잘 나오는 것을 볼 수 있다.

4. crontab 설정

작성한 글은 깃허브에 올라가게 된다. 다만 글을 쓸때마다 서버에 접속해서 git pull을 하고 gatsby build를 해주는 것을 번거로운 일이다. 때문에 이것을 crontab과 간단한 스크립트로 자동화하도록 하자.

sudo nano MY_BLOG_STARTER/build.sh      #build 스크립트 작성

아래 스크립트로 복붙한다.

git pull
gatsby build

sudo nano /etc/crontab                  #crontab 수정

맨 밑에 아래 명령어를 복붙한다.

*/30 * * * * USERNAME cd MY_BLOG_STARTER && bash build.sh   #30분 마다 실행된다.

“USERNAME”은 유저 이름이다.

“MY_BLOG_STARTER”는 클론된 디렉토리이다.

sudo service cron reload                #cron reload

proxmox의 CPU모니터링 그래프를 보면 30분마다 실행되고 빌드가 되면서 CPU 사용량이 올라가는 것을 볼 수 있다.

참고

https://www.wsgvet.com/staticsite/18

https://study-melody.tistory.com/45

https://happist.com/553442/%EC%84%9C%EB%B2%84%EC%97%90%EC%84%9C-%EC%9E%90%EB%8F%99-%EC%8B%A4%ED%96%89%EC%9D%84-%EA%B0%80%EB%8A%A5%EC%BC%80-%ED%95%B4%EC%A3%BC%EB%8A%94-crontab%ED%81%AC%EB%A1%A0%ED%83%AD-%EC%84%A4%EC%A0%95

블로그 첫 글

Sun, 21 May 2023 00:00:00 GMT

Dashboard : Grafana

하드웨어

Type	Name	Q’ty
CPU	Intel(R) Xeon(R) CPU E5-2696 v4 @ 2.20GHz	2ea(2 Sockets)
RAM	SAMSUNG DDR4-3200 ECC/REG (32GB)	8ea
MAINBOARD	HUANANZHI- F8D PLUS	1ea
SSD	SK hynix GOLD P31 NVMe 2TB	2ea(ZFS MIRROR)
	SK hynix GOLD P31 NVMe 500GB	2ea(ZFS STRIPE)
GPU	NVIDIA® QUADRO® P4000	1ea
	NVIDIA® QUADRO® P2000	1ea
NET card	RTL8125B 2.5G quad port NETWORK adapter	1ea
	Chelsio T540-CR Quad Port SFP+ 10GbE	1ea
	Mellanox MCX354A-FCBT CONNECTX-3	1ea
HBA card	LSI 9207-8i 6Gbs SAS HBA P20	1ea
HDD	Seagate 14TB HDD Exos X16 ST14000NM001G 14T SATA 6 Gb/s 7200RPM	8ea(6ea ZFS RAIDZ2, 2ea spare)
CASE	Fractal Design Define 7 XL Black	1ea
CPU cooler	DEEPCOOL AG620	2ea
POWER	Seasonic FOCUS GOLD GM-750 Modular	1ea
UPS	BX1600MI-GR	1ea

Virtual Machine
- Hypervisor & Host OS : PROXMOX
- Fierwall & Router : pfsense
- Proxy : HA Proxy
- VPN : OpenVPN
- DNS Resolver : unbound
- Local DNS : Pi-hole
- NAS : TureNAS Scale
- Cloud : Nextcloud
- Media Stream : Plex
- UPS control : NUT server
- Monitoring : Grafana(lm-sensors, Telegraf, InfluxDB, Prometheus, Tautulli)
- Stable Diffusion Webui
Container
- blog