KR20230174137A - Method and apparatus for data synchronization in container-based multi cluster environment - Google Patents

Abstract

This disclosure generally relates to a container-based cluster environment, and more specifically to a method and apparatus for data synchronization in a container-based multi-cluster environment. According to an embodiment of the present disclosure, in a method performed by a second element management system (EMS) of a second cluster, the method includes: A process of executing a service pod in a standby state that is not in service, a process of identifying the state of the second EMS, and when the state of the second EMS is the standby state, the first EMS from the first EMS of the first cluster 1 A process of receiving data stored in a cluster and data related to an application running in the first EMS, identifying a state of the first EMS, and determining whether the state of the first EMS is standby or the EMS is not running. In the case of an abnormal state, the process may include changing the state of the second EMS to an active state in which the service pod is running and in service, based on the file and the database.

Description

Method and apparatus for data synchronization in a container-based multi-cluster environment {METHOD AND APPARATUS FOR DATA SYNCHRONIZATION IN CONTAINER-BASED MULTI CLUSTER ENVIRONMENT}

This disclosure generally relates to a container-based cluster environment, and more specifically to a method and apparatus for data synchronization in a container-based multi-cluster environment.

Containers virtualize the underlying operating system (OS) and allow containerized apps to recognize that they contain the OS itself, including a central processing unit (CPU), memory, file storage, and network connectivity. Therefore, containers can be deployed and run anywhere.

Containers share the host OS, so there is no need to boot the OS or load libraries. This makes containers much more efficient and lightweight. Container-based applications can be started within seconds, and compared to virtual machine (VM) scenarios, more instances of the application can fit on the machine. The shared OS approach has the added benefit of reduced overhead associated with maintenance, such as patches and updates.

Based on the above-described discussion, this disclosure seeks to provide a method and device for data synchronization of container applications in a container-based multi-cluster environment.

In addition, the present disclosure seeks to provide a method and device for transferring databases and files so that they can be immediately executed in other containers through real-time synchronization between clusters when a failure occurs in one cluster in a container-based multi-cluster environment.

According to various embodiments of the present disclosure, in a method performed by a second EMS (element management system) of a second cluster, the method is executed by loading an initialization container (init container) included in the second EMS. A process of executing a service pod in a standby state that is not in service, a process of identifying the state of the second EMS, and when the state of the second EMS is the standby state, the first EMS from the first EMS of the first cluster 1 A process of receiving data stored in a cluster and data related to an application running in the first EMS, identifying a state of the first EMS, and determining whether the state of the first EMS is standby or the EMS is not running. In the case of an abnormal state, the process may include changing the state of the second EMS to an active state in which the service pod is running and in service, based on the file and the database.

According to various embodiments of the present disclosure, in a method performed by a first element management system (EMS) of a first cluster, the method is performed by loading an initialization container that is included in the first EMS. Executing a service pod in a standby state and not in service, identifying a state of the first EMS, and if the state of the first EMS is in an active state in which the service pod is running and in service, It may include transmitting data stored in the first cluster and data related to an application being executed by the first EMS to the second EMS of the second cluster.

According to various embodiments of the present disclosure, in a second element management system (EMS) of a second cluster, the second EMS includes a transceiver and at least one processor coupled to the transceiver, At least one processor executes a running but not serviced standby service pod included in the second EMS by loading an initialization container, identifies the state of the second EMS, and executes the second EMS. When the state of the EMS is the standby state, receive data stored in the first cluster and data related to an application running in the first EMS from the first EMS of the first cluster, identify the state of the first EMS, and , If the state of the first EMS is a standby state or an abnormal state in which the EMS is not running, change the state of the second EMS to an active state in which the service pod is running and serviced based on the file and the database. It can be set to do so.

According to various embodiments of the present disclosure, in a first element management system (EMS) of a first cluster, the first EMS includes a transceiver and at least one processor coupled to the transceiver, The at least one processor executes a running but not serviced service pod included in the first EMS by loading an initialization container, identifies the state of the first EMS, and executes the first EMS. If the state of 1 EMS is in an active state where the service pod is running and in service, it may be configured to transmit data stored in the first cluster and data related to the application that the first EMS is running.

The present disclosure provides a method and device for transferring databases and files so that they can be immediately executed in other containers through real-time synchronization between clusters when a failure occurs in a container-based multi-cluster environment, which has the effect of eliminating the need for external storage.

The present disclosure provides a method and device for transferring databases and files so that they can be immediately executed in other containers through real-time synchronization between clusters when a failure occurs in a container-based multi-cluster environment, which has the effect of fast updating.

The effects that can be obtained from the present disclosure are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by those skilled in the art from the description below. will be.

Figure 1 illustrates a container-based cluster environment for real-time data synchronization according to an embodiment of the present disclosure.
Figure 2 illustrates a scenario when an abnormal state occurs due to an abnormal situation in a container-based cluster environment for real-time data synchronization according to an embodiment of the present disclosure.
Figure 3 is a diagram showing the state of a pod according to an embodiment of the present disclosure.
Figure 4 is a diagram showing the types of pods according to an embodiment of the present disclosure.
Figure 5 is a diagram showing the lifespan of a pod according to an embodiment of the present disclosure.
Figure 6 shows a flowchart showing a process in which a Pod executes an application according to an embodiment of the present disclosure.
Figure 7 shows a flowchart for EMS to synchronize data according to an embodiment of the present disclosure.
Figure 8 shows a flowchart for EMS to synchronize data according to an embodiment of the present disclosure.
Figure 9 shows a flow chart illustrating a second EMS performing data synchronization according to an embodiment of the present disclosure.
Figure 10 shows a flowchart showing a first EMS performing data synchronization according to an embodiment of the present disclosure.
Figure 11 shows a device diagram in a container-based cluster environment according to an embodiment of the present disclosure.

Hereinafter, embodiments of the present invention will be described in detail with the accompanying drawings. Additionally, when describing the present invention, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the gist of the present invention, the detailed description will be omitted. The terms described below are defined in consideration of the functions in the present invention, and may vary depending on the intention or custom of the user or operator. Therefore, the definition should be made based on the contents throughout this specification.

In addition, in describing the embodiments of the present invention in detail, the main gist of the present invention can be applied to other communication systems with similar technical background and channel type with slight modifications without significantly departing from the scope of the present invention. This may be possible at the discretion of a person skilled in the technical field of the present invention.

The advantages and features of the present invention and methods for achieving them will become clear by referring to the embodiments described in detail below along with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms. The present embodiments are merely provided to ensure that the disclosure of the present invention is complete and to provide common knowledge in the technical field to which the present invention pertains. It is provided to fully inform those who have the scope of the invention, and the present invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

At this time, it will be understood that each block of the processing flow diagram diagrams and combinations of the flow diagram diagrams can be performed by computer program instructions. These computer program instructions can be mounted on a processor of a general-purpose computer, special-purpose computer, or other programmable data processing equipment, so that the instructions performed through the processor of the computer or other programmable data processing equipment are described in the flow chart block(s). It creates the means to perform functions. These computer program instructions may also be stored in computer-usable or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement a function in a particular manner, so that the computer-usable or computer-readable memory It is also possible to produce manufactured items containing instruction means that perform the functions described in the flowchart block(s). Computer program instructions can also be mounted on a computer or other programmable data processing equipment, so that a series of operational steps are performed on the computer or other programmable data processing equipment to create a process that is executed by the computer, thereby generating a process that is executed by the computer or other programmable data processing equipment. Instructions that perform processing equipment may also provide steps for executing the functions described in the flow diagram block(s).

