Optimization of the Cloud for Setup of Hardware of Remote Laboratories

—Few years ago, we built our own virtualized cloud for REMLABNET and we still are taking benefits of this decision. This item handles with using Cloud computing platform for providing Remote laboratories. This work shows, how it is possible to save money if we use centralized system for more consumers. Every consumer can use access to centralized portal in the Cloud computing from Consortium REMLABNET. Every item is focused on environments of universities, where this cloud is existing and this is what we want to use for remote labs. This is item from practice knowledge and experiences about system function and managing virtual platform and next construction and optimization this proposal.


Introduction
Education and research of the Science disciplines are rather difficult activities. Teachers, scientist and researchers are confronted with reduced budgets for their work and disinterest of the students. This condition was exacerbated today by the Covid-19 virus pandemic, which kept students out of labs and school space. This makes ill effect predominantly on experimental laboratories, which in return reduces level of Science education. In such situation the major call is to build laboratories at lower expenses. One way out of the situation in last century was building of remote laboratories (RLs), shared by many clients outside formal hands-on laboratories. These laboratories seem to be the most suitable educational tool for teaching natural sciences today. Subsequently it turned out that simple remote experiments have not fulfilled expectations of educators and new forms of remote experiments sophistications stepped in. As examples may serve extensive graphical support for virtual reality (VR) modelling, rich scale of artificial intelligence (AI) outputs, etc.
Very short logical structure for Remote Laboratory (RL) is on Figure 1, where we can see standard laboratory equipment (right), interface for communication with computer or server and video camera. Following is the main communication computer (server), where data from experiment is coded to standard web page and distributed to a client (left).
In our laboratories, hosted in the Faculty of Applied Informatics (FAI), Tomas Bata University in Zlín and Trnava University in Trnava (TU), is greater number of remote laboratories built on Internet School Experimental System (ISES) [2], for example: Electrochemical cell, Energy in RLC, Incline, Electromagnetic induction, Radioactivity, Wave laboratory, described in [3,4,5,6]. All RLs are placed in Remote Laboratory Management System (RLMS) REMLABNET, where they are supervised and monitored for functioning [7]. Some of the mentioned RL are equipped with embedded and synchronized simulations [8]. The block scheme of REMLABNET is depicted in Figure 2 with following parts [9]: • Data Warehouse (DW)is a part of the system for the storage and data analysis.
• Reservation and management serverpart of the content management system (CMS) -generates a service enabling individual remote experiment reservation for a given time period. • Communication server-next part of CMS is a system designed for the transmission of information and real-time communication, interaction and collaboration in teaching and learning process with RE. • Virtualized cloud -Virtualized datacenter (DTC) contains physical and virtual servers which serve a variety of services including web services, file services etc.
On top of this were recently added following servers: • Diagnostic serverof I and II level [10] • Embedded simulations server [11]. Furthermore, the embedded diagnostic which consist of Ist embedded diagnostics and IInd embedded diagnostics are all configured in the Measure server. It contributes significantly to the remote experiment especially, when experiment is running. The embedded diagnostics communicate constantly with the physical ISES modules connected to the ISES control board. The below diagram shows the function and description of the embedded diagnostics in the Measure server [12]. Connection to Go-Lab served for federalization of two RLMS REMLABNET [13] and GO-LAB [14].

Fig. 2.
Idea of the representation of the Remote Laboratory Management System REMLABNET schematically embedded in a virtualized cloud (shaded area) Mind the "federalization" connection to the RLMS Go-Lab also serving to Graasp interface [16] All REMLABNET's components were placed in the cloud of Trnava University in Trnava [15].

