[OpenStack] Nova

KH55S·2025년 11월 18일
openstack

OpenStack

목록 보기
4/9

Nova

여러 역할이 분담된 MSA로 구성되어 있다.

  • nova-api : 클라우드 사용자와 시스템 내부를 연결하는 HTTP 웹 서버
    • REST API 제공 : 사용자가 Horizon이나 CLI를 통해 보내는 HTTP 요청을 수신하는 진입점
    • 유효성 검사 : Keystone과 통신하여 사용자 인증(Token Validation)을 수행하고, 요청된 Flavor나 Image가 실제로 존재하는지, 사용자의 자원 할당량(Quota)이 충분한지 검사한다.
    • 비동기 처리 : VM 생성은 오래 걸리는 작업이므로, 요청을 Nova DB에 Build 상태로 기록하고, RabbitMQ에 작업 지시를 보낸 뒤, 사용자에게는 즉시 응답을 반환한다.
  • nova-scheduler : 리소스 배치 결정
    • Filtering : 전체 컴퓨터 노드 중에서 VM을 생성할 수 없는 노드를 걸러낸다.
      • RamFilter : 요청한 메모리 이상의 여유 공간이 있는가?
      • ComputeFilter : 해당 호스트가 현재 살아있는가?
      • ImagePropertiesFilter : 이미지가 요구하는 CPU 아키텍처나 하이퍼바이저 타입을 지원하는가?
    • Weighting : 필터링된 노드 중에서 점수를 매겨 순위를 정한다.
      • RamWeigher
        • Spreading(기본값) : 메모리가 가장 많이 남은 호스트에 높은 점수
        • Stacking : 메모리가 가장 적게 남은 호스트에 높은 점수
    • 최종적으로 선정된 컴퓨트 노드의 nova-compute에게 메세지 큐를 통해 VM 생성 명령을 전달
  • nova-conductor : 보안 관리 / 데이터베이스 접근 중재
    • nova-compute는 각 물리 서버에 설치되므로 해킹 위험이 상대적으로 높다. 만약 nova-compute가 DB에 직접 접근한다면 서버 하나가 해킹됐을 때 클라우드 전체 DB가 위험해진다.
    • nova-compute는 DB에 직접 접속하지 않고, 반드시 nova-conductor를 통해서만 DB 상태를 업데이트하거나 정보를 조회한다.
  • nova-compute : 하이퍼바이저 제어 데몬
    • nova-compute는 VM을 직접 만드는 것이 아니라, 리눅스의 libvirt 라이브러리를 통해 KVM, QEMU 같은 하이퍼바이저에게 명령한다.
    • Resource Tracker : 주기적으로 자신이 설치된 물리 서버의 상태를 확인하여, nova-scheduler에 보고한다.
    • Glance(이미지 파일을 다운로드하여 로컬 디스크에 저장) / Neutron(VM에 연결할 가상 네트워크 인터페이스(VIF)를 요청하고 연결) / Cinder(블록 스토리지(볼륨)을 연결)
    • 생명주기 관리 : VM의 생성, 종료, 재부팅 등 실제 인스턴스의 생명주기를 관리한다.

