Zi 字媒體

資料冗餘：如果不夠聰明，那就努力點 上一篇文章「打造穩定的雲服務 - 高可用架構」提到服務的三種典型的高可用架構，分別是 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 的正常服務，要特別小心。 分享到 Twitter(在新視窗中開啟) 按一下以分享至 Facebook(在新視窗中開啟) 分享到 LinkedIn(在新視窗中開啟) 點這裡寄給朋友(在新視窗中開啟) 按一下即可分享至 Skype(在新視窗中開啟) 分享到 Reddit(在新視窗中開啟) 分享到 Tumblr(在新視窗中開啟) 按一下以分享到 Telegram(在新視窗中開啟)