KR20200080458A - Cloud multi-cluster apparatus - Google Patents

Abstract

The present invention relates to a cloud multi-cluster device. The cloud multi-cluster device includes a plurality of cluster parts each including a master node and at least one worker node that are interconnected based on application programming interface (API). The master node includes an API module for providing the API, and the at least one worker node includes a work control module for determining whether load balancing is performed with other cluster parts for specific work based on the load of a corresponding cluster. Therefore, policy sharing and high availability can be provided by forming a plurality of clusters and interworking with other clusters through management controllers inside the clusters.

Description

Cloud multi-cluster device {CLOUD MULTI-CLUSTER APPARATUS}

The present invention relates to a cloud multi-cluster technology, and more specifically, a cloud multi-cluster device capable of providing policy sharing and high availability by configuring multiple multi-clusters and interworking with other clusters through a management controller inside the cluster. It is about.

With the development of cloud systems, various technologies for supporting multi-clusters have been developed in recent years. A computer cluster may correspond to a set of computers in which several computers are connected to behave like one system. The components of the cluster can generally be connected to a high-speed local area network. Each operating system may be executed on a node used as a server.

Computer clusters can be created as a result of a combination of low-cost microprocessors, high-speed networks, and high-performance distributed computing software. Clusters generally provide better performance and reliability than a single computer, and can be much more cost effective than a single computer that provides similar performance and reliability. Therefore, it is widely used, from small to medium-sized clusters of ten or so, to large supercomputers of thousands.

Korean Registered Patent No. 10-1807806 (2017.12.05) relates to a method of containerizing an application on a cloud platform, providing an isolated application execution environment, independent resource allocation, and multiple application operation on the same host. Not only is it possible, OS-level virtualization enables quick operation, it is efficient to deploy and update with a small-sized container image, and it discloses a technology for containerizing applications on a cloud platform that can be moved anywhere.

Korean Registered Patent No. 10-1807806 (2017.12.05)

An embodiment of the present invention is to provide a cloud multi-cluster device capable of providing policy sharing and high availability by configuring multiple multi-clusters and interworking with other clusters through a management controller inside the cluster.

One embodiment of the present invention is to provide a cloud multi-cluster device capable of controlling interworking between multiple clusters through a cluster controller provided for each cluster.

One embodiment of the present invention is to provide a cloud multi-cluster device capable of configuring a multi-cluster in a form in which a cluster control including a scheduler, a load balancer, and a monitoring manager is disposed on a worker node of each cluster.

Among the embodiments, the cloud multi-cluster device includes a plurality of cluster parts each including a master node and at least one worker node interconnected based on an application programming interface (API), and the master node provides the API It includes an API module, and each of the at least one worker node includes a work control module that determines whether to perform load balancing with another cluster unit on a specific work based on the load amount of the corresponding cluster.

The work control module may process control of the load balancing by communicating with a work control module of a corresponding worker node in the other cluster unit.

In the process of controlling the load balancing, the work control module may perform transfer control and transfer transfer of the corresponding load through an ingress module commonly present in the corresponding cluster unit.

When the transfer of the corresponding load is completed, the work control module may receive schedule control through the corresponding master node through the API module.

The work control module may include a load balancer that performs transfer control and transfer transfer necessary for performing the load balancing.

The work control module may further include a scheduler that receives control by the schedule module in the corresponding master node through the API module for scheduling the specific work.

The work control module may further include a monitoring manager that monitors whether the current load is excessive.

The work control module may determine, as the other cluster unit, one of the cluster units in which a response according to the transfer request of the specific work arrives within a specific time when it is predicted that an overload of the current load will exist.

The work control module may continuously monitor the normal performance of the specific work by communicating with the other cluster unit even after the transfer of the specific work is completed through the monitoring manager.

The work control module may notify the requesting device of the specific work that the specific work is abnormal when the abnormal work of the specific work is detected.

The disclosed technology can have the following effects. However, since a specific embodiment does not mean that all of the following effects should be included or only the following effects are included, the scope of rights of the disclosed technology should not be understood as being limited thereby.

The cloud multi-cluster device according to an embodiment of the present invention may control interworking between multiple clusters through a cluster controller provided for each cluster.