Nova Instance (Virtualization)

  • OpenStack Nova가 인스턴스를 생성할 때 사용하는 기술 스택은 ManagementLayer(Nova), Abstraction Layer(Libvirt), User Space VMM(QEMU), Kernel Space Hypervisor(KVM)로 계층화되어 있다.

    VMX Root Mode=(Host mode) / VMX Non-Root Mode(=Guest Mdoe)

    • Intel, AMD의 가상화 기술(VT-x)이 지원하는 CPU의 동작 상태
    • VMX Root Mode=(Host mode)
      • CPU의 모든 권한을 가진다
      • 물리적 하드웨어를 직접 제어한다.
      • Non-Root Mode(VM)를 생성, 시작, 멈출 수 있는 관리자 권한이 있다.
      • VM이 위험하거나 허용되지 않는 작업을 하려고 할 때(VM Exit), 이를 넘겨받아 처리한다.
    • VMX Non-Root Mode(=Guest Mdoe)
      • VM은 자신이 물리 하드웨어를 독점하고 있다고 착각하며 실행된다.
      • 대부분의 명령어는 CPU에서 직접 빠르게 실행되지만, 중요한 시스템 변경이나 하드웨어 접근 권한은 제한된다.
      • 제한된 명령을 실행하려고 하면 CPU가 이를 감지하여 강제로 멈추고(VM Exit) Root Mode로 제어권을 넘긴다.
  • KVM (Kernel-based Virtual Machine) : 커널 레벨 하이퍼바이저
    • KVM은 리눅스 커널에 적재되는 커널 모듈(kvm-amd.ko, kvm-intel.ko 등)이다. 이 모듈이 적재됨으로써 리눅스 커널은 Type-1 하이퍼바이저와 유사한 기능을 수행하게 된다.
    • 하드웨어 가상화 확장 활용
      • KVM은 IntelVT-x 또는 AMD-V와 같은 프로세서의 하드웨어 가상화 확장을 직접 제어한다.
      • 이를 통해 CPU의 실행 모드를 Host Mode(VMX Root Mode)와 Guest Mode(VMX Non-Root Mode)로 구분하여 관리한다.
    • vCPU 실행 및 스케줄링
      • KVM은 각 가상 VM의 vCPU를 리눅스의 일반적인 프로세스(또는 스레드)로 취급한다. 따라서 리눅스 커널의 기본 스케줄러가 vCPU의 스케줄링을 담당한다.
    • 메모리 관리
      • KVM은 하드웨어 지원 페이징(Intel EPT, AMD RVI)를 활용하여 게스트의 물리주소를 호스트의 물리주소로 변환하는 처리를 가속화환다.
    • /dev/kvm 인터페이스 제공
      • KVM은 사용자 공간의 프로세스가 하이퍼바이저 기능에 접근할 수 있도록 /dev/kvm 이라는 캐릭터 디바이스 인터페이스를 제공한다. 사용자 공간의 프로그램은 ioctl() 시스템 콜을 통해 이 장치를 제어한다.
  • QEMU (Quick Emulator) : 사용자 공간 VMM (Virtual Machine Monitor)
    • KVM의 빠른 성능을 빌려 실제로 VM을 띄우고 가상 장치를 연결해주는 실질적인 구동 엔진

    • 게스트 OS가 실행될 수 있는 가상 하드웨어 에뮬레이터 역할을 수행한다.
      • 주변 장치 에뮬레이션 : 마우스, 키보드, 하드 디스크 컨트롤러, 네트워크 카드 등을 소프트웨어적으로 구현하여 게스트 OS에 제공한다.
      • 다양한 아키텍처 지원 : x86 시스템 위에서 ARM 아키텍처용 OS를 돌리는 등, 다른 CPU 아키텍처를 에뮬레이션할 수도 있다.
    • 본래 프로세서 에뮬레이터이나, KVM과 함께 사용될 때는 하드웨어 가속을 지원하는 VMM 역할을 수행한다. QEMU는 사용자 공간에서 실행된다.
    • 프로세스 모델
      • OpenStack에서 생성된 각 인스턴스는 호스트 OS 상에서 하나의 qemu-kvm 프로세스로 실행된다.
    • KVM 가속 활용
      • QEMU는 CPU 명령어 실행을 직접 에뮬레이션하지 않고, /dev/kvm을 통해 KVM 커널 모듈에 명령을 전달한다. 이를 통해 CPU 실행을 네이티브 성능에 준하는 속도로 처리한다.
    • I/O 장치 에뮬레이션
      • KVM은 CPU와 메모리 가상화만 담당한다. 디스크 컨트롤러, NIC, USB 컨트롤러 등 주변장치의 에뮬레이션은 QEMU가 담당한다.
      • 게스트 OS가 I/O 작업을 요청하면, 이는 QEMU 프로세스로 전달되어 실제 호스트의 리소스로 매핑되어 처리된다.
  • Libvirt : 가상화 추상화 API 및 관리 데몬
    • 다양한 하이퍼바이저를 통합 관리하기 위한 오픈 소스 API, 데몬(libvirtd), 관리도구(virsh)의 집합
    • 추상화 계층
      • 상위 애플리케이션(Nova)이 하부의 구체적인 하이퍼바이저 구현체(QEMU CLI 명령어 등)에 종속되지 않도록 표준화된 API를 제공한다.
    • 도메인 정의
      • 가상 머신의 구성 요소(vCPU 수, 메모리 크기, 디스크 경로, 네트워크 인터페이스 등)를 구조화된 XML 포맷을 정의한다. Nova는 이 XML 파일을 생성하여 Libvirt에 전달한다.
    • 생명주기 관리
      • libvirtd 데몬은 Nova로부터 받은 XML 정의를 해석하여, 해당 설정에 맞는 복잡한 qemu-system-x86_64 명령어를 생성하고 프로세스를 실행 시킨다.
  • Nova는 QEMU를 직접 제어하지 않고, 중간 관리자인 Libvirt를 통해 명령을 내린다.
    • OpenStack Nova (지시) → Libvirt (통역/API) → QEMU-KVM (실제 수행) → Hardware
  • 사용자가 OpenStack에서 인스턴스 생성을 요청했을 때, nova-compute가 실제 VM을 구동하는 과정
  1. XML 정의 생성 (Nova -> Libvirt)
    • nova-compute 서비스는 Flavor, Imgae, Port를 조합하여 Libvirt가 이해할 수 있는 Domain XML 데이터를 생성한다.
    • Libvirt API를 호출하여 이 XML을 전달하고 도메인(VM) 생성을 요청한다.
  2. QEMU 프로세스 생성 (Libvirt -> QEMU)
    • libvirtd 데몬은 XML을 기반으로 적절한 인자를 구성하여 qemu-kvm 프로세스를 fork() 및 exec() 한다.
  3. KVM 초기화 (QEMU -> KVM)
    • 실행된 QEMU 프로세스는 open("/dev/kvm") 시스템 콜을 호출하여 KVM 커널 모듈에 접근한다.
    • ioctl(KVM_CREATE_VM) : KVM에 새로운 가상 머신 컨텍스트 생성을 요청
    • ioctl(KVM_CREATE_VCPU) : 정의된 vCPU 개수만큼 가상 CPU 컨텍스트를 생성한다.
  4. 메모리 매핑
    • QEMU는 호스트 OS로부터 메모리 공간을 할당받고, 이를 ioctl(KVM_SET_USER_MEMORY_REGION)을 통해 KVM에게 게스트의 물리 메모리로 등록한다.
  5. 실행 루프
    • QEMU는 ioctl(KVM_RUN)을 호출하여 제어권을 커널(KVM)로 넘긴다.
    • VM Entry : KVM은 CPU 레지스터를 게스트의 상태로 복원하고, CPU를 VMX Non-Root Mode(Guest Mode)로 전환하여 게스트 코드를 직접 실행한다.
  6. VM Exit 및 I/O 처리
    • 게스트 OS가 하드웨어 I/O 접근이나 특권 명령을 실행하면 VM Exit가 발생하여 CPU 제어권이 다시 호스트(KVM)로 넘어온다.
    • KVM은 VM Exit의 원인을 분석한다.
      • 단순한 CPU 상태 변경 등은 KVM이 직접 처리한다.
      • 디스크 I/O 등 주변 장치 접근이 필요한 경우, KVM은 ioctl(KVM_RUN)을 반환하여 사용자 공간의 QEMU에게 처리를 위임한다.
    • QEMU는 요청된 I/O를 에뮬레이션한 후, 다시 ioctl(KVM_RUN)을 호출하여 VM 실행을 재개한다.
profile
KH55S
이전 포스트

[OpenStack] Neutron

다음 포스트

[OpenStack] Keystone

0개의 댓글