2 primary fog plan

[msi]

Hi!
How can I achieve below scenario? all of those beta and alpha node would branches at different states. Alpha and Beta would divide all US locations into two group.

[Sebastian Roth]

@msi What do you expect from us? Where exactly should we start? Advices on the network infrastructure, subnetting, MPLS. Or are you asking for how to configure the FOG nodes?

I read through your other threads trying to get the picture but I still don’t have a clue. Please give us some more information. We know you’ve already setup a FOG server. So would that be the one named Main FOG Server in your picture. And I see that you’ve also had a look at the location plugin. So I’d say you’re on the right track. Please ask more specific questions.

[george1421]

First let me say (yes I know where it came from) this is a pretty old drawing that may not reflect the current FOG design.

A FOG server has two different modes. These modes are selected when you first install FOG. The first mode is “Normal” and the second mode is “Storage”.

A Normal mode install is what you would do if you had a single stand alone fog server.

A Storage mode install is what you would do if you needed to place one or more FOG servers closer to the target computers than a Master (normal mode install).

In this setup you will have a master node and one or more slave (storage) nodes. These storage nodes can be local to the master node (to share the imaging load) or remote beyond some WAN link.

The master node copies all of the snapins and images from the master node to all of the storage nodes in its storage group.

Target computers can pxe boot from local storage node servers, BUT they must be able to reach the master node during pxe booting. Also if you are using the FOG client on each computer, the FOG Client will only interact with the Master FOG server and not the local storage nodes. On e final caveat, when capturing an image, only master nodes can accept an image. To say it another way, Master Nodes can capture and deploy images and snapins, Storage Nodes can only deploy images.

[msi]

@george1421 @Sebastian-Roth You understood me right. What if the master node went down for some odd reason, can we still be able to deploy from the branch storage node? Another scenario is that I have a main machine in Newark city , and my storage is at Elizabeth city. The locations are connected through MPLS. When I deployed a machine at Elizabeth, it took an hour to deploy. However, when I did it at Newark where main FOG machine is, it took only half an hour with the same image. Is there a network issue here? DHCP at Newark pointing to Newark Fog machine, and Elizabeth pointing to Elizabeth node as below:
Newark: next-server 200.134.200.230
bootfile ipxe.efi
Elizabeth: next-server 200.135.200.230
bootfile ipxe.efi

[george1421]

@msi said in 2 primary fog plan:

What if the master node went down for some odd reason, can we still be able to deploy from the branch storage

No in this setup if the master node is off-line all of the storage nodes would be down. There is one part I left out in my wall of text from before. One of the differences between a storage node and a normal node is that the storage node doesn’t have a local database. It uses (connects) to the master node’s (normal mode) database for scheduling and reporting. If the master node is down, then there is no database for the storage nodes. There is an unsupported way to kind of make this scenario work, but its no 100% clean.

In your Elizabeth example. Did you install the FOG location plugin? Did you assign a storage node to a location? Did you assign the target computer to a location?

[msi]

@george1421 yes to first two question. Not sure what do you mean by adding a target computer to a location.

[george1421]

@msi You assign the host you want to image to a location too. That way the target knows who better to talk to. Otherwise it just goes back to the master node.

[Wayne Workman]

@msi said in 2 primary fog plan:

Not sure what do you mean by adding a target computer to a location.

That’s demonstrated in the location plugin video.

[george1421]

@wayne-workman ref: https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

[msi]

@george1421 @Wayne-Workman Yes, I have. George helped with that before. I am kind of suspecting the switch. I noticed those are catalyst 2950 switch. Speed is 10/100 Mbps

[msi]

@george1421 Also, how can I start replication time and image at my choice? For example, I have 12 images but I want to replicate only two of them to a particular storage node at night time. So that I don’t disturb the day time traffic.

Sorry that I am asking too many question, but I have to answer to my boss.

[george1421]

@msi Well there isn’t a clean way to control replication based on time of day. But there is a way…

There are two elements to this.

1. In each image definition you can control what images replicate. For you to send only two a night, just enable the images for replication you want to replicate on that day.
2. You can setup a cron task to enable and disable the fog replicator service based on time of day. Using the same concept you can change the bandwidth consumption by updating the record in the database then restarting the fog replicator service.

Depending on your image size, you might be better off seeding the remote locations via a usb flash drive then enabling replication on the master node once the images have been seeded on the remote storage nodes.

[msi]

@george1421 I just want send two that is corresponds to that particular branch. Can you give me one example of Cron task in this case?

[Wayne Workman]

@msi something like this:

First, disable and stop the image replicator.

systemctl disable FOGImageReplicator
systemctl stop FOGImageReplicator

Then setup a root crontab that would restart it when you want to start, and stop it when you want to stop. We use restart incase it’s already running. If it’s not running, restart will just start it.

0 22 * * * /usr/bin/systemctl restart FOGImageReplicator
0 6 * * * /usr/bin/systemctl stop FOGImageReplicator

[msi]

@wayne-workman I think, I would rather create a storage group and assign the storage node under that group. According to your video tutorial, it shouldn’t replicate it.

[Wayne Workman]

Sounds good.