Multi-cast with Location plugin enabled
-
@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?
-
@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?
-
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.
-
@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.)
-
@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?
-
@wayne-workman I’ll give this a try today and see what I can find, thank you.
-
@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.
-
@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.
-
@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?
-
@zacadams what version of fog are you using?
-
@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.
-
@zacadams what’s the multicast log show?
-
@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.``` -
@zacadams so the session is starting. The clients can’t seem to get the traffic from the server. Are the client machines on a separate network from the fog server?
-
@tom-elliott in this particular scenario the host is trying to communicate with the “remote” fog storage node, which is now a master node in it’s own storage group, and is on the same network as the host.
-
I was able to resolve the issue:
One of the problems was that the multicast interface was set to the interface of the main fog sever (a vm running on ens192 interface) to the interface of what my storage nodes would be (physical machines on eno1 interfaces).
The other issue was the MySQL table on the main fog server being not accessible by remote storage nodes.
I could image from the remote storage nodes but the nodes themselves always had shown “A valid database connection could not be made” on the dashboard. The fix for this could be found here under the “Enable remote mysql access” section, granting remote users all privileges. -
@zacadams what user where you using to talk with the dB? You should’ve been using fogstorage which is setup for you during installation.
-
@tom-elliott That is the one I have been using, the passwords were correct on the fog storage node as well.
-
@zacadams Glad you got this figured out.
-
T tag referenced this topic on