Additionally, each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s). Additionally, it should be noted that in some alternative execution examples it is possible for the functions mentioned in the blocks to occur out of order. For example, it is possible for two blocks shown in succession to be performed substantially at the same time, or it is possible for the blocks to be performed in reverse order depending on the corresponding function.

At this time, the term '~unit' used in this embodiment refers to software or hardware components such as FPGA or ASIC, and the '~unit' performs certain roles. However, '~part' is not limited to software or hardware. The '~ part' may be configured to reside in an addressable storage medium and may be configured to reproduce on one or more processors. Therefore, as an example, '~ part' refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, and procedures. , subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. The functions provided within the components and 'parts' may be combined into a smaller number of components and 'parts' or may be further separated into additional components and 'parts'. Additionally, components and 'parts' may be implemented to regenerate one or more CPUs within a device or a secure multimedia card.

Containers virtualize the underlying operating system (OS) and allow containerized apps to recognize that they contain the OS itself, including a central processing unit (CPU), memory, file storage, and network connectivity. Therefore, containers can be deployed and run anywhere. Containers can provide the flexibility to run cloud applications on physical or virtual infrastructure. Containers can package the services that make up an application and make them portable across a variety of computer environments for development, testing, and production use. Containers allow you to quickly scale application objects to meet spikes in demand. Additionally, containers can be lighter than VMs (virtual machines) because they use the host's operating system (OS) resources. In a Kubernetes environment, a cluster can deploy an application or service to a network, and can be considered a cluster for a single configuration.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster 100-1 may be used with the same meaning as the state of the first EMS 530 included in the first cluster. For example, the state of the second cluster 100-2 may be used in the same sense as the state of the second EMS 540 included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

If the application included in the container-based cluster is a stateful application, when one container-based cluster is active, the remaining container-based cluster may need to remain in a standby state. Active state - Remaining active can have the following problems:

- Task complexity: Active state - When active, NEs (network elements) must be distributed across clusters, otherwise it may be error-prone for the operator.

- Data conflicts: Active - If active, both clusters are running, if both clusters are updated, synchronization may be delayed and service may not be guaranteed or may not function properly.

- Synchronization data must be bidirectional, and data conflicts may occur during data replication.

However, container-based clusters do not support active-standby states. For example, if there are two container-based clusters, active-standby state may mean that when the EMS of one container-based cluster is active, the EMS of the other container-based cluster is in standby state.

In container-based applications, there was a problem where the backup server was connected to the outside when an abnormal situation occurred in one cluster. If the application included in a container-based cluster is a stateful application, a one-to-one mapping relationship may occur between the active cluster and the standby cluster. Therefore, data had to be synchronized from the active cluster to the backup site and from the backup site to the standby cluster. Data may include file data and data for application execution. A file may refer to data related to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing.

In container-based applications, external storage is required for backup, and data must be backed up and managed externally. Problems that may arise from this are as follows:

Synchronization may take a lot of time.

More data may be transferred than the external storage can store.

Due to the large amount of time synchronization takes, your data may be out of date.

In order to solve this problem, the present disclosure provides a method for inter-cluster synchronization.

Figure 1 illustrates a container-based cluster environment for real-time data synchronization according to an embodiment of the present disclosure.

Referring to FIG. 1, the network environment may include a first cluster 100-1 and a second cluster 100-2. In Figure 1, the cluster is shown as including a first cluster (100-1) and a second cluster (100-2), but this is only for convenience of explanation and does not exclude an environment such as the presence of additional clusters. . Additionally, the network environment may include a first network 130-1 and a second network 130-2. In FIG. 1, the network is shown as including a first network 130-1 and a second network 130-2, but this is only for convenience of explanation and does not exclude an environment such as having three or more networks. no.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster 100-1 may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster 100-2 may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

The first cluster 100-1 includes one or more first worker nodes (110-1), one or more first persistent volumes (PVs) (113a-1, 113b-1), and a first master node (master) node) (120-1). Each of the one or more first worker nodes (110-1) may include one or more first pods (111a-1, 111b-1), and one or more first pods (111a-1, 111b-1), Each of 111b-1) may be connected to one or more first PVs 113a-1 and 113b-1, respectively. The first cluster 100-1 may communicate with the first network 130-1. The first cluster 100-1 may communicate with the second network 130-2. The first network 130-1 and the second network 130-2 may be logically or regionally divided.

The second cluster 100-2 may be logically or regionally distinguished from the first cluster 100-1. The second cluster 100-2 may include one or more second worker nodes 110-2, one or more second PVs 113a-2 and 113b-2, and a master node 120-2. Each of one or more second worker nodes 110-2 may include one or more second pods 111a-2 and 111b-2, and one or more second pods 111a-2 and 111b-2. ) Each may be connected to one or more second PVs 113a-2 and 113b-2, respectively. The second cluster 100-2 may communicate with the first network 130-1. The second cluster 100-2 may communicate with the second network 130-2.

Hereinafter, the description of each of the first cluster 100-1 and the second cluster 100-2 may be applied as a description of the cluster. Descriptions of each of the one or more first worker nodes 110-1 and one or more second worker nodes 110-2 may be applied as descriptions of the worker nodes. The description of each of the one or more first pods 111a-1 and 111b-1 and the one or more second pods 111a-2 and 111b-2 may be applied as a description of the pod. The description of each of the one or more first PVs 113a-1 and 113b-1 and the one or more second PVs 113a-2 and 113b-2 may be applied as a description of the PV. The description of each of the first master node 120-1 and the second master node 120-2 may be applied as a description of the master node. The description of each of the first network 130-1 and the second network 130-2 may be applied as a description of the network.

A cluster may refer to a set of nodes in a physical or virtual environment that hosts a container-based application. Clusters can be largely divided into worker nodes and master nodes. A worker node is a node where one or more containers are deployed, and a master node may be a node that manages worker nodes. The cluster's master node allows the administrator to control the entire cluster.

A worker node can contain multiple pods. Container-based clusters can be run by placing containers into pods to run on worker nodes. Worker nodes can be virtual machines (VMs) or physical machines (PMs), depending on the cluster. Each worker node can be managed by the master node. Specifically, each worker node can be managed by a control plane within the master node. According to one embodiment of the present disclosure, each worker node may include services required to run a pod. According to an embodiment of the present disclosure, a cluster may include multiple worker nodes.

A pod can be the smallest unit of compute that can be created, managed, and deployed in a container-based cluster. According to one embodiment of the present disclosure, a Pod is a group of one or more containers that include shared storage and network resources and specifications for how to run the containers. For example, the shared storage could be PV.