Cloud Computing Concept
The last three decades has seen the rise of the DTC computing practically in every application domain. The move to DTC has been powered by two separate trends. In parallel, functionality and data usually associated with personal computing have moved into the DTC; users continuously interact with remote sites while using local computers, while running intrinsically online applications, such as email, chat or manipulating data, traditionally these are stored locally, such as documents, spreadsheets, videos and photos.
In effect, modern architecture is converging towards, virtualization and cloud computing (CC), a paradigm where the whole user activity is funneled into the large DTC via high-speed networks. Simply speaking, CC is a set of computers, services or infrastructure. Delivering services are meant to reduce the work of consumers every day, as well as service providers and IT specialists. CC allows more access to services as it reduces infrastructure delivery time from weeks to hours and it offers reimbursement for provided sources and services only [17].
Main idea of our work and this paper is for clients to use new methods on how to provide RLs. We were first in the world, who provided RLs via CC technology. A new concept of our CC is figured on the Figure 3, where we can see all interesting parts of this idea.
First, we can see main parts of cloud computing. Each cloud is based on three primary services for use [18]: IaaS -Infrastructure as a service is a standard service for providing all infrastructures.
PaaS -Platform as a service is a standard service for providing VMs with operating systems.
SaaS -Software as a service is a standard service for providing SW features for consumers.
Virtualized DTC contains physical and virtual servers, which serve a variety of services including web services, file services, etc. The advantages of DTC are enabling application isolation from malicious or greedy applications to cannot impact other applications co-located on the same physical server. Perhaps the biggest advantage of employing virtualization, is the ability to flexibly remap physical resources to virtual servers in order to handle workload dynamics.
Our other aims are: To construct really stable and dynamically expandable CC for using RLs. To create VMs and linkage for all parts in cloud, is needed to create communication links, virtual network for CC inside, and all needed parts for Cloud Computing concept. The goal of our work is new and acute topic of providing a new service for the consumers -completely functioning "Remote laboratory as a service" (RLaaS) [19].
It is very interesting for all clients of the Remote laboratories, because they can find this cloud concept and every RLs there. For this purpose, we created Consortium named REMLABNET and this is consortium of the three universities: Trnava University in Trnava (Slovakia), Tomas Bata University in Zlin (Czech Republic) and Charles University in Prague (Czech Republic). REMLABNET portal is on domain name or web site www.remlabnet.eu. It is a distance experiment management system for mid and higher-level education which groups some of the e-Laboratory Project experiments -ISES but offers a more rigid platform [20].

Fig. 3. Cloud computing concept in our Remote laboratory area
In Figure 3 is the schematically arrangement of embedded REMLABNET, forming Cloud Computing Remlabnet (CC-R) in blocks. Block 1 (in Figure 3) represents the standard and known functions of REMLBNET containing Remote laboratories, Management and diagnostic service, Scheduling service and Communication services [09]. All these modules are controlled by Unified service portal, enabling access to REMLABNET by clients and administrators. In block 2, there are platform services Computing service interface, Software test, Middleware and Database. There are also modules ensuring the functioning of both REMLABNET and CC-R, Basic resource service (BRS). These are platform DTCs, Servers, Storage devices, Network, Security devices, and Charging management, Service catalog, Order management, Resource scheduling, Monitoring management, Cloud host, Cloud storage, Cloud network, Cloud security and Disaster recovery service.
Two new blocks, called High Security (3) and Big Data (4) were supposed to be an extension of the basic cloud solution REMLABNET forming CC-R. Nowadays, only High Security is in operation. The second Big Data block is under construction. Block High Security (3) contains the most important security components [21], where we define our main processes that require special security protection. Process security in CC-R is in fact the security of the individual RLs. Network security is managed from the University environment, but CC-R also uses the network settings above the University measures. Application data security assures security at the CC-R data level, their storage and individual accesses. Infrastructure security is a component securing the complete RLs CC-R portal, including its physical security. Terminal security is a component that ensures security on a thin client level. Security authentication is the last component ensuring correct and secure access of clients and administrators.

