OpenStack Glance: Managing VM Images

Summary

Glance는 OpenStack의 Image Service다. VM을 생성할 때 사용하는 운영체제 이미지와 이미지 정보를 등록·조회·관리하고, Nova와 Cinder 같은 다른 서비스가 이미지를 사용할 수 있도록 API를 제공한다.

Glance
→ VM boot image 관리

Nova
→ Glance image를 기반으로 VM 생성

Glance는 단순한 파일 저장소가 아니다. 이미지의 metadata, 접근 권한, 상태, 업로드와 다운로드를 관리하고, 실제 binary data는 연결된 storage backend에 저장한다.

Glance가 VM을 실행하거나 network를 연결하는 것은 아니다. Glance는 재사용할 원본 image를 제공하고, Nova가 compute resource와 instance lifecycle을, Neutron이 network를 담당한다.

Architecture

Glance의 기본 구조를 단순화하면 다음과 같다.

User / Nova / Cinder
         │
    Keystone Token
         │
         ▼
     glance-api
      ┌──┴──────────────┐
      ▼                 ▼
Glance Database    glance_store
   Metadata             │
                       ▼
                Storage Backend

Glance API

glance-api는 Image API 요청을 처리한다.

• 이미지 생성, 조회, 수정과 삭제
• 이미지 data upload와 download
• visibility와 project sharing 관리
• image import workflow 처리
• policy와 quota 확인

요청자는 일반적으로 Keystone token으로 인증한다. 실제 수행 가능 범위는 Glance policy와 OpenStack role에 따라 결정되므로, 모든 사용자가 public image를 만들거나 삭제할 수 있는 것은 아니다.

Metadata Database

Glance database에는 binary image 자체가 아니라 다음과 같은 catalog 정보가 저장된다.

• image ID와 name
• status와 visibility
• owner project
• disk format과 container format
• virtual size와 actual size
• checksum, os_hash_algo, os_hash_value
• minimum disk와 RAM
• OS 종류와 version 같은 custom property
• 생성 및 수정 시간

Metadata만 남아 있고 image data가 backend에 없으면 정상적인 VM boot image로 사용할 수 없다. 반대로 backend에 파일만 복사하고 Glance에 등록하지 않으면 OpenStack의 image catalog에서 찾을 수 없다.

Storage Backend

실제 qcow2, raw, iso 파일은 Glance가 사용하는 storage backend에 저장된다.

Glance
= Image management service

Glance Store Backend
= Image binary storage

Glance는 storage system 자체를 대체하지 않는다. glance_store driver를 통해 backend에 image data를 저장하고 접근을 관리한다. 한 cloud에 여러 store를 구성하는 multi-store도 가능하지만, 지원 기능과 download 경로는 backend 조합에 따라 달라진다.

Image and Instance Disk

Glance image는 여러 VM을 만들기 위한 원본 template이다. 실행 중인 VM의 root disk와 같은 데이터가 아니다.

Glance
└── Ubuntu Cloud Image

Compute Nodes
├── worker-01 root disk
├── worker-02 root disk
└── worker-03 root disk

VM을 삭제해도 Glance 원본 image는 그대로 남는다. 반대로 Glance image를 삭제해도 이미 생성되어 독립적인 root disk를 사용하는 VM의 disk가 즉시 함께 삭제되는 것은 아니다. 다만 새 VM 생성과 rebuild에는 해당 image를 더 이상 사용할 수 없다.

Image data는 기본적으로 같은 image ID에서 임의로 덮어쓰는 mutable disk처럼 다루지 않는다. OS patch나 설정을 반영한 새 template이 필요하면 새 image version을 만들고, 검증 후 workload가 참조하는 image ID를 변경하는 방식이 안전하다.

Nova Boot Flow

Image-backed VM이 생성되는 일반적인 흐름은 다음과 같다.

User requests a server
        │
        ▼
Nova validates image metadata in Glance
        │
        ▼
Nova schedules a compute host
        │
        ▼
Compute obtains the base image
        │
        ├── Download from Glance
        ├── Use a local image cache
        └── Access a shared Ceph backend
        │
        ▼
Create an instance root disk
        │
        ▼
QEMU/KVM boots the VM

Compute node는 처음 사용하는 image를 local cache에 저장할 수 있다. 같은 image로 다음 VM을 만들 때 cache를 재사용하면 download traffic과 boot latency를 줄일 수 있다. Cache lifecycle과 cleanup은 Nova 설정에 따라 관리된다.

