2 primary fog plan
-
@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 -
@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?
-
@george1421 yes to first two question. Not sure what do you mean by adding a target computer to a location.
-
@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.
-
@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 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
-
@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.
-
@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.
- 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.
- 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.
-
@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?
-
@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
-
@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.
-
Sounds good.