Optimization of the Cloud Computing REMLABNET
The following subchapter deals with the crucial item of alignment of the demands on efficient functioning of embedded application and demands on cloud HW. Let us choice for the problem solving the criterion function of the necessary throughput for ensuring reliable functioning of the application where two variables are latency L ͼ(0,30)ms, and loss of packets PL ͼ(0,2)%, which we knew for REMLABNET from orientation measurements, whereas fixed variables were window size W = 85KB and Δt = 30 s time span of measurement.
From our point of view, these are two variables that maximally affect throughput. Of course, it is possible to use more variables such as number of nodes, mechanisms (algorithms), channel access or codding scheme.  Figure 4) to find optimum of the criteria function for variable quantities latency L and loss of packets with fixed the other.
Let us give practical example of the process of optimization, followed by the final results.
Example in three steps: 1. For our purpose we use following applications: netem -(Network Emulator) was an enhancement of the Linux traffic control facilities that allowed to add delay, packet loss, duplication and more other characteristics to packets outgoing from a selected network interface, iperf -(Internet Performance), a tool for performing network throughput measurements, tc -(Traffic Control), the user-space utility program used to configure the Linux kernel packet scheduler. Setting a 5ms latency on server 1 and packet loss of 0% #tc qdisc replace dev ens32 root netem latency 5ms loss 0% Then I ran the command to check the iperf communication, using the -c switches to specify the IP address, -t to set the scan progress for 30 seconds, and -Z to set the cubic method for TCP communication #iperf -c 10.33.23.201 -t 30 -Z cubic Now, points 5 and 6 were repeated for all values to fill Table 5. That is, the latency values changed between 0, 5, 10, 15, 20, 25, and 30 ms for a loss of 0, 0.25, 0.5, 1, and 2%.
The last point was the release of network interfaces of both servers, where the latency was set by the command: #tc qdisc del dev ens32 root //for server 1 #tc qdisc del dev ens160 root //for server 2 3. Resulting example of CLI record of the optimization procedure is in Figure 5. http://www.i-joe.org The results of the optimization procedure are summarized in Table 1 and in detail in Figures 6 and 7. Table 1 presents the results of the criterion function (1) of the throughput T for variable latency L for three values of the packet loss PL , 0, 0.025, 0.1, 0.25, 0.5, 1, and 2%. In Figure 6 and Figure 7 are corresponding results in graphical form.   Comparing results in Figures 6 and 7, we can see immediately the results in Figure  6 (depicting Throughput T) are more stringent as results in Figure 7 (depicting Number of transferred data), so discussion will be limited to the results of Figure 6.
The above presented results in Figure 6 were important for the choice of predominantly HW of the Cloud system. The optimized quantity, throughput T, is closely related to the quality and price of the CC HW and, on the other hand, it is closely related to the application requirements. As we established by measurements CC REMLABNET required the throughput T=250 Mbps [22] in a wide range of latencies (in Figure 6 depicted by dark brown line), when the DTC with RLs was located in one destination (TBU Zlin). Then, we easily achieved the values of latency L~15ms, achieve with moderate price of HW, allowing for packet loss 0.1% (brown curve in Figure 6). But, taking into consideration the foreseen development of the system, when we suppose extending to the location of several DTCs, which will definitely result in the latency L>18 ms, we have to concentrate on the solution, increasing the throughput T and thus the price. The reasonable solution is, by improving the quality of HW, and thus by increasing the price of HW, to suppress the packet loss % (towards blue curve in Figure 6).

Optimization of Cloud Computing REMLABNET in 3D graph
In major subchapter 3 of this paper Optimization of the Cloud Computing REMLABNET, we carry out alignment REMLABNET requirements with the cloud properties using Latency, Packet loss, Windows size and Transferred data on output quantity throughput. This quantity turned out to be decisive for any API embedded in cloud and using the REMLABNET requirement of throughput T=250 Mbps in a wide range of latencies, at the present state of the network, when the DTC with RLs is located in one destination (TBU Zlin) and CC REMLABNET in different destination (TU Trnava). Communication is among two countries (Czech Republic and Slovakia). We reach the values of latency L>15ms, which is easy to achieve with moderated price of HW, allowing for packet loss 0.1%. The summarizing result of cloud optimization with respect to CC-REMLABNET needs is in Figure 8 depicting 3D view of Throughput T as function of both Latency L and Packet Loss PL (0, 1, 2 %), together with demands of REMLABNET on cloud qualities (blue plane).