PV can be the storage of a cluster. Specifically, it can be storage in a cluster that has been provisioned by an administrator or provisioned using a storage class. PV is a resource of the cluster, just as worker nodes are a resource of the cluster. PVs can have a lifetime independent of the individual pods using them.

A master node may include a control plane and a data plane. According to an embodiment of the present disclosure, the control plane may be responsible for allocating a classless inter domain routing (CIDR) block to the node when the worker node is registered. According to one embodiment of the present disclosure, the control plane may be responsible for keeping the list of worker nodes up to date with the cloud provider's list of available systems. Specifically, when the control plane is running in a cloud environment and the worker node is abnormal, it can ask the cloud provider whether the VM of that worker node can continue to be used. If the worker node cannot continue to be used, the control plane can delete the worker node from the list of worker nodes. According to one embodiment of the present disclosure, the control plane may monitor the status of the node.

The network is a radio access network and can function as a wireless access network. A network may be an object that provides a wireless channel for accessing the 5G core network. A network can be connected to a cluster. Additionally, the network may be a wired network.

According to an embodiment of the present disclosure, the first cluster 100-1 may be a cluster in an active state. According to an embodiment of the present disclosure, the second cluster 100-2 may be a cluster in a standby state. A cluster in an active state may mean that the service pods included in the cluster are running and in a state of becoming a service. A cluster in a standby state may mean that service pods included in the cluster are running but are not in service. Here, a synchronization pod, as distinct from a service pod, can mean a state that is running and in service, regardless of whether it is active or standby. Synchronization pods can include high availability (HA) pods, database pods, and file replication pods. HA pods are high-availability pods, which can refer to pods that determine the status of the cluster's EMS. A database pod can be a pod for database synchronization. A file replication pod can be a pod for synchronization of files.

Data may be synchronized in real time from each of one or more first PVs 113a-1 and 113b-1 to one or more second PVs 113a-2 and 113b-2. Data may include file data and data for application execution. A file may refer to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing.

According to an embodiment of the present disclosure, one or more first pods 111a-1 and 111b-1 included in the first cluster 100-1 and one or more second pods included in the second cluster 100-2 It can be synchronized in real time by the pods 111a-2 and 111b-2. Through this real-time synchronization, even if the state of the first cluster 100-1 changes from an active state to a standby state or an abnormal state due to an abnormal situation, the second cluster 100-2 is connected to the first cluster 100-1. You can immediately run the application you were running. The second cluster 100-2 may change the state of the second cluster from the standby state to the active state in order to immediately execute the application being executed in the first cluster 100-1.

According to an embodiment of the present disclosure, for real-time synchronization, synchronization pods included in the cluster must be running even in standby state. In other words, the standby state for real-time synchronization may mean that the synchronization pods included in the cluster are running and services are also available from the synchronization pods.

Additionally, such real-time synchronization may require the Service Pod to be running even in standby mode. A service pod running in a standby state may mean that the service pod is running but the service is not running.

Hereinafter, through FIG. 2, a scenario in which the second cluster 100-2 immediately executes the application through data synchronization when the first cluster 100-1 in an active state changes to an abnormal state due to an abnormal situation is described. .

Figure 2 illustrates a scenario when an abnormal state occurs due to an abnormal situation in a container-based cluster environment for real-time data synchronization according to an embodiment of the present disclosure.

Referring to FIG. 2, the network environment may include a first cluster 200-1 and a second cluster 200-2. In Figure 2, the cluster is shown as including a first cluster 200-1 and a second cluster 200-2, but this is only for convenience of explanation and does not exclude an environment such as the presence of additional clusters. . Additionally, the network environment may include a first network 230-1 and a second network 230-2. In FIG. 2, the network is shown as including a first network 230-1 and a second network 230-2, but this is only for convenience of explanation and does not exclude an environment such as having three or more networks. no.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster 210 may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster 220 may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

The first cluster 200-1 includes one or more first worker nodes (210-1), one or more first persistent volumes (PVs) (213a-1, 213b-1), and a first master node (master) node) (220-1). Each of the one or more first worker nodes (210-1) may include one or more first pods (211a-1, 211b-1), and one or more first pods (211a-1, 211b-1) may each be connected to one or more first PVs 213a-1 and 213b-1. The first cluster 200-1 may communicate with the first network 230-1. The first cluster 200-1 may communicate with the second network 230-2. The first network 230-1 and the second network 230-2 may be logically or regionally divided.

The second cluster 200-2 may be logically or regionally distinguished from the first cluster 200-1. The second cluster 200-2 may include one or more second worker nodes 210-2, one or more second PVs 213a-2 and 213b-2, and a master node 220-2. Each of one or more second worker nodes 210-2 may include one or more second pods 211a-2 and 211b-2, and one or more second pods 211a-2 and 211b-2. ) Each may be connected to one or more second PVs 213a-2 and 213b-2, respectively. The second cluster 200-2 may communicate with the first network 230-1. The second cluster 200-2 may communicate with the second network 230-2.

Hereinafter, the description of each of the first cluster 200-1 and the second cluster 200-2 may be applied as a description of the cluster. Descriptions of each of the one or more first worker nodes 210-1 and one or more second worker nodes 210-2 may be applied as descriptions of the worker nodes. The description of each of the one or more first pods 211a-1 and 211b-1 and the one or more second pods 211a-2 and 211b-2 may be applied as a description of the pod. The description of each of the one or more first PVs 213a-1 and 213b-1 and the one or more second PVs 213a-2 and 213b-2 may be applied as a description of the PV. The description of each of the first master node 220-1 and the second master node 220-2 may be applied as a description of the master node. The description of each of the first network 230-1 and the second network 230-2 may be applied as a description of the network.

Referring to FIG. 2, it can be seen that an abnormal situation occurred in the first cluster 200-1. For example, abnormal situations may be pod abnormalities and infrastructure abnormalities. Abnormalities in the infrastructure may include worker node crashes, cluster-level crashes, storage crashes, or independent service or network abnormalities.

According to an embodiment of the present disclosure, when an abnormal situation occurs in the first cluster 200-1 and the first cluster 200-1 enters an abnormal state, the second cluster 200-2 may change from the standby state to the active state. Through real-time synchronization, even if the state of the first cluster 200-1 changes from the active state to the standby state or to the abnormal state due to an abnormal situation, the second cluster 200-2 runs in the first cluster 200-1. You can immediately run the application you were using. This includes one or more first PVs (213a-1, 213b-1) included in the first cluster (200-1) and one or more second PVs (113a-2, 113b) included in the second cluster (100-2). This may be because -2) is synchronized in real time. Real-time synchronization is one or more first pods 111a-1 and 111b-1 included in the first cluster 100-1 and one or more second pods 111a-2 included in the second cluster 100-2. 111b-2). Through real-time synchronization, even if the state of the first cluster (200-1) changes to an abnormal state due to an abnormal situation, the second cluster (200-2) can immediately run the application that was running in the first cluster (200-1). there is. Identification of abnormal conditions may be made by the HA pod.

This real-time synchronization may require the synchronization pod to be running even in standby state. A synchronization pod running in a standby state may mean a state in which the synchronization pod is running and in service.

