OpenStack 네트워크 최적화: unattended-upgrades 문제 해결과 netplan으로의 전환

OpenStack NIC 설정 최적화: 리눅스 브릿지와 VETH 페어를 활용한 효과적인 네트워크 구성 방법

OpenStack 환경에서 NIC가 OVS에 할당되면 외부 접근이 차단되는 문제를 해결하기 위해 물리 NIC를 리눅스 브릿지에 연결하고 VETH 페어를 이용해 OVS와 연결한다. 브릿지에 IP와 MTU 9000을 설정하고, 스크립트와 rc.local을 통해 부팅 시 자동 적용하도록 구성한다. 이를 통해 제한된 NIC로도 Management, Private Provider, Tenant 네트워크를 안정적으로 운영할 수 있다.

/openstack-nic-opt

이전에 OpenStack을 구성하던 중에 여러 개의 네트워크 구성을 위해 rc-local을 사용해서 인터페이스에 veth와 Linux bridge를 생성하여 연결하는 작업을 했었다. 나름 잘 돌아갔고, 나쁘지 않은 방법이었다.

그렇게 잘 쓰던 중 몇 가지 문제에 직면했다. 바로 unattended-upgrades라는 프로그램과 이를 통한 netplan 초기화다.

📌

이 글에서 다루는 내용

unattended-upgrades가 뭔지, 왜 문제가 되는지

netplan이 자동으로 apply 되면서 네트워크가 초기화되는 현상

rc-local 대신 netplan으로 bridge + veth를 구성하는 방법

최종 netplan YAML 구성 예시

unattended-upgrades

Ubuntu에서 최신 보안 패치 및 기타 업데이트들을 자동으로 수행하고 시스템을 유지, 관리하는 것이 목적인 서비스다. 개인이 사용하는 workstation이나 데스크탑 시스템에서는 보안을 자동으로 관리해주니 나름 안전을 위한 프로그램이지만, 패키지 리포지토리에 관련 패키지들이 업데이트되면 언제고 시도때도없이 업데이트를 진행해버리는 문제가 있다.

🤔

unattended-upgrades의 동작 원리

/etc/apt/apt.conf.d/50unattended-upgrades 설정 파일에 따라 동작한다

기본적으로 보안 업데이트(security)만 자동 적용되도록 설정되어 있다

systemd 타이머(apt-daily-upgrade.timer)에 의해 주기적으로 실행된다

업데이트 로그는 /var/log/unattended-upgrades/ 에서 확인할 수 있다

서버 환경에서는 이 서비스가 꽤 골칫거리가 될 수 있다. 예를 들어, apt 락이 걸려서 수동으로 패키지를 설치하려고 하면 "Waiting for unattended-upgr to exit" 같은 메시지가 뜨면서 대기해야 하는 상황이 발생하기도 한다. ~~이거 때문에 삽질한 적 한두 번이 아니다~~

그래서 뭐가 문제인가?

