CN111930832B - Fast and scalable database cluster communication path - Google Patents

Abstract

The present invention relates to a technology for application containers to communicate via direct communication links. One or more first dedicated virtual links are established for direct application container-level communication between one or more first application containers. Data is transmitted between the one or more first application containers via the corresponding one or more first dedicated virtual links, wherein each of the one or more first dedicated virtual links is connected to a corresponding one of the one or more first application containers at a first end and to a corresponding virtual input/output (VIO) at a second end.

Description

Fast and scalable database cluster communication path

Cross-application of related applications

This application claims the priority of U.S. Provisional Patent Application No. 62/221,458, filed on September 21, 2015, entitled “Fast and Scalable Database Cluster Communication Path,” and claims to be a divisional of Chinese Patent Application No. CN201680051225.7, filed on September 21, 2016. The contents of the above two applications are incorporated herein by reference.

Background technique

In order to connect and manage network nodes/devices (e.g., routers/switches, etc.) on an enterprise network through the Internet in a secure manner, multiple secure sessions need to be created depending on the type of services provided by the node/device. When the node/device is located behind a network address translation (NAT)/firewall, the problems associated with connecting and managing the node/device become increasingly prominent. The enterprise NAT/firewall needs to open multiple ports to allow each session. As the number of sessions increases, the number of ports also increases.

Summary of the invention

In one embodiment, a method for transmitting application payloads in a network is provided, comprising: receiving one or more application payloads corresponding to one or more applications on a client, wherein the application payload consists of a client request including a transport layer protocol; terminating the transport layer protocol and reading the application payload associated with the current session; preparing header information including specific application information for each received application to be inserted into a corresponding application payload; and encrypting the application payload including the header information for transmission over a single virtual communication link in the network.

In another embodiment, a non-transitory computer-readable medium is provided, wherein computer instructions for transmitting application payloads in a network are stored in the non-transitory computer-readable medium, and when it is executed by one or more processors, the computer instructions cause the one or more processors to perform the following steps: receiving one or more application payloads corresponding to one or more applications on a client, wherein the application payload consists of a client request containing a transport layer protocol; terminating the transport layer protocol and reading the application payload associated with the current session; preparing header information containing specific application information for each received application to be inserted into a corresponding application payload; and encrypting the application payload containing the header information for transmission over a single virtual communication link in the network.

In another embodiment, a method for application containers to communicate via direct communication links is provided, comprising: establishing one or more first dedicated virtual links for direct application container-level communication between one or more first application containers; transmitting data between the one or more first application containers via the corresponding one or more first dedicated virtual links, wherein each of the one or more first dedicated virtual links is connected to a corresponding one of the one or more first application containers at a first end and to a corresponding virtual input/output (VIO) at a second end.

In another embodiment, a method for providing direct database to application-level communication via virtual input/output is provided, comprising: establishing one or more first dedicated virtual links for direct application-level communication between one or more first database instances; transmitting data between the one or more first database instances via the corresponding one or more first dedicated virtual links, wherein each of the one or more first dedicated virtual links is connected to a corresponding one of the one or more first database instances at a first end.

This summary is intended to briefly introduce some selected concepts that will be further elaborated in the following description. This summary is not intended to identify key features or essential features of the claimed invention, nor is it intended to assist in determining the scope of the claimed invention. The claimed invention is not limited to implementations that address any or all of the disadvantages described in the background.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the present invention are illustrated by way of example and not limitation in the accompanying figures, in which like references indicate similar elements.

FIG1 shows an exemplary network environment in which various embodiments of the present invention may be implemented;

FIG2 shows a virtual communication link environment in which application payloads can be reused;

FIG. 3 illustrates a client and server proxy in the application crypto multiplexing (ACM) environment provided in FIG. 2 ;

4A and 4B show a flow chart of sending and receiving a payload via a virtual communication link;

FIG5 shows a mediation layer added to the payload of an application client or application server;

FIG6 shows an example of the ACM header of FIG5 ;

FIG7 shows a state diagram of an ACM data session state machine;

8A and 8B show an exemplary flow chart of transmitting an application payload in a network;

FIG9 illustrates an exemplary network in which the present invention may be implemented;

FIG10 illustrates exemplary container packet communication using a virtual input/output interface for intra-host communication;

FIG11 illustrates exemplary container packet communication using a virtual input/output interface for inter-host communication;

12 and 13 illustrate various embodiments of direct database/application level communications using VIO without consuming TCP and associated sockets;

14A and 14B illustrate an exemplary flow chart for establishing a virtual link for a container and a database instance;

FIG15 shows an embodiment of a node provided by an embodiment of the present invention;

FIG16 shows a block diagram of a network system that can be used to implement various embodiments;

FIG. 17 shows a block diagram provided by the disclosed technology.

Detailed ways

The present invention relates to a technology for transmitting application payloads in a network: receiving one or more application payloads corresponding to one or more applications on a client, wherein the application payload consists of a client request containing a transport layer protocol; terminating the transport layer protocol and reading the application payload associated with the current session; preparing header information containing specific application information for each received application to be inserted into a corresponding application payload; encrypting the application payload containing the header information so as to be transmitted through a single virtual communication link in the network.

It should be understood that the present invention can be implemented in many different ways and should not be construed as being limited to the embodiments set forth herein. On the contrary, providing these embodiments will make the present invention thorough and complete, and will fully convey the present invention to those skilled in the art. In fact, the present invention is intended to cover the substitution, modification and equivalent of these embodiments, which are included in the scope and spirit of the present invention as defined by the appended claims. In addition, many specific details are set forth in the following detailed description of the present invention, so as to thoroughly understand the present invention. However, those of ordinary skill in the art will recognize that the present invention can be implemented without these specific details.

