Multi-cast with Location plugin enabled

[george1421]

FWIW, only master nodes can use multicast imaging. Unicast imaging can be from a master node -OR- storage node based on the guidance given by the location plugin. It is working by design.

Are the master nodes and storage nodes located at the same site?

[zacadams]

No, the master and storage node are in different locations.

[zacadams]

@george1421 would I be able to set my remote storage node as a master node and then have multicast session run from it?

[george1421]

@zacadams I’m pretty sure you need a full fog server to have the multicast component.

FWIW, a full fog server can be a “storage node” in a storage group. Meaning you can have 2 full fog servers in the same storage group where once is configured as a master and one as a storage node (in the storage group). Your images will replicate from the master server to the remote fog server. The only issues and manual intervention would be to export the image definitions from the real master server and import them into the remote fog server. Understand this is an unsupported configuration but will work well as long as you don’t have a lot of new images on the master server because you will need to export and import for every new image.

[Tom Elliott]

Location plugin will attempt to make the location nodes masters where possible. Of course, you should have a storage node implicitly defined for the the location in question, otherwise it will try to set the master node of the storage group.

[george1421]

@tom-elliott said in Multi-cast with Location plugin enabled:

Location plugin will attempt to make the location nodes masters where possible.

In that you are able to multicast from a storage node as long as all clients are in the same location?

[zacadams]

@tom-elliott I have the remote fog storage node set as the selected node for my remote location and for testing purposes have just set that storage node as a master node as well as my default master node. So for my defaultStorage group I have 2 master nodes, I am trying to now do the multicast on my remote host tied to my remote node. The session appears to start with the remote node now but is not starting the imaging process.

[Tom Elliott]

@zacadams There can be only one! (Highlander reference anybody?)

For real, you can only have 1 master node per storage group. Unless you set both nodes as master in the database, directly - which will likely break things, you will only ever have a single storage node as the master node in a storage group.

As for multicast, it’s a fun game to play around with. Many switches disable forwarding of multicast traffic by default (as multicast will overburden a network). Is your network already setup to allow multicast streams?

[zacadams]

@tom-elliott I know it’s really weird man hahaha, it is currently showing that both are master nodes at the moment. So our setup is a campus with multiple buildings with many hosts in each building. Our current setup uses Ghost servers in each building (I guess the equivalent would be individual fog servers instead) installed on a physical machines in closets that then multicast to the respective hosts in the building. Our network admins will only let us use multicast when imaging to machines in the building so my plan was to use location as a way to represent these buildings and using their existing ghost boxes as fog storage nodes and multicasting from those nodes. I hope that makes sense, do you think my theory is possible with FOG in this setup?

[Wayne Workman]

I don’t know if it’s already been said or not but, you can just create a new storage group - put your remote storage node into that new storage group - then set the node as master. Then it should multicast. To keep replication of images & snapins working, you’ll have to do cross-group sharing at the image level, you’d do that in image management on each individual image & each individual snapin.

[Tom Elliott]

@zacadams It’s not “theory” that’s what it was designed to do. Though what I might recommend is as Wayne suggested, just to keep things less confusing. Create a storage group for each location, and create a storage node for each group. (Images can be assigned to multiple groups so replication can still happen Group Master->Group master)

I’d recommend using true fog servers for this though (or storage nodes) not “ghost” as fog is a long way off from Ghost (and far better I think.)

[george1421]

@zacadams said in Multi-cast with Location plugin enabled:

Our network admins will only let us use multicast when imaging to machines in the building

Just for clarity, how many machines do you typically image at one time?

[zacadams]

@wayne-workman I’ll give this a try today and see what I can find, thank you.

[zacadams]

@tom-elliott beautiful I’m glad to see I was on the right track there, we currently use Ghost and are trying to move to Fog so if this does work I will be happy to see Ghost gone.

[zacadams]

@george1421 the amount of machines vary based on what classrooms are not in use, so it’ll range from 2-300 machines based on how large the classroom’s break is.

[zacadams]

@wayne-workman said in Multi-cast with Location plugin enabled:

To keep replication of images & snapins working, you’ll have to do cross-group sharing at the image level, you’d do that in image management on each individual image & each individual snapin.

I am having trouble finding this setting in image management, would you be able to illuminate me to where I could find this?

[Tom Elliott]

@zacadams what version of fog are you using?

[zacadams]

@tom-elliott I am currently using 1.5.0, I tried using a configuration similar to @Wayne-Workman’s suggestion and the host just seems to stay at the multicast initialization screen but the session never starts.

[Tom Elliott]

@zacadams what’s the multicast log show?

[zacadams]

@tom-elliott the log currently is showing:

/var/log/fog/multicast.log
[03-26-18 12:17:58 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:08 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:18 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:28 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:38 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:48 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:18:58 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:08 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:18 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:28 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:38 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:48 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:19:58 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:08 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:18 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:28 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:39 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:49 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:20:59 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.
[03-26-18 12:21:09 pm] | Task (15) Multi-Cast Task is already running with pid: 18262.```