FogReplicator and Storage Nodes.

[Tom Elliott]

@sbenson So:

SRO side Needs:

Master (SRO-FOG-01)
Slave (MHB-FOG-01)

MHB Side Needs:
Master (MHB-FOG-01)

[Tom Elliott]

@george1421

@george1421 said in FogReplicator and Storage Nodes.:

The network interfaces need to be correct for multicasting. Unicast images don’t use the network interface.

Just trying to clarify:

FOG uses the interface for the bandwidth page. For multicast it uses an auto detection type system now.

[sbenson]

@Tom-Elliott said in FogReplicator and Storage Nodes.:

So:
SRO side Needs:
Master (SRO-FOG-01)
Slave (MHB-FOG-01)
MHB Side Needs:
Master (MHB-FOG-01)

Done, SRO has

| MHB-Slave  |        | 10.63.57.42 | fog  | BaLVo | ens160    |
| SRO-Master | 1      | 10.63.76.44 | fog  | RoiYx | ens160    |

MHB has

| MHB-Master | 1      | 10.63.57.42 | fog  | BaLVo | ens160    |

[Tom Elliott]

@sbenson This should then be good to go.

I’d say, from the SRO Master server, run systemctl restart FOGImageReplicator FOGSnapinReplicator just to make sure things are good to go and things will start replicating (unless you need to wait until later on.)

[george1421]

@Tom-Elliott That probably should be done on the MHB server too just to flush out any cached systems since we deleted a node.

[Tom Elliott]

@george1421 True true true.

[sbenson]

@Tom-Elliott said in FogReplicator and Storage Nodes.:

True true true.

restarted on both
SRO

[17:05:16] root@SRO-FOG-01[0]:/var/log/fog$ systemctl restart FOGImageReplicator FOGSnapinReplicator; tail -n10 -f fogreplicator.log
[05-13-17 12:03:41 am]  * Found Image to transfer to 1 node
[05-13-17 12:03:41 am]  | Image Name: W7P-T460s
[05-13-17 12:03:42 am]  | W7P-T460s: No need to sync d1.fixed_size_partitions file to MHB-Slave
[05-13-17 12:03:42 am]  | W7P-T460s: No need to sync d1.mbr file to MHB-Slave
[05-13-17 12:03:43 am]  | W7P-T460s: No need to sync d1.minimum.partitions file to MHB-Slave
[05-13-17 12:03:43 am]  | W7P-T460s: No need to sync d1.original.fstypes file to MHB-Slave
[05-13-17 12:03:43 am]  | W7P-T460s: No need to sync d1.original.swapuuids file to MHB-Slave
[05-13-17 12:03:43 am]  | W7P-T460s: No need to sync d1.partitions file to MHB-Slave
[05-13-17 12:03:44 am]  | W7P-T460s: No need to sync d1p1.img file to MHB-Slave
[05-13-17 12:03:44 am]  | W7P-T460s: No need to sync d1p2.img file to MHB-Slave

MHB

[17:05:40] root@MHB-FOG-01[0]:/var/log/fog$ systemctl restart FOGImageReplicator FOGSnapinReplicator;tail -n10 -f fogreplicator.log
[05-03-17 4:01:10 am]  *  | This is not the master node
[05-04-17 4:11:10 am]  *  | This is not the master node
[05-05-17 4:21:10 am]  *  | This is not the master node
[05-06-17 4:31:11 am]  *  | This is not the master node
[05-07-17 4:41:11 am]  *  | This is not the master node
[05-08-17 4:51:11 am]  *  | This is not the master node
[05-09-17 5:01:11 am]  *  | This is not the master node
[05-10-17 5:11:11 am]  *  | This is not the master node
[05-11-17 5:21:11 am]  *  | This is not the master node
[05-12-17 5:31:11 am]  *  | This is not the master node

[george1421]

@sbenson The mhb looks a bit suspect, but is OK. For SRO I would expect this if MHB had already been synchronized on a previous run.

I do have to question the time differences. Are you running UTC on these systems, especially SRO?

[Tom Elliott]

@sbenson That is perfectly fine. The MHB Side, could probably do with a (ctrl+c) then rerun the tail command.

Notice how the restart didn’t have the “banner”?

[sbenson]

ok…good news…it’s replicating an image…that I dont want it to(it was set to replicate). So i know replication is working now. Now to test if I deploy a machine from MHB to see if it hits SRO at all… I will keep you updated. Need to reach out to someone in MHB

[sbenson]

@Tom-Elliott I didn’t realize the restarting of the service deleted the file and recreated it. I thought it would just append to it

[Tom Elliott]

@sbenson It’s kind of intentional to ensure a “clean state”.

[Wayne Workman]

@sbenson said in FogReplicator and Storage Nodes.:

@Tom-Elliott I didn’t realize the restarting of the service deleted the file and recreated it. I thought it would just append to it

Yeah, historical replicator logs aren’t important. What’s important are the current logs it’s writing.

[sbenson]

Thank you everyone, this has been resolved. I will say the replication/node setup was the most confusing thing about fog. Everything else is straight forward. Maybe it was just me but a “Storage Nodes for Noobs” might be a good sticky post that explains how to setup a simple 2 server storage node. Other than that everything has been awesome. Thanks for all your hard work.

[Wayne Workman]

@sbenson said in FogReplicator and Storage Nodes.:

Maybe it was just me but a “Storage Nodes for Noobs” might be a good sticky post that explains how to setup a simple 2 server storage node.

I agree. We already have documentation on replication and the location plugin but we need an instructional video on setting up a simple two-node system. I can get a video made pretty easily on this topic, and I’ve been looking for simple topics to make videos about.

[george1421]

@Wayne-Workman Just be aware the OP has setup a FOG Master -> FOG Slave setup not the traditional and fully supported FOG Master -> [FOG] Storage node configuration.

My hope is as the API matures that we can have the FOG Master -> FOG Slave setup a supported configuration.

[Wayne Workman]

@george1421 I didn’t know this was a multi-master setup, if that’s what you meant. I was referring to a video on just configuring a second node into an existing fog setup. With the new access control plugin and site plugin, multi-master setups are just that less a good idea.

As it stands now with the access control plugin, location plugin, and site plugin - the only benifit one stands to gain in a multi-master setup is some level of fault tolerance against the upstream box failing - and fault tolerance against the link failing - and for those two things you loose a comprehensive database/control center in a central location - a major drawback.