ES2700535A1 - DISTRIBUTED NETWORK AND METHOD OF MANAGEMENT OF THE SAME (Machine-translation by Google Translate, not legally binding) - Google Patents

Abstract

Distributed network and method of management of it. In this document two aspects of the same inventive object are detailed, in a first aspect we have a distributed network that includes in its implementation a specific component that is a registration component (called "Discovery") that is responsible for keeping a record of all the components that appear in the application, and that are part of the communication model proposed by the design of the invention. The method used to save that record depends on the technical implementation of the design of the invention, therefore in a second aspect of the invention there is a distributed network management method that implements said registration component, a method that details the use of two communication channels for respective types of messages that are transmitted between the components of the network. (Machine-translation by Google Translate, not legally binding)

Description

DISTRIBUTED NETWORK AND METHOD OF MANAGEMENT OF THE SAME

D E S C R I P C I O N

OBJECT OF THE INVENTION

The object of the invention is part of the technical field of information technology and communications.

More specifically, the object of the invention is directed to communication networks of the so-called distributed networks.

BACKGROUND OF THE INVENTION

A distributed network is a communications network topology in which the nodes are linked to each other so that none of them, not even a stable group of them, has filter power over the information transmitted on the network. Therefore, the dividing line between center and periphery characteristic of centralized and decentralized networks disappears, so that all the nodes are connected to each other without necessarily having to pass through one or several centers.

In the distributed networks the center / periphery division disappears and therefore the filter power over the information that flows through it, likewise a distributed network is robust before the fall of nodes: no node to be extracted generates the disconnection of another.

The operation of a network can and should be monitored, said monitoring can be done remotely so that a series of checks are carried out through the network to obtain information; Normally standard network protocols are used such as ICMP, SNMP, TCP / UDP, HTTP, etc. Generally, the checks are executed from a centralized monitoring server and report information immediately, communications are usually initiated by the monitoring server itself. Through these checks you can perform a series of checks related to, for example, checking if a computer is up ("Host Alive" in English), latency of communications with a specific computer ("Host Latency" in English), check if a service is raised by monitoring the state of a specific port (for example, through HTTP service using port 80), network traffic (preferably through SNMP).

Another way to monitor is one that uses agents, that is, through a light software that remains in execution in operating systems, permanently collecting data from the operating system in which it is installed. Normally you can access levels of information deeper than through network checks, in addition to being able to monitor "from within" the applications that are on the server, in this type of monitoring communications are usually initiated by the agents themselves, but can also It is usually initiated by the server, through agent monitoring, information is usually obtained regarding: CPU usage, memory usage, storage system capacity, number of running processes, services raised as well as internal application monitoring data.

In this sense we have the document US9112894B2, which describes a network platform distributed in real time as well as security monitoring to monitor a link between a distributed sub-network and the Internet, it presents a central server for coordination and supervision locally accessible by various distributed supervision elements. The platform described allows integrating any new service that can be connected or existing on the platform without the need for reconstruction through the extension points, thus ensuring flexibility of use and allowing the addition of new functions or services. The platform allows buffering to direct high-speed network traffic without loss of packets and reducing the necessary processing resources.

US20140337453A1 details a method that involves determining whether a request (SNMP) of the Simple Network Management Protocol requires the involvement of a given device to satisfy the SNMP request or whether the SNMP request does not require the involvement of the device to satisfy the SNMP request by part of a primary device to determine that the SNMP request belongs to the user's device. A non-SNMP request corresponding to the SNMP request is generated and transmitted from the main device to the user's device to determine that the SNMP request requires the involvement of the user's device to satisfy the SNMP request.

In US7415038B2 a method for managing the use of bandwidth for a data processing system in distributed networks is described, the disclosed method involves predicting the use of bandwidth in response to a request within the data processing system.

It is detailed how a network management framework is able to monitor multiple sources of network packets in several subnets within the distributed data processing system; as well as the use of distributed snoopers from the packet usage manager that are deployed to monitor the multiple sources of network packets. The system administrator can request packet filtering based on selected active users or active applications. A bandwidth history database is generated from bandwidth usage data associated with multiple entities within the data processing system, including users, applications and / or endpoints within the data processing system . In response to a requested action within the data processing system, the use of bandwidth for the requested action can be predicted with reference to the history bandwidth database. The actual and expected use of the bandwidth of the requested actions can be shown to the system administrator in real time.

Therefore, it would be necessary to be able to carry out fragmentation in independent groups and distribute these through multiple servers, in addition to maintaining an efficient communication between them. In addition, by distributing an application through several servers, challenges are introduced that do not exist with an application that resides entirely in a single server, such as failures in the communication network, error control, packet loss or corruption of content in the transmission of data.

