WO2023249361A1 - 컨테이너 기반 다중 클러스터 환경에서 데이터 동기화를 위한 방법 및 장치 - Google Patents

컨테이너 기반 다중 클러스터 환경에서 데이터 동기화를 위한 방법 및 장치 Download PDF

Info

Publication number
WO2023249361A1
WO2023249361A1 PCT/KR2023/008494 KR2023008494W WO2023249361A1 WO 2023249361 A1 WO2023249361 A1 WO 2023249361A1 KR 2023008494 W KR2023008494 W KR 2023008494W WO 2023249361 A1 WO2023249361 A1 WO 2023249361A1
Authority
WO
WIPO (PCT)
Prior art keywords
ems
cluster
state
pod
service
Prior art date
Application number
PCT/KR2023/008494
Other languages
English (en)
French (fr)
Inventor
라마사미부파티
김원수
김준
나연주
채경범
Original Assignee
삼성전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Publication of WO2023249361A1 publication Critical patent/WO2023249361A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support

Definitions

  • This disclosure 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.
  • a container is a package of libraries, programs, and configuration files necessary to run an application on a host OS (Operating System).
  • Container-based applications are isolated from each other, and the host OS manages each container-based application to independently use resources such as CPU (central processing unit), memory, file storage, and network connection. Through this process, container-based applications can be recognized as operating independently on a single host OS.
  • Containers share the host OS, so there is no need to boot the OS or load libraries. Therefore, containers can be much more efficient and lightweight compared to VMs (virtual machines) that must run the OS individually. Container-based applications can be launched within seconds, and application instances can be scaled up quickly compared to VM scenarios. Additionally, since containers share the host OS, patches or updates only need to be performed on one OS, which can reduce maintenance-related overhead.
  • the method performed by the second EMS (element management system) of the second cluster is to load an initial container to load an initial container that is running but is not in service.
  • a process of executing a service pod in a standby state, a process of identifying a state of the second EMS, and when the state of the second EMS is the standby state, the first EMS from the first cluster of the first cluster Receiving data related to files stored in a cluster and applications that the first EMS is executing, identifying a state of the first EMS, and determining whether the state of the first EMS is standby or the first EMS is running. If it is 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 data.
  • the method performed by the first EMS (element management system) of the first cluster is to load an initial container to load an initial container that is running but is not in service.
  • a second element management system (EMS) of the second cluster includes a transceiver and at least one processor coupled to the transceiver, and the at least one processor Executes a service pod in a running but not serviced standby state included in the second EMS by loading an initial container, identifies the state of the second EMS, and When the state of is the standby state, receive data related to a file stored in the first cluster and an application that the first EMS is running from a first EMS of the first cluster, and identify the state of the first EMS, If the state of the first EMS is a standby state or an abnormal state in which the first EMS is not running, the state of the second EMS is determined based on the file and the data, and an active state in which the service pod is running and in service. It can be configured to change to .
  • a first element management system (EMS) of the first cluster includes a transceiver and at least one processor coupled to the transceiver, and the at least one processor Executes a service pod in a running but not serviced standby state included in the first EMS by loading an initial container, identifies the state of the first EMS, and If the state of is an active state in which the service pod is running and in service, the first EMS may be configured to transmit data related to files stored in the first cluster and applications running.
  • a method and device for transferring data 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 is provided, eliminating the need for external storage.
  • a method and device for transferring data 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 is provided, enabling rapid updates.
  • 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.
  • the main gist of the present disclosure can be applied to other communication systems with similar technical background and channel types with slight modifications without significantly departing from the scope of the present disclosure. This may be possible at the discretion of a person skilled in the technical field of the present disclosure.
  • 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).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s).
  • the term ' ⁇ unit' used in this embodiment refers to software or hardware components such as FPGA or ASIC, and the ' ⁇ unit' performs certain roles.
  • ' ⁇ 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.
  • 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.
  • a container is a package of libraries, programs, and configuration files necessary to run an application on a host OS (Operating System).
  • Container-based applications are isolated from each other, and the host OS manages each container-based application to independently use resources such as CPU (central processing unit), memory, file storage, and network connection. Through this process, container-based applications can be recognized as operating independently on a single host OS.
  • 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.
  • OS operating system
  • the description of the cluster may be used as a description of the EMS included in the cluster.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • the description of the application may be used as a description of the EMS service application.
  • Active state - Remaining active can have the following problems:
  • Synchronization data must be bidirectional, and data conflicts may occur during data replication.
  • Container-based clusters do not support active-standby states. 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.
  • 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.
  • the data may include data files and data for application execution.
  • a data 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.
  • 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.
  • the network environment may include a first cluster 100-1 and a second cluster 100-2.
  • 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.
  • the network environment may include a first network 130-1 and a second network 130-2.
  • 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.
  • the description of the cluster may be used as a description of the EMS included in the cluster.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • VMs virtual machines
  • PMs physical machines
  • 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.
  • each worker node may include services required to run a pod.
  • 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.
  • 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.
  • 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.
  • the control plane may be responsible for allocating a classless inter domain routing (CIDR) block to the node when the worker node is registered.
  • 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, the control plane is running in a cloud environment and when a worker node is unhealthy, it can ask the cloud provider whether the VM on 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.
  • 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.
  • the first cluster 100-1 may be a cluster in an active state.
  • 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.
  • 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.
  • the data may include data files 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.
  • 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.
  • synchronization pods included in the cluster must be running even in standby state.
  • 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.
  • 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.
  • 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.
  • the network environment may include a first cluster 200-1 and a second cluster 200-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.
  • the network environment may include a first network 230-1 and a second network 230-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.
  • the description of the cluster may be used as a description of the EMS included in the cluster.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • an abnormal situation occurred in the first cluster 200-1.
  • an anomaly could be a pod anomaly or an infrastructure anomaly.
  • Abnormalities in the infrastructure may include worker node crashes, cluster-level crashes, storage crashes, or independent service or network abnormalities.
  • the second cluster 200-2 may change from the standby state to the active state.
  • 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).
  • 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 sync pod running in a standby state may mean a state in which the sync 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.
  • 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.
  • 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.
  • the description of the cluster may be used as a description of the EMS included in the cluster.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • 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.
  • the data may include data files 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 on Cluster 1 and Cluster 2, data can be synchronized. That is, data can be transmitted to other pods. Here, the data may include data files 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 may 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.
  • Figure 4 is a diagram showing the types of pods according to an embodiment of the present disclosure.
  • 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.
  • the description of the cluster may be used as a description of the EMS included in the cluster.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • 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.
  • the service pod 401 In the standby state, the service pod 401 is not serviced, but may need to be running for data synchronization.
  • the data may include data files 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.
  • the HA pod 403 may need to be running and serviced regardless of the state of the cluster.
  • the HA pod 403 may need to be serviced to determine the status of the cluster even when in a standby state.
  • the HA pod 403 may be a pod 303 that is running and in service regardless of its state.
  • 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.
  • the service must be performed 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.
  • 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, in real time, files 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.
  • Figure 5 is a diagram showing the lifespan of a pod according to an embodiment of the present disclosure.
  • a Pod may include, for example, five states.
  • 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.
  • EMS EMS-based system
  • the description of the cluster may be used as a description of the EMS included in the cluster.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • 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 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 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.
  • Figure 6 shows a flowchart showing a process in which a Pod executes an application 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.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • the description of the application may be used as a description of the EMS service application.
  • the EMS may identify an initial container.
  • the initializing container may be a container with all required resources running.
  • 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.
  • 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.
  • the EMS may identify whether the container is active. This is to run the application when the container is active.
  • 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.
  • the EMS may wait for a set time interval.
  • 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.
  • 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.
  • FIG. 7 and 8 show flow charts for performing data synchronization to EMS.
  • a flowchart is shown for a case in which an abnormal situation occurs in the first EMS
  • 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.
  • the description of the cluster may be used as a description of the EMS included in the cluster.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • the description of the application may be used as a description of the EMS service application.
  • the first EMS 710 may identify the first initialization container.
  • the initializing container may be a container with all required resources running.
  • 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.
  • the second EMS 720 may identify a second initialization container.
  • the initializing container may be a container with all required resources running.
  • 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.
  • 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.
  • 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.
  • the first EMS 710 may transmit data.
  • the data may include data files 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.
  • the second EMS 720 may transmit a status check message.
  • the status check message of the second EMS 720 may be transmitted by the HA pod 403 included in the second EMS 720.
  • 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.
  • the first EMS 710 may transmit a status response message.
  • the status response message of the first EMS 710 may be transmitted by the HA pod 403 included in the first EMS 710.
  • the status response message may be a message indicating that the first EMS 710 is in a standby state.
  • 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.
  • an anomaly could be a pod anomaly or an infrastructure anomaly.
  • Abnormalities in the infrastructure may include worker node crashes, cluster-level crashes, storage crashes, or independent service or network abnormalities.
  • 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, if one container-based cluster is active, the remaining container-based clusters need to remain in a standby state.
  • changing the state of the first EMS 710 to the active state may be done by the HA pod 403.
  • 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.
  • the data may include data files 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 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, if 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).
  • 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).
  • the second EMS 720 can immediately execute the application being executed by the first EMS 710.
  • Figure 8 shows a flowchart for EMS to synchronize data 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.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • the description of the application may be used as a description of the EMS service application.
  • the first EMS 810 may identify the first initialization container.
  • the initializing container may be a container with all required resources running.
  • 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.
  • the second EMS 820 may identify a second initialization container.
  • the initializing container may be a container with all required resources running.
  • 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.
  • the first EMS 810 may identify the status of the container.
  • the first EMS 810 executes the application.
  • the state of a service pod in the active state may be pod 303, which is in a running and serviced state.
  • it may be identified that the first EMS 810 is in an active state.
  • status confirmation may be performed by the HA pod 403 included in the first EMS 810.
  • the second EMS 820 may identify the status of the container.
  • the second EMS 820 executes the application.
  • the state of a service pod in the active state may be pod 303, which is in a running and serviced state.
  • status confirmation may be performed by the HA pod 403 included in the second EMS 820.
  • the first EMS 810 may transmit data.
  • the data may include data files 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.
  • Data may be synchronized via database pod 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.
  • the second EMS 820 may transmit a status check message.
  • the status check message of the second EMS 820 may be transmitted by the HA pod 403 included in the second EMS 820.
  • 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.
  • the first EMS 810 may transmit a status response message.
  • the status response message of the first EMS 810 may be transmitted by the HA pod 403 included in the first EMS 810.
  • the status response message may be a message indicating that the first EMS 810 is in a standby state.
  • 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.
  • an anomaly could be a pod anomaly or an infrastructure anomaly.
  • Abnormalities in the infrastructure may include worker node crashes, cluster-level crashes, storage crashes, or independent service or network abnormalities.
  • 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.
  • the data may include data files 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 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.
  • FIGS. 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.
  • the description of the cluster may be used as a description of the EMS included in the cluster.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • the description of the application may be used as a description of the EMS service application.
  • the second EMS runs an initialization container.
  • the initializing container may be a container with all required resources running.
  • 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.
  • the second EMS may identify the status of the second EMS.
  • 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.
  • the state of the service pod 401 may be the pod 303, which is in a running and serviced state.
  • it may be identified that the second EMS is active.
  • it can be identified that the second EMS is in a standby state.
  • status confirmation may be performed by the HA pod 403 included in the second EMS.
  • the second EMS may identify that the state of the second EMS is standby.
  • the second EMS can receive data from the first EMS.
  • the data may include data files 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.
  • the second EMS may check the status of the first EMS.
  • the status of the first EMS may be confirmed through transmission of a status confirmation message.
  • 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, an anomaly could be a pod anomaly or an infrastructure anomaly. Abnormalities in the infrastructure may include worker node crashes, cluster-level crashes, storage crashes, or independent service or network abnormalities.
  • 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.
  • -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).
  • the second EMS can immediately execute the application that was running in the first EMS.
  • 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.
  • the description of the cluster may be used as a description of the EMS included in the cluster.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • the description of the application may be used as a description of the EMS service application.
  • the first EMS executes an initialization container.
  • the initializing container may be a container with all required resources running.
  • 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.
  • the first EMS may identify the state of the first EMS.
  • 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.
  • the state of the service pod 401 may be the pod 303, which is in a running and serviced state.
  • it may be identified that the second EMS is active.
  • it can be identified that the second EMS is in a standby state.
  • status confirmation may be performed by the HA pod 403 included in the second EMS.
  • the first EMS may identify the state of the first EMS.
  • 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.
  • the state of the service pod 401 may be the pod 303, which is in a running and serviced state.
  • it may be identified that the second EMS is active.
  • it can be identified that the second EMS is in a standby state.
  • status confirmation may be performed by the HA pod 403 included in the second EMS.
  • the first EMS may identify that the state of the first EMS is active.
  • the state of a service pod in the active state may be pod 303, which is in a running and serviced state.
  • it may be identified that the first EMS 810 is in an active state.
  • status confirmation may be performed by the HA pod 403 included in the first EMS 810.
  • the first EMS may transmit data.
  • the data may include data files 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
  • 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.
  • the description of the cluster may be used as a description of the EMS included in the cluster.
  • the status of the cluster can be used in the same sense as the status of the EMS included in the cluster.
  • 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.
  • 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.
  • 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.
  • the description of the application may be used as a description of the EMS service application.
  • 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.
  • 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.
  • the method is performed by loading an initial container, the second EMS A process of executing a service pod in a waiting state that is running but not in service, and identifying a state of the second EMS, and when the state of the second EMS is the waiting state, the first Receiving data related to a file stored in the first cluster and an application running on the first EMS from a first EMS of a cluster, identifying a state of the first EMS, and determining the state of the first EMS.
  • 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 data. You can.
  • 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.
  • the process of identifying the state of the first EMS may further include determining the abnormal state when the response message is not received from the first EMS.
  • 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.
  • the file may be received through a file replication pod included in the second EMS, and the data may be received through a database pod included in the second EMS.
  • the files and data may be received in real time.
  • the method includes loading an initial container, the first EMS Included in are a process of executing a service pod in a running state but not in service, a process of identifying a state of the first EMS, and a state of the first EMS indicating that the service pod is running and the service is running. If it is in an active state, it may include transmitting data related to a file stored in the first cluster and an application that the first EMS is executing to the second EMS of the second cluster.
  • the file may be transmitted through a file replication pod included in the first EMS, and the data may be transmitted through a database pod included in the first EMS.
  • the files and data may be transmitted in real time.
  • 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.
  • the second EMS includes a transceiver and at least one coupled to the transceiver.
  • a processor executes a service pod included in the second EMS by loading an initialization container, but the service pod is in a standby state and is not in service, and the second Identify the state of the EMS, and if the state of the second EMS is the standby state, receive data related to a file stored in the first cluster and an application that the first EMS is running from the first EMS of the first cluster; , Identifying 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 first EMS is not running, determine the state of the second EMS based on the file and the data
  • the service pod may be configured to change to an active state, where it is running and a service.
  • the first EMS includes a transceiver and at least one processor coupled to the transceiver. Comprising: the at least one processor, by loading an initial container, executes a service pod in a running but not serviced standby state included in the first EMS, and identifies the state of the first EMS. And, if the state of the first EMS is an active state in which the service pod is running and in service, the first EMS may be configured to transmit files stored in the first cluster and data related to the application being executed.
  • Electronic devices 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.
  • 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.
  • 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.
  • the module may be implemented in the form of an application-specific integrated circuit (ASIC).
  • ASIC application-specific integrated circuit
  • a storage medium e.g., internal memory or external memory
  • a machine e.g., an electronic device
  • a processor e.g., processor
  • a device e.g. electronic device
  • One or more instructions may include code generated by a compiler or code that can be executed by an interpreter.
  • a storage medium that can be read by a device may be provided in the form of a non-transitory storage medium.
  • '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.
  • 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.
  • a device-readable storage medium e.g., compact disc read only memory (CD-ROM)
  • an application store e.g., Play StoreTM
  • two user devices e.g., It can be distributed (e.g. downloaded or uploaded) directly between smartphones) or online.
  • 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.
  • each component (eg, module or program) of the described components may include a single or plural entity.
  • one or more of the components or operations described above may be omitted, or one or more other components or operations may be added.
  • multiple components eg, modules or programs
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

