FogReplicator and Storage Nodes.



  • Server
    • FOG Version: 1.3.0-RC-36 Rev 6048
    • OS: Ubuntu 16.04
    Description

    In our environment we have 2 fog Servers, one In Northern California(SRO) and one in Southern California(MHB). The fog server in SRO runs fine, speeds are great, 3 minute laptop deployments, gigabit speed, etc. Last Friday I was working with someone in MHB showing him how to use fog and the speeds were about 100mbps. He was plugged into a switch and guessed that the switch wasn’t Gig. Later I found out from out network admin that something was saturating the link between MHB and SRO(100mb link). We found that it was the fog server. I do have a Storage Node setup from MHB that(from my understanding) is supposed to sync images from SRO. Does the storage node just tell the machine to pull images from another server in the same node? Why when I till it to pull an image that is on the local machine is it pulling from the remote machine? Should I just disable the nodes and manually sync the images from SRO to MHB? Last Friday I disabled the Storage node and today I had the network guy message me saying that it’s happening again.

    Was I wrong in understanding that FogReplicator was supposed to sync images from SRO to MHB?

    How can I reliably sync the images from one machine to another?

    Why when I point a host at a local image is it pulling an image with the same name from the remote host?


  • Moderator

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


  • Moderator

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


  • Moderator

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



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


  • Moderator

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


  • Senior Developer

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



  • @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



  • 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


  • Senior Developer

    @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”?


  • Moderator

    @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 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
    

  • Senior Developer

    @george1421 True true true.


  • Moderator

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


  • Senior Developer

    @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.)



  • @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    |
    

  • Senior Developer

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


  • Senior Developer

    @sbenson So:

    SRO side Needs:

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

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


  • Moderator

    @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 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).


Log in to reply
 

378
Online

38981
Users

10712
Topics

101676
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.