KR20150102591A - High Availability System - Google Patents

Abstract

Disclosed are a high availability system and an operation method of a message broker in a high availability system. The high availability system of the present invention comprises: a plurality of clients in which a plurality of nodes communicate by publication - subscription messaging, which are respectively positioned in nodes different from each other among the nodes, and which includes an active client for periodically publishing a state message and a standby client; a server positioned in one among the nodes to detect an error of the active client based on state information on the clients, and publishing a fail-over message to the standby client; and a message broker for transferring a message published by the server to the clients, and transferring a message published by the clients to the server.

Description

{High Availability System}

An embodiment of the present invention relates to a high availability system and a method of operating a message broker in a high availability system.

HA (High Availability) is a function that supports non-disruptive services by grouping a plurality of devices and duplicating them. In general, a network device providing a service can support a non-stop service by building a high availability (HA) system by grouping a plurality of devices and duplicating them.

Korean Patent Registration No. 10-0693663

The present invention provides a high-availability system in which a network portion or a connection is not increased due to status monitoring even when a client is increased.

A high availability system according to an embodiment of the present invention includes a plurality of nodes communicating by publish-subscribe messaging, each of the plurality of nodes being located at a different node, an active client periodically issuing a status message, A plurality of clients including a client; A server located in one of the plurality of nodes for detecting a failure of the active client based on state information of the plurality of clients and issuing a failover message to the standby client; And a message broker for delivering a message issued by the server to the plurality of clients and for delivering a message issued by the plurality of clients to the server.

The active client can transmit a drive file necessary for driving to the message broker.

The message broker may forward the activation file of the active client to the standby client.

The standby client can execute the service of the active client by executing the drive file.

The active client may issue a failure recovery message when the failure is restored, receive a drive start message issued by the server from the message broker, and resume service.

The standby client may receive a stop message issued by the server from the message broker and stop the service.

The message broker may forward the registration request message issued by the active client and the standby client to the server.

The message broker may forward the registration completion message issued by the server to the active client and the standby client.

The active client and the standby client may each be provided in at least one node.

The server and one of the active client and the standby client may be located at the same node.

A method of operating a message broker in a high availability system in which a plurality of nodes communicate by publish-subscribe messaging according to an embodiment of the present invention includes the steps of: Receiving a status message to be issued; Transmitting the status message to a server located in one of the plurality of nodes and detecting a failure of the active client based on status information of the active client and the standby client; Receiving from the server a failover message to the standby client issued by the server in response to a failure of the active client; And forwarding the failover message to the active client and the standby client.

The method may further include receiving a drive file necessary for driving from the active client.

The method may further include transmitting the activation file of the active client to the standby client to perform a failover.

The method may further include delivering a failure recovery message issued by the active client after the failure recovery to the server.

The method may further include transmitting a drive start message issued by the server to the fail-over active client.

The method may further include transmitting a stop message issued by the server to the standby client.

The method may further include transmitting a registration request message issued by the active client and the standby client to the server.

The method may further include transmitting a registration completion message issued by the server to the active client and the standby client.

At least one of the active client and the standby client may be provided.

The high availability system according to the embodiment of the present invention can monitor the status without increasing the network load even when the number of clients increases. Also, the high availability system according to the embodiment of the present invention can be operated without changing the server even when a client is added or deleted.

1 is a block diagram that schematically illustrates a high availability system in accordance with an embodiment of the present invention.
2 is a block diagram schematically illustrating a method of operating a server for a high availability service according to an embodiment of the present invention.
3 is a block diagram schematically illustrating a method of operating a message broker for a high availability service according to an embodiment of the present invention.
4 is a flow diagram schematically illustrating a message flow in a high availability system according to an embodiment of the present invention.
5 illustrates an example of a network environment to which a high-availability system according to an embodiment of the present invention is applied.

The following merely illustrates the principles of the invention. Thus, those skilled in the art will be able to devise various apparatuses which, although not explicitly described or shown herein, embody the principles of the invention and are included in the concept and scope of the invention. Furthermore, all of the conditional terms and embodiments listed herein are, in principle, intended only for the purpose of enabling understanding of the concepts of the present invention, and are not intended to be limiting in any way to the specifically listed embodiments and conditions . It is also to be understood that the detailed description, as well as the principles, aspects and embodiments of the invention, as well as specific embodiments thereof, are intended to cover structural and functional equivalents thereof. It is also to be understood that such equivalents include all elements contemplated to perform the same function irrespective of currently known equivalents as well as equivalents to be developed in the future.