DESCRIPTION OF THE INVENTION

Given the nature of the invention, an attempt has been made to maintain, to the extent possible, the language used by the average expert in the subject matter; so that throughout the present document you can find several anglicisms commonly used in the related technical field. Likewise, when it has been possible, the corresponding term has been used in Spanish, the term in question has been defined or the correspondence between terms has been indicated.

Below is a list of terms that are used throughout this document, along with a brief description of them:

• System: Refers to a specific implementation of this design.

• "Component": An individual aspect, encapsulated and isolated from the system.

• "Host": An instance of a system component.

• Client: An external program that wishes to interact with the system.

• "Gateway": The component that acts as an access point to the system, exposed to a communication network using a specific protocol.

• "Middleware": The component that is responsible for processing requests to the system and formatting the responses for the client.

• "Service": The component that is used to represent a specific domain of the system, which processes the logic for requests within that domain.

• "Discovery": The component that acts as a record of the other active components, their configuration, and the "Hosts" where they are located.

• Message: An information packet sent between system components.

• Payload of Assignment ("payload" in English): An object, sent by a component of the system, transmitted through one or more messages.

• Transportation: An object that may be present in a payload, which is created by a "Gateway", sent to a "Service", and possibly among other "Services", and processed by one or more "Middleware".

The object of the invention is based on maintaining "quorum" between the different components that form the architecture of the application.

For this purpose, a distributed network and a management method are proposed in the following document. Said distributed network comprises a series of "host" servers where in at least one of them a series of components are defined: A service component (called "Service") in charge of encapsulating the logic of the application, an intermediate component ( called "Middleware") an access point (called "Gateway") and a registration component (called "Discovery").

The object of the invention is focused on a specific component, the so-called "Discovery", which has the responsibility to collect the configuration and the status of the other components registered with it, and publish them a record of all these for that can be located between them to communicate, unlike the previous art, where a central point of registration is maintained (called "Service Locator"), but that the burden of consulting that record is distributed to the components, instead of generating a point of congestion in that central registry.

All messages are handled through binary flows on the solution available in the implementation language, such as "ZeroMQ" or "Nanomsg", and using communication protocols, such as IPC or TCP, depending on whether the components are in the same physical machine or not, for communication.

These messages carry a payload of assignment ("payload" in English), which define the type of message that is, and therefore its objective.

The format of the most common load object is a "command". These messages are intended to perform a task or request something from another component. The properties contained in this object should preferably be at least the following:

• Name: The name of the command to call (string).

• Arguments: The key arguments / value for the command, if there are no arguments this property should not be defined (object).

The format of a response to a "command" is standardized as a "command-reply". The objective of these messages is exclusively to respond to a "command" message. The properties contained in this object must be at least the following:

• Name: The name of the command that processes the response (string).

• Result: The data provided by the component for the response (object).

In the event that an error occurs, a message of the type "error" could be returned as the response to a "command". The properties contained in this object must include at least the property: "Code", this being a number that represents the error that occurred.

Transport ("Transport") is the object that must be created by a "Gateway" component in each request, and must be propagated through the "Services" during a request. Its objective is to collect the data provided by each "Service", to then be formatted by a "Middleware" as the response to the "Client" making the request. The properties contained in this object may vary according to the implementation, but must include at least: "id", this being a unique identifier of the request (string).

One of the features of the invention, as indicated above, is that a specific component has the responsibility to collect the configuration and the status of the other components registered with it, and to publish a record of all of them. these so that they can be located among them to communicate. This is done using two types of messages, "Heartbeat" and "Mapping".

The messages called "Heartbeat" (heartbeat) are defined as messages that are sent by the "Middleware" and "Service" registered in a "Discovery", said sending is carried out continuously in a certain time interval, and they are referred to the state of the server ("host") where they reside. This can be any data that the "Discovery" considers appropriate to determine, for example, the load to which that server is exposed; such as the use of system resources, such as CPU, physical and / or virtual memory, and disk.

The mapping messages called "Mapping" are sent continuously in an interval by the "Discovery" to each of the components that are registered in the "Discovery; being the message related to a record of the "Middleware" and "Service" that were recorded in said "Discovery" and from which it receives "Heartbeat". This registry includes enough data for one component to locate another, such as the IP address and port number, and / or the communication protocol to be used.

DESCRIPTION OF THE DRAWINGS

To complement the description that is being made and in order to help a better understanding of the characteristics of the invention, according to a preferred example of practical realization thereof, a set of drawings is attached as an integral part of said description. where, with illustrative and non-limiting character, the following has been represented:

