On 12/11/20 6:46 PM, Dan Egli wrote: > On 12/11/2020 3:01 PM, Daniel Fussell wrote: >> PXE booting is usually done to install a base image to a machine. If >> you want to PXE boot and run diskless clients, you may have to shuffle >> some things into the initrd and change systemd service dependencies to >> start the network before mounting the root filesystem and chrooting >> to it. >> >> As said before, to have a common filesystem/image with machine-specific >> customization (whether made by systemd, admin, or user) , you are going >> to have to get clever with overlayfs or some combination of small NFS or >> local volumes mounted into the tree. You will have to be careful that >> processes needing files in the customized mount areas are not run before >> the overlay/mounts are ready, else the processes may continue to use the >> open file descriptors from the original volume. >> > Who said anything about machine specific? I'm looking at the idea of > having 25-50 machines, identical hardware, identical software, > identical uses. Only difference between them would be 1) hostname, 2) > ip and 3) specific SET of data being processed. >
This sounds more like a compute cluster or a render farm than your run-of-the-mill home network; clusters are easier to PXE boot and run from a common image. I'd further say that if you are splitting up data sets for machines to chew on, then you should probably look at cluster managers like Moab, Maui, PBS, Torque, etc. If you are CPU bound, store all of your data sets on an NFS export on a central server and tell the processing nodes which files to work with in the job scheduler; there's no reason to create separate home directories for each processing node. The results files can be written to the NFS, either in the same directory, or in separate directories as you desire. Those are things is determined by the job scheduling config options, not the boot-time config. If you are IO bound (especially network IO bound), I understand various cluster managers will distribute the necessary files in each batch job to each node, then start the batch, and write the results out to the destination of your choosing. I've heard of some clusters managers that can split the dataset to be stored on each node's local storage, and if a process needs data stored on another node it will migrate the entire process to that needed node because it's sometimes cheaper to move the process' memory and use local storage than to move entire data sets across a network. ;-Daniel /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
