KR20230069813A - Apparatus for switching main screen based on distributed telepresence and method using the same - Google Patents

Abstract

A multi-cloud edge system is disclosed. A multi-cloud edge system according to an embodiment of the present invention includes a core cloud; A multi-cluster-based first edge (A FIRST EDGE) node system; and a multi-cluster-based near edge (NEAR EDGE) node system, wherein the multi-cluster-based first edge node system includes a plurality of task nodes; and a master node having a scheduler.

Description

Multi Cloud Edge System {APPARATUS FOR SWITCHING MAIN SCREEN BASED ON DISTRIBUTED TELEPRESENCE AND METHOD USING THE SAME}

The present invention relates to a multi-cloud edge system, and more particularly, to a technique for configuring and managing multiple clusters for edge computing services.

Edge computing technologies deploy computing storage software and the like from the core to the edge as part of a variety of distributed computing topologies that require some form of enterprise data center or centralized cloud service and include it. In addition, by providing core cloud-cloud edge-terminal collaboration-based low-latency data processing technology that selectively utilizes computing resources close to service users to provide faster service than the existing cloud-terminal-centered centralized cloud infrastructure, response speed and Ensure the stability of safety-critical services.

Recently, technology development and related service systems that provide intelligent cloud edge services that process data in close proximity to terminals are being released in order to overcome delays in processing and transmission due to central cloud centralization of explosive data generated by large-scale terminals desired by users. . Among them, Kubernetes, which is operated as a single cluster, is a tool designed to orchestrate and integrate OCI-based container environments and is currently the most used tool. However, in the case of Kubernetes, the use of a single cluster environment is limited, and tools to link multiple clusters are needed. For example, Rancher is designed to install and configure multiple Kubernetes clusters to support multi-clustered Kubernetes. And it was conceived and designed so that users can easily support both public cloud and bare metal servers.

In addition, various methods are being studied to link and service the distributed cloud edge and core cloud. To this end, OpenShift (Istio) of the open source camp is actively progressing as an L7 layer-based service mesh technology. A service mesh is a program developed for interoperability between microservices. Since this method shares the control plane on multiple networks and communicates between clusters through a gateway, the two networks do not need to be directly connected.

In cloud computing, the place where data is processed is the data center, but in edge computing, data is processed at a location close to the terminal to overcome delays in processing and transmission due to the centralization of massive data generated by large-scale edge terminals in the cloud, and data is processed in a location close to the terminal and A high-performance platform that performs distributed collaboration is required.

However, the existing edge system lacks a management method considering multiple clusters, provides services in a form that is not optimized for bare metal, container, FaaS service, etc., does not provide a method for adding resources to guarantee performance when there is a shortage of spare resources, and vertical/horizontal collaboration Insufficient network structure for high-speed connection of multiple clusters, performance problems of OCI used in Kubernetes (response speed-sensitive service delay), lack of architectural technology for a complete collaboration solution, etc. have a problem

Korean Patent Publication No. 10-2018-0119905, published on November 5, 2018 (Name: Distributed cloud-based application execution system, device and method of operating the device applied thereto)

An object of the present invention is to configure a tunneling-based high-speed network environment capable of linking multiple clusters to support a container-based distributed computing environment in edge computing.

In addition, an object of the present invention is to propose a new high-performance architecture for optimal management and service collaboration between clusters on a linked network.

In addition, an object of the present invention is to provide a system structure and an intelligent scheduling method for optimizing vertical and horizontal collaboration between cloud and edge, so that application program developers can achieve vertical collaboration between edge-edge terminals and horizontal collaboration between edge-cloud edge. It is to support the application and materialization of interworking edge platform-based distributed collaboration at the system level.

In addition, an object of the present invention is to construct a high-performance container and a global cache for linking data between containers by utilizing a memory-based storage device to increase container efficiency.

Multi-cloud edge system according to the present invention for achieving the above object is a core cloud; A multi-cluster-based first edge (A FIRST EDGE) node system; and a multi-cluster-based near edge (NEAR EDGE) node system, wherein the multi-cluster-based first edge node system includes a plurality of task nodes; and a master node having a scheduler.

In this case, the first edge node system and the near edge node system may be connected through a high-speed network according to a tunneling protocol.

In this case, a shared storage device for sharing and storing data according to cooperative operation between the first edge node system and the near edge node system may be further included.

In this case, a management node may further include a management node that controls resources required for cooperative operation based on data of the first edge node system and the near edge node system.

At this time, the first edge node system or the near edge node system includes computing nodes, and the computing nodes are container platform-based monolithic applications (MONOLITHIC APPLICATION), micro services (MICRO SERVICE) and service-type functions (FUNCTION AS A SERVICE) can be provided.

At this time, the first edge node system receives a request for an operation load for the task (TASK) from an external device, and the master node uses the scheduler to select a work node where an application capable of performing the task (TASK) is distributed. The determined work node may perform the task, and the master node may collect a result of performing the task and respond to the external device.

