KR20200052399A - Fog computing method with blockchain-based idle resoure sharing - Google Patents

Abstract

A fog computing method is performed in a fog computing system including a user terminal, and a fog node and a fog tracker positioned between the user terminal and a cloud. The fog computing method converts an application developed by using an object-oriented programming in the user terminal into a fog application composed of a plurality of subtasks, searches for target nodes for executing the subtasks among fog nodes in the fog tracker, generates fog application pieces by packaging the subtasks to correspond to the target nodes, respectively distributes the fog application pieces to the target nodes, and executes the subtasks in the target nodes. The fog tracker includes resource information of each of the fog nodes.

Description

FOG COMPUTING METHOD WITH BLOCKCHAIN-BASED IDLE RESOURE SHARING through blockchain-based idle computing resource sharing

The present invention relates to a fog computing method, and more particularly, to a fog computing method supporting an ultra low-latency application by utilizing surrounding idle computing resources and storage resources.

As IoT technology and industry are activated, many large and small devices are connected to the Internet, and by 2020, at least 50 billion devices are expected to be connected to the Internet. IoT applications require real-time responsiveness and low latency while transmitting and receiving information to and from multiple geographically dispersed devices, and operate on various platforms.

Processing massive IoT applications and data in a traditional centralized cloud environment creates latency problems, and it also introduces a huge amount of raw data into the network core and data center, which is a big problem for operators and service providers. It causes cost problems. In order to solve this problem, the concept of fog computing was proposed.

Fog computing was first proposed by Cisco, which means a new computing paradigm that supports efficient processing of data by creating a fog layer between the cloud and the end point. Fog computing is a concept that extends the cloud computing paradigm to the network edge, similar to cloud computing in that it provides users with data, computing, storage, and application services, but is closer to user applications and devices than cloud computing. (Proximity). The fog layer has a structure that works by utilizing the existing infrastructure that has already been established and idle local resources around the user.

Using a distributed method rather than a centralized method, it finds and manages the surrounding idle computing and storage resources around the world, and uses them to create a fog computing platform, fog storage, fog programming interface, optimization algorithm, and orchestration technology, There is no concrete system that implements fog incentive models.

The present invention has been proposed to solve this conventional problem, and provides a platform (that is, a fog operating system) capable of developing and executing computing and storage applications utilizing idle computing and storage resources around the world, thereby improving application response speed. It is intended to provide a fog computing system and a fog computing method that can be improved.

In addition, the present invention is to provide a fog computing system and a fog computing method that provides a blockchain-based incentive to a resource provider in an application utilizing a computing and storage function in order to allow idle computing resources to be actively introduced into the system. .

To achieve the above object, a fog computing method according to an embodiment of the present invention includes a user terminal, and a fog node and a fog tracker located between the user terminal and the cloud. Is performed in a fog computing system. The fog computing method includes converting an application developed by object-oriented programming in the user terminal into a fog application composed of a plurality of subtasks; Retrieving target nodes to perform the sub-tasks among the fog nodes in the fog tracker; Packaging the sub-tasks corresponding to the target nodes to generate fog application pieces; Distributing the fog application pieces to the target nodes, respectively; And executing the sub-tasks on the target nodes. Here, the fog tracker includes resource information of each of the fog nodes.

In addition, the fog nodes are classified into a plurality of fog clusters based on latency, and searching for the target nodes includes searching for a fog cluster closest to the user terminal among the fog clusters. To do; And searching for the target nodes in the searched fog cluster.

In addition, the application includes a plurality of objects (objects), and converting the application to the fog application comprises: decomposing the objects into the sub-tasks; And converting communication using variables and functions between the objects into message passing between the fog nodes.

In addition, the fog computing method further includes registering resource information of each of the fog nodes to the fog tracker before converting the application to the fog applications, and the resource information includes the fog node. Each of them includes resource information, latency information, operating system information, and platform information, and the target nodes can be searched based on the resource information.

Further, the packaging of the fog applications may include: when the target nodes provide a docker environment in which the fog application is executed, packaging the subtasks as a dock image; And when the target nodes do not provide the docker environment, cross compiling the subtasks.

The fog computing method further includes scaling out a first sub-task among the sub-tasks, and scaling out the first sub-task includes the first of the fog nodes through the fog tracker. Searching for an idle node corresponding to the sub-task; Adding the idle node to node information for the first sub-task; And modifying routing information of a second subtask that delivers a message to the first subtask based on the idle node.

The fog computing method may further include searching for a third target node through a second target node that is a parent node of the first target node when a failure occurs in the first target node among the target nodes.

To achieve the above object, a fog computing method according to an embodiment of the present invention includes a user terminal, and a fog node and a fog tracker located between the user terminal and the cloud. Is performed in a fog computing system. The fog computing method includes: encoding a file by dividing a file into a plurality of file fragments in the user terminal; Searching for target nodes to store the file fragments among the fog nodes through the fog tracker; Distributing and storing the file fragments to the target nodes, respectively; Selecting target nodes having the fastest response speed among the target nodes; And collecting and decoding the pieces of the file from the target nodes.

