華爲劉騰：華爲終端雲Cassandra運維實踐分享

點擊此處觀看完整活動視頻

 

各位線上的嘉賓朋友你們好，我是來自華爲消費者BG雲服務部的劉騰，我今天給你們分享的主題是華爲終端雲Cassandra運維實踐。和前面王峯老師提到的Cassandra在360中使用場景不一樣，我今天主要帶來的是運維相關的內容。在去年7月，咱們開發部的吳太銀也在Cassandra社區作過一次分享，講到了Cassandra在華爲的一些應用，包括一些在華爲遇到一些線上問題的定位和處理經驗。今天我就和你們講一下運維這一塊。

 

這是我今天要分享的內容，重點是第二部分：咱們在運維中遇到的一些問題。

華爲終端雲Cassandra使用場景和規模介紹

咱們首先介紹下華爲終端雲在Cassandra使用的狀況，華爲在2014年的時候開始使用Cassandra，這在國內也是相對比較早的。如今通過6年的發展，咱們達到了比較大的應用規模，全球節點數已經超過3萬，總存儲量超過20PB，還有最大的這個表記錄數三千億以上，這個量都是比較大的。

至於爲何華爲終端雲大量地使用Cassandra，這主要歸功於Cassandra自己的一些數據庫優點，好比它高可用、極致在線（應用無感）、可調一致性、多DC(datacenter)部署的特性。此外對運維方面也是很友好的，還有一些運維的工具等等。所以Cassandra在華爲終端雲這一塊應用的是比較多的。

咱們主要將Cassandra用在一些結構化的數據存儲，像咱們的社交風控、IoT等場景都用到了。如今咱們也有多個版本，最先的時候咱們用的是Cassandra 2.x的版本。這是咱們華爲終端雲的一個使用狀況。

運維面臨的主要挑戰

咱們在終端雲這一塊業務發展的這麼快，Cassandra規模這麼大，咱們不免也會遇到一些問題，主要體如今如下這四個方面。

1. 可靠性：早期咱們是IDC機房，這種自建的託管的機房。咱們須要維護這些硬件設備、處理硬盤損壞的這些問題。還要考慮到機房AZ級的這種故障，或數據一致性、備份的問題。而後在使用上，現網還會碰到Cassandra的一些自己的問題，像是大Key和熱Key的問題。

2. 數據庫問題和風險管理：在平常的一些變動管理的問題尤爲是一些高危操做。

3. 資源和成本管理：此外是資源成本這一塊。咱們有這麼多節點，如何管理是個問題。

4. 運維效率： 咱們人數有限（2～3）人，那如何提升運維效率。 

 

我會主要圍繞以上這些話題來說，當遇到這些問題時咱們華爲終端雲是如何作的。

華爲終端雲Cassandra運維體系介紹

其實總體也是一個過程，咱們一開始也是慢慢地摸索過來的。而後咱們纔有一些比較規範的運維流程，由於運維仍是很注重流程的，就是按流程去正確的作事，因此流程很重要，咱們包括一些變動流程、問題處理流程等等。你們也都據說過，華爲公司自己就很注重流程的規範性、流程的建設。

咱們本身通過這幾年的發展，把平臺也建起來了，但咱們依託一些大平臺， 好比說監控的，包括部署和自動發佈的這種平臺。還有咱們本身專門開發的Cassandra運維管理的平臺，像一些作數據庫自動化變動的平臺。咱們會在後面重點介紹在可靠性、風險管理、運維效率等方面的挑戰。

運維實踐經驗分享之可靠性：大集羣拆分

首先咱們會講一下可靠性這一塊，在咱們的大集羣中會遇到一些問題，這是在咱們現網裏發生的一個例子：

咱們有一個超過450節點的大集羣，它的Token總數也比較大，超過10萬。但在咱們當時擴容的過程當中，業務全部的節點負載都很高，業務也受到影響。過後咱們對其進行了分析，發現原始Cassandra客戶端請求、計算路由的時候會有一個讀寫鎖。這本質上當有節點在擴容的時候，它也會更新路由信息。若是你更新比較慢，鎖一直沒被釋放，這會致使你後面的讀寫也拿不到鎖，這樣的話就會致使你的請求一直出差，最終你的服務器負載要持續升高，那就出現問題。

