Nova 시스템 아키텍처

1 개요

Nova System Architecture

노바 시스템 아키텍처

https://docs.openstack.org/nova/2024.1/admin/architecture.html

---

Nova는 다양한 기능을 수행하는 여러 서버 프로세스로 구성되어 있습니다. 사용자 인터페이스는 REST API이며, 내부적으로 Nova 컴포넌트는 RPC 메시지 전달 메커니즘을 통해 통신합니다.

API 서버는 REST 요청을 처리하며, 일반적으로 데이터베이스 읽기/쓰기 작업을 수행하고, 선택적으로 다른 Nova 서비스에 RPC 메시지를 전송하며, REST 호출에 대한 응답을 생성합니다. RPC 메시징은 메시지 큐 위에 추상화된 oslo.messaging 라이브러리를 통해 수행됩니다. Nova는 메시지 기반의 "shared nothing" 아키텍처를 사용하며, 주요 Nova 컴포넌트 대부분은 여러 서버에서 실행될 수 있으며, RPC 메시지를 수신하는 관리자를 가지고 있습니다. 주요 예외는 컴퓨트 서비스로, VMware 또는 Ironic 드라이버를 사용하는 경우를 제외하고는 관리하는 하이퍼바이저에서 단일 프로세스로 실행됩니다. 관리자에게는 선택적으로 주기적인 작업도 있습니다. 우리의 RPC 시스템에 대한 자세한 내용은 AMQP와 Nova를 참조하십시오.

Nova는 전통적인 SQL 데이터베이스를 사용하여 정보를 저장합니다. 이러한 데이터베이스는 여러 컴포넌트 간에 논리적으로 공유됩니다. 업그레이드를 용이하게 하기 위해 데이터베이스는 객체 계층을 통해 액세스되며, 이를 통해 업그레이드된 제어 플레인에서도 이전 릴리스에서 실행되는 컴퓨트 노드와 통신할 수 있습니다. 이를 가능하게 하기 위해 컴퓨트 노드에서 실행되는 서비스는 데이터베이스 요청을 RPC를 통해 중앙 관리자(컨덕터)로 프록시합니다.

Nova 배포를 수평적으로 확장하기 위해 셀(cell)이라는 배포 샤딩 개념을 사용합니다. 모든 배포에는 최소 하나의 셀이 포함되어 있습니다. 자세한 내용은 셀(v2)을 참조하십시오.

2 컴포넌트

다음은 일반적인 Nova 배포의 핵심 컴포넌트에 대한 유용한 설명입니다.

• DB: 데이터 저장을 위한 SQL 데이터베이스.
• API: HTTP 요청을 수신하고 명령어를 변환하며 oslo.messaging 큐 또는 HTTP를 통해 다른 컴포넌트와 통신하는 컴포넌트.
• 스케줄러: 각 인스턴스를 어느 호스트에 할당할지 결정.
• 컴퓨트: 하이퍼바이저와 가상 머신과의 통신을 관리.
• 컨덕터: 조정이 필요한 요청(빌드/크기조정)을 처리하고, 데이터베이스 프록시로 작동하거나 객체 변환을 처리.
• 플레이스먼트: 리소스 제공자 인벤토리와 사용량을 추적.

모든 서비스는 수평적으로 확장가능하도록 설계되었으나, 특히 컴퓨트는 다른 것들보다 훨씬 많이 배치해야 합니다.

3 하이퍼바이저

Nova는 API 서버를 통해 하이퍼바이저를 제어합니다. 최적의 하이퍼바이저를 선택하는 것은 예산, 자원 제약, 지원되는 기능 및 필요한 기술 사양 등을 고려해야 하기 때문에 어려울 수 있습니다. 그러나 대부분의 OpenStack 개발은 KVM 기반 하이퍼바이저를 사용하는 시스템에서 이루어집니다. 다양한 하이퍼바이저의 기능 및 지원에 대한 자세한 목록은 기능 지원 매트릭스를 참조하십시오.

또한, 여러 가용성 영역에 다양한 하이퍼바이저를 사용하여 클라우드를 오케스트레이션할 수 있습니다. Nova는 다음 하이퍼바이저를 지원합니다:

• 베어메탈
• 커널 기반 가상 머신 (KVM)
• 리눅스 컨테이너 (LXC)
• 퀵 에뮬레이터 (QEMU)
• Virtuozzo
• VMware vSphere
• zVM

하이퍼바이저에 대한 자세한 내용은 Nova 설정 참조의 하이퍼바이저 섹션을 참조하십시오.

4 프로젝트, 사용자, 역할

Nova를 사용하려면 먼저 Identity 서비스를 통해 사용자를 생성해야 합니다.

Nova 시스템은 공유 시스템에서 프로젝트 형태로 다양한 소비자들이 사용하고, 역할 기반 접근 권한 할당을 통해 사용될 수 있도록 설계되었습니다. 역할은 사용자가 수행할 수 있는 작업을 제어합니다.

프로젝트는 Nova 서비스 내에서 주요 조직 구조를 형성하는 독립된 자원 컨테이너입니다. 프로젝트는 일반적으로 네트워크, 볼륨, 인스턴스, 이미지, 키, 사용자로 구성됩니다. 사용자는 액세스 키에 project_id를 추가하여 프로젝트를 지정할 수 있습니다.

프로젝트의 경우, 할당할 수 있는 프로세서 코어 수와 RAM의 양을 제한하기 위해 쿼타 제어를 사용할 수 있습니다. 다른 프로젝트에서도 자체 자원에 대한 할당량을 허용합니다. 예를 들어, neutron에서는 프로젝트 내에서 생성할 수 있는 네트워크의 수를 관리할 수 있습니다.

역할은 사용자가 수행할 수 있는 작업을 제어합니다. 기본적으로 대부분의 작업은 특정 역할을 요구하지 않지만, policy.yaml 정책 파일을 편집하여 사용자 역할을 설정할 수 있습니다. 예를 들어, 퍼블릭 IP 주소를 할당하려면 사용자가 admin 역할을 가져야 한다는 규칙을 정의할 수 있습니다.

프로젝트는 사용자가 특정 이미지에 접근할 수 있는 권한을 제한합니다. 각 사용자에게 사용자 이름과 패스워드가 할당됩니다. 인스턴스에 접근할 수 있는 키페어는 각 사용자에게 활성화되지만, 할당량이 설정되어 각 프로젝트가 사용가능한 하드웨어 자원 전반에 걸쳐 자원 소비를 제어할 수 있습니다.

Note

이전 버전의 OpenStack에서는 project(프로젝트) 대신 tenant(테넌트)라는 용어를 사용했습니다. 이 레거시 용어 때문에 일부 명령줄 도구에서는 프로젝트 ID를 입력할 것으로 예상되는 곳에 --tenant_id를 사용합니다.