[Openstack] 오픈스택 강의1 - 클라우드 인프라 서비스의 구조

다음과 같은 링크의 영상을 보고 정리한 내용입니다.

https://www.youtube.com/watch?v=R6nzSH8SEYY

 

- 클라우드 인프라를 구성하는 3가지 실행 환경

: bare metal(물리적인 machine)과 container, 가상 머신을 위한 cloud infrastructure

 

cloud란?

인터넷을 통해 언제 어디서든 컴퓨터 자원을 빌려 쓰는 것이다. 물리적인 it 자원을 가상화하고 추상화된 interface를 만들어 api로 제공함

core component

: nova(computing service), neutron(networking), glance(image service), cinder(block storage), swift(object storage), keystone(identity service)

• 특징: 자원의 상태를 관리하고 자원의 실체는 다른 서비스에게 위임한다. 즉, 오픈스택 자체에는 hardware 가상화를 직접 이용해 가상머신을 생성, 삭제, 관리하는 코드는 없다.

1. nova: kvm 주로 사용, vm을 만들라고 지시하는 역할을 한다.
2. glance: 미리 만들어진 os image resource를 복제해서 인스턴스를 생성한다. cloud-init으로 os 생성/부팅 시 설정 자동화한다.→ cloud-init: 부팅 시 vm이 처음 접속될 때 자동으로 초기 설정해줌 (AWS 기준으로 169.254.169.254라는 특수한 IP로 요청을 보내서 나는 어떤 인스턴스고 어떤 설정을 해야 하나 물어봄)
3. cinder: OpenStack에서 블록 스토리지를 관리해주는 서비스이다. VM에 붙여 쓸 수 있는 가상 디스크 볼륨을 생성하고, VM에 연결해주고, 필요 없으면 삭제한다. 볼륨 스냅샷을 찍어서 백업하거나 스냅샷으로부터 새 볼륨을 만든다. cinder 자체가 스토리지를 직접 저장하지는 않고 스토리지를 관리하는 api 레이어고 실제 데이터는 백엔드 스토리지 (e.g. ceph, lvm)가 저장한다.
4. ceph: 여러 서버의 디스크를 하나로 묶어서 대규모 분산 스토리지를 만들어주는 오픈소스 시스템이다. Ceph의 가장 큰 특징은 중앙 집중식 메타데이터 서버가 없다. 기존 스토리지 시스템은 이 데이터가 어느 디스크에 있는지를 관리하는 중앙 서버가 있는데 이게 병목이 된다. 따라서 Ceph은 CRUSH 알고리즘이라는 계산 방식으로 클라이언트가 직접 데이터 위치를 계산해서 찾아간다. 중간에 거쳐야 할 서버가 없으니 훨씬 빠르고 확장성이 좋다.
5. neutron: 통신이 가능한 layer2 환경을 만들어 주는 것
   vm에게 ip 부여네트워크 분리 기술: vlan 기술 - 스위치를 그냥 케이블을 연결해서 쓰면 같은 스위치에 연결된 서버는 같은 네트워크에 속함. 근데 vlan을 쓰면 같은 스위치에 연결돼도 네트워크 분리 가능 -> 스위치를 더 확장하면 여러 대 스위치에 연결된 같은 vlan_id를 사진 서버끼리 통신 가능, vpc 만들때마다 neutron이 vlan_id 부여

컴포넌트 역할

Nova API	사용자 요청 접수 & 전체 오케스트레이션
Nova Scheduler	VM을 어느 Compute node에 배치할지 결정
Nova Compute	실제 VM 생성 담당 (Compute node 위에서 실행)
Neutron Server	가상 네트워크/포트 생성
Neutron Agent	Compute node에서 OVS 규칙 적용
Cinder API	볼륨 생성 요청 접수
Cinder Volume	실제 블록 스토리지 볼륨 생성
NAS	실제 스토리지 백엔드
libvirt	Nova Compute가 VM을 제어하기 위한 가상화 라이브러리
OpenVSwitch	Compute node의 소프트웨어 스위치
VM	최종 생성되는 가상머신

 

+추가) Cinder 진행 과정

[1] Disk Volume File 만들기

사용자가 VM 생성을 요청하면 Cinder가 OpenStack이 관리하는 스토리지 정보를 조회한다.

A존에 만들어달라고 했으니 Cinder는 A존 NAS 서버 정보를 가져온다.

→ Cinder는 Glance에게 Ubuntu 22.04 OS 이미지를 요청한다. (Glance는 OpenStack에서 OS 이미지를 관리하는 서비스)

→ 이미지는 qcow2 포맷으로 저장되어 있는데 Cinder가 이걸 가져와서 요청한 크기인 100GB에 맞게 raw 포맷으로 변환한다.

→ 변환되면 Cinder는 이 raw 파일을 A존 NAS에 저장한다. 저장 경로는 nfs://172.16.0.100:/volumes/volume-id 같은 NFS 경로가 되고 여기에 100GB짜리 Disk Volume File이 생성된다. 이게 VM의 실제 부팅 디스크가 된다.

