[OpenStack 기반 CSP 구축 #4] OVS 장애 복구와 br-ex 네트워크 영구 설정

About this offer

지난 글에서는 OpenStack 인스턴스를 생성하고 Floating IP를 연결해 SSH 접속을 확인했다. 이후 서버 재부팅과 네트워크 설정 변경 과정에서 두 가지 문제가 발생했다. Open vSwitch가 정상적으로 시작되지 않아 일부 Neutron Agent가 Down 상태로 표시되었다. Controller 노드의 IP와 경로 설정이 누락되어 호스트 자체의 외부 통신이 끊어졌다. 이번 글에서는 두 문제의 원인을 구분해 복구하고, 재부팅 이후에도 네트워크 설정이 유지되도록 Netplan에 반영한 과정을 정리한다. 1. 장애 환경과 증상 문제가 발생한 서버는 Controller 역할을 담당하는 return-compute-1 이었다. 항목 설정 호스트 OS Ubuntu Server 24.04 배포 방식 Kolla-Ansible 네트워크 백엔드 Open vSwitch 물리 NIC enp1s0 외부 브리지 br-ex 호스트 IP 192.168.0.3/24 기본 게이트웨이 192.168.0.1 먼저 재부팅 이후 Neutron Agent 상태를 확인했다. openstack network agent list 일부 Agent가 Down 상태로 표시되었다. Open vSwitch 컨테이너 로그를 확인한 결과, 종료된 프로세스의 PID 파일이 남아 OVSDB 프로세스가 정상적으로 시작되지 못하고 있었다. 이후 네트워크 설정을 수정하는 과정에서는 호스트의 외부 통신도 끊어졌다. 이 문제는 OVS 프로세스 기동 문제와 별개로, 호스트 IP와 기본 경로 설정을 확인해야 했다. 2. OVSDB의 stale PID 파일 정리 OVSDB 기동을 막고 있던 원인은 이전 실행에서 남은 PID 파일이었다. 해당 파일이 실행 중인 프로세스의 PID 파일이 아니라는 것을 확인한 뒤 정리해야 한다. 아래는 당시 복구에 사용한 명령어다. 호스트에 남아 있던 Open vSwitch PID 파일을 제거했다. sudo rm -f /run/openvswitch/*.pid 컨테이너 내부의 OVSDB PID 파일도 정리했다. sudo docker exec -u root openvswitch_db \ rm -f /var/run/openvswitch/ovsdb-server.pid 이후 Open vSwitch 관련 컨테이너를 재시작했다. sudo docker restart openvswitch_db openvswitch_vswitchd 필요한 OVSDB Remote 연결 설정을 복구한 뒤, Agent 상태를 다시 확인했다. openstack network agent list Agent가 모두 정상 상태로 돌아온 것을 확인했다. 다만 Agent 상태가 정상이라는 것만으로 호스트의 인터넷 연결까지 확인된 것은 아니다. 호스트의 IP, 라우팅, DNS는 별도로 점검했다. 3. 호스트 통신 장애 원인: IP와 기본 경로 누락 Controller의 외부 통신이 끊긴 시점에는 기존 물리 NIC인 enp1s0 의 IP 설정이 제거되어 있었다. 물리 NIC를 br-ex 에 연결하는 과정에서 호스트가 사용할 IP와 기본 경로가 브리지 쪽에 제대로 구성되지 않은 것이 문제였다. 이 환경에서 br-ex의 역할 물리 NIC에 직접 IP를 설정하는 구성에서는 enp1s0 이 호스트 주소를 가진다. enp1s0 └─ 192.168.0.3/24 이번 환경에서는 하나의 물리 NIC를 호스트 통신과 OpenStack 외부 네트워크에 함께 사용했다. 따라서 물리 NIC를 OVS 브리지의 포트로 연결하고, 호스트 IP를 br-ex 에 설정하는 형태로 구성했다. 외부 라우터: 192.168.0.1 │ 물리 NIC: enp1s0 │ OVS 브리지: br-ex ├─ 호스트 IP: 192.168.0.3/24 └─ OpenStack 외부 네트워크 연결 이 구조에서 enp1s0 은 물리적인 패킷 송수신을 담당하고, 호스트의 IP 통신은 br-ex 에 설정한 주소를 사용한다. 따라서 물리 NIC의 IP를 제거하는 것만으로 전환이 완료되는 것은 아니다. 브리지 연결, 호스트 IP, 기본 경로가 함께 구성되어야 한다. 4. br-ex에 호스트 네트워크 복구 우선 통신을 복구하기 위해 실행 중인 네트워크에 설정을 직접 적용했다. 물리 NIC 연결 enp1s0 을 br-ex 의 포트로 연결했다. sudo docker exec -it openvswitch_vswitchd \ ovs-vsctl add-port br-ex enp1s0 호스트 IP와 기본 경로 설정 기존 호스트 IP를 br-ex 에 할당했다. sudo ip addr add 192.168.0.3/24 dev br-ex 기본 게이트웨이도 br-ex 를 통해 접근하도록 설정했다. sudo ip route add default via 192.168.0.1 dev br-ex 이 명령어들은 당시 누락된 설정을 복구하기 위해 사용했다. 이미 동일한 포트, 주소, 경로가 존재하는 상태에서 반복 실행할 필요는 없다. 통신 확인 먼저 같은 네트워크에 있는 게이트웨이로 통신을 확인했다. ping 192.168.0.1 게이트웨이 응답을 확인했고, 외부 IP로의 통신도 복구되었다. 하지만 도메인을 사용하는 통신은 여전히 실패했다. ping google.com IP 통신과 DNS 문제를 구분하기 위해 이름 해석 설정을 확인했다. DNS 설정도 누락되어 있어 Google DNS와 Cloudflare DNS를 다시 지정하고 systemd-resolved 를 재시작했다. 이후 도메인을 통한 통신도 정상적으로 동작했다. 5. Netplan으로 설정 영구화 ip addr add 와 ip route add 로 적용한 설정은 실행 중인 네트워크에만 반영된다. 재부팅 이후에도 유지하려면 별도의 영구 설정이 필요하다. 이번 환경에서는 Netplan에 물리 NIC와 OVS 브리지 구성을 정의했다. Open vSwitch 패키지 설치 호스트에서 Netplan의 OVS 구성을 적용할 수 있도록 다음 패키지를 설치했다. sudo apt update sudo apt install openvswitch-switch -y 이 과정은 당시 환경에 적용한 구성이다. Kolla의 OVS 컨테이너도 함께 사용하는 환경이므로, 호스트 서비스와 컨테이너의 OVS 관리 범위는 구분해서 확인할 필요가 있다. Netplan 설정 /etc/netplan/00-installer-config.yaml 을 다음과 같이 수정했다. network: version: 2 renderer: networkd ethernets: enp1s0: dhcp4: false bridges: br-ex: interfaces: - enp1s0 addresses: - 192.168.0.3/24 routes: - to: default via: 192.168.0.1 nameservers: addresses: - 8.8.8.8 - 1.1.1.1 openvswitch: {} 설정의 핵심은 다음과 같다. 항목 적용 내용 enp1s0 DHCP를 사용하지 않고 br-ex 의 포트로 연결 br-ex 호스트 IP 192.168.0.3/24 할당 기본 경로 192.168.0.1 을 게이트웨이로 사용 DNS 8.8.8.8 , 1.1.1.1 사용 openvswitch: {} 해당 브리지를 OVS 브리지로 구성 호스트의 주소와 기본 경로, DNS를 br-ex 기준으로 모아 정의했다. 6. 설정 적용 및 재부팅 검증 Netplan 설정을 적용했다. sudo netplan apply 호스트의 관리 네트워크 자체를 변경하는 작업이므로, SSH 연결이 끊길 경우 사용할 콘솔 접근 수단이 필요하다. 적용 후에는 IP와 경로를 확인했다. ip addr ip route 확인한 항목은 다음과 같다. 192.168.0.3/24 가 br-ex 에 할당되어 있는지 기본 경로가 192.168.0.1 을 향하는지 기본 경로의 인터페이스가 br-ex 인지 외부 IP와 도메인으로 통신할 수 있는지 이후 서버를 재부팅하고 다시 SSH로 접속했다. 재부팅 뒤에도 호스트 IP와 기본 경로가 유지되었고, 인터넷 연결도 정상적으로 동작했다. 수동으로 IP와 경로를 추가하지 않아도 네트워크가 구성되는 것을 확인했다. 7. 별도로 확인한 Cinder 재부팅 문제 네트워크 복구와 별개로 Cinder에서도 재부팅 이후 설정이 유지되지 않는 문제가 있었다. 당시 테스트용 Cinder 스토리지는 이미지 파일을 Loop Device에 연결하고, 그 위에 Volume Group을 구성하는 방식이었다. /var/lib/cinder-volumes.img │ /dev/loop10 │ VG: cinder-volumes 호스트 재부팅 이후 Loop Device 연결이 복원되지 않아, Cinder가 사용할 스토리지를 다시 활성화해야 했다. 당시 사용하던 Loop Device에 이미지 파일을 연결했다. sudo losetup /dev/loop10 /var/lib/cinder-volumes.img Volume Group을 활성화했다. sudo vgchange -ay cinder-volumes 이후 Cinder 관련 컨테이너를 재시작했다. sudo docker restart \ cinder_volume \ cinder_backup \ cinder_api \ cinder_scheduler 이 작업은 재부팅 후 스토리지를 수동으로 복구한 것이며, 자동 복원까지 구성한 것은 아니다. 파일 기반 Loop Device는 테스트 용도로 사용했고, 이후에는 실제 Block Device나 별도 Storage Node를 사용하는 방향으로 개선할 예정이다. 8. 복구 결과와 남은 과제 이번 장애는 다음과 같이 구분해 처리했다. 문제 확인한 원인 처리 OVSDB 기동 실패 종료된 프로세스의 PID 파일 잔존 PID 파일 정리 및 OVS 컨테이너 재시작 호스트 외부 통신 실패 브리지 전환 과정에서 IP와 기본 경로 누락 br-ex 에 IP와 경로 구성 도메인 통신 실패 DNS 설정 누락 DNS 설정 복구 재부팅 후 네트워크 설정 유실 실행 중인 네트워크에만 설정 적용 Netplan에 영구 설정 반영 재부팅 후 Cinder 스토리지 사용 불가 Loop Device 연결 미복원 Loop Device 연결 및 VG 수동 활성화 네트워크는 Netplan 반영 후 재부팅까지 확인했다. Cinder의 파일 기반 스토리지는 수동 복구 상태로 남아 있어 추가 개선이 필요하다. 이번 작업에서는 Neutron Agent 상태, 호스트의 IP와 경로, DNS, 재부팅 후 설정 유지 여부를 각각 확인하는 것 이 중요했다. 한 계층이 정상이어도 다른 계층의 설정이 누락되면 전체 통신은 실패할 수 있었다. 다음 글: Return Cloud Platform 백엔드 설계 인프라의 기본 동작을 확인한 이후에는 사용자가 OpenStack을 직접 다루지 않고도 VM을 생성하고 접속할 수 있도록 서비스 계층을 설계했다. 다음 글에서는 Return Cloud Platform의 요구사항과 백엔드 구조를 정리할 예정이다. VM 생성 및 삭제 사용자 인증 리소스 관리 Go 백엔드 구조 PostgreSQL 데이터 모델과 ERD