오늘부터는 각 서비스에 대해 집중적으로 알아보려고 합니다.

그 첫시간으로 다룰 것은 바로 Nova(노바)인데요~

이미 말씀드린바와 같이 Nova는 VM을 생성하고 관리하는 서비스입니다. 다시 말해 Nova = VM 이렇게 기억하면 편합니다.

그 유래를 보자면, 원래 미 나사 연구소에서 처음 개발되었다가 오픈스택에 기부된 프로젝트입니다.

내부적으로는 API, Scheduler, Compute, Console, Conductor 등 다양한 서비스로 구성이 되어 있고요.

특이점을 보자면 RESTful (Representational State Transfer) API를 지원하고 아마존 EC2 서비스와 호환이 됩니다. 무슨 말인가 하면 Nova API는 EC2 API와 연동이 가능합니다.

) 

그러면 좀 더 상세하게 각 부분에 대해 알아보겠습니다.

1. nova-api

Nova와 연동을 위한 RESTful API 입니다.

2. nova-scheduler

이름처럼 스케쥴러인데요 Queue에 있는 요청들을 수행할 Compute host를 선정하는 역할을 합니다. (데몬) 어느 host에 생성할 것인가 판단을 위해서는 filer를 등록하게 됩니다. 그 filer를 거치면서 최적의 host를 선택하게 됩니다. filter에 대해서는 아래에 다시 한 번 설명할께요.

3. nova-compute

Hypervisor API를 통해 인스턴스를 생성하고 삭제하는 역할을 합니다. (데몬)

4. nova-conductor

grizzly 버전부터 생긴 기능인데 nova-compute와 DB 사이에 위치하고 Nova Database에 접근하기 위한 역할을 합니다. (데몬)

5. nova-novncproxy

인스턴스의 콘솔 접속을 위한 Proxy 데몬입니다.

6. nova-consoleauth

인스턴스의 콘솔 접속을 위한 인증 데몬입니다.

이번에는 몇가지 내부적인 설정을 알아보도록 하죠.

1. 이미지 처리

사용하지 않는 base 이미지는 자동으로 삭제를 합니다. 그런데 미사용 이미지 삭제 기능은 off하는 것이 좋습니다. 예를 들어 nova-compute를 통해 alive 상태를 update하는데 만약 nova-compute가 비정상적으로 동작한다거나 하면 문제가 됩니다.

이 부분은 remove_unused_base_images를 false로 설정하면 됩니다. 

2. filter

위의 nova-scheduler에서 filter에 대해서 잠깐 설명했었는데요.

• AggregateInstanceExtraSpecsFilter : host를 그룹핑하여 flavor와 연동하기 위한 scheduler filter (특정 flavor는 특정 zone에 생성되도록)
• AvailabilityZoneFilter : AZ(가용 존)를 구분하기 위한 scheduler filter 
• RamFilter : 선택한 flavor의 메모리가 생성 가능한지 판단하기 위한 scheduler filter 
• CoreFilter : 선택한 flavor의 CPU가 생성 가능한지 판단하기 위한 scheduler filter 
• ComputeFilter : Compute node가 alive한지 판단하기 위한 scheduler filter 

예: /etc/nova.conf