OpenStack Nova란?
OpenStack Nova는 오픈스택에서 컴퓨트 인스턴스(가상 서버, VM) 를 프로비저닝(생성·관리)하는 핵심 서비스입니다. 즉, 사용자가 원하는 사양의 가상 머신을 만들고, 삭제하고, 상태를 관리하며, 클라우드 내 컴퓨트 자원을 효율적으로 배분하는 역할을 담당합니다.
주요 특징 및 역할
- 가상 머신(VM) 생성/삭제/관리: Nova는 사용자의 요청에 따라 VM(Compute Instance)을 자동으로 생성하고, 삭제하며, 상태(시작, 중지, 재시작 등)를 관리합니다.
- 베어메탈 서버 및 컨테이너 지원: Nova는 Ironic 서비스를 통해 베어메탈 서버(실제 물리 서버) 프로비저닝도 지원하고, 일부 컨테이너 실행도 제한적으로 지원합니다.
- 다양한 하이퍼바이저 지원: KVM, Xen, ESXi, Hyper-V 등 여러 하이퍼바이저와 연동할 수 있습니다.
- 확장성: 대규모 클라우드 환경에서도 수평 확장이 가능하도록 설계되어 있습니다.
- 자동화 및 오케스트레이션: REST API와 CLI, 대시보드(Horizon)를 통해 자동화된 인스턴스 관리가 가능합니다.
Nova 서비스 구성 요소
Nova는 OpenStack의 원래 핵심 컴포넌트이며 가장 복잡한 컴포넌트 중 하나로 간주됩니다. Nova 서비스는 사용자 요청에 따라 가상 머신을 관리하며, 다양한 컴포넌트 간의 오케스트레이션을 통해 작업을 수행하는 분산 애플리케이션으로 설계되었습니다.
- nova-api 서비스: 최종 사용자 및 컴퓨트 API 호출을 수락하고 응답합니다. 대부분의 인스턴스 실행 및 정책 시행과 같은 오케스트레이션 활동을 시작합니다.
- nova-compute 서비스: 하이퍼바이저 API(XenServer용 XenAPI, Libvirt KVM, VMware용 VMware API)를 통해 VM 인스턴스를 생성하고 종료하는 작업 데몬입니다. 컴퓨트 노드에서 실행되며 메시지 큐를 통해 새 요청을 수신합니다.
- nova-scheduler: 메시지 큐에서 VM 인스턴스 요청을 가져와서 어디에서 실행해야 하는지(특히 어떤 컴퓨트 호스트에서 실행해야 하는지) 결정합니다. 자원 가용성을 기반으로 서버를 순위 지정하는 가중치 및 필터와 같은 알고리즘을 사용합니다.
- nova-conductor 서비스: 컴퓨트 노드의 데이터베이스 직접 접근을 방지하여 데이터베이스 보안을 강화하고, 컴퓨트 노드를 대신하여 데이터베이스 작업을 수행합니다.
- 메타데이터 서비스(Metadata Service): 가상 머신에 인스턴스 초기화 및 구성을 위한 구성 데이터를 제공합니다.
- nova-consoleauth 데몬: novncproxy 및 xvncproxy와 같은 VNC 프록시의 콘솔 접근 인증을 제공합니다.
Nova의 인스턴스 생성 흐름
- 사용자 요청: 사용자가 CLI, 대시보드(Horizon), 또는 API로 VM 생성 요청을 보냅니다.
- Nova API: 요청을 받아 데이터베이스에 기록하고, 메시지 큐를 통해 스케줄러에 전달합니다.
- Scheduler: 클라우드 내 가용 자원(컴퓨트 노드, 네트워크 등)을 고려해 VM이 생성될 컴퓨트 노드를 결정합니다.
- Compute 서비스: 선정된 컴퓨트 노드의 Nova Compute가 하이퍼바이저(KVM 등)와 통신해 VM을 실제로 생성합니다.
- Conductor: 필요시 데이터베이스 작업이나 복잡한 조정 작업을 중개합니다.
- 상태 반환: 생성된 VM의 정보가 API를 통해 사용자에게 반환됩니다.
Nova와 다른 OpenStack 서비스의 연동
- Keystone: 인증/권한 관리
- Glance: VM 생성에 필요한 이미지(운영체제 등) 제공
- Neutron: VM에 연결될 가상 네트워크 구성
- Cinder: VM에 연결할 블록 스토리지(디스크) 제공
- Placement: 자원 인벤토리 및 할당 최적화
내부 통신 구조
- Nova의 각 컴포넌트는 메시지 큐(AMQP 기반, 예: RabbitMQ)를 통해 비동기적으로 통신합니다.
- 데이터베이스는 Nova의 상태와 리소스 정보를 저장하며, Conductor가 컴퓨트 노드와 DB 사이의 중계 역할을 합니다.
하이퍼바이저 선택 및 Docker/Magnum
하이퍼바이저(Hypervisor): OpenStack 컴퓨트 노드의 핵심이며, 가상 머신이 하드웨어 계층에 접근하기 위한 관리 기능을 제공하는 가상 머신 모니터(VMM)입니다.
- OpenStack은 KVM, VMware ESXi, QEMU, UML, Xen, Hyper-V, LXC, 베어 메탈(bare metal), 그리고 Docker를 포함한 다양한 VMM을 지원합니다.
- KVM은 OpenStack 컴퓨트의 기본 하이퍼바이저이며, libvirt를 사용하는 상태 비저장(stateless) 워크로드에 가장 적합합니다. /etc/nova/nova.conf에서 compute_driver=libvirt.LibvirtDriver 및 libvirt_type=kvm으로 설정됩니다.
Docker 컨테이너: OpenStack nova-compute용 Docker 드라이버가 지원됩니다.
- 가상 머신이 완전한 가상 하드웨어 플랫폼을 제공하는 반면, 컨테이너는 애플리케이션을 호스팅하기 위한 격리된 사용자 공간을 제공하며, 호스트 운영 체제의 동일한 기본 커널을 사용합니다.
- 컨테이너는 매우 가볍고 빠르며, 새로운 애플리케이션 개발이나 기존 애플리케이션 포팅에 좋은 선택지입니다.
OpenStack Magnum 프로젝트: 서비스형 컨테이너(Container-as-a-Service, CaaS)
- nova-docker 드라이버가 Docker를 Nova가 지원하는 하이퍼바이저로 추가하여 Docker 컨테이너의 라이프사이클을 VM과 유사하게 관리하도록 하는 것이 목표였던 반면, Magnum은 Kubernetes, Apache Mesos, Docker Swarm과 같은 컨테이너 오케스트레이션 엔진(COE)을 사용하여 연결된 컨테이너 그룹의 오케스트레이션을 지원하기 위해 구축되었습니다.
- Magnum은 COE 노드를 Nova 인스턴스로 배포하고, Neutron을 사용하여 COE 노드 간의 네트워크 연결을 제공하며, Cinder 볼륨을 애플리케이션 컨테이너에 사용하고, Heat을 사용하여 COE를 위한 가상 인프라를 오케스트레이션합니다.
- Magnum 구성 요소:
- Bay: COE 소프트웨어를 실행하는 노드 그룹.
- Pod: 동일한 노드에서 실행되는 컨테이너 그룹.
- Service: 소비 가능한 서비스를 제공하는 하나 이상의 Bay.
- BayModel: Bay를 생성하는 데 사용되는 템플릿으로, Nova의 플레이버(flavor) 개념과 유사합니다.
- ReplicationController: 중복성을 위해 여러 포드 복제본이 실행되도록 보장하고, 실패한 컨테이너를 다시 스폰하는 역할을 합니다.
OpenStack 컴퓨트 노드(Compute Node)란?
- 컴퓨트 노드(Compute Node) 는 OpenStack 클라우드에서 실제로 가상 머신(인스턴스, VM)이 실행되는 물리적 서버입니다. 즉, 사용자가 요청한 VM이 실제로 생성되고 운영되는 곳이 바로 컴퓨트 노드입니다.
컴퓨트 노드의 주요 역할
- 가상 머신 실행: Nova-compute 서비스와 하이퍼바이저(KVM, QEMU, VMware ESXi 등)를 통해 VM을 생성, 운영, 삭제합니다
- 네트워크 연결: 각 인스턴스의 네트워크 인터페이스를 가상 네트워크에 연결하고, 방화벽 등 네트워크 정책을 적용합니다. 이를 위해 Neutron 에이전트가 함께 동작할 수 있습니다[1][2][5].
- 스토리지 연동: 인스턴스에 필요한 이미지(Glance), 블록 스토리지(Cinder)와 연동하여 디스크를 마운트합니다.
- 자원 관리: CPU, 메모리, 디스크 등 실제 물리 자원을 여러 VM이 공유해서 사용하게 합니다[6][3].
- 확장성 제공: 컴퓨트 노드는 수평 확장이 가능하여, 더 많은 VM을 운영하고 싶을 때 노드를 추가하면 됩니다.
컴퓨트 노드의 동작 원리
- Nova-compute 서비스가 각 컴퓨트 노드에 설치되어 하이퍼바이저를 제어합니다[1][4][2].
- 사용자의 VM 생성 요청이 컨트롤러 노드의 Nova API로 들어오면, 스케줄러가 어떤 컴퓨트 노드에 VM을 배치할지 결정합니다.
- Nova-compute는 메시지 큐를 통해 명령을 받아, 하이퍼바이저를 통해 VM을 생성/삭제하고, 상태 정보를 DB에 업데이트합니다.
- VM이 생성되면, 네트워크(Neutron)와 스토리지(Glance, Cinder)와 연동해 필요한 리소스를 연결합니다.
컴퓨트 노드의 내부 구성
- Nova-compute: VM 생성/삭제/관리 담당 핵심 서비스.
- 하이퍼바이저: 실제 가상화 기술(KVM, QEMU, VMware 등).
- Neutron 에이전트: 네트워크 연결 및 정책 적용.
- (필요시) Ceilometer 에이전트: 모니터링 및 텔레메트리.
컨트롤러 노드와의 차이점
구분 | 컴퓨트 노드(Compute Node) | 컨트롤러 노드(Controller Node) |
주요 역할 | VM 실행(실제 인스턴스가 동작하는 서버) | 클라우드 전체 제어 및 관리(중앙 제어, API, 스케줄링 등) |
주요 서비스 | Nova-compute, 하이퍼바이저, Neutron 에이전트 등 | Nova-API, Nova-scheduler, Nova-conductor, Keystone, Glance, Neutron-server, Horizon 등 |
자원 제공 | CPU, RAM, 디스크 등 실제 컴퓨트 자원 제공 | 자원 직접 제공 X, 관리·제어 기능 제공 |
확장성 | VM 수요에 따라 노드 추가로 확장 | 고가용성(HA)을 위해 여러 대로 구성 가능 |
동작 방식 | 컨트롤러의 명령을 받아 VM을 생성/삭제/관리 | 사용자 요청 수신, 인증·스케줄링, 전체 인프라 상태 관리 |
컴퓨트 클라우드 분리 (Segregating the Compute Cloud)
클라우드 인프라가 커짐에 따라 API 서비스의 낮은 지연 시간과 서비스 중복성을 유지하기 위한 전략이 필요합니다.
가용성 영역(Availability Zones, AZ)
장애 도메인(fault domains)을 기반으로 컴퓨트 노드를 그룹화하는 개념입니다 (예: 랙에 호스팅된 모든 컴퓨트 노드, 동일한 ToR(Top-of-Rack) 스위치에 연결된 노드, 동일한 PDU(Power Distribution Unit)에서 전원을 공급받는 노드).
컴퓨트 노드는 여러 AZ의 일부가 될 수 없습니다. /etc/nova.conf 파일에서 default_availability_zone 값을 업데이트하여 구성합니다.
호스트 집계(Host Aggregates)
특정 기능을 가진 컴퓨트 자원을 제공하는 컴퓨트 노드를 그룹화하는 전략입니다.
특정 종류의 가상 머신이 더 나은 물리적 하드웨어 지원이 필요한 경우 이러한 컴퓨트 노드에 항상 스케줄링되도록 할 수 있습니다. 호스트 그룹에 메타데이터를 첨부하여 생성하며, 최종 사용자는 동일한 메타데이터가 첨부된 플레이버를 사용해야 합니다. 이질적인 하이퍼바이저 배포(예: KVM 및 VMware ESXi)에 유용합니다.
Nova 셀(Cells)
데이터베이스 및 메시지 큐와 같은 인프라 자원에 대한 부하를 여러 인스턴스에 분산하여 컴퓨트 워크로드를 확장하는 방법입니다. 각 셀은 자체 데이터베이스와 메시지 큐를 가지며, 통신을 개별 셀 내로 제한합니다.
- 아키텍처: 셀은 트리 구조로 배열됩니다. API 셀(루트)은 Nova API 서비스를 실행하지만 Nova 컴퓨트 서비스는 실행하지 않습니다. 컴퓨트 셀은 Nova API를 제외한 모든 Nova 서비스를 자체 DB 및 메시지 큐와 함께 실행합니다.
영역(Regions)
셀과는 다른 접근 방식으로, 여러 Nova API 엔드포인트를 사용하여 가상 머신을 실행할 수 있습니다. 각 Nova 영역은 자체 컴퓨트 노드와 API 엔드포인트가 있는 완전한 Nova 설치를 가집니다.
워크로드 분리(Workload Segregation)
가상 머신 인스턴스를 서로 상대적으로 배치하는 사용성 기능입니다.
- 동일성 정책(Affinity policy): VM을 동일한 컴퓨트 노드에 배치합니다.
- 반동일성 정책(Anti-affinity policy): VM을 서로 다른 컴퓨트 노드에 강제로 배치합니다.
- Nova 클라이언트를 통해 --hint group=svr-grp-uuid 명령으로 VM을 부팅합니다.
초과 할당(Overcommitment) 고려 사항
- 하이퍼바이저 기능으로, 컴퓨트 호스트가 가진 물리적 자원보다 더 많은 자원(CPU, RAM)을 가상 머신에 할당하는 것을 허용하여 자원 낭비를 방지합니다.
- CPU 초과 할당 비율: 기본값은 16:1입니다.
- 계산 공식: (CPU 초과 할당 비율 * 물리 코어 수) / 인스턴스당 가상 코어 수.
- RAM 초과 할당 비율: 기본값은 1.5:1입니다.
- 이러한 비율은 /etc/nova/nova.conf의 cpu_allocation_ratio 및 ram_allocation_ratio 지시문을 통해 변경할 수 있습니다.
- 플레이버(Flavors): RAM, 디스크 공간 및 CPU 코어 수를 정의하는 하드웨어 템플릿입니다.
인스턴스 저장 대안 (Storing Instances' Alternatives)
- 임시 스토리지(Ephemeral storage): 비영구적 스토리지로, VM이 종료되면 관련 디스크가 손실됩니다. Nova 인스턴스의 첫 번째 디스크로 사용되는 Glance 이미지 복사본이 컴퓨트 노드에 다운로드됩니다. NFS 마운트를 통해 외부 스토리지에서 호스팅될 수도 있습니다.
- 외부 공유 파일 스토리지(External shared file storage): 실행 중인 인스턴스의 디스크가 컴퓨트 노드에 있지 않고 외부에 호스팅됩니다.
- 장점: 라이브 마이그레이션 및 이주가 용이하며, 고가용성을 제공합니다.
- 단점: 추가 스토리지가 필요할 때 확장이 불가능하며, 컴퓨트 노드 간 인스턴스 마이그레이션이 어렵고, 컴퓨트 노드 실패 시 인스턴스 손실로 이어질 수 있습니다.
- 그러나 OpenStack 배포에 더 편리한 것으로 간주됩니다.
인스턴스 부팅 이해 (Understanding Instance Booting)
가상 머신을 시작하는 과정은 여러 서비스와의 상호 작용을 포함합니다.
- Nova 스케줄링 프로세스: 가상 머신을 호스팅할 최적의 컴퓨트 노드를 선택하는 과정입니다.
- 기본 스케줄러는 필터 스케줄러이며, 필터링 및 가중치 부여 체계를 사용합니다.
- 이미지로부터 부팅(Booting from Image): 사용자는 가상 머신에 로드될 이미지와 하드웨어 특성(플레이버)을 선택합니다. 이미지는 컴퓨트 노드로 다운로드되며 인스턴스의 첫 번째 하드 드라이브가 됩니다. 이미지에 대한 변경 사항은 VM에 로컬이며 인스턴스 종료 시 손실됩니다.
- 인스턴스 메타데이터 가져오기(Getting the Instance Metadata): 인스턴스에 초기화 데이터를 제공하여 호스트 이름, SSH 키 등을 구성합니다.
- cloud-init 데몬이 인스턴스와 관련된 구성 데이터를 가져오기 위해 EC2 및 Config Drive와 같은 다양한 데이터 소스를 사용합니다.
- EC2 소스는 가장 널리 사용되는 데이터 소스입니다. 특별한 IP 주소(169.256.169.254)의 HTTP 서버를 통해 메타데이터 서비스를 제공합니다.
컴퓨트 노드 추가 (Add a Compute Node)
- OpenStack Ansible (OSA)를 사용하여 컴퓨트 노드를 추가하는 것이 훨씬 간단합니다.
- Ansible을 사용한 배포 단계:
- /etc/openstack_deploy/openstack_user_config.yml 파일을 조정하여 새 컴퓨트 노드에 대한 compute_hosts 스탠자(stanza)를 추가합니다.
- /etc/openstack_deploy/user_variables.yml 파일에서 하이퍼바이저 유형, CPU/RAM 할당 비율, 호스트당 최대 인스턴스 수를 정의합니다.
- setup-hosts.yml 플레이북을 --limit 옵션과 함께 실행하여 대상 컴퓨트 노드에 컨테이너를 설치합니다.
- setup-openstack.yml 플레이북을 실행하여 새 서비스를 배포합니다. 이 때 compute_hosts 그룹으로 제한할 수 있습니다.
서비스 복구 계획 (Planning for Service Recovery)
- 시스템 관리자나 클라우드 운영자의 가장 중요한 작업 중 하나는 백업을 계획하는 것입니다.
- OpenStack은 특정 백업 도구를 지원하지 않으며, 컴포넌트 조합이기 때문에 각 컴포넌트에 대한 백업 전략이 필요합니다.
- backup-manager: 일반 백업에 사용할 수 있는 도구입니다.
- 서비스형 데이터 보호(Data Protection as a Service): 타사 솔루션이나 객체 스토리지를 백업 위치로 사용할 수 있습니다. 그러나 인스턴스 스냅샷을 객체 스토리지에 업로드하는 방식은 점진적 백업의 부재와 관리 복잡성으로 인해 원활하거나 효율적이지 않다고 언급됩니다.
- OpenStack 커뮤니티 프로젝트:
- Raksha: OpenStack 환경을 위한 비방해적(non-disruptive), 유연하며 애플리케이션 인식 백업 솔루션을 목표로 합니다. 인스턴스의 전체 및 점진적 백업을 객체 스토리지 엔드포인트로 수행합니다. 아직 공식적으로 통합되지는 않았습니다.
- Freezer: 백업 및 재해 복구 서비스를 위한 새로운 인큐베이팅 프로젝트입니다.
OpenStack Nova의 통합 CLI(openstack) 주요 명령어 정리
OpenStack의 최신 환경에서는 전통적인 nova CLI 대신, openstack 통합 CLI를 사용하여 Nova(Compute) 관련 리소스를 관리하는 것이 표준입니다. 아래는 실무에서 가장 많이 쓰는 Nova 관련 openstack CLI 명령어들입니다.
인스턴스(서버) 관리
인스턴스 목록 조회
- openstack server list
인스턴스 생성
- openstack server create --image <IMAGE> --flavor <FLAVOR> --network <NETWORK> --key-name <KEY> --security-group <SEC_GRP> <INSTANCE_NAME>
인스턴스 삭제
- openstack server delete <INSTANCE_NAME or ID>
인스턴스 상세 정보 확인
- openstack server show <INSTANCE_NAME or ID>
인스턴스 시작/정지/재시작
- openstack server start <INSTANCE_NAME or ID> openstack server stop <INSTANCE_NAME or ID> openstack server reboot <INSTANCE_NAME or ID>
인스턴스 일시정지/해제, 중단/복구
- openstack server pause <INSTANCE_NAME> openstack server unpause <INSTANCE_NAME> openstack server suspend <INSTANCE_NAME> openstack server resume <INSTANCE_NAME>
인스턴스 리사이즈(사양 변경)
- openstack server resize <INSTANCE_NAME> <FLAVOR> openstack server resize --confirm <INSTANCE_NAME>
인스턴스 재빌드(이미지 교체)
- openstack server rebuild <INSTANCE_NAME> <IMAGE>
인스턴스 콘솔 로그 확인
- openstack console log show <INSTANCE_NAME>
키페어 관리
키페어 생성
- openstack keypair create <KEY_NAME> > <KEY_NAME>.pem chmod 600 <KEY_NAME>.pem
키페어 목록
- openstack keypair list
키페어 삭제
- openstack keypair delete <KEY_NAME>
Flavor(사양) 관리
Flavor 목록
- openstack flavor list
Flavor 상세 정보
- openstack flavor show <FLAVOR>
이미지 관리
이미지 목록
- openstack image list
이미지 상세 정보
- openstack image show <IMAGE>
네트워크/보안 그룹
네트워크 목록
- openstack network list
보안 그룹 목록
- openstack security group list
보안 그룹 규칙 추가
- openstack security group rule create <SEC_GRP> --protocol <PROTOCOL> --dst-port <PORT>
'Server-side 개발 & 트러블 슈팅 > Openstack (오픈스택)' 카테고리의 다른 글
[Openstack] 오픈스택 Cinder 블록 저장 스토리지 이론과 설치 및 실행 방법 가이드 (7) | 2025.07.09 |
---|---|
[Openstack] 오픈스택 swift 분산 Object 스토리지 개념 (1) | 2025.07.09 |
[Openstack] 오픈스택 키스톤(Keystone)의 기초 개념과 명령어 (1) | 2025.06.29 |
[Openstack] 오픈스택 클러스터링의 개념과 인프라 서비스와 베포 (0) | 2025.06.29 |
[OpenStack] 오픈스택 클라우드 아키텍처 (2) | 2025.06.29 |
댓글