Figure 1 .- Shows a diagram of the method object of the invention.

Figure 2 shows a diagram of the object of the invention where the communication of "Heartbeat" and "Mapping" between the "Discovery" and the other components is represented.

PREFERRED EMBODIMENT OF THE INVENTION

In a preferred embodiment of a first aspect of the invention shown in Figure 1, there is a distributed network having an architectural design for a software application, namely that intended to be used by a communication network, and on all over the Internet, which needs to be fragmented and preferably distributed through several different servers.

Its design is based mainly on four components, which represent different architectural elements or entities of an application. You can define any number of components, one being the minimum requirement, and in any order or distribution. These can be distributed through the desired servers, with one or more components residing in a server, and in any geographical location on the planet that has access to a common communication network, such as the Internet.

Each of these components has a different function and responsibility, these components being defined as follows:

1. A component of registration (called "Discovery"): This component is responsible for keeping a record of all the components that appear in the application, and that are part of the communication model proposed by the design of the invention. to save that record may depend on the technical implementation of the design of the invention.

2. An access point (called "Gateway"): This component represents access to the application from a client program, or directly through the network in which the application is exposed, its main function is to receive requests and serve responses According to the communication protocol that is being interpreted, such as HTTP, it does not interpret the content of the requests, but simply is responsible for processing the received message, using the rules defined by the implemented protocol, transforming it into an internal object, which then it can be communicated with other components.The protocols available through a "Gateway" depend on the technical implementation of the design of the invention. This component must be registered with a "Discovery" application to be part of the communication.

3. An intermediate component (called "Middleware"): This component being middleware type implements a logic of information exchange between applications in such a way that assists an application to interact or communicate with other applications, or packages of programs, networks , hardware and / or operating systems, this intermediate component connects with one or more "Gateway", and is responsible for interpreting the content of the requests, and formulate the responses for the "Gateway" that provided them the object of the aforementioned petition. When interpreting a request, it should be possible to extract enough information to determine what service is to be called from the "Gateway." How is determined what is considered necessary information depends on the needs required by each technical implementation of the object of the invention Both the requests and the answers are subject to the protocol that is interpreting the "Gateway" with which they are connected and communicating. This component must be registered with a "Discovery" application to be part of the communication.

4. A service component (called "Service"): This component is responsible for encapsulating the logic of the application, each service component or "Service" represents a domain of the application, such as users, products or services. comments. The objective is that, when fragmenting the application in independent sets, these sets represent some domain of the application, as it could be a concrete aspect or process of the same. Each set, in turn, can allow a series of operations to be performed on that domain, such as in the example of users, creating a new user, modifying an existing user, or deleting a user. In addition, a service component or "Service" can communicate with another service component or "Service" registered in a common "Discovery." This component must be registered with a "Discovery" of the application to be part of the communication.

The communication model of the invention requires that preferably at least two message exchange channels between components be established; These messages can be of two types, as shown in Figure 2:

1. Some first messages (called beats or "Heartbeat"): The "Middleware" and "Service" that are registered with a "Discovery" send, continuously in an interval, data referring to the state of the server where they reside. This can be any data that the "Discovery" considers appropriate to determine the load to which that server is exposed, such as the use of system resources, such as the CPU, physical and / or virtual memory, and disk.

2. A few second messages (called "Mapping"): The "Discovery" sends, continuously in an interval, a record of the "Middleware" and "Service" that were recorded, and from which it receives "Heartbeat", to each of the components that are registered to "Discovery". This registry includes enough data for a component can locate another, such as the IP address and port number, and / or the communication protocol to be used.

The data structure (called object) that is transmitted between the components depends on the technical implementation of the design of the invention.

The protocol and / or technical solution for the format and / or method of data transmission is not specific; however, it must allow asynchronous communication between the components, in such a way that a message between two components does not block that communication channel to other messages.

Thus, in a possible embodiment of the second aspect object of the invention, and referring to Figure 1, we have a "Gateway" (G1) receives a request from an external communication network, such as the Internet, and interprets it and creates an internal object that represents the semantics of that request. The "Gateway" (G1) communicates with a first "Middleware" (M1), passing it the object to determine the "Service" component to which it is desired to call; then a first "Middleware" (M1) analyzes the request and extracts the data that allow to identify the "Service", in a possible embodiment of the object of the invention, the HTTP protocol can be used.