본 개시는 컨테이너 기반 다중 클러스터 환경에서 데이터 동기화를 위한 방법 및 장치에 관한 것이다. 본 개시의 일 실시예에 따른, 제2 클러스터의 제2 EMS(element management system)가 수행하는 방법은, 초기화 컨테이너(initial container)를 로드함으로써, 상기 제2 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하는 과정과, 상기 제2 EMS의 상태를 식별하는 과정과, 상기 제2 EMS의 상태가 상기 대기 상태인 경우, 제1 클러스터의 제1 EMS로부터 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 수신하는 과정과, 상기 제1 EMS의 상태를 식별하는 과정과, 상기 제1 EMS의 상태가 대기 상태 또는 상기 제1 EMS가 실행되지 않는 이상 상태인 경우, 상기 파일 및 상기 데이터에 기반하여 상기 제2 EMS의 상태를, 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태로 변경하는 과정을 포함할 수 있다.

Description

컨테이너 기반 다중 클러스터 환경에서 데이터 동기화를 위한 방법 및 장치
본 개시는 컨테이너 기반 클러스터 환경에 관한 것으로, 보다 구체적으로는 컨테이너 기반 다중 클러스터 환경에서 데이터 동기화를 위한 방법 및 장치에 관한 것이다.
컨테이너는 호스트 OS(Operating System) 상에서 애플리케이션을 실행하는 데 필요한 라이브러리나 프로그램 그리고 설정파일 등을 패키지화 한 것이다. 컨테이너 기반 애플리케이션은 서로 격리되고, 호스트 OS는 각각의 컨테이너 기반 애플리케이션이 CPU(central processing unit), 메모리, 파일 저장소, 네트워크 연결 등의 자원을 독립적으로 사용할 수 있도록 관리한다. 컨테이터너 기반 애플리케이션은 이러한 과정을 통해, 하나의 호스트 OS 상에서 독립적으로 동작하고 있다고 인식할 수 있다.
컨테이너는 호스트 OS를 공유하므로 OS를 부팅하거나 라이브러리를 로드할 필요가 없다. 따라서, 컨테이너는 개별적으로 OS를 구동해야하는 VM(virtual machine)에 비해 훨씬 더 효율적이고 경량화 될 수 있다. 컨테이너 기반 애플리케이션은 몇 초 내에 시작될 수 있으며, VM 시나리오와 비교하여 애플리케이션 인스턴스를 빠르게 확장할 수 있다. 또한, 컨테이너는 호스트 OS를 공유하므로, 하나의 OS에 대해서만 패치 또는 업데이트 등을 수행하면 되므로, 유지 관리와 관련하여 오버헤드가 감소할 수 있다.
본 개시의 다양한 실시 예들에 따르면, 제2 클러스터의 제2 EMS(element management system)가 수행하는 방법은, 초기화 컨테이너(initial container)를 로드함으로써, 상기 제2 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하는 과정과, 상기 제2 EMS의 상태를 식별하는 과정과, 상기 제2 EMS의 상태가 상기 대기 상태인 경우, 제1 클러스터의 제1 EMS로부터 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 수신하는 과정과, 상기 제1 EMS의 상태를 식별하는 과정과, 상기 제1 EMS의 상태가 대기 상태 또는 상기 제1 EMS가 실행되지 않는 이상 상태인 경우, 상기 파일 및 상기 데이터에 기반하여 상기 제2 EMS의 상태를, 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태로 변경하는 과정을 포함할 수 있다.
본 개시의 다양한 실시 예들에 따르면, 제1 클러스터의 제1 EMS(element management system)가 수행하는 방법은, 초기화 컨테이너(initial container)를 로드함으로써, 상기 제1 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하는 과정과, 상기 제1 EMS의 상태를 식별하는 과정과, 상기 제1 EMS의 상태가 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태인 경우, 제2 클러스터의 제2 EMS에게 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 전송하는 과정을 포함할 수 있다.
본 개시의 다양한 실시 예들에 따르면, 제2 클러스터의 제2 EMS(element management system)은, 송수신기(transceiver)와, 상기 송수신기와 연결되는(coupled) 적어도 하나의 프로세서를 포함하고, 상기 적어도 하나의 프로세서는, 초기화 컨테이너(initial container)를 로드함으로써 상기 제2 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하고, 상기 제2 EMS의 상태를 식별하고, 상기 제2 EMS의 상태가 상기 대기 상태인 경우, 제1 클러스터의 제1 EMS로부터 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 수신하고, 상기 제1 EMS의 상태를 식별하고, 상기 제1 EMS의 상태가 대기 상태 또는 상기 제1 EMS가 실행되지 않는 이상 상태인 경우, 상기 파일 및 상기 데이터에 기반하여 상기 제2 EMS의 상태를, 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태로 변경하도록 구성될 수 있다.
본 개시의 다양한 실시 예들에 따르면, 제1 클러스터의 제1 EMS(element management system)은, 송수신기(transceiver)와, 상기 송수신기와 연결되는(coupled) 적어도 하나의 프로세서를 포함하고, 상기 적어도 하나의 프로세서는, 초기화 컨테이너(initial container)를 로드함으로써 상기 제1 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하고, 상기 제1 EMS의 상태를 식별하고, 상기 제1 EMS의 상태가 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태인 경우, 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 전송하도록 구성될 수 있다.
본 개시의 일 실시예에 따르면, 컨테이너 기반 다중 클러스터 환경에서 장애 발생시 클러스터 간 실시간 동기화를 통해 다른 컨테이너에서 즉시 실행할 수 있도록 데이터 및 파일을 전송하는 방법 및 장치를 제공하여, 외부 저장소가 필요하지 않다.
본 개시의 일 실시예에 따르면, 컨테이너 기반 다중 클러스터 환경에서 장애 발생시 클러스터 간 실시간 동기화를 통해 다른 컨테이너에서 즉시 실행할 수 있도록 데이터 및 파일을 전송하는 방법 및 장치를 제공하여, 빠른 업데이트가 가능하다.
본 개시에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 개시의 실시예에 따른 데이터 실시간 동기화를 위한 컨테이너 기반 클러스터 환경을 도시한다.
도 2는 본 개시의 실시예에 따른 데이터 실시간 동기화를 위한 컨테이너 기반 클러스터 환경에서 이상 상황에 의한 이상 상태가 발생한 경우의 시나리오를 도시한다.
도 3은 본 개시의 일 실시예에 따른 파드(pod)의 상태를 나타내는 도면이다.
도 4는 본 개시의 일 실시예에 따른 파드의 종류를 나타내는 도면이다.
도 5는 본 개시의 일 실시예에 따른 파드의 수명을 나타내는 도면이다.
도 6은 본 개시의 일 실시예에 따른 파드가 어플리케이션을 실행하는 과정을 나타내는 순서도를 도시한다.
도 7은 본 개시의 일 실시예에 따른 EMS가 데이터를 동기화하기 위한 흐름도를 도시한다.
도 8는 본 개시의 일 실시예에 따른 EMS가 데이터를 동기화하기 위한 흐름도를 도시한다.
도 9는 본 개시의 일 실시예에 따른 데이터 동기화를 수행하는 제2 EMS를 나타내는 순서도를 도시한다.
도 10은 본 개시의 일 실시예에 따른 데이터 동기화를 수행하는 제1 EMS를 나타내는 순서도를 도시한다.
도 11은 본 개시의 일 실시예에 따른 컨테이너 기반 클러스터 환경에서의 장치도를 도시한다.
이하, 본 개시의 실시예를 첨부한 도면과 함께 상세히 설명한다. 또한 본 개시를 설명함에 있어서 관련된 공지 기능 혹은 구성에 대한 구체적인 설명이 본 개시의 요지를 불필요하게 흐릴 수 있다고 판단된 경우 그 상세한 설명은 생략한다. 그리고 후술되는 용어들은 본 개시에서의 기능을 고려하여 정의된 용어들로서 이는 사용자, 운용자의 의도 또는 관례 등에 따라 달라질 수 있다. 그러므로 그 정의는 본 명세서 전반에 걸친 내용을 토대로 내려져야 할 것이다.
또한, 본 개시의 실시예들을 구체적으로 설명함에 있어서, 본 개시의 주요한 요지는 유사한 기술적 배경 및 채널형태를 가지는 여타의 통신 시스템에도 본 개시의 범위를 크게 벗어나지 아니하는 범위에서 약간의 변형으로 적용 가능하며, 이는 본 개시의 기술분야에서 숙련된 기술적 지식을 가진 자의 판단으로 가능할 것이다.
본 개시의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 개시는 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 개시의 개시가 완전하도록 하고, 본 개시가 속하는 기술분야에서 통상의 지식을 가진 자에게 개시의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 개시는 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
이 때, 본 실시 예에서 사용되는 '~부'라는 용어는 소프트웨어 또는 FPGA또는 ASIC과 같은 하드웨어 구성요소를 의미하며, '~부'는 어떤 역할들을 수행한다. 그렇지만 '~부'는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. '~부'는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 '~부'는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 '~부'들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 '~부'들로 결합되거나 추가적인 구성요소들과 '~부'들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 '~부'들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.
컨테이너는 호스트 OS(Operating System) 상에서 애플리케이션을 실행하는 데 필요한 라이브러리나 프로그램 그리고 설정파일 등을 패키지화 한 것이다. 컨테이너 기반 애플리케이션은 서로 격리되고, 호스트 OS는 각각의 컨테이너 기반 애플리케이션이 CPU(central processing unit), 메모리, 파일 저장소, 네트워크 연결 등의 자원을 독립적으로 사용할 수 있도록 관리한다. 컨테이너 기반 애플리케이션은 이러한 과정을 통해, 하나의 호스트 OS 상에서 독립적으로 동작하고 있다고 인식할 수 있다.
컨테이너는 물리적 또는 가상 인프라에서 클라우드 애플리케이션을 실행할 수 있는 유연성을 제공할 수 있다. 컨테이너는 애플리케이션을 구성하는 서비스를 패키지화하고 개발, 테스트, 및 프로덕션 사용을 위해 다양한 컴퓨터 환경에서 휴대할 수 있게 할 수 있다. 컨테이너를 사용하면 수요 급증에 맞춰 애플리케이션 객체들을 신속하게 확장할 수 있다. 또한, 컨테이너는 호스트의 OS(operating system) 리소스를 사용하기 때문에 VM(virtual machine)보다 가벼울 수 있다. 쿠버네티스(kubernetes) 환경에서는, 클러스터는 네트워크에게 애플리케이션이나 서비스를 배포할 수 있고, 이는 하나의 설정에 대한 클러스터로 간주될 수 있다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터(100-1)의 상태는 제1 클러스터에 포함된 제1 EMS(530)의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터(100-2)의 상태는 제2 클러스터에 포함된 제2 EMS(540)의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
컨테이너 기반 클러스터에 포함된 애플리케이션이 상태 종속적인(즉, stateful) 애플리케이션인 경우, 어느 하나의 컨테이너 기반 클러스터가 활성 상태이면, 나머지 컨테이너 기반 클러스터는 대기 상태(standby state)를 유지하는 것이 필요할 수 있다. 활성 상태-활성 상태를 유지하면 다음과 같은 문제점이 있을 수 있다.
- 작업 복잡도: 활성 상태-활성 상태인 경우, NE(network element)는 클러스터 간에 분산되어야 하며, 그렇지 않다면 운영자(operator)에게 오류가 발생하기 쉬울 수 있다.
- 데이터 충돌: 활성 상태-활성 상태인 경우, 두 클러스터가 모두 실행 중이면, 두 클러스터 모두 업데이트 하는 경우 동기화가 지연될 수 있고 서비스가 보장되지 않거나 제대로 작동하지 않을 수 있다.
- 동기화 데이터는 양방향으로 구성되어야 하며, 데이터 복제 중에 데이터 충돌이 발생할 수 있다.
컨테이너 기반 클러스터는 활성 상태-대기 상태를 지원하지 않는다. 두 개의 컨테이너 기반 클러스터가 있는 경우, 활성 상태-대기 상태란 어느 하나의 컨테이너 기반 클러스터의 EMS가 활성 상태인 경우, 다른 하나의 컨테이너 기반 클러스터의 EMS가 대기 상태임을 의미할 수 있다.
컨테이너 기반 클러스터에 포함된 애플리케이션이 상태 종속적인(stateful) 애플리케이션인 경우, 활성 클러스터와 대기 클러스터 간 1대1 매핑 관계가 발생할 수 있다. 따라서, 활성 클러스터에서 백업 사이트로, 백업 사이트에서 대기 클러스터로 데이터를 동기화하여야 했다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 데이터 파일은 클러스터에 저장된 자료와 관련된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다.
컨테이너 기반 애플리케이션에서, 백업을 위해서는 외부 저장소가 필요하고, 외부에서 백업을 하고 데이터를 관리하여야 한다. 이를 통해 발생할 수 있는 문제점은 다음과 같다:
- 동기화에 많은 시간이 소요될 수 있다.
- 외부 저장소가 저장할 수 있는 용량보다 더 많은 데이터가 전송될 수 있다.
- 동기화에 걸리는 많은 시간을 통해 데이터가 최신이 아닐 수 있다.
본 개시는 이와 같은 문제를 해결하기 위하여, 클러스터 간 동기화를 위한 방법을 제공한다.
도 1은 본 개시의 실시예에 따른 데이터 실시간 동기화를 위한 컨테이너 기반 클러스터 환경을 도시한다.
도 1을 참고하면, 네트워크 환경은 제1 클러스터(cluster)(100-1) 및 제2 클러스터(100-2)를 포함할 수 있다. 도 1에서는 클러스터에 관하여 제1 클러스터(100-1) 및 제2 클러스터(100-2)를 포함하는 것으로 도시되었으나, 이는 설명의 편의를 위할 뿐, 추가적인 클러스터가 있는 등의 환경을 배제하는 것은 아니다. 또한, 네트워크 환경은 제1 네트워크(130-1) 및 제2 네트워크(130-2)을 포함할 수 있다. 도 1에서는 네트워크에 관하여 제1 네트워크(130-1) 및 제2 네트워크(130-2)를 포함하는 것으로 도시되었으나, 이는 설명의 편의를 위할 뿐, 셋 이상의 네트워크가 있는 등의 환경을 배제하는 것은 아니다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터(100-1)의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터(100-2)의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
제1 클러스터(100-1)는 하나 이상의 제1 워커 노드(worker node)(110-1), 하나 이상의 제1 PV(persistent volume)(113a-1, 113b-1), 제1 마스터 노드(master node)(120-1)을 포함할 수 있다. 하나 이상의 제1 워커 노드(worker node)(110-1) 각각은 하나 이상의 제1 파드(pod)(111a-1, 111b-1)를 포함할 수 있고, 하나 이상의 제1 파드(111a-1, 111b-1) 각각은 하나 이상의 제1 PV(113a-1, 113b-1) 각각과 연결될 수 있다. 제1 클러스터(100-1)는 제1 네트워크(130-1)과 통신을 수행할 수 있다. 제1 클러스터(100-1)는 제2 네트워크(130-2)과 통신을 수행할 수 있다. 제1 네트워크(130-1)와 제2 네트워크(130-2)는 논리적 또는 지역적으로 구분될 수 있다.
제2 클러스터(100-2)는 제1 클러스터(100-1)와 논리적 또는 지역적으로 구분될 수 있다. 제2 클러스터(100-2)는 하나 이상의 제2 워커 노드(110-2), 하나 이상의 제2 PV(113a-2, 113b-2), 마스터 노드 (120-2)을 포함할 수 있다. 하나 이상의 제2 워커 노드(worker node)(110-2) 각각은 하나 이상의 제2 파드(111a-2, 111b-2)를 포함할 수 있고, 하나 이상의 제2 파드(111a-2, 111b-2) 각각은 하나 이상의 제2 PV(113a-2, 113b-2) 각각과 연결될 수 있다. 제2 클러스터(100-2)는 제1 네트워크(130-1)과 통신을 수행할 수 있다. 제2 클러스터(100-2)는 제2 네트워크(130-2)과 통신을 수행할 수 있다.
이하, 제1 클러스터(100-1) 및 제2 클러스터(100-2) 각각에 대한 설명은 클러스터에 대한 설명으로 적용될 수 있다. 하나 이상의 제1 워커 노드 (110-1) 및 하나 이상의 제2 워커 노드(worker node)(110-2) 각각에 대한 설명은 워커 노드에 대한 설명으로 적용될 수 있다. 하나 이상의 제1 파드(111a-1, 111b-1) 및 하나 이상의 제2 파드(111a-2, 111b-2) 각각에 대한 설명은 파드에 대한 설명으로 적용될 수 있다. 하나 이상의 제1 PV(113a-1, 113b-1) 및 하나 이상의 제2 PV(113a-2, 113b-2) 각각에 대한 설명은 PV에 대한 설명으로 적용될 수 있다. 제1 마스터 노드(120-1) 및 제2 마스터 노드(120-2) 각각에 대한 설명은 마스터 노드에 대한 설명으로 적용될 수 있다. 제1 네트워크(130-1) 및 제2 네트워크(130-2) 각각에 대한 설명은 네트워크에 대한 설명으로 적용될 수 있다.
클러스터는 컨테이너 기반 애플리케이션(application)을 호스팅하는 물리 환경 또는 가상 환경의 노드들로 이루어진 집합을 의미할 수 있다. 클러스터는 크게 워커 노드와 마스터 노드로 구분될 수 있다. 워커 노드는 하나 이상의 컨테이너가 배치되는 노드이고, 마스터 노드는 워커 노드를 관리하는 노드일 수 있다. 클러스터의 마스터 노드를 통해 관리자는 클러스터 전체를 제어할 수 있다.
워커 노드는 복수의 파드를 포함할 수 있다. 컨테이너 기반 클러스터는 워커 노드에서 실행할 컨테이너를 파드에 배치하여 실행할 수 있다. 워커 노드는 클러스터에 따라 VM(virtual machine) 또는 PM(physical machine)일 수 있다. 각각의 워커 노드는 마스터 노드에서 관리할 수 있다. 구체적으로, 각각의 워커 노드는 마스터 노드 내에 있는 제어 평면에서 관리할 수 있다. 본 개시의 일 실시예에 따르면, 각각의 워커 노드는 파드를 실행하는 데 필요한 서비스를 포함할 수 있다. 본 개시의 일 실시예에 따르면, 클러스터에는 여러 개의 워커 노드를 포함할 수 있다.
파드는 컨테이너 기반 클러스터에서 생성 및 관리할 수 있고 배포 가능한 가장 작은 컴퓨팅 단위일 수 있다. 본 개시의 일 실시예에 따르면, 파드는 공유 저장소 및 네트워크 자원과 컨테이너 실행 방법에 대한 사양을 포함하는 하나 이상의 컨테이너 그룹이다. 예를 들어, 공유 저장소는 PV일 수 있다.
PV는 클러스터의 저장소일 수 있다. 구체적으로, 관리자가 프로비저닝(provisioning)을 했거나 저장소 클래스를 사용하여 프로비저닝된 클러스터의 저장소일 수 있다. PV는 워커 노드가 클러스터의 자원인 것과 같이, 클러스터의 자원이다. PV는 PV를 사용하는 개별 파드와 독립적인 수명을 가질 수 있다.
마스터 노드는 제어 평면 및 데이터 평면을 포함할 수 있다. 본 개시의 일 실시예에 따르면, 제어 평면은 워커 노드가 등록될 때 노드에 CIDR(classless inter domain routing) 블록을 할당하는 역할을 수행할 수 있다. 본 개시의 일 실시예에 따르면, 제어 평면은 워커 노드의 목록을 클라우드 공급자의 사용 가능한 시스템 목록과 함께 최신 상태로 유지하는 역할을 수행할 수 있다. 구체적으로, 제어 평면은 클라우드 환경에서 실행 중이면서 워커 노드가 비정상일 때 해당 워커 노드의 VM을 계속 사용할 수 있는지 클라우드 공급자에게 물을 수 있다. 해당 워커 노드를 계속 사용할 수 없는 경우, 제어 평면은 워커 노드의 목록에서 해당 워커 노드를 삭제할 수 있다. 본 개시의 일 실시예에 따르면, 제어 평면은 노드의 상태를 모니터링할 수 있다.
네트워크는 무선 액세스 네트워크(radio access network)로서, 무선 접속 네트워크의 역할을 수행할 수 있다. 네트워크는 5G 코어 네트워크에 접속하기 위한 무선 채널을 제공하는 객체일 수 있다. 네트워크는 클러스터와 연결될 수 있다. 또한 네트워크는 유선 네트워크일 수 있다.
본 개시의 일 실시예에 따르면, 제1 클러스터(100-1)는 활성 상태의 클러스터일 수 있다. 본 개시의 일 실시예에 따르면, 제2 클러스터(100-2)는 대기 상태의 클러스터일 수 있다. 활성 상태의 클러스터란, 클러스터에 포함된 서비스 파드들이 실행 중이고 서비스가 되는 상태임을 의미할 수 있다. 대기 상태의 클러스터란, 클러스터에 포함된 서비스 파드들이 실행 중이나 서비스가 되지 않는 상태임을 의미할 수 있다. 여기서, 서비스 파드와 구별되는 동기화 파드는 활성 상태 또는 대기 상태인지 여부에 관계없이 실행 중이고 서비스가 되는 상태임을 의미할 수 있다. 동기화 파드는 HA(high availability) 파드, 데이터베이스 파드, 파일 복제 파드를 포함할 수 있다. HA 파드는 고 가용성 파드로써, 클러스터의 EMS의 상태를 판단하는 파드를 의미할 수 있다. 데이터베이스 파드는 데이터베이스 동기화를 위한 파드일 수 있다. 파일 복제 파드는 파일의 동기화를 위한 파드일 수 있다.
데이터는 하나 이상의 하나 이상의 제1 PV(113a-1, 113b-1) 각각에서 하나 이상의 제2 PV(113a-2, 113b-2) 각각으로 실시간 동기화될 수 있다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다.
본 개시의 일 실시예에 따르면, 제1 클러스터(100-1)에 포함된 하나 이상의 제1 파드(111a-1, 111b-1) 및 제2 클러스터(100-2)에 포함된 하나 이상의 제2 파드(111a-2, 111b-2)에 의해 실시간 동기화될 수 있다. 이러한 실시간 동기화를 통해, 제1 클러스터(100-1)의 상태가 활성 상태에서 대기 상태 또는 이상 상황에 의한 이상 상태로 바뀌더라도 제2 클러스터(100-2)가 제1 클러스터(100-1)에서 실행하던 애플리케이션을 즉시 실행할 수 있다. 제2 클러스터(100-2)는 제1 클러스터(100-1)에서 실행하던 애플리케이션을 즉시 실행하기 위하여, 제2 클러스터의 상태를 대기 상태에서 활성 상태로 변경할 수 있다.
본 개시의 일 실시예에 따르면, 실시간 동기화를 위해서는 대기 상태에서도 클러스터에 포함된 동기화 파드들이 실행 중이어야 한다. 즉, 실시간 동기화를 위한 대기 상태는 클러스터에 포함된 동기화 파드들은 실행 중이며, 동기화 파드에서 서비스도 되는 상태를 의미할 수 있다.
또한, 이러한 실시간 동기화를 위해서는, 대기 상태에서도 서비스 파드가 실행 중일 것이 요구될 수 있다. 대기 상태에서 서비스 파드가 실행 중이라는 의미는, 서비스 파드가 실행 중이고 서비스는 되지 않는 상태임을 의미할 수 있다.
이하, 도 2를 통해, 활성 상태의 제1 클러스터(100-1)가 이상 상황에 의해 이상 상태로 바뀌는 경우 데이터 동기화를 통하여 제2 클러스터(100-2)가 애플리케이션을 즉시 실행하는 시나리오가 설명된다.
도 2는 본 개시의 실시예에 따른 데이터 실시간 동기화를 위한 컨테이너 기반 클러스터 환경에서 이상 상황에 의한 이상 상태가 발생한 경우의 시나리오를 도시한다.
도 2을 참고하면, 네트워크 환경은 제1 클러스터(cluster)(200-1) 및 제2 클러스터(200-2)를 포함할 수 있다. 도2에서는 클러스터에 관하여 제1 클러스터(200-1) 및 제2 클러스터(200-2)를 포함하는 것으로 도시되었으나, 이는 설명의 편의를 위할 뿐, 추가적인 클러스터가 있는 등의 환경을 배제하는 것은 아니다. 또한, 네트워크 환경은 제1 네트워크(230-1) 및 제2 네트워크(230-2)을 포함할 수 있다. 도 2에서는 네트워크에 관하여 제1 네트워크(230-1) 및 제2 네트워크(230-2)를 포함하는 것으로 도시되었으나, 이는 설명의 편의를 위할 뿐, 셋 이상의 네트워크가 있는 등의 환경을 배제하는 것은 아니다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터(210)의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터(220)의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
제1 클러스터(200-1)는 하나 이상의 제1 워커 노드(worker node)(210-1), 하나 이상의 제1 PV(persistent volume)(213a-1, 213b-1), 제1 마스터 노드(master node)(220-1)을 포함할 수 있다. 하나 이상의 제1 워커 노드(worker node)(210-1) 각각은 하나 이상의 제1 파드(pod)(211a-1, 211b-1)를 포함할 수 있고, 하나 이상의 제1 파드(211a-1, 211b-1) 각각은 하나 이상의 제1 PV(213a-1, 213b-1) 각각과 연결될 수 있다. 제1 클러스터(200-1)는 제1 네트워크(230-1)과 통신을 수행할 수 있다. 제1 클러스터(200-1)는 제2 네트워크(230-2)과 통신을 수행할 수 있다. 제1 네트워크(230-1)와 제2 네트워크(230-2)는 논리적 또는 지역적으로 구분될 수 있다.
제2 클러스터(200-2)는 제1 클러스터(200-1)와 논리적 또는 지역적으로 구분될 수 있다. 제2 클러스터(200-2)는 하나 이상의 제2 워커 노드(210-2), 하나 이상의 제2 PV(213a-2, 213b-2), 마스터 노드 (220-2)을 포함할 수 있다. 하나 이상의 제2 워커 노드(worker node)(210-2) 각각은 하나 이상의 제2 파드(211a-2, 211b-2)를 포함할 수 있고, 하나 이상의 제2 파드(211a-2, 211b-2) 각각은 하나 이상의 제2 PV(213a-2, 213b-2) 각각과 연결될 수 있다. 제2 클러스터(200-2)는 제1 네트워크(230-1)과 통신을 수행할 수 있다. 제2 클러스터(200-2)는 제2 네트워크(230-2)과 통신을 수행할 수 있다.
이하, 제1 클러스터(200-1) 및 제2 클러스터(200-2) 각각에 대한 설명은 클러스터에 대한 설명으로 적용될 수 있다. 하나 이상의 제1 워커 노드 (210-1) 및 하나 이상의 제2 워커 노드(worker node)(210-2) 각각에 대한 설명은 워커 노드에 대한 설명으로 적용될 수 있다. 하나 이상의 제1 파드(211a-1, 211b-1) 및 하나 이상의 제2 파드(211a-2, 211b-2) 각각에 대한 설명은 파드에 대한 설명으로 적용될 수 있다. 하나 이상의 제1 PV(213a-1, 213b-1) 및 하나 이상의 제2 PV(213a-2, 213b-2) 각각에 대한 설명은 PV에 대한 설명으로 적용될 수 있다. 제1 마스터 노드(220-1) 및 제2 마스터 노드(220-2) 각각에 대한 설명은 마스터 노드에 대한 설명으로 적용될 수 있다. 제1 네트워크(230-1) 및 제2 네트워크(230-2) 각각에 대한 설명은 네트워크에 대한 설명으로 적용될 수 있다.
도 2를 참고하면, 제1 클러스터(200-1)에 이상 상황이 발생한 상황을 알 수 있다. 예를 들어, 이상 상황은 파드의 이상 상황 또는 인프라의 이상 상황일 수 있다. 인프라의 이상 상황은 워커 노드 크래시(crash), 클러스터 레벨 크래시, 저장소 크래시, 또는 독립적인 서비스 또는 네트워크 이상(abnormal)을 포함할 수 있다.
본 개시의 일 실시예에 따르면, 제1 클러스터(200-1)에 이상 상황이 발생하여 이상 상태가 된 경우, 제2 클러스터(200-2)는 대기 상태에서 활성 상태로 변경될 수 있다. 실시간 동기화를 통해, 제1 클러스터(200-1)의 상태가 활성 상태에서 대기 상태 또는 이상 상황에 의해 이상 상태로 바뀌더라도 제2 클러스터(200-2)가 제1 클러스터(200-1)에서 실행하던 애플리케이션을 즉시 실행할 수 있다. 이는, 제1 클러스터(200-1)에 포함된 하나 이상의 제1 PV(213a-1, 213b-1)와 제2 클러스터(100-2)에 포함된 하나 이상의 제2 PV(113a-2, 113b-2)가 실시간 동기화되었기 때문일 수 있다. 실시간 동기화는 제1 클러스터(100-1)에 포함된 하나 이상의 제1 파드(111a-1, 111b-1) 및 제2 클러스터(100-2)에 포함된 하나 이상의 제2 파드(111a-2, 111b-2)에 의해 이루어질 수 있다. 실시간 동기화를 통해, 제1 클러스터(200-1)의 상태가 이상 상황에 의해 이상 상태로 바뀌더라도 제2 클러스터(200-2)는 제1 클러스터(200-1)에서 실행하던 애플리케이션을 즉시 실행할 수 있다. 이상 상태의 식별은 HA 파드에 의해 이루어질 수 있다.
이러한 실시간 동기화를 위해서는, 대기 상태에서도 동기화 파드가 실행 중일 것이 요구될 수 있다. 대기 상태에서 동기화 파드가 실행 중이라는 의미는, 동기화 파드가 실행 중이고 서비스가 되는 상태를 의미할 수 있다.
동기화 파드는 HA(high availability) 파드, 데이터베이스 파드, 파일 복제 파드를 포함할 수 있다. HA 파드는 고 가용성 파드로써, 클러스터의 EMS의 상태를 판단하는 파드를 의미할 수 있다. 데이터베이스 파드는 데이터베이스 동기화를 위한 파드일 수 있다. 파일 복제 파드는 파일의 동기화를 위한 파드일 수 있다
또한, 이러한 실시간 동기화를 위해서는, 대기 상태에서도 서비스 파드가 실행 중일 것이 요구될 수 있다. 대기 상태에서 서비스 파드가 실행중이라는 의미는, 서비스 파드가 실행 중이고 서비스는 되지 않는 상태임을 의미할 수 있다. 구체적으로, 이는 도 3에서 더 자세히 설명된다.
도 3은 본 개시의 일 실시예에 따른 파드의 상태를 나타내는 도면이다.
도 3을 참고하면, 파드는 세 가지 상태를 포함할 수 있다. 구체적으로, 파드의 세 가지 상태는 실행 중이나 서비스는 되지 않는 파드(301), 실행 중이고 서비스가 되는 파드(303), 및 비정상적인 상태의 파드(305)로 나타낼 수 있다. 파드의 세 가지 상태는 모두 EMS에 의해 제어될 수 있다. 도 3에서는 파드는 세 가지 상태만 도시되었으나, 이는 설명의 편의를 위할 뿐, 추가적인 상태를 배제하는 것은 아니다. 이에 대해서는 도 5와 관련된 설명에서 보다 상세히 설명된다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
동기화 파드는 HA(high availability) 파드, 데이터베이스 파드, 파일 복제 파드를 포함할 수 있다. HA 파드는 고 가용성 파드로써, 클러스터의 EMS의 상태를 판단하는 파드를 의미할 수 있다. 데이터베이스 파드는 데이터베이스 동기화를 위한 파드일 수 있다. 파일 복제 파드는 파일의 동기화를 위한 파드일 수 있다.
실행 중이나 서비스는 되지 않는 파드(301)는 대기 상태의 클러스터에서의 서비스 파드를 의미할 수 있다. 파드는 클러스터의 EMS가 제어하고, 클러스터의 EMS의 일부일 수 있다. 대기 상태의 클러스터는 서비스가 실행되지 않으나, 데이터 동기화를 위하여 서비스 파드를 실행할 필요가 있다. 실행 중의 의미는, EMS 서비스를 위하여 실행 중이라는 의미일 수 있다. 또한, 실행 중의 의미는, 대기 상태에서도 데이터를 동기화하기 위하여 실행 중이라는 의미일 수 있다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다. 서비스가 되지 않는다는 의미는, EMS 서비스 어플리케이션을 실행하기 위한 서비스가 되지 않는다는 것을 의미할 수 있다. 즉, EMS 서비스 어플리케이션은 실행하지 않는 상태를 의미한다. 실행 중이나 서비스는 되지 않는 상태의 파드(301)는 초기화 컨테이너만 로딩되어 있고 다른 컨테이너들은 로딩되어 있지 않은 상태를 의미할 수 있다.
실행 중이고 서비스되는 파드(303)는 활성 상태의 클러스터에서의 서비스 파드를 의미할 수 있다. 또한, 서비스 파드와 구별되는 동기화 파드는 활성 상태 또는 대기 상태인지 여부에 관계없이 실행 중이고 서비스되는 파드(303)일 수 있다. 파드는 클러스터의 EMS가 제어하고, 클러스터의 EMS의 일부일 수 있다. 서비스가 된다는 의미는, EMS 서비스 어플리케이션을 실행하기 위한 서비스가 되고 있다는 것을 의미할 수 있다. 즉, EMS 서비스 어플리케이션이 실행 중이라는 것을 의미할 수 있다. 동기화 파드는 클러스터 1, 클러스터 2에서 실행 중 이므로, 데이터 동기화를 할 수 있다. 즉, 다른 파드에게 데이터를 전송할 수 있다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다.
비정상적인 파드(305)는 이상 상태의 클러스터에서의 파드를 의미할 수 있다. 파드는 클러스터의 EMS가 제어하고, 클러스터의 EMS의 일부일 수 있다. 이상 상태의 클러스터는 실행되지 않는 파드일 수 있다. 실행되지 않는 이유는 이상 상황에 의할 수 있다. 이상 상황은 EMS의 이상 상황으로써, 구체적으로 파드의 이상 상황 또는 인프라의 이상 상황일 수 있다. 인프라의 이상 상황은 워커 노드 크래시(crash), 클러스터 레벨 크래시, 저장소 크래시, 또는 독립적인 서비스 또는 네트워크 이상(abnormal)을 포함할 수 있다.
파드의 상태에 관하여 도 3에서 기술하였다. 도 4에서는 파드의 종류에 대해 설명된다.
도 4는 본 개시의 일 실시예에 따른 파드의 종류를 나타내는 도면이다.
도 4를 참고하면, 파드는 네 가지의 종류를 포함할 수 있다. 구체적으로, 파드의 네 가지 종류는 서비스 파드(401), HA 파드(403), 데이터베이스 파드(305), 및 파일 복제 파드(307) 등을 포함할 수 있다. 도 4에서는 파드는 네 가지 종류만 도시되었으나, 이는 설명의 편의를 위할 뿐, 다른 종류를 배제하는 것은 아니다. 서비스 파드(401), HA 파드(403), 데이터베이스 파드(405), 및 파일 복제 파드(407)는 모두 EMS에 의해 제어될 수 있다. 서비스 파드(401)를 제외한 HA 파드(403), 데이터베이스 파드(305), 및 파일 복제 파드(307)는 동기화 파드에 포함될 수 있다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
서비스 파드(401)는 EMS 어플리케이션을 실행할 수 있는 파드를 의미할 수 있다. 클러스터가 활성 상태인 경우, 실행 중이고 서비스가 가능한 상태로써, 어플리케이션을 실행할 수 있다. 즉, 클러스터가 활성 상태에서는 서비스 파드(401)는 실행 중이고 서비스가 되는 파드(303)일 수 있다. 컨테이너 기반 클러스터에 포함된 애플리케이션이 상태 종속적인(stateful) 애플리케이션인 경우, 어느 하나의 클러스터가 활성 상태이면, 다른 하나의 클러스터는 대기 상태를 유지하는 것이 필요할 수 있다. 어느 하나의 클러스터가 활성 상태인 경우, 다른 하나의 클러스터는 대기 상태여야 하는 데, 대기 상태는 서비스 파드(401)가 실행 중이나 서비스는 되지 않는 상태를 의미할 수 있다. 이러한 클러스터 대기 상태에서는 서비스 파드(401)는 실행 중이나 서비스는 되지 않는 파드(301)일 수 있다. 대기 상태에서는 서비스 파드(401)는 서비스는 되지 않으나, 데이터의 동기화를 위해서 실행중이어야 할 수 있다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다.
HA 파드(403)는 고 가용성 파드로써, 상태를 판단하는 파드를 의미할 수 있다. HA 파드(403)은 클러스터의 상태를 파악할 수 있다. 클러스터의 상태 파악을 위하여, HA 파드(403)은 클러스터의 상태와 무관하게 실행 중이고 서비스가 되어야 할 수 있다. 예를 들어, HA 파드(403)은 대기 상태인 경우에도 클러스터의 상태를 파악하기 위하여 서비스가 되어야 할 수 있다. 즉, HA 파드(403)는 상태와 무관하게 실행 중이고 서비스가 되는 파드(303)일 수 있다.
본 개시의 일 실시예에 따르면, HA 파드(403)은 자신의 클러스터의 상태를 파악할 수 있다, 예를 들어, HA 파드(403)는 다른 클러스터의 상태도 파악할 수 있다. 또한 HA 파드(403)는 클러스터의 상태를 파악하여, 클러스터의 상태를 변경할 수 있다. 예를 들어, 자신의 클러스터의 상태가 대기 상태이고 다른 클러스터가 대기 상태인 경우, 자신의 클러스터의 상태를 활성 상태로 변경할 수 있다. 예를 들어, 자신의 클러스터의 상태가 대기 상태이고 다른 클러스터가 대기 상태인 경우, 다른 클러스터의 상태를 활성 상태로 변경할 수 있다. 예를 들어, 자신의 클러스터의 상태가 활성 상태이고 다른 클러스터가 활성 상태인 경우, 자신의 클러스터의 상태를 대기 상태로 변경할 수 있다. 예를 들어, 자신의 클러스터의 상태가 활성 상태이고 다른 클러스터가 활성 상태인 경우, 다른 클러스터의 상태를 대기 상태로 변경할 수 있다. 클러스터의 상태 변경은 우선 순위에 의할 수 있다.
데이터베이스 파드(405)는 데이터베이스 동기화를 위한 파드일 수 있다. 데이터베이스 파드(405)를 통해 자신의 클러스터와 다른 클러스터의 PV 사이의 데이터베이스를 동기화할 수 있다. 데이터 동기화를 위하여는, 클러스터의 상태와 무관하게 서비스가 수행되어야 한다. 즉, 데이터베이스 파드(405)는 클러스터의 상태와 무관하게 실행 중이고 서비스가 되는 파드(303)일 수 있다. 이는 다른 클러스터의 상태가 활성 상태에서 대기 상태 또는 이상 상황에 의한 이상 상태로 변경된 경우, 자신의 클러스터에서 이전에 다른 클러스터에서 실행 중이었던 어플리케이션을 즉시 실행하기 위함이다.
파일 복제 파드(407)는 파일의 동기화를 위한 파드일 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있다. 파일 복제 파드(407)를 통해 자신의 클러스터와 다른 클러스터의 PV 사이의 파일을 동기화할 수 있다. 파일 동기화를 위하여는, 클러스터의 상태와 무관하게 서비스되어야 할 수 있다. 즉, 파일 복제 파드(407)는 클러스터의 상태와 무관하게 실행 중이고 서비스가 되는 파드(303)일 수 있다. 이는 다른 클러스터의 상태가 활성 상태에서 대기 상태 또는 이상 상황에 의한 이상 상태로 변경된 경우, 자신의 클러스터에서 이전에 다른 클러스터에서 실행 중이었던 어플리케이션을 즉시 실행하기 위한 파일을 실시간으로 저장하기 위함이다.
도 4에서는 파드의 종류 및 역할에 관하여 기술하였다. 도 5에서는 파드의 수명과 관련하여 설명된다.
도 5는 본 개시의 일 실시예에 따른 파드의 수명을 나타내는 도면이다.
도 5를 참고하면, 파드는, 예를 들어, 다섯 가지 상태를 포함할 수 있다. 구체적으로, 파드의 다섯 가지 상태는 파드 펜딩(501), 파드 실행 중(503), 성공(505), 실패(507), 및 알 수 없음(509)로 나타낼 수 있다. 파드의 다섯 가지 상태는 모두 EMS에 의해 제어될 수 있다. 도 5에서는 파드는 다섯 가지 종류만 도시되었으나, 이는 설명의 편의를 위할 뿐, 추가적인 상태를 배제하는 것은 아니다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
파드 펜딩(501)은 파드가 승인되었으나, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않은 상태를 의미할 수 있다. 실행할 준비가 되지 않은 상태는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함될 수 있다.
파드 실행 중(503)은 파드의 모든 컨테이너가 생성되었고, 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있는 것을 의미할 수 있다.
성공(505)는 파드에 있는 모든 컨테이너들이 성공적으로 종료되었고, 재시작되지 않음을 의미할 수 있다.
실패(507)는 파드에 있는 모든 컨테이너가 종료되었고, 적어도 하나의 컨테이너가 실패로 종료되었음을 의미할 수 있다.
알 수 없음(509)는 어떤 이유에 의해서 파드의 상태를 얻을 수 없음을 의미할 수 있다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생할 수 있다.
도 5에서는 파드의 수명과 관련하여 설명되었다. 도 6에서는 파드가 어플리케이션을 실행하는 과정이 설명된다.
도 6은 본 개시의 일 실시예에 따른 파드가 어플리케이션을 실행하는 과정을 나타내는 순서도를 도시한다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
도 6을 참고하면, 단계(610)에서 EMS는 초기화 컨테이너(initial container)를 식별할 수 있다. 초기화 컨테이너는 요구되는 모든 자원이 실행된 컨테이너일 수 있다. 본 개시의 일 실시예에 따르면, 초기화 컨테이너에서 컨테이너의 EMS에 포함된 파드의 상태는 실행 중이나 서비스는 되지 않는 상태인 파드(301)일 수 있다. 즉, 실행 중이나 서비스는 되지 않는 상태의 파드(301)는 초기화 컨테이너만 로딩되어 있고 다른 컨테이너들은 로딩되어 있지 않은 상태를 의미할 수 있다.
단계(620)에서, EMS는 컨테이너가 활성 상태인지 여부를 식별할 수 있다. 컨테이너의 활성 상태인 경우 어플리케이션을 실행하기 위함이다. 본 개시의 일 실시예에 따르면, 활성 상태에서의 서비스 파드의 상태는 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 현재 컨테이너의 상태가 대기 상태인 경우, 단계(630)으로 진행될 수 있다. 현재 컨테이너의 상태가 활성 상태인 경우, 단계(640)으로 진행될 수 있다. 본 개시의 일 실시예에 따르면, 상태 확인은 EMS에 포함된 HA 파드(403)에 의해 이루어질 수 있다.
단계(630)에서, EMS는 설정된 시간 간격동안 대기할 수 있다. 본 개시의 일 실시예에 따르면, 컨테이너의 EMS에 포함된 파드의 상태는 실행 중이나 서비스는 되지 않는 상태인 파드(301)일 수 있다.
단계(640)에서, EMS는 어플리케이션을 실행할 수 있다. 활성 상태에서의 서비스 파드의 상태는 실행 중이고 서비스되는 상태인 파드(303)일 수 있다.
도 6에서는 파드가 어플리케이션을 실행하는 과정이 설명되었다. 도 7 및 도 8에서는 EMS까 데이터 동기화를 수행하기 위한 흐름도가 도시된다. 도 7에서는, 제1 EMS에 이상 상황이 발생하는 경우에 관한 흐름도가 도시되고, 도 8에서는, 제1 EMS에 이상 상황이 발생하지 않은 경우에 관한 흐름도가 도시된다.
도 7에서는 본 개시의 일 실시예에 따른 EMS가 데이터를 동기화하기 위한 흐름도를 도시한다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
도 7을 참고하면, 단계(701)에서 제1 EMS(710)는 제1 초기화 컨테이너를 식별할 수 있다. 초기화 컨테이너는 요구되는 모든 자원이 실행된 컨테이너일 수 있다. 본 개시의 일 실시예에 따르면, 초기화 컨테이너에서 컨테이너의 EMS에 포함된 파드의 상태는 실행 중이나 서비스는 되지 않는 상태인 파드(301)일 수 있다.
단계(703)에서, 제2 EMS(720)는 제2 초기화 컨테이너를 식별할 수 있다. 초기화 컨테이너는 요구되는 모든 자원이 실행된 컨테이너일 수 있다. 본 개시의 일 실시예에 따르면, 초기화 컨테이너에서 컨테이너의 EMS에 포함된 파드의 상태는 실행 중이나 서비스는 되지 않는 상태인 파드(301)일 수 있다.
단계(705)에서, 제1 EMS(710)는 컨테이너의 상태를 식별할 수 있다. 예를 들어, 제1 EMS(710)는 파드가 활성 상태인지 여부를 식별할 수 있다. 컨테이너가 활성 상태인 경우 제1 EMS(710)가 어플리케이션을 실행하기 위함이다. 본 개시의 일 실시예에 따르면, 활성 상태에서의 서비스 파드의 상태는 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제1 EMS(710)가 활성 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 상태 확인은 제1 EMS(710)에 포함된 HA 파드(403)에 의해 이루어질 수 있다.
단계(707)에서, 제2 EMS(720)는 컨테이너의 상태를 식별할 수 있다. 예를 들어, 제2 EMS(720)는 파드가 활성 상태인지 여부를 식별할 수 있다. 활성 상태인 경우 제2 EMS(720)가 어플리케이션을 실행하기 위함이다. 본 개시의 일 실시예에 따르면, 활성 상태에서의 서비스 파드의 상태는 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS(720)가 대기 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 상태 확인은 제2 EMS(720)에 포함된 HA 파드(403)에 의해 이루어질 수 있다.
단계(709)에서, 제1 EMS(710)는 데이터를 전송할 수 있다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다. 데이터는 실시간 동기화될 수 있다. 파일은 파일 복제 파드(407)를 통해 동기화될 수 있다. 데이터베이스는 데이터베이스 파드(405)를 통하여 동기화될 수 있다. 제2 EMS(720)의 상태는 대기 상태이나, 제2 EMS(720)에 포함된 서비스 파드(401)는 실행 중이나 서비스는 되지 않는 파드(301)이므로, 실행 중이므로 데이터가 동기화될 수 있다. 데이터는 제1 클러스터(100-1)에 포함된 하나 이상의 제1 파드(111a-1, 111b-1) 및 제2 클러스터(100-2)에 포함된 하나 이상의 제2 파드(111a-2, 111b-2)에 의해 실시간 동기화될 수 있다. 데이터는 하나 이상의 제1 PV(113a-1, 113b-1) 각각에서 하나 이상의 제2 PV(113a-2, 113b-2) 각각으로 실시간 동기화될 수 있다.
단계(711)에서, 제2 EMS(720)는 상태 확인 메시지를 전송할 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS(720)의 상태 확인 메시지는 제2 EMS(720)에 포함된 HA 파드(403)가 전송할 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS(720)의 상태 확인은 제1 EMS(710)에 포함된 HA 파드(403)와 제2 EMS(720)에 포함된 HA 파드(403)의 메시지 송수신을 통해 이루어질 수 있다.
단계(713)에서, 제1 EMS(710)는 상태 응답 메시지를 전송할 수 있다. 본 개시의 일 실시예에 따르면, 제1 EMS(710)의 상태 응답 메시지는 제1 EMS(710)에 포함된 HA 파드(403)가 전송할 수 있다. 본 개시의 일 실시예에 따르면, 상태 응답 메시지는 제1 EMS(710)가 대기 상태임을 나타내는 메시지일 수 있다. 본 개시의 일 실시예에 따르면, 상태 응답 메시지는 전송되지 않을 수 있다. 상태 응답 메시지는 제1 EMS(710)의 이상 상황에 의한 이상 상태로 인하여 전송되지 않을 수 있다. 예를 들어, 이상 상황은 파드의 이상 상황 또는 인프라의 이상 상황일 수 있다. 인프라의 이상 상황은 워커 노드 크래시(crash), 클러스터 레벨 크래시, 저장소 크래시, 또는 독립적인 서비스 또는 네트워크 이상(abnormal)을 포함할 수 있다.
단계(715)에서, 제1 EMS(710)는 제2 EMS(710)의 상태를 대기 상태로 변경할 수 있다. 상태 종속적인(stateful) 애플리케이션인 경우, 어느 하나의 컨테이너 기반 클러스터가 활성 상태이면, 나머지 컨테이너 기반 클러스터는 대기 상태(standby state)를 유지하는 것이 필요하기 때문이다. 본 개시의 일 실시예에 따르면, 제1 EMS(710)의 상태를 활성 상태로 변경하는 것은 HA 파드(403)에 의한 것일 수 있다. 실시간 동기화를 통해, 제1 EMS(710)가 대기 상태로 변경되더라도 데이터는 하나 이상의 하나 이상의 제1 PV(113a-1, 113b-1) 각각에서 하나 이상의 제2 PV(113a-2, 113b-2) 각각으로 실시간 동기화될 수 있다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다.
단계(717)에서, 제2 EMS(720)는 제2 EMS(720)의 상태를 활성 상태로 변경할 수 있다. 상태 종속적인(stateful) 애플리케이션인 경우, 어느 하나의 컨테이너 기반 클러스터가 활성 상태이면, 나머지 컨테이너 기반 클러스터는 대기 상태(standby state)를 유지하는 것이 필요하기 때문이다. 본 개시의 일 실시예에 따르면, 제2 EMS(720)의 상태를 활성 상태로 변경하는 것은 HA 파드(403)에 의한 것일 수 있다. 실시간 동기화를 통해, 제2 EMS(720)는 제1 EMS(710)에서 실행하던 애플리케이션을 즉시 실행할 수 있다. 이는, 제1 클러스터(100-1)에 포함된 하나 이상의 제1 PV(113a-1, 113b-1)와 제2 클러스터(100-2)에 포함된 하나 이상의 제2 PV(113a-2, 113b-2)가 실시간 동기화되었기 때문이다. 실시간 동기화는 제1 클러스터(100-1)에 포함된 하나 이상의 제1 파드(111a-1, 111b-1) 및 제2 클러스터(100-2)에 포함된 하나 이상의 제2 파드(111a-2, 111b-2)에 의해 이루어질 수 있다. 실시간 동기화를 통해, 제1 EMS(710)의 상태가 이상 상황에 의해 이상 상태로 바뀌더라도 제2 EMS(720)는 제1 EMS(710)에서 실행하던 애플리케이션을 즉시 실행할 수 있다.
도 7에서는, 제1 EMS에 이상 상황이 발생하는 경우에 관한 흐름도가 도시되었다. 도 8에서는, 제1 EMS에 이상 상황이 발생하지 않은 경우에 관한 흐름도가 도시된다.
도 8은 본 개시의 일 실시예에 따른 EMS가 데이터를 동기화하기 위한 흐름도를 도시한다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
도 8을 참고하면, 단계(801)에서 제1 EMS(810)는 제1 초기화 컨테이너를 식별할 수 있다. 초기화 컨테이너는 요구되는 모든 자원이 실행된 컨테이너일 수 있다. 본 개시의 일 실시예에 따르면, 초기화 컨테이너에서 컨테이너의 EMS에 포함된 파드의 상태는 실행 중이나 서비스는 되지 않는 상태인 파드(301)일 수 있다.
단계(803)에서, 제2 EMS(820)는 제2 초기화 컨테이너를 식별할 수 있다. 초기화 컨테이너는 요구되는 모든 자원이 실행된 컨테이너일 수 있다. 본 개시의 일 실시예에 따르면, 초기화 컨테이너에서 컨테이너의 EMS에 포함된 파드의 상태는 실행 중이나 서비스는 되지 않는 상태인 파드(301)일 수 있다.
단계(805)에서, 제1 EMS(810)는 컨테이너의 상태를 식별할 수 있다. 컨테이너가 활성 상태인 경우 제1 EMS(810)가 어플리케이션을 실행하기 위함이다. 본 개시의 일 실시예에 따르면, 활성 상태에서의 서비스 파드의 상태는 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제1 EMS(810)가 활성 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 상태 확인은 제1 EMS(810)에 포함된 HA 파드(403)에 의해 이루어질 수 있다.
단계(807)에서, 제2 EMS(820)는 컨테이너의 상태를 식별할 수 있다. 활성 상태인 경우 제2 EMS(820)가 어플리케이션을 실행하기 위함이다. 본 개시의 일 실시예에 따르면, 활성 상태에서의 서비스 파드의 상태는 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS(820)가 대기 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 상태 확인은 제2 EMS(820)에 포함된 HA 파드(403)에 의해 이루어질 수 있다.
단계(809)에서, 제1 EMS(810)는 데이터를 전송할 수 있다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다. 데이터는 실시간 동기화될 수 있다. 파일은 파일 복제 파드(407)를 통해 동기화될 수 있다. 데이터는 데이터베이스 파드(405)를 통하여 동기화될 수 있다. 제2 EMS(820)의 상태는 대기 상태이나, 제2 EMS(820)에 포함된 서비스 파드(401)는 실행 중이나 서비스는 되지 않는 파드(301)이므로, 실행 중이므로 데이터가 동기화될 수 있다. 데이터는 제1 클러스터(100-1)에 포함된 하나 이상의 제1 파드(111a-1, 111b-1) 및 제2 클러스터(100-2)에 포함된 하나 이상의 제2 파드(111a-2, 111b-2)에 의해 실시간 동기화될 수 있다. 데이터는 하나 이상의 제1 PV(113a-1, 113b-1) 각각에서 하나 이상의 제2 PV(113a-2, 113b-2) 각각으로 실시간 동기화될 수 있다.
단계(811)에서, 제2 EMS(820)는 상태 확인 메시지를 전송할 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS(820)의 상태 확인 메시지는 제2 EMS(820)에 포함된 HA 파드(403)가 전송할 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS(820)의 상태 확인은 제1 EMS(810)에 포함된 HA 파드(403)와 제2 EMS(820)에 포함된 HA 파드(403)의 메시지 송수신을 통해 이루어질 수 있다. 상태 확인 메시지를 전송할 수 있다.
단계(813)에서, 제1 EMS(810)는 상태 응답 메시지를 전송할 수 있다. 본 개시의 일 실시예에 따르면, 제1 EMS(810)의 상태 응답 메시지는 제1 EMS(810)에 포함된 HA 파드(403)가 전송할 수 있다. 본 개시의 일 실시예에 따르면, 상태 응답 메시지는 제1 EMS(810)가 대기 상태임을 나타내는 메시지일 수 있다. 본 개시의 일 실시예에 따르면, 상태 응답 메시지는 전송되지 않을 수 있다. 상태 응답 메시지는 제1 EMS(810)의 이상 상황에 의한 이상 상태로 인하여 전송되지 않을 수 있다. 예를 들어, 이상 상황은 파드의 이상 상황 또는 인프라의 이상 상황일 수 있다. 인프라의 이상 상황은 워커 노드 크래시(crash), 클러스터 레벨 크래시, 저장소 크래시, 또는 독립적인 서비스 또는 네트워크 이상(abnormal)을 포함할 수 있다.
단계(715)에서, 제1 EMS(710)는 제2 EMS(710)의 상태를 활성 상태로 유지할 수 있다. 상태 종속적인(stateful) 애플리케이션인 경우, 어느 하나의 컨테이너 기반 클러스터가 활성 상태인 경우, 나머지 컨테이너 기반 클러스터는 대기 상태(standby state)를 유지하는 것이 필요하기 때문이다. 실시간 동기화를 통해, 제2 EMS(720)가 대기 상태라도 데이터는 하나 이상의 하나 이상의 제1 PV(113a-1, 113b-1) 각각에서 하나 이상의 제2 PV(113a-2, 113b-2) 각각으로 실시간 동기화될 수 있다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다.
단계(817)에서, 제2 EMS(820)는 제2 EMS(820)의 상태를 유지할 수 있다. 상태 종속적인(stateful) 애플리케이션인 경우, 어느 하나의 컨테이너 기반 클러스터가 활성 상태인 경우, 나머지 컨테이너 기반 클러스터는 대기 상태(standby state)를 유지하는 것이 필요하기 때문이다.
도 7 및 도 8에서는 EMS까 데이터 동기화를 수행하기 위한 흐름도가 도시되었다. 도 9 및 도 10에서는 데이터 동기화를 수행하는 EMS를 나타내는 순서도가 도시된다.
도 9는 본 개시의 일 실시예에 따른 데이터 동기화를 수행하는 제2 EMS를 나타내는 순서도를 도시한다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
도 9를 참고하면, 단계(910)에서, 제2 EMS는 초기화 컨테이너를 실행한다. 초기화 컨테이너는 요구되는 모든 자원이 실행된 컨테이너일 수 있다. 본 개시의 일 실시예에 따르면, 초기화 컨테이너에서 컨테이너의 EMS에 포함된 파드의 상태는 실행 중이나 서비스는 되지 않는 상태인 파드(301)일 수 있다.
단계(930)에서, 제2 EMS는 제2 EMS의 상태를 식별할 수 있다. 제2 EMS의 상태가 활성 상태인 경우 제2 EMS가 어플리케이션을 실행하기 위함이다. 본 개시의 일 실시예에 따르면, 제2 EMS의 상태가 활성 상태에서의 서비스 파드의 상태는 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS의 상태가 활성 상태인 경우 서비스 파드(401)의 상태가 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS가 활성 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS가 대기 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 상태 확인은 제2 EMS에 포함된 HA 파드(403)에 의해 이루어질 수 있다.
단계(950)에서, 제2 EMS는 제2 EMS의 상태가 대기 상태임을 식별할 수 있다. 제2 EMS의 상태가 대기 상태인 경우, 제2 EMS는 제1 EMS로부터 데이터를 수신할 수 있다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다. 데이터는 실시간 동기화될 수 있다. 파일은 파일 복제 파드(407)를 통해 동기화될 수 있다. 데이터베이스는 데이터베이스 파드(405)를 통하여 동기화될 수 있다. 제2 EMS의 상태는 대기 상태이나, 제2 EMS에 포함된 서비스 파드(401)는 실행 중이나 서비스는 되지 않는 파드(301)이므로, 실행 중이므로 데이터가 동기화될 수 있다. 데이터는 제1 클러스터(100-1)에 포함된 하나 이상의 제1 파드(111a-1, 111b-1) 및 제2 클러스터(100-2)에 포함된 하나 이상의 제2 파드(111a-2, 111b-2)에 의해 실시간 동기화될 수 있다. 데이터는 하나 이상의 제1 PV(113a-1, 113b-1) 각각에서 하나 이상의 제2 PV(113a-2, 113b-2) 각각으로 실시간 동기화될 수 있다.
단계(970)에서, 제2 EMS는 제1 EMS의 상태를 확인할 수 있다. 본 개시의 일 실시예에 따르면, 제1 EMS의 상태 확인은 상태 확인 메시지의 전송을 통해 이루어질 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS의 상태 확인 메시지는 제2 EMS에 포함된 HA 파드(403)가 전송할 수 있다. 제1 EMS(820)의 상태 확인은 제1 EMS에 포함된 HA 파드(403)와 제2 EMS에 포함된 HA 파드(403)의 메시지 송수신을 통해 이루어질 수 있다.
제2 EMS는 제1 EMS의 상태가 대기 상태 또는 이상 상태인지 여부를 식별할 수 있다. 본 개시의 일 실시예에 따르면, 제1 EMS에 포함된 HA 파드로부터 수신한 메시지에 기반하여 제1 EMS의 상태가 대기 상태 또는 이상 상태인지 여부를 식별할 수 있다. 본 개시의 일 실시예에 따르면, 제1 EMS에 포함된 HA 파드로부터 메시지가 수신되지 않을 수 있다. 제1 EMS에 이상 상황에 의한 이상 상태가 발생한 경우, HA 파드로부터 메시지가 수신되지 않을 수 있다. 예를 들어, 이상 상황은 파드의 이상 상황 또는 인프라의 이상 상황일 수 있다. 인프라의 이상 상황은 워커 노드 크래시(crash), 클러스터 레벨 크래시, 저장소 크래시, 또는 독립적인 서비스 또는 네트워크 이상(abnormal)을 포함할 수 있다.
단계(990)에서, 제2 EMS는 제1 EMS의 상태가 대기 상태 또는 이상 상태인지 여부가 식별된 경우, 제1 EMS로부터 수신한 데이터에 기반하여 제2 EMS의 상태를 활성 상태로 변경할 수 있다. 상태 종속적인(stateful) 애플리케이션인 경우, 어느 하나의 컨테이너 기반 클러스터가 활성 상태인 경우, 나머지 컨테이너 기반 클러스터는 대기 상태(standby state)를 유지하는 것이 필요하기 때문이다. 본 개시의 일 실시예에 따르면, 제2 EMS의 상태를 활성 상태로 변경하는 것은 HA 파드에 의한 것일 수 있다. 실시간 동기화를 통해, 제2 EMS는 제1 EMS에서 실행하던 애플리케이션을 즉시 실행할 수 있다. 이는, 제1 클러스터(100-1)에 포함된 하나 이상의 제1 PV(113a-1, 113b-1)와 제2 클러스터(100-2)에 포함된 하나 이상의 제2 PV(113a-2, 113b-2)가 실시간 동기화되었기 때문이다. 실시간 동기화는 제1 클러스터(100-1)에 포함된 하나 이상의 제1 파드(111a-1, 111b-1) 및 제2 클러스터(100-2)에 포함된 하나 이상의 제2 파드(111a-2, 111b-2)에 의해 이루어질 수 있다. 실시간 동기화를 통해, 제1 EMS의 상태가 이상 상황에 의해 이상 상태로 바뀌더라도 제2 EMS는 제1 EMS에서 실행하던 애플리케이션을 즉시 실행할 수 있다.
도 9에서는 데이터 동기화를 수행하는 제2 EMS를 나타내는 순서도가 도시되었다. 도 10에서는 데이터 동기화를 수행하는 제1 EMS를 나타내는 순서도가 도시된다.
도 10은 본 개시의 일 실시예에 따른 데이터 동기화를 수행하는 제1 EMS를 나타내는 순서도를 도시한다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
도 10을 참고하면, 단계(1010)에서, 제1 EMS는 초기화 컨테이너를 실행한다. 초기화 컨테이너는 요구되는 모든 자원이 실행된 컨테이너일 수 있다. 본 개시의 일 실시예에 따르면, 초기화 컨테이너에서 컨테이너의 EMS에 포함된 파드의 상태는 실행 중이나 서비스는 되지 않는 상태인 파드(301)일 수 있다.
단계(1030)에서, 제1 EMS는 제1 EMS의 상태를 식별할 수 있다. 제1 EMS의 상태가 활성 상태인 경우 제1 EMS가 어플리케이션을 실행하기 위함이다. 본 개시의 일 실시예에 따르면, 제1 EMS의 상태가 활성 상태에서의 서비스 파드의 상태는 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제1 EMS의 상태가 활성 상태인 경우 서비스 파드(401)의 상태가 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS가 활성 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS가 대기 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 상태 확인은 제2 EMS에 포함된 HA 파드(403)에 의해 이루어질 수 있다.
단계(1030)에서, 제1 EMS는 제1 EMS의 상태를 식별할 수 있다. 제1 EMS의 상태가 활성 상태인 경우 제1 EMS가 어플리케이션을 실행하기 위함이다. 본 개시의 일 실시예에 따르면, 제1 EMS의 상태가 활성 상태에서의 서비스 파드의 상태는 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제1 EMS의 상태가 활성 상태인 경우 서비스 파드(401)의 상태가 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS가 활성 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 제2 EMS가 대기 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 상태 확인은 제2 EMS에 포함된 HA 파드(403)에 의해 이루어질 수 있다.
단계(1050)에서, 제1 EMS는 제1 EMS의 상태가 활성 상태임을 식별할 수 있다. EMS의 상태가 활성 상태인 경우 제1 EMS가 어플리케이션을 실행하기 위함이다. 본 개시의 일 실시예에 따르면, 활성 상태에서의 서비스 파드의 상태는 실행 중이고 서비스되는 상태인 파드(303)일 수 있다. 본 개시의 일 실시예에 따르면, 제1 EMS(810)가 활성 상태임을 식별할 수 있다. 본 개시의 일 실시예에 따르면, 상태 확인은 제1 EMS(810)에 포함된 HA 파드(403)에 의해 이루어질 수 있다.
제1 EMS는 데이터를 전송할 수 있다. 여기서, 데이터는 데이터 파일 및 어플리케이션 실행을 위한 데이터를 포함할 수 있다. 파일은 클러스터에 저장된 데이터를 의미할 수 있고, 어플리케이션 실행을 위한 데이터는 EMS가 실행 중인 어플리케이션과 관련된 데이터일 수 있다. 데이터는 실시간 동기화될 수 있다. 파일은 파일 복제 파드(407)를 통해 동기화될 수 있다. 데이터베이스는 데이터베이스 파드(405)를 통하여 동기화될 수 있다. 제2 EMS의 상태는 대기 상태이나, 제2 EMS에 포함된 서비스 파드(401)는 실행 중이나 서비스는 되지 않는 파드(301)이므로, 실행 중이므로 데이터가 동기화될 수 있다. 데이터는 제1 클러스터(100-1)에 포함된 하나 이상의 제1 파드(111a-1, 111b-1) 및 제2 클러스터(100-2)에 포함된 하나 이상의 제2 파드(111a-2, 111b-2)에 의해 실시간 동기화될 수 있다. 데이터는 하나 이상의 제1 PV(113a-1, 113b-1) 각각에서 하나 이상의 제2 PV(113a-2, 113b-2) 각각으로 실시간 동기화될 수 있다.
도 11은 본 개시의 일 실시예에 따른 컨테이너 기반 클러스터 환경에서의 장치도를 도시한다. 도 11에 예시된 구성은 제1 클러스터, 제1 네트워크, 제2 클러스터, 제2 네트워크 중 적어도 하나의 기능을 가지는 장치의 구성으로서 이해될 수 있다. 제1 클러스터 및 제2 클러스터 컨테이너 기반 클러스터에 대응될 수 있다.
본 개시의 일 실시예에 따르면, 클러스터에 대한 설명은 클러스터에 포함된 EMS에 대한 설명에 대한 의미로 쓰일 수 있다. 또한 클러스터의 상태는 클러스터에 포함된 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제1 클러스터의 상태는 제1 클러스터에 포함된 제1 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 제2 클러스터의 상태는 제2 클러스터에 포함된 제2 EMS의 상태와 동일한 의미로 쓰일 수 있다. 예를 들어, 후보 클러스터의 상태는 후보 클러스터에 포함된 후보 EMS의 상태와 동일한 의미로 쓰일 수 있다. 본 개시의 일 실시예에 따르면, 어플리케이션에 대한 설명은 EMS 서비스 어플리케이션에 대한 설명에 대한 의미로 쓰일 수 있다.
도 11를 참조하면, 클러스터 또는 네트워크는 송수신부(1110), 메모리(1130), 프로세서(1120)를 포함하여 구성된다.
송수신부(1110)는 다른 장치들과 통신을 수행하기 위한 인터페이스를 제공한다. 구체적으로, 송수신부(1110)는 클러스터 또는 네트워크의 객체에서 다른 클러스터 또는 네트워크 객체 또는 다른 장치로 송신되는 비트열을 물리적 신호로 변환하고, 다른 장치로부터 수신되는 물리적 신호를 비트열로 변환한다. 즉, 송수신부(1110)는 신호를 송신 및 수신할 수 있다. 구체적으로, 송수신부(1110)는 이에 따라, 송수신부(1110)는 모뎀(modem), 송신부(transmitter), 수신부(receiver) 또는 송수신부(transceiver)로 지칭될 수 있다.
메모리(1130)는 클러스터 또는 네트워크의 객체의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장한다. 본 개시의 일 실시예에 따르면, 메모리(1130)는 클러스터 또는 네트워크의 동작을 위한 기본 프로그램, 응용 프로그램, 설정 정보 등의 데이터를 저장한다. 메모리(1130)는 휘발성 메모리, 비휘발성 메모리 또는 휘발성 메모리와 비휘발성 메모리의 조합으로 구성될 수 있다. 그리고, 메모리(1130)는 프로세서(1120)의 요청에 따라 저장된 데이터를 제공한다.
프로세서(1120)는 클러스터 또는 네트워크의 객체의 전반적인 동작들을 제어한다. 본 개시의 일 실시예에 따르면, 프로세서(1120)는 송수신부(1110)를 통해 신호를 송수신한다. 또한, 프로세서(1120)는 메모리(1130)에 데이터를 기록하고, 읽는다. 이를 위해, 프로세서(1120)는 적어도 하나의 프로세서(processor)를 포함할 수 있다. 본 개시의 다양한 실시예들에 따라, 프로세서(1120)는 무선 통신망을 이용한 동기화를 수행하도록 제어할 수 있다. 예를 들어, 프로세서(1120)는 전술한 클러스터 또는 네트워크의 객체의 전반적인 동작들을 제어할 수 있다.
상술한 바와 같은 본 개시의 실시예들에 따른, 제2 클러스터의 제2 EMS(element management system)가 수행하는 방법에 있어서, 상기 방법은, 초기화 컨테이너(initial container)를 로드함으로써, 상기 제2 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하는 과정과, 상기 제2 EMS의 상태를 식별하는 과정과, 상기 제2 EMS의 상태가 상기 대기 상태인 경우, 제1 클러스터의 제1 EMS로부터 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 수신하는 과정과, 상기 제1 EMS의 상태를 식별하는 과정과, 상기 제1 EMS의 상태가 대기 상태 또는 상기 제1 EMS가 실행되지 않는 이상 상태인 경우, 상기 파일 및 상기 데이터에 기반하여 상기 제2 EMS의 상태를, 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태로 변경하는 과정을 포함할 수 있다.
일 실시 예에서, 상기 제1 EMS의 상태를 식별하는 과정은, 상기 제1 EMS에게 상태를 확인하는 메시지를 전송하는 과정과, 상기 제1 EMS로부터 활성 상태 또는 대기 상태에 관한 정보를 포함하는, 상기 상태를 확인하는 메시지에 대한 응답 메시지를 수신하는 과정을 포함할 수 있다.
일 실시 예에서, 상기 제1 EMS의 상태를 식별하는 과정은, 상기 제1 EMS로부터 상기 응답 메시지가 수신되지 않는 경우, 상기 이상 상태로 판단하는 과정을 더 포함될 수 있다.
일 실시 예에서, 상기 이상 상태는, 파드 이상(failure), 워커 노드 고장(crash), 클러스터 고장(cluster crash), 저장소 고장(storage crash), 독립적인 서비스 또는 네트워크 이상(abnormal) 중에서 적어도 하나를 포함할 수 있다.
일 실시 예에서, 상기 파일은 상기 제2 EMS에 포함된 파일 복제 파드를 통해 수신되고, 상기 데이터는 상기 제2 EMS에 포함된 데이터베이스 파드를 통해 수신될 수 있다.
일 실시 예에서, 상기 파일 및 상기 데이터는 실시간으로 수신될 수 있다.
상술한 바와 같은 본 개시의 실시예들에 따른, 제1 클러스터의 제1 EMS(element management system)가 수행하는 방법에 있어서, 상기 방법은, 초기화 컨테이너(initial container)를 로드함으로써, 상기 제1 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하는 과정과, 상기 제1 EMS의 상태를 식별하는 과정과, 상기 제1 EMS의 상태가 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태인 경우, 제2 클러스터의 제2 EMS에게 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 전송하는 과정을 포함할 수 있다.
일 실시 예에서, 상기 파일은 상기 제1 EMS에 포함된 파일 복제 파드를 통해 전송되고, 상기 데이터는 상기 제1 EMS에 포함된 데이터베이스 파드를 통해 전송될 수 있다.
일 실시 예에서, 상기 파일 및 상기 데이터는 실시간으로 전송될 수 있다.
일 실시 예에서, 상기 제2 EMS로부터 상태를 확인하는 메시지를 수신하는 과정과, 상기 제2 EMS에게 상기 활성 상태임을 알리는 메시지를 전송하는 과정을 더 포함할 수 있다.
상술한 바와 같은 본 개시의 실시예들에 따른, 제2 클러스터의 제2 EMS(element management system)에 있어서, 상기 제2 EMS는, 송수신기(transceiver)와, 상기 송수신기와 연결되는(coupled) 적어도 하나의 프로세서를 포함하고, 상기 적어도 하나의 프로세서는, 초기화 컨테이너(initial container)를 로드함으로써 상기 제2 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하고, 상기 제2 EMS의 상태를 식별하고, 상기 제2 EMS의 상태가 상기 대기 상태인 경우, 제1 클러스터의 제1 EMS로부터 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 수신하고, 상기 제1 EMS의 상태를 식별하고, 상기 제1 EMS의 상태가 대기 상태 또는 상기 제1 EMS가 실행되지 않는 이상 상태인 경우, 상기 파일 및 상기 데이터에 기반하여 상기 제2 EMS의 상태를, 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태로 변경하도록 구성될 수 있다.
상술한 바와 같은 본 개시의 실시예들에 따른, 제1 클러스터의 제1 EMS(element management system)에 있어서, 상기 제1 EMS는, 송수신기와, 상기 송수신기와 연결되는(coupled) 적어도 하나의 프로세서를 포함하고, 상기 적어도 하나의 프로세서는, 초기화 컨테이너(initial container)를 로드함으로써, 상기 제1 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드를 실행하고, 상기 제1 EMS의 상태를 식별하고, 상기 제1 EMS의 상태가 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태인 경우, 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 전송하도록 설정될 수 있다.
본 문서에 개시된 다양한 실시 예들에 따른 전자 장치는 다양한 형태의 장치가 될 수 있다. 전자 장치는, 예를 들면, 휴대용 통신 장치(예: 스마트폰), 컴퓨터 장치, 휴대용 멀티미디어 장치, 휴대용 의료 장치, 카메라, 웨어러블 장치, 또는 가전 장치를 포함할 수 있다. 본 문서의 실시 예에 따른 전자 장치는 전술한 장치들에 한정되지 않는다.
본 문서의 다양한 실시 예들 및 이에 사용된 용어들은 본 문서에 기재된 기술적 특징들을 특정한 실시 예들로 한정하려는 것이 아니며, 해당 실시 예의 다양한 변경, 균등물, 또는 대체물을 포함하는 것으로 이해되어야 한다. 도면의 설명과 관련하여, 유사한 또는 관련된 구성요소에 대해서는 유사한 참조 부호가 사용될 수 있다. 아이템에 대응하는 명사의 단수 형은 관련된 문맥상 명백하게 다르게 지시하지 않는 한, 아이템 한 개 또는 복수 개를 포함할 수 있다. 본 문서에서, "A 또는 B", "A 및 B 중 적어도 하나","A 또는 B 중 적어도 하나,""A, B 또는 C," "A, B 및 C 중 적어도 하나,"및 "A, B, 또는 C 중 적어도 하나"와 같은 문구들 각각은 그 문구들 중 해당하는 문구에 함께 나열된 항목들 중 어느 하나, 또는 그들의 모든 가능한 조합을 포함할 수 있다. "제1", "제2", 또는 "첫째" 또는 "둘째"와 같은 용어들은 단순히 해당 구성요소를 다른 해당 구성요소와 구분하기 위해 사용될 수 있으며, 해당 구성요소들을 다른 측면(예: 중요성 또는 순서)에서 한정하지 않는다. 어떤(예: 제1) 구성요소가 다른(예: 제2) 구성요소에, "기능적으로" 또는 "통신적으로"라는 용어와 함께 또는 이런 용어 없이, "커플드" 또는 "커넥티드"라고 언급된 경우, 그것은 어떤 구성요소가 다른 구성요소에 직접적으로(예: 유선으로), 무선으로, 또는 제3 구성요소를 통하여 연결될 수 있다는 것을 의미한다.
본 문서에서 사용된 용어 "모듈"은 하드웨어, 소프트웨어 또는 펌웨어로 구현된 유닛을 포함할 수 있으며, 예를 들면, 로직, 논리 블록, 부품, 또는 회로 등의 용어와 상호 호환적으로 사용될 수 있다. 모듈은, 일체로 구성된 부품 또는 하나 또는 그 이상의 기능을 수행하는, 부품의 최소 단위 또는 그 일부가 될 수 있다. 예를 들면, 일 실시 예에 따르면, 모듈은 ASIC(application-specific integrated circuit)의 형태로 구현될 수 있다.
본 문서의 다양한 실시 예들은 장치(machine)(예: 전자 장치) 의해 읽을 수 있는 저장 매체(storage medium)(예: 내장 메모리 또는 외장 메모리)에 저장된 하나 이상의 명령어들을 포함하는 소프트웨어(예: 프로그램)로서 구현될 수 있다. 예를 들면, 장치(예: 전자 장치)의 프로세서(예: 프로세서)는, 저장 매체로부터 저장된 하나 이상의 명령어들 중 적어도 하나의 명령을 호출하고, 그것을 실행할 수 있다. 이것은 장치가 호출된 적어도 하나의 명령어에 따라 적어도 하나의 기능을 수행하도록 운영되는 것을 가능하게 한다. 하나 이상의 명령어들은 컴파일러에 의해 생성된 코드 또는 인터프리터에 의해 실행될 수 있는 코드를 포함할 수 있다. 장치로 읽을 수 있는 저장매체는, 비일시적(non-transitory) 저장매체의 형태로 제공될 수 있다. 여기서, '비일시적'은 저장매체가 실재(tangible)하는 장치이고, 신호(signal)(예: EM파)를 포함하지 않는다는 것을 의미할 뿐이며, 이 용어는 데이터가 저장매체에 반영구적으로 저장되는 경우와 임시적으로 저장되는 경우를 구분하지 않는다.
일 실시 예에 따르면, 본 문서에 개시된 다양한 실시 예들에 따른 방법은 컴퓨터 프로그램 제품(computer program product)에 포함되어 제공될 수 있다. 컴퓨터 프로그램 제품은 상품으로서 판매자 및 구매자 간에 거래될 수 있다. 컴퓨터 프로그램 제품은 장치로 읽을 수 있는 저장 매체(예: CD-ROM(compact disc read only memory))의 형태로 배포되거나, 또는 어플리케이션 스토어(예: 플레이 스토어TM)를 통해 또는 두개의 사용자 장치들(예: 스마트폰들) 간에 직접, 온라인으로 배포(예: 다운로드 또는 업로드)될 수 있다. 온라인 배포의 경우에, 컴퓨터 프로그램 제품의 적어도 일부는 제조사의 서버, 어플리케이션 스토어의 서버, 또는 중계 서버의 메모리와 같은 장치로 읽을 수 있는 저장 매체에 적어도 일시 저장되거나, 임시적으로 생성될 수 있다.
다양한 실시 예들에 따르면, 기술한 구성요소들의 각각의 구성요소(예: 모듈 또는 프로그램)는 단수 또는 복수의 개체를 포함할 수 있다. 다양한 실시 예들에 따르면, 전술한 해당 구성요소들 중 하나 이상의 구성요소들 또는 동작들이 생략되거나, 또는 하나 이상의 다른 구성요소들 또는 동작들이 추가될 수 있다. 대체적으로 또는 추가적으로, 복수의 구성요소들(예: 모듈 또는 프로그램)은 하나의 구성요소로 통합될 수 있다. 이런 경우, 통합된 구성요소는 복수의 구성요소들 각각의 구성요소의 하나 이상의 기능들을 통합 이전에 복수의 구성요소들 중 해당 구성요소에 의해 수행되는 것과 동일 또는 유사하게 수행할 수 있다. 다양한 실시 예들에 따르면, 모듈, 프로그램 또는 다른 구성요소에 의해 수행되는 동작들은 순차적으로, 병렬적으로, 반복적으로, 또는 휴리스틱하게 실행되거나, 동작들 중 하나 이상이 다른 순서로 실행되거나, 생략되거나, 또는 하나 이상의 다른 동작들이 추가될 수 있다.

