Ram Disk and Fog
-
I don’t see any situation in which a ram disk would help a fog server. Disk read/write speeds are usually not the bottleneck for a fog server, normally network throughput is.
-
What I would like to do is put a ram disk on the host. Not the server. Server side is fine. I run a cluster setup and use USB 3.0 drives that have been failing me (not to mention are slow). So would like to port everything over to a ram disk and just add another stick of ram to all my hosts. Ideally, FOG (kind of like how clonezilla has a to ram option) would create a ram disk on the host, then image the to the ram disk again, on the host. Obviously each time a host would boot it would need to do this. I didnt see a ram disk write up anywhere so didnt know if it was possible.
-
@cmcgonag What operating system do you expect to run on this target computer?
-
@cmcgonag I am not sure I get what you mean. This sounds like you want to image to a RAM disk and the boot off it. From what I understand this is per se not possible as for imaging you already need to boot the FOG OS (called FOS - a small linux system that runs in RAM itself). From there it would be possible to create a RAM disk and write an image to that but what then? How do you boot into that system? Via reboot? Or possibly via chrooting into that system. That would actually be possible but pretty nasty to setup.
Why not doing something like “diskless booting”? See here for a description on that in the Arch wiki.
-
essentially ubuntu with some mods. I can run whatever though. I believe most of my drivers are compatible with most linux distros.
-
@sebastian-roth I think this will work! I need to read through the whole write up, and report back. But essentially the idea is what I am looking to accomplish. Just a quick question, does the nfs server have to have enough storage for the (client file system) x (the number of clients)?
-
@cmcgonag Now we know that you are talking ubuntu here. There are things you can do today to make this happen. There is no need to image a ram drive, just use a live boot media. Then use FOG iPXE to deliver the live boot media to the target computer.
Ref: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
This will give you the same results as deploying to a ram drive in that it will have to be rebuilt each time you boot. You will just need to setup an NFS share to keep persistent data. Beyond that you can create a custom ubuntu live boot image and still deploy that via iPXE to your target computers, using FOG.
-
@cmcgonag said in Ram Disk and Fog:
ust a quick question, does the nfs server have to have enough storage for the (client file system) x (the number of clients)?
While I know this was directed to Sebastian, but if you use the live boot concept, you have a single OS image that is deployed to any computer, then you have the live boot OS connect back to your home drive for user’s nonvolatile file storage.
-
@george1421 That is awesome. So for the clusters, they actually dont have any non volatile storage needs. Essentially all that is handled via the scripts from the main server, so just need a fix without the NFS storage I guess. They just call for data, get it and send it back. All NVM processing is done somewhere else, and the code to handle that is on the programs I have installed on the OS.
I guess what I need to figure out is how to create a live boot media of current setup. In your write up, can I also deploy via groups? My plan was to more or less push updates via the group function not the individual menus. I will spend some time reading the diskless setup tutorials y’all posted as well. Because I will no longer will have an sda in the traditional sense (usb 3.0) just want to make sure I understand where the filesystem will live.
-
@cmcgonag said in Ram Disk and Fog:
In your write up, can I also deploy via groups? My plan was to more or less push updates via the group function not the individual menus
I’m not sure I understand this question. The target systems will pxe boot. You will tell fog the default action will be to run a specific iPXE menu. That specific iPXE menu will be a custom one you create to boot your live image. Its all automatic. If you want to update the master image, you just update it on the fog server and tell the clients to reboot. When they return to service they will be executing the new code all without human intervention.
-
@george1421 As for creating a custom ubuntu live, here is a thread that talks about it. https://askubuntu.com/questions/741753/how-to-use-cubic-to-create-a-custom-ubuntu-live-cd-image
Also something to consider that’s a bit more embedded is something like thinstation. Thinstation is intended to create a thin linux client to be used as a small and tight bootable linux OS. IF you don’t need the robustness of ubuntu, then it may be something to look into. I don’t know your exact use case so I can’t say it would be a good fit or not.
-
I was confused about this part, but realized that I was use to the old way of thinking / booting into my hard disk. You are correct I need the default loop to pull down a fresh copy every time. I appreciate the help.
“The last bit of magic we need to do is setup a new FOG iPXE boot menu entry for this OS.
In the fog WebGUI go to FOG Configuration->iPXE New Menu Entry
Set the following fields
Menu Item: os.Ubuntu1604
Description: Ubuntu 16.04.03
Parameters:
kernel tftp://${fog-ip}/os/ubuntu/16.04/vmlinuz
initrd tftp://${fog-ip}/os/ubuntu/16.04/initrd.gz
imgargs vmlinuz initrd=initrd.gz root=/dev/nfs netboot=nfs nfsroot=${fog-ip}:/images/os/ubuntu/16.04/ locale=en_US.UTF-8 ip=dhcp rw
boot || goto MENU
Menu Show with: All Hosts
That’s it, just pxe boot your target system and pick Ubuntu 16.04.03 from the FOG iPXE boot menu.” -
@cmcgonag Yes you have it on the iPXE menu stuff.
One additional thing, you can set your
Ubuntu 16.04.03to be the default action in the iPXE menu. So there is no ‘picking’ if you want it to just happen. -
@cmcgonag sounds a lot like you are in need of a customized embedded linux os to do some sort of jobs. There are better ways to do this than using fog and Ubuntu. You should look into the Yocto project or a customized copy of Debian.
-
@cmcgonag Without going too much into the detail of your application (because it sounds proprietary) Are these clustered system headless, or is there an interactivity between humans and the system where you need to X windows gui? As Wayne said there may be other ways to go about this.
FOG it self uses an embedded linux that gets deployed to the target computer to move the disk images. We call this embedded OS FOS. It is comprised of a linux kernel (bzImage) and a virtual hard drive (init.gz). That is delivered to the target computer using tftp and http. If you are creating a headless system you could do something similar without the requirements of FOG.
-
@george1421 They are headless, however, they do have the ability to run interactively but I only use that for debugging, we keep having issues with our cron. I have them restart every 12 hours and they keep hanging. That is not ideal at all. We are still building out the datacenter now, so we havent circled back around to this. So far I am still booting using the old method, It is ubuntu. I can run whatever linux distro makes it easiest. I also am looking into MOSIX.
-
@george1421 If there is an easier way to do that, then I am all ears. I like the FOG interface though. Makes it easy. In your original method you posted does that require a hard drive to to be present or is it building the OS to init.gz in ram?
