[OpenStack 기반 CSP 구축 #3] 첫 번째 VM 생성과 KVM·Cinder·Neutron 트러블슈팅

Об этом предложении

지난 포스팅에서는 Kolla-Ansible을 이용해 여러 대의 베어메탈 서버 위에 OpenStack을 배포하고, Horizon Dashboard까지 접근하는 데 성공했다. 하지만 클라우드 플랫폼에서 가장 중요한 것은 결국 이 질문이다. 사용자가 실제 가상 머신을 생성할 수 있는가? 이번에는 OpenStack에서 사용할 Image, Flavor, Network를 구성하고 실제 첫 번째 VM을 생성해보았다. 물론 한 번에 성공하지는 않았다. 오히려 이 과정에서 KVM, Cinder, Neutron, Floating IP까지 OpenStack 내부 구조를 본격적으로 이해하게 되었다. 1. OpenStack 초기 리소스 생성 Kolla-Ansible에는 테스트 환경을 빠르게 생성하기 위한 init-runonce 스크립트가 포함되어 있다. 먼저 OpenStack 관리자 환경을 불러온다. source /etc/kolla/admin-openrc.sh 그리고 다음 스크립트를 실행했다. /home/return/openstack-venv/share/kolla-ansible/init-runonce 이 스크립트는 OpenStack 테스트에 필요한 기본 리소스들을 자동으로 생성해준다. CirrOS 이미지 Demo Network Demo Subnet Router Public Network Security Group Rule SSH Keypair Flavor CirrOS는 OpenStack 테스트에서 많이 사용하는 초경량 Linux 이미지 다. 일반 Ubuntu 이미지보다 훨씬 작기 때문에 VM 생성과 네트워크 테스트를 빠르게 진행할 수 있다. 2. Image와 Network 생성 확인 스크립트를 실행한 후 이미지 목록을 확인했다. openstack image list 이미지 목록에는 cirros 와 ubuntu-22.04 가 등록되어 있었고, 상태는 다음과 같았다. cirros active ubuntu-22.04 active 네트워크도 확인했다. openstack network list 이번 환경에서는 내부 VM 통신용 네트워크와 외부 네트워크를 다음과 같이 구성했다. 네트워크 역할 demo-net 내부 VM 통신용 네트워크 public1 외부 네트워크 Router 역시 정상적으로 생성되었는지 확인했다. openstack router list 이제 최소한 VM을 생성할 준비는 끝난 셈이다. 3. Horizon에서 첫 번째 Instance 생성 Horizon Dashboard에서 직접 VM을 생성해보았다. 설정은 최대한 단순하게 구성했다. 항목 설정값 Instance Name test-first-vm Image cirros Flavor m1.tiny Network demo-net 설정을 마친 뒤 Instance 시작 버튼을 눌렀다. 여기까지만 보면 성공적으로 첫 VM을 만든 것처럼 보였다. 하지만 잠시 후 Instance 상태가 다음과 같이 변경되었다. ERROR 4. 첫 번째 문제: Nova Scheduling 실패 가장 먼저 Instance 상세 정보를 확인했다. openstack server show test-first-vm 여기서 Host 정보가 정상적으로 할당되지 않은 것을 확인했다. VM을 실행할 Compute Node가 배정되지 않은 상태였기 때문에, Nova의 스케줄링과 Compute Node 상태부터 확인하기로 했다. CPU 가상화 지원 확인 문제를 좁혀가기 위해 각 Compute Node의 하드웨어 가상화 지원 여부를 확인했다. egrep -c '(vmx|svm)' /proc/cpuinfo 확인한 노드에서는 다음 결과가 나왔다. 8 CPU 가상화 플래그는 확인할 수 있었다. KVM Device 확인 다음으로 확인한 것은 /dev/kvm 이었다. ls -l /dev/kvm 여기서 문제를 발견했다. KVM Device는 존재했지만, Nova Compute 컨테이너에서 해당 Device에 접근하는 데 권한 문제가 있었다. 5. KVM Device 권한 수정 권한 문제인지 확인하기 위한 테스트로 /dev/kvm 의 접근 권한을 임시로 변경했다. sudo chmod 666 /dev/kvm 그리고 Nova Compute 컨테이너를 재시작했다. sudo docker restart nova_compute 기존 ERROR 상태의 Instance는 삭제했다. openstack server delete test-first-vm 이후 다시 VM을 생성했다. openstack server create \ --flavor m1.tiny \ --image cirros \ --network demo-net \ test-final-vm 상태를 확인했다. openstack server list 이번에는 기다리던 상태가 나타났다. ACTIVE 드디어 우리가 직접 구축한 Compute Node에서 실제 VM이 실행되기 시작했다. 6. 그런데 또 ERROR가 발생했다 한 번 Instance 생성에 성공했다고 모든 문제가 해결된 것은 아니었다. 계속 새로운 VM을 생성하다 보니 다시 ERROR 상태가 발생했다. 이번에는 Network와 Storage 쪽도 확인해야 했다. 특히 Cinder Volume을 사용하는 과정에서 Volume이 error 상태로 빠지는 문제 가 있었다. 초기 환경에서 Cinder Storage Backend가 완전히 안정화되지 않은 상태였고, 이 문제가 VM 생성 과정에도 영향을 주고 있었다. Volume을 사용하지 않고 부팅하기 우선 VM 자체 기능을 검증하는 것이 중요했다. Cinder Volume을 사용하지 않고 이미지에서 바로 부팅하는 방식으로 우회했다. openstack server create \ --flavor m1.tiny \ --image cirros \ --network demo-net \ test-no-volume-vm 결과는 성공이었다. Status: ACTIVE 내부 IP도 10.0.0.x 형태로 정상적으로 할당되었다. Nova Compute에서 이미지를 이용한 VM 생성은 가능했다. 이를 통해 Volume을 사용하는 경로, 특히 Cinder 쪽으로 문제 범위를 좁힐 수 있었다. Cinder 문제 자체를 해결한 것은 아니지만, VM 생성 기능과 Volume 관련 문제를 나누어 확인할 수 있었다. 7. Floating IP 연결 VM은 만들어졌지만, 현재 할당된 주소는 OpenStack 내부에서 사용하는 Private IP였다. 내 노트북에서 직접 SSH 접속하려면 외부 네트워크와 연결해야 한다. OpenStack에서는 이러한 역할을 Floating IP 가 담당한다. Floating IP 생성 및 연결 외부 네트워크인 public1 에서 Floating IP를 생성했다. openstack floating ip create public1 생성된 IP를 Instance에 연결했다. openstack server add floating ip test-no-volume-vm <FLOATING_IP> <FLOATING_IP> 에는 실제로 생성된 Floating IP를 입력한다. Security Group 설정 SSH와 ICMP를 허용하기 위해 Instance에 적용된 Security Group에 규칙을 추가했다. 먼저 ICMP를 허용했다. openstack security group rule create \ --proto icmp \ <SECURITY_GROUP_ID> SSH 접속을 위한 TCP 22번 포트도 허용했다. openstack security group rule create \ --proto tcp \ --dst-port 22 \ <SECURITY_GROUP_ID> 여기서는 Security Group 이름이 중복되는 문제가 있어, 이름 대신 ID를 직접 지정 했다. 8. OpenStack 내부에서는 되는데 Host에서 접근이 안 된다 Floating IP까지 연결했지만 또 문제가 발생했다. OpenStack 내부에서는 Network Agent도 정상이고 Instance도 실행되고 있었지만, Ubuntu Host에서 Floating IP 대역으로 통신할 수 없었다. OpenStack 내부 가상 네트워크와 실제 Host Network 사이의 연결을 확인해야 했다. External Bridge 활성화 먼저 External Bridge인 br-ex 상태를 확인하고 다시 활성화했다. sudo ip link set br-ex up 외부 네트워크 Route 추가 이번 환경에서 사용한 외부 네트워크 대역은 10.0.2.0/24 였다. 해당 대역으로 향하는 Route를 추가했다. sudo ip route add 10.0.2.0/24 dev br-ex scope link br-ex에 IP 할당 Host가 해당 네트워크에서 통신할 수 있도록 br-ex 에도 IP를 부여했다. sudo ip addr add <BR_EX_IP>/24 dev br-ex <BR_EX_IP> 에는 10.0.2.0/24 대역에서 다른 장비나 Floating IP와 중복되지 않는 주소를 사용했다. 이후 Host에서 Floating IP로 ping을 보내자 정상적으로 응답이 돌아왔다. 9. 최종 SSH 접속 마지막으로 내 노트북에서 직접 VM으로 SSH 접속을 시도했다. ssh cirros@<FLOATING_IP> CirrOS 기본 인증 정보로 로그인하자 셸 프롬프트가 나타났다. $ 다음 명령어도 정상적으로 동작했다. ls 이 순간 우리가 만든 환경에서는 VM 생성부터 외부 클라이언트의 SSH 접속까지 가능해졌다. 직접 구축한 인프라에서 VM을 생성하고, 네트워크를 통해 접속할 수 있는 작은 CSP가 된 것이다. 10. OpenStack을 직접 구성하면서 느낀 점 퍼블릭 클라우드를 사용할 때는 EC2 Instance 하나를 만드는 과정이 굉장히 간단하다. 버튼 몇 개를 누르면 VM, Network, Security Group, Public IP, Storage가 연결된다. 하지만 OpenStack을 직접 구축하면서, 그 뒤에서 여러 컴포넌트가 어떤 역할을 하는지 하나씩 확인할 수 있었다. 컴포넌트 역할 Nova VM을 실행할 Compute Resource를 선택하고 인스턴스 생성·관리를 담당한다. Neutron 가상 네트워크와 연결을 관리한다. Open vSwitch 가상 스위치로서 패킷을 전달한다. Cinder VM에서 사용할 블록 스토리지를 제공한다. Security Group VM에 적용되는 네트워크 접근 규칙을 관리한다. Floating IP 외부에서 VM의 내부 IP로 접근할 수 있도록 연결한다. 평소 AWS에서 너무 당연하게 사용하던 기능들이 실제로는 여러 인프라 컴포넌트의 협업으로 만들어진다 는 것을 체감할 수 있었다. 🔜 다음 포스팅: OpenStack 네트워크가 전부 죽었다 첫 VM 생성과 SSH 연결에는 성공했지만, 얼마 지나지 않아 더 큰 문제가 발생했다. 서버를 재부팅한 이후 Open vSwitch가 정상적으로 올라오지 않았다. 이후 네트워크 설정을 수정하는 과정에서 메인 Controller Node의 인터넷 연결까지 완전히 끊어졌다. 다음 포스팅에서는 아래 과정을 다뤄보려고 한다. OVSDB stale pidfile 문제 Open vSwitch 복구 br-ex 와 물리 NIC의 관계 Controller Node 인터넷 연결 장애 Netplan + OVS 영구 설정