Ceph上容器之前的思考有哪些

小編給大家分享一下Ceph上容器之前的思考有哪些，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

服務(wù)的硬件資源需求

首先必須了解Ceph里面的MON、OSD、MDS、MGR、RGW各種服務(wù)的軟硬件需求，知道你規(guī)劃的Ceph規(guī)模是多大，當(dāng)前分配給對(duì)應(yīng)容器的資源是否合適，不然到了后期你需要做各種硬件資源調(diào)整而不得不重啟容器的時(shí)候，你的服務(wù)可用性會(huì)可能會(huì)大打折扣。總之就是一句話，硬件資源一步到位，不要瞎折騰。別讓OOM成為常態(tài)！

軟件平滑升級(jí)

不要以為上了容器你就可以輕松應(yīng)對(duì)軟件版本升級(jí)了，Ceph理論上是可以實(shí)現(xiàn)小版本的軟件混合部署，但是一旦你發(fā)現(xiàn)某個(gè)版本有坑，那你不得不全部調(diào)整到同一個(gè)版本的時(shí)候會(huì)發(fā)現(xiàn)一堆問題，先升級(jí)Mon還是OSD？大批量服務(wù)起不來(lái)怎么辦？出現(xiàn)slow request怎么辦？如果你天真的以為上了容器以后，通過幾個(gè)簡(jiǎn)單的容器命令實(shí)現(xiàn)ceph版本的平滑升級(jí)，甚至是跨大版本升級(jí)，那么你自求多福吧，跨大版本升級(jí)很少有不出問題的，最關(guān)鍵是升級(jí)操作基本上都是起手無(wú)回，敢?guī)еa(chǎn)數(shù)據(jù)去升級(jí)的都是“真正的猛士”。而且升級(jí)過程中出現(xiàn)的各種奇葩問題，可能資深運(yùn)維也不一定能夠hold住，最后還是得求助開發(fā)去協(xié)助處理，但是你知道一個(gè)懂Ceph源碼開發(fā)的工程師招聘起來(lái)有多難嗎？

無(wú)狀態(tài)服務(wù)？

Mon、OSD需要儲(chǔ)存數(shù)據(jù)到本地文件系統(tǒng)和LevelDB(RocksDB),而且都對(duì)存儲(chǔ)設(shè)備有一定的性能要求（特別是OSD），Ceph為了維護(hù)數(shù)據(jù)一致性內(nèi)部引入了epoch機(jī)制，這意味著你每一次服務(wù)重啟都會(huì)發(fā)生版本變更，這些基礎(chǔ)數(shù)據(jù)和對(duì)應(yīng)的服務(wù)都是強(qiáng)綁定，要想實(shí)現(xiàn)容器服務(wù)飄移到任意物理節(jié)點(diǎn)，你首先要解決容器volume數(shù)據(jù)共享，這樣你又得引入一套共享文件系統(tǒng)，一個(gè)坑沒填上又給自己挖了一個(gè)。既然做不到無(wú)狀態(tài)服務(wù)，那么MON、OSD這些角色容器化之前就要斟酌清楚要不要把原本簡(jiǎn)單的問題復(fù)雜化了。最后Ceph里面唯一可以實(shí)現(xiàn)無(wú)狀態(tài)服務(wù)的角色就是RGW，而且RGW結(jié)合容器化實(shí)現(xiàn)的負(fù)載均衡是一個(gè)非常適合場(chǎng)景，如果要實(shí)現(xiàn)無(wú)狀態(tài)的容器化，RGW是唯一選擇。

網(wǎng)絡(luò)構(gòu)架

每個(gè)Ceph服務(wù)進(jìn)程都需要綁定到靜態(tài)的IP（頻繁變更IP會(huì)極大增加維護(hù)統(tǒng)一配置的管理成本），而且最好是不要將單個(gè)ceph集群的服務(wù)節(jié)點(diǎn)跨網(wǎng)段部署（跨網(wǎng)段也會(huì)埋下一些坑），所以你的容器網(wǎng)絡(luò)是否支持Ceph的這些靜態(tài)配置的網(wǎng)絡(luò)需求，也需要提前考慮周詳。如果你的容器網(wǎng)絡(luò)是是三層套二層這種，一層一層封裝再一層一層解封，帶來(lái)的開銷絕對(duì)不可低估，最最最要命的是，任何分布式系統(tǒng)都對(duì)時(shí)鐘有著強(qiáng)依賴，節(jié)點(diǎn)之間的網(wǎng)絡(luò)延遲過高必然導(dǎo)致時(shí)鐘偏差，最終影響集群穩(wěn)定性和數(shù)據(jù)一致性。

性能損耗

OSD能夠用裸存儲(chǔ)設(shè)備的就不要用文件系統(tǒng)，鑒于現(xiàn)在Ceph的性能差強(qiáng)人意，盡量縮短IO路徑，絕對(duì)是明智的選擇。

運(yùn)維復(fù)雜度

日志管理

Ceph 各種奇葩故障都需要借助日志進(jìn)行定位，能夠第一時(shí)間看到故障現(xiàn)場(chǎng)是最好的，但是容器化以后查看日志就沒那么輕松了，如果真的要上容器化，那還是上一套類似ELK做集中日志管理吧。（coredump也是一個(gè)坑）

服務(wù)監(jiān)控

可能你原本已經(jīng)寫好zabbix一類的Ceph的監(jiān)控插件，但是現(xiàn)在換到容器，原來(lái)的方案還適用嗎？包括現(xiàn)有的MGR dashboard還有很長(zhǎng)的路要走。

硬件故障

這個(gè)是讓我吐槽最大的地方，原本OSD磁盤故障，直接幾條命令就可以搞定的事情，現(xiàn)在引入了容器以后，換盤的操作復(fù)雜度增加了很多，雖然可以上腳本自動(dòng)化去實(shí)現(xiàn)這些東西，但是對(duì)運(yùn)維人員的技能要求更高，原本換盤的技術(shù)棧為L(zhǎng)inux+ceph，現(xiàn)在是Linux+ceph+容器，無(wú)形之中提高了招人的門檻，當(dāng)然給的薪水也要高了,但是最后老板們就不高興了，特別是經(jīng)濟(jì)危機(jī)下的裁員，你給了老板一個(gè)充足的理由去干掉你。

以上是“Ceph上容器之前的思考有哪些”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！