文章目錄
前言
在前面的文章中，筆者寫過關於Ozone OM HA實現的相關文章(Ozone OM服務HA原理分析)，裏面談論了目前OM HA的一些實現細節以及OM HA如何搭建這類的說明性文章。但是一套完整，高可用的系統，它需要確保其服務整體的健壯性，目前Ozone依賴的SCM服務還沒有實現HA，是一個單點的服務。Ozone社區在實現了OM HA之後，已經在設計考慮實現SCM的HA方案(相關JIRA：HDDS-2823)，以此能夠達到一個穩定可使用的Ozone發佈版本。本文筆者根據目前社區JIRA上對SCM HA的部分設計要點，來聊聊關於Ozone SCM服務的HA，我們有哪些主要設計要點以及其與OM HA的不同之處。
SCM HA相較於OM HA的區別點
這裏SCM是StorageContainerManager名稱的簡寫，而OM是OzoneManager的簡稱。在Ozone服務中，SCM是底層提供存儲能力的基礎服務，OM則是其上的應用服務。對於OM這樣的應用服務，它在實現HA時重要考慮的點在於Leader/Follower服務節點上db元數據狀態的一致。瞭解Ozone OM的同學應該清楚，OM的元數據不是類似HDFS NameNode的純內存的維護，而是用外部K-V db庫做存儲的，而這個db是以文件形式持久化在本地的。因此OM HA在實現中只要做到這個外部db的數據同步更新，基本上就算完成OM HA的核心操作了。
SCM HA服務內存狀態數據一致性的控制
但是SCM HA如果要去實現的話，它需要考慮的東西就要複雜很多了。首先它同樣有類似OM db這樣的元數據需要去同步，在SCM中這類的數據有Container，Pipeline數據。另外SCM在內存中還維護着Container，Pipeline的狀態數據，它們的狀態數據是根據下面Datanode實時彙報上來進行更新的。這類狀態數據實質上不會更新在db文件裏去，因此在SCM HA的實現中，內存狀態數據的一致性同樣是一個需要關注和考慮的點。
對於SCM HA的內存狀態一致性控制，筆者個人的傾向是同樣利用Apache Ratis做內存狀態的控制，要定義相應內存狀態更新的StateMachine來做。OM HA目前實行有db transaction更新的StateMachine實現了，SCM HA的db更新可借鑑於此。
Follower SCM內部管理服務的“失效”處理
Ozone SCM內部包含許多管理服務類進行着Node，Container以及Pipeline的管理，此類服務在後面的Follower SCM內都應該"失效化"，另外一種解釋可以稱之爲“空跑”，不做任何實質的處理操作。我們只允許Leader SCM服務做請求操作處理，並同步replicate它的狀態改變到Follower SCM上，這個狀態改變包括
- db transaction
- 內存維護狀態的update
這裏提到的管理服務包括有以下幾類：
- ReplicationManager，以及類似此Manager類。
- ReportHandler，以及類似此Handler類。
當然這裏有人可能會說了，爲什麼我們不能維持Follower SCM中ReportHandler的功能，來做Container，Pipeline內存狀態的更新呢？類似於HDFS NameNode那樣呢？這裏實質上有Container report信息到SCM服務的latency考量，以及此狀態延時可能造成的後續問題還需要進一步地實現討論。因此纔有了前面小節提到的做到SCM服務間內存狀態的完全一致性同步方案考慮。
SCM HA failover行爲處理
SCM服務從單點模式變爲HA模式，SCM服務本身Leader選舉切換理應對其Client端(這裏目前指的就是OM服務)來講是透明的。SCM的做法和現有OM HA類似，Follower角色服務拋出異常並且附帶當前的Leader角色的SCM地址id，然後Client進行返回結果SCM id的retry。
SCM HA的整體架構圖
以下是社區SCM HA設計文檔中 SCM HA的整體架構設計圖：、
本文所闡述的SCM HA可詳見下面的文檔鏈接處。
引用
[1].https://issues.apache.org/jira/browse/HDDS-2823