add support for root filesystem image transfer via uftp, and md5sum c…

[rich350]

This is for using uftp (http://uftp-multicast.sourceforge.net) as a method for transferring the root filesystem image to booting nodes. It is designed to handle the use case of deploying a single image to a large number of nodes, where large means the number of nodes could otherwise overwhelm the management server or service nodes if using wget, and where all nodes will be receiving the same image. It does not support simultaneous booting of nodes that should receive different images.

[xcatbot]

CI CHECK RESULT : > PR FORMAT CORRECT> BUILD SUCCESSFUL > INSTALL XCAT SUCCESSFUL> CODE SYNTAX CORRECT> FAST REGRESSION TEST Successful: Totalcase 215 Pass 215 failed 0

[whowutwut]

@immarvin With regards to the .rpm files that are included in this pull request, it seems like this should be something that is included in the xcat-dep package and not in the xcat-core? correct?

@rich350 Thanks for creating this, I'm out until Monday but will take some closer look in the next few days.

[rich350]

Regarding the uftp rpms, I was not sure how this should be handled, so I added them just in case. The uftpd binary needs to make its way into the initrd, so I packaged it and added it to the image so that packimage would pick it up. Moving this to xcat-dep sounds like the right thing to do.

With respect to booting multiple images simultaneously using this method, in theory it should be possible to associate an image with a particular UDP port, pass this via a kernel parameter as well, and have uftpd listen on that port. Then uftp-listener would need to listen continuously (I have a version that does this), determine the destination port based on the image requested, and start the transfer to the nodes listening on that port. I will try to work that out next.

Thanks for considering this!

[immarvin]

hi @whowutwut , I think the uftp server and client should better be in xcat-dep.

hi @rich350 , thanks for your contribution. we will handle the ship things of uftp server and client in xCAT. One question, do you have any data of the performance comparison between uftp and http/wget on transferring a 2G-3G file ?

[rich350]

Actually, I just noticed that the uftp command in this version of uftp-listener is tuned for jumbo frames, and I meant to tune for non-jumbo, so I will need to fix that. In any event, I just ran a comparison between crest-mgmt1 and crest1, which is our power8 test system. This is over 1Gb/s:

size of file:
-rw-r--r-- 1 root root 3541421174 Jul 28 10:14 /rootimg.cpio.gz

with uftp (this is tuned for non-jumbo frames):
uftp -I enP3p5s0f0 -R 850000 -D /rootimg.cpio.gz /install/netboot/crest-compute/rhels7.3/20170726/rootimg.cpio.gz
Transfer status:
Host: 0xAC1ECC04 Status: Completed time: 32.711 seconds
Total elapsed time: 32.711 seconds
Overall throughput: 105726.83 KB/s

with wget:
wget http://172.30.204.2:80//install/netboot/crest-compute/rhels7.3/20170726/rootimg.cpio.gz
100%[=======================================================================================================>] 3,541,421,174 81.6MB/s in 31s

2017-07-28 10:21:41 (108 MB/s) - ‘rootimg.cpio.gz’ saved [3541421174/3541421174]

So wget was at 108MB/s, and uftp was at 105MB/s.

Here is uftp with a slightly higher transfer rate:
uftp -I enP3p5s0f0 -R 900000 -D /rootimg.cpio.gz /install/netboot/crest-compute/rhels7.3/20170726/rootimg.cpio.gz
Host: 0xAC1ECC04 Status: Completed time: 32.162 seconds
Total elapsed time: 32.162 seconds
Overall throughput: 107531.85 KB/s

So now at 107MB/s.

There are many knobs to turn on this tool, but transfer rate and block size seem to have the most effect. It is UDP, and recipients will NAK if a block is missed, which tells the sender to re-send. But if it is tuned too "close to the edge" the NAKs will potentially creep in and hurt overall throughput. I think 900000 transfer rate and non-jumbo packet size would be a good compromise. There is also a buffer size parameter which I have not tested.

In any event, it is comparable to wget, and should scale much better.

[rich350]

Superceded by pull request #3560