The disclosed technology generally provides a "many-to-one" integrated proxy and tunnel solution that adds an intermediary layer between the application payload and the transmission control protocol (TCP)/secure socket layer (SSL) header, where a state machine can be used to control the session.

This integrated proxy and tunnel solution can be implemented using a client or server based on the location of the network node/device. The network node/device illustratively includes but is not limited to a router, switch, WiFi device, Internet of Things (IOT) device, or any physical and virtual device as understood by a person of ordinary skill in the art viewing the present invention.

It will be apparent from the following discussion that the disclosed technology can provide a single point for security services. For example, an application can delegate encryption responsibilities to a device, and the device can establish a channel between the device and a controller and exchange encrypted data, thereby providing a secure connection between the devices. An encryption server is provided on the server side to implement the disclosed technology, and an encryption client function is provided on the client side to implement the disclosed technology. The communication channel can authenticate and provide message integrity, user authentication, and confidentiality. The communication channel can also support standard symmetric/asymmetric encryption functions and can establish a secure channel behind a NAT/firewall.

FIG. 1 illustrates an exemplary network environment in which various embodiments of the present invention may be implemented. The network environment 100 includes, for example, a client 102, a server 104, an SDN controller 112, and an administrator 114. Typically, SDN involves the use of an independent controller that performs control functions for a group of network devices. As an example of a software defined network, in the case of routing, instead of a router performing individual analysis to determine a route through the network, the controller may determine the route and cause other devices in the network to operate according to the controller's decision. Software defined networks may be implemented using different protocols, including open protocols such as OpenFlow, as well as proprietary protocols from network providers.

In the depicted embodiment, the SDN 106 includes network nodes 108 and 110 and service devices 116. The network nodes 108 and 110 may include switches and other devices (not shown). These network nodes 108 and 110 may be physical instantiations or virtual instantiations that are generally used to forward network traffic. Although not shown, the SDN 106 may also include other types of devices, such as routers, load balancers, and various L4-L7 network devices among other network devices.

The SDN 106 may connect various endpoint devices such as the client 102 and the server 104. In addition, the SDN 106 may provide services to network traffic flowing between the client devices 102 and the server devices 104. In one embodiment, the administrator 114 may use the SDN controller 112 to program the network devices of the SDN 106 to transmit the network traffic of the client 102 to one or more service devices 116.

The service device 116 may include, for example, an intrusion detection service (IDS) device, an intrusion prevention system (IPS) device, a web proxy, a web server, a web application firewall, etc. In other examples, the service device 116 may additionally or alternatively include a device for providing services, such as denial of service (DoS) protection, distributed denial of service (DDoS) protection, service filtering, wide area network (WAN) acceleration, or other such services.

Although shown as a separate device, it should be understood that the service device 116 can be a physical device, a multi-tenant device, or a virtual service (e.g., a cloud-based service), and can be easily applied to virtual devices and cloud-based applications in addition to physical devices.

2 shows a virtual communication link environment that can multiplex application payloads. The environment 200, also referred to herein as an application crypto multiplexing (ACM) environment 200, includes, for example, a virtual communication link 202, a client agent 204, an application client 206, a server agent 208, and an application server 210.

A virtual communication link (e.g., a virtual tunnel) allows two computer programs (e.g., client and server applications) that cannot directly address each other to run. For example, when a client application of an application client 206 needs to connect to a server application of an application server 210 at a remote site, the server application 210 may be located on a computer in a local network (e.g., behind a firewall) that is not addressable by the client or collaborator. At this point, the application client 206 will not be able to directly address the application server 210. Therefore, the virtual communication link enables the application client 206 to access the application server 210 and vice versa.

In an embodiment of the disclosed technology, the virtual communication link 202 allows one or more applications on the application client 206 and/or application server 210 to share a single communication channel (e.g., a virtual communication link or tunnel) by multiplexing and/or demultiplexing the payload of the applications on the application client 206 and/or application server 210 to process services from the same device.

More specifically, the client agent 204 and the server agent 208 (explained below with reference to FIG. 3 ) and the virtual communication link 202 may be integrated or combined at each end of the channel to form a single socket interface by multiplexing and/or demultiplexing the payloads of the application client 206 and the application server 210 to communicate using the virtual communication link 202 such as an encrypted virtual tunnel (VT).

In one embodiment, the multiplexing and/or demultiplexing may be achieved by adding an ACM header to a payload of a specific application that carries specific application information. The header is described in more detail below with reference to FIG5 and FIG6.

The application client 206 may include a first client application 206A such as a Network Configuration Protocol (NETCONF) plug-in, a second client application 206B such as a Simple Network Management Protocol (SNMP) plug-in, and/or a third client application 206C such as a Control and Provisioning of Wireless Access Points (CAPWAP) plug-in. These plug-ins can be used for remote configuration of devices and allow business models to be seamlessly added to existing network devices that make up the network. In other words, rather than deploying a business generator to strategically introduce business models to various points in the network, the required business models are encapsulated and transmitted to the existing network devices of the network through plug-ins, otherwise, these plug-ins will be used to manipulate the data configuration of the network devices.

For example, NETCONF provides a mechanism for configuring network devices and uses data encoding based on Extensible Markup Language (XML) for configuration data, which may include policy data; SNMP allows device management systems to traverse and modify the management information base (MIB), which stores configuration data within managed elements; CAPWAP is a protocol for exchanging messages between any mesh node and the controller through the virtual communication link, and was originally designed for so-called lightweight access points.

The client agent 204 includes an encryption client 204A operatively coupled to first, second and third client applications 206A, 206B and 206C, respectively, via sockets (see FIG. 3 for explanation).

Similar to the application client 206, the application server 210 may include one or more of a first server application 210A such as a NETCONF plug-in, a second server application 210B such as an SNMP plug-in, and/or a third server application such as a CAPWAP plug-in, which are operably coupled to the application encryption server via a socket.