The fog computing system and the fog computing method according to embodiments of the present invention provide a fast response speed to a user application by placing a cloud-based server application close to the user application, and a user application that uses a lot of computing resources is closer to the user It can improve application execution speed and reduce battery usage by distributing and executing it in the surrounding idle resources.

In addition, the fog computing system and the fog computing method provide a faster response speed compared to a cloud-based storage system by storing data in idle storage resources located around the node, and store and distribute one file to multiple nodes It provides a fault-tolerance that allows you to get a complete file even if only a part of a file fragment is present, and may not be dependent on one storage service provider by distributing and storing data among multiple nodes.

Furthermore, the fog computing system and the fog computing method provide blockchain-based micro-miniature incentives by sharing resources to systems and other applications that can manage, track, and search idle computing and storage resources around the world in a decentralized form. By providing a system that is provided, it is possible to utilize idle computing and storage resources around the world.

1 is a block diagram illustrating a fog computing system according to embodiments of the present invention.
FIG. 2 is a diagram illustrating a logical overview of the fog computing system of FIG. 1.
3 is a block diagram illustrating an example of a fog included in the fog computing system of FIG. 1.
FIG. 4 is a diagram illustrating a process of distributing and storing files in the fog computing system of FIG. 1.
5A is a diagram illustrating a process of converting an application into a fog application in the fog computing system of FIG. 1.
FIG. 5B is a diagram illustrating a process of distributing fog applications in the fog computing system of FIG. 1.
6 is a diagram illustrating an example of a fog application.
FIG. 7 is a diagram illustrating a process of scaling out a fog application in the fog computing system of FIG. 1.
8 is a diagram illustrating a process of solving an application problem in the fog computing system of FIG. 1.
9A, 9C, 10A, and 10B are diagrams illustrating a development process of a fog application.
11 is a diagram illustrating an example of a clustering algorithm of a fog tracker included in the fog computing system of FIG. 1.
12A and 12B are diagrams illustrating delay times of fog nodes included in the fog computing system of FIG. 1.
13 is a block diagram illustrating a blockchain-based fog incentive model according to embodiments of the present invention.
14 is a block diagram illustrating an example of the fog incentive model of FIG. 13.
15A is a block diagram illustrating a fog storage system according to embodiments of the present invention.
15B is a diagram illustrating an example of metadata used in the fog storage system of FIG. 15A.
16 is a flowchart illustrating a fog computing method according to an embodiment of the present invention.
17 is a flowchart illustrating a fog computing method according to another embodiment of the present invention.

1 is a block diagram illustrating a fog computing system according to embodiments of the present invention. FIG. 2 is a diagram illustrating a logical overview of the fog computing system of FIG. 1.

Referring first to FIG. 1, the fog computing system 100 (or the fog computing framework, fog computing architecture, and fog operating system) includes a user terminal 110, a fog 120, and a cloud 130. The user terminal 110, the fog 120, and the cloud 130 may be interconnected through a wired or wireless network.

The user terminal 110 may be located at the lowest layer of the fog computing system 100.

The fog 120 is located in the middle layer of the fog computing system 100, and the fog 120 includes a plurality of fogs 120a and 120b (or fog clusters), and the fog nodes 121-1 To 121-N) (wherein N is an integer of 2 or more). The fog nodes 121-1 to 121-N include an edge device, an access point, a gateway, a small server, and the like, and may be located adjacent to a network edge. The fog nodes 121-1 to 121-N may have sufficient resources to process, analyze, and store data. Meanwhile, the fog nodes 121-1 to 121 -N may remove unnecessary data portions and transmit only meaningful data to the cloud 130.

In addition, the fog 120 may include a fog tracker 122. The fog tracker 122 may manage idle resource information of the fog nodes 121-1 to 121 -N. The fog tracker 122 may store and store idle resource information by distributing it with other fog trackers in the fog computing system 100 using blockchain technology. The fog tracker 122 may be a blockchain node.

The cloud 130 is located at the top layer of the fog computing system 100 and can permanently store data and analyze global data.

The fog computing system 100 may utilize idle computing and storage resources that are not used, that is, not owned by the user terminal 100 as a fog node. Since the fog nodes 121-1 to 121-N are located closer to the user terminal 110 than the cloud 130, they may have more interactive and more responsive characteristics. .

1. Computation offloading from user terminal 110 to fog 120

The application (or client application) of the user terminal 110 needs to distribute the load of the application by using the idle computing of the fog node 121, or it is necessary to store data by using the idle storage of the fog node 121 If there is, the fog agent can be operated by distributing the application to the surrounding fog node (121). Here, the fog agent may be an agent that is located or installed in the user terminal 110 or the like, and offloads the application to the fog nodes 121.

