오픈스택 Compute Nova

박도준·2020년 5월 20일

[클라우드] - OpenStack

목록 보기

3/10

Nova에 대해 자세히 알아봅시다.

Nova란?

openstack docs에서의 Nova에 대한 정의를 살펴보겠습니다.

"Nova is the OpenStack project that provides a way to provision compute instances (aka virtual servers). Nova supports creating virtual machines, baremetal servers (through the use of ironic), and has limited support for system containers. Nova runs as a set of daemons on top of existing Linux servers to provide that service."

한줄씩 키워드를 정리하면서 보겠습니다.
Nova is the OpenStack project that provides a way to provision compute instances (aka virtual servers).
노바는 오픈 스택 프로젝트 중 하나이며, 컴퓨트 인스턴스(가상 서버) 프로비져닝 서비스를 제공한다.

-컴퓨트 인스턴스(가상 서버)

가상 서버를 알아보기 전에 먼저 가상화에 대해서 알아보겠습니다.
가상화란 하나의 물리적 자원을 여러 대의 논리적 시스템으로 활용하는 방안입니다. 기존에는 하나의 하드웨서 시스템에 하나의 운영제체(OS)를 동작시켰으나, 하드웨서 성능이 발전함에 따라 하나의 하드웨어에 여러 대의 운영체제(OS)를 설치하여 자원(CPU/Memory/disk)을 공유하는 소프트웨어 기술입니다.

그러면 가상 서버는 어떻게 만들어질까요?
바로 서버 가상화를 통해 만들어집니다. 서버 가상화란 게스트/호스트 기반에서 하드웨어로부터 서버 소프트웨어를 추상화하여 하나의 물리적 장치에서 여러 개의 가상 서버를 실행할 수 있게 해주는 기술입니다.

즉, 가상 서버란 하나의 물리적 서버에서 여러 개의 애플리케이션, 운영체제(os)들이 제각기 서로 영향을 미치지 않으면서 사용되는 서버를 뜻합니다.
(가상 서버=가상 머신=VM)

- 프로비저닝

사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 프로비저닝이라고 합니다. 쉽게 말해서, 서비스를 제공하기 위해, 네트워크, 저장공간 그리고 웹앱 서비스 등을 제공하는데, 서비스 제공하기 전에 준비하는 단계를 뜻합니다.

Nova supports creating virtual machines, baremetal servers (through the use of ironic), and has limited support for system containers.

Nova는 기본적으로 가상 머신의 생성과 Ironic을 통한 베어메탈 서버의 생성을 지원하고, 제한적이지만 시스템 컨테이너도 지원합니다.

- Ironic을 통한 베어메탈 서버의 생성

베어메탈 서버를 Ironic을 통해서 생성한다고 했는데 Ironic이란 무엇일까요?
Ironic이란 가상 머신 대신 베어메탈 머신을 준비시키는 오픈스택 프로젝트입니다.
베어메탈의 하이버바이저 API이자 베어메탈 하이퍼바이저와 상호 작용하는 플러그인들의 집합으로 생각할 수 있습니다.

베어메탈은 어떤 소프트웨어도 설치되어 있지 않은 하드웨어를 의미합니다.
즉, 베어메탈 서버는 베어 메탈 방식으로, 하드웨어 위에 하이퍼바이저 OS 설치 없이 유저가 설치하고 싶은 OS를 직접 하드웨어 위에 설치하는 방식입니다.

베어메탈 호스팅은 하이버파이저를 사용하지 않습니다. CPU와 메모리를 아무와도 공유하지 않기 때문에 더 빠르고 일관성 있는 안정정인 성능을 얻을 수 있습니다. 자신만의 소프트웨어를 설치할 수도 있는데, 일부 기업은 이 때문에 베어메탈 호스팅을 이용하기도 합니다.

베어메탈 호스팅 : 호스팅 업체에서 제공하는 전용 서버를 사용해 시스템을 구축하는 것을 말합니다.
- 장점 : 서버에 대한 모든 권한을 가질 수 있고 서버의 모든 성능을 사용할 수 있으며 독립적으로 사용하기 때문에 웹 호스팅에 비해 보안 측면에서도 더 유리한 면이 있습니다.
- 단점 : 호스팅 서비스임에도 초기 설치 기간이 오래 걸리고 비용도 많이 듭니다. 그래서 호스팅을 받기 보다는 직접 상면(장비나 설비를 설치할 수 있는 공간)을 임대하여 서버를 직접 구축하는 것이 더 유리하기도 합니다.

- 컨테이너(Container)

컨테이너를 알아보기 위해 VM과 비교를 하면서 설명드리겠습니다.