The server agent 208 includes an encryption server 208A operatively coupled to first, second and third client applications 210A, 210B and 210C, respectively, via sockets (see FIG. 3 for explanation).

Accordingly, the ACM environment 200 allows an SDN controller, such as the SDN controller 112, to communicate with and manage network devices, such as network nodes 108 and 110, using a network, such as a public cloud or the Internet. By using the disclosed ACM environment 200, a firewall may not need to open multiple ports to support multiple applications. Instead, the ACM environment 200 enables the SDN controller 112 to easily manage multiple applications. The ACM environment 200 may also reduce TCP proxy session overhead and tunnel payload overhead, and may be used for control plane services running different applications on the same device.

The ACM environment 200 is different from other encryption technologies. For example, other technologies such as Internet key exchange (IKE)/Internet protocol security (IPSEC) use layer 3-based tunneling technology and layer 4-based SSL technology. These technologies use one session for each application.

Figure 3 illustrates the client and server agents in the ACM environment provided in Figure 2. The ACM environment 300 includes, for example, a virtual communication link 202, such as an encrypted virtual tunnel communicatively coupled to a client agent 204 and a server agent 208.

The client agent 204 includes a session manager 302A, a MUX/DEMUX 306A, a transport layer security (TLS)/datagram TLS (DTLS) client 304A, a NETCONF client (session 1) 310A, and a SNMP client (session 2) 312A. Similarly, the server agent 208 includes a session manager 302B, a MUX/DEMUX 306B, a transport layer security (TLS)/datagram TLS (DTLS) client 304B, a NETCONF client (session 1) 310B, and a SNMP client (session 2) 312B.

The session manager 302A can implement transparent, secure and open communication between the application client 206 ( FIG. 2 ) and the client agent 204. In one embodiment, the session manager 302A can perform encrypted session processing, including managing encrypted session handshakes, and managing keys, certificates, authentication, authorization, etc. In addition, the session manager 302A can establish encrypted sessions and/or connections, terminate encrypted sessions and/or connections, and establish itself as a middleman for encrypted sessions and/or connections, etc. in one embodiment.

The NETCONF client 1 (session 1) 310A and the SNMP client 2 (session 2) 312A are coupled to the session manager 302A via socket communication. Similarly, the NETCONF server 1 (session 1) 310B and the SNMP server 2 (session 2) 312B are coupled to the session manager 302B via socket communication.

The MUX/DEMUX 306A on the client proxy 204 may be used to route the application payload from multiple sockets on the application client 206 to a single socket on the client proxy 204 by multiplexing the application payload. The multiplexed application payload may be transmitted to the proxy server 208 via the virtual communication link 202 and then transmitted to the application server 210. In one embodiment, the MUX/DEMUX 306A is used to transmit the application payload from the client proxy 204 to the corresponding multiple sockets on the application server 210 (after demultiplexing at the server proxy 208) via a single secure connection (e.g., the virtual communication link 202).

Similarly, the MUX/DEMUX 306A on the client agent 204 can be used to receive application payloads from the virtual communication link 202 using a single socket on the client agent 204. The application payload received from the application server 210 can be demultiplexed by the MUX/DEMUX 306A into discrete application payloads, and each discrete application payload can be transmitted to a corresponding one or more sockets on the application client 206. In one embodiment, the MUX/DEMUX 306A is used to receive application payloads over a single secure connection (e.g., virtual communication link 202) from the server agent 204 to corresponding multiple sockets on the application client 206.

The MUX/DEMUX 306A is also responsible for preparing ACM header information and adding the ACM header information to the application payload, as described below.

The term socket as used herein refers to a port, buffer, logical node or object for receiving data in any format, such as HTTP format, from a remote device via a network connection. The MUX/DEMUX 306B may be configured in a similar manner.

In order to ensure the communication on the virtual communication link 202, TLS/DTLS clients 304A (client agent) and 304B (server agent) can be used. The TLS/DTLS clients 304A and 304B are responsible for encrypting/decrypting the multiplexed/demultiplexed application payload. The TLS protocol is mainly intended to provide privacy and data integrity between two communicating computer applications. TLS is designed to run above transport protocols such as TCP and below application layers such as HTTP. In order to establish an encrypted secure data channel, the connecting peers must agree on the cipher set to be used and the key used to encrypt the data. TLS is also suitable for running datagram protocols such as the User Datagram Protocol (UDP). Datagram TLS (DTLS) is a TLS-based protocol that can protect datagram transmissions such as UDP and is well suited for tunnel applications, such as CAPWAP tunnels to controllers in mesh networks.

4A and 4B show a flow chart of sending and receiving payloads over a virtual communication link. The process described herein is implemented by the client agent 204 and the server agent 208 as shown in FIG3. However, it should be understood that any network component or element can perform this implementation, and the disclosed embodiment is a non-limiting example.

Specifically, FIG. 4A shows a flow chart of sending client data to a server. Client 310A and/or client 312A create a TCP/UDP client request and send application data (e.g., payload) to client agent 204. At 402A, the client agent 204 receives the application data through session manager 302A. At this point, the session manager 302A terminates the TCP connection and reads the application data from the local session and obtains session information. Manages the state (FIG. 7) and session, and sends session details to MUX/DEMUX 306A.

At 404A, the MUX/DEMUX 306A prepares an ACM header and adds the ACM header to the application data (payload). The ACM header and application payload are described in detail below in conjunction with FIG. 5 and FIG. 6 .

At 406A, the TLS/DTLS client 304A is responsible for encrypting/decrypting the data (application data+ACM header) and sending the application data to the application server 210 via the virtual communication link 202.

At 412A, the server agent 208 receives the encrypted/decrypted data (application+ACM header) via the virtual communication link 202. At 410A, the MUX/DEMUX 306B adds/removes the ACM header to the payload.

