EExcel 丞燕快速查詢2

EExcel 丞燕快速查詢2
EExcel 丞燕快速查詢2 https://sandk.ffbizs.com/

Ray Tracy ZFS

Ray Tracy 一個工具或技術, 能否達到你的期望用途, 關鍵在於:

使用者是否充分了解他, 並且能夠熟練的駕馭他.

世上沒有絕對好用的工具, 也沒有絕對該用甚麼的場景:

我曾經深度挖掘 zfs 的各種參數, 試圖調到最好, 經過半年之後卻發現, 當我的 Workload 特性有細微改變的時候, zfs 會放大這些改變, 導致整個運作偏離我預想的方向....(其實就是參數過度優化: Over-optimized, 但我發現 zfs 的參數很容易讓你走上這條路)

這問題, 導致我必須經常監督 zfs 的表現, 並記錄我的 workload 每一個時間軸的變化趨勢, 好讓我在下周或下個月, 遇到新的問題時, 知道該朝甚麼方向改變甚麼參數, zfs 才能獲得最佳結果.

這對 Hacker 或 Geek 來說, 是件無比美好的事情, 因為他們每周都可以看到新的變化, 接受新的挑戰, 然後從當中挖掘出更多 zfs 新的參數組合與用途, 再來發表給大家聞香敬拜....

但對機房的 SRE 來說, 這件事情根本就是噩夢, 因為原本可以安穩睡一個星期的覺, 現在變成每天半夜都睡不著, 你不知道他是否會在半夜 3 點突然惡化, 導致線上有 50 萬個會員在交易的電商網站, 反應變慢, 破圖, 甚至無法交易, 最後被客戶從睡夢中挖起來解決問題.....

我也跟您一樣, 試圖解決 Storage 同步的問題, 而引進 Gluster 技術. 剛開始看似一切正常, 資料都正常複寫, 直到有一天, 某一台 node 意外故障而重開, 觸發 Gluster 開始做 healing 的時候, 我才發現:

- 他的 healing 比我預期的時間更長上數十倍
- 他在 healing 期間會造成 VM 寫入資料異常
- 他在 node 發生 flip-flap 的時候, 會選出錯誤的 node

這些問題難道都沒測試過嗎? 有啊, 但是我測試的時候, 並沒有出現這些現象, 國外人家測試的時候, 也沒有特別警告這些現象; 初期也都沒問題, 是跑了幾個月之後, 才開始劣化....

所以, 我從每天調校 zfs, 轉成每天要調校 Gluster, 參數又多如牛毛, 排列組合起來有上百種變化, 然後又是生產環境, 我不能隨便停下來測試, 每一次調整都得確保線上系統不會掛掉, 也不能隨便重開機...

如果當初我知道會有這麼多問題, 我絕對不會這麼快就讓他上生產環境, 至少要測到我有信心為止. 但是, 最初的測試都顯示: 他們似乎是個很好的選擇, 直到我上了生產環境之後數個月, 才開始出問題....

最後我回到傳統硬體 RAID +NFS, 當然這樣的效能無法滿足原先用 zfs 的期待, 不過我又自行加上 bcache 技術設法加速, 只是我選擇比較保守的參數, 以資料安全性為優先, 不追求最高效能; 初步看起來, 這樣大概可以滿足我現行的狀況還剩一點點餘裕, 至少, 他不會造成我整個 I/O 被 block 住, 連 CPU 都被吃死死不能動的狀況 (此問題我在 zfs 和 gluster 都遇到)

但是這個組合, 沒辦法解決跨 Storage replication 的問題, 也就是沒有 HA; 所以, 我勢必要跳離這個方案, 目前下一個候選者是 Ceph, 但過去幾年來, Ceph 有名的除了很容易做到大容量 Scale-out 和 Replication 之外, 還有一個眾人皆知的缺陷是: 效能低落, 所以, 我該如何解決效能低落問題, 同時享受他帶來的 Scale-out 好處? 並且, 在我的環境內可以正常工作?

我的經驗, 並不代表別人也是同樣的狀況, 你可以找到許多把 zfs 和 gluster 用得很愉快的用戶, 但是他們的 workload 和環境也跟我大不相同....

這些 Storage 的課題, 都需要在實際環境中實做過才會知道...














向聖夫 這種 fine tuning 必須從 application 層級開始 跑很多 micro service 才有可能針對每一個 micro service 去優化
.
但是如果你把所有的 workload 放在一個 vm 裡面, 你會發現 你的 write 變快了 但是犧牲了你的 read.... 這個時候怎麼優化都會出問題

你有 sequential write 其實需要的是 spinning disk 才快

你有 random write 小 io 這個是要 nvme ssd 才快 Ray Tracy 說的 bcache 很讚 但是它還是有誤判的情況 以及每一顆 nvme ssd 的 controller 能夠同時處理的 thread 跟 command 都不一樣 所以你優化 A 牌的參數換到 B 牌上去時 是完全沒路用

如果你仔細觀察 nvme ssd 下的 controller busy time 你就會發現 當ssd command 塞爆的時候 你會發現它比 hdd 還慘 ( 不是 ssd 上的 ram buffer 用光了喲)