隨著 Rook 越來越受歡迎，我們想談談它的缺陷以及在使用過程中可能遇到的問題。
關於我：自 hammer 版本以來具有 ceph 管理經驗，社群創辦人 在電報中。
為了避免毫無根據，我將參考 Habr 接受的有關 ceph 問題的帖子（根據評級判斷）。我也遇到了這些帖子中的大部分問題。所用材料的連結位於帖子末尾。
在有關 Rook 的文章中，我們提到 ceph 是有原因的 - Rook 本質上是用 Kubernetes 包裹的 ceph，這意味著它繼承了 ceph 的所有問題。我們先從 ceph 問題開始。
簡化叢集管理
Rook 的優點之一是可以透過 kubernetes 輕鬆管理 ceph。
然而ceph包含超過1000個設定參數，而透過rook我們只能編輯其中的一小部分。
Luminous 上的範例
> ceph 守護程式 mon.a 設定顯示|廁所
1401
Rook 的定位是安裝和更新 ceph 的便捷方式
不使用 Rook 安裝 ceph 沒有任何問題 - 可以在 30 分鐘內編寫一個 ansible playbook，但更新時會出現很多問題。
引用 Krok 的帖子
例如：從悍馬升級到珠寶後，Crush 可調裝置操作不正確
> ceph osd crush 顯示可調參數
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
“個人資料”：“未知”，
“最佳可調參數”：0，
...
}
但即使在小版本中也存在問題。
範例：更新 12.2.6 使叢集進入健康錯誤狀態，並且 PG 有條件中斷
不更新，等待測試？但我們似乎使用 Rook 是為了方便更新等等。
Rook 災難復原叢集的複雜性
例如：OSD 崩潰，拋出錯誤。您懷疑問題出在配置中的某個參數上，您想要更改特定守護程序的配置，但由於您有 kubernetes 和 DaemonSet，所以無法更改。
別無選擇。 ceph 告訴 osd.Num injectargs 不起作用 - OSD 已關閉。
除錯複雜性
對於某些設定和效能測試，需要直接連接到 osd 守護程式套接字。對於 Rook 來說，您首先需要找到所需的容器，然後進入它，找到缺少的偵錯工具，然後感到非常沮喪。
順序 OSD 提升的難度
例如：OSD 出現 OOM，開始重新平衡，隨後後續的 OSD 也出現故障。
解決方案：逐一提升 OSD，等到它們完全包含在叢集中後，再提升下一個 OSD。 （有關更多詳細信息，請參閱 Ceph 報告：災難的剖析）。
對於裸機安裝，這只需手動完成；對於 Rook 和每個節點一個 OSD 的情況，沒有特別的問題；如果每個節點的 OSD> 1，則會出現順序提升的問題。
當然，它們是可解的，但我們引入 Rook 來簡化，結果卻變得複雜。
為 Ceph 守護程式選擇限制的困難
對於 ceph 的裸機安裝，計算叢集所需的資源非常容易 - 有公式和研究。當使用弱 CPU 時，您仍然需要執行一些效能測試，以了解什麼是 Numa，但它仍然比 Rook 更容易。
對於 Rook 來說，除了可以計算的記憶體限制之外，還有設定 CPU 限制的問題。
在這裡，您必須努力進行效能測試。如果將限制設定得太低，則會得到一個緩慢的集群，如果設定了 unlim，則會在重新平衡期間獲得活動的 CPU 使用率，這會對 Kubernetes 中的應用程式產生不良影響。
網路問題 v1
對於 ceph，建議使用 2x10Gb 網路。一個用於客戶端流量，另一個用於 ceph 服務需求（重新平衡）。如果您在裸機上使用 ceph，那麼這種分離很容易配置，如果您使用 Rook，那麼透過網路分離會給您帶來問題，因為並非每個叢集配置都允許您為 pod 提供兩個不同的網路。
網路問題 v2
如果您拒絕分離網絡，那麼在重新平衡期間，ceph 流量將堵塞整個通道，並且 Kubernetes 中的應用程式將會變慢或崩潰。您可以降低 ceph 重新平衡的速度，但是由於重新平衡時間較長，第二個節點因磁碟或 OOM 而脫離叢集的風險會增加，並且叢集只能保證只讀。
長期重新平衡 - 長期應用程式減速
引自 Ceph 的貼文。災難的剖析。
測試集群效能：
4 KB 寫入操作需要 1 毫秒，1000 個執行緒的吞吐量為 1 次操作/秒。
4 MB（物件大小）的操作需要 22 毫秒，效能為每秒 45 次操作。
因此，當三個域中有一個域發生故障，叢集在一段時間內處於降級狀態，並且一半的熱物件分散在不同的版本中，那麼一半的寫入操作將以強制復原開始。
我們將強制恢復時間大致計算為對退化物件的寫入操作。
首先我們在 4 毫秒內讀取 22 MB，寫入 22 毫秒，然後在 1 毫秒內寫入 4 KB 的實際資料。總體而言，對 SSD 上降級物件的一次寫入操作需要 45 毫秒，而我們的標準效能為 1 毫秒 - 效能下降了 45 倍。
我們擁有的退化物體的比例越高，一切就變得越可怕。
事實證明，重新平衡速度對於叢集的正常運作至關重要。
ceph 的伺服器特定設置
ceph 有時需要特定的主機調整。
例如：sysctl 設定和 JumboFrame 相同，其中一些設定可能會對您的有效載荷產生負面影響。
Rook 的真正需求仍有疑問
如果您在雲端，您可以從雲端提供者處獲得存儲，這更加方便。
如果你在自己的伺服器上，那麼管理ceph會更方便，不需要kubernetes。
您是否從任何低成本託管機構租用伺服器？然後你會對網路、其延遲和頻寬產生很多困擾，這顯然會對 ceph 產生負面影響。
合計： 實施 kuberentes 和實施儲存是不同的任務，具有不同的輸入和不同的解決方案選項 - 混合它們意味著在選擇其中一個時做出可能很危險的權衡。即使在設計階段，將這些解決方案結合起來也會非常困難，而且還有營運期。
使用文獻列表：
你說 Ceph...它真的那麼好嗎？
頭孢。 災難剖析
來源： www.habr.com
