Network boot system for low-cost laboratory computer

The problem in private universities in the developing country is that they have many computers in the computer laboratory but do not have enough resources to maintain it. The part of the computer that is most frequently damaged is a hard disk drive due to unstable electricity and causes many computers to become inactive due to universities inability to replace it. In this study, we present comprehensive research on reviving existing inactive computers with minimal expenditure. We use a combination of PXE, DHCP, TFTP, and VHD to implement the Network Boot System (NBS). In addition, we conducted simulations to measure the client’s network booting time on HDD and SSD. The simulations were carried out using 15 client PCs booted simultaneously from NBS’s server using two different master images on HDD and SSD. We found that all of the inactive computers could work normally. The use of SSD could increase the performance of NBS significantly. The expenditure cost to use mainstream SSD for an NBS’s server is much lower than having to replace the HDD for the entire inactive computers. Those strengthen that an NBS is feasible to be used on low-cost laboratory computers.


Introduction
Humans have entered the digital era [1] that requires information and communication technology (ICT) in order to accelerate the exchange of information. Progress in the field of information and communication technology (ICT) has led to the rapid development of computer hardware and software [2]. The use of ICT in the educational sector has a positive impact on student's performance [3] and help in achieving national development goals [4]. Economic growth in developing countries also depends heavily on investment in ICT and the number of specialists in the ICT field [5]. However, the problem that hinders the development of ICT in developing countries is not human resources, but physical infrastructure. A poor internet connection and unstable electricity are the major challenges encountered during the use of ICT, especially in the academic world [6]. Unstable electricity will lead to loss of performance in electrical equipment or could cause it to be malfunction [7]. The computer's power supply that continues to receive an unstable electricity source will be over-stressed and in turn damage the computer hardware [8]. The most easily damaged computer hardware from electrical instability is the Hard Disk Drive (HDD). Small private universities in developing countries usually don't have the resources to maintain computers in their lab. Those computers slowly become inactive one by one because of a hardware failure, especially the HDD. The objective of this study is to revive the inactive computers using Network Boot System (NBS) by means of combining the Preboot Execution Environment (PXE), Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP) and Virtual Hard Disk (VHD). We performed the analysis of network boot time to operating system using NBS between 2x 250GB HDD in RAID 0 and 120GB SSD, particularly The computer performance is also measured by the loading speed of Google Chrome. Furthermore, we compared the expenditure between adding mainstream SSD to the NBS server and replacing the HDD of entire inactive computers in the lab.

Network boot system
Network Boot System (NBS) uses three main protocols, namely the Preboot Execution Environment (PXE), Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP) [9]. Furthermore, the boot server, which storing OS images in Virtual Hard Disk (VHD) and boot management software, is also required. During the network boot process, the PXE-enabled client requests the IP Address through PXE and DHCP Server. The network boot server responds by sending the IP Address and boot images options menu. The boot images options show the list of OS images and can be configured to choose automatically or depending on user input. The Network Boot Server sends the image of the selected operating system to the client's Random Access Memory (RAM) by using a TFTP. After all the image data is sent, the client automatically loads the OS as depicted in figure 1.   [10]. PXE based network boot system requires DHCP and TFTP protocol. DHCP serves as a way to provide network configuration to the client, especially the IP Address of the client itself and the TFTP Server. After receiving the network configuration, the client contacts the TFTP server to request the OS images. TFTP responds by sending the small set of complementary files in order to boot a minimalistic OS executive and loads its own network driver. By this time, the remaining instruction to boot the OS is delivered through standard protocols like Hypertext Transfer Protocol (HTTP) or Network File System (NFS), as shown in figure 2. These protocols are small enough to be implemented in the firmware of the client's Network Interface Cards (NIC).

VHD, disk2vhd
and Image Server. Virtual Hard Disk (VHD) is a disk image file format that contains the complete contents of a physical hard disk. This file format is used by Virtual Machine (VM) as hard disk drives [11]. There are two types of VHD, namely dynamically expanding and fixed-size. Dynamically expanding disk only allocates disk space as needed, while fixed-size disk automatically uses all the preconfigured space. The physically installed OS image must be converted into VHD with the help of a tool called disk2vhd and stored in Image Server.

Boot management.
Boot management software is required to manage the interaction and data traffics between the Network Boot Server and PXE-Enabled client. This application could manage multiple master image, monitor the transfer rate between clients and network boot server, upload the OS image to the Image Server and create multiple boot options.

