[Leaplist] Power mitigation, diskless v. truly thin, virtualization and/or remote -- WAS: Scanner Setup Help?

[Kevin Korb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The primary use of 2 of my diskless systems is playing video files.  One
of them is the media system in my living room and the other is the media
system/IRC terminal in my bed room.  This was one of my primary reasons
for not considering true thin clients.  Not to mention the fact that the
one in my bedroom is just the hardware that used to be my desktop.  The
only reason the one in my living room is fairly new hardware instead of
something old is that it has to play HD content which requires a good CPU.

Bryan J. Smith wrote:
> Richard F. Ostrow Jr. <rich at warfaresdl.com> wrote:
>> A major version of "diskless" is that you spend real money getting
>> a nice, highly redundant file server, and the client machines
>> benefit from the redundancy built into the file server - ie, they
>> don't need expensive RAID cards or anything similar. Of course,
>> doing this for a desktop system probably isn't a good idea...
>> 100MBit ethernet will only get you 10-12 MBytes/sec, whereas a
>> local hard drive will get you a 10X performance increase.
> 
> First off, it depends on the implementation of diskless.  If you
> are using read-only mounts with caching (various filesystem
> operations) and tmpfs for coalesced writes, then you can mitigate
> performance issues.  In some cases, you may see other benefits,
> including security.
> 
> Secondly, this brings me back to the fact that diskless != thin
> client.  Thin clients don't access binaries, libraries, etc...
> over a network, but only display remotely running programs.  So
> that removes the entire network bottleneck, as long as the remote
> display is using an efficient widget/meta communication.
> 
> The only issue with thin clients remaining are bitmapped operations.
> They eat both bandwidth and unnecessarily taxi the server with overhead.
> E.g., streaming video in a browser window.  Red Hat's SPICE protocol
> was designed to remove this issue, making thin clients a desktop
> reality without common Internet browsing issues.
> 
>> Personally, I utilize a master RAID server with real
>> redundancy hardware (poweredge 1650 with 3 1TB SATA drives
>> connected to a RAID-1 with 256M battery-backed RAM, as well as
>> 768M ECC registered RAM, lights-out management, etc... all
>> for ~$715) ($150 server, $75 lights-out management
>> module, $80/drive, $250 RAID card). One drive is configured
>> as a "hot spare", meaning it will automatically reconstruct
>> the array in the event of a failure (buying me some time to fix
>> it before another drive fails, which DOES and HAS happened 
>> killed my last array)).
> 
> Yes, hot spares should be considered mandatory with today's disk
> failure rates in excess of 2%/year (400,000 hours MTBF).
> 
>> Note that as of today, you can get 1.5 TB drives for $90 each.
> 
> Indeed.  And 2W (tiny fraction of a watt when idle) 2.5" drives
> are running $75 for 500GB, $50 for 320GB.
> 
>> To this, I connect my mythtv backend, which boots off of
>> NFS to take advantage of the redundancy...
> 
> What about your network redundancy?
> Also, have you considered local CompactFlash instead?
> 
>> and then tosses it out the window by using a software RAID-0
>> for the recordings across 3 1TB hard drives (so the system is
>> fault-tolerant, but the recordings are highly susceptible).
>> Unfortunately, my experience thus far has been that linux
>> only barely supports diskless systems, and frequently breaks
>> that support for lengthy periods of time with kernel updates
>> and baselayout updates.
> 
> All Fedora and Red Hat Enterprise Linux releases have supported
> "Stateless" for a long period of time.  I have implemented such
> for both diskless and thin client.
> 
> It only requires identification of select directories for write
> operations.  Most of the time, the defaults "just work."
> 
> In the case of Thin Clients, the Thin Client only needs a minimal
> environment (X, maybe ICAClient, RDP, etc..., assuming you're
> doing a full, remote X root -- otherwise you need a window manager
> as well), which completely simplifies the issue.  I.e., /tmp
> and a few other things.
> 
>> For example, a recent kernel update removed TCP packet support
>> from NFS... which causes problems on my switch (admittedly, not
>> a linux problem, but a switch problem... but using TCP packets
>> fixed it).
> 
> Did you mean UDP?  I'm not following.
> 
>> Personally, for low-power systems (of which I have three),
>> I use solid state over CF cards with a Via architecture
>> (usually C7 CPUs). These have high temperature tolerances
>> and very low power consumption... they've been running in
>> my garage without A/C or ventilation for 1.5 months thus far.
> 
> Before the Intel Atom, the long-standing Cyrix, National Semi
> and Via products from Geode through C3 through C7 were the lowest
> power x86 solutions.
> 
>> Basically, these are simple data processing machines
>> (email, web server, proxy (purely in RAM, not in flash),
>> bind9 server, etc) that don't need tremendous amounts of
>> storage... or if they do, they can tie in over NFS
>> to my file server.
> 
> Candidates for virtual machines.  For Linux on Linux, Xen paravirt
> is still a very capable and high performing solution, putting KVM
> and fullvirt aside.
> 

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpp9xcACgkQVKC1jlbQAQebDACeJQw4jpT9NHEdyVZ4RXcmBfJG
+RkAoIzTwL51b6B8ydoup62XxvwKdjU6
=lxoS
-----END PGP SIGNATURE-----

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.