In this case, a service based on vertical collaboration calculation provided by the core cloud and the first edge node system and a service based on horizontal collaboration calculation provided by the first edge node system and the near edge node system may be provided.

According to the present invention, it is possible to provide a high-performance architecture for efficient collaboration between clusters by constructing a global cache for high-performance containers and data linkage between containers by utilizing a memory-based storage device to increase container efficiency.

In addition, the present invention can provide a collaboration service between clusters by connecting tunneling-based high-speed networks.

In addition, the present invention enables distributed collaboration based on an edge platform that links horizontal collaboration between a core cloud and an edge and horizontal collaboration between an edge and an edge terminal to be applied and materialized at the system level.

1 is a diagram showing an example of a multi-cluster linkage architecture structure for an edge service according to the present invention.
2 is a diagram showing an example of a system for an existing edge service.
3 is a diagram showing an example of a 3Locarions-based edge service system including a cloud, an edge, and a neighboring edge according to the present invention.
4 is a diagram showing an example of an edge service capable of vertical and horizontal collaboration according to the present invention.
5 is a diagram showing an example of a structure of a container system based on in-memory container storage according to the present invention.
FIG. 6 is a diagram illustrating an example of a detailed structure of the in-memory container storage shown in FIG. 5 .
FIG. 7 is a diagram illustrating an example of a detailed structure of the in-memory container storage engine shown in FIG. 5 .
8 is a diagram illustrating an example of a container in-memory storage creation method according to the present invention.
9 is a diagram showing an example of a container file system implemented in an in-memory storage according to the present invention.
10 is a diagram illustrating an example of an image sharing environment of an in-memory container storage according to the present invention.
11 is a diagram showing an example of a configuration for a user sharing environment according to the present invention.
FIG. 12 is a diagram illustrating an example of a detailed structure of the in-memory container storage management module shown in FIG. 5 .
13 is an operational flowchart illustrating an example of a detailed process for data sharing management in the in-memory container storage management module according to the present invention.
14 is a diagram showing an example of an inter-cluster connection structure according to the present invention.
15 is a diagram showing an example of a configuration of an edge service system scheduler according to the present invention.
16 is a diagram showing an example of a leveled scheduler according to the present invention.
17 is a diagram showing an example of a Shared/Leveled complex scheduler according to the present invention.
18 is a diagram showing an example of a scheduler policy executor of an edge service system according to the present invention.
FIG. 19 is a diagram illustrating an example of a processing flow of the scheduler policy executor shown in FIG. 18 .
FIG. 20 is an operational flowchart illustrating an example of a processing sequence of a 3-step request queue of the scheduler policy executor shown in FIG. 18 .
21 is a diagram showing an example of dynamic arrangement and interworking of service distribution collaboration based on an intelligent scheduler according to the present invention.
22 is a diagram showing an example of an edge service system to which an intelligent scheduler according to the present invention is applied.
23 is a diagram illustrating an example of an optimization processing flow of an edge service system to which an intelligent scheduler according to the present invention is applied.

The present invention will be described in detail with reference to the accompanying drawings. Here, repeated descriptions, well-known functions that may unnecessarily obscure the subject matter of the present invention, and detailed descriptions of configurations are omitted. Embodiments of the present invention are provided to more completely explain the present invention to those skilled in the art. Accordingly, the shapes and sizes of elements in the drawings may be exaggerated for clarity.

In this document, "A or B", "at least one of A and B", "at least one of A or B", "A, B or C", "at least one of A, B and C", and "A Each of the phrases such as "at least one of , B, or C" may include any one of the items listed together in that phrase, or all possible combinations thereof.

Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the accompanying drawings.

1 is a diagram showing an example of a multi-cluster linkage architecture structure for an edge service according to the present invention.

Referring to FIG. 1 , on the edge system according to the present invention, vertical collaboration refers to collaboration between a core cloud 110 and an edge 120, and horizontal collaboration refers to collaboration between an edge 120 and a neighboring edge 130. can do.

At this time, a network connection as shown in FIG. 1 is required for each collaboration. Therefore, in the present invention, a tunneling-based high-speed network for collaboration is configured, and shared storage and storage for linking mutual clusters can be configured. The edge system configured in this way can be driven and managed by a global scheduler in charge of overall management.

At this time, the nodes of the cluster are container platforms and can be composed of monolithic applications, microservices, and FaaS (Function as a Service) systems. As mentioned above, the container platform is configured based on memory-resident containers using memory-based storage devices, and the global cache can also utilize memory-based storage for high-speed configuration.

At this time, the existing edge service has the following problems in the form of supporting only vertical collaboration as shown in FIG. 2 .

- Insufficient movement support

- Partial vertical collaboration

- Limited linkage technology for collaboration

- Partial support in connection with service

That is, the system for the existing edge service as shown in FIG. 2 consists of a relationship between only the cloud and the edge, but the edge service system proposed in the present invention is not only the cloud and the edge as shown in FIG. It can be composed of 3 locations (3 Locations) with added.

