AOC55

Cloud, Devops, Backend, Kubernetes, Openstack, ...

Cloud/Openstack

Openstack :: Nova의 Service 목록과 Status & State

aoc55.soft@gmail.com 2025. 9. 23. 00:06
개인적으로 공부하는 관점에서 작성한 내용이라, 잘못된 부분이 있을 수 있습니다. 잘못된 부분은 말씀주시면 감사하겠습니다.

 

 

Openstack CLI로 openstack compute service list 라고 입력 시 보통 아래와 출력이 되는데 관련해서 조금 알아보자.

 

  • 여기서 gc6-compt1, gc6-compt2 는 Openstack 설치 시 Compute Node의 역할을 하는 Node의 Host 이름이다.

Nova의 Service 목록

위에서 보았듯이 openstack compute service list 로 입력 시 출력되는 Nova의 Service 들을 간단히 알아보자.

nova-compute

  • 실제 VM을 하이퍼바이저 위에서 생성 및 관리등을 하는 워커 프로세스.
  • ex. KVM/Libvirt API를 호출해서 VM을 띄우고, attach/detach, 스냅샷, 콘솔 등등을 처리.
  • 스케줄러가 결정한 요청을 받아서 실행함.
  • 서비스 배치의 경우 Compute Node 마다 실행.

nova-scheduler

  • 어느 nova-compute에 VM 올릴지 스케줄링을 담당한다.
  • 스케줄링 과정에서 요청의 Flavor, AZ, .. 등을 고려해 여러 필터 등을 거쳐서 최종적으로 배치될 nova-compute(compute node)의 위치를 결정한다.
  • 스케줄러 인스턴스의 경우 여러 개의 스케줄러를 띄울 수 있고, 각 스케줄러는 독립적으로 병렬적으로 스케줄링을 할 수 있다.

nova-conductor

  • nova-compute 프로세스와 실제 Nova가 사용하는 DB 간의 중개 역할을 한다.
  • 즉, 각 Compute Node(만약수천개라면?)에 뜬 서비스들이 각각 개별적으로 DB 연결을 하는 것이 아니라, DB 연결에 대해 중앙 제어화 하기 위한 목적이다.
  • 만약 nova-compute 프로세스가 모두 '각자' 연결하면? (예전에는 이랬다고 한다) 커넥션 증가, 보안 취약, 충돌/락 문제 등등... 의 문제가 발생.
  • 따라서 nova-compute 프로세스가 DB에 직접적으로 Write 등을 하는게 아니라, nova-conductor에 RPC 콜 방식으로 중개를 요청한 뒤, 요청을 받은 nova-conductor에서 실질적으로 DB 연결 및 Write/Read 등을 수행한다.
  • nova-conductor의 배치의 경우, "Stateless"기반이기 떄문에 여러 개의 프로세스를 동시에 구동하는데 문제가 없다.
  • (보통 컨트롤러 노드 2~3대 이상이면, 확장성을 위해서 nova-conductor 역시 각 노드에 배포하는 식으로 권고한다고 한다)
nova-compute (각 노드)
     │ RPC
     ▼
nova-conductor (컨트롤러)
     │ SQLAlchemy/DB Driver
     ▼
Nova DB

 

이외에 nova-api-osapi, nova-api-metadata 가 있는데 이들의 경우에는 "compute service" 보다는 API Server 프로세스 이기에, openstack compute service list에는 조회되지 않는다.

관련해서 실제로 아래와 같이 Nova가 사용하는 Database 내 servies 라는 테이블을 조회하면 아래와 같다.