Glance와 Nova가 모두 Ceph RBD를 사용하면 data를 HTTP로 내려받아 다시 저장하는 대신 Ceph의 copy-on-write 기능을 활용할 수 있는 구성이 가능하다. 실제 경로는 Nova의 images_type, Glance store와 direct URL 관련 설정에 따라 달라진다.

Boot-from-volume에서는 Cinder가 Glance image를 바탕으로 boot volume을 만들고 Nova가 그 volume을 VM에 연결한다. 따라서 모든 VM boot가 반드시 compute node의 local root disk를 만드는 것은 아니다.

Image Formats

qcow2

qcow2는 QEMU의 copy-on-write image format으로 OpenStack lab과 cloud image에서 널리 사용된다.

• Sparse allocation과 copy-on-write 지원
• Raw보다 실제 파일 크기가 작을 수 있음
• Snapshot, compression 같은 format 기능 제공
• Metadata 구조 때문에 raw보다 처리 overhead가 생길 수 있음

파일 이름이 .img라고 해서 format이 raw인 것은 아니다. 등록하기 전에 실제 format을 확인해야 한다.

qemu-img info --output=json noble-server-cloudimg-amd64.img

raw

Raw image는 별도 format metadata가 없는 단순한 disk byte representation이다.

• 구조가 단순하고 backend에서 효율적으로 처리할 수 있음
• Virtual size 전체를 저장하면 용량이 커질 수 있음
• Ceph RBD 같은 backend와 조합할 때 적합할 수 있음

iso

ISO는 일반적으로 운영체제 installer나 live media에 사용한다. 무인 설치 pipeline을 별도로 구성하지 않는다면, VM을 빠르게 자동 생성하는 작업에는 OS가 이미 설치된 Cloud Image가 더 적합하다.

disk_format을 실제 payload와 다르게 지정하면 boot 실패뿐 아니라 image 처리 과정의 보안 문제를 만들 수 있다. 신뢰할 수 있는 출처에서 image를 받고 checksum과 signature를 검증하는 것이 중요하다.

Cloud Images and cloud-init

Cloud Image는 cloud 환경에서 자동으로 부팅하도록 준비된 VM image다. 일반 설치 ISO와 달리 운영체제가 이미 설치되어 있으며, 보통 cloud-init으로 instance별 초기 설정을 받는다.

Ubuntu Cloud Image
        │
Nova creates a VM
        │
cloud-init reads metadata and user data
        │
        ├── Adds an SSH public key
        ├── Creates users
        ├── Sets the hostname
        └── Runs initial commands

동적 Worker처럼 반복해서 짧은 시간 안에 생성해야 하는 VM에는 installer ISO보다 Cloud Image가 적합하다. 다만 cloud-init에 장시간 설치 작업을 모두 넣으면 boot 완료 판단과 재시도 처리가 어려워질 수 있으므로, 최소 bootstrap 이후 Ansible이나 image baking pipeline으로 책임을 나눌 수 있다.

Image Lifecycle and Visibility

Common Statuses

Nova는 일반적으로 active image를 사용한다. Image가 queued에 오래 머무르면 upload가 시작되지 않았는지, saving이나 importing에서 멈추면 Glance log와 backend capacity·permission을 확인해야 한다.

Visibility

shared image는 대상 project를 image member로 추가하는 절차가 필요하고, 환경과 workflow에 따라 member가 공유를 수락해야 사용할 수 있다. public image 생성은 보통 operator policy로 제한된다.

단일 project의 전용 Worker image라면 private가 안전한 기본값이다. 여러 project에 배포할 검증된 base image만 shared 또는 public으로 노출하는 편이 좋다.

Registering an Image

Ubuntu Cloud Image를 private image로 등록하는 예시는 다음과 같다.

openstack image create ubuntu-24.04-worker \
  --file noble-server-cloudimg-amd64.img \
  --disk-format qcow2 \
  --container-format bare \
  --private \
  --property os_distro=ubuntu \
  --property os_version=24.04

--disk-format은 확장자가 아니라 qemu-img info로 확인한 실제 format과 일치해야 한다. 등록 후에는 다음 정보를 확인한다.

openstack image list
openstack image show ubuntu-24.04-worker

status: active
disk_format: qcow2
container_format: bare
visibility: private
size and virtual_size
checksum or os_hash_value

반복 가능한 운영 환경에서는 Horizon에서 수동 upload하기보다 CLI, Ansible 또는 image pipeline으로 출처, checksum, property와 visibility를 함께 관리하는 것이 좋다.

Image, Snapshot, and Volume

Volume-backed server의 snapshot은 local root disk snapshot과 경로가 다르며 Cinder의 volume snapshot이나 image 생성 workflow가 관여할 수 있다. 따라서 VM snapshot은 항상 동일한 방식으로 Glance에 저장된다고 가정하면 안 된다.