At 408A, the session manager 302B on the server agent 208 then reads the application data from the MUX/DEMUX 306B and creates/manages a local session with the application server 210. The application data is then sent to the application server 210 over the session's secure socket, and the client 310B and/or 312B reads the request and prepares an application response.

FIG4B shows a flow chart of sending server data to a client. In response to the client request of FIG4A, the server 1 310B and/or server 2 312B prepares an application response. At 402B, the session manager 302B reads the application data (e.g., payload) from the application server 210 and creates/manages a record for the session information. The session manager 302B then sends the session information and application data to the MUX/DEMUX 306B.

At 404B, MUX/DEMUX 306 reads the session information and application data and prepares an ACM header to be added/removed from the application data (payload). At 406B, TLS/DTLS service 304B encrypts the application data (application+ACM header) and sends the encrypted application data to the application client 206 via the client proxy 204 and virtual tunnel link 202.

When the TLS/DTLS client 304A of the proxy client 204 receives the encrypted application data, the application data (application+ACM header) is decrypted at 408B, and at 410B, the MUX/DEMUX 306A removes the ACM header from the application data (payload) and sends the decrypted application data to the session manager 302A. The session manager 302A then reads the application data from the MUX/DEMUX 306A and sends the application data to the corresponding sockets of the client 1 310A and/or the client 2 312A, where the response is received from the application server 210.

Figure 5 shows an intermediary layer added to the payload of an application client or application server. The shim layer is shown added between layer 4 and layer 7 of the open systems interconnection (OSI) layer 502. The figure also shows three payloads, including: NETCONF payload 502A, SNMP payload 502B, and CAPWAP payload 502C.

As shown, Layer 3 (IP) is the packet layer that builds and manages multi-node networks, including addressing, routing, and service control. Layer 4 (TCP/UDP) is the transport layer responsible for transmitting data segments between points in the network, including segmentation, acknowledgment, and multiplexing. Layer 5 and/or Layer 6 may include added intermediary layers as part of the presentation layer (Layer 6) and session layer (Layer 5) that manage communication sessions, such as continuously exchanging information between two nodes in the form of multiple forward and backward transmissions. Layer 7 (NETCONF/SNMP/CAPWAP) is the application layer that contains high-level APIs, including resource sharing and remote file access.

FIG6 shows an example of the ACM header of FIG5. The ACM header includes, for example, an ACM version field, an ACM operation (Op) type field, a secure session control field, an application session/source port field, an application identifier (ID) field, and a payload length field. It should be understood that the header shown is a non-limiting example of a header configuration, and any variation may be implemented.

The size and information type of the fields defined in the ACM header may vary. As an example, in a non-limiting embodiment, the ACM Version field may be 4 bits and may indicate an initial version; the ACM Op Type field may be 4 bits and may indicate an operation type; the Secure Session Control field may be 2 bytes and may indicate a secure session control type; the Application Session/Source Port field may be 2 bytes and may indicate a session ID or source port; the Application ID field may be 2 bytes and may indicate an application TCP, UDP ID or destination port; the Payload Length field may be 2 bytes and may indicate the size of the payload.

The payload can be configured as any one or more of the following information types: ACM hello request, ACM hello response, ACM confirmation, ACM data or data transfer, ACM service update, ACM service update confirmation, ACM health statistics request, ACM health statistics response, ACM control/alarm/error, ACM heartbeat request and/or ACM heartbeat response.

Fig. 7 shows a state diagram of an ACM data session state machine. The ACM data session state machine includes an initial state 702, a data write state 704/710, a data read state 706/712, and a session close state 708. As shown in Fig. 7, the data operation state can be defined according to the following contents: a session start event (CE)-11, a read data/write data event (DRWS)-01, a read data/write data end event (DRWE)-10, and a session close event (CT)-00.

8A and 8B show an exemplary flow chart of transmitting an application payload in a network. Referring to FIG8A , at 802, one or more application payloads 502A, 502B, and 502C are received, for example, by a proxy client 204, wherein the one or more application payloads 502A, 502B, and 502C correspond to one or more applications 206A, 206B, and 206C on an application client 206, respectively, and the application payload consists of a client request including a transport layer protocol such as TCP or UDP.

At 804, the application payload received at the proxy client 204 is terminated, for example by the session manager 302A, and read for the current session.

At 806, the MUX/DEMUX 306A prepares header information containing specific application information for each received application to be inserted into a corresponding application payload. At 808, the TLS/DTLS client 304A encrypts the application payload containing the header information for transmission over a single virtual communication link 202 in the network.

8B, the one or more application payloads, including header information inserted into the application payloads, may be multiplexed to share a single communication channel (ie, virtual communication link).

The multiplexed application payload is transmitted over a shared communication link at 812. Upon reaching the end point (eg, server proxy 208), the application payload is demultiplexed (and decrypted) so that the application server 210 can respond to the request from the client at 814.

9 shows an exemplary network in which the present invention may be implemented. The network 900 includes a cloud 902, a network 906, a cloud provider 908, and clients 914A and 914B to 914N.

The cloud 902 includes one or more hosts 904 to 904N (collectively referred to as 904N), wherein each host 904N includes one or more nodes 904N1. In one embodiment, the node 904N1 is a virtual machine (VM) located on a physical machine, such as the host 904 through the host 904N. In another embodiment, the host 904N may be located in a data center. For example, the one or more nodes 904N1 are located on a physical machine 904N on the cloud 902 provided by a cloud provider 908. When located on the host 904N, a user can interact with one or more applications (e.g., applications 904N1-2 and 904N1-3) and execute on the one or more nodes 904N1 using a client computer system such as clients 914A and 914B to 914N. In one embodiment, without using a VM, the applications 904N1-2 and 904N1-3 may be located on the host 904N. As described above, the one or more nodes 904N1 execute one or more applications 904N1-2 and 904N1-3 that may be owned or managed by different users and/or organizations. For example, a customer may deploy applications 904N1-2 and 904N1-3, wherein the applications 904N1-2 and 904N1-3 may coexist with another customer application located on the same or different nodes 904N as the first customer application. In one embodiment, portions or separate applications 904N1-2 and 904N1-3 are executed on different nodes 904N.