對於這種問題，咱們就有一些建議。一個是你的控制集羣的規模，尤爲是虛擬Token數量。咱們原來最先的時候設的Token number數的是256，若是節點一多，那Token總數就會很大，這便會影響它自己的計算性能。所以咱們建議Token數不要超過10萬。其實咱們在社區上也找到過一個case，跟咱們這個狀況差很少，他當時也遇到這個問題。 他好像是Cassandra 3.x的版本，咱們是當時仍是Cassandra 2.x的版本。

而後對於一些新的集羣，若是你的數據很大，要提早作好容量規劃，儘可能不要讓集羣中單節點負載過大，不要等到過後再去拆分。我看到以後Cassadra 4的版本優化了Token的分配和管理機制，那在後面是能夠嘗試升級到Cassandra 4的版本的。

這裏我實際上是經過這個案例來說爲何要作大集羣拆分，其實若是集羣太大的話，它還會帶來一些問題，好比說你這個擴容會比較慢，由於你每次只能擴一個節點，對不對？你的集羣一大，你擴容確定會比較慢，還有就是數據修復也會比較慢。

因此對於這種大集羣，咱們是建議要控制規模。雖然理論上Cassandra也許能夠支持幾百上千個節點，但若是你真正到那麼大的規模，我以爲對於運維來講是一個很是大的挑戰，對系統穩定性也有必定影響。

咱們原來有一個業務集羣就作了一個拆分，那怎麼拆？這幾年來，咱們的一些早期業務可能有多個服務，這些服務可能就共用了一個集羣，而後經過不一樣的Keyspace和Table來區分。規模太大以後怎麼辦？咱們建議它按照服務維度和keyspace表維度進行拆分。

咱們這裏面有幾點要注意的。存量的數據，咱們能夠經過打快照sstableloader作一個遷移。而後增量數據咱們能夠用到Kafka，前提是咱們要改一下咱們的驅動，要支持雙寫。雙寫就是你在寫你原集羣的時候，你要把數據主鍵寫到kafka裏面，這樣的話咱們會有一個消費的程序。我去Kafka裏面把主鍵查出來，去原集羣反查，把數據寫入到新集羣，經過這樣的方式作到一個全量加增量的數據同步。作完以後，咱們可能還要作一個一致性的對比。這就是一個大集羣拆分的思路。

運維實踐經驗分享之可靠性：多AZ部署

以前咱們提到由於可靠性在IDC機房面臨的一些問題，後面就慢慢遷移到雲上了。其實雲上也會面臨一些問題，好比說你這麼大的集羣，你會有反親和的問題。雲上那些虛擬機你是看不到它分佈在哪一個物理機上面的，那就須要用到反親和組，你不可能把你的集羣機器都獨立放到一臺物理機上，由於公有云實際上是有可能會存在這種狀況的。若是有物理故障，它會影響到集羣的可靠性。如今有不少雲廠商都有專屬物理主機，若是你集羣規模都太大，你本身買單獨虛擬機，而後利用Cassandra自己的機架感知，從而讓Cassandra將不一樣副本分佈在不一樣的機架上。

其次就是如今不少公司推薦並在使用的，也就是3AZ部署，在這裏咱們會介紹咱們的場景的主管模式，咱們在消費和終端裏都有用到。好比圖中的雙AZ副本，它的優勢也很明顯，你若是client的話，你正常只會訪問本地DC（圖中對應的是AZ），但問題是成本高，還有要本身考慮故障切換。

3AZ3副本的優勢是，咱們能夠把每一個AZ當一個虛擬rack來看待，那讀寫一致性就能夠用QUORUM，這樣成本就會低一些，任意AZ的故障也不會影響可用性。但它也有的缺點，你由於跨AZ隨機訪問會增長訪問時延，這取決於你AZ間網絡時延。通常像公有云廠商AZ間時延說的是不高於兩毫秒，但若是你的業務對這種時延比較敏感的話，那可能這種並非特別適合。對它的性能可能也會有必定的降低，咱們測試出來大概是會下降15%～20%。

