資料冗餘：如果不夠聰明，那就努力點
上一篇文章「打造穩定的雲服務 - 高可用架構」提到服務的三種典型的高可用架構，分別是 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 的正常服務，要特別小心。