In the cloud multi-cluster device according to an embodiment of the present invention, a cluster control including a scheduler, a load balancer, and a monitoring manager may be configured to form a multi-cluster in a form arranged in a worker node of each cluster.

1 is a diagram illustrating a physical configuration of a cloud multi-cluster device according to an embodiment of the present invention.
2 is a diagram illustrating a cloud multi-cluster device according to an embodiment of the present invention.
3 is a diagram illustrating an operation between cluster units according to an embodiment of the present invention.
4 is a flowchart illustrating a multi-cluster operation process performed in a cloud multi-cluster device according to an embodiment of the present invention.

Since the description of the present invention is merely an embodiment for structural or functional description, the scope of the present invention should not be interpreted as being limited by the embodiments described in the text. That is, since the embodiments can be variously changed and have various forms, it should be understood that the scope of the present invention includes equivalents capable of realizing technical ideas. In addition, the purpose or effect presented in the present invention does not mean that a specific embodiment should include all of them or only such an effect, and the scope of the present invention should not be understood as being limited thereby.

Meanwhile, the meaning of terms described in the present application should be understood as follows.

Terms such as “first” and “second” are for distinguishing one component from other components, and the scope of rights should not be limited by these terms. For example, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component.

When a component is said to be "connected" to another component, it may be understood that other components may exist in the middle, although they may be directly connected to other components. On the other hand, when a component is said to be "directly connected" to another component, it should be understood that no other component exists in the middle. On the other hand, other expressions describing the relationship between the components, that is, "between" and "immediately between" or "adjacent to" and "directly neighboring to" should be interpreted similarly.

Singular expressions are to be understood as including plural expressions unless the context clearly indicates otherwise, and terms such as “comprises” or “have” are used features, numbers, steps, actions, elements, parts or the like. It is to be understood that a combination is intended to indicate the existence, and does not preclude the existence or addition possibility of one or more other features or numbers, steps, operations, components, parts or combinations thereof.

In each step, the identification code (for example, a, b, c, etc.) is used for convenience of explanation. The identification code does not describe the order of each step, and each step clearly identifies a specific order in context. Unless stated, it may occur in a different order than specified. That is, each step may occur in the same order as specified, or may be performed substantially simultaneously, or in the reverse order.

The present invention can be embodied as computer readable code on a computer readable recording medium, and the computer readable recording medium includes all kinds of recording devices in which data readable by a computer system is stored. . Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disks, and optical data storage devices. In addition, the computer-readable recording medium can be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

All terms used herein have the same meaning as generally understood by a person skilled in the art to which the present invention pertains, unless otherwise defined. The terms defined in the commonly used dictionary should be interpreted as being consistent with meanings in the context of the related art, and cannot be interpreted as having ideal or excessively formal meanings unless explicitly defined in the present application.

1 is a diagram illustrating a physical configuration of a cloud multi-cluster device according to an embodiment of the present invention.

Referring to FIG. 1, the cloud multi-cluster device 100 may include a processor 110, a memory 130, a user input/output unit 150, and a network input/output unit 170.

The cloud multi-cluster device 100 may be implemented as a server corresponding to a computer or program capable of configuring multiple multi-clusters and controlling operations between clusters. The basic configurations constituting the cloud multi-cluster device 100 may be described as follows, but are not limited thereto, and may be implemented in various forms including additional components for basic and application operations. .

The processor 110 may execute each procedure in the process of configuring multi-clusters and controlling operations between clusters, and may manage the memory 130 that is read or written throughout the process, and is located in the memory 130. The synchronization time between volatile memory and non-volatile memory can be scheduled. The processor 110 can control the overall operation of the cloud multi-cluster device 100 and is electrically connected to the memory 130, the user input/output unit 150, and the network input/output unit 170 to control data flow therebetween. Can be controlled. The processor 110 may be implemented as a central processing unit (CPU) of the cloud multi-cluster device 100.

The memory 130 may be implemented as a non-volatile memory such as a solid state disk (SSD) or a hard disk drive (HDD), and may include auxiliary storage devices used to store overall data required for the cloud multi-cluster device 100. And may include a main memory device implemented with volatile memory such as random access memory (RAM).