즉, cinder는 어느 스토리지에 저장할지 결정하고(스토리지 정보 조회), OS 이미지를 적절한 형태로 변환하고(qcow2 → raw), 실제 NAS에 볼륨 파일을 생성한다. Glance는 OS 이미지 창고 역할만 하고 실제 볼륨 생성과 관리는 전부 Cinder가 담당한다.

 

[2] 실제로 VM이 file을 어떻게 자기 디스크로 사용하는지

 

Hypervisor(VM을 실행하는 물리 서버)가 NAS를 NFS로 마운트한다. (mount -t nfs 172.16.0.100:/volumes /mnt/volumes : NAS의 /volumes 디렉토리가 Hypervisor의 /mnt/volumes 경로로 연결)

hypervisor에게는 NAS에 있는 파일이 로컬 파일처럼 보임

→ 그 다음 VM을 실행할 때 디스크 경로로 /mnt/volumes/volume-id를 지정한다. VM 입장에서는 그냥 로컬 디스크가 연결된 것처럼 느끼지만 실제 데이터는 NAS에 저장됨

 

OpenStack Neutron + OpenVSwitch 네트워크 구조

OpenVSwitch: 하이퍼바이저에서 동작하는 소프트웨어 스위치

VM: 가상머신으로 eth0 NIC을 통해 네트워크에 연결, 물리 인터페이스: 실제 서버의 NIC로 외부 네트워크와 연결

① Neutron → OVS (청록색 화살표): VM이 B 네트워크에 연결되면 Neutron이 해당 네트워크에 맞는 VLAN 정보(여기선 VLAN 200) 를 OVS에 설정

② VM → OVS (빨간색 화살표): VM의 NIC(eth0)은 하이퍼바이저의 OVS 포트에 직접 연결, VM 입장에선 일반 스위치에 꽂힌 것처럼 동작

③ OVS → 물리 인터페이스 (청록색 화살표): OVS가 VM 트래픽에 VLAN 200 태그를 붙여서 물리 NIC으로 내보냄, 물리 네트워크에서 VLAN으로 트래픽 분리

 

하이퍼바이저 내부 네트워크 흐름

 

① VM → OVS: A VM (초록), B VM (빨강), C VM (파랑) 각각 OVS의 포트에 연결, 각 VM은 자신이 속한 가상 네트워크에 따라 다른 VLAN에 매핑됨, Neutron이 이 매핑 정보를 OVS에 미리 설정

② OVS → eth0 (VLAN Tagging): OVS는 나가는 트래픽에 VLAN 태그를 붙임, 여기서 B VM의 트래픽은 VLAN 200 태그가 붙어서 나감 → 이를 통해 물리 네트워크에서도 VM별 트래픽 분리

③ eth0 → 데이터센터: 목적지 IP 192.168.0.100으로 향하는 패킷이 VLAN 200 태그와 함께 물리 네트워크(데이터센터)로 전송

 

인스턴스 생성 과정

1. 사용자 요청 접수: 사용자가 Nova API에 인스턴스 생성 요청
2. 스케줄링: Nova API가 Nova Scheduler에게 어느 Compute node에 VM 올릴지 문의 → Nova Scheduler가 리소스 상태를 확인하고 적합한 Compute node 선택 후 Nova API에 반환
3. 네트워크 준비: Nova API → Neutron Server에게 가상 network port 생성 요청 → Neutron Server가 포트/IP 할당 → Compute node의 Neutron Agent가 OpenVSwitch 에 해당 VM용 VLAN 규칙 설정
4. 스토리지 준비: Nova API가 Cinder API에게 볼륨 생성 요청 → Cinder API에 따라 Cinder Volume가 실제 볼륨 생성 → Cinder Volume은 백엔드인 NAS 에 실제 스토리지 공간 할당
5. VM 생성: Nova API가 선택된 Compute node의 Nova Compute에 VM 생성 지시 → Nova Compute가 libvirt 를 통해 하이퍼바이저에 VM 생성 → VM의 NIC은 OpenVSwitch 포트에 연결됨
6. 완료 보고: Nova Compute가 VM 생성 완료 후 Nova API에 생성 완료 전달 → Nova API가 사용자에게 인스턴스 생성 완료 응답

사용자
  ↓
Nova API → Nova Scheduler (배치 결정)
  ↓              ↓
Neutron Server  Cinder API → Cinder Volume → NAS
  ↓
Nova Compute (Compute node)
  ├── libvirt → VM 생성
  └── Neutron Agent → OpenVSwitch 규칙 적용
  ↓
Nova API ← 생성 완료 전달

 

- 오픈스택 component 동작 방식

모든 컴포넌트 = API 서버 + Agent

API 서버: 클라이언트 또는 다른 컴포넌트의 REST API 요청을 받는 창구

Agent: 실제 IT 자원(VM, Network, Storage)의 생성/삭제/조회 담당, 자원을 직접 다루지 않고 API의 보조역할

외부 클라이언트
      ↓ REST API 호출
  API Server
      ↓
   메시지 큐  ←── Agent (예: Scheduler)
      ↓              (큐에 정보를 넣기도 함)
   Agent들
   ├── Agent → VM
   ├── Agent → Storage
   └── Agent → Network