Editing Diskless node

{{Short description|Computer workstation operated without disk drives}}
[[File:Sun 2-50 Front.jpg|thumb|A Sun-2/50 diskless workstation from [[Sun-2]] series]]
A '''diskless node''' (or '''diskless workstation''') is a [[workstation]] or personal computer without [[disk drive]]s, which employs [[network booting]] to load its [[operating system]] from a [[server (computing)|server]]. (A computer may also be said to ''act as a diskless node'', if its disks are unused and network booting is used.)

Diskless nodes (or computers acting as such) are sometimes known as ''[[network computer]]s'' or '''hybrid clients'''. ''Hybrid client'' may either just mean diskless node, or it may be used in a more particular sense to mean a diskless node which runs ''some'', but not all, [[application software|applications]] remotely, as in the [[thin client]] computing architecture.

Advantages of diskless nodes can include lower production cost, lower running costs, quieter operation, and manageability advantages (for example, centrally managed software installation).

In many universities and in some large organizations, [[Personal computer|PC]]s are used in a similar configuration, with some or all applications stored remotely but [[execution (computers)|executed]] locally—again, for manageability reasons. However, these are not diskless nodes if they still [[booting|boot]] from a local [[hard drive]].

==Distinction between diskless nodes and centralized computing==

Diskless nodes process [[data (computer science)|data]], thus using their own [[Central processing unit|CPU]] and [[Random-access memory|RAM]] to run [[computer software|software]], but do not store data persistently—that task is handed off to a server. This is distinct from [[thin client]]s, in which all significant processing happens remotely, on the server—the only software that runs on a thin client is the "thin" (i.e. relatively small and simple) client software, which handles simple input/output tasks to communicate with the user, such as drawing a [[dialog box]] on the [[display device|display]] or waiting for user input.

A collective term encompassing both thin client computing, and its technological predecessor, [[computer terminal|text terminals]] (which are text-only), is [[centralized computing]]. [[Thin client]]s and text terminals can both require powerful central processing facilities in the servers, in order to perform all significant processing tasks for all of the clients.

Diskless nodes can be seen as a compromise between [[rich client]]s (such as ordinary personal computers) and centralized computing, using central storage for efficiency, but not requiring centralized processing, and making efficient use of the powerful processing power of even the slowest of contemporary CPUs, which would tend to sit idle for much of the time under the centralized computing model.

{| class="wikitable" style="margin-left:auto; margin-right:auto;"
|
![[Centralized computing]] <br/>or [[Thin client]]
!Diskless node
!Dataless node <ref>page 166, Managing NFS and NIS, By Mike Eisler, Ricardo Labiaga, Hal Stern, O'Reilly Media, Inc., Jul 1, 2001</ref>
![[Rich client]]
|-
!Local [[hard drive]]s used for data
|{{No}}
|{{No}}
|{{No}}
|{{Yes}}
|-
!Local [[hard drive]]s used for OS
|{{No}}
|{{No}}
|{{Yes}}
|{{Yes}}
|-
!Local general-purpose processing used
|{{No}}
|{{Yes}}
|{{Yes}}
|{{Yes}}
|}

==Principles of operation==

The operating system (OS) for a diskless node is loaded from a server, using [[network booting]]. In some cases, removable storage may be used to initiate the bootstrap process, such as a [[USB flash drive]], or other bootable media such as a [[floppy disk]], CD or DVD. However, the [[firmware]] in many modern computers can be configured to locate a server and begin the bootup process automatically, without the need to insert bootable media.