Synchronization pods can include high availability (HA) pods, database pods, and file replication pods. HA pods are high-availability pods, which can refer to pods that determine the status of the cluster's EMS. A database pod can be a pod for database synchronization. A file replication pod can be a pod for synchronization of files.

Additionally, such real-time synchronization may require the Service Pod to be running even in standby mode. A service pod running in a standby state may mean that the service pod is running but the service is not running. Specifically, this is explained in more detail in Figure 3.

Figure 3 is a diagram showing the state of a pod according to an embodiment of the present disclosure.

Referring to Figure 3, a Pod can contain three states. Specifically, the three states of a pod can be represented as a pod that is running but not in service (301), a pod that is running and in service (303), and a pod in an abnormal state (305). All three states of a pod can be controlled by the EMS. In Figure 3, only three states of the pod are shown, but this is only for convenience of explanation and does not exclude additional states. This is explained in more detail in the description related to FIG. 5.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

Synchronization pods can include high availability (HA) pods, database pods, and file replication pods. HA pods are high-availability pods, which can refer to pods that determine the status of the cluster's EMS. A database pod can be a pod for database synchronization. A file replication pod can be a pod for synchronization of files.

Pod 301 that is running but not in service may refer to a service pod in a cluster in a standby state. Pods are controlled by the cluster's EMS and can be part of the cluster's EMS. A cluster in a standby state does not run services, but needs to run service pods for data synchronization. Running may mean that it is running for EMS service. Additionally, running may mean that it is running to synchronize data even in a standby state. Data may include file data and data for application execution. A file may refer to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing. Not providing the service may mean that the service for executing the EMS service application is not available. In other words, this means that the EMS service application is not running. A Pod 301 that is running but not in service may mean that only the initialization container is loaded and other containers are not loaded.

A running and serviced pod 303 may refer to a service pod in an active cluster. Additionally, a synchronization pod, as distinct from a service pod, can be a pod 303 that is running and being serviced, regardless of whether it is active or standby. Pods are controlled by the cluster's EMS and can be part of the cluster's EMS. Becoming a service may mean that it is becoming a service for executing an EMS service application. In other words, this may mean that the EMS service application is running. Since the synchronization pods are running in cluster 1 and cluster 2, data can be synchronized. That is, data can be transmitted to other pods. Data may include file data and data for application execution. A file may refer to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing.

Abnormal pod 305 may refer to a pod in a cluster in an abnormal state. Pods are controlled by the cluster's EMS and can be part of the cluster's EMS. A cluster in an abnormal state may be a pod that is not running. The reason it is not executed may be due to an abnormal situation. An abnormal situation is an abnormal situation in the EMS, and can specifically be an abnormal situation in a pod or an abnormal situation in the infrastructure. Abnormalities in the infrastructure may include worker node crashes, cluster-level crashes, storage crashes, or independent service or network abnormalities.

The state of the pod is described in Figure 3. In Figure 4, the types of pods are explained.

Figure 4 is a diagram showing the types of pods according to an embodiment of the present disclosure.

Referring to Figure 4, pods may include four types. Specifically, the four types of pods may include service pods (401), HA pods (403), database pods (305), and file replication pods (307). In Figure 4, only four types of pods are shown, but this is only for convenience of explanation and does not exclude other types. Service pod 401, HA pod 403, database pod 405, and file replication pod 407 can all be controlled by the EMS. HA pods 403, database pods 305, and file replication pods 307, excluding service pods 401, may be included in synchronization pods.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

The service pod 401 may refer to a pod that can run an EMS application. When a cluster is active, it is running and serviceable, allowing you to run applications. That is, when the cluster is active, the service pod 401 may be the pod 303 that is running and becomes a service. If the application included in a container-based cluster is a stateful application, when one cluster is active, the other cluster may need to remain in a standby state. When one cluster is in an active state, the other cluster must be in a standby state, and the standby state may mean that the service pod 401 is running but is not in service. In this cluster standby state, the service pod 401 may be a pod 301 that is running but not in service. In the standby state, the service pod 401 is not serviced, but may need to be running for data synchronization. Data may include file data and data for application execution. A file may refer to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing.

The HA pod 403 is a high availability pod and may refer to a pod that determines its status. The HA pod 403 can determine the status of the cluster. In order to determine the state of the cluster, the HA pod 403 may need to be running and serviced regardless of the state of the cluster. For example, the HA pod 403 may need to be serviced to determine the status of the cluster even when in a standby state. In other words, the HA pod 403 may be a pod 303 that is running and in service regardless of its state.

According to one embodiment of the present disclosure, the HA pod 403 can determine the state of its own cluster. For example, the HA pod 403 can determine the state of other clusters. Additionally, the HA pod 403 can determine the state of the cluster and change the state of the cluster. For example, if your cluster's status is in standby and another cluster is in standby, you can change the status of your cluster to active. For example, if your cluster's status is Standby and another cluster is Standby, you can change the other cluster's status to Active. For example, if your cluster's status is active and another cluster is active, you can change the status of your cluster to standby. For example, if your cluster's status is Active and another cluster is Active, you can change the other cluster's status to Standby. Cluster state changes can be based on priority.

The database pod 405 may be a pod for database synchronization. The database pod 405 allows you to synchronize the database between your cluster and the PVs of other clusters. For data synchronization, the service must be provided regardless of the state of the cluster. That is, the database pod 405 may be a pod 303 that is running and in service regardless of the state of the cluster. This is so that when the status of another cluster changes from active to standby or abnormal due to an abnormal situation, the application that was previously running in the other cluster is immediately executed in its own cluster.

The file replication pod 407 may be a pod for file synchronization. A file may refer to data stored in a cluster. File replication pods 407 allow you to synchronize files between your cluster and PVs of other clusters. For file synchronization, services may need to be provided regardless of the state of the cluster. That is, the file replication pod 407 may be a pod 303 that is running and in service regardless of the state of the cluster. This is to save files in real time for immediately executing applications that were previously running in other clusters in your own cluster when the status of another cluster changes from active to standby or abnormal due to an abnormal situation.

In Figure 4, the types and roles of pods are described. In Figure 5, the lifespan of a pod is explained.

Figure 5 is a diagram showing the lifespan of a pod according to an embodiment of the present disclosure.

Referring to Figure 5, a Pod may include, for example, five states. Specifically, the five states of a Pod can be represented as Pod Pending (501), Pod Running (503), Success (505), Failed (507), and Unknown (509). All five states of a pod can be controlled by EMS. In Figure 5, only five types of pods are shown, but this is only for convenience of explanation and does not exclude additional states.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

Pod pending 501 can mean that a pod has been approved, but one or more containers have not been set up and are not ready to run. The not-ready-to-execute state can include not only the time before the pod is scheduled, but also the time it takes to download the container image over the network.

Pod running 503 may mean that all containers in the pod have been created and at least one container is still running or in the process of starting or restarting.

Success (505) may mean that all containers in the pod were terminated successfully and will not be restarted.

Failure 507 may mean that all containers in the pod have terminated, and at least one container has terminated with failure.

Unknown (509) may mean that the status of the pod cannot be obtained for some reason. This step can usually be caused by a communication error with the node on which the pod is supposed to run.

