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를 사용합니다.

5 블록 스토리지

OpenStack은 두 가지 종류의 블록 스토리지를 제공합니다: Nova 자체에서 프로비저닝되는 스토리지와 블록 스토리지 서비스인 Cinder에서 관리되는 스토리지입니다.

Nova 프로비저닝 블록 스토리지

Nova는 루트 디스크와 선택적인 "이페머럴 (ephemeral)" 볼륨을 생성할 수 있는 기능을 제공합니다. 루트 디스크는 인스턴스가 볼륨에서 부팅 인스턴스가 아닌 한 항상 존재합니다.

루트 디스크는 인스턴스와 연관되며 해당 인스턴스의 생명 주기 동안만 존재합니다. 일반적으로 이는 인스턴스의 루트 파일 시스템을 저장하는 데 사용되며, 게스트 운영 체제의 재부팅 동안에도 지속되고, 인스턴스 삭제 시 제거됩니다. 루트 이페머럴 볼륨의 크기는 인스턴스의 플레이버에 의해 정의됩니다.

루트 볼륨 외에도 플레이버는 추가적인 이페머럴 블록 장치를 제공할 수 있습니다. 이는 파티션 테이블이나 파일 시스템이 없는 원시 블록 장치로 나타납니다. 클라우드 인식 운영체제는 이러한 스토리지 장치를 발견하고, 포맷하고, 마운트할 수 있습니다. Nova는 Linux 배포판의 기본 파일 시스템을 ext4, 비 Linux 및 비 Windows 운영체제의 경우 VFAT, Windows의 경우 NTFS로 정의합니다. 그러나, 다른 파일 시스템 유형을 설정할 수도 있습니다.

Note

예를 들어, Ubuntu의 기본 클라우드 이미지에 포함된 cloud-init 패키지는 기본적으로 이 공간을 ext4 파일 시스템으로 포맷하고 /mnt에 마운트합니다. 이는 cloud-init 기능이며 OpenStack 메커니즘이 아닙니다. OpenStack은 원시 스토리지만 프로비저닝합니다.

Cinder 프로비저닝 블록 스토리지

OpenStack 블록 스토리지 서비스인 Cinder는 특정 인스턴스와 독립적인 지속 가상화 블록 장치로 나타나는 지속 볼륨을 제공합니다.

지속 볼륨은 단일 인스턴스에서 접근할 수 있거나 여러 인스턴스에 연결될 수 있습니다. 이러한 유형의 설정은 지속 볼륨에 여러 인스턴스가 접근할 수 있도록 전통적인 네트워크 파일 시스템을 필요로 합니다. 또한 NFS, CIFS 또는 Ceph와 같은 클러스터 파일 시스템과 같은 전통적인 네트워크 파일 시스템이 필요합니다. 이러한 시스템은 OpenStack 클러스터 내에서 구축되거나 외부에서 프로비저닝될 수 있지만, OpenStack 소프트웨어는 이러한 기능을 제공하지 않습니다.

지속 볼륨을 부팅가능하도록 설정하고 전통적인 비클라우드 기반 가상화 시스템과 유사한 지속 가상 인스턴스를 제공하는 데 사용할 수 있습니다. 이 경우에도 선택한 플레이버에 따라 인스턴스가 이페머럴 스토리지를 유지할 수 있습니다. 이 경우 루트 파일 시스템은 지속 볼륨에 있을 수 있으며, 인스턴스가 종료되더라도 상태가 유지됩니다. 이러한 유형의 설정에 대한 자세한 내용은 블록 스토리지 서비스 소개를 참조하십시오.