[DOCS] 5장 1~5절 Glance 강의 문서 작성 (이성연)

lectures/ch5/ch5_1_lec.qmd

@@ -0,0 +1,70 @@
+---
+title: "가상 이미지에 대한 이해 (raw, qcow2 등)"
+---
+
+# OpenStack Glance 서비스 및 가상 이미지 포맷 분석
+
+## 1. 개요
+* OpenStack에서 가상 머신(VM)의 근간이 되는 OS 템플릿을 관리하는 Glance 서비스와 가상 이미지 포맷의 특성을 분석합니다.
+* 클라우드 환경에서 운영체제 이미지는 단순한 파일이 아닌, 인프라의 성능과 저장 공간 효율성을 결정짓는 핵심 자산입니다.
+
+## 2. 가상 이미지(Virtual Image)의 정의 및 역할
+가상 이미지는 가상 머신(VM)을 실행하기 위해 필요한 운영체제(OS), 애플리케이션, 그리고 시스템 설정 데이터가 포함된 '디지털 템플릿' 입니다.
+
+* **기술적 정체**: 물리적 하드디스크의 상태를 하나의 파일로 캡처(Capture)한 바이너리 데이터 덩어리입니다.
+* **클라우드에서의 역할**: 매번 OS를 수동으로 설치할 필요 없이, 미리 구성된 이미지를 복제하여 수초 내에 동일한 환경의 인스턴스를 대량으로 배포하는 근간이 됩니다.
+
+## 3. 가상 이미지 포맷의 종류 및 비교 분석
+클라우드 생태계에는 다양한 하이퍼바이저(Hypervisor)가 존재하며, 각 환경에 최적화된 여러 이미지 포맷이 사용됩니다.
+
+| 포맷 | 풀 네임 | 주요 특징 및 용도 |
+|---|---|---|
+| **RAW** | Raw Binary | 가공되지 않은 순수 디스크 데이터. 구조가 단순하여 I/O 성능이 가장 뛰어나지만, 실제 데이터와 무관하게 전체 용량을 점유합니다. |
+| **QCOW2** | QEMU Copy-On-Write 2 | OpenStack의 표준 포맷. 쓴 만큼만 용량을 차지하는 'Thin Provisioning'과 '스냅샷' 기능을 지원하여 클라우드 운영 효율이 가장 높습니다. |
+| **VMDK** | Virtual Machine Disk | VMware 환경의 표준 규격입니다. 엔터프라이즈 환경에서 널리 쓰이며 오픈스택과의 호환성도 뛰어납니다. |
+| **VHD/VHDX** | Virtual Hard Disk | Microsoft Hyper-V 및 Azure에서 주로 사용되는 포맷입니다. |
+| **VDI** | VirtualBox Disk Image | Oracle VirtualBox의 네이티브 포맷으로 주로 개인 개발 환경에서 사용됩니다. |
+| **ISO** | Optical Disk Image | CD/DVD 등의 광학 미디어를 파일화한 것으로, 주로 OS 설치용 매체로 활용됩니다. |
+
+## 4. Glance의 이미지 처리 메커니즘
+Glance 서비스가 사용자로부터 이미지를 받아 저장하고 관리하는 상세 과정은 다음과 같습니다.
+
+### 4.1 이미지 등록 및 업로드 라이프 사이클
+1. **API 접수 (Request)**: 사용자가 이미지 업로드를 요청하면 Glance API가 이를 수신합니다.
+2. **메타데이터 기록 (Registry)**: 이미지의 이름, 포맷, 가시성(Visibility) 등의 정보를 Glance DB에 먼저 기록합니다. (상태: queued)
+3. **바이너리 스트리밍 (Storage)**: 실제 이미지 본체 데이터를 드라이버를 통해 Backend Store (NAS, Swift, Ceph 등)로 전송합니다. (상태: saving)
+4. **무결성 검증 (Checksum)**: 전송이 끝나면 MD5/SHA-256 해시값을 대조하여 데이터가 변조되거나 깨지지 않았는지 확인합니다.
+5. **최종 활성화 (Active)**: 검증이 완료되면 이미지를 사용할 수 있는 상태인 active 로 변경합니다.
+
+### 4.2 이미지 변환 및 배포 최적화
+* **Image Conversion**: 특정 하이퍼바이저가 지원하지 않는 포맷일 경우, Glance는 내부도구(qemu-img)를 사용하여 가상 머신이 읽을 수 있는 포맷으로 변환 과정을 거칩니다.
+* **Image Caching**: 자주 호출되는 이미지는 컴퓨팅 노드(Nova)에 캐싱하여 네트워크 트래픽을 줄이고 배포 속도를 가속화합니다.
+
+## 5. Glance 이미지 관리 논리 구조
+```mermaid
+graph TD
+    User((User))
+    API[Glance API]
+    DB[(Glance DB: Metadata)]
+    Store{Backend Store}
+
+    User -- "1. Upload Request" --> API
+    API -- "2. Write Metadata" --> DB
+
+    subgraph "Image Processing"
+        API -- "3. Stream Binary" --> Store
+    end
+
+    Store -- "4. Checksum" --> API
+    API -- "5. Set Status: Active" --> User
+
+    subgraph "Supported Formats"
+        F1[RAW / QCOW2]
+        F2[VMDK / VHD]
+        F3[ISO / VDI]
+    end
+
+    Store -.-> F1
+    Store -.-> F2
+    Store -.-> F3
+```