First, the fog agent installed in the user terminal 110 of the fog nodes (121-1 to 121-N) around the fog agent (or user terminal 110) through the fog tracker 122, which is a blockchain node. You can check the information of idle resources.

2. Moving from the cloud 130 to the fog 121 (migration)

The server application is mainly located in the cloud 130 and operates. However, when the physical distance between the user terminal 110 and the cloud 130 is far, the response speed of a service provided through a server application may be slowed down. Accordingly, the fog computing system 100 may migrate at least a part (or some pieces) of the server application to the fog node 121 positioned closest to the user terminal 110. In this case, the user terminal 110 may communicate with the server application deployed in the fog node 121 located relatively close, instead of communicating with the server application operating in the cloud located relatively far.

Referring to FIG. 2, the fog computing system 100 (or a fog operating system) may be divided into a physical layer, a fog layer, and a fog application.

The physical layer may refer to actual physical devices. By operating a fog agent on physical devices, the physical devices can act as fog nodes. The physical equipment (or the user terminal 110) computes and utilizes surrounding fog resources (eg, idle resources of the first to fourth fog nodes 121-1 to 121-4). Storage services are available. That is, physical devices can build a fog layer.

Fog nodes (for example, first to fourth fog nodes 121-1 to 121-4) in which fog agents are installed, their resource information and the like are based on a blockchain (BC) -based fog tracker 122 (or , Fog tracker service provided through the fog tracker 122a. Through the fog tracker 122a, any fog node located in the world is located close to itself and satisfies the needs of the user. As will be described later, a blockchain-based incentive may be provided to nodes that provide resources for active participation of the fog nodes.

The fog application layer refers to a layer of applications operating in fog nodes. A fog application can span multiple fog nodes, and can also span multiple fog clusters. For example, the first fog application APP1 includes the first to fourth fog application pieces APP_F1 to APP_F4, which are connected to the first to fourth fog nodes 121-1 to 121-4. Can exist. For example, the second fog application APP2 exists across the first and second fog clusters 120a and 120b, and the third fog application APP3 includes the second and second fog clusters 120b and 120c. ).

3 is a block diagram illustrating an example of a fog included in the fog computing system of FIG. 1.

Referring to FIG. 3, the fog 120 (or the fog operating system) may include a computing unit 310, a storage unit, a networking unit, and a blockchain unit 320.

The computing unit 310 may mainly perform a function of a fog computing framework (or operation offloading). The computing unit 310 includes a resource manager 311, a task manager 312, a container manager 314, and a binary It may include a manager 315 and a virtualizer 316.

The resource manager 311 may monitor the resources of the fog node (and user terminal). The task manager 312 manages a processing state of a job (eg, a subtask constituting a fog application) assigned to a fog node, and can control execution and termination of the job. The container manager 314 and the binary manager 315 package a piece of the fog application constituting the fog application to be executable in a corresponding fog node in the process of converting the application to a fog application, for example, the container manager 314 Is packaged as a docker image of a docker, and the binary manager 315 can perform cross compile. The virtualizer 316 can provide a virtual environment that can independently execute fog applications and the like.

Although not shown, the computing unit 310 orchestrations a virtualized fog node manager managing a virtualized fog node, an application manager managing a fog application and its execution state, and fog applications. ) May further include an orchestrator.

The storage unit performs a function of fog storage (ie, distributed data storage) and may be configured as a store manager 313. The networking unit may perform a network communication function.

The block chain unit 320 may provide a function of fog tracker, idle fog computing around the world, and store, manage, and search information of storage resources. The block chain unit 320 stores the resource store 321 that stores / manages idle resource information of the fog nodes, the metadata store 322 that stores / manages metadata representing management information of the fog nodes, and identification information of the fog nodes. It may include a naming store 323 for setting / storing / managing, and a key value store 324 for storing / managing keys (or key values) used for data encryption.

FIG. 4 is a diagram illustrating a process of distributing and storing files in the fog computing system of FIG. 1.

4, the encoding unit of the fog storage manager 410 (Encoding) is a single file stored in a physical volume (physical volume) of the host (for example, the user terminal 110) into a plurality of file fragments You can cut and encode each of multiple file fragments.

In order to store encoded file shares in fog nodes, the host sends the fog tracker 122 peripheral idle storage resource information (eg, fog nodes 121-1 to 121-3). (Idle storage resource information). Upon receiving the surrounding idle storage resource information from the fog tracker 122, the host may distribute the encoded file fragments to corresponding fog nodes, and the fog nodes may store the encoded file fragments. The relationship information between the encoded file fragments and fog nodes (eg, information that a specific encoded file fragment is stored in a specific fog node) exists in the form of metadata, and the metadata is a public key. key), and the encrypted metadata may be stored in a blockchain (eg, fog tracker 122), a cloud, or a local system (eg, user terminal 110). The user terminal 110 can find a single file by collecting fragments of files stored at any time.