At this time, the three locations (3 Locations) may mean a cloud (Public / Private Cloud), an edge (an edge that is directly connected to a user and served), and a neighboring edge (near edge, a peripheral edge close to the edge).

In addition, referring to FIG. 2, the existing edge service provides only monolithic applications and microservices, but in the edge service system proposed in the present invention, as shown in FIG. 3, monolithic applications and microservices ( Micro Service) and 3 Application Types corresponding to Function as a Service (FaaS) can be supported.

At this time, the three application types (3 Application Types) may have different characteristics in terms of application complexity, service scale, and resource usage type, as shown in [Table 1].

application type complexity Scale Type of resource use monolithic application simple middle constant use of resources microservice complication award Partial resource use expansion/reduction possible service function simple under Temporary use of resources

Therefore, the edge service proposed in the present invention needs to effectively apply functions such as mutual collaboration or service movement that well reflect these characteristics.

At this time, according to FIG. 3, vertical and horizontal cooperation optimization of the edge service system according to the present invention can be supported based on 3LT (3 Locations, 3 Application Types). That is, since the existing edge service shown in FIG. 2 provides only partial and vertical collaboration, it has limitations that service collaboration is limited or service linkage is partial.

Therefore, in order to solve this problem, the present invention proposes a structure capable of various vertical and horizontal collaborations regardless of location or service type through the 3LT-based edge service system shown in FIG. 3 .

At this time, FIG. 4 shows an example of an edge service capable of vertical and horizontal collaboration according to the present invention, which corresponds to the form of scale-out using 3L, scale-up using 3L, and predictive over edge using 3L. It can support key collaborations between cloud and edge systems.

5 is a diagram showing an example of a structure of a container system based on in-memory container storage according to the present invention.

Referring to FIG. 5 , the in-memory container storage system according to the present invention may include an in-memory container storage 510, an in-memory container storage engine 520, main memory, disk storage, and remote storage.

Hereinafter, the structure and operation flow of the in-memory container storage system according to the present invention will be described in detail with reference to FIG. 6 .

First, the container may create an in-memory container storage 610 that is a storage on main memory having a non-volatile characteristic, and a storage volume of the container may be configured on the in-memory container storage 610 .

The container may create and operate a container storage volume, which is a file system (eg, /var/lib/docker for Docker) volume on which the container is executed, on the in-memory container storage 610 . Accordingly, a container access command generated by the container may be transmitted to the in-memory container storage 610 .

The in-memory container storage engine 620 may create a unitary shape of the in-memory container storage 610 by integrating main memory, disk storage, and remote storage. In addition, the in-memory container storage engine 620 processes a disk access command by using main memory, disk storage, and remote storage.

At this time, the in-memory container storage 610 provides a standard block storage format interface through the in-memory container storage engine 620, so that it can be operated without additional modification.

Hereinafter, the structure of the in-memory container storage engine according to the present invention will be described in detail with reference to FIG. 7 .

Referring to FIG. 7 , the in-memory container storage engine 700 may include a storage interface module 710, a storage access distribution module 720, and a storage control module 730.

First, the storage interface module 710 may provide a standard block storage format interface and may receive a disk access command generated by a container. The command received in this way may be transmitted to the storage access distribution module 720 .

The storage access distribution module 720 may determine whether to perform a service using main memory storage, disk storage, or remote storage according to characteristics of a disk access command. Then, an access command may be transmitted to the main memory control module, the disk storage control module, and the remote storage control module included in the storage control module 730 .

The storage control module 730 may include a main memory control module, a disk storage control module, a remote storage control module, a main memory disk creation module, a disk backup/restoration module, and a real-time synchronization module.

The main memory control module can process a disk access command using the main memory, which can provide a high access speed.

For example, when a disk access command is received by the main memory control module, the disk access commands transmitted in blocks through the main memory disk creation module are actually read/written on the main memory that can be accessed in address units. Write) can be processed. Through this, data of the virtual disk can be created and stored in the main memory.

The disk storage control module may process virtual desk access commands using disk storage.

8 is a diagram illustrating an example of a container in-memory storage creation method according to the present invention.

Referring to FIG. 8 , a method of creating a single hybrid container in-memory storage 800 by integrating a main memory storage 810 and a disk storage 820 is shown.

The in-memory container storage 800 provides a standard block storage format and can be created by mapping an area of the main memory storage 810 to the front of the storage and mapping an area of the disk storage 820 to the rear.

For example, areas corresponding to block IDs 1 to N of the main memory storage 810 may be mapped to areas corresponding to block IDs 1 to N of the in-memory container storage 800 . Also, areas corresponding to block IDs 1 to M of the disk storage 820 may be mapped to areas corresponding to block IDs N+1 to N+M of the in-memory container storage 800 . At this time, a storage boundary may be set between the block IDs N and N+1 in the container in-memory storage 800 to divide the main memory storage area 810 and the disk storage area 820 .

