Separate server for ipxe
-
Can you explain a bit more why you want to move the ipxe services?
FOG does require pretty tight integration with iPXE to make the menu work seamlessly.
-
My fog server is getting quite a few requests and the cpu load climbs to a point where the pxe boot will start timing out for multiple systems. Users don’t want to have to escape out of the pxe boot and I’m forced to shut the server down.
-
@ablohowiak you can’t really move the parts of ipxe that are effected here, since it’s the php generated boot files that you’re timing out on. let’s try to fix the real problem than. first off, what OS and version number, what version of FOG, how many clients checking in? Also, what kind of hardware are you running your server on?
-
@ablohowiak about how much systems connecting the server we are talking about if you say the load is slowing the machine? My first intention would be get a more powerful system?
-
OS: Ubuntu 16.04
Fog:
Hardware: VM - 4 cpu @ 2.67 GHz with 12GB of ram.
Clients: 8k+Prior - 1.30 RC 11, no problem with the same number clients and server.
-
@ablohowiak could you please update to latest rc?
-
do you have any systems running the legacy client, or are they all new client?
-
If your FOG master server is getting “overloaded” you can setup a FOG storage node for imaging and pxe boot services and let the FOG master node manage the client check-ins and overall FOG image management process. With 8k clients I would have already spun up additional storage nodes on your campus just to manage (share) the load.
I might have also spun off the mysql database to its own server that could be customized specifically for transactional loads.
-
Ah, I wasn’t aware that the storage nodes could also provide the pxe boot. That’s exactly what we’d like to do and we have a number of them, albeit running older versions.
Clients are mostly 11.5 or higher.
-
@ablohowiak said in Separate server for ipxe:
Ah, I wasn’t aware that the storage nodes could also provide the pxe boot. That’s exactly what we’d like to do and we have a number of them, albeit running older versions.
Just be aware that all of the storage nodes and master node "“should” be on the same release so everyone is happy. But the pxe files were included on the storage nodes starting with 1.3.0. (in reality one of the trunk builds of 1.2.0 but 1.3.0 is a nice round number).
Just be aware either way the master FOG server will still be part of the pxe booting process since the boot.php is used to instruct the clients on what to do during the iPXE menu creation. PXE boooting from the storage nodes may only resolve parts of your issue.
-
@george1421 said in Separate server for ipxe:
PXE boooting from the storage nodes may only resolve parts of your issue.
or possibly none. i suspect what you’re seeing is a product of a bug in 1.3.4 that has been fixed in later release candidates. before you set out to do anything complicated, try upgrading FOG.
-
@Junkhacker I suspect the same.
Or, it could possibly be something else. Remember that time I was beating my head against the wall for a week over why the fog server was crippled? Turned out it was a broken fiber cable left laying unfixed for a week by a piece-of-trash contractor that should have been fired.
Not saying it’s a broken fiber cable but… it could be the last thing you would expect, something very wild and off the wall.
