Slashdot Mirror
High Performance Diskless Linux At AX-Div, LLNL
Lee Busby writes "As a co-author, I am biased, but I think that our recent paper describing a diskless Linux deployment at Lawrence Livermore National Lab (PDF)may be of general interest. It's a little different than most diskless systems -- simpler, and designed to be high performance."
Thanks for the link. I work in a similar environment where security requirements are more easily met by diskless workstations.
This project started a few years ago and there have been some interesting new developments since.
Given the current situation, would you consider using iSCSI in your environment?
"Provided by the management for your protection."
This has some nice configuration management ideas. Given that a linux distribution is small, cloning them for each diskless is a neat approach to balance centralized management versus changing hardware.
That said... NFS is woefully insecure so, if subversion by an insider is a problem (as it would be with, say, disk workstations), NFS may not be the best choice for handling the disk management.
A.
the more they stay the same. This doesn't seem too much different from the 'dumb' terminal connected to the corporate mainframe that is still in use today. Except that it is running Linux, a much superios OS to IBM's MVS or z/OS.
CMDRTACO CHECK YOUR EMAIL!
A quick skim of the PDF leads me to believe they are still using NFS for the operation.
My question would be, does anybody have any meaningful experiences using CodaFS or Intermezzio?
Where I work, we have NFS mounted home directories. When the main server goes down, we all get to twiddle our thumbs because we cannot do anything without a home directory.
It would seem to me that the caching of Coda and Intermezzio would be better - you still have the centralized management of the disk images, but you also get the speed of local access and the robustness of not having a single failure point in the server.
But I've not had time to set up a trial system - has anybody else?
www.eFax.com are spammers
The company I work for (actually, the company I own) builds and sells specialized systems that use diskless via NFS. One server and up to 10 terminals. Each terminal has it's own (very stripped down) root fs, and they all share a single usr fs mounted ro.
I use e2fs still, despite other options available. It benchmarks reasonably well across the board. (Personally, I think it's a lot more important to have more than sufficient memory on the server than to quibble about benchmark numbers.. cache cache cache.) More importantly, e2fs has proven reliable, even when tired customers just turn their server off rather than shut it down. (the system does send internal "Nag" notes to upper management whenever the server is improperly shut down) More than that though, as I'm a (totally) small time business with very limited human resources, the customers all need to be on the same page. Much easier to troubleshoot over the phone when everybody's running the same 'stuff'.
Much ado has been given to configuring the sizes of rsize and wsize in NFS mounted filesystems. I've tested and tested and tested. The default value (4096 in the server/terminal kernels i run) works the best over the most situations, but that's perhaps due to the combination of hardware I'm using, so if you're setting one up yourself, you'll probably want to investigate. (see the current NFS howto at linuxdoc.org. There's a section on tuning, and links to some benchmark suites.). At any rate, you definitely want your NICs to run in full duplex to avoid collision overhead on NFS so do your homework before picking a card. Performance in my case isn't an issue anyways, except when booting a terminal. Even on my local setup here, where I do a lot of box backups on the back-net via NFS, the defaults seem to work as well as anything else.
The terminals are typically pentiums, recycled. They're cheap, and need to be given the harsh environment the terminals work in. I've used both netboot and etherboot as loaders, and have finally settled on etherboot as it seems to build loaders that for are more tolerant of NIC card firmware revisions.
Network hardware is just a switch and 100mbit network cards. I support only one card at present (actually 3, but two are being deprecated), but bought a dozen or so of the most commonly available cards and played with them for a while before deciding on one. I want consistency in loaders, especially across a single site. Mostly though, I want the customers to be able to replace *anything* that breaks with commonly available stuff themselves so they can get back up quickly. Not that I mind the fees for on site service, but I'd much prefer happy customers. Rabidly happy customers have basically done 95% of my sales for me. Those sort of relationships aren't worth jeopardizing over specialized hardware or a fee.
The terminals all run our proprietary software package. (While that might offend some OSS guys, it pays my bills.. and at ~130K lines of C, represents a *substantial* investment in time, and a long period of being 'not paid'.) A hook in /etc/inittab to the software replaces getty in the appropriate runlevels, and since my customers all own pizza/pasta stores, the replacement is named 'pizgetty'. Pizgetty is just a wrapper that strips root perms and starts the frontend of the real software package. Each terminal runs several separate connections (typically.. it's configurable) to the server software so a terminal actually provides more than one virtual/independent screen. The software handles all configuration internally, so changing node names around, re-configuring printers or other hardware is done (hopefully) only from menus within the software. However if you're swapping nodes, the affected nodes do have to be rebooted once the config is written. Things are statically routed, which keeps configurations easy to manage.
Likewise, the server screens function like a terminal's screens. There's no login prompt without a high level of p
Seems swap via NFS might cause some bottlenecks. Since cost doesn't seem to be the issue, why not compile ide and fs support into your tagged client kernels? You could then on the client boxes (theoretically?) add a hd and set up swap locally. Though I suppose there might be security concerns at LL about the theoretical possibility of removal of a 'swap' harddrive and subsequent inspection elsewhere.