File fragments may be stored only in the fog nodes 121, but are not limited thereto. If necessary, synchronize with the fog nodes 121 and the cloud storage system (i.e., a storage system of the cloud 130, which is a relatively stable and large-capacity storage system), and the file fragments are stored in the cloud storage system. It may be. That is, the user terminal 110 quickly stores the file in the fog nodes 121 located adjacent to the user terminal 110 with low latency, and has a network bandwidth greater than that of the user terminal 110. ), Fog nodes 121 having an excellent environment such as a battery may synchronize file fragments with cloud storage.

5A is a diagram illustrating a process of converting an application into a fog application in the fog computing system of FIG. 1. The conversion of the application to fog applications can be performed automatically and / or manually.

Referring first to FIG. 5A, in order for an application to be converted into fog applications, an application (or legacy application) must be developed or generated through object-oriented programming. In this case, one object included in the application may be one subtask in the fog application.

The user terminal 110 may decompose the objects included in the application into subtasks (eg, SubTask A / B / C). On the other hand, the user terminal 110 may configure or convert communication using variables and functions between objects in an application in the form of message passing on the network (message passing between fog nodes). . Accordingly, an application that can operate only in one fog node can be turned into a plurality of subtasks that can communicate through message passing on the network.

Subsequently, the user terminal 110 may package the subtasks in a form that can be distributed and operated in fog nodes. For example, if a target node (i.e., a fog node to which a subtask is assigned, e.g., a third target node (TN3)) provides a virtual execution environment, the subtask provides a deployment image of the virtual execution environment (e.g. For example, it can be packaged as a docker image of docker. For another example, if the target node (eg, the first and second target nodes TN1 and TN2) does not provide a virtual execution environment, the subtask cross compiles corresponding to the target node. Can be. Fog application fragments (eg, first to third fog application fragments APP_F1, APP_F2, APP_F3) may be generated through packaging.

Through the fog tracker 122, peripheral fog nodes having idle resources suitable for executing fog application fragments are searched, and fog application fragments can be deployed through communication with fog agents of the fog nodes.

FIG. 5B is a diagram illustrating a process of distributing fog applications in the fog computing system of FIG. 1. In FIG. 5B, the fog nodes 121-1 to 121-5 register their resource information to the fog tracker 122, the configuration requesting idle resource information around them, and the fog application pieces (APP_F1) ~ APP_F4) is shown a configuration that is distributed to the surrounding fog nodes.

All fog agents can register resource information of the fog node on which they are installed on the fog tracker 122, which is a blockchain node.

division Fog Node CPU RAM Storage OS Mobility Battery 121-1 Router 10 G 20 G 100 G IOS No 100% 121-2 Laptop 3 G 8 G 20 G Mac Yes 70% 121-3 Laptop 1 G 2 G 3 G Linux Yes 20% 121-4 Server 8 G 16 G 30 G Linux No 100% 121-5 Smart phone 2 G 2 G 4 G Android Yes 30%

Table 1 shows an example of resource information of the first to fifth fog nodes 121-1 to 121-5 registered in the fog tracker 122.

When the fog application operating on the user terminal 110 (or a specific fog node) is composed of four fog application fragments (APP_F1 to APP_F4) (or subtasks), fog application fragments (APP_F1 to APP_F4) Requirements such as resource information required for each and OS information of a target node to be distributed may exist.

The user terminal 110 may request necessary resource information from the fog tracker 122 through a resource request message. In this case, the fog tracker 122 returns to the user terminal 110 the most appropriate fog node information (that is, information of the fog nodes having the resource that best matches the required resource) through a resource allocation algorithm. (response).

The user terminal 110 may respectively distribute fog application pieces to corresponding fog nodes based on the received fog node information. For example, the second application piece APP_F2 may be distributed to the first fog node 211-1, and the third application piece APP_F3 may be distributed to the fifth fog node 211-5.

As described above, when the target node provides a virtualization layer (eg, a virtual machine environment in which an application is executed), such as a docker, the user terminal 110 may apply the corresponding virtual environment (virtualization). ), You can package the piece of fog application. For example, when the target node (eg, the first fog node 121-1) provides a docker environment, the user terminal 110 is a fog application (eg, a second fog application piece (APP_F2)) Can be packaged and distributed as a docker image.

When the target node does not provide a virtualization layer such as a docker when application decomposition is performed, the user terminal 110 cross compiles the fragment of the fog application to the target node using a cross-compilation function. (cross compile). For example, a piece of fog application may be cross-compiled for a target node's operating system and platform and distributed in a binary form. Table 2 below shows examples of the OS and platform of the target node.