Conclusion
Our idea of use of Cloud computing was attested and discussed with experts in this research part. The way of our work is good and have a big progress. We can provide new service, Remote laboratory as a Service (RLaaS) in our cloud system. Our clients are primary teachers, students and brainpower of the Universities and High Schools, but access is possible for all consumers via Internet. This show, how the University network is very overcast for communication and traffic. This claims, that network and all parts of IT structure must be without failure and latency. And be secured too for management and research data protection.
In this paper we showed our idea of constructing Cloud computing system and its optimization. In our case, throughput is primary parameter for optimization of the communication in our cloud solution.
RLs are being seen as the most suitable tool of today for teaching and research of natural sciences. They give big opportunities without the need of travelling to handson laboratories. It depends only on how we try to build them and consequently using them. Our work is oriented to save money in education and research, if everyone builds their own Remote laboratories. We have connected many laboratories from Zlin University, Trnava University, Charles University and other in the world. Our work is in simple terms "Bring Technology to Service!".
Factors like latency (delays), jitter (irregularities in the signal) and error rate (actual mistakes during transmission) can reduce the overall throughput. In our formula T=f(L, PL) (1) we speak about function of Latency and Packet Loss, which have primary impact to throughput. 3D view of Throughput T as function of both Latency L and Packet Loss PL (0, 1, 2 %), together with demands of REMLABNET on cloud qualities is depicted on Figure 8. Both Latency and Packet Loss can be affected by a host of factors including bottlenecks, security attacks, and damaged devices.
Overall, we can recap our knowledge into these points, which says about factors that affect throughput: 1. Transmission medium limitation -Bandwidth (or the theoretical capacity) of a particular transmission medium will limit the throughput over that medium. 2. Enforced limitationis set by the ISP, we met with her mainly at the crossing of interstate lines 3. Network congestion -The degree of congestion on the network will also affect throughput. 4. Latency -Latency / delay is the time it takes for a packet to get from sender to destination. 5. Packet Loss and Errors -This is because bad/lost packets may need to be retransmitted, reducing the average throughput between the devices communicating. 6. Protocol Operation -The protocol used to carry and deliver the packets over a link can also affect the throughput.
The throughput on a network can be improved once the cause of low/reduced throughput has been identified as listed under the "Factors that affect Throughput": • Bandwidth can be increased to provide more throughput especially in cases where the network is overloaded. • Bottlenecks should be identified and removed from the network.
• Faulty devices or components should be replaced and overburdened devices should be upgraded. • Quality of Service (QoS) can be applied to ensure that critical communication is unaffected by network congestion.

8 Authors
Pavel Beňo is currently working at Trnava University, has a Ph.D. from the Faculty of Applied Informatics in Tomas Bata University in Zlín, Czech Republic, in the field of remote laboratories. He is a research assistant and creator of the cloud computing technology for university and REMLABNET purposes. He is also an expert in network security and penetration testing in computer crime. He is the author of many publications in the field of informatics and security. For many years he has worked as a teacher with research in pedagogy and didactics of the sciences. Sandra Šprinková is currently studying for her bachelor's degree in the Pedagogical Faculty of Trnava University in the field of Mathematics and English. She is working on the creation of a mathematical model for virtual laboratories, that will be used in schools for better teaching in sciences. sandra.sprinkova@tvu.sk Tomas Komenda is PhD student with the Tomas Bata University in Zlín, Faculty of Applied Informatics, Czech Republic, and he is working in Seznam CZ company. KomendaTomas@seznam.cz