lectures/ch5/ch5_2_lec.qmd

@@ -0,0 +1,106 @@
+---
+title: "Image Metadata 구조"
+---
+
+# OpenStack Glance Image Metadata 구조 및 체계 분석
+
+## 1. 개요
+클라우드 환경에 이미지를 업로드하면 용량이나 디스크 포맷(QCOW2 등) 같은 '물리적인 기본 정보'는 자동으로 기록됩니다. 하지만 수십, 수백 개의 이미지가 운영되는 실제 환경에서는 이런 기본 정보만으로 인프라를 제대로 통제하기 어렵습니다. 실제(실무) 환경에서는 배치 문제, 보안 통제, 자원 관리와 같은 실무적인 고민들이 발생할 수 있습니다. 이러한 문제를 해결하기 위해, 관리자가 직접 이미지에 세밀한 '꼬리표(태그)'를 달아 목적에 맞게 분류하고 제어하는 기능이 바로 사용자 정의 메타데이터(Custom Metadata)입니다. 
+
+## 2. 사용자 정의 메타데이터 관리 명령어 CRUD
+오픈스택 CLI에서는 '추가'와 '수정'이 하나의 명령어(set)로 통합되어 동작하는 것이 특징입니다. 
+
+### 2.1 추가 및 수정 (Add / Update)
+* **명령어**: `set` 
+* **원리**: 입력한 키(Key)가 기존에 없으면 새롭게 추가되고, 이미 존재하는 키라면 입력한 값(Value)으로 수정(덮어쓰기) 됩니다. 
+
+```bash
+# 사용법
+openstack image set-property <키>=<값> <이미지ID_또는_이름> 
+
+# 예시 (해당 이미지가 프론트엔드 부서용임을 추가/수정할 때)
+openstack image set-property department=frontend_dev ubuntu-24.04-custom 
+```
+
+### 2.2 삭제 (Delete)
+* **명령어**: `unset` 
+* **원리**: 더 이상 필요 없는 사용자 정의 속성을 지정하여 이미지에서 완전히 떼어냅니다. 
+
+```bash
+# 사용법
+openstack image unset-property <키> <이미지ID_또는_이름> 
+
+# 예시 (부서 지정 속성을 삭제할 때)
+openstack image unset-property department ubuntu-24.04-custom 
+```
+
+### 2.3 적용 결과 확인 (Read / Verify)
+* **명령어**: `show` 
+* **원리**: 메타데이터를 조작한 후에는 반드시 해당 이미지의 전체 정보를 조회하여 properties 항목에 변경 사항이 잘 들어갔는지 확인해야 합니다. 
+
+```bash
+# 사용법 (결과창의 properties 필드 확인)
+openstack image show ubuntu-24.04-custom 
+```
+
+> **💡 TIP**: OpenStack CLI 환경에서는 메타데이터의 '추가'와 '수정'을 별도의 명령어 구분 없이 `set` 명령어 하나로 처리합니다. 키(Key)의 존재 여부에 따라 자동으로 분기되기 때문에, 작업 후에는 반드시 `show` 명령어로 검증하는 습관이 필요합니다. 
+
+## 3. Metadata 논리 구조도
+아래 다이어그램은 Glance 데이터베이스 내에서 기본 속성과 사용자 정의 속성이 어떻게 구조화되어 관리되는지 보여줍니다. 
+
+```mermaid
+graph TD
+    %% 전체 서비스 구조
+    GlanceDB[(Glance Database)] --- ImageObject[Image Object Entity] 
+
+    %% 이미지 객체 하위 구조
+    ImageObject --> BaseProps[Base Properties<br/>기본 속성 - 필수/고정]
+    ImageObject --> CustomProps[User-defined Properties<br/>사용자 정의 속성 - 선택/가변]
+
+    %% 기본 속성 세부 항목
+    subgraph "System Mandatory Fields"
+        BaseProps --> B1[UUID / Name]
+        BaseProps --> B2[Status: active, saving...]
+        BaseProps --> B3[Disk Format: RAW, QCOW2...]
+        BaseProps --> B4[Container Format: bare...]
+        BaseProps --> B5[Min RAM / Min Disk]
+    end
+
+    %% 사용자 정의 속성 세부 항목
+    subgraph "Customizable Metadata Schema"
+        CustomProps --> C1[OS Distro: Ubuntu, Windows...]
+        CustomProps --> C2[Architecture: x86_64, ARM64...]
+        CustomProps --> C3[HW Virtualization: hw_scsi_model...]
+        CustomProps --> C4[Visibility: Public, Private, Shared]
+    end
+
+    %% 실제 데이터와 연결
+    ImageObject -->|Pointer| BackendStore{Glance Backend Store<br/>Actual Image Binary Data}
+
+    %% 스타일 정의
+    style ImageObject fill:#f9f,stroke:#333,stroke-width:2px
+    style GlanceDB fill:#e1f5fe,stroke:#01579b
+    style BackendStore fill:#fff3e0,stroke:#e65100
+```
+
+## 4. Metadata 아키텍처 및 저장 원리
+Glance의 이미지는 '이미지 바이너리 데이터'와 이를 설명하는 '메타데이터'로 분리되어 관리됩니다. 
+
+* **데이터베이스 관리**: 메타데이터는 빠른 검색과 인덱싱을 위해 Glance 데이터베이스(DB) 내에 구조화된 형태로 저장됩니다. 
+* **스토어 분리**: 실제 대용량 이미지 파일은 Glance 백엔드 스토어(Backend Store)에 보관되며, 메타데이터는 이 위치를 가리키는 포인터 정보를 포함합니다. 
+* **검증 프로세스**: 사용자가 VM 생성을 요청할 시, 시스템은 메타데이터를 우선 조회하여 하드웨어 사양(Min RAM 등)의 적합성 여부를 검토합니다. 
+
+## 5. 주요 구성 범주 분석 
+
+### 5.1 시스템 기본 속성 (Base Properties) 
+이미지 등록 시 시스템에 의해 필수적으로 요구되거나 생성되는 고유 속성입니다. 
+* **ID / Name**: 이미지의 고유 식별 번호 및 명칭 
+* **Status**: 현재 이미지의 가용 상태 (예: active, queued) 
+* **Disk Format**: 가상 디스크 저장 방식 (예: RAW, QCOW2) 
+* **Resource Constraints**: 구동에 필요한 최소 RAM 및 디스크 용량 명시 
+
+### 5.2 사용자 정의 속성 (Image Properties) 
+운영 효율성을 위해 관리자가 임의로 부여하는 키-값(Key-Value) 형태의 메타데이터입니다. 
+* **OS Information**: 운영체제의 배포판 및 버전 정보 
+* **Hardware Properties**: 특정 가상 하드웨어 모델(NIC, 디스크 컨트롤러) 지정 
+* **Visibility**: 이미지의 공개 및 공유 범위 정의 (Public, Private, Shared)