Thus, the functions of the various elements shown in the drawings, including the functional blocks shown in the figures or similar concepts, may be provided by use of dedicated hardware as well as hardware capable of executing software in connection with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, a single shared processor, or a plurality of individual processors, some of which may be shared. Also, the use of terms such as processor, control, or similar concepts should not be construed as exclusive reference to hardware capable of executing software, but may include, without limitation, digital signal processor (DSP) hardware, (ROM), random access memory (RAM), and non-volatile memory. Other hardware may also be included.

The above objects, features and advantages will become more apparent from the following detailed description in conjunction with the accompanying drawings. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

On the other hand, when an element is referred to as "including " an element, it does not exclude other elements unless specifically stated to the contrary.

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

1 is a block diagram that schematically illustrates a high availability system in accordance with an embodiment of the present invention.

Referring to FIG. 1, the high availability system 100 according to the present embodiment continually checks the operation status of each node in order to respond to a service request of an external user, and determines whether a problem occurs in a service in operation, It is checked whether a problem has occurred in the node, and if a problem occurs, the service right requested to another node is switched so that the service can be continuously performed.

The high availability system 100 may be a system in which nodes acting as servers and clients form a network. The server and the client can generate and send various types of messages, send and receive them wired or wirelessly, and process and store messages. To this end, the server and the client may comprise, for example, at least one processor, at least one memory, at least one power supply, at least one network interface, at least one operating system (OS)