Target Operating System Target Platform Android arm darwin 386 darwin amd64 darwin arm darwin amd64 dragonfly amd64 freebsd 386 freebsd amd64 freebsd arm linux 386 linux amd64 linux arm linux arm64 linux ppc64 linux ppc64le linux mips linux mipsle linux mips64 linux mips64le netbsd 386 netbsd amd64 netbsd arm openbsd 386 openbsd amd64 openbsd arm plan9 386 plan9 amd64 solaris amd64 windows 386 windows amd64

FIG. 6 is a diagram illustrating an example of a fog application. Referring to FIG. 6, the fog application may include a plurality of sub-tasks. For example, the first fog application APP1 is composed of first to third fog application fragments APP_F1 to APP_F3, and the second fog application APP2 is fourth to seventh fog application fragments APP_F4 to APP_F7).

The subtasks may be expressed in the form of a directed acyclic graph (hereinafter referred to as DAG) according to the direction of communication that delivers the message. That is, the DAG may indicate a message delivery direction of subtasks constituting an application.

 The first and second fog applications APP1 and APP2 are applied to the fog nodes because the plurality of fog applications can be simultaneously deployed and operated (for example, the first to fourth target nodes TN1 to TN4). Because they can be distributed), different fog applications can be managed with different DAGs.

Several FAG agents (eg, FAG agents of the first to fourth target nodes TN1 to TN4) that manage the operation of one application through the DAG are parent-child types It can exist in a tree structure. Each fog agent can communicate with its child fog agent to monitor whether subtasks on the DAG are working properly. For example, a problem occurs in a specific subtask or physical node (or a fog node, a target node), so that its child subtask (that is, a subtask running in a child fog agent) may not work properly. In this case, the parent agent may be obliged to solve the problem for the corresponding subtask.

FIG. 7 is a diagram illustrating a process of scaling out a fog application in the fog computing system of FIG. 1. Scale out serves to increase the performance of a subtask by placing one subtask in multiple nodes.

Referring to FIG. 7, a subtask (eg, a second fog application piece (APP_F2)) serving as a sensor is distributed to the first fog node 121-1 and serves as an analyzer. The subtask (for example, the third fog application piece (APP_F3)) is distributed to the second fog node 121-2, and a subtask (for example, the fourth fog application piece) acting as a visualizer. (APP_F4)) is distributed to the sixth fog node 121-6, and it can be assumed that a case in which the subtask of the analyzer is to be scaled out.

First, use the fog tracker 122 to find nearby idle nodes (eg, the third fog node 121-3 to the fifth fog nodes 121-5), and a naming store (see FIG. 3). You can update the node information of the analyzer (eg IP list). For example, if the IP addresses of the second to fifth fog nodes 121-3 to 121-5 are 141.223.2.2, 141.223.2.3, 141.223.2.4, and 141.223.2.5, the corresponding IP addresses may be updated have.

Subsequently, routing information of a subtask (for example, a second application piece (APP_F2)) that delivers a message to the analyzer on the application DAG information may be modified. That is, when there is only one analyzer, a message is transmitted only to the existing analyzer (Analyzer-0), and after scale-out, the existing analyzer (Analyzer-0) and the first to third analyzers (Analyzer-1, Analyzer-2, Analyzer) The message delivery target may be modified so that the message is delivered to -3).

Various load balancing algorithms can be used, for example, to deliver messages evenly to analyzers (Analyzer-0, Analyzer-1, Analyzer-2, Analyzer-3), as shown in FIG. 7 " SimpleHash "message can be delivered to the analyzers (Analyzer-0, Analyzer-1, Analyzer-2, Analyzer-3).

8 is a diagram illustrating a process of solving an application problem in the fog computing system of FIG. 1. 8 illustrates a process of failing over a problem occurring in a fog application or a fog node.

7 and 8, FIG. 8 illustrates a fog application substantially the same as the fog application illustrated in FIG. 7, and it may be assumed that a problem occurs in the second fog node 121-2.

The state information “Analyzer sum = 37, count = 4” is based on the directory service of the fog tracker 122 (for example, based on a key-value store described with reference to FIG. 3). Storage system).