여기에 추가로 network 관련 보안 조치들이 업데이트되거나 network 관련 패키지가 업데이트되면 netplan이 자동으로 apply 되는데, 이게 /etc/netplan/**.yaml와 같은 파일들의 내용이 자동으로 적용된다.

문제라면 우리의 netplan에는 최소한의 네트워크 통신만을 설정하고, 나머지를 rc-local로 ip 명령어를 사용하여 직접 설정하였다는 것이다. netplan이 다시 apply 되면 rc-local로 설정한 내용들이 전부 날아가버린다.

⚠️

실제로 일어나는 일

unattended-upgrades가 네트워크 관련 패키지를 업데이트한다

업데이트 후 netplan apply가 자동으로 트리거된다

netplan에는 최소 설정만 있으므로, rc-local로 만들어둔 bridge, veth, 라우팅 테이블이 전부 초기화된다

서버 접속이 끊긴다 😭

서버실에 직접 가서 복구해야 한다

이 문제를 해결하기 위해 찾던 중 netplan이 모든 걸 다 할 수 있다는 사실을 알아버렸다. 젠장

unattended-upgrades 비활성화는?

물론 unattended-upgrades를 비활성화하는 방법도 있다.

# 서비스 비활성화
sudo systemctl stop unattended-upgrades
sudo systemctl disable unattended-upgrades

# 또는 패키지 자체를 제거
sudo apt remove unattended-upgrades

하지만 보안 업데이트를 완전히 끄는 건 서버 운영 관점에서 그리 좋은 선택은 아니다. 특히 외부에 노출된 OpenStack 환경이라면 더더욱. 그래서 근본적인 해결책으로 netplan 자체에서 모든 네트워크 설정을 관리하기로 했다. netplan이 apply 되더라도 우리가 원하는 설정이 그대로 적용되니까.

netplan으로 전환하기

YAML configuration

Top-level configuration structure: The general structure of a Netplan YAML file is shown below. version(number) Defines what version of the configuration format is used. The only value supported is...

https://netplan.readthedocs.io/en/stable/netplan-yaml/#properties-for-device-type-virtual-ethernets

위 링크는 netplan yaml을 설정할 수 있는 공식 문서인데 이걸 참고하면 진행 가능하다.

💡

netplan의 virtual-ethernets 지원 히스토리

원래 netplan에서는 veth 디바이스를 설정하는 것이 불가능했다. 오래전부터 커뮤니티에서 요청이 있었지만, netplan 0.107 버전부터 virtual-ethernets 키가 추가되면서 드디어 veth 페어를 YAML로 정의할 수 있게 되었다. 🚀

Ubuntu 24.04 이상을 사용하고 있다면 기본 탑재된 netplan 버전으로 사용 가능하다.

기존에는 rc-local 스크립트에서 ip link add, brctl addbr 같은 명령어로 직접 설정했지만, 이제는 netplan YAML 하나로 깔끔하게 관리할 수 있다.

bridges

Linux bridge는 어떤 인터페이스에 물릴지와 물린 인터페이스의 아이피 정보들을 적어주면 된다.

network:
  version: 2
  ethernets:
    enp2s0:
      mtu: 9000
      dhcp4: false
  bridges:
    mybr0:
      interfaces:
        - enp2s0
      mtu: 9000
      addresses:
      - "172.30.0.11/16"
      nameservers:
        addresses:
        - 8.8.8.8
        search: []
      routes:
      - to: "default"
        via: "172.30.0.1"

사실상 enp2s0에 적어두었던 내용을 그대로 mybr0로 옮기고 interfaces만 추가해주는 것과 같다고 볼 수 있다.

📝

bridge 설정 시 주의사항

물리 인터페이스(enp2s0)에는 dhcp4: false만 설정하고, IP는 브릿지에 할당해야 한다

mtu는 물리 인터페이스와 브릿지 모두 동일하게 설정해야 한다. 불일치하면 패킷 드롭이 발생할 수 있다

nameservers와 routes도 물리 인터페이스가 아닌 브릿지 쪽에 설정한다. 브릿지가 실제 통신의 진입점이기 때문이다

virtual-ethernets

virtual-ethernets 설정을 통해 veth0, veth1을 설정할 수 있고, bridge의 interfaces 옵션으로 연결할 수 있다.

network:
  version: 2
  bridges:
    mybr0:
      interfaces:
        - veth0
  virtual-ethernets:
    veth0:
      peer: veth1
    veth1:
      peer: veth0

💡

veth 페어 설정 시 포인트

veth 페어는 양쪽 모두 정의해야 한다. veth0만 정의하고 veth1을 생략하면 동작하지 않는다

peer 값은 반드시 서로를 가리켜야 한다 (veth0 → veth1, veth1 → veth0)

기존 rc-local에서 ip link add veth0 type veth peer name veth1 했던 것과 동일한 효과다

기존에는 ip 명령어로 veth를 생성하고, brctl addif나 ip link set master로 bridge에 연결하는 과정을 스크립트로 작성해야 했다. 이제는 YAML에 선언만 해두면 netplan이 알아서 처리해준다. ~~세상 참 좋아졌다~~

최종 YAML 구성

아래는 최종본이다.

vlans는 컨트롤 노드에서 Octavia를 사용하기 위해 설정한 건데, 지금으로서는 무시해도 좋다.

network:
  version: 2
  ethernets:
    eno1:
      dhcp4: false
    eno2:
      dhcp4: false
    enp2s0:
      mtu: 9000
      dhcp4: false
  bridges:
    mybr0:
      interfaces:
        - enp2s0
        - veth0
      mtu: 9000
      addresses:
      - "172.30.0.11/16"
      nameservers:
        addresses:
        - 8.8.8.8
        search: []
      routes:
      - to: "default"
        via: "172.30.0.1"
  virtual-ethernets:
    veth0:
      peer: veth1
    veth1:
      peer: veth0
  vlans:
    eno1.210:
      id: 210
      link: eno1
      addresses:
        - 172.32.0.1/16

📝

최종 구성 해설

ethernets: 물리 NIC 3개를 정의. IP는 할당하지 않고 dhcp4: false로 설정

bridges: mybr0 브릿지에 물리 NIC(enp2s0)와 veth 페어의 한쪽(veth0)을 연결

virtual-ethernets: veth 페어 생성. veth1은 OVS에서 수동으로 연결

vlans: Octavia용 VLAN 인터페이스 (선택사항)

적용 방법

# YAML 파일 작성
sudo vi /etc/netplan/01-network-config.yaml

# 문법 확인 (적용 전 반드시!)
sudo netplan try

# 문제 없으면 적용
sudo netplan apply

# 적용 확인
ip addr show
bridge link show

⚠️

netplan try를 반드시 먼저 실행하자

netplan try는 설정을 임시로 적용한 뒤 120초 내에 확인하지 않으면 자동으로 롤백해준다. 원격으로 작업 중이라면 이걸 먼저 실행하는 것이 정신 건강에 이롭다. 잘못된 설정으로 서버 접속이 끊겨도 2분만 기다리면 원래대로 돌아온다.

rc-local에서 남은 작업

netplan으로 bridge와 veth 설정을 옮겼지만, OVS 브릿지에 veth1을 연결하는 작업은 여전히 rc-local이나 별도 스크립트에서 처리해야 한다. netplan은 OVS 포트 추가를 직접 관리하지 않기 때문이다.

#!/bin/bash
# /etc/rc.local (OVS 연결 부분만 남김)

OVS_BR="br-vpn"
VETH1="veth1"

# OVS 브릿지에 veth1 연결
if ovs-vsctl br-exists $OVS_BR; then
    ovs-vsctl --may-exist add-port $OVS_BR $VETH1
else
    ovs-vsctl add-br $OVS_BR
    ovs-vsctl add-port $OVS_BR $VETH1
fi

echo "OVS setup complete."

이전에 비하면 rc-local의 역할이 대폭 줄어들었다. netplan이 네트워크 기본 설정을 책임지고, rc-local은 OVS 연동만 담당하는 깔끔한 구조가 되었다. ~~삽질의 결과물 치고는 나쁘지 않다~~

핵심 정리

✅ 문제: unattended-upgrades가 네트워크 패키지 업데이트 시 netplan apply를 자동 트리거하여 rc-local 설정이 초기화됨

✅ 해결책: rc-local 대신 netplan YAML에서 bridge + veth를 직접 정의

✅ bridges: 물리 NIC를 브릿지에 연결하고, IP는 브릿지에 할당

✅ virtual-ethernets: netplan 0.107+에서 지원. 양쪽 peer를 모두 정의해야 함

✅ OVS 연동: veth1을 OVS에 연결하는 부분만 rc-local에 남김

✅ 안전한 적용: netplan try로 먼저 테스트 후 netplan apply

주의사항

⚠️ netplan 버전 확인: virtual-ethernets는 netplan 0.107 이상에서만 지원된다. netplan --version으로 확인하자

⚠️ MTU 일관성: 물리 NIC와 bridge의 MTU가 다르면 패킷 드롭이 발생할 수 있다

⚠️ 원격 작업 시 netplan try 필수: 잘못된 설정은 서버 접속 불가로 이어질 수 있다

⚠️ OVS 포트 확인: netplan apply 이후 OVS 포트 연결이 정상인지 ovs-vsctl show로 확인하자

⚠️ unattended-upgrades 비활성화는 비추: 보안 업데이트를 끄는 것보다 netplan으로 설정을 통합하는 것이 올바른 해결책이다

참고 자료

Netplan YAML Configuration (공식 문서)

Ubuntu Automatic Updates 공식 문서

Linux Bridge 공식 문서

Open vSwitch 공식 문서