VM과 컨테이너는 애플리케이션과 그 의존성들을 독립된 단위로 묶어 격리하여 어디서든 실행 가능하게 한다는 비슷한 목적을 가지고 있습니다. 또한 물리적 하드웨어의 필요성을 제거하여 컴퓨터의 자원을 에너지 면에서도, 그리고 비용 면에서도 더 효율적으로 사용할 수 있게 해준다는 점에서도 비슷합니다.

하지만 VM과 컨테이너는 결정적인 차이가 있습니다. 바로 설계의 접근법입니다.

우선 VM부터 알아보겠습니다.

VM은 기본적으로 컴퓨터의 에뮬레이션으로, 하이퍼바이저를 통해 물리적 기계 위에서 돌아갑니다.

하이퍼바이저

잠시 하이퍼바이저에 대해서 알아보겠습니다.
하이퍼바이저 등장 전에는 단일 서버를 여러 사용자가 공유할 수 있도록 물리적으로 공간을 격리하는데 그쳤다면, 하이퍼바이저가 출현하면서 물리 서버 자원을 추상화하고, 논리적으로 공간을 분할하여 'VM'이라는 독립적인 가상 환경의 서버를 이용할 수 있게 되었습니다.

하이퍼바이저를 정의하면 호스트 시스템에서 다수의 게스트 OS를 구동할 수 있게 하는 소프트웨어라고 할 수 있습니다.
또한, 하이퍼바이저는 가상화하면서 하드웨어와 각각의 VM을 모니터링하는 중간 관리자, VMM(Virtual Machine Monitor)이라고도 불립니다.

이러한 하이퍼바이저는 두 개의 범주로 분류할 수 있습니다.

<Type 1> 네이티브 or 하이퍼바이저형

하이퍼바이저가 하드웨어 바로 위에서 실행되는 방식입니다. 하이퍼바이저가 하드웨어를 직접 제어하기 때문에 자원을 효율적으로 사용할 수 있고, 별도의 호스트 OS가 없으므로 오버헤드가 적지만 여러 하드웨어 드라이버를 세팅해야 하므로 설치가 어렵습니다.
Type 1의 종류로는 KVM, Xen,Hyper-V이 있습니다.

<Type 2> 호스트형

호스트형 하이퍼바이저는 일반적인 소프트웨어처럼 호스트 OS 위에서 실행됩니다.
하드웨어 자원을 VM 내부의 게스트 OS에 에뮬레이트 하는 방식이기 때문에 네이티브 방식에 비해 오버헤드가 크지만, 기존의 컴퓨터 환경을 그대로 사용하는 방식이므로 설치 및 구성이 편리하다는 점과 플랫폼에 대한 제약이 없다는 점이 장점입니다.
대표적으로 qemu,VMware server, Virtual box가 있습니다.

하이퍼바이저에 의해 구동되는 VM은 각 VM마다 독립된 가상 하드웨어 자원을 할당 받습니다.
그리고 VM들은 논리적으로 분리되어 있어 한 VM에 오류가 발생해도 다른 VM으로 퍼지지 않는다는 장점이 있습니다.

이제 컨테이너에 대해 알아보겠습니다.

컨테이너는 갑자기 등장한 가상화 기술이 아닙니다. 리눅스 기반 시스템에서 프로세스 간 격리를 위해 사용하던 기술들을 조합하여 발전시킨 것이라고 볼 수 있습니다.
컨테이너는 하드웨어의 가상화를 제공하는 VM과는 달리, 유저 공간(user space)의 추상화를 통해 운영체제 레벨의 가상화를 제공합니다.

컨테이너란 호스트 OS상에 논리적인 구획(컨테이너)을 만들고, 어플리케이션을 작동시키기 위해 필요한 라이브러리나 어플리케이션 등을 하나로 모아, 마치 별도의 서버인 것처럼 사용할 수 있게 만든 것입니다.
호스트 OS의 리소스를 논리적으로 분리시키고, 여러 개의 컨테이너가 공유하여 사용합니다.

VM과 비교했을 때 컨테이너는 하이퍼바이저와 게스트 OS가 필요하지 않으므로 더 가볍습니다. 그리고 컨테이너에는 OS가 포함되지 않기 때문에 크기가 수십 MB에 불과하고, 운영체제 부팅이 필요 없으므로 서비스를 시작하는 시간도 짧습니다.

(현재 가장 많이 널리 사용되고 있는 오픈소스 컨테이너 형식은 Docker입니다.)

Nova runs as a set of daemons on top of existing Linux servers to provide that service.

Nova는 리눅스 서버 상에서 여러 개의 데몬으로 움직이며 서비스를 제공합니다.

- 데몬(daemon)

멀티태스킹 운영 체제에서 데몬은 사용자가 직접적으로 제어하지 않고, 백그라운드에서 돌면서 여러 작업을 하는 프로그램을 말합니다. 다른 운영체제에서는 시스템 프로세스라고 합니다.

