Odnoklassniki 是 RuNet 上最大的 Apache Cassandra 用戶，也是世界上最大的用戶之一。 我們從 2010 年開始使用 Cassandra 來儲存照片評級，現在 Cassandra 管理著數千個節點上的 PB 級數據，事實上，我們甚至開發了自己的 .
12 月 XNUMX 日，我們將在聖彼得堡辦事處舉辦 。 本次活動的主要發言人將是 Odnoklassniki Oleg Anastasyev 的總工程師。 Oleg 是分散式和容錯系統領域的專家；他與 Cassandra 合作已有 10 多年，並多次 .
在聚會前夕，我們與 Oleg 討論了 Cassandra 分散式系統的容錯性，詢問他會在聚會上談論什麼以及為什麼值得參加這個活動。
Oleg 於 1995 年開始了他的編程生涯。 他開發了銀行、電信和運輸領域的軟體。 自 2007 年以來，他一直在 Odnoklassniki 平台團隊擔任首席開發人員。 他的職責包括開發高負載系統、大型資料倉儲的架構和解決方案，以及解決入口網站效能和可靠性問題。 他還在公司內部培訓開發人員。
- 奧列格，你好！ XNUMX月份發生了 ，獻給Apache Cassandra，與會者表示討論一直持續到深夜，請告訴我，您對第一次聚會的印像如何？
來自不同公司、不同背景的開發者帶著自己的痛苦、意想不到的問題解決方案和精彩的故事來到這裡。 我們設法以討論的形式進行了大部分聚會，但討論太多，我們只能觸及計劃主題的三分之一。 我們非常關注如何使用真實生產服務的範例來監控我們的監控方式和內容。
我很感興趣並且非常喜歡它。
- 從公告來看， 將完全致力於容錯，為什麼選擇這個主題？
Cassandra 是典型的繁忙分散式系統，除了直接服務使用者請求之外，還具有大量功能：八卦、故障偵測、模式變更傳播、叢集擴展/縮減、反熵、備份和復原等。 與任何分散式系統一樣，隨著硬體數量的增加，發生故障的可能性也會增加，因此 Cassandra 生產叢集的運作需要深入了解其結構，以預測發生故障和操作員操作時的行為。 使用 Cassandra 多年後，我們 ，我們準備分享，也想討論店裡的同事如何解決典型問題。
— 說到 Cassandra，容錯是什麼意思？
首先，當然是系統承受典型硬體故障的能力：機器、磁碟或與節點/資料中心的網路連線遺失。 但這個主題本身要廣泛得多，特別包括從故障中恢復，包括人們很少準備好的故障，例如操作員錯誤。
— 你能舉一個負載最多、最大的資料集群的例子嗎？
我們最大的叢集之一是 Gift 叢集：超過 200 個節點和數百 TB 資料。 但它並不是負載最多的，因為它被分散式快取覆蓋。 我們最繁忙的叢集可處理數萬個 RPS 寫入和數千個 RPS 讀取。
- 哇！ 東西多久會壞一次？
！ 我們總共擁有 6 多台伺服器，每週更換幾台伺服器和數十塊磁碟（不考慮機器群升級和擴展的平行過程）。 對於每種類型的故障，都有明確的指示說明要做什麼以及按什麼順序進行，一切都會盡可能自動化，因此故障是例行公事，並且在 99% 的情況下發生時不會被用戶注意到。
——你如何面對這樣的拒絕？
從 Cassandra 運行之初和第一起事件開始，我們就研究了備份和復原機制，建置了考慮到 Cassandra 叢集狀態的部署程序，例如不允許重新啟動節點如果資料可能遺失。 我們計劃在聚會上討論這一切。
——正如你所說，不存在絕對可靠的系統。 您準備並能夠處理哪些類型的故障？
如果我們談論 Cassandra 叢集的安裝，如果我們在一個 DC 或整個 DC 中丟失多台機器（這種情況已經發生），使用者將不會注意到任何事情。 隨著DC數量的增加，我們正在考慮開始在兩個DC故障的情況下保證可操作性。
— 您認為 Cassandra 在容錯性方面缺乏什麼？
Cassandra 與許多其他早期 NoSQL 儲存一樣，需要深入了解其內部結構和發生的動態過程。 我想說它缺乏簡單性、可預測性和可觀察性。 但聽到其他會議參與者的意見會很有趣！
奧列格，非常感謝您抽出時間回答問題！
我們正在等待每一位想要在 12 月 XNUMX 日在我們聖彼得堡辦公室舉行的聚會上與 Apache Cassandra 操作領域的專家進行交流的人。
來吧，會很有趣的！
來源： www.habr.com