Page 48 - Kaleidoscope Academic Conference Proceedings 2021

5.2 Virtual file system over FaaS

To enable a multi-tenant IoT infrastructure, the
I/Ocloud paradigm [21] aims at stretching the cloud
Infrastructure-as-a-Service (IaaS) paradigm by adapting
the cloud-enabled functionalities to the IoT infrastructure.
Figure 5 – A Node-RED flow based on a Qinling function.
Of course, choosing between the deviceless computing
paradigm and the I/Ocloud depends on the developer’s
needs. The I/Ocloud approach provides full control
over the IoT deployments and even low-level access to
the sensors/actuators. Specifically, the solution provides
cloud-based abstracted instances representing physical IoT
nodes and their hosted sensors/actuators. The IoT nodes
abstraction consists of providing accessible Virtual Nodes
(VNs) with attached (virtual) I/O resources (see Figure 7)
virtualized through the file system. Technically, a VN is a
self-contained and isolated environment (i.e., a container)
with a mounted Virtual file system (VFS). The VN can be
Figure 6 – Graph and gauge generated by the Qinling
seen then as a physical IoT node able to host a user-defined
functions.
business logic and provide, at the same time, interactions
with remote physical I/O resources. The filesystem-level
associates them with the functions (see Figure 4).
abstraction and syscall trapping are based on the Filesystem
3. The user, using the extended Node-RED version (that in USErspace (FUSE11) software interface and the S4T
has the new nodes based on Qinling), can design his/her IoT-oriented FaaS capabilities. Within this view, recent
customized workflow among distributed IoT nodes and efforts are in progress to promote the use of the FaaS
the cloud-based instances as well. paradigm to cope with shared file systems’ access [22].

4. Once the user runs his/her flow using Node-RED
Figure 8 depicts a layered architecture of the virtualization
GUI, Qinling, together with Zun and IoTronic, takes approach. As shown in the figure, bottom-up, we have
the responsibility of instantiating the functions and sensors and actuators, in the case of a physical IoT device
executing them when required according to the (left node), whereas on the right, a compute node belonging
applications’ logic. to a cloud data center is depicted, featuring no directly
To highlight a use case of our approach, we created a attached transducers. In the IoT node, on top of the
simple flow that makes use of Qinling to monitor the Central Linux-based Operating System (OS), we have the sysfs-based
interface that enables I/O operations with the physical pins.
Processing Unit (CPU) usage of an edge IoT node. In Figure 5,
To fully virtualize and reproduce the corresponding IoT
the flow that uses a Qinling-based Node-RED function is
node on the cloud side, the General-Purpose Input/Output
shown. In particular, the flow is meant to report the CPU
(GPIO) pseudo-file system (sysfs) of the IoT node has to be
usage on a Raspberry Pi every one second. A Node-RED
supplemented by a comprehensive clone of the user-space
Timing node is used to trigger the function deployed on the
setup. This clone of the pseudo-file system is generated
board (the node is named Qinling-node in the figure) to report
by FUSE that uses, underneath, Qinling functions to enable
the CPU percentage usage. Afterwards, the value received FS
over
remote interactions with the physical resources. Wrapping
is sent to a formatter in order to create a 10 minutes history FaaS
up, the red dashed arrows highlight the final result in terms
Function 5
CPU usage graph and a gauge showing the last value received
Function 4
Function 6
(see Figure 6). We mention here that the Node-RED flow is
Function 2
Function 3
11 https://github.com/libfuse/libfuse
conceived on a cloud-based VM and not the IoT node itself
(unlike OpenWhisk Light, see Section 2) Virtual node Virtual node (1) Virtual node (2) Virtual node
Application
Application Application Application
I/Ocloud Virtual
Container Engine/Hypervisor
Virtual datacenter disk VN I/O Container Engine/Hypervisor Container Engine/Hypervisor
disk operations
FS
Virtual over Virtual I/O sysfs Virtual I/O sysfs Virtual I/O sysfs
network VN 2 FaaS
VN 1 I/O
FaaS Engine
I/O Hypervisor I/O Hypervisor
Virtual Virtual
Virtual Virtual resource resource resource Function
resource resource Function Function I/O
operations
VN
I/O Hypervisor
File System
GPIO sysfs
IoT node 1 IoT node 2
OS Linux-based OS
IoT node Linux-based OS
IoT IoT ... IoT IoT IoT . . . IoT VN IoT node IoT node
S
resource resource resource resource resource resource migration S A Cloud Compute node
IoT node
A S S
Figure 7 – I/Ocloud virtualization approach. Figure 8 – I/Ocloud file system virtualization over FaaS.
– xliv –
Virtual Node Virtual Node
Application Application
Container Engine/Hypervisor
Virtual I/O sysfs Virtual I/O sysfs
FaaSFS
I/O Hypervisor
Redis-fs
Redis
Arancino OS Function Function Function
IoT node
S A S
File System
Linux-based OS
S A S