The user input/output unit 150 may include an environment for receiving user input and an environment for outputting specific information to the user. For example, the user input/output unit 150 may include an input device including an adapter such as a touch pad, a touch screen, an image keyboard, or a pointing device, and an output device including an adapter such as a monitor or touch screen. In one embodiment, the user input/output unit 150 may correspond to a computing device connected through a remote connection, and in such a case, the cloud multi-cluster device 100 may be performed as a server.

The network input/output unit 170 includes an environment for connecting to an external device or system through a network, for example, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), and a VAN ( Value Added Network).

2 is a diagram illustrating a cloud multi-cluster device according to an embodiment of the present invention.

Referring to FIG. 2, the cloud multi-cluster device 100 may include a plurality of cluster units 210 each including an interconnected master node and at least one worker node based on an API (Application Programming Interface). Here, the cluster unit 210 may correspond to a unit system that serves to provide applications, system resources, and data to users without interruption while operating as a single system in which two or more systems or nodes are continuously available. have. The cluster unit 210 may correspond to a set of virtual/physical machines composed of a master node 211 and at least one worker node 213, and each node therein It can operate as a full-featured standalone system.

In addition, the master node 211 inside the cluster unit 210 and at least one worker node 213 may be interconnected to provide high availability while operating as one entity. That is, the cluster unit 210 can provide almost uninterrupted access to data and applications by controlling the cluster to continue to run even if an error occurs that causes a single server system to crash. Such errors may include errors in hardware, software, or networks.

The master node 211 may perform a role of managing the worker node 213, and the load amount of each worker node 213, etc. through the management module (for example, the agent of FIG. 2) of the worker node 213 The state can be grasped, and load balancing for the corresponding cluster unit 210 can be performed through the optimal pod arrangement between the work nodes 213. In one embodiment, the master node 211 may be implemented by including an API module 215 that manages an API, for example, the API module 215 may correspond to an API server. In another embodiment, the master node 211 may include a scheduler, a controller manager, and a database etcd.

Here, the scheduler (scheduler) can manage the newly created pod and serve to determine the node to deploy the pod, and the controller manager (Controller Manager) can perform the role of managing the controller, and the database ( etcd) may correspond to a distributed key value store that allows data to be stored and shared across a distributed cluster of machines. The API module 215 may control the scheduler, controller manager, and database (etcd).

The worker node 213 can run multiple service pods, and one pod can contain multiple containers. In other words, a service pod may consist of one or more associated containers. In one embodiment, the pod may correspond to a minimum deployment/deployment unit. In addition, the worker node 213 may include a management agent for communicating with the master node 211, a plurality of service pods, and a cluster controller for multi-cluster management. The management agent can control the cluster controller and service pod.

In one embodiment, the worker node 213 may include a work control module 217 that determines whether to perform load balancing with another cluster unit 210 for a specific worker based on the load amount of the cluster unit 210. have. Here, the work control module 217 may serve to control interworking between the cluster units 210 for the purpose of configuring a multi-cluster, and a plurality of pods included in the worker node 213 It may be implemented as one of them, for example, may correspond to the cluster controller (cluster controller) of FIG. 2. The work control module 217 may provide policy sharing and high availability through interworking between the corresponding cluster unit 210 and other cluster units 210.

In one embodiment, the work control module 217 communicates with the work control module 217 of the corresponding worker node 213 in the other cluster unit 210 to handle control of load balancing. Here, load balancing may correspond to an operation of resolving this by appropriately distributing and processing multiple servers considering load increase, load, and speed reduction of the servers when the traffic generated by the service is high. . The work control module 217 may serve to control load balancing between the cluster units 210 when there are multiple cluster units 210.

More specifically, the work control module 217 may perform load transfer to another cluster unit 210 when the load of the corresponding cluster unit 210 is high, and in this case, the load in the cluster unit 210 is a worker node. It may be measured by the required computation amount of the work (work) performed in the service pod of (213), the load transfer may correspond to the transmission of a specific work.

