Fog: multicasting across subnets

  • So I’ve looked into this a bit and I’ve figured there are two ways to do this. One is to just have the switches configured to do such a thing, which were working on to no avail yet. We are able to ping other computers from different Vlans on our internal network so this should be possible. The second option would be to have a storage node in each Vlan. Which would be better and more functional to use, and how would one set this up? it would be ideal to be able to just use the one server, but either option is viable. Im running Ubuntu 14.04 with Fog Trunk.

  • @K.Hays said in Fog: multicasting across subnets:

    That’s awesome actually i didn’t know that. How many computers can fog do max in this way, do you think?

    As many as you wish. I limit mine to 2 to keep things moving along quickly - that way no computer takes hours, but each one takes about 5 minutes and they take turns. This is also easier on the server’s HDD as well.

    For image deployment to many hosts at once using unicast, the server’s HDD speed is critical, along with it’s network speed. The switch’s internal throughput is also important.

  • @Sebastian-Roth ill post this the next time I’m at a separate building so that i can run the test. Might be a little while.
    @Wayne-Workman That’s awesome actually i didn’t know that. How many computers can fog do max in this way, do you think?

  • @K.Hays FOG has a queuing functionality. I set my fog server to run 2 tasks at max.

    So when I image 30 computers and start them all up, 2 start, 28 wait in line. when the 2 finish, another 2 go.

    This is automatic.

  • Developer

    @K-Hays Have you had a look at the process list on your FOG server after starting a multicast task? Please show us the output of ps ax | grep udp on your FOG server while a multicast task is waiting!

  • @Wayne-Workman The problem is the amount of bandwidth that would take up. Unless unicast doesn’t take any more bandwidth than multicast would then that’s not an option. We would be multicasting up to 30+ computers at a time sometimes and I’m afraid unicasting would take down the network in those situations. and Sebastion i ran through that troubleshoot page already, but thank you.

  • Developer

    @K-Hays Have you done any multicast tests by hand yet?

    You might want to stick to unicast if you cannot make it work but if you want to deploy the same image to a lot of computers then multicast is one of the nicest ways of doing it I suppose.

  • @K.Hays My advice, don’t multicast. fog unicasting is stupid fast. And - most multicast issues are network problems that unicast does not suffer from.

    FYI - I used to use fog with multicast. Then I got over that, because unicast is just so fast. I image an entire lab with unicast in under 30 minutes. 40GB image.

  • For now we just decided to put a fog server in each building because summer is approaching quickly and we need a better alternative to ghost. Advice is still welcome if there is any to give at this point. Thanks for the help so far.

  • @Tom-Elliott Im using 14.04 on the nodes also. The interface names on both are eth2. One of the nodes defaulted to eth0 in the database and the other we manually changed to eth2. I believe we got the same results regardless.

  • Senior Developer

    @K.Hays what is the OS you are using on these nodes? What are the actual interface names and are they reflected properly in the db.

  • @Wayne-Workman It depends on the image. For the ones linked to the storage node, i.e the middle school group we have, it says Middle School. But the checkbox isn’t checked, should it be? Thats all thats in there though

  • @K.Hays if you go to Image Management and click on one of your images, and then click on “Storage Group” on the left, what do you see?

  • Well here is the updated situation. As you know not too long ago we set up a fog server that could unicast and do all that across subnets no problem. Theoretically it should have been able to multicast (since we had a fog server up and running before which was able to do so, but it is currently and permanently inaccessible) but it would pause at the partclone screen. Then we decided to try storage nodes, as making modifications to the switches may be complicated at the moment. So we set up two different storage nodes in two different buildings, both with trunk and both set up AS storage nodes. They were loaded correctly and were also able to unicast too and from them, the images were physically stored on them also. When we tried to multicast though, it stopped again at the partclone screen. I’m assuming this is most likely a network issue, which we will be more able to solve this summer, as during the school year it gets complicated. But i just wanted to check to see if there is another solution, or possibly something that I am not doing correctly. Sorry for the influx of questions but it would be great if this was ready by the time we started summer maintenance.

  • @K.Hays Notifying a few folks that might be able to help.


  • @Wayne-Workman I found another log for multicast manager and it says “unable to locate udp sender”

  • This post is deleted!

  • @Wayne-Workman It says the image file was not found. Which is weird because we were able to unicast using that file.
    specifically it said the task was found but it failed to execute because the image was not found.

  • @K.Hays said in Fog: multicasting across subnets:

    @Wayne-Workman When i try to enable FOGMulticastManager it tells me it fails.

    Inside of /opt/fog/log there are logs for the multicast manager. They are also accessible via the log viewer. Try to start the service, and then look at the logs - share what you find.

  • @Wayne-Workman When i try to enable FOGMulticastManager it tells me it fails.
    Edit: Never mind, i stopped it then restarted it and now it says it’s running.