Glance는 VM image catalog이지 application file, database data, container image를 저장하는 범용 repository는 아니다. Docker image는 container registry가, persistent application data는 Cinder, NFS, CephFS나 object storage가 담당한다.

Kolla-Ansible Configuration

Kolla-Ansible에서는 /etc/kolla/globals.yml에서 Glance와 backend를 설정한다.

단일 node lab의 File backend 예시는 다음과 같다.

enable_glance: "yes"
glance_backend_file: "yes"

이 설정은 Glance service와 저장 방식을 배포하는 것이며 실제 Ubuntu image를 자동 등록하는 것은 아니다.

globals.yml
→ Deploys Glance and configures its store

openstack image create
→ Registers actual image metadata and data

File backend의 기본 data directory는 Kolla Docker volume에 둘 수 있다. 단일 glance-api가 동작하는 lab에는 간단하지만, controller를 여러 대 운영하면 각 node의 local directory가 서로 다른 image를 보지 않도록 shared filesystem이나 분산 backend가 필요하다.

Kolla-Ansible은 File backend의 경로를 NFS 같은 공유 filesystem에 둘 수 있다.

glance_backend_file: "yes"
glance_file_datadir_volume: "/path/to/shared/storage/"

Ceph RBD를 사용할 때는 Glance용 pool, user와 keyring을 준비하고 backend를 활성화한다.

glance_backend_ceph: "yes"

단일 controller 실습에서는 local File backend가 단순하다. 운영 환경에서는 controller 장애, image 용량, upload/download throughput, backup, multi-store와 Nova backend 구성을 함께 고려해야 한다.

Dynamic Swarm Worker Example

동적 Swarm Worker VM을 만드는 프로젝트에서 Glance는 Ubuntu Cloud Image를 제공한다.

Verified Ubuntu Cloud Image
        │
Registered in Glance
        │
Nova creates a Worker VM
        │
Neutron attaches network connectivity
        │
cloud-init or Ansible bootstraps the VM
        │
Docker installation
        │
ZeroTier join and NFS mount
        │
Swarm Worker join

Glance image에는 공통 OS package와 cloud-init을 준비하고, project별 secret이나 일회성 join token은 넣지 않는 것이 좋다. Secret은 instance 생성 시 안전한 전달 경로로 주입하고, image를 갱신하면 새 ID와 version을 만들어 rollback 가능한 상태를 유지한다.

Common Misconceptions

• Glance는 VM을 실행하지 않고 boot image를 관리한다.
• Glance database에는 image metadata가, store backend에는 binary data가 저장된다.
• Glance 원본 image와 실행 중인 VM root disk는 서로 다른 resource다.
• .img 확장자만으로 qcow2인지 raw인지 판단할 수 없다.
• File backend는 단순하지만 host-local directory만으로 HA가 보장되지는 않는다.
• Server snapshot과 Cinder volume snapshot은 같은 resource가 아니다.
• Cloud Image의 cloud-init과 Glance는 서로 다른 역할을 담당한다.
• Glance는 Docker container image registry나 일반 object storage가 아니다.

Key Takeaways

• Glance는 VM image의 catalog, metadata, lifecycle, visibility와 data access를 관리한다.
• 실제 image data는 Glance가 연결한 File, Ceph RBD, Swift 같은 backend에 저장된다.
• Nova는 Glance image를 확보해 instance root disk를 만들거나 Cinder boot volume을 사용한다.
• Cloud Image와 cloud-init을 사용하면 반복적인 VM bootstrap을 자동화할 수 있다.
• Image format, hash, source와 visibility를 검증해야 안전한 base image를 운영할 수 있다.
• Kolla-Ansible의 File backend는 lab에 적합하지만 HA 환경에서는 shared storage 설계를 함께 고려해야 한다.

Review Questions

1. Glance database와 store backend에는 각각 무엇이 저장되는가?
2. Glance image와 실행 중인 VM root disk는 어떻게 다른가?
3. Nova가 같은 image로 두 번째 VM을 더 빠르게 만들 수 있는 이유는 무엇인가?
4. private, shared, community, public visibility는 어떻게 다른가?
5. File backend를 여러 controller에서 사용할 때 shared storage가 필요한 이유는 무엇인가?
6. 동적 Worker image 안에 project secret을 넣으면 안 되는 이유는 무엇인가?

References

• Glance Documentation
• Image Service API v2
• Glance Image Statuses
• Glance Disk and Container Formats
• Nova KVM Image Configuration
• Kolla-Ansible Glance Guide
• Kolla-Ansible External Ceph Guide