데몬의 동작 방식을 이해하기 쉽게 예를 들어 설명해보겠습니다.
메일 서버는 언제 도착하고 나갈 지 모르기에 서버 관리자가 항시 대기할 수는 없는데 메일 서버 프로그램이 데몬으로 항시 실행되고 있다면 원할한 운영이 가능할 것입니다.

Nova가 기본적인 서비스를 하기 위해 필요한 최소의 오픈스택 서비스

Keystone : ID를 발급하고 인증 서비스를 제공 합니다.
Glance : 컴퓨트 이미지 리포지토리를 제공. 모든 컴퓨트 인스턴스는 Glance 이미지로 생성됩니다.
Neutron : 컴퓨트 인스턴스가 사용하는 가상 네트워크와 물리적 네트워크를 제공합니다.

Nova api

Nova의 모든 사용자 기능은 REST API를 통해서 제공되고 있으며, 이 기능을 사용하여 더 복잡한 로직을 만들거나 NOVA 서비스를 자동화 할 수 있습니다.

API Versions

시간이 지남에 따라 사용자에게 새로운 기능을 제공하기 이해 Nova API는 버전 관리를 지원합니다. 노바에서 버전은 아래와 같은 형식으로 릴리즈 합니다.

{major}.{minor}.{patch}
ex) 2.0.3

이러한 버전 번호는 다음과 같은 지침으로 구성됩니다.

Major Version : Nova에 대한 중대한 아키텍쳐 변경과 역호환성을 깰 수 있는 중요한 변경이 있을 때만 변경이 된다.
Minor Version : minor version이 증가하면 새로운 기능이나 기존 기능의 향상을 의미한다.
Patch Version : 버전 번호에 대한 가장 일반적인 변경 사항이며 버그 수정 또는 매우 사소한 방식으로만 기능에 영향을 미치는 기타 변경 사항을 나타낸다.

노바에는 두 종류의 버전이 있습니다.

major version : 전용 URL이 있다.
microversion : X-OpenStack-Nova-API-Version 헤더를 사용하여 요청하거나 마이크로버전 2.27 이후 OpenStack-API-Version 헤더로도 가능하다.

v2.1 API는 microversion을 지원하는 초기 버전이고, Stein에서는 최대 2.72까지 지원합니다.(현재는 2.87까지 있습니다.)

사용자는 API요청에서 헤더를 지정할 수 있습니다.

X-OpenStack-Nova-API-Version: [version]

여기서 [version] 현재 API에 유효한 api version입니다.
만약 버전이 지정되지 않은 경우 API는 v2.1 API의 버전 요청을 한 것처럼 동작합니다.

API Version 더 알아보기

GET / 을 하게되면 모든 Major version들을 나열해서 보여줍니다.
지원되는 최소 및 최대 microversion에 대한 정보뿐만 아니라 각 API 버전에 대한 보다 구체적인 정보까지 가져옵니다.

GET / 의 Response 예를 보겠습니다.

{
    "versions": [
        {
            "id": "v2.0",
            "links": [
                {
                    "href": "http://openstack.example.com/v2/",
                    "rel": "self"
                }
            ],
            "status": "SUPPORTED",
            "version": "",
            "min_version": "",
            "updated": "2011-01-21T11:33:21Z"
        },
        {
            "id": "v2.1",
            "links": [
                {
                    "href": "http://openstack.example.com/v2.1/",
                    "rel": "self"
                }
            ],
            "status": "CURRENT",
            "version": "2.87",
            "min_version": "2.1",
            "updated": "2013-07-23T11:33:21Z"
        }
    ]
}

위의 코드는 JSON형식으로 작성되어 있습니다.
위 코드에서 사용된 용어에 대해 하나씩 살펴보겠습니다.

versions
- In : body
- Type : array
- 설명 : 사용 가능한 API 버전을 설명하는 버전 개체 목록
id
- In : body
- Type : string
- 설명 : 해당 버전의 이름
links
- In : body
- Type : array
- 설명 : 해당 리소스에 대한 링크
min_version
- In : body
- Type : string
- 설명 : 이 버전의 API가 microversion을 지원하는 경우 지원되는 최소 마이크로버전. 만약 지원하지 않는 경우 빈 문자열
status
- In : body
- Type : string
- 설명 : 이 API 버전의 상태
  - CURRENT : 사용할 API의 기본 버전
  - SUPPORTED : 이전 버전이지만 여전히 지원되는 API 버전
  - DEPRECUTED : 제거할 예정인 API의 사용되지 않는 버전
updated (별로 유용한 정보가 아니여서 앞으로는 더 이상 사용되지 않고 곧 없어질 항목)
- In : body
- Type : string
- 설명 : update된 시기를 말해준다.
version
- In : body
- Type : string
- 설명 : 이 버전의 API가 microversion을 지원하는 경우 지원되는 최대 microversion. 만약 지원되지 않는 경우 빈 문자열.