mysql> select host, `binary`, `topic` from nova.services;
+-----------------------------------+--------------------+-----------+
| host                              | binary             | topic     |
+-----------------------------------+--------------------+-----------+
| nova-api-osapi-c6465df8f-wnsgp    | nova-osapi_compute | NULL      |
| nova-conductor-6df5cb68d8-phzqs   | nova-conductor     | conductor |
| nova-scheduler-f47d4dcb-jz88m     | nova-scheduler     | scheduler |
| nova-api-metadata-ff749945c-9zlh4 | nova-metadata      | NULL      |
| gc6-compt2                        | nova-compute       | compute   |
| gc6-compt1                        | nova-compute       | compute   |
| nova-scheduler-f47d4dcb-qwtj9     | nova-scheduler     | scheduler |
| nova-api-metadata-ff749945c-mvlnw | nova-metadata      | NULL      |
| nova-api-metadata-ff749945c-kj54c | nova-metadata      | NULL      |
| nova-api-osapi-c6465df8f-k8v8b    | nova-osapi_compute | NULL      |
| nova-api-metadata-ff749945c-5585d | nova-metadata      | NULL      |
| nova-scheduler-f47d4dcb-55mbf     | nova-scheduler     | scheduler |
| nova-conductor-6df5cb68d8-n6l6v   | nova-conductor     | conductor |
| nova-scheduler-f47d4dcb-bl79h     | nova-scheduler     | scheduler |
+-----------------------------------+--------------------+-----------+
  • nova-api-osapi-.., nova-api-metadata-... 관련 Row들은 topic Column이 NULL 인 것을 알 수 있다.

즉, 사실상 openstack compute service list 에서는 topic 필드의 NULL 이 아닌 서비스만 출력해준다.

State & Status

Nova의 Service 관련하여 조회 할 경우, 아래와 같이 상태 필드로 StateStatus 가 있다.

 

관련해서 무엇을 의미하는지 간단히 알아보자.

State

State

  • 해당 필드로 올 수 있는 값(value)으로는 up, down 이다.
  • 순수하게, 해당 서비스가 살아있는지 여부에 대한 확인 목적이다.
  • 별도의 관리자 등이 명령어로 제어할 일 없고, 각 서비스들이 스스로 Heart Beat 를 보내는 방식으로 갱신하는 영역이다.

Down 테스트

  • 특정 Compute Node 에서 일부로 nova-compute Process를 내려본 뒤 관찰하기.
| bf18e82c-a0fe-4ecb-aa74-e1b5eff303f4 | nova-compute   | gc6-compt2                      | az1      | enabled | down  | 2025-09-22T13:59:16.000000 |
  • State가 down 으로 관측된다. (단, Status는 그대로 enabled 임)

각 서비스들의 Heart Beat 기록 방법

그러면, State 의up & down 을 판별하기 위해서 사용되는 "heart beat" 는 어떤식으로 이루어지는 것일까?

보통 각 서비스들이 프로세스 내 주기적 Task를 통해서, 스스로 (nova-conductor 를 거쳐) Nova의 Services DB 내 직접 레코드를 기록하는 방식이라고 한다.

관련해서 역시 nova.services Table 을 조회하면 아래와 관련된 필드를 찾을 수 있다.

select * form nova.services;

 

테이블 출력에서 아래와 같이 관련된 일부 필드를 확인 할 수 있다.

  • last_seen_up : 마지막에 각 서비스들이 '스스로 살아있음'을 보낸 시각.
  • report_count : 하트비트를 보고한 횟수

이 필드들 기반에서 Openstack CLI에서는 위의 last_seen_up 시간과 updated_at 시간을 비교해서, 해당 서비스가 up 인지 down 인지 판별하는 방식이라고 한다.

Status

이제 Status 를 알아보자. (State 아님)

Status

  • 해당 필드로 올 수 있는 값(value)으로는 enabled, diasbled 이 있다.
  • ex. "nova-compute"의 경우 오픈스택 관리자가 해당 노드에 VM 스케줄링 할지 여부에 대한 결정으로, 만약disabled 인 경우에는 새로운 VM 생성 등이 스케줄링 되지 않는다.
  • 이 속성의 경우, 실제 필요에 따라 명령어로 제어할 일이 충분히 발생한다. (위와 같이 VM 신규 생성을 막거나 할때 등)

Status 제어 CLI (ex. nova-compute)

# enable
openstack compute service set --enable gc6-compt1 nova-compute

# disable
openstack compute service set --disable gc6-compt1 nova-compute
# | gc6-compt1                      | az1      | disabled |

 

끝!

'Cloud > Openstack' 카테고리의 다른 글

Openstack :: Nova Cell 이란?  (0) 2025.10.18
Openstack :: Heat Study (1)  (0) 2025.05.17
Openstack :: Keystone System Role  (0) 2025.02.16
Openstack :: barbican 이란?  (1) 2025.02.08