In one embodiment, as understood by those skilled in the art, the data used to execute applications 904N1-2 and 904N1-3 includes application images built from pre-existing application components and source code for users who manage the applications 904N1-2 and 904N1-3. An image in an SDN and container network scenario refers to data representing an executable application file that is used to deploy functionality for a runtime instance of the application. In one example, an image is built using the Docker tool, also referred to as a Docker image. As explained below, although the use of a Docker bridge is not excluded, the use of a Docker bridge will not be required in implementing various embodiments of the present invention.

The one or more nodes 904N1-2 and 904N1-3 can execute the application by starting an instance of the application image as a container 904N1-2A, 904N1-2B, 904N1-3A, and 904N1-3B in one or more nodes 904N1-2 and 904N1-3. The containers 904N1-2A, 904N1-2B, 904N1-3A, and 904N1-3B in one or more nodes 904N1-2 and 904N1-3 can implement the functions of the applications 904N1-2 and 904N1-3.

Containers 904N1-2A, 904N1-2B, 904N1-3A, and 904N1-3B can implement operating system-level virtualization, in which an abstraction layer is provided on the kernel of the operating system on the host computer (not shown). The abstraction layer supports, for example, multiple containers, each of which includes an application and its related content. Each container can be executed as an independent process on the operating system and share the kernel with other containers. The container relies on kernel functions to utilize resource isolation (CPU, memory, block I/O, network, etc.) and separate namespaces, and completely isolate the application view of the operating environment. By using containers, resources can be isolated, so that the business is limited, and the process is configured to have a private view of the operating system with its own process ID space, file system structure, and network interface. Multiple containers can share the same kernel, but each container can be restricted to use only a specific amount of resources, such as CPU, memory, and I/O.

Clients 914A and 914B to 914N can be connected to a host 904N on a cloud 902 provided by a cloud provider 908 via a network 906, wherein the network 906 can be a private network (e.g., a local area network (LAN), a wide area network (WAN), an intranet, or other similar private network) or a public network (e.g., the Internet). Each client 914A and 914B to 914N can be a mobile device, a PDA, a portable computer, a desktop computer, a tablet computing device, a server device, or any other computing device. Each host 904N can be a server computer system, a desktop computer, or any other computing device.

Although various embodiments are described based on the above-mentioned network, those skilled in the art will appreciate that the network is a non-limiting example and can be implemented in various other configurations, including a single integral computer system, and various other combinations of computer systems or similar devices connected in various ways.

FIG10 illustrates an exemplary container packet communication using a virtual input/output interface for intra-host communication. In a traditional SDN, containers are generated from application images collected from, for example, a specified registry. When a container is instantiated (usually by a daemon), a unique network address is assigned to the container, which connects the container to a virtual Ethernet bridge, such as a Docker bridge. All containers in the system communicate by transmitting packets to the Docker bridge, which are then forwarded through the container network. However, the container communicates with each of the heavy bridge ports and utilizes an open vSwitch (OVS) and/or linux kernel bridge mechanism.

In other embodiments, containers 1002, 1004, and 1006 can utilize server virtualization methods such as operating system-level virtualization, in which the kernel of the operating system allows multiple isolated user space instances to be implemented. Some instances may include, but are not limited to, containers, virtualization engines (virtualization engines, VE), virtual private servers (virtualprivate servers, VPS), jails or regions, and/or any hybrid combination thereof. Some exemplary available technologies for containers 1002, 1004, and 1006 include chroot, Linux-VServer, lmctfy ("Let me contain your program"), LXC (Linux container), OpenVZ (Open Virtuozzo), Parallels Virtuozzo container, Solaris container (and Solaris zone), FreeBSD Jail, sysjail, WPAR (workload partition), HP-UX container (Secure Resource Partition, SRP), iCore virtual account, and Sandboxie.

According to the disclosed technology, direct container-level communication is achieved through virtual input/output (VIO) 1010A/B (or input/output virtualization (IOV)). In VIO, a single physical adapter card acts as multiple virtual network interface cards (NIC) and virtual host bus adapters (HBA). These VIOs 1010A/B can be loaded onto the host 1008 (as shown in FIG. 10 ) and include VIO software and/or hardware that can be used to control data packets input and output from containers 1002, 1004, and 1006 through the communication links 1-6 such as dedicated links. Each VIO 1010A/B can directly multiplex and demultiplex the data packets into other containers 1002, 1004, and 1006, thereby solving the limitations of container communication within the host. This configuration can be easily deployed and expanded, and reduces communication overhead.

Referring to FIG. 10 , direct container-level communication is implemented, wherein containers 1002, 1004, and 1006 are communicatively coupled to each other using communication links 1-6 via VIOs 1010A/B connected to a host 1008. In one embodiment, each container 1002, 1004, and 1006 may include a virtual network interface card (vNIC) connected to a corresponding one or more VIOs 1010A/B, without the need to use a bridge to support communication therebetween. It should also be understood that the VIOs 1010A/B may use a bridge or OVS to send packets.

As an example, assume that containers 1002, 1004, and 1006 include dedicated links 1, 2, 3, and 6 (for the purpose of discussion, assume that links 4 and 5 do not exist). Each of the containers 1002, 1004, and 1006 establishes a dedicated virtual link between the corresponding container and the VIO. Therefore, container 1002 forms a link (1) between container 1002 and VIO 1010A, and a link (6) between container 1002 and VIO 1010B; container 1004 forms a link (2) between container 1004 and VIO 1010A; and container 1006 forms a link (3) between container 1006 and VIO 1010B.

