Openstack Storage - Cinder/Manila/Ceph

이 책을 바탕으로 작성됨

---

Cinder

• OpenStack의 Cinder 서비스는 VM의 하드 드라이브를 위한 영구적인 블록 스토리지 관리를 제공함
• 이전에는 nova-volume의 일부였지만, 기능이 많아지면서Cinder로 분리됨
• Cinder 볼륨은 가상머신에 추가 하드디스크처럼 붙이며, VM이 꺼져도 데이터는 유지됨
• Cinder의 주요 기능:
  • 볼륨 관리: 볼륨 생성 또는 삭제를 허용함
  • 스냅샷 관리: 볼륨 스냅샷을 생성하거나 삭제할 수 있음
  • 인스턴스에 볼륨 연결/분리: 가상 머신에 볼륨을 연결하거나 분리할 수 있음
  • 볼륨 복제: 기존 볼륨을 복제할 수 있음
  • 스냅샷에서 볼륨 생성: 스냅샷을 기반으로 새 볼륨을 생성할 수 있음
  • 이미지를 볼륨으로 복사 및 그 반대: 이미지를 볼륨으로 또는 볼륨을 이미지로 복사할 수 있음
• Cinder의 네트워크 연결 방식
  • Cinder는 다음 방식 중 하나로 스토리지를 VM에 연결:
    • iSCSI, NFS 등..
      → 실제로는 스토리지를 네트워크로 전달해주는 방식
    • iSCSI: 네트워크를 통해 디스크를 연결하는 스토리지 프로토콜
      • 로컬에 디스크가 없더라도, 원격 서버의 디스크를 내 컴퓨터처럼 사용할 수 있게 해줌
      • TCP/IP를 통해 블록 디바이스를 전달함
• Cinder는 tenant단위로 스토리지 사용량 제한 가능

---

Cinder Components

• Cinder API Server:
  • 외부로부터 REST API 요청을 받음 (볼륨 생성, 삭제 등)
• Cinder Scheduler
  • 볼륨을 어느 Cinder Volume Server에 배치할지 결정
• Cinder Volume Server
  • 실제 물리 디스크(LVM 기반 볼륨)를 호스팅하는 서버

LVM 기반 볼륨

• Logical Volume Manager: 리눅스에서 사용하는 유연한 디스크 파티셔닝 및 관리 시스템
• 기존 디스크 관리 방식은:
  • HDD -> partition -> format -> moount
  • 기존 방식은 파티션을 미리 정확히 나누어야하기에, 공간 변동에 대응하기 어려움
  • 디스크 추가/확장이 번거러움
  • 이런 기존 방식을 보완하기 위한게 LVM
• LVM은 세 단계로 구성됨
  • 1단계: Physical Volume (PV)
    • 실제 디스크 장치 혹은 파티션
  • 2단계: Volume Group (VG)
    • 여러 PV를 묶어서 하나의 큰 논리적 pool을 만듦
    • 이 풀에서 원하는 크기만큼 나눠서 LV를 만들 수 있음
  • 3단계: Logical Volume (LV)
    • 실제 파일시스템을 올리고 마운트하는 공간 (파티션처럼 동작)
  • 장점:
    • 크기 조절에 유연함
    • 디스크 추가에 자유로움
    • 스냅샷 가능함
    • 여러 개의 디스크를 하나처럼 사용할 수 있음

• iSCSI initiator: 디스크를 요청하는 쪽 (Nova Compute node)
• iSCSI Target: 디스크르르 제공하는 쪽 (Cinder Volume server)
• Cinder가 Cinder Volume server에 있는 LVM 볼륨을 iSCSI로 공유함
• LibVirt:
  • 리눅스에서 가상화를 제어하고 관리하는 라이브러리
  • KVM 같은 hypervisor를 통합적으로 관리할 수 있게 도와주는 인터페이스임
