雲架構實戰 - 雲服務資料冗餘高可用架構


資料冗餘:如果不夠聰明,那就努力點

上一篇文章「打造穩定的雲服務 - 高可用架構」提到服務的三種典型的高可用架構,分別是 M/S, A/A 與分散式架構。
再來討論一下關於資料冗餘 (Data Redundancy) 相關的架構設計。我們先想想…如果有一台提供資料的服務,像是 MySQL 或網路磁碟系統等等服務,當資料服務提供節點發生故障時,資料要如何持續的供應與進行計算?答案很簡單,就是放兩份,如果你擔心兩台節點都掛了,好吧,那就放三份.......透過這種浪費空間重複儲存資料的方法來提升可用性,就是所謂的「資料冗餘」。

不停的製作資料副本也不是解決問題的唯一辦法,這樣的架構實在太浪費磁碟空間了,因此如果要在巨量資料的情況下實現資料冗餘,就衍生了另一種分散式儲存的架構。原理簡單的說,就是將資料切分為許多 Shard 分散儲存在不同的節點中,節點通常是不同的實體機、機櫃、地理區域等等。除了分散資料以外,同時也建立副本進行儲存,避免資料損毀。這樣的架構似乎很完美,但是在實務上如果要在分散式架構上實現 ACID 的代價是很高的,有時候高到可以直接放棄 ACID 特性也是常有的情況。

分散式的資料庫可以透過「共識算法」來自動協同資料的同步,近年越來越多相關的研究,像是支付寶所使用的 OrcenBase 就是這樣的設計。

接下來介紹幾種在高可用架構下,常用到的資料庫與儲存系統。

高可用的關聯式資料庫 (RDBMS)

以關聯式資料庫來說,實現資料冗餘與 ACID 是會有衝突的,在 Master/Slave 架構下,最多就是同步時間的影響,有時候 Master 寫入的資料來不及同步到 Slave,查詢的時間差導致錯誤發生。如果真的要避免這個問題,不太複雜的邏輯可以搭配 Key/Value Database,像是 Redis 這樣的服務來避免。基本上讀寫分離的速度很快,除了 Master 要多放幾包乖乖都可以滿足需求。

如果透過是 Active/Active 架構 (可參考上一篇文章) 來實現,兩台機器會存在些許的同步時間。以往我對 MySQL, PostgreSQL 這些 Open Source 的資料庫比較熟悉,之前研究在實現 A/A 架構其實都已經是成熟的機制,但要特別注意的就是由於多個節點可以寫入,資料的衝突要在業務邏輯中避免,比如使用非連續的流水號 ID、使用亂數 ID 等等技巧。相對於 M/S 機制 A/A 的同步速度更慢,但是多了一個容錯的機制,可以讓其中一個節在「乖乖過期」的情況下,繼續提供資料庫讀寫服務。

MySQL 相關 Replication 教學可以參考「MySQL Replication 主從式架構設定教學」這一篇文章。

高可用的 No-SQL Database

除了典型常使用的 MySQL 之外,遇到一些時常變更的業務需求,或者容易大量產生資料的情況,我們可能會選擇 No-SQL 特性的資料庫。像常使用的 MongoDB 就是一種 Schema Less 的資料庫,適合用來存放大量資料,或者一些欄位不固定的資料。這一類資料庫也可以稱為 Document DB,總之都是存放一個 Json 物件。像是 MongoDB 就支援 Replication 功能與 Shard Cluster,Replication 可以建立資料副本,並且同時提供服務,屬於 Master/Slave 架構,當 Node 出問題時會自動投票選出適合的節點擔任 Master 角色。

我們都知道,所有的 Master/Slave 架構都會有垂直擴充上限的問題,單一個節點的資料處理能力有限。MongoDB 透過分片的方式來處理水平擴充問題,分片就是將資料根據定義的好規則分別分散儲存到不同的 Node,可提昇整體的資料處理能力。分片機制最需要注意的就是分片的演算法,根據業務邏輯選擇適合的分片規格非常重要,可以準確的將運算路由到少數的節點進行處理,效率才會高。MongoDB Sharding Cluster 搭建方式可以參考「MongoDB Sharding 分散式儲存架構建置」這一篇文章。

高可用的 Fulltext Search Engine

除了一般的關聯資料、NoSQL 資料以外,也可能會有全文搜尋的需求,特別是在維運時期,大量的 Log 與內容搜尋等等功能。全文搜尋與一般的資料庫是全然不同的設計架構,全文搜尋透過「反向索引」實現大量在資料中進行高速搜尋。目前 Open Source 已經有很多成熟的全文搜尋軟體,特別是 ElasticSearch 強大的功能與穩定性。如果選用 ElasticSearch 這樣的產品,基本上已經有自動的數據分片、容錯與資料副本等等功能。這裡我自己最多用了六台機器建構 Cluster,其實也沒有太多的 Cluster 管理經驗可以分享,比較深刻的問題就是由於底層的機制是實現「反向索引」,因此字典檔的管理是相當重要的,更新字典後的在線 Reindex 工作也是有些挑戰。

高可用的 Object Storage

除了資料另一種就是檔案了,現在大量的檔案習慣都是放在像是 AWS S3 這樣的服務中,透過 IaaS 的高可用、無限擴充的特性,讓開發者或系統營運方幾乎不用進行 Storage 的系統維護工作。以 Open Source Project 來說,Ceph 是目前最常被使用的項目。Ceph 是一個分散式檔案系統,支援在線 (On-line) 動態水平擴充,資料的存放被切割為片段後,透過 CRUSH Maps 演算法決定存放的位置,同時實現分流、資料副本、水平擴充等等特性,可以說是非常強大。正確的配置 Ceph 是很重要的,如果要使用 Ceph 請務必先了解 Ceph 的特性與架構,盡可能遵循 CephFS Best Practices 的建議。比較常犯的錯誤如下:

  • 單一個 OSD 配置過高的空間,當這個高容量的 OSD 斷線時,就會開始建立資料副本,速度會很慢
  • 一台實體機器執行了太多 OSD,一旦機器死了就同時死了好多 OSD
  • 整座 Cluster OSD 數量太少,一但發生單一個 OSD 故障,就會 Rebalancing 大量資料造成嚴重緩慢
  • OSD 之間的網路速度與品質不良,當網路斷線時造成節點誤判離線而開始 Rebalancing
  • Placement Groups (PGs) 數量規劃過低,可以參考 Ceph PGs per Pool Calculator 進行計算

以上是我們在使用 Ceph 容易犯下的錯誤,沒有設計好常常會造成單一節點故障時,反而影響到整座 Ceph 的正常服務,要特別小心。

這是真的廣告

白金贊助

平價童鞋首選