Claims (15)

  1. 제2 클러스터의 제2 EMS(element management system)가 수행하는 방법에 있어서,
    초기화 컨테이너(initial container)를 로드함으로써, 상기 제2 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하는 과정과,
    상기 제2 EMS의 상태를 식별하는 과정과,
    상기 제2 EMS의 상태가 상기 대기 상태인 경우, 제1 클러스터의 제1 EMS로부터 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 수신하는 과정과,
    상기 제1 EMS의 상태를 식별하는 과정과,
    상기 제1 EMS의 상태가 대기 상태 또는 상기 제1 EMS가 실행되지 않는 이상 상태인 경우, 상기 파일 및 상기 데이터에 기반하여 상기 제2 EMS의 상태를, 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태로 변경하는 과정을 포함하는 방법.
  2. 제1항에 있어서,
    상기 제1 EMS의 상태를 식별하는 과정은,
    상기 제1 EMS에게 상태를 확인하는 메시지를 전송하는 과정과,
    상기 제1 EMS로부터 활성 상태 또는 대기 상태에 관한 정보를 포함하는, 상기 상태를 확인하는 메시지에 대한 응답 메시지를 수신하는 과정을 포함하는 방법.
  3. 제2항에 있어서,
    상기 제1 EMS의 상태를 식별하는 과정은,
    상기 제1 EMS로부터 상기 응답 메시지가 수신되지 않는 경우, 상기 이상 상태로 판단하는 과정을 더 포함하는 방법.
  4. 제1항에 있어서,
    상기 이상 상태는,
    파드 이상(failure), 워커 노드 고장(crash), 클러스터 고장(cluster crash), 저장소 고장(storage crash), 독립적인 서비스 또는 네트워크 이상(abnormal) 중에서 적어도 하나를 포함하는 방법.
  5. 제1항에 있어서,
    상기 파일은,
    상기 제2 EMS에 포함된 파일 복제 파드를 통해 수신되고,
    상기 데이터는,
    상기 제2 EMS에 포함된 데이터베이스 파드를 통해 수신되는 방법.
  6. 제1항에 있어서,
    상기 파일 및 상기 데이터는 실시간으로 수신되는 방법.
  7. 제1 클러스터의 제1 EMS(element management system)가 수행하는 방법에 있어서,
    초기화 컨테이너(initial container)를 로드함으로써, 상기 제1 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하는 과정과,
    상기 제1 EMS의 상태를 식별하는 과정과,
    상기 제1 EMS의 상태가 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태인 경우, 제2 클러스터의 제2 EMS에게 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 전송하는 과정을 포함하는 방법.
  8. 제7항에 있어서,
    상기 파일은,
    상기 제1 EMS에 포함된 파일 복제 파드를 통해 전송되고,
    상기 데이터는,
    상기 제1 EMS에 포함된 데이터베이스 파드를 통해 전송되는 방법.
  9. 제7항에 있어서,
    상기 파일 및 상기 데이터는 실시간으로 전송되는 방법.
  10. 제7항에 있어서,
    상기 제2 EMS로부터 상태를 확인하는 메시지를 수신하는 과정과,
    상기 제2 EMS에게 상기 활성 상태임을 알리는 메시지를 전송하는 과정을 더 포함하는 방법.
  11. 제2 클러스터의 제2 EMS(element management system)에 있어서,
    송수신기(transceiver)와,
    상기 송수신기와 연결되는(coupled) 적어도 하나의 프로세서를 포함하고,
    상기 적어도 하나의 프로세서는,
    초기화 컨테이너(initial container)를 로드함으로써 상기 제2 EMS에 포함되는 실행 중이나 서비스는 되지 않는 대기 상태의 서비스 파드(pod)를 실행하고,
    상기 제2 EMS의 상태를 식별하고,
    상기 제2 EMS의 상태가 상기 대기 상태인 경우, 제1 클러스터의 제1 EMS로부터 상기 제1 클러스터에 저장된 파일 및 상기 제1 EMS가 실행 중인 애플리케이션과 관련된 데이터를 수신하고,
    상기 제1 EMS의 상태를 식별하고,
    상기 제1 EMS의 상태가 대기 상태 또는 상기 제1 EMS가 실행되지 않는 이상 상태인 경우, 상기 파일 및 상기 데이터에 기반하여 상기 제2 EMS의 상태를, 상기 서비스 파드가 실행 중이고 서비스가 되는 활성 상태로 변경하도록 구성되는 제2 EMS.
  12. 제11항에 있어서,
    상기 적어도 하나의 프로세서는,
    상기 제1 EMS에게 상태를 확인하는 메시지를 전송하고,
    상기 제1 EMS로부터 활성 상태 또는 대기 상태에 관한 정보를 포함하는, 상기 상태를 확인하는 메시지에 대한 응답 메시지를 수신하고,
    상기 제1 EMS로부터 상기 응답 메시지가 수신되지 않는 경우, 상기 이상 상태로 판단하도록 구성되는 제2 EMS.
  13. 제11항에 있어서,
    상기 이상 상태는, 파드 이상(failure), 워커 노드 고장(crash), 클러스터 고장(cluster level crash), 저장소 고장(storage crash) 중에서 적어도 하나를 포함하는 제2 EMS.
  14. 제11항에 있어서,
    상기 파일은,
    상기 제2 EMS에 포함된 파일 복제 파드를 통해 수신되고,
    상기 데이터는,
    상기 제2 EMS에 포함된 데이터베이스 파드를 통해 수신되는 제2 EMS.
  15. 제11항에 있어서,
    상기 파일 및 상기 데이터는 실시간으로 수신되는 제2 EMS.