9 is a diagram showing an example of a container file system implemented in an in-memory storage according to the present invention.

Referring to FIG. 9 , a file system used in a container according to the present invention may be configured on an in-memory container storage.

According to the present invention, the container's basic file system can be driven in the main memory for driving the container's main memory. For example, in the case of a container, a user-needed file can be provided individually by using a unifying file system function included in the kernel of the existing Linux environment.

At this time, the unifying file system function is a concept of mounting multiple file systems on a single mount point, and instead of creating a new file system type, all directory entries are unified and processed in the virtual file system (VFS) layer. can do. Thus, the filesystem coalescing function allows directory entries in child filesystems to be merged with directory entries in parent filesystems to create a logical combination of all mounted filesystems. Therefore, management and file search for the entire file system shared in the system can be performed locally, and file management for the entire share can be facilitated.

That is, as shown in FIG. 9, the container file system according to the present invention can be configured in a layered form as an integrated file system.

Each layer classified as a merged area (merged) 930, a container layer (920), and an image layer (910) operates by creating and mounting a specific directory on the in-memory container storage. can

First, the container layer 920 is a layer that can be written, and is created at the top layer so that each container can have its own state. In this case, after the container is created, all changes can be performed in the container layer 920 . In addition, since read/write in the container layer 920 is performed on memory, it can operate at a high speed. And, for efficiency of file management, difference information between the actual image and the container image may be included.

The image layer 910 is a read-only layer and can be shared with other containers. At this time, multiple images shared with other layers can be operated in the container layer 920 .

That is, the image layer 910 can increase its efficiency by sharing container images with different systems.

For example, as shown in FIG. 9 , the container image of the image layer 910 needs to be pulled from a common repository (eg, github) when the container is deployed. At this time, it is possible to operate efficiently by storing the image used in the container system locally or bringing it in advance to ensure performance.

In the present invention, a method of storing an already pulled image in a shared storage for reuse is proposed. As described above, many images of the image layer 910 exist on in-memory container storage, and container images of the entire system are backed up and stored in disk storage or remote storage, which can be added to the image layer 910. can Through this, container images of the entire system can be used in the container layer 920, and images can be continuously provided through the integrated access area 930.

The integrated access area 930 may include layer link information so that all file systems of the container layer 920 and the image layer 910 can be accessed, and this link information can be shared with users to enable file access. can

10 is a diagram illustrating an example of an image sharing environment of an in-memory container storage according to the present invention.

Referring to FIG. 10 , a shared storage 1000 may be used to provide shared data in the in-memory container storage according to the present invention.

For example, the shared storage 1000 may be network file storage (SAN, NAS, etc.) or storage attached to a local disk.

Referring to FIG. 10 , the image sharing environment according to the present invention may have a structure in which a container image stored in a shared storage 1000 is provided to a user at the user's request.

For example, the sharing management function can be provided through the container file system layer management module of the in-memory container storage management module shown in FIGS. The shared data 1010 may be provided to the user.

Hereinafter, with reference to FIG. 11, a process of sharing data in a node having an in-memory container storage for providing shared data as shown in FIG. 10 will be described in detail.

11 shows a user (tenant) approach method that can improve security by distinguishing and providing data to be shared according to the group using the shared data, rather than sharing all data when sharing data according to the present invention. there is.

First, a user directory (/sharedData/tenant) is created in the Node A in-memory container storage 1110 at the request of the user (Tenant), and the user's directory (/sharedData/tenant) is created in the container layer 1111 (upper directory). You can create and map one directory (diff) under tenant). In this case, user data may use deduplication data for file system management. The diff directory created in this way corresponds to a container layer and may correspond to data stored by accessing or editing/modifying a file by a user. Also, the work directory can be created and mapped under the user's directory. The work directory may correspond to a user data storage area of the container layer.

In addition, the lower directory (lowerdir2=/sharedData/base/File1-Link, File2-Link??FileN-Link/) located at the lowest level in the image layer 1112 stores all file links of the shared storage 1120. It can be set to (/sharedData/base...) as a management point.

At this time, the image layer 1112 can expose the lower directory (lowerdir2=/sharedData/base/File1-Link, File2-Link??FileN-Link/) to the management system so that the user can select the necessary file. The lower directory (lowerdir1=/sharedData/tenantA/base/File1-Link, File2-Link) created in the image layer 1112 is linked with the upper directory to arrange link information only for a file selected by the user.

Through this process, the user can view only the files he/she selects through the subsystem.

Therefore, users can share files through user directories shared with them, and lower directories can always maintain an immutable state. In other words, the lower directories are used as read-only, which effectively prevents write problems when data is shared by several people. If a change occurs in a file in the lower directory, the change is recorded in the upper directory, so the entire shared file can be managed efficiently.

FIG. 12 is a diagram illustrating an example of a detailed structure of the in-memory container storage management module shown in FIG. 5 .

