[問題] 部屬大量檔案至多台電腦

看板Linux作者 (陳阿燒)時間13年前 (2012/08/26 10:43), 編輯推噓4(4推 0噓 48→)
留言52則, 6人參與, 最新討論串1/1
請問有什麼方法能夠穩定的複製同樣的檔案 且容量較大的情(況約60GB左右) 至上百台電腦? 有沒有較省頻寬較快速且不易出錯的方式 謝謝 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.168.233.124
→
08/26 10:45, , 1F
udp-sender ?
08/26 10:45, 1F
→
08/26 10:55, , 2F
local BT upload download?
08/26 10:55, 2F
→
08/26 11:09, , 3F
udp sender我不知道是不是用過的同一款 沒有retry
08/26 11:09, 3F
→
08/26 11:10, , 4F
而且容易斷...一斷一台就少一台
08/26 11:10, 4F
→
08/26 11:10, , 5F
BT我現在的在用 但因為檔案變更機會大 要重新做種
08/26 11:10, 5F
→
08/26 11:10, , 6F
但種都在遠端....做起來很花時間 所以才想有沒有
08/26 11:10, 6F
→
08/26 11:11, , 7F
其他方式 還是說 上述兩種方法是我使用方式錯誤
08/26 11:11, 7F
→
08/26 11:12, , 8F
BT特色是WAN上多送端至一接收端,在LAN上沒有優勢,算總傳輸
08/26 11:12, 8F
→
08/26 11:12, , 9F
量就知道了
08/26 11:12, 9F
→
08/26 11:21, , 10F
08/26 11:21, 10F
→
08/26 11:22, , 11F
沒實際用過,但它man page裏有request retransmission字眼
08/26 11:22, 11F
→
08/26 11:22, , 12F
理論上設對參數就能正確傳完
08/26 11:22, 12F
→
08/26 11:23, , 13F
因為環境特殊 Source骨幹外 然後一台Server掛Source NFS
08/26 11:23, 13F
→
08/26 11:23, , 14F
所以頻寬不是很夠 相對不可能讓Client抓取大量資料
08/26 11:23, 14F
→
08/26 11:23, , 15F
BT雖然是互相share進度 但目前就卡在做種的效率
08/26 11:23, 15F
→
08/26 11:24, , 16F
BT不會賺到,我剛說過,你計算總傳輸量就知道
08/26 11:24, 16F
→
08/26 11:25, , 17F
真正會賺到的只有 udp 廣/多播 然後搭配selective repeat
08/26 11:25, 17F
→
08/26 11:25, , 18F
就是該man page中所謂的(request retransmission lost pac
08/26 11:25, 18F
→
08/26 11:25, , 19F
ket)
08/26 11:25, 19F
→
08/26 11:34, , 20F
請問如果透過udp-sender 如何傳送資料夾
08/26 11:34, 20F
→
08/26 11:35, , 21F
之前是將他壓縮成tar 但這問題也就跟BT一樣了
08/26 11:35, 21F
→
08/26 11:38, , 22F
udp-sender 看 man page 可以從 stdin 讀,所以應該是tar
08/26 11:38, 22F
→
08/26 11:39, , 23F
到pipe給udp-sender,這個load若不壓縮應該還好,每次全傳檔
08/26 11:39, 23F
→
08/26 11:39, , 24F
案本來就要全部被讀取一次
08/26 11:39, 24F
推
08/26 12:26, , 25F
網路架構是什麼,作業系統又是什麼
08/26 12:26, 25F
→
08/26 12:26, , 26F
不會是VOD吧.....
08/26 12:26, 26F
→
08/26 12:43, , 27F
架構大致上 Source---WAN(NFS)---Server----LAN(100+)
08/26 12:43, 27F
→
08/26 12:43, , 28F
系統為 Linux
08/26 12:43, 28F
→
08/26 12:44, , 29F
不是影音相關資料 大都是VM
08/26 12:44, 29F
→
08/26 13:22, , 30F
不知道DFS是不是個選擇？
08/26 13:22, 30F
推
08/26 15:38, , 31F
這有方案啊......可以看看別人怎做
08/26 15:38, 31F
推
08/26 15:42, , 32F
看看NOVELL PlateSpin Forge 合不合用
08/26 15:42, 32F
→
08/26 16:04, , 33F
謝謝 不過條件要Opensource跟free(最重要)
08/26 16:04, 33F
推
08/27 05:29, , 34F
clonezilla?不知道是否可達成
08/27 05:29, 34F
→
08/27 05:30, , 35F
打錯 應該是另外一套叫作企鵝龍的 英文好像叫DRBL?
08/27 05:30, 35F
→
08/27 15:25, , 36F
原po最後有處理方案了嗎?若有能否分享一下?
08/27 15:25, 36F
→
08/27 21:46, , 37F
udpcast 有辦到做到斷線回復的部分嗎
08/27 21:46, 37F
→
08/27 21:47, , 38F
目前測試用udpcast retransmit的情況居高不下 且還是會有
08/27 21:47, 38F
→
08/27 21:47, , 39F
client斷線情況發生
08/27 21:47, 39F
→
08/27 21:49, , 40F
此外企鵝龍clonezilla應該是限於partition
08/27 21:49, 40F
→
08/27 21:59, , 41F
--retries-until-drop retries 參數看看有沒有幫助?
08/27 21:59, 41F
→
08/28 02:18, , 42F
應該說sender再傳送約10%左右r-xmit已經達到300%以上
08/28 02:18, 42F
→
08/28 02:19, , 43F
我正在想如果最佳化網路環境 當使用udpcast時網路中
08/28 02:19, 43F
→
08/28 02:19, , 44F
盡量避免有其他封包流動的情況看看能否改善
08/28 02:19, 44F
→
08/28 05:59, , 45F
其它參數思考方向:降低bitrate(因為你台數太多,HD速度跟不
08/28 05:59, 45F
→
08/28 06:00, , 46F
上發送速度的收方可能不少. 還有就是採用 forward error
08/28 06:00, 46F
→
08/28 06:01, , 47F
correction,減少需要重傳的機會. 都不行就考慮減少一次動
08/28 06:01, 47F
→
08/28 06:02, , 48F
作的收方數量,分成幾批發送。根據文件舉例15台,或許是可以
08/28 06:02, 48F
→
08/28 06:02, , 49F
以一次15台接收方為上限.
08/28 06:02, 49F
→
08/28 06:03, , 50F
以上調整都會降低throughput,總體來看是否划算要實測才知
08/28 06:03, 50F
→
08/28 06:04, , 51F
不過能讓一批n台參與的收方順利都收完又比逐台傳n次省就算
08/28 06:04, 51F
→
08/28 06:05, , 52F
有賺到.
08/28 06:05, 52F
‣ 更多 jjooeeyy 的文章
文章代碼(AID): #1GEOrCV2 (Linux)