Lustre's Load Balance Mechanism

• 利用虛擬機初步測試的結果發現 Lustre 檔案系統在寫入操作方面，本身就具有 load balance 的機制，
  在 OST 具有不同大小的情況下，MDS 會先指派 free space 較大的 OST 給予 client 寫入檔案。
  然而若 OST 全部具有同樣大小的情況，MDS 則會採用 round-robin 的機制，輪流分配 OST 給 client 端寫入檔案!
  
  
• 得到上面這個結論後的第一個反應就是，那麼 read 的 Load Balance 豈不是也已經作好了?
  一旦當初被寫入的檔案很平均地分布在各個 OST 中，那麼當 client 要讀取的時候，load 照理說也會自動被分散掉不是嗎?
  
  
• 關於這點必須要還再思考，並且構思接下來要實驗的方式!

• 使用 lfs 指令可以指定 file stripe 的大小、以及欲使用的 OST 數目，這個對 Load Balance 將會有幫助!

• Lustre 在處理 file stripe 上面有個缺點，就是無法自動判別 target OST 是否還有空間可以存放資料。譬如說，有四個不同大小的 OSTs ，其中最大的是40GB (假設是 OST01)，最小的是 5GB (假設是 OST04)，如果採用 file stripe 的方式將大檔案均勻分割再平均撒到四個OSTs中，這個情況下，OST04 一定會最先用完容量，一旦 OST04 的容量用完，那麼這個 client 就再也無法寫入任何檔案至所掛載的 Lustre 檔案系統中；可惜的是，此時其他的OST可能還有許多空間可以利用(光是OST01應該就還會有35GB的空間可以使用)。因此這是 lustre 在處理 File Stripe 時的一個重大缺點。用一句話來形容："針對容量差異越大的 OSTs，Lustre 就越無法有效率地使用它們"。

• 相反地來說，若是針對OST大小差不多的情況來看的話，"lfs setstripe" 指令在處理大檔案這方面，的確提供了相當好的 Load Balance 機制。以 Grid 的概念來看的話，是不可能每個 OST 都差不多擁有相近的容量的；然而若是以 cluster 來看的話，OST 的大小是可以設定成差不多的。以目前的測試環境來看，比較像是 cluster 的環境，因為大多是相同容量的硬碟。以測試來說的話，這個問題可以暫時忽略。

• 以 "lfs setstripe -c -1" 這個指令來看的話，若是可以修改它，讓它做到隨時自動偵測各個 OST 的大小，並且及時回報給 MDT，促使 MDT 不要再將寫入的任務分配到即將耗盡空間的 OST 中，這是一個可以嘗試的方向，這個貢獻看起來似乎是還滿有意義的。

• 如果不考慮 File Stripe 的話，就沒有上述的困擾，上面都是針對 File Stripe 來討論，如果讀寫的檔案以小檔居多的話，實際上並不需要做 File Stripe 的動作，如此就沒有 OST 會浪費的問題，因為 Lustre 有內建機制可以自動將寫入的任務分配到剩餘空間(Free Spaces)較多的OST中。

整理一下上面所描述的成一張表格：

OST大小\欲存取的檔案大小	大檔案居多(need stripe files)	小檔案居多(no stripe needed)
OST的大小差異大 (類 Grid 的環境)	使用 "lfs setstripe" 指令，但有無法有效利用所有 OST 的重大缺點	使用 Lustre 內建的 weighted allocator 來自動尋找空間剩餘較多的OSTs
OST的大小差異小 (類 Cluster 的環境)	使用 "lfs setstripe" 指令即可完美達到 Load Balance 的目的	使用 Lustre 內建的 round-robin 機制來自動輪流將檔案寫入 OSTs 之中

• 眼尖的民眾可以發現一個有趣的結果就是："最差的就會拖累整體"。平行運算中只要有一個特別慢的，那麼很可能就會拖累整個工作進行的速度；而檔案系統也是如此，容量越小的越容易拖累大家。但是在檔案系統中，只要能解決 "lfs setstripe" 指令在 類-Grid環境中處理大檔案的重大缺點，就可以解決此問題。就像在平行運算中使用 task-pull 的方式是一樣的道理，簡單地說就是能力越強的，要做的事情就越多。檔案系統也是，容量越大的，它被寫入的機會應該也要越大才是。直到大的都用完了，再來用小的。