Referring to FIG. 12 , the in-memory container storage management module 1200 according to the present invention includes a container file system layer management module, an in-memory container storage creation management module, an in-memory container storage sharing management module, and an in-memory container engine management module. can be configured.

The container file system layer management module can monitor the current state and running state of the container file system. Also, when using in-memory container storage, you can manage the creation and state of container systems.

The in-memory container storage creation management module may create in-memory container storage when a container is to be configured in an in-memory form at the request of a user. At this time, when the creation of the in-memory container storage is completed, the container file system layer management module creates the container file system of the system.

The in-memory container storage sharing management module can create a shared file system between storages to share image layers according to a user's request, and perform an operation to synchronize them. At this time, the link information of the image layer can be merged into one system and synchronized.

The in-memory container storage engine management module can drive, create, and monitor the status of the system's in-memory container storage drivers.

Hereinafter, a process of performing data sharing management in the in-memory container storage management module according to the present invention will be described in detail with reference to FIG. 13 .

First, a user (tenant) may access the system and request and select file sharing (S1302 and S1304).

At this time, the users may be divided into users receiving file sharing and providers for providing file sharing.

Accordingly, it may be determined whether the user is a provider providing file sharing (S1306).

As a result of the determination in step S1306, if the user is a user receiving file sharing, it may be determined whether the corresponding user is the first user (S1308).

As a result of determination in step S1308, if the user is the first user, a user directory can be created (S1310), and related directories can be created (S1312) to mount the entire system environment (S1314).

Thereafter, by moving to the lower directory of the user directory (S1316), link information for a shared file requested by the user may be found and created from a shared storage base (S1318).

In addition, as a result of the determination in step S1308, if the user is not the first user, the user moves directly to the lower directory of the user directory (S1316), and the link information for the shared file requested by the user can be found and created from the shared storage base. (S1318).

In addition, as a result of the determination in step S1306, if the user is a provider providing file sharing, it is possible to access the shared storage, upload the file (S1320), move to the shared storage base (S1322), and create a shared file link ( S1324).

14 is a diagram showing an example of an inter-cluster connection structure according to the present invention.

The present invention is intended to smoothly provide edge computing services and maximize the efficiency of large-capacity data processing and distributed environments. Therefore, consideration of the vertical distribution environment between the core cloud and the cloud edge and the horizontal distribution environment between the cloud edges is required to provide the collaboration function of edge computing.

For example, interconnection between clusters and high-speed distributed deployment technology are essential in order to connect distributed environment services of edge computing that are deployed regionally beyond clusters through a high-speed network. Therefore, the connection structure between clusters should be designed considering the network connection function on multiple cluster nodes of the cloud edge system and its interface. In addition, along with the network connection function, a function for linking fast data movement and storage is also required.

Referring to FIG. 14 , the service connection structure according to the present invention may mean a network connection function on multiple clusters for linking core-edge and edge-edge. In other words, it may correspond to a function for linking different networks for the use of a nearby edge and uninterrupted service according to the mobile service of the cloud edge.

In this case, the present invention can provide a high-speed gateway engine function and a basic route engine function for internal recognition of clusters in order to connect multiple clusters to a network. Gateways and routers can be deployed locally through the global edge scheduler as a management function on the cluster.

In this case, the high-speed gateway can be linked using tunneling between two networks as a network connection method for linking and operating multiple clusters at high speed.

Through tunneling, reliable data transmission can be guaranteed by encapsulating the payload in the tunneling section and using a specific protocol. In addition, tunneling can be applied to the L7, L3, and L2 layers among the 7 layers of the Internet. As the tunneling of the lower layer is supported, many protocols used in the upper layer can be used as they are, and the performance is also faster.

14 shows an example of linking two clusters using L3 layer tunneling. In the case of protocols used for such connected tunneling, the processing speed is often slower than other protocols. In order to overcome this problem, the present invention uses a user-level network driver (DPDK, Data Plane Development Kit) for kernel bypass Connect to the tunneling network.

In addition, the interface between the master node and the worker node may be connected through a tunneling interface and a bridge, and may be connected to a network composed of an existing overlay network.

More specifically, a high-speed gateway engine function, a global shared cache function, a kernel bypass supporting network stack configuration function, a user-level network driver management function, and a router agent function can be provided by the inter-cluster connection structure shown in FIG. 14 .

The high-speed gateway engine function can perform multi-cluster tunneling at the L3 layer using a user-level network driver.

The global shared cache function is a storage function for sharing data in conjunction with a local shared cache after creating high-speed shared storage by utilizing a network-based storage system that utilizes memory-based storage. can be utilized

The kernel bypass support network stack configuration function may correspond to a library for kernel bypass, device management and configuration management functions (eg DPDK hardware support stack).

The user-level network driver management function may correspond to a CLI function for distributing, connecting, and managing user-level network drivers (for example, Cisco FD.io, etc., a network driver provided by an application).