FIG. 11 illustrates exemplary container packet communication using a virtual input/output interface for inter-host communication. The inter-host instance includes containers 1102, 1104, 1106, 1108, 1110, and 1112, which are communicatively coupled to VIO 1122A/B in corresponding hosts 1114 and 1116. Similar to the description in FIG. 10, the container establishes a dedicated virtual link for direct application-level communication through the VIO 1122A/B. The dedicated virtual link can be multiplexed onto one or more physical links 1120 directly using input queues, etc.

The physical link 1120 enables each host, such as host 1114 and host 1116. The physical network interface 1120 may be a network I/O device that provides hardware, software, or a combination thereof, support for any form of I/O virtualization (IOV). Exemplary IOV devices include, but are not limited to, SR-IOV devices and non-SR-IOV devices compliant with PCI-SIG, MR-IOV devices compliant with PCI-SIG, multi-queue NICs, I/O adapters, converged network cards, and converged network adapters (CNA).

In an exemplary embodiment, assume that there are three dedicated virtual links on each of the host 1114 and the host 1116 between the container and the VIO. In the host 1114, the container 1102 creates link 1, the container 1104 creates link 2, and the container 1106 creates link 3. In the host 1116, the container 1108 creates link 4, the container 1110 creates link 5, and the container 1112 creates link 6. Within the host 1114, the information transmitted from the containers 1102, 1104, and 1106 to the VIOS 1122A/B can be multiplexed onto one or more physical links 1120 for transmission to the host 1116. It should be understood that the information of any one or more containers can be multiplexed and/or transmitted onto one or more physical links. On the host 1116, the received transmission information can be demultiplexed and sent to the corresponding one or more containers 1108, 1110, and 1112.

Figures 12 and 13 illustrate various embodiments of direct database/application level communication using VIO without consuming TCP and related sockets. One or more embodiments may be standardized to a common application programming interface (API) used by a database (DB). Direct DB/application level communication via VIO may be easy to implement and scale, and reduce communication overhead.

According to the disclosed technology, direct DB instance level communication is achieved through virtual input/output (virtual input/output, VIO) 1210A/B (or input/output virtualization). In VIO, a single physical adapter card acts as multiple virtual network interface cards (NIC) and virtual host bus adapters (HBA). These VIO 1210A/B can be loaded onto the host 1208 and include VIO software and/or hardware, which can be used to control the data packets input and output from DB instances 1202, 1204 and 1206 through the communication links 1-6 such as dedicated links. Each VIO 1210A/B can directly multiplex and demultiplex the data packets to other DB instances 1202, 1204 and 1206, thereby solving the limitations of instance communication within the host. This configuration can be easy to deploy and expand, and reduce communication overhead.

Specifically, FIG. 12 shows an exemplary database instance communication using a virtual input/output interface for intra-host communication. It is understood that a database (DB) instance is a set of memory structures and background processes that access a set of database files. The process can be shared by all users.

DB instance level communication is implemented, wherein DB instances 1202, 1204, and 1206 are communicatively coupled to each other using communication links 1-6 via VIO 1210A/B connected to host 1208. In one embodiment, each container 1202, 1204, and 1206 may include a virtual network interface card (vNIC) connected to corresponding one or more VIOs 1210A/B without the need to use a bridge to support communication therebetween. It should also be understood that the VIO 1210A/B may use a bridge or OVS to send packets.

As an example, assume that containers 1202, 1204, and 1206 include dedicated links 1, 2, 3, and 6 (for discussion purposes, assume that links 4 and 5 do not exist). Each of the DB instances 1202, 1204, and 1206 establishes a dedicated virtual link between the corresponding container and the VIO. Thus, DB instance 1202 forms a link (1) between DB instance 1202 and VIO 1210A, and a link (6) between DB instance 1202 and VIO 1210B; DB instance 1204 forms a link (2) between DB instance 1204 and VIO 1210A; and DB instance 1206 forms a link (3) between DB instance 1206 and VIO 1210B.

FIG. 13 shows an exemplary DB instance packet communication using a virtual input/output interface for inter-host communication. The inter-host instance includes instances 1302, 1304, 1306, 1308, 1310, and 1312, which are communicatively coupled with VIO 1322A/B in corresponding host 1314 and host 1316. Similar to the description in FIG. 12, the DB instance establishes a dedicated virtual link for direct application-level communication through the VIO 1322A/B. The dedicated virtual link can be multiplexed onto one or more physical links 1320 directly using input queues, etc. without TCP sockets.

The physical link 1320 enables each host, such as host 1314 and host 1316. The physical network interface 1320 may be a network I/O device that provides hardware, software, or a combination thereof, support for any form of I/O virtualization (IOV). Exemplary IOV devices include, but are not limited to, SR-IOV devices and non-SR-IOV devices compliant with PCI-SIG, MR-IOV devices compliant with PCI-SIG, multi-queue NICs, I/O adapters, converged network cards, and converged network adapters (CNA).

In an exemplary embodiment, assume that there are three dedicated virtual links on each of the host 1314 and the host 1316 between the DB instances and the VIO. In the host 1314, the DB instance 1302 creates link 1, the DB instance 1304 creates link 2, and the DB instance 1306 creates link 3. In the host 1316, the DB instance 1308 creates link 4, the DB instance 1310 creates link 5, and the DB instance 1312 creates link 6. Within the host 1314, information transmitted from the DB instances 1302, 1304, and 1306 to the VIOS 1322A/B can be multiplexed onto one or more physical links 1320 for transmission to the host 1316. It should be understood that the information of any one or more DB instances can be multiplexed and/or transmitted onto one or more physical links. On the host 1116, the received transmission information can be demultiplexed and sent to the corresponding one or more DB instances 1308, 1310, and 1312.