In Figure 5, the lifespan of the pod is explained. In Figure 6, the process by which a Pod executes an application is explained.

Figure 6 shows a flowchart showing a process in which a Pod executes an application according to an embodiment of the present disclosure.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

Referring to Figure 6, in step 610, the EMS may identify an initialization container (init container). The initializing container may be a container with all required resources running. According to an embodiment of the present disclosure, in an initializing container, the state of the pod included in the EMS of the container may be the pod 301, which is in a state of running but not being serviced. In other words, a Pod 301 that is running but not in service may mean that only the initialization container is loaded and other containers are not loaded.

At step 620, the EMS may identify whether the container is active. This is to run the application when the container is active. According to one embodiment of the present disclosure, the state of a service pod in the active state may be pod 303, which is in a running and serviced state. If the current state of the container is in the standby state, step 630 may be performed. If the current state of the container is active, step 640 may be progressed. According to one embodiment of the present disclosure, status confirmation may be performed by the HA pod 403 included in the EMS.

At step 630, the EMS may wait for a set time interval. According to an embodiment of the present disclosure, the state of the pod included in the EMS of the container may be the pod 301, which is in a state of running but not being serviced.

At step 640, the EMS may execute the application. The state of a service pod in the active state may be pod 303, which is in a running and serviced state.

In Figure 6, the process of a pod executing an application is explained. 7 and 8 show flow charts for performing data synchronization to EMS. In FIG. 7, a flowchart is shown for a case in which an abnormal situation occurs in the first EMS, and in FIG. 8, a flowchart is shown for a case in which an abnormal situation does not occur in the first EMS.

Figure 7 shows a flowchart for EMS to synchronize data according to an embodiment of the present disclosure.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

Referring to FIG. 7, in step 701, the first EMS 710 may identify the first initialization container. The initializing container may be a container with all required resources running. According to an embodiment of the present disclosure, in an initializing container, the state of the pod included in the EMS of the container may be the pod 301, which is in a state of running but not being serviced.

At step 703, the second EMS 720 may identify a second initialization container. The initializing container may be a container with all required resources running. According to an embodiment of the present disclosure, in an initializing container, the state of the pod included in the EMS of the container may be the pod 301, which is in a state of running but not being serviced.

At step 705, the first EMS 710 may identify the status of the container. For example, first EMS 710 can identify whether a pod is active. When the container is in an active state, the first EMS 710 executes the application. According to one embodiment of the present disclosure, the state of a service pod in the active state may be pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, it may be identified that the first EMS 710 is in an active state. According to one embodiment of the present disclosure, status confirmation may be performed by the HA pod 403 included in the first EMS 710.

At step 707, the second EMS 720 may identify the status of the container. For example, the second EMS 720 can identify whether a pod is active. When in the active state, the second EMS 720 executes the application. According to one embodiment of the present disclosure, the state of a service pod in the active state may be pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, it can be identified that the second EMS 720 is in a standby state. According to one embodiment of the present disclosure, status confirmation may be performed by the HA pod 403 included in the second EMS 720.

At step 709, the first EMS 710 may transmit data. Data may include file data and data for application execution. A file may refer to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing. Data can be synchronized in real time. Files may be synchronized via file replication pods 407. Databases can be synchronized through database pods 405. The state of the second EMS 720 is the standby state, but the service pod 401 included in the second EMS 720 is a pod 301 that is running but not in service, so data can be synchronized because it is running. Data is one or more first pods 111a-1, 111b-1 included in the first cluster 100-1 and one or more second pods 111a-2, 111b included in the second cluster 100-2. -2) It can be synchronized in real time. Data may be synchronized in real time from each of the one or more first PVs 113a-1 and 113b-1 to each of the one or more second PVs 113a-2 and 113b-2.

At step 711, the second EMS 720 may transmit a status check message. According to an embodiment of the present disclosure, the status check message of the second EMS 720 may be transmitted by the HA pod 403 included in the second EMS 720. According to an embodiment of the present disclosure, the status of the second EMS 720 is checked by using messages from the HA pod 403 included in the first EMS 710 and the HA pod 403 included in the second EMS 720. This can be accomplished through transmission and reception.

At step 713, the first EMS 710 may transmit a status response message. According to an embodiment of the present disclosure, the status response message of the first EMS 710 may be transmitted by the HA pod 403 included in the first EMS 710. According to an embodiment of the present disclosure, the status response message may be a message indicating that the first EMS 710 is in a standby state. According to one embodiment of the present disclosure, the status response message may not be transmitted. The status response message may not be transmitted due to an abnormal condition of the first EMS 710. For example, abnormal situations may be pod abnormalities and infrastructure abnormalities. Abnormalities in the infrastructure may include worker node crashes, cluster-level crashes, storage crashes, or independent service or network abnormalities.

In step 715, the first EMS 710 may change the state of the second EMS 710 to a standby state. This is because, in the case of a stateful application, when one container-based cluster is active, the remaining container-based clusters need to remain in a standby state. According to one embodiment of the present disclosure, changing the state of the first EMS 710 to the active state may be done by the HA pod 403. Through real-time synchronization, even if the first EMS (710) changes to the standby state, data is stored in one or more first PVs (113a-1, 113b-1) and one or more second PVs (113a-2, 113b-2), respectively. ) can be synchronized in real time with each. Data may include file data and data for application execution. A file may refer to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing.

At step 717, the second EMS 720 may change the state of the second EMS 720 to the active state. This is because, in the case of a stateful application, when one container-based cluster is active, the remaining container-based clusters need to remain in a standby state. According to one embodiment of the present disclosure, changing the state of the second EMS 720 to the active state may be performed by the HA pod 403. Through real-time synchronization, the second EMS 720 can immediately execute the application being executed by the first EMS 710. This includes one or more first PVs (113a-1, 113b-1) included in the first cluster (100-1) and one or more second PVs (113a-2, 113b) included in the second cluster (100-2). This is because -2) is synchronized in real time. Real-time synchronization is one or more first pods 111a-1 and 111b-1 included in the first cluster 100-1 and one or more second pods 111a-2 included in the second cluster 100-2. 111b-2). Through real-time synchronization, even if the state of the first EMS 710 changes to an abnormal state due to an abnormal situation, the second EMS 720 can immediately execute the application being executed by the first EMS 710.

In Figure 7, a flowchart is shown for a case in which an abnormal situation occurs in the first EMS. In Figure 8, a flowchart is shown for a case in which an abnormal situation does not occur in the first EMS.

Figure 8 shows a flowchart for EMS to synchronize data according to an embodiment of the present disclosure.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

Referring to FIG. 8, in step 801, the first EMS 810 may identify the first initialization container. The initializing container may be a container with all required resources running. According to an embodiment of the present disclosure, in an initializing container, the state of the pod included in the EMS of the container may be the pod 301, which is in a state of running but not being serviced.

At step 803, the second EMS 820 may identify the second initialization container. The initializing container may be a container with all required resources running. According to an embodiment of the present disclosure, in an initializing container, the state of the pod included in the EMS of the container may be the pod 301, which is in a state of running but not being serviced.