The router agent function runs on all nodes and can configure routes using synchronized endpoint resources from other clusters and enable full cluster-to-cluster connectivity. At this time, Iptable rules can be set, and in order to connect and communicate with the gateway engine, it can have a routing table of the gateway engine.

15 is a diagram showing an example of a configuration of an edge service system scheduler according to the present invention.

The scheduler of the existing edge service system is a fixed scheduler determined by specific logic, and such a non-adaptive scheduler has a structure that is difficult to optimize for actively arranging or using resources in response to changes in service scale or usage pattern.

Therefore, the present invention intends to propose a new scheduler based on multiple clusters to improve the problems of the existing scheduler.

The target of application of the scheduler proposed through the present invention may correspond to a resident container for executing a monolithic application or microservice and a non-resident container for execution of a function as a service (FaaS).

Referring to FIG. 15 , the edge service system scheduler according to the present invention may be composed of four types of schedulers including a global edge scheduler 1510 and three schedulers 1520, 1530, and 1540 corresponding to 3 locations.

The global edge scheduler 1510 may correspond to a scheduler for interworking the cloud scheduler 1520, the master edge scheduler 1530, and the neighboring edge scheduler 1540.

The cloud scheduler 1520 may correspond to schedulers of public and private clouds.

The master edge scheduler 1530 may correspond to a scheduler of an edge (master edge) where main services are executed.

The neighboring edge scheduler 1540 may correspond to schedulers of neighboring edges around the master edge.

The edge service scheduler configured in this way is a scheduler capable of dynamically setting policies and an intelligent scheduler through log data analysis. In addition, it is possible to minimize the cost according to the scheduling policy change, and to minimize waiting and delay time.

In addition, by using the edge service scheduler shown in FIG. 15, horizontal collaboration and vertical collaboration can be applied at the system level in the edge service.

For example, the edge service scheduler according to the present invention may correspond to a complex scheduler combining a leveled scheduler and a shared scheduler.

At this time, the leveled scheduler is a scheduler for sequential processing, and the shared scheduler corresponds to a scheduler that competes with each other to find the optimal condition.

For example, the scheduler shown in FIG. 16 is in the form of a 3-level scheduler, and scheduling work may be performed in the order of a master edge scheduler, a neighboring edge scheduler, and a cloud scheduler. If resource allocation succeeds through the 1st level master edge scheduler, execution of the 2nd level neighboring edge scheduler and the 3rd level cloud scheduler can be omitted. However, if resource allocation fails in the master edge scheduler, the first level, the task can be sequentially transferred to the next level scheduler. Service developers can use this leveled scheduler to apply load balancing of edge services and collaboration between services at the system level.

As such, the leveled scheduler processes tasks sequentially, but the shared scheduler can operate as a competition mode between schedulers. For example, after requesting a task from two or more schedulers at the same time, receiving candidates from each scheduler, selecting the most suitable one from among them and processing the task may operate.

As another example, the scheduler shown in FIG. 17 is a leveled scheduler composed of 2 levels, and at 2 levels, a neighboring edge scheduler and a cloud scheduler are configured as a shared scheduler. It may correspond to a complex scheduler proposed in the present invention.

If resource allocation fails in the master edge scheduler, which is level 1, tasks are requested to the neighboring edge scheduler and the cloud scheduler simultaneously through contention mode in level 2. After that, candidates are received from the neighboring edge scheduler and the cloud scheduler, and a job can be processed by selecting the most suitable one among them.

18 is a diagram showing an example of a scheduler policy executor of an edge service system according to the present invention.

Referring to FIG. 18 , the scheduler policy executor for executing the complex scheduler according to the present invention may be composed of an edge scheduler policy executor 1800 and a cluster (edge/neighbor edge/cloud cluster) to execute actual containers.

The functions of the main components constituting the scheduler policy executor according to the present invention are shown in [Table 2].

component function Global Scheduler REST API A REST API corresponding to the scheduler requesting allocation of related application containers from the user interface or command line tool global scheduler handler A component that handles the global scheduler REST API request queue manager A component that receives container allocation requests from the global scheduler handler and stores and manages the data. global scheduler controller A component that pulls scheduling request data from the request queue and creates and runs a global scheduler work thread. global scheduler work thread A thread that converts scheduler jobs into messages to be delivered to the global scheduler agent on the corresponding master node and stores them in the job message queue. Edge Cluster Metadata Repository A repository that stores metadata related to edge clusters task message queue A repository that stores scheduler operation messages between the edge scheduler policy executor and the cluster. global scheduler agent A component that receives its corresponding scheduler job message from the job message queue on the cluster's master node and calls the REST API. Edge (Cloud) Scheduler A component that detects unallocated containers and selects worker nodes to run containers on. walker agent Agents running containers on worker nodes

Hereinafter, the process flow of the scheduler policy executor according to the present invention will be described in detail with reference to FIG. 19 .

Referring to FIG. 19, a process of creating and executing a container requested from a client on a worker node is as follows.

First, when a user calls a REST API corresponding to container creation, a global scheduler handler may be executed to process the called REST API.

