FogReplicator and Storage Nodes.

[george1421]

@sbenson WAIT, I just saw a flaw in your design!!!
For MHB-Storage_node that has the same IP address as your SRO-Master. Is this by design?? If so, its wrong. You will create a replication loop and confuse the target computers.

This right here will might cause the clients at MHB to talk to the SRO server. Because it tells the clients at MHB there is a second server in MHB, which is actually at SRO.

mysql> select ngmMemberName as name,ngmIsMasterNode as master, ngmHostname as host,ngmUser as user, left(ngmPass,5) as pass from nfsGroupMembers;
+------------------+--------+-------------+------+-------+
| name             | master | host        | user | pass  |
+------------------+--------+-------------+------+-------+
| MHB-Storage_Node |        | 10.63.76.44 | fog  | RoiYx |

[george1421]

@sbenson said in FogReplicator and Storage Nodes.:

@george1421 But the userid and password are required…or atleast they have an asterisk next to them making it seem like they are. I did notice a problem, the interfaces on these boxes aren’t eth0, they are ens160 on both. I can’t imagine that would cause the traffic to magically be routed to the SRO machine.

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

[sbenson]

@george1421
SRO

mysql> select ngmMemberName as name,ngmIsMasterNode as master, ngmHostname as host,ngmUser as user, left(ngmPass,5) as pass, ngmInterface as interface from nfsGroupMembers;
+------------+--------+-------------+------+-------+-----------+
| name       | master | host        | user | pass  | interface |
+------------+--------+-------------+------+-------+-----------+
| MHB-Slave  |        | 10.63.57.42 | fog  | BaLVo | ens160    |
| SRO-Master | 1      | 10.63.76.44 | fog  | RoiYx | ens160    |
+------------+--------+-------------+------+-------+-----------+
2 rows in set (0.00 sec)

MHB

mysql> select ngmMemberName as name,ngmIsMasterNode as master, ngmHostname as host,ngmUser as user, left(ngmPass,5) as pass, ngmInterface as interface from nfsGroupMembers;
+------------------+--------+-------------+------+-------+-----------+
| name             | master | host        | user | pass  | interface |
+------------------+--------+-------------+------+-------+-----------+
| MHB-Master       | 1      | 10.63.57.42 | fog  | BaLVo | ens160    |
| MHB-Storage_Node |        | 10.63.57.42 | fog  | BaLVo | ens160    |
+------------------+--------+-------------+------+-------+-----------+
2 rows in set (0.00 sec)

[Tom Elliott]

@sbenson Unless you need it, the MHB Server does not need a second node. There is literally no point for it.

[george1421]

@sbenson OK we need to get something cleared up. Tom and I have been chatting and we need to understand. At site MHB how many physical fog servers are installed master or slave nodes. I think we’ve been adding complexity because I misunderstood something.

[sbenson]

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

Unless you need it, the MHB Server does not need a second node. There is literally no point for it.

It’s only there because George said so

@george1421 said in FogReplicator and Storage Nodes.:

OK we need to get something cleared up. Tom and I have been chatting and we need to understand. At site MHB how many fog servers are installed master or slave nodes. I think we’ve been adding complexity because I misunderstood something

There are a TOTAL of 2 servers in the whole company, SRO-FOG-01 and MHB-FOG-01. Both of these machines are installed on our vmware infrastructures(no not the same ESXI hosts).

[george1421]

@sbenson said in FogReplicator and Storage Nodes.:

There are a TOTAL of 2 servers in the whole company, SRO-FOG-01 and MHB-FOG-01

Well for that I’m sorry. Somewhere along the way I thought you said you had two physical fog servers at MHB, because you had two subnets there. I didn’t question it.

Delete the slave node on the MHB fog server and then things will straighten out.

[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.