如今不少初創型公司都會部署到公有云的服務器上，大家能夠嘗試一下這種3AZ部署方式，作一下性能測試看看效果如何。

在Cassandra原來是一個DC的狀況下，若是要拓展到多個DC，咱們要考慮如何同步這些數據。

首先咱們既能夠用nodetool rebuild也能夠用sstableloader。這兩種方式也有不同的地方，build只能從原AZ(DC)其中的一個副本節點獲取數據, 若是三個AZ副本不一致，那有可能沒法獲取一致的數據，咱們所以建議在同步以前要作repair操做。sstableloader的問題是拷貝的數據量是原來的三倍，所以磁盤須要申請額外的存儲空間，數據遷移完成後還要用nodetool cleanup刪除冗餘的數據。這兩種方式能夠根據你的使用狀況來選擇性的使用。

運維實踐經驗分享之可靠性：數據一致性

接着咱們來談一下數據一致性所遇到的一些問題，雖然咱們使用quorum或local quorum，但這也是Cassandra會面臨比較多的一個問題。由於你始終會面臨壞盤、節點宕機，或某些公司出現的集羣網絡、負載不穩定等問題。這些都會致使數據不一致。若是你經過本身的DBA管理這些物理機，這樣的成本仍是比較高的。如今不少都是在雲上的，包括咱們也是經過雲將數據遷移到虛擬機。將硬盤換成雲硬盤，數據一致性相對就會好不少了。固然，它也會帶來一些問題，好比成本會有小幅上升。還有hint的保留時長也能夠從默認的3小時改成24小時，這對磁盤的存儲增長不會很大，若是你的集羣網絡環境比較穩定的話，就不會有什麼問題。

最後就是要對數據作一個按期地修復，也就是所謂的repair操做。你通常兩週到一個月作一次，其實不會有太大的問題。但不用作的太頻繁，由於修復太頻繁會佔用過多資源。同時你要控制修復段足夠的小，併發量要控制好，儘可能不要影響在線的業務。

咱們其實有多個場景，用的兩個最直接的部署，咱們也會按期去作一個對比。在華爲終端雲這裏，咱們早期也用了ES(ElasticSearch)來彌補Cassandra二級索引的不足，但這也會帶來一些問題。由於ES和Cassandra數據會有不一致，你要按期作一些檢查修復。

運維實踐經驗分享之可靠性：數據備份

接下來咱們介紹一下數據備份，這是爲了一些極端的場景，其實大部分狀況下你是用不到的。但對於咱們這麼大的規模來講，有不少重要核心數據，所以咱們必定是要考慮這種備份，這裏有幾個場景，我就不詳細介紹了。備份其實仍是基於原生Cassandra的快照(snapshot)的能力。它其實本質上就用的是Hard Link，這樣咱們便會把這數據備份到咱們的OBS存儲中。目前咱們RPO能夠作到5分鐘之內，RTO大概就是根據數據的下載的時間，通常1T數據大概要2~3小時。

我以爲對於一些小公司和初創型公司來講，你要關注的是你要出現了誤操做怎麼辦？你可能認爲你的數據不須要備份到OBS這種程度，但你可使用Cassandra自己自帶的特性，你能夠把配置文件裏的配置項都打開，如在作TRUNCATE的時候作自動快照。這我以爲是Cassandra的對運維來講很是好的一個的地方。若是你真的誤刪了，其實硬盤上並沒刪除。你仍能夠經過快照很快地進行恢復，這也不須要什麼太大的成本。無論是開發人員、仍是運維人員，我強烈建議你們在後面使用的時候打開這些開關，防止一些極端的狀況。

運維實踐經驗分享：Cassandra數據庫風險治理

下面列了一些咱們數據庫現網的一些問題管理中的使用規則。有些開發同事可能認爲這些規則限制了他，但這些機制實際上是Cassandra自己的一些約束。若是你突破這些約束，你的現網可能會出現一些不可預知的問題。假如你在設計schema階段引入了問題，到後期一旦出現問題，在短期內是沒法解決的。你要從新優化schema，作出新的版本，這會花費很長的時間。