Then, the global scheduler handler can send the requested data to the request queue manager, and the request queue manager can store the requested data in a queue.

after, The global scheduler controller may bring data to be processed from the request queue in consideration of priority, create a global scheduler task thread, and transfer the data to be processed to execute a scheduling task.

Then, the global scheduler job thread analyzes the requested job, converts the scheduler job into a message form requested to the corresponding cluster, and transmits it to the job message queue manager.

Then, when the task message queue manager stores the delivered message in the task message queue, the cluster's global scheduler agent checks whether there is a message corresponding to the edge and neighboring edges from the task message queue and retrieves the corresponding message.

After that, the global scheduler agent analyzes the imported message and calls the corresponding API to its edge API server.

After that, the edge scheduler can create and run the requested container through the worker agents in the worker nodes.

FIG. 20 is an operational flowchart illustrating an example of a processing sequence of a 3-step request queue of the scheduler policy executor shown in FIG. 18 .

The proposed scheduler policy executor proposed in the present invention can process a request queue by dividing it into three stages in order to preferentially process requests that have been requested for scheduling but have repeatedly failed, or to process requests with priority options prior to basic scheduling requests. there is.

At this time, the three-level request queue may be configured in the order of a first front queue (FF), a second front queue (SF), and a base queue (B).

The first front queue may correspond to a queue for preferentially processing requests that have been requested for scheduling but have repeatedly failed.

The second front queue may correspond to a queue for prioritizing requests having priority options over basic scheduling requests.

Referring to FIG. 20, in the processing of the 3-step request queue of the edge scheduler policy executor, first, it is determined whether the requested data has a priority option (FAST Option) (S2005), and if there is a priority option, the second front queue It is stored in (S2010), and if there is no priority option, it can be stored in the base queue (S2020).

After this, it is checked whether there is data in the queue in the order of First Front Queue, Second Front Queue, and Base Queue, and schedules task queues in order by N from each queue. Scheduling can be attempted by creating in (S2030).

After that, it is determined whether scheduling has succeeded (S2035), and if scheduling has failed, the number of failures (Fail_Num) of each request is increased by 1 (S2040), and whether the number of failures exceeds the predetermined number of failures (K*) can be determined (S2045).

As a result of the determination in step S2045, if the number of failures exceeds the predetermined number of failures (K*), the request may be stored in the first front queue (S2050).

In addition, as a result of the determination in step S2045, if the number of failures does not exceed the predetermined number of failures (K*), it is determined again whether there is a priority option (S2055), and if there is a priority option, it is stored in the second front queue. (S2010), if there is no priority option, it can be stored in the base queue (S2020).

In addition, as a result of the determination in step S2035, if scheduling is successful, the scheduling task may be terminated.

At this time, the scheduling task shown in FIG. 20 is repeated until there is no all requested data in the request queue of step 3, and if there is no data, it can wait.

21 is a diagram showing an example of dynamic arrangement and interworking of service distribution collaboration based on an intelligent scheduler according to the present invention.

Referring to FIG. 21 , the scheduler of the edge service system proposed in the present invention may correspond to an intelligent scheduler rather than a fixed scheduler.

For example, the proposed edge service system as shown in FIG. 21 collects real-time monitoring data and logs for the cloud, edge, and neighboring edge based on the distributed-collaborative dynamic arrangement intelligent analyzer 2100, and uses the collected data for deep learning. Various services can be dynamically deployed through AI analysis such as

22 is a diagram showing an example of an edge service system to which an intelligent scheduler according to the present invention is applied.

The edge service system proposed in the present invention may require a lot of history data when deriving an intelligent scheduler policy through artificial intelligence training.

At this time, it is impossible to build an edge service system and immediately perform artificial intelligence training, but after collecting historical data for a certain period of time, edge scheduler policy training can be performed.

The main components constituting the edge service system shown in FIG. 22 and the functions of each of the main components are shown in [Table 3].

Component function Edge Scheduler Policy Metadata Store Repository to store Edge Scheduler Policy (ESP) Edge Scheduler Policy Planner A component that establishes policies based on information collected from edge application-specific information collectors and edge cluster information collectors. Information Collector by Edge Application Component that collects response speed, CPU actual usage rate, memory actual usage rate, and other resource usage status for each application running on the edge Edge Cluster Information Collector Component that collects information such as actual CPU utilization rate and memory actual utilization rate for each physical node constituting the cluster Edge Scheduler Policy Log Datastore Storage that stores the result of applying the edge scheduler policy through the edge scheduler policy logger Edge Scheduler Policy Trainer A component that trains by fetching historical data from the edge scheduler policy log data store. Edge Scheduler Policy Evaluator Component that evaluates according to the degree of optimization after applying the edge scheduler policy Edge Scheduler Policy Executor Component that executes the best policy after applying multiple edge scheduler policies and evaluating them according to the degree of optimization Edge Scheduler Policy Logger A component that stores executed scheduler policies and their results as logs.

