Posts made by MCSDFog

Hey george1421,

Thanks for the response.

To clear things up a bit. We do have multicast working across vlans, the issue is more the reliability. On one vlan only certain models (Dell e5430s, Dell 3380s) will multicast with others (Dell 3340s, Dell 3350s, Dell 3390 2in1) get to the gparted screen and just sit like they are waiting additional computers to join. Then on both of the vlans if you need to cancel the multicast tasks and try to kick if off again, it seems to be hit or miss if the host get past the gparted screen and start imaging. Seems I need to wait a certain amount of time before trying to kick off the job again. I haven’t nailed down that minimum wait time…seems to be 15 min or less. If I do it too soon it just sits at the gparted screen.

So that is why I decided to look at the Storage Node approach. I then came across the wiki article about Storage management.

https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Storage_Manangement

In the Storage Management section it talks about Storage Groups and multicasting via the Storage Group’s Group Master Node. I was unclear if I could make sure hosts on a vlan hit the Group Master Node on that vlan. Maybe I was adding wishful thinking.

Thanks

Randy

Hello,

I found in my environment, it is helpful for multicasting if I have a FOG server on each of our vlans (two we use for imaging). However, this approach introduces the problem of separate databases; separate host registration, images etc.

It is my understanding a possible solution/better approach would be to have one FOG Server (normal install) and multiple FOG Storage Nodes. My goal for this approach would be to have one FOG server (normal install) and a FOG Storage Node for two of our vlans (vlan 1 and vlan 2).

However, I am a bit unclear about multicasting and Storage Nodes. How can I make sure that computers on vlan 1 connect to the FOG Storage Node on vlan 1 and computers on vlan 2 connect to the FOG Storage Node on vlan 2 when multicasting?

Thanks

Randy

@tom-elliott At this point I stayed on 1.5.3 and I ran tests with three different kernels. 4.16.6 and 4.17.0 behaved similarly. They both took over 4 min to finish Erasing MBR/GPT. With kernel 4.15.2 the Erasing MBR/GPT took about 1 sec.

@tom-elliott We are seeing the same thing. Went from 1.5.2 to 1.5.3. Switching to the 4.15.2 kernel fixed this problem for us.

Thanks