노바는 여러개의 서버 프로세스들로 구성되어있다. 각 프로세스는 다른 기능을 수행한다. 유저가 바라보는 인터페이스는 REST API인 반면, Nova 컴포넌트들 내부적으로는 RPC message 전송 메커니즘으로 소통한다.
API 서버들은 데이터베이스 읽기/쓰기작업과 같은 REST 요청을 수행한다. 때로는 다른 Nova 서비스들에게 RPC message들을 전송하기도 하며, REST 요청에 대해 응답을 생성하기도 한다. RPC messaging은 메세지 큐를 추상화한 oslo.messaging 라이브러리를 이용해 수행된다. Nova는 message를 기반으로한, "shared nothing" 아키텍쳐를 사용한다. 대부분의 주요 nova 컴포넌트들은 여러 서버에서 기동될 수 있고, RPC message들을 listening 하고 있는 매니저들을 가지고 있다. 그 중에 compute service는 컴포넌트가 매니징하고있는 하이퍼바이저 위에서 단일 프로세스만 수행한다. 매니저는 또한 선택적으로 주기적 태스크를 가진다.
Nova는 정보를 저장하기 위해 전통적인 SQL DB를 사용한다. DB는 다중 컴포넌트들 사이에서 논리적으로 공유된다.
Nova 배포의 수평적으로 확장을 위해"cells" 라는 deployment sharding 이라는 개념이 있다. 모든 배포는 최소 1개의 cell을 포함한다.

Hypervisors

Nova는 API 서버를 통해 하이퍼바이저들을 통제한다. 사용할 최적의 하이퍼바이저를 선택하는것은 예산, 자원의 제약, 제공되는 기능, 요구 기술 스펙 등에 따라서 어려울 수 있다. 하지만 대부분의 오픈스택 개발은 KVM 기반의 파이퍼바이저를 이용해서 이루어진다.
또한 각기 다른 가용구역에 있는 다중 하이퍼바이저들을 통해 클라우드를 오케스트레이션 할 수 있다. 노바는 다음과 같은 하이퍼바이저들을 지원한다.

• Baremetal
• Hyper-V
• Kernel-based Virtual Machine (KVM)
• Linux Containers (LXC)
• Quick Emulator (QEMU)
• Virtuozzo
• VMware vSphere
• zVM

Projects, Users, and Roles

Nova를 사용하기 위해서는 Identity service에서 유저를 생성해야한다.
Nova 시스템은 각기 다른 프로젝트의 유저들이 공유시스템 하에서 권한 기반의 접근 규약을 할당하여 사용할 수 있게 설계되었다. 권한은 유저가 수행할 수 있는 액션을 제한할 수 있다.

프로젝트는 Nova 서비스 안에서 주요 조직을 구성하는의 고립된 자원 컨테이너이다. 일반적으로 네트워크, 볼륨, 인스턴스, 이미지, 키, 유저들로 구성되어있다. 유저는 자신의 access key에 project_id를 추가해서 프로젝트를 명시할 수 있다.

Quota를 이용하면 프로젝트에 할당될 수 있는 프로세서 코어의 수와 RAM의 크기를 제한할 수 있다. 다른 프로젝트들도 각각 quota를 설정할 수 있다. 예를들어 Neutron은 하나의 프로젝트 안에서 생성될 수 있는 네트워크의 수를 제한할 수 있게 해준다.

Role을 통해 유저가 수행할 수 있는 액션을 제한할 수 있다. 기본적으로 대부분의 액션은 특정한 권한을 요구하지 않지만, policy.yaml 을 편집하여 권한을 설정할 수 있다. 예를 들어, public IP 주소를 할당하기 위해서는 admin 이라는 role이 있어야만 하는 규칙을 설정할 수 있다.

프로젝트는 유저가 특정 이미지에 접근하는 것을 제한한다. 각 유저는 이름과 비밀번호를 가지고 있다. 인스턴스로의 접근을 허가하는 Keypair는 모든 유저가 가지고 있을 수 있기 때문에, quota를 설정하여 각 프로젝트의 가용한 하드웨어 자원 소비를 통제할 수 있다.

과거 버전에서는 project 대신 tenant 라는 용어가 쓰였다.

Block storage

오픈스택은 두가지 종류의 블록스토리지를 제공한다. Nova 자체적으로 프로비저닝 되는 스토리지와, 블록스토리지서비스인 Cinder에 의해 관리되는 스토리지이다.

Nova-provisioned block storage

Nova는 루트 디스크와 선택적으로 "단기 사용하는" 볼륨을 만들 수 있는 기능을 제공한다. 인스턴스가 Boot From Volume 인스턴스가 아닌 이상 루트디스크는 항상 존재한다.
루트디스크는 인스턴스와 결합하여, 인스턴스의 수명에 의존하여 존재한다. 일반적으로, 루트디스크는 인스턴스의 루트 파일 시스템을 저장하기 위해서, 그리고 게스트 OS의 상태를 영속하기위해서 사용되고, 인스턴스가 삭제됨에 따라 같이 제거된다. 단기사용 볼륨의 양은 인스턴스의 flavor에 의해 결정된다.

루트볼륨 뿐만 아니라, 플레이버도 추가 단기사용 볼륨 디바이스를 제공한다. 이 것은 파티션 테이블이나 파일시스템이 없는 raw 블록 디바이스라고도 한다. cloud-aware OS는 이와 같은 스토리지 디바이스를 찾고, 포맷하고, 마운트할 수 있다.

Cinder-provisioned block storage

오픈스택의 블록스토리지 서비스인 Cinder는 영구적인 볼륨을 제공한다. 이는 특정 인스턴스에 종속적인 영구 가상 블록 디바이스 라고도 한다.

영구 볼륨은 단일 인스턴스에 의해 접근 가능하며 다중 인스턴스에 부착될 수 있다. This type of configuration requires a traditional network file system to allow multiple instances accessing the persistent volume. It also requires a traditional network file system like NFS, CIFS, or a cluster file system such as Ceph. 이러한 시스템들은 오픈스택 클러스터 안에서 구성될 수 있다.

ref) openstack official