The high availability system 100 according to the present embodiment includes a server 10, a plurality of first to nth active clients 30: 30_1, 30_2, ..., 30_n, First to m-th standby clients 50: 50_1, ..., 50_m, and a message broker 70. [

Each of the server 10, the first to nth active clients 30 (30_1, 30_2, ..., 30_n), the first to mth standby clients 50_1 to 50_m, and the message broker 70 And may be located in at least one node.

The server 10, the first to nth active clients 30_1 to 30_n and the first to mth standby clients 50_1 and 50_m function as a publisher and a subscriber You can do it all.

Publishers and subscribers can communicate with each other using messages of a particular type or a specific category, and channels can be formed during this process.

For example, when the server 10 issues a message and the first to nth active clients 30_1, 30_2, ..., 30_n and the first to mth standby clients 50_1, 50_m subscribe to the message The first to the n-th active clients 30_1 to 30_n and the first to m-th standby clients 50_1 and 50_m issue a message and a channel for the server 10 to subscribe to the message is formed . Communications between the publisher and the subscriber may be made via the message broker 70. Accordingly, the server 10 can communicate with a plurality of clients by a pair of channels, and it is not necessary to form a channel for communication for each client.

The publisher sends a message to the message broker 70, and the subscriber registers (subscribes) the subscription to the message broker 70 to receive the message.

A message published by the publisher is sent to all subscribed subscribers, and multiple publishers may be located on the same channel at the same time.

The message may include message type information and destination information. The message type information includes a network registration request message (REGISTER_ACTIVE / REGISTER_PASSIVE), a message indicating status information (HEARTBEAT_ACTIVE / HEARTBEAT_PASSIVE), a failover execution message (DO_FAILOVER), a failover interruption message DO_STANDBY, a termination message (FORCE_QUIT) . The destination information may include the last subscriber information of the published message. For example, the destination information may be a client to receive a message, a client to perform a failover, and the like.

The first through the nth active clients 30_1 through 30_n and the first through mth standby clients 50_1 through 50_m receive messages based on the destination information, And can execute the corresponding command according to the message type.

The server 10 manages the clients 30 and 50 and monitors the status of the active client 30 through a message broker using publish / subscribe messaging, (50) sends the command to drive the same function.

The server 10 can provide normal high-availability services by detecting changes in the status of clients, such as addition, removal, failure, fail-over, etc. of the clients 30 and 50. The server 10 may have information on an identifier (ID), status information, priority, service type, etc. of the clients 30 and 50 subscribed to the channel.

The server 10 may receive the registration request messages of the first to nth active clients 30_1 to 30_n and the first to mth standby clients 50_1 to 50_m. The registration request message may include identifier information (ID) of the client. The identifier information may be the IP address of the node where the client is located. The server 10 may add the first to nth active clients 30_1, 30_2, ..., 30_n that have requested registration to the active client list. In addition, the server 10 may add the first through m-th standby clients 50_1, ..., 50_m requested to be registered to the standby client list.

The server 10 registers the first to n-th active clients 30_1, 30_2, ..., and 30_n added to the list and the registration requests of the first to m-th standby clients 50_1 to 50_m A registration completion message can be issued with feedback. Accordingly, the first to n-th active clients 30_1, 30_2, ..., 30_n and the first to m-th standby clients 50_1, ..., 50_m can be subscribed to the channel.

The server 10 starts a high availability (HA) service based on the information of the clients 30 and 50 subscribed to the channel, and the first to nth active clients 30_1, 30_2, ..., The first to m-th standby clients 50_1 to 50_m can be set to the active state (ACTIVE) or the standby state (STANDBY).

The server 10 transmits a status information message including status information of the first through n-th active clients 30_1, 30_2, ..., 30_n and the first through m-th standby clients 50_1, ..., .

The server 10 can detect the failure based on the status information of the first through n-th active clients 30_1, 30_2, ..., 30_n. The server 10 may determine that the active client 30 has failed if the status information message of the specific active client 30 is not received for a predetermined period or more.

The server 10 issues a fail-over message (FAILOVER) so that at least one of the first through m-th standby clients 50_1, ..., and 50_m performs the service of the active client 30, can do. Accordingly, even if a failure occurs in the active client 30, the standby client 50 can continuously perform the service.

When the server 10 receives the failure recovery message of the active client 30 from which the failure has been restored, the server 10 may issue a start-up message so that the failed active client 30 can resume the service. For example, the failback message may be a new registration request message issued by the failed active client 30. The drive start message may be a registration completion message issued by the server as a feedback for a new registration request message. The server 10 can update the failed active client 30 by adding it back to the active client list. Then, the server 10 may issue a drive stop message to stop the service of the standby client 50 that is performing the failover.

The first to nth active clients 30_1, 30_2, ..., 30_n may perform the same service or perform different services. The first to nth active clients 30_1, 30_2, ..., 30_n may issue a registration request message. The first to n-th active clients 30_1, 30_2, ..., 30_n may receive the registration completion message as a feedback of the registration request and start the corresponding service.

The first through n-th active clients 30_1, 30_2, ..., 30_n may periodically issue status information messages. The first to nth active clients 30_1, 30_2, ..., 30_n can stop the service if a failure occurs and issue a failure recovery message (i.e., a new registration request message) when the failure is restored. The first to nth active clients 30_1, 30_2, ..., 30_n may resume the suspended service upon receiving a drive start message (i.e., a registration completion message).

The first to m-th standby clients 50_1, ..., and 50_m may issue a registration request message in a standby state. The first to m-th standby clients 50_1, ..., and 50_m may receive the registration completion message as feedback for the registration request.

The first to m-th standby clients 50_1, ..., and 50_m may periodically issue status information messages. The first to m-th standby clients 50_1 to 50_m may receive a failover message and a drive file capable of performing a service performed by the failed active client 30, and may be switched to an active state . The first to m-th standby clients 50_1, ..., and 50_m can perform services on behalf of the failed active client 30. When the first to m-th standby clients 50_1, ..., and 50_m receive the drive stop message, they can stop the service being performed and return to the standby state again.

The message broker 70 is a module for transferring messages between the server 10 and the clients 30 and 50.

The message broker 70 receives a registration request message issued by the first through the n-th active clients 30_1, 30_2, ..., and 30_n and the first through m-th standby clients 50_1 through 50_m To the server 10.

The message broker 70 transmits the registration completion message issued by the server 10 to the first to nth active clients 30_1 to 30_n and the first to mth standby clients 50_1 to 50_n, 50_m, respectively.

The message broker 70 receives the status information messages issued by the first through the n-th active clients 30_1, 30_2, ..., and 30_n and the first through m-th standby clients 50_1 through 50_m To the server 10. The message broker 70 can receive and store the drive files necessary for service execution from the first to nth active clients 30_1, 30_2, ..., and 30_n through separate routes.

The message broker 70 receives the failover message issued by the server 10 and transmits the failover message to the first to nth active clients 30_1, 30_2, ..., 30_n and the first to mth standby clients 50_1, ..., and 50_m, respectively. Then, the message broker 70 can deliver the operation file of the failed active client 30 to the corresponding standby client 50 to be failed over.

The message broker 70 can receive the failback message (i.e., a new registration request message) issued by the failing active client 30 and deliver it to the server 10. The message broker 70 receives the drive start message (i.e., the registration completion message) and the drive stop message issued by the server 10 and stores the first to nth active clients 30_1, 30_2, ..., 30_n, 1 to m-th standby clients 50_1, ..., 50_m. Accordingly, the failed active client 30 returns to the active state to resume the service, and the standby client 50 that has performed the failover can stop the service and return to the standby state.

2 is a block diagram schematically illustrating a method of operating a server for a high availability service according to an embodiment of the present invention.

Referring to FIG. 2, a server periodically receives a status information message from at least one active client and at least one standby client through a message broker (S21).

The server can detect the failure of the active client based on the status information message of the active client (S23). The server can determine that the active client's status information is not received within a predetermined period of time.

If it is determined that the active client has failed, the server may issue a fail-over message requesting the standby client to fail (S25). The message broker can pass the failover message and the running file to the standby client.

When the server receives the failure recovery message from the active client through the message broker (S27), the server issues a drive start message for causing the failed active client to restart the service and a standby client in the fail-over to suspend the service (S29). Accordingly, the active client receiving the drive start message through the message broker is switched to the active state to restart the service, and the standby client receiving the drive stop message can switch to the standby state by stopping the service.

3 is a block diagram schematically illustrating a method of operating a message broker for a high availability service according to an embodiment of the present invention.

Referring to FIG. 3, the message broker periodically receives a status information message issued by at least one active client and at least one standby client, and transmits the status information message to the server (S31).

The message broker can receive the failover message issued by the server and forward it to the standby client (S33). The message broker can forward the running file of the failed active client to the standby client.

For example, a message broker delivers a failover message to a plurality of active clients and a plurality of standby clients, and a plurality of active clients and a plurality of standby clients, each of which receives a failover message, It is possible to confirm whether or not the message is its own based on the IP address. When the standby client of the IP address is confirmed by its own message, it can execute the received drive file and execute the failover command.

The message broker may receive the failback message issued by the active client and forward it to the server (S35).

The message broker may receive a start-up message that causes the fail-over active client issued by the server to resume the service, and a suspend message that the standby client is failing to stop the service, and may forward the message to the active client and the standby client at step S37. .

For example, the active client and the standby client can receive a driving start message and a driving stop message, check whether each message is a message of itself, and then execute an instruction of a corresponding message. The active client can confirm the start-up message with its own message and restart the service, and the standby client can confirm the start-stop message with its own message and stop the service.

4 is a flow diagram schematically illustrating a message flow in a high availability system according to an embodiment of the present invention.

Although only one active client 30 and one standby client 50 are shown in FIG. 4 for the sake of convenience, the present invention is equally applicable to a case where a plurality of active clients 30 and a plurality of standby clients 50 are provided. Of course. A message issued by the server 10 is delivered to a plurality of active clients 30 and a plurality of standby clients 50. A message issued by each active client 30 is delivered to the server 10, A message issued by the server 50 may be transmitted to the server 10. A plurality of active clients (30) and a plurality of standby clients (50) can identify whether a received message is a message of itself, and can execute an instruction according to a message type if the received message is its own message.

Referring to FIG. 4, a high availability system may operate in registration phase 1, state management phase 2, and failover phase 3.

In the registration step 1, the active client 30 issues a registration request message (S71), and the message broker 70 receives the registration request message and delivers it to the server 10 (S72). The server 10 may add the active client 30 to the active client list (S73). The server 10 issues a registration completion message (S74), and the message broker 70 can receive the registration completion message and deliver it to the active client 30 (S75).

Similarly, the standby client 50 issues a registration request message (S76), and the message broker 70 can receive the registration request message and deliver it to the server 10 (S77). The server 10 may add the standby client 50 to the standby client list (S78). The server 10 issues a registration completion message (S79), and the message broker 70 can receive the registration completion message and deliver it to the standby client 50 (S80).

In the state management step 2, the active client 30 and the standby client 50 can periodically publish a status information message informing their own status information (S81, S82). The active client 30 and the standby client 50 may publish status information messages at the same time or at different times, respectively. The message broker 70 can receive the status information message and deliver it to the server 10 at the same time or at another time (S83). The server 10 can check the status of the active client 30 and the standby client 50 based on the status information message and update the status information (S84).

In the failover step (3), the active client (30) transfers the drive file necessary for performing its service to the message broker (70) and can back it up (S91). In the embodiment of FIG. 4, the drive file backup S91 is performed in the failover step 3, but the present invention is not limited to this and may be performed in the registration step 1 or the state management step 2. If the status information message of the active client 30 is not received for a certain period of time, the server 10 determines that the active client 30 is a failure (S92) and can issue a fail-over message (S93). The message broker 70 may receive the failover message and forward it to the standby client 50 to perform failover in step S95 and may also forward the backup file of the active client 30 to the standby client 50 (S94).

5 illustrates an example of a network environment to which a high-availability system according to an embodiment of the present invention is applied.

In the data processing network 1000 shown in FIG. 5, the plurality of devices 1010 can communicate with the monitoring server 1080 through the first network 1020 and the second network 1070. The plurality of devices 1010 may include a camera, a mobile terminal, a computing device, and the like. The first network 1020 and the second network 1070 may be wired or wireless networks. Also, the first network 1020 and the second network 1070 may be local or remote networks.

A gateway 1050 or a media server is connected to the first network 1020 and the second network 1070 through a communication link and is connected to the first network 1020 and the second network 1070 As a point of entry. Since the gateway 1050 is a gateway device for communication, it may be a single point of failure where all the networks are paralyzed in the event of a failure.

Thus, for a persistent network environment, the high availability system of the present invention can be applied to the gateway 1050 to enable continuous service of the gateway 1050. [ For example, an active client may be implemented in the gateway 1050, and the gateway 1050 may form a network with the node on which the standby client, message broker, and server are implemented. As another example, a server and an active client may be implemented together in the gateway 1050, and a standby client and a message broker may form a network with the implemented node.

The high availability system according to the present embodiment can continuously provide a normal service regardless of any defects occurring in system resources such as hardware, software, or a network. That is, the high-availability system according to the present embodiment can enhance the security of the service in providing the service directly to the target user through the network.

The embodiments of the present invention can be applied not only to a high availability system but also to a system in which clustering must be provided and node management in a cloud computing environment.

The method of operating the high-availability system according to the present invention can be implemented as a computer-readable code on a computer-readable recording medium. A computer-readable recording medium includes all kinds of recording apparatuses in which data that can be read by a computer system is stored. Examples of the computer-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like. In addition, the computer-readable recording medium may be distributed over network-connected computer systems so that computer readable codes can be stored and executed in a distributed manner. In addition, functional programs, codes, and code segments for implementing the present invention can be easily inferred by programmers of the technical field to which the present invention belongs.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is clearly understood that the same is by way of illustration and example only and is not to be taken by way of limitation, You will understand. Accordingly, the true scope of protection of the present invention should be determined only by the appended claims.

100: High availability system
10: Server
30: Active Client
50: Standby client
70: Message Broker

Claims (10)

In a high availability system in which a plurality of nodes communicate by publish-subscribe messaging,
A plurality of clients located at different ones of the plurality of nodes and each including an active client and a standby client that periodically issue status messages;
A server located in one of the plurality of nodes for detecting a failure of the active client based on state information of the plurality of clients and issuing a failover message to the standby client; And
And a message broker for delivering a message issued by the server to the plurality of clients and for delivering a message issued by the plurality of clients to the server. The method according to claim 1,
Wherein the active client sends to the message broker a drive file necessary for driving. 3. The method of claim 2,
Wherein the message broker delivers the activation file of the active client to the standby client. The method of claim 3,
And the standby client performs the service of the active client by executing the drive file. The method according to claim 1,
Wherein the active client issues a failback message when the failure is restored and receives a drive start message issued by the server from the message broker to resume service. 6. The method of claim 5,
Wherein the standby client receives from the message broker a drive stop message issued by the server and stops the service. The method according to claim 1,
Wherein the message broker delivers a registration request message issued by the active client and the standby client to the server. 8. The method of claim 7,
Wherein the message broker delivers a registration completion message issued by the server to the active client and the standby client. The method according to claim 1,
Wherein the active client and the standby client are each provided at at least one node. The method according to claim 1,
Wherein the server and one of the active client and the standby client are located at the same node.

Images