顯示具有 Software-Defined Storage (SDS) 標籤的文章。 顯示所有文章
顯示具有 Software-Defined Storage (SDS) 標籤的文章。 顯示所有文章

2014年10月14日 星期二

OpenStack Swift 簡介

OpenStack Swift 簡介

目錄


1、OpenStack Swift 是什麼?

以下截至 StackSwift 的定義:
OpenStack Swift is a multi-tenant, highly scalable and durable object storage system that was designed to store large amounts of unstructured data at low cost via a RESTful HTTP API.
從上述簡單的定義,無法完全表達 Swift 的強大,因此以下列出 Swift 的特色:
  • open source & 免費。
  • 目前有許多大型的 object storage 雲端服務使用 Swift (例如:Rackspace、Cloud Files、HP Cloud … etc)。
  • Swift 可以單獨提供 storage 服務,也可以與其他的雲端環境進行整合。
  • 只要是標準的 x86 架構的硬體,搭配標準的 Linux 系統,就可以運行 Swift。
  • Swift 跟 Amazon S3 相同,提供最終一致性(eventual consistency),因此也提供了強大的水平擴展能力。
  • 所有儲存在 Swift 的物件、檔案都有一個 URL。
  • 提供標準的 RESTful HTTP API,因此非常合適作為經由 web-based 存取資料的用戶端、裝置、應用程式。
  • 儲存於 Swift 的物件可以擁有可擴展性的 metadata,可用來有效率的進行索引 & 搜尋。
  • 所有儲存在 Swift 的物件都會有多個複本存在於其他的 Zone or Region。
  • Swift 透過增加額外的節點就可以很簡單的進行擴展。
  • 當增加或更換硬體時,不需要將原本的資料移動到其他的節點內。
  • 在 Swift 運行中,可隨時增加 or 移除節點。
  • 設計在低成本的前提下,可儲存超大量非結構性資料(檔案、圖片、影像 … 等等)。

2、Swift Request

Swift 有個重要特性:
所有儲存在 Swift 的物件、檔案都有一個 URL,並可透過 HTTP RESTful API 存取
接著來看看實際上 object 是如何存放在 Swift 中的,用下圖來說明:
object storage localtion in Swift
上圖一共有三個部分,分別是:

2.1 Account

Account storage 在整個 Swift storage 中是一個獨一無二的名稱,但 Account storage 在概念上並不屬於特定使用者的帳號 or 認證資訊,而是屬於儲存區域(storage area)的概念。
在 Account storage 中,包含了與 Account 相關的 metadata 之外,就是儲存包含在此 Account 內的 Container 資訊。

2.2 Container

Container storage 則是屬於使用者自行定義的儲存區域,除了包含一些與 Container 本身相關的 metadata 之外,裡面主要就是 object 存放的地方。

2.3 Object

Object storage 存放的資料除了檔案本身之外,還包含了與檔案相關的 metadata。

2.4 Object URL 組成

有了 Account / Container / Object 三種概念後,就可以進一步來了解每個 object 的 URL 組成,每個 object 都會有一個專屬的 URL 可供存取,結構如下:
https://swift.example.com/v1/account/container/object
其中 URL 結構包含兩個主要部分:

3、Swift Processes

只要有運行 Swift process 或是 service 的機器,稱為 “node”。
運行 Proxy server process 的機器稱為 Proxy Node。
運行 Account / Container / Object process 的機器稱為 Storage Node。(當然也另外包含了處理資料一致性的 consistent service)
以下可以用一張簡單的圖說明 proxy node & storage node 在處理資料時的關係:
Swift Proxy Node & Storage Node

3.1 Proxy Layer

Proxy server process 是 Swift 中直接與外部的 client 連線的部分,用來處理來自外部的 HTTP request & response。
在整個架構中建議至少使用兩個 proxy node,以避免 single point failure 的狀況發生。
當 proxy server 收到 client request 後,會決定某個 storage node 來處理,收到 storage node 處理完的通知後會再回應給 client。

3.2 Account Layer

Account server process 用來處理與 Account 相關的 metadata & Account 內所包含的 Container 資訊,而這些資訊是存放再 Account server process 所在機器內的 SQLite 資料庫中。

3.3 Container Layer

