Decoupling FOG Database from FOG Server
-
Hi,
May i know is it possible to decouple the FOG Database from FOG server? If can is there any guides on this?
Example:
FOG Server at 192.168.1.101
FOG Database & images store at 192.168.1.102Thank You
Best Regards
WT -
@wt_101 You can decouple the database. You can moved the images off the fog server too, but with that you will lose the ability to multicast. If multicasting isn’t an issue for you then its possible.
As to instructions. There isn’t any as of now.
What device is your second server? Can you install FOG on it or is this a general purpose computer that will be used for more than just FOG?
-
@wt_101 said in Decoupling FOG Database from FOG Server:
FOG Server at 192.168.1.101
FOG Database & images store at 192.168.1.102Don’t think putting database and images on the same machine is going to help you with decoupling the load. You may tell us a bit more about why you wanna do this in the first place.
-
This is completely possible. For spreading things out, any of the following is possible.
Multiple FOG Masters to separate FOG Client traffic / node traffic from your traffic / engineer traffic.
- This solves the nervous user problem (clicking buttons in the UI over and over rapidly).
- This solves load issues with 15 engineers / technicians just sitting on the dashboard with the graphs chewing up server CPU.
- 1 FOG Master for people to interact with.
- 1 FOG Master for everything else (node check-ins, FOG Client check-ins)
- Could split this out even further if you wanted. Could setup load balancing with F5 or HAProxy, for example. Or, could do simple DNS load balancing by creating many records of the same DNS name, but each pointing to different FOG Server IP Addresses.
One or more seperate storage nodes for imaging load
- Build separate Storage Nodes, as many as you think you need. Set one as the storage master of your storage group. Only storage group masters can multicast.
- An image can be assigned to multiple storage groups. So you could have two storage nodes, each a master of a separate storage group. One will be the image master (the original), and that master will replicate to the other master.
- Replication documentation here.
- Multi-casting documentation here.
- Multi-casting troubleshooting documentation here.
If your geographically dispersed, use the location plugin.
- Documentation can be found here. This covers the topic with an older FOG version but is still accurate.
Put Database on dedicated VM.
- Setup MariaDB on another VM. Set password, remote access. Documentation here.
- Dump your database from your fog server, load to new DB.
- For all your your fog masters and storage nodes: Point them to the new database via this file:
/opt/fog/.fogsettings. Documentation here. - Re-run fog installers on all fog masters and all storage nodes.
Increase Client Checkin Time
- This will resolve a lot of the client load.
- Documentation here.
-
@sebastian-roth the main goal is to ensure high availability for FOG Server & Fault Tolerant
decouple into below as individual component
FOG Web UI
FOG Database
FOG Storage Node -
Hi @george1421 may i know why moving images off the fog server will lose multicast ability?
The second server will be a ubuntu server with RAID setup to store the images only. (this is just the plan, we yet to setup)
-
@wt_101 said in Decoupling FOG Database from FOG Server:
may i know why moving images off the fog server will lose multicast ability
The service that runs the multicast is only (normally) run from a master node in a storage group. The fog server will use the udpsend command utility on the fog server against local media (or perceived local media).
What is your end goal here? The big question is why, what do you hope to achieve or remediate with this architecture change?
-
“Fault Tolerance” is a huge, generic term. I hear it so often in my job, that it doesn’t mean anything to me anymore.
What is your written & agreed upon RPO?
What is your written & agreed upon RTO?
What is your written & agreed upon SLA?
https://www.acronis.com/en-us/articles/rto-rpo/
https://wow24-7.io/blog/what-is-sla-service-level-agreements-and-their-role-in-business -
This post is deleted! -
Hi @george1421
Because we want to avoid WebApp Server Down (storage failure) causing the images fail together. If we can host the image at other server with RAID setup this can reduce the risk.
Is it possible to setup storage node (Image Server) as my master node so that it can perform multi cast? Because we dont need to store the image at WebApp Server
I do experiment with below setup using multi PC with virtual box for multi cast
FOG Web Server (192.168.1.66) @ PC1- i disable default storage node (basically we dont need it in the web server)
- 192.168.1.99 as new storage node using default group & set as master
FOG Image Server/Storage Node (192.168.1.99) @ PC2
Client
PC2 have 2 virtual box host 1, 2
PC1 have 1 virtual box host 3I group all these host 1,2,3 together to perform multicast
1st & 2nd round it success perform multi cast for all 3 host
3rd round
- PC2 host 1 & host 2 it process about 16% then stuck at few min then can proceed the partclone deployment then until 46% and stuck again
- PC1 host 3 it stuck at partclone screen not even progress bar appear
few min later i lost my internet connection guess the router is jam
may i know what is the problem is how can i troubleshoot to enable the multicast work smoothly?
Thanks
-
@wt_101 I can tell you that multicast is more problems than unicast. Multicast requires more resources (things setup correctly) than unicast.
The way fog works is that the udpsend (multicast sending program) is launched by the web server. So multicasting is linked to the server where the web ui is running. The storage nodes do not have a web ui. So the key here is that multicasting is started by the FOG web server.
It is technically possible to launch a program on a remote linux server using ssh. This requires ssl certificates to be put in place so that the ssh connection uses certificates instead of a password.
A storage node is technically a normal fog server except it uses the master node database and the web interface is shut off from browsing. The web interface is there, its just blocked from access. So the udpsend program should also be installed, so it could send out multicast images. FOG isn’t designed that way, but its not impossible to do if you had the motivation and php programming skills.
The last thing I can think is if:
- The FOG API can be called on a “Storage node” AND
- You can schedule a multicast deployment via the API
You could make a curl call from the master node to the storage node to initiate a multicast deployment. I’m only mentioning this because it might be possible, but I have not tried to know if it IS possible to do.
So to recap I see 3 ways to get a storage node to multicast.
- Use ssh and call udpsend directly from the fog server
- Write a custom php page on the storage noted that would launch udp send based on a web page call that passes the required parameters.
- Use the FOG API to call a multicast send on a storage node.
I can’t tell you if any of these methods will work. I can only tell you that the sending of multicast image is tied to the FOG Web UI.
