Multicast from second storage group
-
@Mentaloid what you’re looking for IS capable. The reason it failed is likely because node 13 didn’t replicate to the second server.
-
The image is only stored on the second server - hence the separate storage group. The reason for this is the middle is a VPN - FOG13 sits on one side, and acts as a storage server for systems on that side. The other storage server is on the other side of the VPN. Replication between the 2 should not happen as they are 2 different storage groups, and is undesired as the VPN is well… too slow
The trick is, I’d like to be able to multicast from either storage group, so I can essentially pick which server to use.
It won’t kill me, and I’ll probably bodge a script or plugin eventually. Unicast works fairly well in the mean time.
-
@Mentaloid Don’t know if you’ve noticed or not, but you can limit replication bandwidth inside Storage Management.
-
@Wayne-Workman
Yep - I had noticed. 170 gigs worth of images @ full speed of the VPN connection doesn’t outpace sneakernet in this case though!wow… I haven’t referenced sneakernet in way to long a time
-
@Mentaloid I guess I’m not understanding.
Multicast will only work on “Master Nodes”. If FOG13 doesn’t have the image, but FOGStorage02 does, and they’re both the “same” group, I’d recommend making a different group and have each server the master of their respective group. FOGStorage02 would then be able to multicast images within it’s own network and FOG13 would be able to do the same.
Of course, the image MUST exist on the nodes you want to multicast from.
-
If you can deal with my long winded answer I think we have a setup that my company uses that will help.
We have a location that is connected to HQ via a site to site vpn. The remote site only has a 5Mb/s internet connection. Because of access rights issues I don’t want techs at site A to mistakenly deploy images to systems at site B. With a standard fog master/slave setup I can’t restrict FOG in the way I need it. So what we setup is what I’m calling a master/master setup with FOG. So at each site there is a master node with its own storage group. At HQ there is a second master node in a development storage group. The images are tested and validated on the development environment FOG server. (for this discussion there are 3 FOG servers involved. 2 at HQ and 1 at site B). On the development FOG server I created a storage group and defined the deployment fog server at HQ and the fog server at site B slaves. Understand all fog servers in this setup are master nodes, I just defined the two deployment servers as slaves to the development FOG server.
So with this setup the images will be replicated from the development FOG server to both deployment FOG servers. This works great to get the images from the development FOG server to the deployment FOG servers, nothing tricky (other than defining the deployment FOG servers as slave nodes to the development FOG server) is needed to get the images.
The last bit is to export the image definitions from the development FOG server and import them (manually) into both deployment FOG servers. In my case we update the images once a quarter, but never change their name. If we changed the name we would have to go through the manual process of exporting the image configurations and then importing them into both deployment servers. Not a big task if we needed to. Having an automated way to do this would be great. Maybe once fog 1.3.0 is released it will be worth the effort since right now in the trunk the code changes frequently.
-
@george1421
Thanks George - I had contemplated that, but I’d have to then have different pxe boot structures.I have already written a bit of a bodge script that checks multicast tasks on my main FOG server, and starts the UDPCAST process on the storage server if the image is found locally (storage group and image = local). This seems to have worked for my purposes.
Thanks everyone for their input!
-
@Mentaloid said in Multicast from second storage group:
@george1421
Thanks George - I had contemplated that, but I’d have to then have different pxe boot structures.While I appears you have a path, your above statement is interesting (??) I’m not sure I’m following this. Each site has their own dhcp server right? Or they share a single dhcp server, but they have their own scopes. Unless I’m missing something there is no booting differences between a master/slave setup for booting than a master/master setup.
-
Same dhcp server, same scope. The VPN is hardware tunnel, so any computers @ both sites act as if they are in the same physical network/scope.
-
@Mentaloid said in Multicast from second storage group:
I have already written a bit of a bodge script that checks multicast tasks on my main FOG server, and starts the UDPCAST process on the storage server if the image is found locally (storage group and image = local)
Now you have to share the script.