Container server process 用來處理 Container metadata & 包含在內的 object 資訊需求,這些資料同樣也是存在 Container server process 所在機器內的 SQLite 的資料庫中。

3.4 Object Layer

Object server process 負責實際檔案的儲存,檔案是以二進位的方式儲存於磁碟中。
除了二進位資料外,還包含了很重要的時間戳記(timestamp)資訊,時間戳記資訊可以讓 Swift 同時儲存多種不同版本的檔案,
而 object 的 metadata 則是以副檔名 xattrs 的方式,與 object 儲存在一起,Swift 會負責將這些資料複製到多個不同節點上。

4、Swift Consistency Services

為了確保每個 storage node 之間的資料一致,Swift 提供了兩個重要的 Service,分別是 Auditor & Replicator。

4.1 Auditor

Auditor service 運作在每一個 storage node 中,持續掃描磁碟確認沒有任何錯誤的發生,若是有錯誤發生,Auditor service 就會將有問題的 object 移到隔離區。
每一個 process(Account / Container / Object) 都有專屬的 Auditor 進行資料檢查之用。
Audit Service

4.2 Replicator

同樣的 Account / Container / Object process 也都有相對應的 replicator,功能主要用來確保本地端的資料與 Cluster 中其他 storage node 的資料是一致的。
比較需要注意的是,replicator service 只會將新的資料送到其他的 storage node,而不會從其他的 storage node 抓取新資料回來更新本地端資料。
而 replicator service 是透過 checksum 的方式來達到各 storage node 資料的一致:
Replicator Service

5、Swift Cluster 分群概念

Swift 是由一堆 proxy node & storage node 所組成,為了容易區分,因此有 Region & Zone 兩種邏輯上的分群概念。
以下直接用一張圖來說明 Region & Zone 的樣子:
Swift Cluster Architecture
Zone 是由多個 storage node 所組成,一般常用來作為資料中心內部同機櫃的分類之用,或是用來將特別用途的 node 歸類之用。
Region 則是由多個 Zone 組成,一般常用來區分不同區域的資料中心。
Region & Zone 是可以隨使用者自行定義的,上述只是範例而已。

6、Swift 資料存取設計

6.1 Partition

Swift 為了有效的跨 storage node 來存放資料,並可以達到快速存取的目的,在資料存放的模型有經過特別設計,以下用一張簡單的圖來說明:
Swift Partition
從上圖可以看到有三種元素,分別是:
  1. Storage Node
  2. Disk
  3. Partition
每個 Storage node 可能會有好幾個 Disk。
而 Partition 在這邊並不是傳統磁碟分割的概念來看,而是應該把它當作是 Disk 的一個目錄的概念來看,所以一個 Disk 會有很多個 Partition。
Partition 是 Swift process 處理的最小單位,也是資料實際存放的地方,而 consistency process 則是以 partition 為單位在檢查資料的一致性,資料在不同的硬碟(or 設備)間移動也是以 partition 為單位。
透過以 paritition 為單位來處理的方式,Swift 可以減少 process & 網路的負擔。

6.2 Ring

Ring 在 Swift 架構中是個相當重要的部分,它是一個映射(mapping)檔案,由一致性的 hash 演算法所產生,種類有三種,分別是 Account Ring / Container Ring / Object Ring。
透過 Ring 就可以知道每一個 object 實際對應到的 Account & Container & 實際存放的位置(partition),如下圖:
Swift Ring
Ring 存在於 Swift Storage Cluster 中的每一個 node 中,透過 Ring,可以確保每個 object 在 Swift Storage Cluster 中有多個複本存在於不同的 storage 內,也可以確保後續可以進行快速的存取。
透過維持一致性的 Ring,Swift Storage Cluster 不僅避免了單點錯誤的狀況發生,提升存取的速度,也大大的增加水平擴展的能力。

7、Switch 完整架構

最後來個 Swift Storage Cluster 的完整架構概觀:
OpenStack Swift Architecture
  • Proxy Server 是直接接受來自 client 請求的部分。
  • Proxy Server 收到 client 請求後,會透過 Ring 快速地進行 object 的存取 or 將資料同步到不同的 Object Server(storage node) 上。
  • 不同的 Object Server 可能會根據不同的規劃(地理區域、服務對象、功能性….等),區分成不同的 Zone(or Region) 作為管理之用。

