使用 MogileFS 的一些經驗

我想,KKBOX 的 MogileFS cluster 應該是目前有公開使用 MogileFS 單位中,最大的一座 MogileFS cluster 了。

在 KKBOX Blog 的這篇提到了一些目前 KKBOX 使用 MogileFS 的狀況,這裡補充一些原文沒提到的技術資訊。

Database

首先是 Database,由於 MogileFS 透過 MySQL 的 lock functions (GET_LOCK(), RELEASE_LOCK()… ) 來確保不會同時對一個檔案進行操作,所以我們無法使用 Percona XtraDB Cluster 之類的 Galera Cluster based solution,而是採用標準的 MySQL。透過 DRBD 做 MySQL 的 HA,並配合 Heartbeat 提供 Active-Standby VIP 架構。

Tracker

Tracker 的部份同這邊提到的,早先是在部份的 data node 上跑 tracker(mogilefsd)。初期跑起來輕鬆愉快,但是在 data node 數量日益增多後,我們發現這樣的架構有幾個問題:

  1. 管理成本增加
  2. 在 rebalance 或 device (disk)更換或加新 data node 時,兼 tracker 角色的 data node 很容易頻寬被吃滿導致其上的檔案無法正確存取。

解法是將 tracker 獨立出來,目前的架構是兩台一組,用 heartbeat 做成 active-active 架構,兩個 VIP 走 DNS round-robin 方式將量打散。在 tracker 遇到效能瓶頸時一次加兩台機器進去。

硬體架構

這邊提到

36 顆 6TB WD 紅標硬碟儲存 MogileFS 檔案。

早期的架構是透過 RAID card 做 RAID5 or RAID 6,一台機器做成一顆 MogileFS device。後來因為成本考量,改用 Linux 的 MD 來做 soft RAID。最後因為效能考量,調整成每顆實體硬碟就是一個 MogileFS device。

目前跑了三年多,硬碟故障率也還在預期中,平均一年壞 15~20 顆。

網路架構

這邊提到

tracker 和 storage server 都是兩條 1Gbps LACP 接到 Top-of-Rack 的 L2 Switch。
每台 Top-of-Rack 都是兩條 10Gbps 光纖 LACP 到資料中心的 Core Router。

起初是所有機器都只接一條 1G 線,後來發現 tracker 在 MogileFS 有大量 IO 時會吃滿 1G,於是我們把所有 tracker 都接兩條 1G,bonding 起來。

隨著用量逐漸成長,data node 開始也出現 1G 線路在尖峰時間會吃滿的情況。於是我們也把 data node 全部接兩條 1G 做 bonding。

接著就發現,所有機器都俱備 2G 線路後,變成機器接的 switch uplink 也需要有足夠的頻寬,於是我們就把 switch 的 uplink 改成兩條 10G。

最後,盡量讓整個 MogileFS cluster 放在相同的 subnet 下,甚至是相同的機櫃。

其他

  1. perl 的 Sys::Syscall module 有 bug,目前最新的 0.25 有問題,需要降回 0.23 或是手動 patch。
  2. tracker 的 replication worker 跑一跑會突然爛掉,所有 worker 健在,就是不做事。workaround 是定時重跑 replication worker 或是直接重跑 mogilefsd。這問題我們還在追,目前有一些進展。
  3. 加 data node 或換硬碟,一次要一批一起做。更換少量硬碟或是加太少 data node 上去,會使這些新硬碟或 data node 成為 re-sync/rebalance 熱點,在完成整個 re-sync/rebalance 操作前,會處於幾乎不可用狀態。這個現象隨著 MogileFS cluster 規模越大會越明顯。
本篇發表於 Linux, Software 並標籤為 , , 。將永久鏈結加入書籤。

發表迴響