23 is a diagram illustrating an example of an optimization processing flow of an edge service system to which an intelligent scheduler according to the present invention is applied.

The key to optimizing the edge service system to which the intelligent scheduler is applied in the present invention is to provide both a method for optimizing at minimum cost and a method for optimizing at maximum speed.

Referring to FIG. 23 , in the processing sequence of the edge service system to which the intelligent scheduler is applied, first, container platform information may be collected through an information collector for each edge application and an edge cluster information collector.

After that, the edge scheduler policy planner can select a policy from the edge scheduler policy metadata storage based on the information collected through the edge application-specific information collector and the edge cluster information collector.

Then, one of ESP application cost minimization type and ESP application optimization type may be selected according to the load level of the container platform.

After that, containers can be allocated through the edge scheduler policy executor.

Thereafter, evaluation of the edge scheduler policy for each type may be performed through relative comparison before and after applying the edge scheduler policy.

After that, the finally selected edge scheduler policy can be applied as a whole so that there is no unapplied part.

Thereafter, the result of applying the finally selected edge scheduler policy through the edge scheduler policy logger may be stored in the edge scheduler policy log data storage.

After that, the edge scheduler policy trainer can collect stored edge scheduler policy log data, and can create an optimized intelligent edge policy through the edge scheduler policy trainer.

The multi-cloud edge system according to the present invention described above with reference to FIGS. 1 to 23 has the following advantages compared to other systems or existing systems.

High-speed container system - Maintain a high-speed container platform by configuring in-memory-based containers

Resolving memory limitations - Resolving limitations on memory size with an expandable storage structure, and solving problems caused by volatile memory with a backup/restore function through a real-time backup environment

Structure suitable for sharing - Data and images can be shared in memory using the Unifying file system provided by the current system

Kernel merged ease of use - Each module that makes up the system is included in Linux, so you can easily configure and use the system.

User-level network tunneling connection of L3-level multi-cluster - In order to perform multi-cluster network connection at high speed, a high-speed network is constructed by applying a tunneling technique using a kernel bypass network stack.

Provides optimized intelligent scheduler function for collaboration

- Scheduling suitable for low-latency service is possible, and collaboration that integrates vertical and horizontal collaboration can be applied

- Collaboration can be applied at the system level

- Collaboration based on intelligent offloading

- Uninterrupted service connection possible

- Integrated distributed processing including cloud/edge/neighboring edge

- Possible to create efficient intelligent scheduler policy based on log or statistical information

As described above, the multi-cloud edge system according to the present invention is not limited to the configuration and method of the embodiments described above, but the above embodiments are all or all of the embodiments so that various modifications can be made. Some of them may be selectively combined and configured.

110: Cloud 120: Edge
130: neighboring edge
510, 610, 800: In-memory container storage
520, 620, 700: In-Memory Container Storage Engine
710: storage interface 720: storage access distribution module
730: storage control module 810: main memory storage
820: disk storage 910, 1112: image layer
920, 1111: container layer 930: integrated access area
1000, 1120: shared storage 1010: shared data
1110: Node A in-memory container storage
1130: Node B in-memory container storage
1200: in-memory container storage management module
1510: Global Edge Scheduler 1520: Cloud Scheduler
1530: Master Edge Scheduler 1540: Neighbor Edge Scheduler
1800: Edge Scheduler Policy Executor
2100: Distributed-collaborative dynamic batch intelligent analyzer

Claims (7)

core cloud;
A multi-cluster-based first edge (A FIRST EDGE) node system; and
Including a multi-cluster-based near edge (NEAR EDGE) node system,
The multi-cluster-based first edge node system
a plurality of work nodes; and
A multi-cloud edge system, including a master node with a scheduler. The method of claim 1,
A multi-cloud edge system that connects the first edge node system and the near edge node system to a high-speed network according to a tunneling protocol. The method of claim 2,
The multi-cloud edge system further comprising a shared storage device for sharing and storing data according to cooperative operation between the first edge node system and the near edge node system. The method of claim 1,
The multi-cloud edge system further comprising a management node for controlling resources required for collaborative operation based on data of the first edge node system and the near edge node system. The method of claim 1,
The first edge node system or the near edge node system includes computing nodes,
The computing nodes are a multi-cloud edge system that provides monolithic applications (MONOLITIC APPLICATION), micro services (MICRO SERVICE) and service-type functions (FUNCTION AS A SERVICE) based on a container platform. The method of claim 1,
The first edge node system receives a request for a computational load for a task (TASK) from an external device,
The master node determines a work node where an application capable of performing the task (TASK) is distributed using the scheduler,
The determined working node performs the task,
The multi-cloud edge system, wherein the master node collects the result of performing the task and responds to the external device. The method of claim 1,
A multi-cloud edge system that provides services by vertical collaborative computation provided by the core cloud and the first edge node system and services by horizontal collaborative computation provided by the first edge node system and the near edge node system.

Images