8、參考資料

2014年10月11日 星期六

Ceph 簡介

Ceph 簡介

目錄

1、前言

什麼是 Ceph?

它是以 RADOS (Reliable Autonomic Distributed Object Store) 為主要設計方式的分散式儲存平台,因此在水平擴展的能力極為強大。

以下截錄一段在 inktank 網站上的說明:

Ceph is an open-source, massively scalable, software-defined storage system which provides object, block and file system storage in a single platform. It runs on commodity hardware—saving you costs, giving you flexibility—and because it’s in the Linux kernel, it’s easy to consume.

從以上的內容可以看出,Ceph 是個軟體定義的儲存系統有以下幾個特點:

  1. 在同一平台下可同時提供 Object Storgae & Block Storage & File System 等三種不同的服務。
  2. 強大的擴展能力。
  3. 不受限於任何硬體規格,no vendor lock-in !

一個平台可以同時提供三種服務,簡直是健達出奇蛋一樣,三種願望一次滿足。XD

2、Ceph 功能

Ceph 在三種不同的功能(object / block / file system)中,分別提供了以下特性:

CEPH OBJECT STORE CEPH BLOCK DEVICE CEPH FILESYSTEM
RESTful Interface Thin-provisioned POSIX-compliant semantics
S3- and Swift-compliant APIs Images up to 16 exabytes Separates metadata from data
S3-style subdomains Configurable striping Dynamic rebalancing
Unified S3/Swift namespace In-memory caching Subdirectory snapshots
User management Snapshots Configurable striping
Usage tracking Copy-on-write cloning Kernel driver support
Striped objects Kernel driver support FUSE support
Cloud solution integration KVM/libvirt support NFS/CIFS deployable
Multi-site deployment Back-end for cloud solutions Use with Hadoop (replace HDFS)
Disaster recovery Incremental backup

3、與 OpenStack 整合狀況

從 Folsom 版本開始,Ceph 就已經正式整合進 OpenStack 了。

Ceph for OpenStack

Ceph 提供了 Block Device service 給 Cinder & Glance & Nova 使用,還包含了其他強大的特性,例如:High Availability、Fault Tolerant … 等等。

此外 Ceph 也完全相容 Swift API,因此可以取代 Swift 提供 Object Storage service 之用;當然認證部分當然也整合了 Keystone。

由於以上原因,Ceph 可說是提供了一個完整的 storage solution 可用來整合進 OpenStack 中。

4、Ceph 基礎元素

在開始研究 Ceph 之前,有些基礎的元素是需要先了解的,以下逐一介紹:

4.1 CRUSH

CRUSH 在整個資料分散上扮演著重要角色,從「CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data」一文中可以看出 CRUSH 的功能:

CRUSH, a scalable pseudo-random data distribution function designed for distributed object-based storage system that efficiently maps data objects to storage devices without relying on a central directory.

CRUSH is designed to facilitate the addition and removal of storage while minimizing unnecessary data movement.

The algorithm accommodates a wide variety of data replication and reliability mechanisms and distributes data in terms of user-defined policies that enforce separation of replicas across failure domains.

從上面的說明可以看出,CRUSH 提供了以下功能:

  1. 將資料有效率的存放在不同的儲存裝置中。
  2. 即使移除整個 cluster 中的儲存裝置,也不會影響到資料正常的存取。
  3. 不需要有任何主要的管理裝置(or 節點)來做為控管之用。
  4. 可依照使用者所定義的規則來處理資料分散的方式。

CRUSH 包含了兩個部分,分別是 Algorithm & Map。

4.1.1 CRUSH Algorithm

CRUSH Algorithm 的用途在於可透過資料儲存位置的計算,決定如何存取資料;也因為是透過演算法計算的方式,可以有效避免 single point of failure 的問題發生。

4.1.2 CRUSH Map

CRUSH Map 是一群資訊的集合,包含了:

  1. OSD(Object Storage Daemon) 集合的資訊
  2. 由多個 device 所匯集而成的實體位置資訊
  3. 多個用來指定 Ceph 應該如何在 ceph cluster pool 進行資料複製的規則

透過以上資訊,CRUSH 可以將資料分散存放在不同的實體位置,並避免單點錯誤造成資料無法存取的狀況發生。