14A and 14B show an exemplary flow chart for establishing a virtual link for a container and a database instance. Referring to FIG. 14A , the flow chart relates to an application container communicating via a direct communication link. At 1402, one or more first dedicated virtual links 1-6 (e.g., established by each container 1002, 1004, and 1006) are established for direct application container-level communication between one or more first application containers. Then, at 1404, data can be transmitted between the one or more first application containers 1002, 1004, and 1006 via the corresponding one or more first dedicated virtual links 1-6, wherein each of the one or more first dedicated virtual links 1-6 is connected at a first end to a corresponding one of the one or more first application containers 1002, 1004, and 1006 and is connected at a second end to a corresponding virtual input/output (VIO).

Referring to FIG. 14B , the flow chart relates to providing direct database to application level communication via virtual input/output (VIO). At 1406, one or more first dedicated virtual links 1-6 (e.g., established by each DB instance 1202, 1204, and 1206) are established for direct application level communication between the one or more first DB instances 1202, 1204, and 1206. Then, at 1408, data may be transmitted between the one or more first DB instances 1202, 1204, and 1206 via the corresponding one or more first dedicated virtual links 1-6, wherein each of the one or more first dedicated virtual links 1-6 is connected at a first end to a corresponding one of the one or more first DV instances 1202, 1204, and 1206 and at a second end to a corresponding virtual input/output (VIO).

FIG. 15 shows an embodiment of a node provided by an embodiment of the present invention. The node may be, for example, nodes 108 and 110 (FIG. 1) or any other node or router described in the network. The node 1500 may include multiple input/output ports 15110/1530 and/or a receiver (Rx) 1512 and a transmitter (Tx) 1532 for receiving and sending data from other nodes, a processing system or processor 1520 (or a content-aware unit), including a memory 1522 and a programmable content forwarding plane 1528 to process data and determine which node sends the data. As described above, the node 1500 may also receive application data (payload).

Although a single processor is shown, the processor 1520 is not limited thereto and may include multiple processors. The processor 1520 may be implemented as one or more central processing units (CPU) chips, cores (e.g., multi-core processors), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs) and/or digital signal processors (DSPs), and/or may be part of one or more ASICs. The processor 1520 may be used to perform any or a combination of steps described in the embodiments to implement any of the schemes described herein, such as the processes shown in FIG. 4A/FIG. 4B, FIG. 8, and FIG. 14. In addition, the processor 1520 may be implemented using hardware, software, or a combination thereof.

The memory 1522 (or memory) may include a cache 1524, a long-term memory 1526, and a database cluster communication module 1528, and may be used to store routing tables, forwarding tables, or other tables or information disclosed herein. Although a single memory is shown, the memory 1522 may be implemented as a read-only memory (ROM), a random access memory (RAM), or an auxiliary memory (e.g., one or more disks or tape drives for non-volatile data storage).

The introduction of the database cluster communication module 1528 provides improvements to the functionality of the node 1500. The database cluster communication module 1528 can also convert the node 1500 to a different state. Alternatively, the database cluster communication module 1528 is implemented as an instruction stored in the processor 1520.

FIG. 16 shows a block diagram of a network system that can be used to implement various embodiments. A particular device can utilize all of the components shown, or only a subset of the components, and the degree of integration can vary with the device. In addition, a device can include multiple instances of components, such as multiple processing units, processors, memories, transmitters, receivers, etc. The network system may include a processing unit 1601 equipped with one or more input/output devices, such as a network interface, a storage interface, etc. The processing unit 1601 may include a central processing unit (CPU) 1610, a memory 1620, a mass storage device 1630, and an I/O interface 1660 connected to a bus. The bus may be one or more of several bus architectures including any type of memory bus or memory controller, peripheral bus, etc.

The CPU 1610 may include any type of electronic data processor. The memory 1620 may include any type of system memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM) or a combination thereof. In one embodiment, the memory 1620 may include a ROM used at startup, and a DRAM for storing programs and data used when executing a program. In an embodiment, the memory 1620 is non-temporary. The mass storage device 1630 may include any type of storage device for storing data, programs and other information and making the data, programs and other information accessible through a bus. The mass storage device 1630 may include, for example, one or more of a solid-state drive, a hard disk drive, a magnetic disk drive, an optical disk drive, etc.

The processing unit 1601 also includes one or more network interfaces 1650, which may include wired links such as Ethernet cables, and/or wireless links to access nodes or one or more networks 1680. The network interfaces 1650 allow the processing unit 1601 to communicate with remote units via the networks 1680. For example, the network interface 1650 may provide wireless communications via one or more transmitters/transmit antennas and one or more receivers/receive antennas. In one embodiment, the processing unit 1601 is coupled to a local area network or a wide area network for data processing and communication with remote devices, such as other processing units, the Internet, remote storage facilities, etc.

FIG17 shows a block diagram provided by the disclosed technology. The receiving/sending module 1702 receives and sends one or more application payloads corresponding to one or more applications on the client. The termination module 1704 terminates the transport layer protocol and reads the application payload associated with the current session. The preparation module 1706 prepares header information containing specific application information for each received application to be inserted into a corresponding application payload. The encryption/decryption module 1708 encrypts/decrypts the application payload containing the header information so that it can be transmitted through a single virtual communication link in the network. The multiplexing/demultiplexing module 1710 multiplexes/demultiplexes the application payload so that it can be transmitted through a single communication channel (virtual communication link). Finally, the virtual I/O module 1712 allows application containers to communicate directly with each other using virtual input/output (VIO) on the host. The disclosed technology provides multiple secure applications from the same device, which have multiplexed/demultiplexed application payloads transmitted through a single encrypted channel. One or more advantages of this technology include but are not limited to: no session establishment overhead and tunnel overhead, reduction of TCP proxy session overhead and tunnel payload overhead, can be used and can be used for control plane services running different applications on the same device, reduce the number of secure session establishment times (asymmetric and symmetric), realize communication between SDN controller and network devices through public cloud or Internet, multiplex multiple applications through a single encrypted session, firewall does not need to open multiple ports to support multiple applications, manage network devices (routers/switches/WiFi/IOT) through Internet/cloud, and can easily manage multiple applications such as Netconf/SNMP and Capwap.