At step 805, the first EMS 810 may identify the status of the container. When the container is in an active state, the first EMS 810 executes the application. According to one embodiment of the present disclosure, the state of a service pod in the active state may be pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, it may be identified that the first EMS 810 is in an active state. According to one embodiment of the present disclosure, status confirmation may be performed by the HA pod 403 included in the first EMS 810.

At step 807, the second EMS 820 may identify the status of the container. When in the active state, the second EMS 820 executes the application. According to one embodiment of the present disclosure, the state of a service pod in the active state may be pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, it can be identified that the second EMS 820 is in a standby state. According to one embodiment of the present disclosure, status confirmation may be performed by the HA pod 403 included in the second EMS 820.

At step 809, the first EMS 810 may transmit data. Data may include file data and data for application execution. A file may refer to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing. Data can be synchronized in real time. Files may be synchronized via file replication pods 407. Databases can be synchronized through database pods 405. The state of the second EMS 820 is the standby state, but the service pod 401 included in the second EMS 820 is a pod 301 that is running but not in service, so data can be synchronized because it is running. Data is one or more first pods 111a-1, 111b-1 included in the first cluster 100-1 and one or more second pods 111a-2, 111b included in the second cluster 100-2. -2) It can be synchronized in real time. Data may be synchronized in real time from each of the one or more first PVs 113a-1 and 113b-1 to each of the one or more second PVs 113a-2 and 113b-2.

At step 811, the second EMS 820 may transmit a status check message. According to an embodiment of the present disclosure, the status check message of the second EMS 820 may be transmitted by the HA pod 403 included in the second EMS 820. According to an embodiment of the present disclosure, checking the status of the second EMS (820) includes messages from the HA pod 403 included in the first EMS 810 and the HA pod 403 included in the second EMS 820. This can be accomplished through transmission and reception. A status check message can be sent.

At step 813, the first EMS 810 may transmit a status response message. According to an embodiment of the present disclosure, the status response message of the first EMS 810 may be transmitted by the HA pod 403 included in the first EMS 810. According to an embodiment of the present disclosure, the status response message may be a message indicating that the first EMS 810 is in a standby state. According to one embodiment of the present disclosure, the status response message may not be transmitted. The status response message may not be transmitted due to an abnormal condition of the first EMS 810. For example, abnormal situations may be pod abnormalities and infrastructure abnormalities. Abnormalities in the infrastructure may include worker node crashes, cluster-level crashes, storage crashes, or independent service or network abnormalities.

At step 715, the first EMS 710 may maintain the state of the second EMS 710 in the active state. This is because, in the case of a stateful application, when one container-based cluster is active, the remaining container-based clusters need to remain in a standby state. Through real-time synchronization, even if the second EMS 720 is in a standby state, data is transmitted from each of one or more first PVs 113a-1 and 113b-1 to one or more second PVs 113a-2 and 113b-2, respectively. can be synchronized in real time. Data may include file data and data for application execution. A file may refer to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing.

At step 817, the second EMS 820 may maintain the state of the second EMS 820. This is because, in the case of a stateful application, when one container-based cluster is active, the remaining container-based clusters need to remain in a standby state.

7 and 8 show flow charts for performing data synchronization to EMS. 9 and 10 show flowcharts showing the EMS performing data synchronization.

Figure 9 shows a flow chart illustrating a second EMS performing data synchronization according to an embodiment of the present disclosure.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

Referring to Figure 9, at step 910, the second EMS runs an initialization container. The initializing container may be a container with all required resources running. According to an embodiment of the present disclosure, in an initializing container, the state of the pod included in the EMS of the container may be the pod 301, which is in a state of running but not being serviced.

At step 930, the second EMS may identify the status of the second EMS. When the state of the second EMS is active, the second EMS executes the application. According to an embodiment of the present disclosure, the state of the service pod when the state of the second EMS is active may be pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, when the state of the second EMS is active, the state of the service pod 401 may be the pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, it may be identified that the second EMS is active. According to an embodiment of the present disclosure, it can be identified that the second EMS is in a standby state. According to one embodiment of the present disclosure, status confirmation may be performed by the HA pod 403 included in the second EMS.

At step 950, the second EMS may identify that the state of the second EMS is standby. When the state of the second EMS is standby, the second EMS can receive data from the first EMS. Data may include file data and data for application execution. A file may refer to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing. Data can be synchronized in real time. Files may be synchronized via file replication pods 407. Databases can be synchronized through database pods 405. The state of the second EMS is standby, but the service pod 401 included in the second EMS is a pod 301 that is running but not in service, so data can be synchronized because it is running. Data is one or more first pods 111a-1, 111b-1 included in the first cluster 100-1 and one or more second pods 111a-2, 111b included in the second cluster 100-2. -2) It can be synchronized in real time. Data may be synchronized in real time from each of the one or more first PVs 113a-1 and 113b-1 to each of the one or more second PVs 113a-2 and 113b-2.

At step 970, the second EMS may check the status of the first EMS. According to an embodiment of the present disclosure, the status of the first EMS may be confirmed through transmission of a status confirmation message. According to an embodiment of the present disclosure, the status check message of the second EMS may be transmitted by the HA pod 403 included in the second EMS. The status of the first EMS 820 can be confirmed through message transmission and reception between the HA pod 403 included in the first EMS and the HA pod 403 included in the second EMS.

The second EMS can identify whether the state of the first EMS is a standby state or an abnormal state. According to an embodiment of the present disclosure, it is possible to identify whether the state of the first EMS is a standby state or an abnormal state based on a message received from the HA pod included in the first EMS. According to one embodiment of the present disclosure, messages may not be received from the HA pod included in the first EMS. If an abnormal condition occurs in the first EMS due to an abnormal situation, messages may not be received from the HA pod. For example, abnormal situations may be pod abnormalities and infrastructure abnormalities. Abnormalities in the infrastructure may include worker node crashes, cluster-level crashes, storage crashes, or independent service or network abnormalities.

In step 990, when it is identified whether the state of the first EMS is a standby state or an abnormal state, the second EMS may change the state of the second EMS to an active state based on data received from the first EMS. . This is because, in the case of a stateful application, when one container-based cluster is active, the remaining container-based clusters need to remain in a standby state. According to one embodiment of the present disclosure, changing the state of the second EMS to the active state may be done by the HA pod. Through real-time synchronization, the second EMS can immediately run the application that was running on the first EMS. This includes one or more first PVs (113a-1, 113b-1) included in the first cluster (100-1) and one or more second PVs (113a-2, 113b) included in the second cluster (100-2). This is because -2) is synchronized in real time. Real-time synchronization is one or more first pods 111a-1 and 111b-1 included in the first cluster 100-1 and one or more second pods 111a-2 included in the second cluster 100-2. 111b-2). Through real-time synchronization, even if the state of the first EMS changes to an abnormal state due to an abnormal situation, the second EMS can immediately execute the application that was running in the first EMS.

In Figure 9, a flow chart showing the second EMS performing data synchronization is shown. FIG. 10 shows a flowchart showing a first EMS performing data synchronization.

Figure 10 shows a flowchart showing a first EMS performing data synchronization according to an embodiment of the present disclosure.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

