Fog: multicasting across subnets
-
@K.Hays and you watched the image replicate? And it’s physically present on the new node?
You might also look this over: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_Downloading_-_Multicast
-
@Wayne-Workman yeah i watched it but i didnt check the storage node itseld to see if it actually saved there. I cant see why it wouldnt have though unless its a problem some people have. I think it was set up correctly. We were able to image to and from it.
-
@K.Hays is the
FOGMulticastManagerrunning? Any logs about it in the log viewer? -
@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. -
@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/logthere 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 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. -
This post is deleted! -
@Wayne-Workman I found another log for multicast manager and it says “unable to locate udp sender”
-
@K.Hays Notifying a few folks that might be able to help.
-
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 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?
-
@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 what is the OS you are using on these nodes? What are the actual interface names and are they reflected properly in the db.
-
@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.
-
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.
-
@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.
-
@K-Hays Have you done any multicast tests by hand yet? https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_Downloading_-_Multicast
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.
-
@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.
-
@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 udpon your FOG server while a multicast task is waiting! -
@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.
