2016-06-15 56 views
1

背景

我們面臨的問題是,我們正在做的視頻編碼,並希望負載分配到集羣中的多個節點。動態服務創建分配負載

我們希望將特定節點上的視頻編碼作業的數量限制在某個最大值。我們還希望將小視頻編碼作業發送到羣集中的某個特定分組節點,並將長視頻編碼作業發送到集羣中的另一個分組節點。

這背後的想法是通過將大型作業分割成單獨的節點池來幫助維護客戶端之間的公平性。這有助於確保小型視頻編碼作業不會被運行長編碼作業的單個租戶阻止/限制。

使用服務織物

我們計劃使用ASF服務的視頻編碼。考慮到這一點,我們有一個動態創建每個作業的服務的想法。然後可以使用放置約束來確定作業將運行在哪個節點池。基於內存使用情況,CPU使用情況的自定義度量標準...可用於限制節點上活動作業的數量。

使用此方法,分配作業的節點將不得不查詢是否可以創建滿足佈局約束和度量標準的新服務。

問題

  • 當一個服務不能放在一個節點上會發生什麼? (使用CreateServiceAsync我假設?)
  • 這個民意測驗是否過於昂貴?
  • 我們的視頻編碼可執行文件與大約80MB的服務一起打包。這會使新服務的啓動需要很長時間嗎? (分鐘與秒)

  • 作爲替代方案,我們可以使用基於隊列的可靠系統,其中大作業池從一個隊列中拉出,小作業池從另一個隊列中拉出。這似乎是更簡單的方法,但我想探索所有選項以確保我不會錯過Service Fabric的某些功能。有沒有更好的方法你會建議?

回答

1

我對配置約束和動態服務沒有經驗,所以我不能說這個。

性能指標的輪詢不是非常昂貴,據說這不是一個自由的操作。一秒輪詢間隔不應該導致任何巨大的性能影響,同時仍然提供相當程度的分辨率。

在部署時將服務包複製到每個節點,而不是在服務啓動時,因此它會使部署速度稍慢但不會影響服務創建。

您打算將工作數據放在可靠的集合中,但是問題在於如何實現。我剛纔提出的一個想法可能值得考慮,那就是將作業處理服務作爲分區服務,並基於編碼作業大小和/或租戶的分區策略,以便來自同一租戶的大型作業卡在同一隊列中,而較小的別人的工作去別處。另外,我過去處理過的一件事是SF遠程處理限制了發送的消息的大小,並在其太大時拋出,所以如果你的視頻文件從服務傳遞到服務,將要考慮用於內部服務通信的分頁策略。