Referring to Figure 10, at step 1010, the first EMS executes an initialization container. The initializing container may be a container with all required resources running. According to an embodiment of the present disclosure, in an initializing container, the state of the pod included in the EMS of the container may be the pod 301, which is in a state of running but not being serviced.

At step 1030, the first EMS may identify the state of the first EMS. When the state of the first EMS is active, the first EMS executes the application. According to an embodiment of the present disclosure, the state of the service pod when the state of the first EMS is active may be pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, when the state of the first EMS is active, the state of the service pod 401 may be the pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, it may be identified that the second EMS is active. According to an embodiment of the present disclosure, it can be identified that the second EMS is in a standby state. According to one embodiment of the present disclosure, status confirmation may be performed by the HA pod 403 included in the second EMS.

At step 1030, the first EMS may identify the state of the first EMS. When the state of the first EMS is active, the first EMS executes the application. According to an embodiment of the present disclosure, the state of the service pod when the state of the first EMS is active may be pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, when the state of the first EMS is active, the state of the service pod 401 may be the pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, it may be identified that the second EMS is active. According to an embodiment of the present disclosure, it can be identified that the second EMS is in a standby state. According to one embodiment of the present disclosure, status confirmation may be performed by the HA pod 403 included in the second EMS.

At step 1050, the first EMS may identify that the state of the first EMS is active. When the state of the EMS is active, the first EMS is to execute the application. According to one embodiment of the present disclosure, the state of a service pod in the active state may be pod 303, which is in a running and serviced state. According to an embodiment of the present disclosure, it may be identified that the first EMS 810 is in an active state. According to one embodiment of the present disclosure, status confirmation may be performed by the HA pod 403 included in the first EMS 810.

The first EMS may transmit data. Data may include file data and data for application execution. A file may refer to data stored in a cluster, and data for application execution may be data related to an application that the EMS is executing. Data can be synchronized in real time. Files may be synchronized via file replication pods 407. Databases can be synchronized through database pods 405. The state of the second EMS is standby, but the service pod 401 included in the second EMS is a pod 301 that is running but not in service, so data can be synchronized because it is running. Data is one or more first pods 111a-1, 111b-1 included in the first cluster 100-1 and one or more second pods 111a-2, 111b included in the second cluster 100-2. -2) It can be synchronized in real time. Data may be synchronized in real time from each of the one or more first PVs 113a-1 and 113b-1 to each of the one or more second PVs 113a-2 and 113b-2.

Figure 11 shows a device diagram in a container-based cluster environment according to an embodiment of the present disclosure. The configuration illustrated in FIG. 11 can be understood as a configuration of a device having at least one function among a first cluster, a first network, a second cluster, and a second network. The first cluster and the second cluster may correspond to container-based clusters.

According to an embodiment of the present disclosure, the description of the cluster may be used as a description of the EMS included in the cluster. Additionally, the status of the cluster can be used in the same sense as the status of the EMS included in the cluster. For example, the state of the first cluster may be used with the same meaning as the state of the first EMS included in the first cluster. For example, the state of the second cluster may be used with the same meaning as the state of the second EMS included in the second cluster. For example, the status of a candidate cluster may be used in the same sense as the status of a candidate EMS included in the candidate cluster. According to an embodiment of the present disclosure, the description of the application may be used as a description of the EMS service application.

Referring to FIG. 11, a cluster or network includes a transceiver 1110, a memory 1130, and a processor 1120.

The transceiver unit 1110 provides an interface for communicating with other devices. Specifically, the transceiver 1110 converts a bit string transmitted from an object in a cluster or network to another cluster or network object or another device into a physical signal, and converts a physical signal received from another device into a bit string. That is, the transceiver 1110 can transmit and receive signals. Specifically, the transceiver 1110 may be referred to as a modem, a transmitter, a receiver, or a transceiver.

The memory 1130 stores data such as basic programs, applications, and setting information for the operation of cluster or network objects. According to an embodiment of the present disclosure, the memory 1130 stores data such as basic programs, applications, and setting information for operation of a cluster or network. The memory 1130 may be comprised of volatile memory, non-volatile memory, or a combination of volatile memory and non-volatile memory. And, the memory 1130 provides stored data according to the request of the processor 1120.

The processor 1120 controls the overall operations of objects in the cluster or network. According to an embodiment of the present disclosure, the processor 1120 transmits and receives signals through the transceiver 1110. Additionally, the processor 1120 writes and reads data into the memory 1130. For this purpose, the processor 1120 may include at least one processor. According to various embodiments of the present disclosure, the processor 1120 may control to perform synchronization using a wireless communication network. For example, the processor 1120 may control the overall operations of the objects of the above-described cluster or network.

In the method performed by the second EMS (element management system) of the second cluster according to the embodiments of the present disclosure as described above, the method includes loading an initialization container in the second EMS. A process of executing a service pod in a standby state that is included in running but not in service, a process of identifying a state of the second EMS, and when the state of the second EMS is the standby state, the first pod of the first cluster A process of receiving data stored in the first cluster and data related to an application running in the first EMS from an EMS, a process of identifying a state of the first EMS, and determining that the state of the first EMS is a standby state or EMS. If it is in an abnormal state in which the service pod is not running, the process may include changing the state of the second EMS to an active state in which the service pod is running and in service, based on the file and the database.

In one embodiment, the process of identifying the state of the first EMS includes transmitting a message confirming the state to the first EMS and information about an active state or standby state from the first EMS, It may include receiving a response message to the message confirming the status.

In one embodiment, the abnormal state may be identified based on the fact that a response message is not received from the first EMS.

In one embodiment, the abnormal state is at least one of pod failure, worker node crash, cluster crash, storage crash, independent service, or network abnormality. It can be included.

In one embodiment, the file may be received through a file replication pod included in the second EMS, and the database may be received through a database pod included in the second EMS.

In one embodiment, the files and the database may be received in real time.

In the method performed by the first EMS (element management system) of the first cluster according to the embodiments of the present disclosure as described above, the method includes loading an initialization container (init container) in the first EMS. The process includes executing a service pod in a standby state that is running but not in service, identifying a state of the first EMS, and changing the state of the first EMS to an active state in which the service pod is running and in service. In the case of the state, the process may include transmitting data stored in the first cluster and data related to the application being executed by the first EMS to the second EMS of the second cluster.

In one embodiment, the file may be transmitted through a file replication pod included in the first EMS, and the database may be transmitted through a database pod included in the first EMS.

In one embodiment, the files and the database may be transmitted in real time.

In one embodiment, the process may further include receiving a message confirming the status from the second EMS and transmitting a message indicating the active status to the second EMS.

In the second EMS (element management system) of the second cluster according to the embodiments of the present disclosure as described above, the second EMS includes a transceiver and at least one processor coupled to the transceiver. Comprising: the at least one processor, by loading an initialization container (init container), executes a service pod in a running but not serviced standby state included in the second EMS, and identifies the state of the second EMS; , when the state of the second EMS is the standby state, receive data stored in the first cluster and data related to an application running in the first EMS from the first EMS of the first cluster, and Identify the state, and if the state of the first EMS is a standby state or an abnormal state in which the EMS is not running, determine the state of the second EMS based on the file and the database to determine whether the service pod is running and is in service. It can be set to change to active state.

