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 소프트웨어는 이러한 기능을 제공하지 않습니다.

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

6 블록 구축하기

OpenStack에서 기본 운영체제는 일반적으로 OpenStack 이미지 서비스(Glance)에 저장된 이미지를 복사하여 사용합니다. 이는 가장 일반적인 경우로, 알려진 템플릿 상태에서 시작하며 가상 머신이 삭제될 때 모든 누적 상태가 소멸되는 휘발성 인스턴스를 생성합니다. 또한, OpenStack 블록 스토리지 서비스에 지속 볼륨에 운영체제를 설치할 수도 있습니다. 이렇게 하면 가상 머신이 삭제되고 다시 생성될 때도 OpenStack 블록 스토리지 볼륨에 누적된 상태가 유지되는 더 전통적인 지속 시스템을 제공합니다. 시스템에서 사용가능한 이미지 목록을 얻으려면 다음 명령어를 실행하세요:

$ openstack image list
+--------------------------------------+-----------------------------+--------+
| ID                                   | Name                        | Status |
+--------------------------------------+-----------------------------+--------+
| aee1d242-730f-431f-88c1-87630c0f07ba | Ubuntu 14.04 cloudimg amd64 | active |
| 0b27baa1-0ca6-49a7-b3f4-48388e440245 | Ubuntu 14.10 cloudimg amd64 | active |
| df8d56fc-9cea-4dfd-a8d3-28764de3cb08 | jenkins                     | active |
+--------------------------------------+-----------------------------+--------+

표시된 이미지 속성은 다음과 같습니다:

ID

이미지의 자동 생성된 UUID

Name

사람이 읽을 수 있는 자유 형식의 이미지 이름

Status

이미지의 상태. ACTIVE로 표시된 이미지는 사용가능합니다.

Server

실행 중인 인스턴스의 스냅샷으로 생성된 이미지의 경우, 이는 스냅샷이 파생된 인스턴스의 UUID입니다. 업로드된 이미지의 경우 이 필드는 비어 있습니다.

가상 하드웨어 템플릿은 flavor(플레이버)라고 불립니다. 기본적으로, 이는 관리자 사용자가 설정할 수 있지만, nova-api 서버의 access controls policy.yaml을 재정의하여 이 동작을 변경할 수 있습니다. 자세한 내용은 Nova 정책을 참조하십시오.

시스템에서 사용가능한 플레이버 목록을 얻으려면 다음 명령어를 실행하세요:

$ openstack flavor list
+-----+-----------+-------+------+-----------+-------+-----------+
| ID  | Name      |   RAM | Disk | Ephemeral | VCPUs | Is_Public |
+-----+-----------+-------+------+-----------+-------+-----------+
| 1   | m1.tiny   |   512 |    1 |         0 |     1 | True      |
| 2   | m1.small  |  2048 |   20 |         0 |     1 | True      |
| 3   | m1.medium |  4096 |   40 |         0 |     2 | True      |
| 4   | m1.large  |  8192 |   80 |         0 |     4 | True      |
| 5   | m1.xlarge | 16384 |  160 |         0 |     8 | True      |
+-----+-----------+-------+------+-----------+-------+-----------+

7 Nova 서비스 아키텍처

이 기본 카테고리는 서비스 아키텍처와 클라우드 컨트롤러에 대한 정보를 설명합니다.

API 서버

클라우드 프레임워크의 중심에는 API 서버가 있으며, 이 서버는 하이퍼바이저, 스토리지, 네트워킹의 명령 및 제어를 사용자에게 프로그래밍 방식으로 제공합니다.

API 엔드포인트는 인증, 인가, 기본 명령과 제어 기능을 처리하는 기본 HTTP 웹 서비스입니다. 이러한 API 인터페이스는 Amazon, Rackspace와 관련 모델을 사용하여 API 호환성을 제공하여 다른 벤더의 제공사항과 상호작용할 수 있는 여러 기존 도구 세트와의 호환성을 보장합니다. 이러한 광범위한 호환성은 벤더 락인을 방지합니다.

메시지 큐

메시지 큐는 컴퓨팅 노드(처리), 네트워킹 컨트롤러(네트워크 인프라를 제어하는 소프트웨어), API 엔드포인트, 스케줄러(가상 리소스에 할당할 물리적 하드웨어를 결정) 및 유사한 컴포넌트 간의 상호작용을 중개합니다. 클라우드 컨트롤러와의 통신은 여러 API 엔드포인트를 통한 HTTP 요청으로 처리됩니다.

일반적인 메시지 전달 이벤트는 API 서버가 사용자로부터 요청을 수신하는 것으로 시작됩니다. API 서버는 사용자를 인증하고 그들이 해당 명령을 발행할 수 있는 권한이 있는지 확인합니다. 요청에 관련된 객체의 가용성이 평가되며, 가용한 경우 요청은 관련 워커들을 위한 큐 엔진으로 라우팅됩니다. 워커는 자신의 역할에 따라 지속적으로 큐를 청취하며, 때로는 호스트 이름에 따라 다릅니다. 큐에 해당 작업 요청이 도착하면 워커는 작업을 할당받아 실행을 시작합니다. 완료되면 응답이 큐에 전달되어 API 서버가 수신자에게 전달합니다. 데이터베이스 항목은 이 과정에서 필요한 경우 조회, 추가, 삭제됩니다.

컴퓨트 워커

컴퓨트 워커는 호스트 머신에서 컴퓨팅 인스턴스를 관리합니다. API는 다음 작업을 완료하기 위해 컴퓨트 워커에게 명령을 보냅니다:

• 인스턴스 실행
• 인스턴스 삭제 (인스턴스 종료)
• 인스턴스 재부팅
• 볼륨 연결
• 볼륨 분리
• 콘솔 출력 가져오기

네트워크 컨트롤러

네트워크 컨트롤러는 호스트 머신의 네트워킹 리소스를 관리합니다. API 서버는 메시지 큐를 통해 명령을 전달하며, 이는 네트워크 컨트롤러가 처리합니다. 특정 작업은 다음을 포함합니다:

• 고정 IP 주소 할당
• 프로젝트를 위한 VLAN 구성
• 컴퓨트 노드를 위한 네트워크 구성