PCT/KR2023/008494 2022-06-20 2023-06-20 컨테이너 기반 다중 클러스터 환경에서 데이터 동기화를 위한 방법 및 장치 WO2023249361A1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2022-0074915 2022-06-20
KR20220074915 2022-06-20
KR1020220144437A KR20230174137A (ko) 2022-06-20 2022-11-02 컨테이너 기반 다중 클러스터 환경에서 데이터 동기화를 위한 방법 및 장치
KR10-2022-0144437 2022-11-02

Publications (1)

Publication Number Publication Date
WO2023249361A1 true WO2023249361A1 (ko) 2023-12-28

Family

ID=89377930

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/008494 WO2023249361A1 (ko) 2022-06-20 2023-06-20 컨테이너 기반 다중 클러스터 환경에서 데이터 동기화를 위한 방법 및 장치

Country Status (2)

Country Link
KR (1) KR20230174137A (ko)
WO (1) WO2023249361A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130038517A (ko) * 2011-10-10 2013-04-18 엔에이치엔비즈니스플랫폼 주식회사 분산된 컨테이너들을 사용하여 데이터를 관리하는 시스템 및 방법
KR20150029181A (ko) * 2013-09-09 2015-03-18 삼성에스디에스 주식회사 클러스터 시스템 및 클러스터 시스템에서 서비스 가용성을 제공하기 위한 방법
JP2020536319A (ja) * 2017-09-30 2020-12-10 オラクル・インターナショナル・コーポレイション コンテナのグループの動的マイグレーション
KR20210031829A (ko) * 2019-09-13 2021-03-23 구글 엘엘씨 컨테이너화된 환경에서 클러스터의 라이브 마이그레이션
KR20210127761A (ko) * 2019-04-01 2021-10-22 구글 엘엘씨 멀티 클러스터 인그레스

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130038517A (ko) * 2011-10-10 2013-04-18 엔에이치엔비즈니스플랫폼 주식회사 분산된 컨테이너들을 사용하여 데이터를 관리하는 시스템 및 방법
KR20150029181A (ko) * 2013-09-09 2015-03-18 삼성에스디에스 주식회사 클러스터 시스템 및 클러스터 시스템에서 서비스 가용성을 제공하기 위한 방법
JP2020536319A (ja) * 2017-09-30 2020-12-10 オラクル・インターナショナル・コーポレイション コンテナのグループの動的マイグレーション
KR20210127761A (ko) * 2019-04-01 2021-10-22 구글 엘엘씨 멀티 클러스터 인그레스
KR20210031829A (ko) * 2019-09-13 2021-03-23 구글 엘엘씨 컨테이너화된 환경에서 클러스터의 라이브 마이그레이션