4.2 Placement Group

首先用下圖來說明 object / Placement Group / OSD 之間的關係:

Placement Group

當使用者把資料(object)存到 cluster 中時,每個 object 都會對應到一個 placement group(PG),而每一個 PG 都會對應到一組 OSD,其中第一個 OSD 為 primary,其他則是 replica。

多個 PG 也可以對應到同一個 OSD,因此 PG & OSD 其實是種多對多的關係。

而 OSD 在幹嘛? 就是把資料存入到不同的實體位置囉!

4.3 Object Storage Daemon (OSD)

Ceph OSD(Object Storage Daemon) Daemon 的主要工作就是透過網路,進行實際資料(object)的存取,但 OSD 完整個功能主要有以下幾項:

  1. 資料儲存
  2. 資料複製
  3. 資料回復
  4. 資料回填(backfilling, 通常發生於新 OSD 加入時)
  5. Rebalance (發生於新 OSD 加入 CRUSH map 時)
  6. 以 heartbeat 的方式取得其他 OSD 的狀態,並將資訊提供 Ceph Monitor

4.4 Monitor

為了有效的在分散式的環境下存取檔案,每一個 Ceph Monitor daemon 維護著很多份與 cluster 相關的映射資料(map),包含:

  1. Monitor map
  2. OSD map
  3. Placement Group (PG) map
  4. CRUSH map
  5. MDS map (若使用 Ceph File System,還會有這組映射資料)

主要是用來監控 Ceph Storage Cluster 上的即時狀態,確保 Ceph 可以運作無誤。

4.5 Metadata Server (MDS)

負責管理 Ceph File System 上的 metadata,且讓使用者可以把 Ceph File System 當作一般的檔案系統操作。

Ceph Object Storage & Ceph Block Device 不會使用到 MDS。

5、Ceph Storage Cluster 架構

5.1 Ceph Node 類型

組成 Ceph Storage Cluster 的元素稱為 Ceph node,而 Ceph node 共有以下類型:

5.1.1 Ceph OSD Daemons

實際與 client 溝通進行資料存取的即為 OSD daemon。

每個 object 被儲存到多個 PG(placement group) 中,每個 PG 再被存放到多個 OSD 中。

為了達到 Active + Clean 的狀態,確認每份資料都有兩份的儲存,每個 Ceph Storage Cluster 中至少都必須要有兩個 Ceph OSD。

5.1.2 Monitor

在每一個 Ceph Storage Cluster 中,都有多個 Monitor 存在,每個 Monitor 都維護著上述的五種映射資訊(monitor map / OSD map / PG map / CRUSH map / MDS map),以及 monitor / OSD / PG …等狀態的歷史資訊。

5.1.3 MDS

作為處理 Ceph File System 的 metadata 之用,若僅使用 Block or Object storage,就不會用到這部分功能。

5.2 完整架構

首先用下圖來表示完整的 Ceph 架構:

Ceph Architecture

其中最底層的 RADOS 是由 OSD & Monitor & MDS 三種所組成:

enter image description here

以上則是提供不同的 middleware( radosgw / rbd / cephfs),呼叫 librados 進行資料存取,來提供不同的 service(Object / Block / File System)。

5.2.1 Object Storage

Ceph Object Storage 的架構如下:

Ceph Object Storage

其中底層由 OSD & Monitor 來組成,透過 librados 來控制協調;上層則提供了 RADOSGW 來達成與 OpenStack Swift & Amazon S3 APIs 的一致性。

5.2.2 Block Storage

Ceph Block Storage 的架構如下:

Ceph Block Storage

Ceph Block device 提供了 thin-provison / 可調整大小 / 分散儲存 / 快照 / 一致性 … 等功能。

Ceph block storage 除了可以被 Linux kernel 直接使用外,也可以被 KVM / Qemu 使用,也可以透過 LIBRBD 與其他雲端系統(例如:OpenStack、CloudStack)整合。

5.2.3 File System

Ceph File System 的架構如下:

Ceph File System

底層的部分同樣是由 RADOS(OSDs + Monitors + MDSs) 提供,在上一層同樣與 librados 溝通,最上層則是有不同的 library 將其轉換成標準的 POSIX 檔案系統供使用。

6、參考資料