• 볼륨 연결 과정
  • Cinder 볼륨 생성: 볼륨 이름과 크기를 지정하여 Cinder 볼륨을 생성함
    • Cinder의 기본 볼륨 드라이버는 iSCSI를 통한 LVM
    • 볼륨 그룹(VG)에 논리 볼륨(LV)을 생성함
  • Nova 인스턴스에 볼륨 연결:  Cinder 볼륨을 Nova 인스턴스에 연결함
    • 생성된 LV를 컴퓨트 노드에 iSCSI Qualified Name (IQN)으로 제공함
    • IQN: 스토리지 대상 (target)을 고유하게 식별하기 위한 이름
  • 가상 머신에 볼륨 제공: 마지막으로 Libvirt 라이브러리를 사용하여 iSCSI 드라이브를 가상 머신에 추가 블록 장치로 제공함

---

Cinder 백엔드 드라이버 및 스케줄링

• Cinder는 플러그인 아키텍처를 제공하여 다양한 스토리지 백엔드 드라이버를 노출함
• 기본 백엔드 드라이버는 LVM-iSCSI이며, NFS(파일 공유 중심), GlusterFS(고가용성 분산 스토리지) 및 NetApp(기업용 상용 스토리지)과 같은 다양한 스토리지로 구성할 수 있음
  • 다중 백엔드 활성화
    • 여러 백엔드 드라이버를 동시에 활성화할 수 있음
  • 스케줄러 구성
    • 새로운 볼륨을 어떤 Cinder volume 노드에 생성할지 결정하는 컴포넌트
    • 스케줄러는 기본적으로 capacity, availability zone, capability filters로 구성될 수 있음
  • 볼륨 유형 정의
    • 사용자는 cinder 정의를 사용하여 특정 백엔드 드라이버로 볼륨을 요청할 수 있음
• Cinder 서비스 배포
  • OpenStack Ansible은 Cinder 서비스 배포를 위한 플레이북을 제공함
  • Cinder API 서비스는 컨트롤러 노드에 배포될 수 있음

---

Manila

• Manila: 서비스는 파일 공유를 서비스로 제공함
  • 가상 머신에 영구적인 파일 공유 스토리지를 제공함
  • 단일 공유를 여러 사용자가 동시에 접근할 수 있음
  • NFS 및 CIFS(Common Internet File System)와 같은 다양한 파일 공유 프로토콜을 백엔드 드라이버로 지원함
   

 

• 서비스 구성 요소
  • Manila API 서버
    • REST 인터페이스를 통해 클라이언트의 파일 공유 생성 및 관리 요청을 처리
  • Manila 데이터 서비스
    • 공유 마이그레이션및 백업을 담당함
  • Manila 스케줄러
    • 새로 요청된 파일 공유를 호스팅할 올바른 공유 서버를 선택하는 역할
  • Manila 공유 서버
    • OpenStack 테넌트가 요청한 스토리지 공유를 실제로 호스팅하는 서버

공유 연결 과정

• Manila는 공유 서버에서 공유를 orchestration하거나, 공유 서버 자체를 배포하고 관리하도록 구성될 수 있음
• 공유 서버 자체를 배포하고 관리할때는
  • Nova를 사용하여 공유 서버 appliance를 호스팅할 인스턴스를 시작하고,
  • Cinder 볼륨을 사용하여 파일 공유를 생성하며,
  • Neutron을 사용하여 이러한 appliance 서버의 공유를 테넌트 가상 머신이 접근할 수 있도록 해야함
• 과정
  1. default share type 생성
  2. share network생성
     • 공유 서버에 연결될 Neutron 네트워크의 ID와 서브넷 ID를 옵션 명령어와 함께 사용해 공유 네트워크를 생성해야함
  3. 공유 생성
     • 파일 공유 프로토콜(ex: NFS)과 크기, 이름을 지정하여 공유를 생성함
  4. 접근 규칙 생성
     • 모든 IP 주소에서 읽기/쓰기 권한 허용 같은거..
  5. NFS 마운트 소스 확인
     • VM에서 NFS를 통해 파일 공유에 접근하기 위해 마운트할 소스 경로를 확인함
     • 이후 가상 머신내에서 이 경로를 마운트하여 사용할 수 있음

 

