我想，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 數量日益增多後，我們發現這樣的架構有幾個問題：
- 管理成本增加
- 在 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 下，甚至是相同的機櫃。
其他
- perl 的 Sys::Syscall module 有 bug，目前最新的 0.25 有問題，需要降回 0.23 或是手動 patch。
- tracker 的 replication worker 跑一跑會突然爛掉，所有 worker 健在，就是不做事。workaround 是定時重跑 replication worker 或是直接重跑 mogilefsd。這問題我們還在追，目前有一些進展。
- 加 data node 或換硬碟，一次要一批一起做。更換少量硬碟或是加太少 data node 上去，會使這些新硬碟或 data node 成為 re-sync/rebalance 熱點，在完成整個 re-sync/rebalance 操作前，會處於幾乎不可用狀態。這個現象隨著 MogileFS cluster 規模越大會越明顯。