Clonezilla SE的 unicast, multicast, broadcast clone

日期：

可以確定用 Clonezilla live 作為 Clonezilla SE 用戶端的作業系統，然後儲存映像檔在本機硬碟的另一個分割區，敗在我的硬碟是較舊款的，所以反而拖慢整個速度 ... 然後測試了 Clonezilla SE 確實是可以同時儲存 (預設，沒選要unicast, multicast, broadcast) 不同的映像檔，速度也不會太差 ...

備份的時候
drbl-ocs -b -q2 -j2 -sc -p reboot -z1p -i 1000000 -h " 192.168.0.6" -l zh_TW.UTF-8 startparts save MiT06-W7x86-02_Clear sda1
drbl-ocs -b -q2 -j2 -sc -p reboot -z1p -i 1000000 -h " 192.168.0.4" -l zh_TW.UTF-8 startparts save MiT04-W7x86S-01_Clear sda1

不同規格可以同時備份，速度跑的跟分開備份不相上下啊 !
Stats: Saved /home/partimag, /dev/sda1, success, 13.0 GB = 3176638 Blocks, 14.750 mins;
Stats: Saved /home/partimag, /dev/sda1, success, 20.2 GB = 4936352 Blocks, 14.445 mins;


接著便嘗試一下用 multicast 來同時還原不同映像檔 ...嗯 ... 第二個卡住了 ! xD
drbl-ocs -b -e1 auto -e2 -r -x -j2 -k -p reboot --clients-to-wait 1 -h " 192.168.0.4" -l zh_TW.UTF-8 startparts multicast_restore MiT04-W7x86S-01_Clear sda1
drbl-ocs -b -e1 auto -e2 -r -x -j2 -k -p reboot --clients-to-wait 1 -h " 192.168.0.6" -l zh_TW.UTF-8 startparts multicast_restore MiT06-W7x86-02_Clear sda1

考量到接著應該不會發生同一個時間點開始還原 ... 而應該是陸續有機器要還原 ... 所以很多台(同映像檔)在分析時，整個流程應該是差不多，用群播(等待共幾台時一起還原)來解決 ... 如果不同映像檔就是用點播 !!! 
但這個情況下我只測了兩台 (用top看好像也沒很吃資源) ! 

根據 DRBL 網頁上所解釋，或許機器數量越多時會造成一定速度的降低 ... 

接著還是只能再試一下 unicast 了
drbl-ocs -b -e1 auto -e2 -r -x -j2 -k -p reboot -h " 192.168.0.4" -l zh_TW.UTF-8 startparts restore MiT04-W7x86S-01_Clear sda1
drbl-ocs -b -e1 auto -e2 -r -x -j2 -k -p reboot -h " 192.168.0.6" -l zh_TW.UTF-8 startparts restore MiT06-W7x86-02_Clear sda1

不同規格同時還原，測了幾次速度跑起來還不差啊
drbl-ocs -b -e1 auto -e2 -r -x -j2 -k -p reboot -h " 192.168.0.4" -l zh_TW.UTF-8 startparts restore MiT04-W7x86S-01_Clear sda1
drbl-ocs -b -e1 auto -e2 -r -x -j2 -k -p reboot -h " 192.168.0.6" -l zh_TW.UTF-8 startparts restore MiT06-W7x86-02_Clear sda1

Stats: Unicast restored MiT06-W7x86-02_Clear, /dev/sda1, success, 13.0 GB = 3176638 Blocks, 7.382 mins;
Stats: Unicast restored MiT04-W7x86S-01_Clear, /dev/sda1, success, 20.2 GB = 4936352 Blocks, 10.928 mins;
Stats: Unicast restored MiT04-W7x86S-01_Clear, /dev/sda1, success, 21.1 GB = 5140330 Blocks, 7.435 mins
Stats: Unicast restored MiT04-W7x86S-01_C, /dev/sda1, success, 20.2 GB = 4936348 Blocks, 9.159 mins;
Stats: Unicast restored MiT06-W7x86-02_C, /dev/sda1, success, 10.4 GB = 2531895 Blocks, 5.136 mins;
Stats: Unicast restored MiT04-W7x86S-01_Clear, /dev/sda1, success, 20.2 GB = 4936352 Blocks, 11.405 mins;
Stats: Unicast restored MiT06-W7x86-02_Clear, /dev/sda1, success, 13.0 GB = 3176638 Blocks, 7.566 mins;

比較一下之前用 multicast 單獨跑的速度，真的不會太差 !

Stats: Multicast restored MiT04-W7x86S-01_Clear, /dev/sda1, success, 21.1 GB = 5140330 Blocks, 14.488 mins;
Stats: Multicast restored MiT04-W7x86S-01_Clear, /dev/sda1, success, 21.1 GB = 5140330 Blocks, 14.337 mins;

總之建議環境是使用同一個映像檔，這是在我測試整個流程時的問題但回頭想想 ... 如果是同一批映像檔但卻會不同時間開始還原 ... ? 嗯 ? 看樣子應該還是只能考慮 unicast 了 !


Clonezilla SE中，這3個模式使用的作法分別是:
  • unicast: 透過NFS讀取印象檔所有資料
  • multicast: 透過NFS判讀印象檔，透過udpcast來接收分割區的印象檔。
  • broadcast: 透過NFS判讀印象檔，透過udpcast來接收分割區的印象檔，而udpcast中特別使用參數"--broadcast"。

unicast和multicast/broadcast模式最大的差別是在於unicast模式中伺服器因為是透過NFS來提供檔案給每台用戶端電腦讀取，因此CPU與網路負載都會隨著用戶端機器的數目而增加。

而multicast/broadcast模式用戶端只有在判讀印象檔的時候透過NFS到伺服器讀取印象檔。之後分割區的還原是透過udpcast來處理，因此，伺服器的CPU負載不太會隨用戶端機器數目增加而等量增加，

而multicast/broadcast的封包是透過網路交換器來複製。因此只要網路交換器支援multicast的話，基本上Clonezila restore的時候運作就可以充份利用multicast這個功能。

至於multicast和broadcast模式之間的差別在於multicast模式下，只有加入multicast模式的用戶端才會收到封包，沒有加入的用戶端，會在硬體層級就把封包擋掉。而且網路交換器只會把封包送到有加入multicast模式的用戶端。這樣效率上當然會比較理想。然而，有些網路環境並不允許multicast模式存在，因此就可以退而求其次，使用broadcast。

因此，整個實體環境分析的測試 ... 到這邊可以說是解決了 ! 
花的時間已經比之前的版本快上很多了 ! 多機的環境也可以算是搞定了 !

只能說 DRBL/Clonezilla 實在是太強大了 !