FogReplicator and Storage Nodes.
-
@sbenson OK what you are currently running is an unsupported mode of FOG. Yes it works well and how I have my fog servers setup.
In a traditional FOG setup you have one master node and one or more storage nodes. A fog storage node is exactly like a FOG master node, except a storage node doesn’t have a local database, it uses the Master Nodes database.
In your setup you have 2 fog master nodes (each with their own sql database) you have one of the servers configured as a master node and in the master node the other configured as a storage node. This IS required to get your images to flow to your remote fog server.
Now we need to understand why a client at your remote site is trying to pull an image from the HQ site. At your remote site, what values do you have for dhcp options 66 and 67. Those should point to the fog server at the remote site. In a split master setup (like you have) each site should only know about its local fog server.
-
@george1421
We confirmed that the MHB network ranges both hit the MHB server x.x.57.42. SRO is currently hosted on x.x.76.44, and the Scope in SRO reflects the same.Ideally we want SRO and MHB to be two separate servers, but sync the images between eachother. When I log into the MHB server it doesn’t show any of the images listed on SRO, it only shows the ones locally on MHB. To add to the confusion, I have added a list of ALL of our currently deployed machines to the SRO hosts. These also do not show up when logging into the MHB server.
-
@sbenson how did you create the remote (or HQ fog server) Did you clone one to the other? There is a file on the fog server /tftpboot/default.ipxe that contains the IP address of the fog server. I’m looking for cross pollination here.
In theory if you dropped the site to site link both fog servers should be able to image perfectly.
-
@george1421 Two totally separate installations. No database restorations or anything. Nothing cloned at all. Both default.ipxe’s show the correct IP addresses
-
@sbenson said in FogReplicator and Storage Nodes.:
Ideally we want SRO and MHB to be two separate servers, but sync the images between eachother. When I log into the MHB server it doesn’t show any of the images listed on SRO, it only shows the ones locally on MHB. To add to the confusion, I have added a list of ALL of our currently deployed machines to the SRO hosts. These also do not show up when logging into the MHB server.
This is fine. Its still not clear then why its using across the site to site link. If you power off the server at HQ can you image at the remote site?
-
@sbenson In a traditional FOG Master node and storage node setup you would use the location plugin to direct the clients to the right fog server for imaging. But this isn’t the case here you have to independent FOG servers.
I wonder if the spike in network traffic your network admin saw was actually image replication between the two fog servers??
-
@george1421 I haven’t tried powering off the main server. I can give that a shot and see if the MHB server even responds. I do feel this has to do with some snafu in my storage nodes. When I originally tried setting the syncing up I was under the impression it was the opposite direction(pull vs push).
-
@george1421 said in FogReplicator and Storage Nodes.:
I wonder if the spike in network traffic your network admin saw was actually image replication between the two fog servers??
This is not the case, I actually have the replication service set on a 24 hour cycle, and restart the service at 2am(iirc). This was the only way to make the replication happen at a given scheduled time.
-
@sbenson said in FogReplicator and Storage Nodes.:
I was under the impression it was the opposite direction(pull vs push).
The replication bits are isolated from the imaging components. So I don’t think a misconfiguration on this would cause imaging cross the wan link.
-
@george1421 here is a quick question. Am I supposed to have a default storage node and an extra one for SRO? This might be the problem. The original default storage node was removed so there is only a SRO storage node listed. tho the SRO server has 2 storage nodes. One labeled SyncMHB and one labeled SyncSRO. I will admit the Storage nodes have been extremely confusing from other replication services I have used in the past.
-
@sbenson ok that was confusing.
Lets say you have two fog servers (one at hq and one at remote site) and at your remote site you have a storage node (i.e. at your remote site you have 2 fog servers one is a full fog server and one is a storage node). You want images created to HQ to replicate to the other fog servers (full servers or storage nodes).
At your HQ you will create one storage group. That storage group will have your HQ FOG server configured as the default server and your fog server at your remote site. With that configuration your images from the HQ FOG server will replicate to the FOG server at the remote site. You will need to manually create the image definitions to see these images at the remote fog server.
Now at the remote fog server you create a new storage group and add your remote fog server and storage node in that storage group. The remote fog server shall not know about the HQ fog server. Its not part of its configuration. As far as the remote fog server knows, images just magically show up in its /images directory.
-
@george1421 The graphic here explains visually what I just stumbled through.
https://forums.fogproject.org/topic/6014/create-the-concept-of-a-foreignmasterstorage-deployment-node/13 -
@george1421 2 Physical servers SRO-FOG-01 and MHB-FOG-01.
for all intents and purposes SRO-FOG-01 is the Main server that will have the majority of work done on it(Creating new images, deployments, changes, etc). The MHB-FOG-01 will deploy images that I would have created on SRO-FOG-01, and synced over to MHB-FOG-01. The MHB-FOG-01 should NEVER tell anyone in the Southern California(MHB-FOG-01) network to pull from the Northern California(SRO-FOG-01) server.From what you explained it kinda matches what I have…except some things are weird.
SRO-FOG-01 has 2 storage nodes listed, SyncMHB(Not master) and SyncSRO(Master).
…SyncMHB is set to IP x.x.57.42(the IP of MHB-FOG-01), Storage Group default, Img Path = /images, etc…
…SyncSRO is set to the local IP x.x.76.44, Storage Group default, same Image path, etc.MHB-FOG-01 has one storage node, SRO(Not Master, I was told the name didn’t matter)
…SRO is set to x.x.76.44, default storage group, paths, etc…It may be best to just start over and say this. I have fog servers in 2 different cities, on 2 different internet circuits. I want the Images on Server 1 to be replicated on Server 2. What is the best method to complete this?
-
-
@sbenson said in FogReplicator and Storage Nodes.:
The MHB-FOG-01 should NEVER tell anyone in the Southern California(MHB-FOG-01) network to pull from the Northern California(SRO-FOG-01) server.
So in this case you should be able to power off the fog server at SRO and the MHB fog server and clients should image without issue. This IS the design.
-
@george1421 said in FogReplicator and Storage Nodes.:
So in this case you should be able to power off the fog server at SRO and the MHB fog server and clients should image without issue. This IS the design.
This is what we were looking for, that is why we wanted it to sync automatically during the middle of the night. Then possibly the only thing we would have to do after a sync is export the images(txt file) on SRO, and import them on the MHB server
-
@sbenson said in FogReplicator and Storage Nodes.:
SRO-FOG-01 has 2 storage nodes listed, SyncMHB(Not master) and SyncSRO(Master).
…SyncMHB is set to IP x.x.57.42(the IP of MHB-FOG-01), Storage Group default, Img Path = /images, etc…
…SyncSRO is set to the local IP x.x.76.44, Storage Group default, same Image path, etc.In this case SRO server should ONLY have the MHB fog server, with the SRO fog server setup as master. All others not the master. This will tell the Master FOG server to replicate to everyone else that is not a master.
On the MHB fog server I think you have one storage node, If that is the case create the MHB fog server as the master node and your MHB storage node as not the master.
This setup will then only sync SRO FOG server -> MHB fog server and MHB Fog server -> MHB Storage node. That way there is only one replication across the WAN.
-
@sbenson said in FogReplicator and Storage Nodes.:
@george1421 said in FogReplicator and Storage Nodes.:
That is super confusing.
Its super confusing since it is so complex. Your setup is similar to the HQ and ATL setup (right side of the picture). Just remember the FOG server setup as the master in the storage group will send the image to all other nodes not the master node within the storage group.
-
@sbenson said in FogReplicator and Storage Nodes.:
Then possibly the only thing we would have to do after a sync is export the images(txt file) on SRO, and import them on the MHB server
Yes this is correct export from SRO and import into MHB.
The developers are working on a way for this setup to automatically update in a future release of fog, maybe 1.4.3 or 1.4.4, but I can’t say. They are creating a new API call that will make this process a bit easier.
-
@george1421 said in FogReplicator and Storage Nodes.:
In this case SRO server should ONLY have the MHB fog server, with the SRO fog server setup as master. All others not the master. This will tell the Master FOG server to replicate to everyone else that is not a master.
On the MHB fog server I think you have one storage node, If that is the case create the MHB fog server as the master node and your MHB storage node as not the master.
This setup will then only sync SRO FOG server -> MHB fog server and MHB Fog server -> MHB Storage node. That way there is only one replication across the WAN.Sorry for the delay in getting back to you, been busy with other projects. So fog servers pull from the master node, not get pushes from the master node?
So on SRO I create an SRO node where it is the master, it’s own IP and set a user/pass for it
On MHB I set MHB as a master node(storing images in /images?) and a SRO as a client node(also storing images in /images?)Edit, wait that is totally backwards from what you just said, let me re-work this