lectures/ch5/ch5_3_lec.qmd

@@ -0,0 +1,87 @@
+---
+title: "Glance Backend Store에 대한 개념"
+---
+
+# OpenStack Glance Backend Store 개념 및 구조 분석
+
+OpenStack Glance의 스토리지 아키텍처를 이해할 때, 가장 먼저 짚고 넘어가야 할 부분은 '실제 저장 공간'과 이를 연결하는 '설정 영역'의 차이를 명확히 구분하는 것입니다. 실무 환경에서는 이 두 가지를 혼용해서 부르기 쉽지만, 시스템 상에서는 엄연히 다른 역할을 수행합니다. 
+
+* **Glance Backend Store (물리/논리적 저장소)**: 가상 머신의 이미지가 실제로 보관되는 '물리적 또는 논리적인 저장 공간 그 자체'를 의미합니다. 로컬 서버의 하드디스크(file), 분산 객체 스토리지(swift), 블록 스토리지(cinder 또는 ceph) 등이 여기에 해당하며, 비유하자면 이미지가 쌓이는 '실제 창고'입니다. 
+* **[glance_store] (연동 설정 구역)**: Glance 프로그램이 위에서 언급한 창고(Backend Store)들을 찾아가기 위해 사용하는 `glance-api.conf` 파일 내의 설정 섹션입니다. 어떤 드라이버를 로드할지, 저장소의 주소는 어디인지, 인증 계정은 무엇인지를 정의하며, 창고 문을 열기 위한 '내비게이션과 열쇠' 역할을 합니다. 
+
+## 1. Glance Backend Store 구조
+아래 다이어그램은 사용자 요청이 Glance API를 거쳐 실제 물리적 저장소인 백엔드 스토어에 도달하는 논리적 흐름을 나타냅니다. 
+
+```mermaid
+graph LR
+    User[Client / User] -- API Request --> G_API[Glance API] 
+    G_API -- Metadata Query --> G_DB[(Glance DB)] 
+
+    subgraph "Glance Backend Stores"
+        G_API -- "Store Driver (Store Library)" --> Drivers{Storage Drivers}
+        Drivers -- File System --> Local[Local Disk / NFS]
+        Drivers -- Object Storage --> Swift[OpenStack Swift / Ceph RGW]
+        Drivers -- Block Storage --> Cinder[OpenStack Cinder]
+        Drivers -- Distributed --> Ceph[Ceph RBD]
+    end
+
+    %% 스타일 정의
+    style G_API fill:#f9f,stroke:#333,stroke-width:2px
+    style G_DB fill:#e1f5fe,stroke:#01579b
+    style Drivers fill:#fff3e0,stroke:#e65100
+```
+
+## 2. 주요 백엔드 스토어 유형 및 특징
+Glance는 인프라 환경의 규모와 요구 성능에 따라 다음과 같은 다양한 스토어 타입을 지원합니다. 
+
+| 스토어 타입 | 기술적 특성 | 활용 사례 |
+|---|---|---|
+| **File (Filesystem)** | 호스트 서버의 로컬 디스크나 NFS(Network File System)를 이용하는 방식입니다. | 단일 노드 테스트 혹은 소규모 환경 |
+| **Swift** | OpenStack의 오브젝트 스토리지 서비스인 Swift와 연동하여 데이터를 분산 저장합니다. | 대규모 클라우드 및 고가용성 보장 필요 시 |
+| **Ceph (RBD)** | 분산 스토리지 솔루션인 Ceph를 백엔드로 사용하며, 현재 실무에서 가장 많이 선호되는 방식입니다. | 고성능, 확장성 중심의 엔터프라이즈 인프라 |
+| **Cinder** | OpenStack의 블록 스토리지인 Cinder를 이미지 저장소로 활용합니다. | 스토리지 인프라를 Cinder로 통합 운영할 경우 |
+| **HTTP** | 외부 웹 서버에 있는 읽기 전용 이미지를 가져오는 방식입니다. | 외부 공개 이미지를 직접 배포할 경우 |
+
+## 3. 백엔드 스토어의 동작 원리
+사용자가 이미지를 업로드하거나 다운로드할 때 Glance는 다음과 같은 순서로 백엔드 스토어와 상호작용합니다. 
+
+1. **드라이버 호출**: Glance API는 설정 파일(`glance-api.conf`)에 정의된 백엔드 스토어 드라이버를 로드합니다. 
+2. **데이터 전달**: 사용자가 전송한 이미지 바이너리 데이터를 선택된 드라이버를 통해 백엔드 저장소로 스트리밍합니다. 
+3. **위치 정보(Location URI) 저장**: 업로드가 완료되면, 이미지가 저장된 물리적 위치 주소를 생성하여 Glance DB의 메타데이터 영역에 기록합니다. 
+
+## 4. glance-api.conf 설정 파일과 백엔드 스토어 연동
+Glance API와 저장소 간의 통신 로직은, 실제 서버의 `/etc/glance/glance-api.conf` 파일 내 `[glance_store]` 섹션 설정을 통해 제어됩니다. 스토리지 설정의 원리를 가장 직관적으로 이해하기 위해, 성격이 완전히 대비되는 두 가지 방식인 File 스토어(로컬)와 Swift 스토어(외부 네트워크)의 설정 방법을 비교해 보겠습니다. 
+
+* **File과 Swift의 차이**: File 방식은 내 서버의 로컬 하드디스크에 이미지를 저장하므로 단순히 '저장할 폴더 경로'만 알려주면 됩니다. 반면 Swift는 네트워크 너머에 있는 독립된 대규모 객체 스토리지이므로, 단순히 주소뿐만 아니라 "내가 누구인지" 증명하는 인증(Authentication) 정보가 필수적으로 추가되어야 한다는 뚜렷한 구조적 차이가 있습니다. 
+
+### 4.1 File 스토어 설정 예시 (로컬 디스크 기반)
+가장 기본적인 형태로, 단일 노드 테스트 환경 등에서 주로 사용됩니다. 
+
+```ini
+[glance_store] 
+# 사용 가능한 스토어 드라이버 목록 
+stores = file, http 
+# 이미지를 업로드할 때 사용할 기본 스토어 지정 
+default_store = file 
+# (File 전용) 이미지가 실제로 저장될 로컬 서버의 절대 경로 
+filesystem_store_datadir = /var/lib/glance/images/ 
+```
+
+### 4.2 Swift 스토어 설정 예시 (분산 객체 스토리지 연동)
+외부 스토리지와 연동해야 하므로, 인증 서버(Keystone)의 주소와 Glance 서비스 계정 정보가 추가로 필요합니다. 
+
+```ini
+[glance_store] 
+stores = swift, http 
+default_store = swift 
+
+# (Swift 전용) 인증을 처리할 Keystone 서버 주소 
+swift_store_auth_address = http://controller:5000/v3/ 
+
+# (Swift 전용) Swift에 접근하기 위한 Glance 서비스 계정 이름 및 비밀번호 
+swift_store_user = service:glance 
+swift_store_key = <GLANCE_PASSWORD> 
+
+# (Swift 전용) 이미지를 담을 Swift 컨테이너(버킷) 명칭 
+swift_store_container = glance 
+```