This data can be in the URL, the parameters of the search string or in the headers, and it includes said data in an object that returns to the "Gateway" (G1), with the data provided by the first "Middleware". "(M1), the" Gateway "(G1) proceeds to communicate with a first" Service "(S1), making it reach the object that contains the data of the request. When processing its logic, the first "Service" (S1) also calls a second "Service" (S2), sending it the object received from the "Gateway" (G1), and the second "Service" (S2) when it finishes executing. its logic, enters its data in the object and returns it to the first "Service" (S1) .The first "Service" (S1) also ends, and enters its data in the object and returns it to the "Gateway" (G1). The "Gateway" (G1) then communicates with a second "Middleware" (M2) and sends it the object received from the first "Service" (S1). With the object data the second "Middleware" (M2) generates the response and it is returned to the "Gateway" (G1). "Gateway" (G1) uses the response generated by the second "Middleware" (M2) to respond to the request received from the external communication network.

Figure 1 shows the figure of "Discovery" (D1) for a better understanding of an alternative embodiment of the object of the invention shown in Figure 2, in which use is made of the implementation of a message communication model " Heartbeat "and" Mapping "between the" Discovery "(D1) and the other components, realization based on the preferred embodiment shown in figure 1. In this case, in addition to the aforementioned components, there is a third component" Service "(S3) ) and the "Discovery" component (D1) is actively involved to generate the first messages (called beats or "Heartbeats") in which "Middleware" (M1, M2) and "Services" (S1, S2, S3) that are registered with the "Discovery" (D1) send the status of the server where they reside, while in the second messages (called mapping or "Mapping"): the "Discovery" (D1) sends a record of the "Middleware" (M1) , M2) and "Services "(S1, S2, S3) and from which it receives" Heartbeats ", to each of the components that are registered to" Discovery "(D1).

In a preferred embodiment, once the "host" of a component of "Middleware" or "Service" has registered with an instance of the "Discovery" component, by means of the respective register by means of which the "Discovery" receives a series of data (variables according to implementation) being from then when you can start receiving messages like "Heartbeats", the "Discovery" sends messages "Mapping" to the components registered in the "Discovery" and in this way periodically updates its status by publishing an event, in an interval preferably defined in milliseconds, and depending on the demand for use; generating in this way a quorum.

This "Mapping" and "Heartbeat" message sending event is carried out using preferably and in a non-limiting manner "MessagePack" any other transport protocol.

Preferably, the "Heartbeat" type messages include, as the payload, at least one property that allows the "Discovery" to determine if there is redundancy which "host" to choose for a specific component; said property refers to data that can be referred to: CPU, memory, network, disks, and swap memory.

These data should preferably be stored by the "Discovery" component, and used as a reference to determine the health status of each "host". With these data the "Discovery" can generate a series of indices or "weight" generated from the information included in the messages type "Hearbeat" related to redundancy of each "host" storing them, in such a way that you have at your disposal a list of the suitability of each "host" for each component.

Claims (7)

1. Distributed network comprising a plurality of servers, characterized in that at least one of the servers resides, at least one of: - a registration component which in turn comprises a register of all the components contained in an application, - an access point, intended to receive requests and serve responses according to a communication protocol that is interpreting, - an intermediate component connected to at least one of the access points - a service component, and - two message channels that, in turn, include: - a first message channel connecting intermediate components and service components registered in a registration component for transmitting first messages between intermediate components and service components registered in a registration component in such a way that the state of the server where they reside is sent , and - a second message channel connecting the registration component with each of the components that are registered in said registration component for transmitting a second number of messages that are sent from the registration component and that comprise a register of intermediate components and registered service components from which it receives first messages. 2. Management method of a distributed network comprising a plurality of servers, wherein at least one of said servers comprises at least one of the following components: - a registration component which in turn comprises a register of all the components contained in an application, - an access point, intended to receive requests and serve responses according to a communication protocol that is interpreting, - an intermediate component connected to at least one of the access points - a service component, registered in the registration component, and - two message channels, which in turn include: - a first message channel connecting intermediate components and service components registered in a registration component for transmitting first messages between intermediate components and service components registered in a registration component in such a way that the state of the server where they reside is sent , Y - a second message channel that connects the registration component with each of the components that are registered in said registration component to transmit a second number of messages that are sent from the registration component and that comprise a register of intermediate components and components of registered service from which you receive first messages; where the method comprises generating a series of indexes from the information included in the "Hearbeat" type messages, in such a way that a list of the suitability of location for each component is available. Method according to claim 2, characterized in that the communication between the components is asynchronous. Method according to claim 2 characterized in that when the server in which an intermediate component or service component resides has been registered with an instance of the registration component, it is periodically updated its status by publishing an event. Method according to claim 4 characterized in that the event is sent as a serialized object as a payload ("payload"). Method according to claim 4 characterized in that the event is published in a defined interval in milliseconds. Method according to claim 4 characterized in that the state comprises data of: CPU, memory, network, disks, and swap memory.