Block, Object, and File Share
대규모 클라우드 배포에 필수적인 신뢰할 수 있고 확장 가능하며 견고한 스토리지 솔루션에 대해 설명하고 있음
Swift, Cinder, Manila와 같은 OpenStack 스토리지 서비스에 대한 설명과 OpenStack과 원활하게 통합되는 클라우드 스토리지 솔루션인 Ceph를 소개하고 있음
Understanding the storage types
- 스토리지는 크게 영구(Persistent)스토리지와 임시(Ephemeral) 스토리지로 구분할 수 있음
Ephemeral Storage
- VM이 종료되면 연결된 디스크의 데이터에 대해 손실이 발생함
- 주로 Nova 인스턴스의 루트 디스크로 사용됨
- VM(인스턴스)을 만들면, 그 인스턴스의 루트 디스크 (OS가 설치되는 디스크)는 Ephemeral storage
- 그렇기에 Nova의 루트 디스크는 기본적으로 VM이 실제로 실행되는 hypervisor machine의 로컬 디스크에 저장
- 또는 NFS(Network File System) 마운트를 통해 외부 스토리지에 호스팅될 수 있음
- NFS 마운트를 할 경우, 루트 디스크가 공유 스토리지에 존재하므로 여러 하이퍼바이저 호스트에서 접근할 수 있어 가상 머신 간 마이그레이션이 가능함
Persistent Storage
- 영구 스토리지란 스토리지 리소스가 항상 사용 가능함을 의미함
- VM을 종료하더라도 디스크의 데이터는 영향을 받지 않고 유지됨
- OpenStack에서 영구 스토리지는 세 가지 옵션으로 나누어짐
- 객체 스토리지 (Object storage): Swift
- 파일 공유 스토리지 (File share storage): Manila
- 블록 스토리지 (Block storage): Cinder
Object Storage
- 여기서 object는: metadata + file의 조합을 말함
- Object storage is not NAS/SAN
- Object storage는 사용자가 데이터를 object 형태로 저장할 수 있도록 하며, RESTful HTTP API (or SOAP)를 사용하여 접근함
- 전통적인 NAS(Network Attached Storage) 또는 SAN(Storage Area Network) 저장소와 달리,
- Object storage는 무한히 확장 가능하며, 노드 장애 발생 시에도 데이터 손실 없이 더 안정적으로 처리할 수 있음
- 데이터는 binary large objects(blobs)로 저장되며, (binary 쓴다는거 자체가 엄청난 이득임)
- Replica가 이 object storage 서버에 분산 저장되기 때문
- 객체는 플랫 flat namespace에 저장됨
- 전통적인 파일 시스템과는 달리, 디렉터리 구조나 계층 같은 특정한 구조를 유지하지는 않음
- BFS(로컬 디스크 파일 시스템), SMB(server message block)같은 파일 프로토콜을 사용해 직접 접근할 수는 없음
- Object Storage는 고성능이 필요한 작업이나, 자주 변경되는 structured data 에는 적합하지 않음
Swift
Swift는 Amazon Web Services의 S3 서비스와 유사한 클라우드 기반 오브젝트 스토리지 서비스
- Swift 주요 장점
- 확장성 (Scalability):
분산 아키텍처를 통해 성능과 확장성을 제공 - 온디맨드 (On-demand):
사용자는 하나의 엔드포인트를 통해 스토리지를 필요한 만큼 즉시 provisioning 할 수 있음 - 탄력성 (Elasticity):
필요에 따라 스토리지 리소스를 동적으로 늘리거나 줄일 수 있음
- 확장성 (Scalability):
Swift Architecutre
Swift는 소프트웨어로 데이터를 관리할 수 있게 해줌 -> SDS(Software Defined Storage)의 핵심 개념
분산 아키텍처로 구성되어 있어 SPOF(단일 실패 지점)가 없으며, 수평 확장이 가능
Swift의 주요 구성 요소
- Proxy 서버
- 사용자 요청(파일 업로드, 컨테이너 생성, 메타데이터 수정 등)을 받는 Gateway
- OpenStack Object API 또는 HTTP를 통해 요청 처리
- 성능 향상을 위해 memcached 기반 캐시를 사용하여 성능을 향상 시킴
- 오브젝트 요청은 항상 인증 토큰이 필요하며, 보통 Keystone을 통한 인증 설정이 필요함
- Account 서버
- Swift의 계정 정보를 관리함
- 계정에 연결된 컨테이너 목록을 관리함
- Container 서버
- 컨테이너는 사용자가 정의한 저장소 단위 (전통 파일 시스템의 폴더 비슷)
- 객체를 포함하는 컨테이너 정보를 관리함
- Object 서버
- 실제 데이터(object)와 메타데이터를 저장함
- 모든 오브젝트는 반드시 하나의 컨테이너에 소속되어야 함
- 메타데이터는 key-value 쌍으로 저장되며, xattr(확장 속성)을 통해 확장 기능을 제공함
- Swift는 데이터를 처리하기 위해 백그라운드 데몬인 감사자(auditors), 업데이트자(updaters), 복제자(replicators), 제거자(reapers)를 실행함
- 해당 프로세스들로 인해 디스크 I/O 트래픽이 증가하게됨
- 각 객체 및 컨테이너 구성 파일에서 concurrency 값을 추가하여 동시 실행되는 백그라운드 프로세스 수를 제한할 수 있음
[object-replicator]
concurrency = 2Indexing the data
- Object Storage Device(OSD)에서 데이터를 검색하고, 인덱싱하는 작업은 메타데이터를 활용하여 이루어짐
- 일반적인 NAS 스토리지도 메타데이터를 사용하지만, OSD의 경우에는 객체 자체와 함께 key-value 쌍 형태로 메타데이터를 저장함
- OSD는 저장 효율을 높이기 위해 객체를 chunk해도 각 조각에 메타데이터를 계속 태그 하기에 단순하게 작동함
Rich API access
- Swift proxy process는 스토리지 클러스터 외부와 통신을 할 수 있음(only)
- Swift proxy 덕분에 OSD에 접근할 수 있음
- Swift는 애플리케이션과의 쉬운 통합을 위해 PHP, Java, Python 등 언어별 라이브러리를 제공함(이 라이브러리로 HTTP 통신함)
- Object 요청은 항상 인증 토큰을 필요하며, 인증은 일반적으로 Keystone과 같은 WSGI(Web Server Gateway Interface) 미들웨어를 통해 구성됨
Swift Gateways
- Swift 자체는 CIFS나 NFS 같은 전통적인 파일 시스템 인터페이스를 기본적으로 제공하지 않음
- 대신, Swift filesystem gateways라는 layer를 사용하면, 기존 애플리케이션이 Swift와 상호작용할 수 있도록 함
- Swift filesystem gateway 덕분에 전통적인 파일 기반 애플리케이션과도 통합이 가능해짐
Physical design considerations
- Swift 사용의 핵심은 data durability과 availability(가용성)을 보장함
- Swift 클러스터는 기본적으로 3개의 replica를 고려하여 설계됨 (3-replica 구조)
- 이는 데이터가 기록되면 두 개의 다른 replica에 분산되어 데이터 가용성을 높임
- ex) 50TB의 데이터를 처리해야 하는 스토리지 노드가 실패하면, Swift의 3-replica 구조를 충족하기 위해 이 거대한 데이터 blob을 원격으로 전송하는 데 몇 시간이 걸릴 수 있음
- 따라서 스토리지 서버와 proxy 간의 대역폭 사용량을 고려하는 것이 중요함
- 즉, 스토리지 전용 네트워크를 할당하는 것이 중요한 이유임 (대용량 데이터를 전송해야 할 때 네트워크에 부하를 줄이기 위해)
- Swift에서는 논리적 네트워크 설계와 네트워크 부하 분산을 위해 스토리지 트래픽을 분리했음!!
- 그러기 Swift 구조에 대해서 물리적 이해가 필요로함
Understanding Swift's Data Hierarchy
- 위에서는 Swift에서 account, container, object가 데이터를 구성하며, 이것이 물리적인 저장소에 저장된다는 것을 알아봄
- 이제는 Storage node에 대해 알아보자
- Swift는 isolate failures(장애 격리)를 보장하며, 이를 위해 클러스터를 노드 단위로 넓게 분산시킴
- Swift는 논리적인 데이터 구성과 물리적인 저장을 분리하기 위해 새로운 계층 구조를 정의함
Region
- 지리적으로 분산된 환경에서 데이터를 여러 노드에 저장함
- 이 노드들은 서로 다른 리전에 위치함(멀티-리전 클러스터, MRC)
- 리전 간의 높은 지연 시간이 발생함
- 이를 위해 Swift는 읽기/쓰기 선호도(read/write affinity) 기능을 지원하여
- 지연 시간 측정을 기반으로 가까운 위치의 데이터를 우선적으로 읽고,
- 쓰기는 로컬에서 이루어진 후 비동기적으로 다른 리전으로 전송됨
Zone
- 리전은 zones(영역)을 포함하며, 이는 Swift가 제공하고자 하는 availability level을 정의함
- 하나의 존은 rack이나 스토리지 노드 등 하드웨어 묶음으로 구성되며,
- 하드웨어 장애를 다른 이웃으로부터 격리하는 역할을 함
Storage Nodes
- regioin -> zone -> storage nodes
- storage node는 아래와 같은 정보를 저장함
- 계정 정보
- 컨테이너
- 객체 데이터
- 메타데이터
Storage device
- Swift 데이터 스택에서 가장 작은 단위
- 이 장치는 노드 내부의 디스크일 수도 있고, 외부 디스크 배열일 수도 있음
- Swift에서 사용하는 디스크는 JBOD (Just a Bunch Of Disks)로 구성됨 (그냥 여러개의 디스크 묶음)
- RAID와는 달리, JBOD는 여러 디스크를 개별 장치로 취급하여 호스트 컴퓨터에서 각각 접근 가능하게 함
- 용량을 많이 확보할 수 있지만 데이터 복구에 취약함,
- 그치만 Swift 자체가 복제 및 장애 복구 메커니즘을 가지고 있음
- Swift는 replication, distribution architecture, rebalancer-replicator demon을 통한 복구 메커니즘이 존재함
Swift Ring
- Swift Ring: Swift가 클러스터 내에서 데이터를 처리하는 방식을 말함
- Swift는 오브젝트 데이터를 account → container → object 계층 구조에 따라 논리적으로 구성
- Account는 OpenStack에서 tenant(프로젝트)에 해당함
- 각 tenant는 여러 개의 container를 가질 수 있음
- 각 container는 여러 개의 object를 포함할 수 있음
- 이런 구조를 물리적 저장소(디스크)의 위치와 매핑해주는 것이 Swift Ring
- Swift는 account ring, container ring, object ring이라는 세 가지 링이 있음
- Swift Proxy는 해당 요청이 어떤 저장소(account/container/object)에 대한 것인지 파악하여,
- 해당 링을 참조해 물리적 위치를 찾음
- Swift Ring은 외부 도구인 swift-ring-builder를 사용하여 생성함
- Swift-ring-builider는 Swift 클러스터 내의 storage-device 정보를 수집하여 이를 Hash-function을 통해 partition 단위로 나눔
- 각 파티션은 클러스터 내의 물리적 장치와 매핑됨
- 이때 각 스토리지 드라이브는 100개의 파티션으로 나누는 것이 권장됨
- ex) 객체 스토리지 클러스터에 50개의 디스크를 사용한다면 5000개의 파티션이 필요함
Storage policy and erasure coding
- Swift에서 데이터의 high availability를 제공하는 방법은 데이터를 여러 replica로 만들어 다른 region, zone, 노드, 디스크에 분산 저장하는 방식임
- 이 방법은 스토리지 비용이 매우 높음,
- 기본적으로 Swift는 각 객체마다 3개의 replica를 저장하도록 되어 있는데
- 이러한 방식을 사용하면 비용면에서 비효율적임
- 그래서 Swift는 Erasure coding을 통해 이를 해결할려 함
Erasure Coding
- 이러한 비용 문제를 해결하기 위한 방법이 바로 Erasure Coding
- 이는 데이터를 복제하지 않고, parity 정보(데이터 복원을 위한 계산된 정보)를 생성하여 손실된 데이터를 복구할 수 있도록 만드는 방법임
- 사용자가 Swift에 데이터를 업로드하면, Swift Proxy는 해당 데이터를 여러 segment로 나누고 PyECLIB라는 라이브러리를 호출하여 Erasure code 조각으로 인코딩함
- 생성된 조각들은 여러 스토리지 노드에 분산되어 저장됨
복구 과정
- 사용자가 데이터를 요청하면, Proxy 서버가 여러 스토리지 노드에 동시에 요청을 보내고,
- 조각화된 데이터(fragment)를 받아 디코딩해서 원본 객체를 복원함
- Erasure Coding 방식은 약 40%의 오버헤드를 가짐 (3중 복제 방식은 200% 오버헤드)
Swift Hardware
- Swift 클러스터에 필요한 프록시 및 스토리지 노드의 수를 결정하는 것은 중요함
- Container, Account, Object는 하나의 스토리지 Tier로 논리적으로 그룹화되어 Object Server의 Disk에 저장됨
- 그러면 얼마나 많은 프록시와 스토리지가 필요한지 계산을 한번 해보자
- 객체 저장소 용량 필요량: 50TB
- Replica 수: 3
- 파일 시스템: XFS (대용량 파일 처리)
- 하드디스크 크기: 2.5TB
- 샤시(chassis) 하나당 하드디스크 슬롯: 30개 (서버나 스토리지를 담는 하드웨어 프레임)
- 총 storgae 용량: 50TB * 3 = 150TB (replica수가 3이므로..)
- XFS 파일 시스템 메타데이터 오버헤드 고려: 50 TB 이상의 파일 시스템 크기에 대해 1.0526의 오버헤드 값을 적용하기에
- 150 TB * 1.0526 = 약 158 TB
- 필요한 하드 드라이브 수: 158 TB / 2.5 TB/드라이브 = 약 64개
- 총 스토리지 노드 수: 64 개 / 30 개 = 약 2.1333, 즉 3개의 노드가 필요
Where to place what
- 프록시 서버는 클라이언트 요청을 받아 스토리지 노드에 전달함 → CPU 사용률이 높아질 수 있음
- 스토리지 노드는 디스크 I/O가 집중되므로 CPU 리소스가 더 많이 필요함
- Swift는 XFS 파일시스템의 inode를 RAM에 캐싱함
- RAM이 많을수록 캐시 성능 ↑ → 객체 접근 속도 향상
- 기본 설정: 서버당 2GB RAM
- 디스크와 성능 관련 사항
- account server, container server → SSD 사용 권장 (데이터 위치 탐색 속도 향상)
- object 서버 → **SATA/ATA 디스크 (예: 6TB)**도 적절
- IOPS(초당 입출력 횟수)가 부족하면 → 디스크 수를 추가해야 함
Swift network
- 대규모 인프라에서는 스토리지 시스템 전용 추가 네트워크를 구성하는 것이 중요하며, Swift 네트워크는 다음과 같이 확장됨
- Front-cluster network: proxy server가 외부 클라이언트와 통신하고 클러스터의 외부 API 접근 트래픽을 전달함
- Storage cluster network: 스토리지 노드와 프록시 간의 통신을 허용하며, 동일한 리전 내 여러 랙 간의 노드 간 통신을 허용함
- Replication network: 스토리지 노드 간의 복제 관련를 위한 전용 네트워크 세그먼트(망)
'클라우드 > OpenStack' 카테고리의 다른 글
| glance에서 keystone 서비스 연동 (0) | 2025.07.19 |
|---|---|
| Key Stone install & managment (0) | 2025.07.06 |
| Openstack Installation (0) | 2025.07.06 |
| Openstack Storage - Cinder/Manila/Ceph (0) | 2025.07.05 |
| Introduction to Openstack (0) | 2025.06.29 |