所以在咱們這裏會先立規則。你們在開發的同時，必定要知道這些規範，在開發階段就要減小這些問題。在咱們華爲，若是你有業務要接入Cassandra，你要按照這些規則自檢一下，咱們作一個簡單的評審，若是沒有問題，咱們就會給你提供一些建議方案。若是你的分區鍵在你的表結構Schema設計上存在一些問題，咱們會給出一些建議，讓你優化以後再接入現網。若是後期實在仍是有漏掉的，咱們經過一些巡檢，把這些問題找出來，會通知到業務，跟業務一塊兒去作一些優化。

我看到DataStax公衆號上面有一篇文章也講的很是詳細，有哪些注意事項。我認爲每一個開發的同事，包括運維的同事都要認真熟讀一下。

運維實踐經驗分享：熱key案例

這實際上是咱們一個熱Key的案例，我就不詳細講了。其實你在設計Schema的時候便要考慮你的場景是否存在熱Key，能規避則儘可能規避，若是規避不了則須要靠多級緩存。若是熱Key的話加Redis可能還不夠，由於Redis也是單點的，可能還須要考慮本地多級緩存。或者用redis自己的這種前端proxy作負載均衡才能解決問題。熱Key這種問題是比較難處理的，我估計不少開發人員都會所面臨這種問題。但你要避免熱Key出如今Cassandra中，若是出現了，對Cassandra影響會比較大，甚至會影響正常Key的訪問。所以熱Key在設計階段必定是要規避的。

運維實踐經驗分享：CQL發佈

咱們有這麼大的規模，所以咱們常常有一些變動，須要一些數據庫的自動化平臺來幫咱們提高一些效率並下降一些風險。咱們的DBA人數有限，可能不能完成這麼多事情。

咱們如今有一個CQL的審覈模塊，它會自動把你的那些你看到那些DDL腳本解析出來。若是是非高危字段，咱們可讓你走自動化變動流程。若是是DROP這樣高危的刪除字段操做，咱們是不會讓你自動在現網上運行的，要走另外的流程。對於那些剛開始的，尤爲是有些公司沒有運維的同事，大家的變動裏若是有高危操做你必定要先識別出來。還要考慮操做前有沒有備份，出現極端狀況下是否有可挽救的措施，這些是必定要注意的。

運維實踐經驗分享：基於AIOPS多維度故障診斷

最後咱們介紹下監控，由於前面看到線上的一些朋友在問監控怎麼作，咱們也分享一下咱們的經驗。其實咱們比較簡單，就像一些技術指標監控，這種你們都會。不少開源軟件都很方便，網上的文檔也不少，像早期的Zabbix和如今的Prometheus。包括Cassandra內部的JMX，在採集metrics時都有現成的模版，Prometheus也都有相關的支持。我以爲你們能夠把這些監控都加上。咱們後面也有本身加的監控，好比說咱們本身在驅動裏面會把一些時延成功率等這些信息打到日誌裏，而後上報到咱們的日誌平臺中作一些監控。

這個好處是你能夠端到端去看你Cassandra的狀況，觀察客戶端到Cassandra的時延成功率是怎樣的。這有利於你經過一些網絡等幫助你去對問題進行一些定位。還有好比咱們時延成功率，咱們能夠作一些動態預知的告警，咱們平臺有機器學習的能力，當你忽然有波動的時，好比有業務版本變動或者業務忽然有個浪涌上來了，這時候你就知道有異常。這種便有利於提早及時去發現問題。

運維實踐經驗分享：自動化巡檢

咱們還講一下巡檢，巡檢其實跟監控有一點差別。巡檢實際上是提早去發現問題，不是等告警的時候才發現問題。咱們針對前面講的一些指標容量風險，包括成功率時延等等進行一些巡檢，但咱們會作一些圖。