GET /{api_version}/ 을 하면 root에서 특정 api에 대한 세부사항을 알 수 있습니다.

GET /v2.1/ 의 Response 예를 보겠습니다.

    "version": {
        "id": "v2.1",
        "links": [
            {
                "href": "http://openstack.example.com/v2.1/",
                "rel": "self"
            },
            {
                "href": "http://docs.openstack.org/",
                "rel": "describedby",
                "type": "text/html"
            }
        ],
        "media-types": [
            {
                "base": "application/json",
                "type": "application/vnd.openstack.compute+json;version=2.1"
            }
        ],
        "status": "CURRENT",
        "version": "2.87",
        "min_version": "2.1",
        "updated": "2013-07-23T11:33:21Z"
    }
}

용어를 살펴보겠습니다. (위에서 설명한 용어는 포함하지 않았습니다.)

media-types (별로 유용한 정보가 아니여서 앞으로는 더 이상 사용되지 않고 곧 없어질 항목)
- In : body
- Type : array
- 설명 : 파일에 대한 type을 뜻한다.

나머지 API 호출에는 OpenStack Identity 서비스를 통한 인증이 필요합니다. 인증 후 타입 컴퓨팅의 ID 토큰에서 기본 서비스 URL을 추출할 수 있습니다. 이 서비스 URL은 모든 API 호출이 전체 경로를 구축하기 위해 사용하는 루트 URL이 될 것입니다.

예로 들어 서비스 URL이 http://mycompute.pvt/compute/v2.1인 경우 /servers에 대한 전체 API 호출은 http:////mycompute.pvt/compute/v2.1/servers 입니다.

Compute API Reference 더 알아보기

KVM와 Qemu의 개념

위에서도 설명한 Hypervisor 중 KVM와 Qemu에 대해서 알아보겠습니다. 위에서 말했듯이 KVM은 Type1의 가상화 솔루션이고, Qemu는 Type2의 가상화 솔루션입니다.

KVM과 Qemu 모두 리눅스 OS를 위한 가상화 솔루션입니다. 하지만 대부분의 경우 KVM과 Qemu를 같이 설치하는데, 이는 KVM과 Qemu는 상호 보완적인 관계에 있기 때문입니다.

우선 KVM부터 설명하면, Kernel-based Virtual Machine 의 줄임말로서, 리눅스 커널의 mainline에 포함된 정식 커널 모듈 중 하나입니다.

Qemu는 가상화(Hypervisor)보다는 에뮬레이터라고 말하는 것이 더 정확한 표현입니다.
여기서 가상화와 에뮬레이션에 대해서 짚고 넘어가겠습니다.

가상화란 동 하드웨어를 사용할 수 있는 OS를 가상머신에서 구동하기 위해 Hypervisor를 통해 커널 번역, 자원 분배 등의 기능을 제공하는 것입니다.

에뮬레이션은 다른 종류의 하드웨어에서 구동하기 위해 가상의 하드웨어 환경을 소프트웨어적으로 구현하는 것입니다.

다시 Qemu를 설명하면 Qemu는 완벽한 pc를 위한 오픈 소스 에뮬레이터입니다. 프로세서를 에뮬레이션하는 이외에 Qemu는 네트워크, 비디오 하드웨어와 같은 필요한 모든 하위 시스템을 흉내냅니다.

에뮬레이션은 가상화에 비해 성능이 매우 낮다는 것이 보편적인 견해입니다. 그래서 Qemu를 사용할 때, 하드웨어 아키텍처가 일치할 때에 한해 KVM Acceleration 기능을 사용해 Guest OS를 구성하는 것이 일반적입니다.

즉, Qemu라는 소프트웨어는 리눅스 커널에 내장되어 있는 KVM 모듈을 이용해 가상화 환경을 마련할 수도 있고, 안할수도(에뮬레이션) 있습니다.

Block Device Mapping

Nova는 클라우드 인스턴스에 노출될 수 있는 블록 디바이스 개념을 갖고 있습니다.

블록 디바이스란

블록 디바이스는 바이트 또는 비트(블록) 단위로 순차적으로 데이터를 이동시키는 스토리지 디바이스입니다. 이러한 디바이스는 임의 엑세스를 지원하고 일반적으로 버퍼 I/O를 사용합니다.
블록 디바이스는 컴퓨터에 물리적으로 장착될 수 있고 그렇지 않은 경우 컴퓨터에 물리적으로 장착된 것처럼 임의 액세스가 가능합니다.

블록 디바이스 매핑

블록 디바이스 매핑은 인스턴스가 가지고 있는 모든 블록 장치에 대한 데이터를 구성하고 유지하는 방법입니다.

블록 디바이스 매핑에 대한 더 자세한 내용

박도준

Better late than never