Also Published As

Publication number Publication date
KR20230174137A (ko) 2023-12-27

Similar Documents

Publication Publication Date Title
WO2020017843A1 (ko) 클라우드 플랫폼에서의 클러스터 리소스 할당 및 관리 방법
EP3189647B1 (en) Apparatus and method for on-process migration of industrial control and automation system across disparate network types
US9992058B2 (en) Redundant storage solution
JP2019075691A (ja) ミラーパケット制御プログラム、ミラーパケット制御方法、およびミラーパケット制御装置
WO2019189963A1 (ko) 분산 클러스터 관리 시스템 및 그 방법
WO2020233073A1 (zh) 区块链环境检测方法、设备、装置及存储介质
WO2019039851A1 (ko) Usb 인터페이스를 통해 외부 장치와 연결하는 방법 및 그를 위한 전자 장치
JP6299640B2 (ja) 通信装置
WO2018120680A1 (zh) 虚拟磁盘备份系统、方法、装置、服务主机和存储介质
WO2021125502A1 (ko) 컨테이너 기반의 클라우드 서비스 제공 시스템 및 그 방법
WO2017052061A1 (ko) Gpos 연동형 실시간 로봇 제어 시스템 및 이를 이용한 실시간 디바이스 제어 시스템
WO2023249361A1 (ko) 컨테이너 기반 다중 클러스터 환경에서 데이터 동기화를 위한 방법 및 장치
WO2019190095A1 (ko) 네트워크 기능 가상화 환경에서 네트워크 자원 관리를 위한 장치 및 방법
WO2019088721A1 (ko) 오픈형 생중계 플랫폼
WO2019208870A1 (ko) 무선 네트워크를 통해 프로그램을 업데이트하는 무선기기 및 무선시스템
WO2020180072A1 (ko) 엣지 컴퓨팅 환경에서 어플리케이션 재배치를 제어하기 위한 장치 및 방법
WO2020171472A1 (en) Electronic device and control method thereof
WO2024096440A1 (ko) 컨테이너 기반 다중 클러스터 환경에서 서비스의 가중치 기반 고 가용성 제어 방법 및 장치
WO2023214855A1 (ko) 컨테이너 기반 다중 클러스터 환경에서 컨테이너 애플리케이션를 제어하기 위한 방법 및 장치
WO2023022321A1 (ko) 분산 학습용 서버 및 분산 학습 방법
WO2022108274A1 (ko) Bms 관리 장치 및 방법
WO2022139101A1 (ko) 사물 인터넷 장치, 사물 인터넷 장치 관리 시스템 및 사물 인터넷 장치를 관리하는 방법
WO2011145896A2 (ko) 코디네이터 결정 방법 및 장치
EP3961402B1 (en) Fault-tolerant system, server, fault-tolerant system operation method, server operation method, and program for server operation method
WO2024090901A1 (ko) 가상 노드를 이용한 노드 관리 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23827476

Country of ref document: EP

Kind code of ref document: A1