NBS software and hardware setup.
The most important step to build the NBS is the creation of an OS image. Due to many variations of the OSes, the most effective method to create the image is by means of trial and error and the one, which passed the trial and error phase, will be called master image, as depicted in figure 3. Create a beta image starts with physically install the OS on the single intended client computer. The reason the OS must be installed in the client computer is to ensure the OS in configured on that exact client computer and minimize the possibility of problems that will arise later. The next step is to install the network driver on the OS. The last step is to convert the physically installed OS to VHD format. This can be done with the help of a tool called disk2vhd. Figure 4 helps visualize these steps.
The Beta Image that has been prepared must go through a testing phase at the client. The most important test is whether Beta Image can be used on the client. Slighty different hardware configuration in the client is able to make the Beta Image cannot boot on a client. The client's BIOS is configured so that the client boots from PXE and automatically boot from the network boot server. The first phase of the test is the smoothness of the OS loading up to the Desktop page. The most common problem is that the operating system stops loading at the OS logo. This happens because the operating system does not find the client's network card driver and stops the loading process. This problem can be overcome by inserting the client's network driver in Beta Image, upload the newly created beta image to Image Server, synchronize to boot management software and retest the beta image. The second test phase is to install the required drivers and applications to the beta image. Each driver and application in that beta image must be tested in each client to minimize the problems that might occur in the future. The beta image that passes both test phases automatically becomes the Master Image as shown in Figure 5. The Master Image must be given a clear name to distinguish it from the Beta Image. Boot management software cannot distinguish between Beta Image and Master Image, hence file names are very important.   The network topology used in this paper is shown in figure 6.
The network must be configured first in order to work properly. The configuration of the network topology of the NBS is depicted in Table 1. The hardware specification for the Network Boot Server and the Client is shown in Table 2. Our experiment used 15 computers that were inactive due to HDD faults and there was no HDD replacement available. All clients have an exact hardware configuration. The server for NBS uses almost the same configuration as the clients, except in storage media where the server uses two 250GB HDD in RAID 0 mode and a single 120 GB SATA SSD for simulation purposes.

Simulation
During this research, we built two master images, Empty Master Image, and Application Master Image. The Empty Master Image only had a network chip driver installed and had a total size of 26 GB. The Application Master Image had additional drivers installed and graphical design applications, which had a total size of 52 GB. The outline of the experiment is to measure the network boot time of 15 clients simultaneously by using different images and different storage medias. Our boot management software has a menu that displays the length of time the computer is active and data traffic activities. This menu will be our basis for recording boot simulation time. We recorded the boot time until the data traffic below 100KB/second and OS desktop is visible on the clients' monitor, which we assume that OS loading is complete. The application used to measure application loading time was fresh installed Google Chrome on the client. Application loading time recorded with the help of the FreeStopWatch tool. The online stores that we used as a basis for expenditure comparison were jakartanotebook.com and bhinneka.com.

Result and discussion
Ample time must be allocated for the creation of client's OS Image. Slighty different hardware configuration differences in the client are able to make the Beta Image cannot boot on the client. The most recommended way to build the Beta Image is to install the OS on the intended client computer or the computer that has the same system archithecture. During this research, one hour is spent to build the Beta Image and another 24 hours to made it become a master image. The master image was then syncronized with boot management software. After the image is synchronized, the boot management software must be configured to use PXE, DHCP, and TFTP. DHCP range was set to 192.168.2.2 -192.168.2.17 in order to minimize not intended device to receive IP Address from the DHCP server. When all the preparations are complete, a master image boot simulations were performed for 15 clients simultaneously. Pre-simulation was done by seeing whether all clients can enter the OS desktop normally. The first simulation is to compare the client boot time using Empty Master Image stored on HDD RAID 0 and on SSD. The master image used for this first simulation only has a network driver installed and we named it Empty Master Image. The results showed that the use of SSDs for Master Image could increase boot speeds up to 126%. HDD RAID 0 records a boot time of 3 minutes 42 seconds (222 seconds), while SSD records a loading speed of 1 minute 38 seconds (98 seconds) as shown in figure 7.
The second simulation is almost the same as the first, but using the Application Master Image.   The third simulation is to compare the loading speed of Google Chrome on the client between HDD RAID 0 and SSD. We found that HDD RAID 0 recorded a loading speed of 17 seconds, while SSD recorded a loading speed of only 5 seconds or 340% faster than using HDD RAID 0, as depicted in figure 9. The use of SSD will speed up loading at network boot and application loading on NBS.
The price of SSD based storage media is getting cheaper lately. In Indonesia, we could found the price of 120 GB SSD as lower as Rp331.800 or 23.4 US$ [12]. The advantage of SSD like getting cheaper, durable and much faster than HDD, often outweight the disadvantage of the SSD in the storage capacity [13]. The total expenditure for using mainstream SSD as storage media for Master Image in NBS is much less than replacing the HDD/SSD for 15 damaged inactive computer, as depicted in figure 10 [14].    [16] have an alternative algorithm and local smart monitoring system for distributing bandwidth fairly and evenly for internet browsing users. This could useful for maximizing bandwidth usage in network boot for local networks.

Conclusion
In this study, we developed an NBS method to reuse inactive computers due to HDD failure with minimal cost. We conducted a simulation to evaluate the performance of NBS by using 15 PCs that boot simultaneously from the NBS server and record the boot time. These PCs booted using two (2) different Master Images and different storage media on NBS to measure the performance between HDD and SSD on NBS. Our first simulation result indicated that the use of SSD could increase the performance of NBS twice as much as HDD. The second simulation also supports this result, even though it uses a different Master Image. The loading time of the application has the most improvement using SSD because it is three times faster than using an HDD. In addition, the expenditure cost of using mainstream SSD in the NBS server was much lower than replacing HDDs in 15 clients. These findings strengthen that NBS is a feasible solution for low-cost laboratory computers and will serve as a base of future advanced studies about network booting. Furthermore, in our future work, we will evaluate the ability of NBS when integrated with new algorithms and smart monitoring system [15] [16][17] on a large number of the lab computer.