• Manila로 인해
  • 테넌트 간 격리 및 접근 제어가 가능해짐
  • VM뿐만 아니라 베어메탈, 컨테이너 등에서도 사용 가능
  • 공유된 디렉토리를 VM간에 쉽게 연결 가능함 (협업 폴더로 활용...)

---

Ceph

• Ceph는 Openstack 환경에서 object, block, file system, interface를 모두 제공할 수 있는 소프트웨어 정의 분산 스토리지 솔루션임
  • Ceph는 Swift를 통한 객체 스토리지, Cinder를 통한 블록 스토리지, 파일 시스템 인터페이스를 단일 시스템에 제공할 수 있음
  • Glance 서비스의 이미지 저장 백엔드로도 사용될 수 있음

 

Ceph의 아키텍처 및 핵심 구성 요소

• Ceph의 핵심은 RADOS (Reliable Autonomic Distributed Object Storage)임
• RADOS는 스토리지 클러스터 전반에 걸쳐 객체의 분산 및 복제를 담당함

주요 구성 요소

• Object Storage Devices (OSD)
  • 물리적 디스크에 해당함
  • XFS나 Btrfs와 같은 파일 시스템에 있는 디렉토리가 될 수 있음
  • OSD는 RADOS 서비스를 위한 ODS 데몬을 실행하며, 객체의 복제, 일관성 및 복구를 담당함
• Placment Groups (PGs)
  • Ceph 클러스터에 저장된 각 객체는 PG에 매핑됨
  • 객체와 OSD간의 중간 컨테이너 역할
  • 객체 복제를 담당하기도 함
• Pool
  • Ceph에서 pool은 Swift의 링 개념과 유사하며, 공유되지 않는 PG의 수를 정의 함
  • OSD 내 객체에 대한 hash map을 제공함
• CRUSH map (Controlled Replication Under Scalable Hashing)
  • CRUSH 알고리즘은 정의된 기준에 따라 객체가 OSD에 어떻게 분산되는지를 결정함
  • 즉, 클러스터 내에서 객체를 찾는 중앙 조회 테이블이 필요 없어짐
  • 복제된 객체가 동일한 디스크, 호스트, 랙에 저장되지 않도록 보장함
• MON (Monitor Daemon Server)
  • 주로 OSD를 실행하는 각 노드에서 데이터의 일관성 상태를 확인하는 데 중점을 둠
• MDS (Metadata Server)
  • 객체 위에 POSIX 파일 시스템을 구축하는 경우, 메타데이터를 저장하기 위해 Ceph 파일 시스템에 필요함

---

Openstack과의 통합

• 블록 스토리지 (Cinder):
  • Ceph는 Nova 인스턴스에 블록 스토리지를 제공하는 RADOS Block Device (RBD)를 제공하며,
  • 이는 librbd 라이브러리를 통해 QEMU 드라이버로 접근할 수 있음
• 성능 향상 (Copy-on-Write):
  • Ceph는 Copy-on-Write (CoW) 클로닝 기능을 제공하여 단일 마스터 이미지에서 수천 개의 VM을 즉시 시작할 수 있음
  • 이는 VM 부팅 및 I/O 성능을 크게 향상시킵니다.
• 이미지 스토리지 (Glance):
  • Glance가 Ceph를 이미지 스토리지 백엔드로 사용하도록 구성할 수 있음
• 네트워크 아키텍처:
  • ceph-mon 데몬은 컨트롤러 노드에서 실행되어 관리 서비스를 중앙 집중화할 수 있음
  • ceph-osd 노드는 별도의 스토리지 노드에서 복제본으로 실행되어야 함
  • Compute 노드는 이미지 복제 또는 볼륨 저장에 필요한 Ceph 노드를 인식하기 위해 Ceph 클라이언트가 실행되어야 함
  •  네트워크 관점에서 ceph-osd 노드는 프라이빗 스토리지 네트워크에 연결되며,
  • Ceph 데몬을 실행하는 노드는 관리 네트워크에 연결됨
• Ceph는 Ceph Ansible을 통해 배포할 수 있음