In the first EMS (element management system) of the first cluster according to the embodiments of the present disclosure as described above, the first EMS includes a transceiver and at least one processor coupled to the transceiver. Comprising: the at least one processor, by loading an initialization container (init container) to execute a service pod in a running but not serviced standby state included in the first EMS, and identify the state of the first EMS; , if the state of the first EMS is in an active state in which the service pod is running and in service, the first EMS may be set to transmit data stored in the first cluster and data related to the application being executed. .

Electronic devices according to various embodiments disclosed in this document may be of various types. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to embodiments of this document are not limited to the devices described above.

The various embodiments of this document and the terms used herein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various changes, equivalents, or replacements of the embodiments. In connection with the description of the drawings, similar reference numbers may be used for similar or related components. The singular form of a noun corresponding to an item may include a single item or a plurality of items, unless the relevant context clearly indicates otherwise. 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 phrases such as “at least one of , B, or C” may include any one of the items listed together in the corresponding phrase, or any possible combination thereof. Terms such as "first", "second", or "first" or "second" may be used simply to distinguish one element from another, and may be used to distinguish such elements in other respects, such as importance or order) is not limited. One (e.g. first) component is said to be "coupled" or "connected" to another (e.g. second) component, with or without the terms "functionally" or "communicatively". Where mentioned, it means that one component can be connected to another component directly (e.g. wired), wirelessly, or through a third component.

The term “module” used in this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit, for example. A module may be an integrated part or a minimum unit of parts or a part thereof that performs one or more functions. For example, according to one embodiment, the module may be implemented in the form of an application-specific integrated circuit (ASIC).

Various embodiments of this document are software (e.g., a program) that includes one or more instructions stored in a storage medium (e.g., internal memory or external memory) that can be read by a machine (e.g., an electronic device). It can be implemented as: For example, a processor (eg, processor) of a device (eg, electronic device) may call at least one instruction among one or more instructions stored from a storage medium and execute it. This allows the device to be operated to perform at least one function according to at least one instruction called. One or more instructions may include code generated by a compiler or code that can be executed by an interpreter. Device-readable storage media may be provided in the form of non-transitory storage media. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g. EM waves). This term is used when data is semi-permanently stored in the storage medium. There is no distinction between temporary storage and temporary storage.

According to one embodiment, methods according to various embodiments disclosed in this document may be included and provided in a computer program product. Computer program products are commodities and can be traded between sellers and buyers. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read only memory (CD-ROM)), or through an application store (e.g., Play StoreTM), or on two user devices (e.g., It can be distributed (e.g. downloaded or uploaded) directly between smartphones) or online. In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a device-readable storage medium, such as the memory of a manufacturer's server, an application store server, or a relay server.

According to various embodiments, each component (eg, module or program) of the described components may include a single or plural entity. According to various embodiments, one or more of the components or operations described above may be omitted, or one or more other components or operations may be added. Alternatively or additionally, multiple components (eg, modules or programs) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each component of the plurality of components in the same or similar manner as that performed by the corresponding component of the plurality of components prior to integration. According to various embodiments, operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or Alternatively, one or more other operations may be added.

Claims (20)

In the method performed by the second EMS (element management system) of the second cluster,
A process of executing a service pod included in the second EMS and in a standby state that is running but not in service by loading an initialization container;
A process of identifying the state of the second EMS;
When the state of the second EMS is the standby state, receiving data stored in the first cluster and data related to an application running in the first EMS from the first EMS of the first cluster;
A process of identifying the state of the first EMS;
If the state of the first EMS is a standby state or an abnormal state in which the EMS is not running, change the state of the second EMS to an active state in which the service pod is running and serviced based on the file and the database. How to include courses.
According to paragraph 1,
The process of identifying the state of the first EMS is,
A process of transmitting a status confirmation message to the first EMS,
A method comprising receiving a response message to the message confirming the status, including information about an active state or a standby state, from the first EMS.
According to paragraph 2,
A method wherein the abnormal state is identified based on no response message being received from the first EMS.
According to paragraph 1,
The abnormal state includes at least one of pod failure, worker node crash, cluster crash, storage crash, independent service, or network abnormality.
According to paragraph 1,
The file is received via a file replication pod included in the second EMS,
A method wherein the database is received through a database pod included in the second EMS.
According to paragraph 1,
wherein the file and the database are received in real time.
In the method performed by the first EMS (element management system) of the first cluster,
A process of executing a service pod included in the first EMS and in a standby state that is running but not in service by loading an initialization container;
A process of identifying the state of the first EMS;
If the state of the first EMS is in an active state where the service pod is running and in service, send the second EMS of the second cluster the data stored in the first cluster and the data related to the application that the first EMS is running. A method involving the process of transmitting a .
In clause 7,
The file is transmitted through a file replication pod included in the first EMS,
A method wherein the database is transmitted through a database pod included in the first EMS.
In clause 7,
A method wherein the file and the database are transmitted in real time.
In clause 7,
A process of receiving a status confirmation message from the second EMS,
The method further includes transmitting a message indicating the active state to the second EMS.
In the second EMS (element management system) of the second cluster,
Transmitter and receiver,
Comprising at least one processor coupled to the transceiver,
The at least one processor,
Execute a service pod included in the second EMS that is running but in a standby state and is not in service by loading an initialization container,
Identify the status of the second EMS,
When the state of the second EMS is the standby state, receive data stored in the first cluster and data related to an application running in the first EMS from the first EMS of the first cluster,
Identify the status of the first EMS,
If the state of the first EMS is a standby state or an abnormal state in which the EMS is not running, change the state of the second EMS to an active state in which the service pod is running and serviced based on the file and the database. Second EMS to be established.
According to clause 11,
The at least one processor is configured to identify the state of the first EMS,
Send a message confirming the status to the first EMS,
A second EMS configured to receive a response message from the first EMS to the message confirming the status, including information about an active state or a standby state.
According to clause 12,
The abnormal state is a second EMS identified based on no response message being received from the first EMS.
According to clause 11,
The abnormal state includes at least one of pod failure, worker node crash, cluster level crash, and storage crash.
According to clause 11,
The file is received via a file replication pod included in the second EMS,
A second EMS, wherein the database is received through a database pod included in the second EMS.
According to clause 11,
A second EMS where the file and the database are received in real time.
In the first EMS (element management system) of the first cluster,
Transmitter and receiver,
Comprising at least one processor coupled to the transceiver,
The at least one processor,
Executing a service pod included in the first EMS that is running but in a standby state and not in service by loading an init container,
Identify the status of the first EMS,
A first EMS configured to transmit data stored in the first cluster and data related to an application for which the first EMS is running when the state of the first EMS is in an active state where the service pod is running and in service. .
According to clause 17,
The file is transmitted through a file replication pod included in the first EMS,
A first EMS where the database is transmitted through a database pod included in the first EMS.
According to clause 17,
A first EMS in which the files and the database are transmitted in real time.
According to clause 17,
The at least one processor,
Receiving a message confirming the status from the second EMS,
A first EMS configured to transmit a message indicating the active state to the second EMS.

Images