其實對一些沒有專門運維人員的小公司，你能夠用那些監控的API接口本身寫一個python腳本或一個Java程序。腳本天天把數據採集出來，統計彙總後，發郵件給相關責任人看一下，這樣也是蠻好的，也不須要作這麼漂亮的一個圖。

社區版Cassandra的運維優化建議

前面咱們講了運維面臨的一些挑戰和實踐經驗，其實咱們也遇到了一些問題，想提出來和你們探討一下。

但願改進的功能：

• Repair： 由於repair仍是比較消耗CPU和IO資源的，在集羣數量大時，修復時間會變長，咱們還要關注對業務有沒有額外影響。但願後期有人能對repair的資源佔用作出必定的限制，好比作一些限制配置類的東西。

• 數據遷移的方案： 還有就是數據遷移的方案，好比之後業務要從其它數據庫或者IDC機房遷移到雲上的話，Cassandra有沒有一些好的遷移方案，這樣開發者就不須要本身作一些開發，從而提升應用性。

• 數據一致性不可度量和監控：對於數據一致性不可度量，我以爲一時半會也沒有什麼好的解決方案，沒辦法很好的監控。

• 二級索引： 目前已經支持的兩種二級索引其實都是不太推薦你們使用的。

但願支持的功能：

• 支持表計數統計：咱們有不少開發人員帶着SQL的使用思路，想查詢一張表有多少條記錄。其實這目前是查不出來的，咱們只能經過其它手段進行一些統計。

• Nodetool支持commitlog的解析和回放：目前社區尚未這個功能，若是作到的話，數據備份就能夠作到按時間點恢復，也就是真正的PITR(Point-In-Time-Recovery)。

• 墓碑：還有就是墓碑的一些優化。

待探討:

• RocksDB（優化GC問題）：前面不少老師也提到了，RocksDB應該也是有一些規劃的。目前RocksDB也比較火爆，不少大廠如今都在考慮用RocksDB作一些多模數據庫。存儲引擎好像都會用會考慮用Rocksdb。

• 3AZ部署狀況下驅動優化路由算法，也就是下降跨AZ訪問的時延。

• 將來是否會考慮分支，將存算分離、強一致性做爲一個分支。咱們企業雲的兄弟部門在這方面作了一些嘗試。

最後，咱們2020年經歷了全球的疫情，這對線上的應用確實是爆發式的增加。對於Cassandra來講是有不少機會的，實際上咱們華爲終端有不少應用是能夠用Cassandra的。好比一些原來用Redis的能夠切換到Cassandra，這對Cassandra來講都是一些機會。

提問環節

問： 怎樣實現C*數據冗餘複製和控制存儲成本之間的平衡？

答：其實這是一個可靠性和成本之間的取捨。得根據業務場景來看，咱們有一些業務它數據是核心數據，那它也願意多出一些成本。好比說它的副本能夠爲三甚至達到AZ級容災。同城雙活的話，那就是6個副本。

 

若是對於數據可靠性要求不是特別高，三副本其實能夠解決大部分的問題。甚至有一些用OLAP的場景有的咱們有離線的數據，用兩個副本也是ok的，要根據業務的實際場景來。

問：大集羣中數據一致性修復的挑戰有哪些？

答：這個問題我以爲提的很好，咱們原來一些大集羣，在面對前面的大數據修復時，它要面臨幾個問題。第一個它的修復週期特別長，還有一個就是咱們對現網的影響。你修復時要控制住，不能讓它有對現網產生影響。須要控制修復的併發，包括token段的切分，要切的足夠小。

 

問：自動化C*集羣運維的挑戰在哪裏？有哪些技術和工具能夠參考？

答：其實運維這一塊，咱們前面其實也提到了，以前介紹了一些咱們主要遇到的問題。自動化運維的話，咱們有作一些自動發佈和自動部署，這能夠提高一些效率。也包括監控這一塊，咱們講了一些多維度的監控，還有巡檢。

 

監控的工具方面，一開始咱們有用OpsCenter，開源的像是Zabbix和Prometheus這些。用於定位問題的像是自帶的nodetool，有不少命令，對於平常運維效率是頗有幫助的，我建議你們都去了解一下。