[[File:Carry-i-front-and-rear.jpg|thumb|center|600px|The ''[[Carry-I]]'' book-size LAN station was an early diskless system based on an [[Intel 80286]] processor and produced by Taiwan's [[Flytech Technology]] circa 1991.]]

For network auto-booting, the [[Preboot Execution Environment]] (PXE) or [[Bootstrap Protocol]] (BOOTP) network protocols are commonly used to find a server with files for booting the device. Standard full-size desktop PCs are able to be network-booted in this manner with an add-on network card that includes a [[Preboot Execution Environment|Universal Network Device Interface]] boot ROM. Diskless network booting is commonly a built-in feature of desktop and laptop PCs intended for business use, since it can be used on an otherwise disk-booted standard desktop computer to remotely run diagnostics, to install software, or to apply a [[disk image]] to the local hard drive.

After the bootstrapping process has been initiated, as described above, bootstrapping will take place according to one of three main approaches.

*In the first approach (used, for example, by the [[Linux Terminal Server Project]]), the [[kernel (operating system)|kernel]] is loaded into memory and then the rest of the operating system is accessed via a [[Clustered file system|network filesystem]] connection to the server. (A small [[RAM drive|RAM disk]] may be created to store temporary files locally.) This approach is sometimes called the "[[Network File System|NFS]] root" technique when used with Linux or Unix client operating systems.
*In the second approach, the kernel of the OS is loaded, and part of the system's memory is configured as a large RAM disk, and then the remainder of the OS image is fetched and loaded into the RAM disk. This is the implementation that [[Microsoft]] has chosen for its [[Windows XP Embedded]] remote boot feature.<ref name="microsoft">{{cite web|url=http://msdn2.microsoft.com/en-us/embedded/aa731381.aspx|title=Remote Boot Feature Overview|website=Windows Embedded Developer Center|archive-url=https://web.archive.org/web/20080423084418/http://msdn2.microsoft.com/en-us/embedded/aa731381.aspx|archive-date=2008-04-23}}</ref>
*In the third approach, disk operations are virtualized and are actually translated into a network protocol. The data that is usually stored in a disk drive are then stored in virtual disks files homed on a server. The disk operations such as requests to read/write disk sectors are translated into corresponding network requests and processed by a service or daemon running on the server side. This is the implementation that is used by [[Neoware]] Image Manager, Ardence, VHD Central Management System<ref name="vhdsoft">{{cite web|url=http://www.vhdsoft.com/index.php?menu_id=0&submenu_id=0|title=VHD Central Management System|website=Xtreaming Technology Inc.|access-date=2014-03-22|archive-url=https://web.archive.org/web/20140323032852/http://www.vhdsoft.com/index.php?menu_id=0&submenu_id=0|archive-date=2014-03-23}}</ref> and various "boot over iSCSI" products. This third approach differs from the first approach because what is remote is not a [[file system]] but actually a disk device (or [[raw device]]) and that the client OS is not aware that it is not running off a hard disk. This is why this approach is sometimes named "[[VHD (file format)|Virtual Hard Disk]]" or "Network Virtual Disk".

<div style="margin-left: 16pt">
This third approach makes it easier to use client OS than having a complete disk image in RAM or using a read-only file system. In this approach, the system uses some "write cache" that stores every data that a diskless node has written. This write cache is usually a file, stored on a server (or on the client storage if any). It can also be a portion of the client RAM. This write cache can be persistent or volatile. When volatile, all the data that has been written by a specific client to the virtual disk are dismissed when said client is rebooted, and yet, user data can remain persistent if recorded in user (roaming) profiles or home folders (that are stored on remote servers). The two major commercial products (the one from [[Hewlett-Packard]], and the other one from [[Citrix Systems]]) that allow the deployment of Diskless Nodes that can boot [[Microsoft Windows]] or [[Linux]] client OS use such write caches. The Citrix product cannot use persistent write cache, but VHD and HP product can.
</div>

== Diskless Windows nodes ==

Windows 3.x and Windows 95 OSR1<ref name="microsoft2">{{cite web|url=http://www.microsoft.com/technet/archive/win95/rk04_svr.mspx|title=Windows 95: Server-Based Setup for Windows 95|website=[[Microsoft TechNet]]|archive-url=https://web.archive.org/web/20061124173505fw_/http://www.microsoft.com/technet/archive/win95/rk04_svr.mspx|archive-date=2006-11-24}}</ref> supported Remote Boot operations, from [[NetWare]] servers,<ref name="H17007Index">{{cite web|url=http://h17007.www1.hp.com/us/en/networking/index.aspx#.Uy33Sn18hpg|title=HP Networking: switches, routers, wired, wireless, HP TippingPoint Security – HP®|publisher=h17007.www1.hp.com|access-date=22 March 2014|archive-url=https://web.archive.org/web/20140322120942/http://h17007.www1.hp.com/us/en/networking/index.aspx#.Uy19mS-l1c8|archive-date=22 March 2014}}</ref>{{failed verification|date=May 2022}} [[Microsoft Windows|Windows]] NT Servers<ref name="microsoft3">{{cite web|url=http://support.microsoft.com/kb/158278|title=Explanation of How Windows NT Server 4.0 Remoteboot Works|publisher=support.microsoft.com|access-date=2014-03-22|archive-url=https://web.archive.org/web/20140323014635/http://support.microsoft.com/kb/158278|archive-date=2014-03-23}}</ref> and even DEC [[Pathworks]] servers.<ref name="microsoft4">{{cite web|url=http://support.microsoft.com/kb/82654|title=DEC Pathworks Remote Boot Workstations Under Windows 3.1|publisher=support.microsoft.com|access-date=2014-03-22|archive-url=https://web.archive.org/web/20140323002413/http://support.microsoft.com/kb/82654|archive-date=2014-03-23}}</ref>

Third party software vendors such as Qualystem (acquired by [[Neoware]]), LanWorks (acquired by [[3Com]]), Ardence (acquired by [[Citrix Systems]]), APCT<ref name="apct">{{cite web|url=http://www.apct.net/en/pd_absolutboot.html|title=AbsolutBoot|website=APCT - Advanced PC Technologies|archive-url=https://web.archive.org/web/20010222055859/http://www.apct.net/en/pd_absolutboot.html|archive-date=2001-02-22}}</ref> and Xtreamining Technology<ref name="vhdsoft"/> have developed and marketed software products aimed to remote-boot newer versions of the [[Microsoft Windows|Windows]] product line: Windows 95 OSR2 and Windows 98 were supported by Qualystem and Lanworks, Windows NT was supported by APCT and Ardence (called VenturCom at that time), and Windows 2000/XP/2003/Vista/Windows 7 are supported by [[Hewlett-Packard]] (which acquired [[Neoware]] which had previously acquired Qualystem) and Citrix Systems (which acquired [[Ardence]]).

==Comparison with rich clients==

===Software installation and maintenance===

With essentially a single OS image for an array of machines (with perhaps some customizations for differences in hardware configurations among the nodes), installing software and maintaining installed software can be more efficient. Furthermore, any [[system change]]s made during operation (due to user action, worms, viruses, etc.) can be either wiped out when the power is removed (if the image is copied to a local RAM disk) such as Windows XP Embedded remote boot<ref name="microsoft5">{{cite web|url=http://msdn.microsoft.com/en-us/library/ms838569.aspx|title=Deploying Windows XP Embedded Remote Boot|first=Mark|last=Chamberlain|date=February 2004|website=[[Microsoft Developer Network]]|archive-url=https://web.archive.org/web/20120515201115/http://msdn.microsoft.com/en-us/library/ms838569.aspx|archive-date=2012-05-15}}</ref><ref name="microsoft6">{{cite web|url=http://msdn.microsoft.com/en-us/library/ms838543.aspx|title=RAM Boot Using SDI in Windows XP Embedded with Service Pack 1|first=Saad|last=Syed|date=November 2002|website=[[Microsoft Developer Network]]|archive-url=https://web.archive.org/web/20121013174724/http://msdn.microsoft.com/en-us/library/ms838543.aspx|archive-date=2012-10-13}}</ref> or prohibited entirely (if the image is a network filesystem). This allows use in public access areas (such as [[libraries]]) or in schools etc., where users might wish to experiment or attempt to "hack" the system.

However, it is not necessary to implement network booting to achieve either of the above advantages - ordinary [[personal computer|PCs]] (with the help of appropriate software) can be configured to download and reinstall their operating systems on (e.g.) a nightly basis, with extra work compared to using shared disk image that diskless nodes boot off.

Modern diskless nodes can share the very same disk image, using a 1:N relationship (1 disk image used simultaneously by N diskless nodes). This makes it very easy to install and maintain software applications: The administrator needs to install or maintain the application only once, and the clients can get the new application as soon as they boot off the updated image. Disk image sharing is made possible because they use the write cache: No client competes for any writing in a shared disk image, because each client writes to its own cache.

All the modern diskless nodes systems can also use a 1:1 Client-to-DiskImage relationship, where one client "owns" one disk image and writes directly into said disk image. No write cache is used then.

Making a modification in a shared disk image is usually made this way:

#The administrator makes a copy of the shared disk image that he/she wants to update (this can be done easily because the disk image file is opened only for reading)
#The administrator boots a diskless node in 1:1 mode (unshared mode) from the copy of the disk image he/she just made
#The administrator makes any modification to the disk image (for instance install a new software application, apply patches or hotfixes)
#The administrator shutdowns the diskless node that was using the disk image in 1:1 mode
#The administrator shares the modified disk image
#The diskless nodes use the shared disk image (1:N) as soon as they are rebooted.

===Centralized storage===

The use of central disk storage also makes more efficient use of disk storage. This can cut storage costs, freeing up capital to [[investment|invest]] in more reliable, modern storage technologies, such as [[RAID|RAID array]]s which support redundant operation, and [[storage area network]]s which allow hot-adding of storage without any interruption. Further, it means that losses of disk drives to mechanical or electrical failure—which are statistically highly probable events over a timeframe of years, with a large number of disks involved—are often both less likely to happen (because there are typically fewer disk drives that can fail) and less likely to cause interruption (because they would likely be part of RAID arrays). This also means that the nodes ''themselves'' are less likely to have hardware failures than [[rich client]]s.

Diskless nodes share these advantages with [[thin client]]s.

====Performance of centralized storage====

However, this storage efficiency can come at a price. As often happens in computing, increased storage efficiency sometimes comes at the price of decreased performance.

Large numbers of nodes making demands on the same server simultaneously can slow down everyone's experience. However, this can be mitigated by installing large amounts of [[random-access memory|RAM]] on the server (which speeds up read operations by improving [[Cache (computing)|caching]] performance), by adding more servers (which distributes the I/O workload), or by adding more disks to a RAID array (which distributes the ''physical'' I/O workload). In any case this is also a problem which can affect ''any'' client-server network to some extent, since, of course, rich clients also use servers to store user data.

Indeed, user data may be much more significant in size and may be accessed far more frequently than operating systems and programs in some environments, so moving to a diskless model will not ''necessarily'' cause a noticeable degradation in performance.

Greater [[network bandwidth]] (i.e. capacity) will also be used in a diskless model, compared to a rich client model. This does not necessarily mean that a higher capacity network infrastructure will need to be installed—it could simply mean that a higher proportion of the existing network capacity will be used.

Finally, the combination of network data transfer [[latency (engineering)|latencies]] (physically transferring the data over the network) and contention latencies (waiting for the server to process other nodes' requests before yours) can lead to an unacceptable degradation in performance compared to using local drives, depending on the nature of the application and the capacity of the network infrastructure and the server.

===Other advantages===

Another example of a situation where a diskless node would be useful is in a possibly hazardous environment where computers are likely to be damaged or destroyed, thus making the need for inexpensive nodes, and minimal hardware a benefit. Again, thin clients can also be used here.

Diskless machines may also consume little power and make little noise, which implies potential [[Environmentally friendly|environmental benefits]] and makes them ideal for some [[computer cluster]] applications.

==Comparison with thin clients==

Both thin client and diskless node architectures employ diskless clients which have advantages over rich clients (see above), but differ with regard to the location of processing.

===Advantages of diskless nodes over thin clients===
*'''Distributed load''' The ''processing'' load of diskless nodes is distributed. Each user gets its own processing isolated environment, barely affecting other users in the network, as long as their workload is not filesystem-intensive. Thin clients rely on the central server for the processing and thus require a fast server. When the central server is busy and slow, both kinds of clients will be affected, but thin clients will be slowed completely, whereas diskless nodes will only be slowed when accessing data on the server.
*'''Better multimedia performance'''. Diskless nodes have advantages over thin clients in [[multimedia]]-rich applications that would be bandwidth intensive if fully served. For example, diskless nodes are well suited for [[video gaming]] because the rendering is local, lowering the latency.
*'''Peripheral support''' Diskless nodes are typically ordinary personal computers or [[workstation]]s with no hard drives supplied, which means the usual large variety of [[peripheral]]s can be added. By contrast, thin clients are typically very small, sealed boxes with no possibility for internal expansion, and limited or non-existent possibility for external expansion. Even if e.g. a [[USB]] device can be ''physically'' attached to a thin client, the thin client software might not support peripherals beyond the basic input and output devices - for example, it may not be compatible with [[graphics tablet]]s, [[digital camera]]s or [[Image scanner|scanner]]s.

===Advantages of thin clients over diskless nodes===
*The '''hardware is cheaper''' on thin clients, since processing requirements on the client are minimal, and [[3D acceleration]] and elaborate audio support are not usually provided. Of course, a diskless node can also be purchased with a cheap CPU and minimal multimedia support, if suitable. Thus, cost savings may be smaller than they first appear for some organizations. However, many large organizations habitually buy hardware with a higher than necessary specification to meet the needs of particular applications and uses, or to ensure [[future proofing]] ''(see next point)''. There are also less "rational" reasons for overspecifying hardware which quite often come into play: departments wastefully using up budgets in order to retain their current budget levels for next year; and uncertainty about the future, or lack of technical knowledge, or lack of care and attention, when choosing PC specifications. Taking all these factors into account, thin clients may bring the most substantial savings, as only the servers are likely to be substantially "gold-plated" and/or "future-proofed" in the thin client model.
*'''Future proofing''' is not much of an issue for thin clients, which are likely to remain useful for the entirety of their replacement cycle - one to four years, or even longer - as the burden is on the servers. There are issues when it comes to diskless nodes, as the processing load is potentially much higher, thus meaning more consideration is required when purchasing. Thin client networks may require significantly more powerful servers in the future, whereas a diskless nodes network may in future need a server upgrade, a client upgrade, or both.
*Thin client networks have '''less network bandwidth consumption''' potentially, since much data is simply read by the server and processed there, and only transferred to the client in small pieces, as and when needed for display. Also, transferring graphical data to the display is usually more suited for efficient [[data compression]] and optimisation technologies (see e.g. [[NX technology]]) than transferring arbitrary [[computer program|programs]], or user data. In many typical application scenarios, both total bandwidth consumption and "burst" consumption would be expected to be less for an efficient thin client, than for a diskless node.

==See also==
*[[Thin client]]
*[[Network block device]]
*[[Diskless Remote Boot in Linux]]
*[[Preboot Execution Environment]]

==Notes==
<references/>

==References==
*{{cite journal |title=File Servers versus Disk Servers |first=Tim |last=Maroney |volume=3 |issue=4 |url=http://www.mactech.com/articles/mactech/Vol.03/03.04/File,DiskServers |year=1987 |journal=[[MacTech]] |access-date=2007-07-23 |archive-url=https://web.archive.org/web/20060428144123/http://www.mactech.com/articles/mactech/Vol.03/03.04/File,DiskServers/ |archive-date=2006-04-28 |url-status=dead}}
*{{cite thesis|type=License of Science in Technology|publisher=[[Helsinki University of Technology]], department of Electrical Engineering|first=Hannu H.|last=Kari|title=Diskless Workstations in a Local Area Network|date=1989}}
*{{cite conference |last1=Foster |first1=Louis A. |last2=Hughes |first2=Norman L. |title=Proceedings of the twenty-second SIGCSE technical symposium on Computer science education - SIGCSE '91 |date=March 1991 |chapter=Making Files Real With a Virtual Disk |conference=Twenty-second SIGCSE technical symposium on Computer science education |pages=199–204 |chapter-url=http://portal.acm.org/ft_gateway.cfm?id=107039&type=pdf |chapter-format=PDF |doi=10.1145/107004.107039|isbn=0897913779 |doi-access=free }}
*{{cite patent|country=US|number=5146568|pubdate=1992-09-08|title=Remote bootstrapping a node over communication link by initially requesting remote storage access program which emulates local disk to load other programs|assign1=[[Digital Equipment Corporation]]|inventor1-last=Flaherty|inventor1-first=James E.|inventor2-last=Abrahams|inventor2-first=Alan}} 
*{{cite report|url=http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-319.html|title=A Workstation Architecture to Support Multimedia|first=Mark David|last=Hayter|date=November 1993|publisher=Computer Laboratory, University of Cambridge |doi=10.48456/tr-319|id=UCAM-CL-TR-319}}
*{{cite patent|country=US|number=5577210|pubdate=1996-11-19|title=Remote booting of an operating system by a network|assign1=[[Groupe_Bull|Bull S.A.]]|inventor1-last=Abdous|inventor1-first=Arave|inventor2-last=Demortain|inventor2-first=Stephane|inventor3-last=Dalongvile|inventor3-first=Didier}}
*{{cite conference |year=1996 |title=Petal: Distributed Virtual Disks |last=Lee |first=Edward K. |author2=Thekkath, Chandramohan A. |conference=7th International Conference on Architectural Support for Programming Languages and Operating Systems |url=http://thekkath.org/Documents/petal.pdf |access-date=2009-07-21 |archive-date=2011-04-01 |archive-url=https://web.archive.org/web/20110401012138/http://thekkath.org/Documents/petal.pdf |url-status=dead }}
*{{cite report|url=http://www.cl.cam.ac.uk/Research/SRG/netos/plana/danos/final_report.ps|title=Operating systems support for the Desk Area Network|first1=Ian|last1=Leslie|first2=Derek|last2=McAuley|author-link2=Derek McAuley|format=Postscript|date=July 24, 1996|archive-url=https://web.archive.org/web/20031021062607/http://www.cl.cam.ac.uk/Research/SRG/netos/plana/danos/final_report.ps|archive-date=2003-10-21}} 
*{{cite press release|url=http://pressreleasespider.com/feed2885.aspx|title=Management of Diskless Windows 2000 and XP Stations from a Linux Server|date=2004|archive-url=https://web.archive.org/web/20100210173338/http://pressreleasespider.com/feed2885.aspx|archive-date=2010-02-10}}

==External links==
*Network Block Device home page http://nbd.sourceforge.net/

{{Computer sizes}}

{{DEFAULTSORT:Diskless Node}}
[[Category:Diskless workstations| ]]