In one embodiment, the work control module 217 performs transfer control and transfer transfer of the corresponding load through an ingress module 219 commonly present in the corresponding cluster unit 210 in the process of controlling load balancing. can do. The ingress module 219 may correspond to a component that provides load balancing for a single cluster based on HTTP(s). For example, in FIG. 2, the ingress module 219 receives a service request from an external network (External N/W) to a single cluster unit 210 and connects to a service pod inside the worker node 213 It can play a role. If the multi-cluster unit 210 operates, different cluster units 210 may be intermediary, and for example, transfer control and transfer of load may be performed.

In one embodiment, the work control module 217 may receive the schedule control through the master node 211 through the API module 215 when the transfer of the transfer of the load is completed. The master node 211 may serve to allocate each resource of the corresponding cluster unit 210 to an appropriate node through the scheduler, and when the transfer transfer of the load by the work control module 217 is completed, transfer the transfer result. You can update the entire scheduling that you have reflected. Therefore, the work control module 217 may receive the updated scheduling information through the API module 215 when the transfer of the load is completed.

In one embodiment, the work control module 217 may determine that one of the cluster units, in which a response according to a request to transfer a specific work arrives within a specific time, is determined as another cluster unit if it is predicted that an overload of the current load is expected. For example, the work control module 217 determines the cluster unit 210 that is the target for transfer of transfer based on a preset priority when the plurality of cluster units 210 having a response arrive within a specific time or the response arrival time The fastest cluster unit 210 may be determined as the transfer target, and the cluster unit 210 having the smallest number of services or work currently being processed may be determined as the transfer target.

In one embodiment, the work control module 217 may calculate a response waiting time according to a request to transfer a specific work through the following equation. Accordingly, the work control module 217 may determine one of the cluster units arriving within the response waiting time as the other cluster unit 210.

[Mathematics]

Here, D is the response waiting time, D ₀ is the basic waiting time, k is the proportional constant, N _c is the number of currently active cluster units, N _aw is the average number of worker nodes per cluster unit, W is It may mean the entire load of the work running in a specific cluster part. Here, W may correspond to a computational amount required to process the work in operation, and may be expressed as a total amount of resources or time required for processing the work. The greater the number of cluster units 210 operating in the entire system, and the greater the number of worker nodes 213 operating in each cluster unit 210, the shorter the response waiting time may be, and the entire system due to the currently operating work. The response wait time may increase as the sum of the loads increases.

3 is a diagram illustrating an operation between cluster units according to an embodiment of the present invention.

Referring to FIG. 3, the cloud multi-cluster device 100 may configure and manage a plurality of cluster units 210. The cluster unit 210 may include a master node 211 and at least one worker node 213, and the cluster unit 210 communicates with other external cluster units 210 through the work control module 217. can do. Here, the work control module 217 may correspond to a cluster controller. In FIG. 3, the work control module 217 may be implemented by including an interface for communicating with the API module 215 of the master node 211.

In one embodiment, the work control module 217 may include a load balancer 313 that performs transfer control and transfer transfer necessary for performing load balancing. The load balancer 313 may perform transfer of a specific work to another cluster unit 210 or receive a specific work transferred from the other cluster unit 210. In addition, the load balancer 313 may communicate with the external load balancer 313 in conjunction with the ingress module 219.

In one embodiment, the work control module 217 may further include a scheduler 311 that receives control by the schedule module in the corresponding master node 211 through the API module for scheduling a specific work. The scheduler 311 may receive the schedule control from the master node 211 through an interface, and based on this, the scheduler 311 may schedule the work, for example, a service pod to execute the work. You can assign or redeploy work between service pods.

In one embodiment, the work control module 217 may further include a monitoring manager 315 that monitors whether the current load is excessive. The monitoring manager 315 may include Pod configuration management, Monitor management, Service management, and Node configuration management. The monitoring manager 315 may monitor and manage various resources processed by the worker node 213 through interworking with the load balancer 313, and provide information for load balancing between the clusters 210 can do.

In one embodiment, the work control module 217 may continuously monitor the normal performance of a specific work by communicating with another cluster unit 210 even after the transfer of the specific work is completed through the monitoring manager 315. The monitoring manager 315 may periodically receive information related to a specific work transferred to another cluster unit 210 in addition to resource monitoring of the corresponding cluster unit 210 through the monitoring manager 315 of the other cluster unit 210. have. To this end, the monitoring manager 315 may separately manage information regarding a work that does not exist in the corresponding cluster unit 210, and periodically update status information for each work.