When a failure occurs in the analyzer of the second fog node 121-2 (for example, a node having an IP address of 141.223.2.2) (for example, If isHealthy (fog: // myapp) = false) ), Which is delivered to the first fog node 121-1, which is the parent fog agent of the second fog node 121-2 on the application DAG (for example, (notifyFailover (getDAGParent (fog: / / myapp / actor / analyzer))), the first fog node 121-1 may be in charge of failover.

In this case, first, an idle node (for example, the third fog node 121-3) in which the new analyzer to replace the existing analyzer will operate may be found, and a new analyzer may be newly generated (spawn (Analyzer)). In addition, the state information of the existing analyzer can be set in a new analyzer using an interface called “setState (Analyzer)”.

Thereafter, when the IP address of the new analyzer is updated in the naming store (see FIG. 3), a sensor (eg, the first fog node 121-1) may transmit a message to the new analyzer. . Therefore, the fog application will operate normally.

Operation Description send Send a message to a Crystal receive Receive a message and process it stayInCloud Crystal will stay in the cloud stayInFog Crystal will stay in the local fog cluster stayInThing Crystal will stay in the client node where it was created moveToCloud Crystal will move to the cloud moveToFog Crystal will move to the fog moveToThing Crystal will move to the client node replicateCrystal Scale out a Crystal and do load balancing spawnCrystal Create a Crystal instance on a node migrateCrystal Migrate a Crystal instance to a node checkpointCrystal Save the state of Crystal respawnCrystal Re-create a Crystal from a checkpoint killCrystal Terminate Crystal instance getCrystal Get name of Crystal getCrystalList Get the list of Crystals for an application getCrystalParent Get the list of Crystal's parent Crystals getCrystalChild Get the list of Crystal's child Crystals getCrystalLocation Get location information of a Crystal getcrystalLatency Get latency from a Crystal to another getNode Get name of a fog node GetNodeList Get the list of fog nodes in the fog cluster getNodeLocation Get location information of a node getNodeLatency Get latency from Crystal to a fog node getFog Get name of the local fog cluster getFogList Get the list of fog clusters getFogLocation Get location coverage of a fog cluster getFogLatency Get latency from Crystal to a fog cluster getLatency Set latency limit a Crystal has to guarantee getStorage Set storage limit a Crystal can use getMemory Set memory limit a Crystal can use getCPU Set CPU limit a Crystal can use

Table 3 shows examples of the fog programming interface (or the fog application's programming interface). A user can develop a fog application using these programming interfaces and implement an orchestration function according to the application.

Event Description onCreate New Crystal Created onFailure Crystal failed onKill Crystal killed onMigrate Crystal migrated OnReplicate Crystal replicated onHighLatency Average Latency is higher than limit onLowCPU Node running out of CPU onLowMemory Node running out of memory onLowStorage Node running out of storage

Table 4 shows examples of the fog event handler. Users can use these functions to implement logic to handle a specific event in a node or fog application. 9A, 9C, 10A, and 10B are diagrams illustrating a development process of a fog application. 9A to 9C show a simple example of creating a fog application, an example of implementing an orchestration function according to application requirements, and an example of implementing a Map Reduce framework using a fog programming API. .

Referring first to FIGS. 7 and 9A, the fog application of FIG. 7 (or second to fourth fog application pieces (APP_F2 to APP_F4)) may be developed through the fog programming interface of Table 3. Also, as illustrated in FIG. 9B, fog application pieces (or sub-tasks A, B, and C) may be distributed to an end device (or user terminal), fog, and cloud.

Referring to FIG. 9C, when an event such as low memory occurs, a function of moving a piece of fog application from the end device (Thing) to the cloud may be implemented according to a fog programming interface defining movement to the cloud. .

Referring to FIG. 10A, when a fog application is generated in a first fog node FN1 (or a first fog agent), a request and reply to a fog node that meets requirements in the fog tracker FT This is done, the second fog node (FN2) has a subtask as a mapper (Mapper), a third fog node (FN3) has a subtask as a reducer (Reducer), and a fourth fog node (FN4) as a mapper ( Mapper) role subtasks can be distributed.

Referring to FIG. 10B, when an event such as low memory occurs in the second fog node FN2 (or the second fog agent), the fourth fog node FN4 in the first fog node FN1 as the parent fog agent Is set as a new fog node, and the subtask of the fifth fog node FN5 may be migrated to the sixth fog node FN6 in consideration of the delay time.

As described with reference to FIGS. 10A and 10B, a MapReduce framework may be implemented.

11 is a diagram illustrating an example of a clustering algorithm of a fog tracker included in the fog computing system of FIG. 1. 12A and 12B are diagrams illustrating delay times of fog nodes included in the fog computing system of FIG. 1.

First, referring to FIGS. 1 and 11, the fog tracker 122 has information on idle resources around the world, and when the fog node 121 requests information on idle resources, it informs the information on idle resources Play a role. However, whenever the resource request information of the fog node comes, it is expensive to find and inform the optimal resource. Accordingly, the fog tracker 122 may divide and manage the fog nodes into a fog cluster (or fog group). For example, by using the clustering algorithm illustrated in FIG. 11, fog nodes may be managed by dividing them into groups based on similar latency.

For example, the fog nodes located inside the A university in Pohang, the fog nodes located in the B university in Daejeon, and the fog nodes located in the C university in Seoul, when measuring latency to the random node S, FIG. 12A And groups may be formed as shown in FIG. 12B. A fog cluster or fog group may be formed based on the measurement result.

For example, when the fog node K near Pohang requests a resource, the fog tracker 122 does not sort adjacent nodes among all fog nodes around the world, but the fog cluster closest to the fog node K You can find (fog cluster) and only information about the fog nodes existing in the corresponding fog cluster.

13 is a block diagram illustrating a blockchain-based fog incentive model according to embodiments of the present invention. FIG. 13 illustrates a process of providing incentives to fog nodes that lend resources using a blockchain when computing is performed using fog idle resources. 14 is a block diagram illustrating an example of the fog incentive model of FIG. 13. FIG. 14 illustrates an exemplary fog incentive model implemented based on the ethereum of FIG. 13.

13 and 14, first to third subtasks A, B, and C may exist in the user terminal 110. The first to third subtasks A, B, and C may be distributed to three different fog nodes. The fog nodes can properly execute the subtasks, respectively, and deliver results to a task requestor (eg, the user terminal 110). In this case, the fog agent of the task requestor (for example, the user terminal 110) automatically encrypts cryptocurrency as much as participating in computing at the blockchain wallet address of the fog nodes that have executed the subtask. (cryptocurrency). For example, as illustrated in FIG. 14, when a fog incentive system is developed using Ethereum, an incentive may be provided through an API such as “Eth.sendTransaction (fog_peers)”.

15A is a block diagram illustrating a fog storage system according to embodiments of the present invention. 15A illustrates a process in which the file “hello.txt” is distributedly stored in fog nodes. 15B is a diagram illustrating an example of metadata used in the fog storage system of FIG. 15A.

15A, a file called “hello.txt” may be stored in a local filesystem. The fog storage system 1500 may divide files into multiple pieces using an encoder to store the files in various fog nodes. Then, it communicates with the fog tracker through the resource finder to find the optimal fog storage idle resources, and efficiently uses the encoded file fragments using a scheduler and event handler. Can be stored in multiple fog nodes using a storage connector.

As shown in FIG. 15B, the information of encoded file shares and its location information are stored in the form of objects, and information for accessing the encoded file fragments and the corresponding file. Meta information may be managed in the form of metadata.

16 is a flowchart illustrating a fog computing method according to an embodiment of the present invention.

1 and 16, the fog computing method of FIG. 16 may be performed in the fog computing system 100 of FIG. 1. As described with reference to FIG. 1, the fog computing system 100 includes a user terminal 110 and a fog node 121 and a fog tracker 122 located between the user terminal 110 and the cloud 130. can do.

The resource information (or idle resource information) of the fog node 121 may be registered in the fog tracker 122 (or the fog tracker service) (S1610). Here, the resource information may include resource information of the fog node 121, delay time information, operating system information, and platform information, as described with reference to Table 1.

The resource information of the fog node 121 may be periodically updated through the fog tracker 122.

The fog tracker 122 may classify the fog node 121 into fog clusters based on latency (S1620). For example, the fog tracker 122 may group fog nodes having low latency using the clustering algorithm illustrated in FIG. 11. In this case, as illustrated with reference to FIGS. 12A and 12B, when searching for target nodes, among the fog clusters, the fog cluster closest to the user terminal 110 is searched for, and the target nodes are searched for in the searched fog cluster, The load of the fog tracker 122 can be reduced.

Thereafter, the application developed by object-oriented programming in the user terminal 110 may be converted or generated into a fog application composed of a plurality of subtasks (S1630).

As described with reference to FIGS. 5A and 5B, an application developed with object-oriented programming includes a plurality of objects. In this case, the user terminal 110 may decompose the objects into sub-tasks and convert communication using variables and functions between the objects into message passing between fog nodes. have.

Subsequently, the user terminal 110 requests a resource (or a search for fog nodes having idle resources) corresponding to the fog application (S1640), and the fog tracker 122 subtasks among the fog nodes 121 The target nodes to be performed are searched (S1650), and the fog tracker 122 has the most appropriate fog node information (that is, the resource having the best resource for the required resource) through a resource allocation algorithm. The information of the fog nodes) may be returned to the user terminal 110 (S1660).

Subsequently, the user terminal 110 may package the subtasks in correspondence with target nodes to generate fog application pieces (S1670).

As described above, the user terminal 110 may package the subtasks as a dock image when the target nodes provide a docker environment in which the fog application is executed. Alternatively, if target nodes do not provide a docker environment, subtasks can be cross-compiled.

Thereafter, the pieces of the fog application are respectively distributed from the user terminal 110 to the target nodes (or the fog node 121) (S1660), and sub-tasks (or fog applications) may be executed on the target nodes ( S1670).

In one embodiment, the method of FIG. 16 may scale out a first sub-task among the sub-tasks. As described with reference to FIG. 7, the method of FIG. 16 searches for an idle node corresponding to the first sub-task among the fog nodes through the fog tracker 122 and sets the idle node to the node information for the first sub-task. In addition, routing information of the second sub-task that delivers a message to the first sub-task may be modified based on the idle node.

In one embodiment, the method of FIG. 16 may search for a third target node through a second target node that is a parent node of the first target node when a failure occurs in the first target node among the target nodes. As described with reference to FIG. 8, the method of FIG. 16 may perform a failure overcoming function when a problem or failure occurs in a specific fog node or a specific subtask.

The method of FIG. 16 can improve application execution speed and reduce battery usage by providing a fast response speed to a user application and distributing and executing a user application that uses a lot of computing resources to surrounding idle resources near the user. .

17 is a flowchart illustrating a fog computing method according to another embodiment of the present invention.

1, 4, and 17, the method of FIG. 17 may be performed in the fog computing system 100 of FIG. 1.

In the user terminal 110, a single file may be divided into a plurality of file fragments and encoded (S1710).

Thereafter, the user terminal 110 requests a resource (or information about a fog node to store a file) to the fog tracker 122 (S1715), and a target to store pieces of files among the fog nodes through the fog tracker 122 The nodes are searched (S1720), and the search results (eg, fog node list) may be returned to the user terminal 110 (S1725).

Subsequently, file fragments may be distributed and stored from the user terminal 110 to target nodes (eg, the fog node 121) (S1730).

Thereafter, when a read request for a stored file is generated, the target nodes having the fastest response speed among target nodes may be selected through the fog tracker 122. For example, one piece of file may be duplicated and stored in a plurality of target nodes. In this case, one target node having the fastest response speed among the target nodes may be selected. For example, the user terminal 1220 requests the fog tracker 122 to search for the target node (S1740), and the fog tracker 122 searches for the target node based on the response speed (or delay rate), (S1745), the search result may be provided to the user terminal 110 (S1750).

Thereafter, the user terminal 110 requests the transmission of the file (or file fragment) to the target node (eg, the fog node 121) (S1755), and the target node responds to the file to the user terminal 110 ) (S1760). Thereafter, the user terminal 110 may check the file by decoding the file fragments (S1765).

Meanwhile, in FIG. 17, it has been described as collecting and decoding file fragments in the user terminal 110, but is not limited thereto. For example, file fragments may be collected and decoded from the searched target node.

As described with reference to FIG. 17, the method of FIG. 17 provides a faster response speed compared to a cloud-based storage system by storing data in idle storage resources located around the node, and fragments a single file into multiple nodes It provides a fault-tolerance that allows you to get a complete file even if only a part of the file fragments stored in the file are distributed to each other.It is not dependent on one storage service provider by distributing and storing data among multiple nodes. Can be.

100: fog computing system
110: user terminal
120: fog
121: fog node
122: fog tracker
130: cloud
310: computing department
320: Blockchain Department

Claims (8)

In a fog computing method performed in a fog computing system including a user terminal and a fog node and a fog tracker positioned between the user terminal and the cloud,
Converting an application developed by object-oriented programming in the user terminal into a fog application composed of a plurality of subtasks;
Retrieving target nodes to perform the sub-tasks among the fog nodes in the fog tracker;
Packaging the sub-tasks corresponding to the target nodes to generate fog application pieces;
Distributing the fog application pieces to the target nodes, respectively; And
And executing the sub-tasks on the target nodes,
The fog tracker is a fog computing method including resource information of each of the fog nodes. The method of claim 1, wherein the fog nodes are classified into a plurality of fog clusters based on latency,
Searching for the target nodes,
Searching for a fog cluster closest to the user terminal among the fog clusters; And
And searching for the target nodes in the searched fog cluster. The method of claim 1, wherein the application includes a plurality of objects (objects),
The step of converting the application to the fog application,
Decompose the objects into the sub-tasks; And
And converting communication utilizing variables and functions between the objects into message passing between the fog nodes. According to claim 1,
Before the step of converting the application to the fog application, further comprising registering the resource information of each of the fog nodes to the fog tracker,
The resource information includes resource information, delay time information, operating system information, and platform information of each of the fog nodes,
The target node is a fog computing method that is searched based on the resource information. The method of claim 4, wherein the packaging of the fog applications,
Packaging the subtasks as a dock image when the target nodes provide a docker environment in which the fog application is executed; And
And if the target nodes do not provide the docker environment, cross compiling the subtasks. According to claim 1,
And scaling out a first sub-task among the sub-tasks.
The step of scaling out the first sub-task,
Searching for an idle node corresponding to the first sub-task among the fog nodes through the fog tracker;
Adding the idle node to node information for the first sub-task; And
And modifying routing information of a second subtask that delivers a message to the first subtask based on the idle node. According to claim 1,
And searching for a third target node through a second target node that is a parent node of the first target node when a failure occurs in the first target node among the target nodes. In a fog computing method performed in a fog computing system including a user terminal and a fog node and a fog tracker positioned between the user terminal and the cloud,
Encoding by dividing one file into a plurality of file fragments at the user terminal;
Searching for target nodes to store the file fragments among the fog nodes through the fog tracker;
Distributing and storing the file fragments to the target nodes, respectively;
Selecting target nodes having the fastest response speed among the target nodes; And
And collecting and decoding the pieces of files from the target nodes.

Images