Other embodiments of the disclosed technology advantageously provide the following non-limiting advantages: VIO reduces communication latency while shortening the end-to-end communication path, thereby improving the overall performance of the database; and VIO can reduce the total number of concurrent connections between database instances, where there is usually a strict limit on the number of TCP connections that a server can establish and send data messages. This will improve the scalability of the database cluster, which also means that more database instances can be put into the database cluster, and the database cluster can process more queries simultaneously. This will also improve the overall database system performance.

According to various embodiments of the present invention, the methods described herein may be implemented by a hardware computer system executing a software program. In addition, in a non-limiting embodiment, implementation may include distributed processing, component/object distributed processing, and parallel processing. A virtual computer system process may be constructed to implement one or more methods or functions described herein, and the processor described herein may be used to support a virtual processing environment.

Here, various aspects of the present invention are described in conjunction with the flowcharts and/or block diagrams of the methods, devices (systems) and computer program products of the embodiments of the present invention. It should be understood that each frame of the flowchart and/or block diagram and the combination of frames in the flowchart and/or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to generate a mechanism so that these instructions executed by the processor of the computer or other programmable instruction execution device create a mechanism for implementing the functions/actions specified by one or more frames in the flowchart and/or block diagram.

The terms used herein are only used to describe specific aspects and are not intended to limit the present invention. Unless otherwise clearly stated in the context, the singular forms "a", "an" and "the" used herein include plural meanings. It should be further understood that the terms "include" and/or "comprise" are used to illustrate the presence of the features, wholes, steps, operations, elements and/or parts, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, parts and/or combinations thereof.

The present invention is described for illustrative purposes only, and these descriptions are not intended to be exhaustive or limited to the disclosed embodiments. Without departing from the scope and spirit of the present invention, various modifications and variations will be apparent to those skilled in the art. Various aspects of the present invention are selected and described in order to better explain the principles and practical applications of the present invention, and to enable those of ordinary skill in the art to understand the present invention and various modifications suitable for the intended specific use.

To achieve the objectives of this article, each process associated with the disclosed technology can be performed continuously by one or more computing devices. Each step in the process can be performed by the same or different computing devices used in other steps, and each step is not necessarily performed by a single computing device.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it should be understood that the subject matter defined in the claims is not necessarily limited to the specific features or acts described above. Instead, the specific features and acts described above are disclosed as exemplary ways of implementing the claims.

Claims (10)

1. A method for application containers to communicate via a direct communication link, comprising: establishing one or more first dedicated virtual links for direct application container level communication between the plurality of first application containers; Data is transmitted between the multiple first application containers through the corresponding one or more first dedicated virtual links, wherein each of the one or more first dedicated virtual links is connected to a corresponding one of the multiple first application containers at a first end and to a corresponding virtual input/output (VIO) at a second end; the VIO is connected to a first host; and the one or more first dedicated virtual links are multiplexed onto one or more physical links. 2. The method according to claim 1, further comprising: establishing one or more second dedicated virtual links for direct application container level communication between the plurality of second application containers; Data is transmitted between the multiple second application containers through the corresponding one or more second dedicated virtual links, wherein each of the one or more second dedicated virtual links is connected to a corresponding one of the multiple second application containers at a first end and to a corresponding virtual input/output (VIO) at a second end; the VIO is connected to a second host; and the one or more second dedicated virtual links are multiplexed onto the one or more physical links. 3. The method according to claim 1 or 2 is characterized in that one or more first dedicated virtual links are multiplexed to one or more physical links through an input queue, and one or more second dedicated virtual links are multiplexed to the one or more physical links through an input queue. 4 . The method according to claim 1 , wherein the data can be transmitted between the one or more first and second application containers without using a bridge. 5. A method for providing direct database to application level communications via virtual input/output, comprising: establishing one or more first dedicated virtual links for direct application-level communication between the plurality of first database instances; Data is transmitted between the multiple first database instances through the corresponding one or more first dedicated virtual links, wherein each of the one or more first dedicated virtual links is connected to a corresponding one of the multiple first database instances at a first end and to a corresponding virtual input/output (VIO) at a second end; the VIO is connected to a first host; and the one or more first dedicated virtual links are multiplexed onto one or more physical links. 6. The method according to claim 5, further comprising: establishing one or more second dedicated virtual links for direct application-level communication between the plurality of second database instances; Data is transmitted between the multiple second database instances through the corresponding one or more second dedicated virtual links, wherein each of the one or more second dedicated virtual links is connected to a corresponding one of the multiple second database instances at a first end and to a corresponding virtual input/output (VIO) at a second end; the VIO is connected to a second host; and the one or more second dedicated virtual links are multiplexed onto the one or more physical links. 7. The method according to claim 5 or 6 is characterized in that one or more first dedicated virtual links are multiplexed to one or more physical links through an input queue, and one or more second dedicated virtual links are multiplexed to the one or more physical links through the input queue. 8. The method according to claim 5 or 6, characterized in that the data can be transmitted between the one or more first and second database instances without using a transmission control protocol (TCP) socket. 9. A network device for application containers to communicate via a direct communication link, comprising: Memory, for storing computer instructions; A processor is used to execute the computer instructions so that the network device implements the method described in any one of claims 1-4. 10. A network device for providing direct database to application level communications via virtual input/output, comprising: Memory, for storing computer instructions; A processor is used to execute the computer instructions so that the network device implements the method described in any one of claims 5-8.