In one embodiment, the work control module 217 may notify the requesting device of the specific work when the abnormal performance of the specific work is detected. Even if the execution location is changed from a specific cluster unit 210 to another cluster unit 210 by transfer, the work control module 217 can track and manage the execution state of a specific work through the monitoring manager 315, If an abnormal performance is detected after the transfer to the other cluster unit 210, the corresponding information may be provided to the requesting device requesting execution of the corresponding work. In this case, the information provided to the requesting device may include information on the corresponding work, information on the cluster unit 210 to which the corresponding work is assigned, and information on a worker node and a service pod in which the corresponding work is disposed.

4 is a flowchart illustrating a multi-cluster operation process performed in a cloud multi-cluster device according to an embodiment of the present invention.

Referring to FIG. 4, the cloud multi-cluster device 100 may configure a multi-cluster by generating a plurality of cluster units 210 and monitor whether the cluster unit 210 is overloaded (step). S410). The cloud multi-cluster device 100 may request the transfer of a specific work to the other cluster unit 210 when the load overload of the specific cluster unit 210 is predicted (step S430).

The cloud multi-cluster device 100 may determine one of the cluster units 210 to which the response according to the transfer request arrives within a specific time as a transfer target (step S450). The cloud multi-cluster device 100 may monitor the normal performance of a specific work by communicating with another cluster unit 210 after the transfer of the specific work is completed (step S470). In one embodiment, the cloud multi-cluster device 100 may notify the requesting device of the specific work that the specific work is abnormal when the abnormal performance of the specific work is detected through the work control module 217.

Although described above with reference to preferred embodiments of the present invention, those skilled in the art variously modify and change the present invention without departing from the spirit and scope of the present invention as set forth in the claims below. You can understand that you can.

100: cloud multi-cluster device
110: processor 130: memory
150: user input/output unit 170: network input/output unit
210: cluster unit 211: master node
213: worker node 215: API module
217: Work control module 219: Ingress module
311: Scheduler 313: Load Balancer
315: monitoring manager

Claims (10)

Based on the API (Application Programming Interface), and includes a plurality of clusters each comprising a master node and at least one worker node interconnected,
The master node includes an API module that provides the API,
Each of the at least one worker node is a cloud multi-cluster device including a work control module for determining whether to perform load balancing with another cluster unit on a specific work based on the load amount of the corresponding cluster.
According to claim 1, The work control module
Cloud multi-cluster device, characterized in that for processing the control of the load balancing by communicating with the work control module of the worker node in the other cluster unit.
According to claim 2, The work control module
Cloud multi-cluster device, characterized in that during the load balancing control process, transfer control and transfer of the load are performed through an ingress module commonly present in the corresponding cluster.
According to claim 3, The work control module
The cloud multi-cluster device, characterized in that when the transfer of the corresponding load is completed, the schedule control through the corresponding master node is received through the API module.
According to claim 1, The work control module
Cloud load multi-cluster device, characterized in that it comprises a load balancer (load balancer) for performing the transfer control and transfer transfer required to perform the load balancing.
According to claim 5, The work control module
And a scheduler receiving control by the schedule module in the corresponding master node through the API module for scheduling the specific work.
According to claim 6, The work control module
Cloud multi-cluster device further comprising a monitoring manager (monitoring manager) for monitoring whether the current load.
The work control module of claim 7, wherein the work control module
Cloud multi-cluster device, characterized in that when it is predicted that an overload of the current load will exist, one of the cluster units to which the response according to the transfer request of the specific work arrives within a certain time is determined as the other cluster unit.
The work control module of claim 7, wherein the work control module
The cloud multi-cluster device, characterized in that, after the migration of the specific work is completed through the monitoring manager, the normal performance of the specific work is continuously monitored by communicating with the other cluster unit.
10. The method of claim 9, The work control module
The cloud multi-cluster device, characterized in that when the abnormal performance of the specific work is detected, the requesting device of the specific work is notified of the abnormal performance of the specific work.

Images