CN107911463B - Business cross-cloud architecture and creation method and management method thereof - Google Patents
Business cross-cloud architecture and creation method and management method thereof Download PDFInfo
- Publication number
- CN107911463B CN107911463B CN201711209025.2A CN201711209025A CN107911463B CN 107911463 B CN107911463 B CN 107911463B CN 201711209025 A CN201711209025 A CN 201711209025A CN 107911463 B CN107911463 B CN 107911463B
- Authority
- CN
- China
- Prior art keywords
- management
- local
- container
- cloud
- virtual machine
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
Abstract
The application discloses a service cross-cloud architecture, which comprises a management center, virtual machines respectively positioned on different cloud platforms and a plurality of hypervisors respectively corresponding to each cloud platform; each virtual machine comprises a container, an Open vSwitch and an agent; establishing a path between hypervisors corresponding to different cloud platforms in advance; the management center transmits the management command to a local hypervisor corresponding to the target virtual machine; the local Open vSwitch in the target virtual machine acquires the management command received by the local hypervisor through the local agent, and transmits the management command to a local corresponding container so as to perform corresponding service management on the container by using the management command. Because the invention is based on virtual network configuration, and the container and the Open vSwitch are applied to separate the service network from the bottom cloud platform, the invention can directly realize the unified management among different cloud platforms, and reduce the difficulty of service crossing the cloud. Correspondingly, the application also discloses a business cross-cloud architecture creating method and a business cross-cloud architecture management method.
Description
Technical Field
The invention relates to cloud computing, in particular to a service cross-cloud architecture and a creating method and a management method thereof.
Background
With the technical development, the cloud computing service is more and more widely used, and meanwhile, the market has stronger and stronger requirements on the deployment of multi-data center heterogeneous cloud and hybrid cloud. However, due to the difference of structure types and service manufacturers, the unified management of cross-cloud structures such as heterogeneous cloud and hybrid cloud is always a difficult problem. Different manufacturers have different underlying cloud platform frameworks, different principles and different specific implementation manners of computing, storage and network communication, which often increases difficulty for unified management of heterogeneous clouds, and a cross-cloud architecture simplifies management difficulty or realizes unified management through a series of technologies and schemes.
The current cross-cloud architecture mainly comprises two methods:
the first is to rent a physical proprietary device of a public cloud on which a complete set of cloud platforms are deployed. The local data center uses the physical equipment of a certain manufacturer, rents the physical equipment on the source public cloud, and deploys the cloud computing software product of the local manufacturer on the physical equipment, so that the remote end (the public cloud) can be brought into the management platform of the cloud product of the manufacturer, and the unified management of the local (private cloud) and the remote end (the public cloud) is realized. The scheme has the advantages that the equipment on the remote public cloud can be applied as required, and the remote cloud computing software product is the same as the local cloud computing software product, so that unified management is facilitated. The disadvantages are that not all public clouds provide for the renting of physical devices, and the renting of physical devices plus the deployment of cloud product software is time consuming.
The second is by way of an API, common to vendors with deep technology collaboration. Different cloud computing software product manufacturers of multiple heterogeneous clouds provide computing, storage and network related APIs for secondary development, so that service virtual machines, network topology, virtual networks, safety equipment and storage data of customers can be uniformly managed on the heterogeneous clouds. The advantage of this solution is that the deep cooperation between vendors can customize some specific functions, and the performance is better. The disadvantage is that deep cooperation among manufacturers is required, even some non-public APIs need to be provided, which is not easy to realize and has no universality for most manufacturers.
Disclosure of Invention
In view of this, the present invention provides a cross-cloud service architecture, a creating method thereof, and a management method thereof, so as to reduce the management difficulty of the cross-cloud service. The specific scheme is as follows:
a service cross-cloud architecture comprises a management center, virtual machines respectively positioned on different cloud platforms and a plurality of hypervisors respectively corresponding to the cloud platforms one by one; each virtual machine comprises a container, an Open vSwitch and an agent; wherein the content of the first and second substances,
establishing communication connection between hypervisors corresponding to different cloud platforms in advance;
the management center is used for transmitting the management command to a local hypervisor corresponding to the cloud platform where the target virtual machine is located;
and the local Open vSwitch in the target virtual machine acquires the management command received by the local hypervisor through a local agent, and transmits the management command to a local corresponding container so as to perform corresponding service management on the container by using the management command.
Preferably, the service is in a cross-cloud architecture and comprises N management center clusters of the management centers; wherein N is an integer not less than 2.
Preferably, the management center is located in a separate physical device or virtual machine or container.
Correspondingly, the invention discloses a business cross-cloud architecture creating method, which is used for creating the business cross-cloud architecture; the method comprises the following steps:
setting a management center;
establishing communication connection between hypervisors corresponding to different cloud platforms;
configuring each virtual machine in the service cross-cloud architecture through the management center;
the process of configuring any virtual machine by the management center comprises the following steps: starting the virtual machine, installing an agent in the virtual machine, configuring the agent to obtain a configured agent, installing an Open vSwitch and a container in the virtual machine by using the configured agent, and configuring the Open vSwitch.
Preferably, the process of configuring the agent includes: configuring the IP address of the management center for the agent;
the process of configuring the Open vSwitch includes: forwarding configuration, configuring access control policy of firewall, configuring IP address of corresponding container and encapsulating the IP address in the Open vSwitch.
Preferably, the process of configuring the access control policy of the firewall includes:
and configuring an access control strategy of the distributed firewall, wherein the access control strategy is an access control rule of N layers, and N is more than or equal to 2 and less than or equal to 4.
Correspondingly, the invention discloses a business cross-cloud architecture management method, which is applied to the business cross-cloud architecture; wherein the method comprises the following steps:
the management center transmits the management command to a local hypervisor corresponding to the cloud platform where the target virtual machine is located;
and the local Open vSwitch in the target virtual machine acquires the management command received by the local hypervisor through a local agent, and transmits the management command to a local corresponding container so as to perform corresponding service management on the container by using the management command.
Preferably, when the management command is a data write command, the process of performing corresponding service management on the container by using the management command includes:
and writing the service data corresponding to the data writing command into the storage equipment corresponding to the container through the container.
Preferably, in the process of writing, by the container, the service data corresponding to the data write command into the local storage device corresponding to the container, the method further includes:
and migrating the service data corresponding to the data writing command to a storage device corresponding to a preset remote container.
Preferably, the migrating the service data corresponding to the data write command to the storage device corresponding to the preset remote container includes:
and migrating the service data corresponding to the data writing command to the storage equipment corresponding to the preset remote container by using an asynchronous replication technology.
Preferably, the business cross-cloud architecture management method further includes:
and periodically sending heartbeat information and event information to the management center by using a local agent of any virtual machine in the service cross-cloud architecture, and managing the life cycle of a container corresponding to the local agent.
Preferably, the event information includes:
network topology change information, and/or state change of a container corresponding to the local agent, and/or state change of a virtual machine where the local agent is located;
the process of managing the lifecycle of the container corresponding to the home agent includes:
and managing the life cycle of the container corresponding to the local agent according to a parameter setting rule from the local agent and/or a management command sent by the management center.
Preferably, before the management center transmits the management command to the local hypervisor corresponding to the cloud platform where the target virtual machine is located, the method further includes:
and the management center issues a management command according to the event information.
Preferably, before the management center transmits the management command to the local hypervisor corresponding to the cloud platform where the target virtual machine is located, the method further includes:
and the management center issues a management command according to the client instruction.
In the invention, a service cross-cloud architecture comprises a management center, virtual machines on different cloud platforms and a plurality of hypervisors which are distributed on each cloud platform and correspond to each other one by one; a plurality of hypervisors are connected with each other; an agent in each virtual machine is connected with a local Open vSwitch and a hypervisor where the virtual machine is located, and the local Open vSwitch is connected with a container in the virtual machine; when the management center transmits the management command, the management command is sequentially sent to the local corresponding container through the local hypervisor, the local agent and the local Open vSwitch of the target virtual machine. Through the management center, unified deployment and management among different cloud platforms can be achieved, and scheduling of services among cross-cloud resource pools is achieved. Because the invention is based on virtual network configuration, physical equipment does not need to be rented to different cloud platforms, and a container and an Open vSwitch are applied, bottom layer coverage is realized on the cloud platform, a service network is isolated from the bottom layer cloud platform, and specific design and development do not need to be made aiming at the framework, the principle and the specific implementation mode of the bottom layer cloud platform, so that deep cooperation among manufacturers of different cloud platforms is not needed, and therefore, the service cross-cloud architecture can directly realize unified management among different cloud platforms, and the difficulty of service cross-cloud is reduced.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
FIG. 1 is a schematic structural diagram of a business cross-cloud architecture;
fig. 2 is a schematic diagram of a tunnel termination point in an overlay service network;
FIG. 3 is a flow chart of steps of a business cross-cloud architecture creation method;
FIG. 4 is a flow chart of steps of a method for cross-cloud architecture management of services;
fig. 5 is a flowchart illustrating steps of a specific service cross-cloud-architecture management method.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The embodiment of the invention discloses a service cross-cloud architecture, which comprises a management center, virtual machines respectively positioned on different cloud platforms and a plurality of hypervisors respectively corresponding to the cloud platforms one by one; each virtual machine includes a container, an Open vSwitch and an agent.
The specific distribution may be as shown in fig. 1, where the local and remote nodes refer to different cloud platforms, and they are named according to the relative positions. In addition, the dashed line between the management center and the agent in the figure is not used to represent an actual data communication link, but is used to represent a correspondence relationship between the management center and the agent in the control management plane.
In this embodiment, the cloud platform on the service cross-cloud architecture may include any one or more of a public cloud, a private cloud, and a hybrid cloud, for example, the cloud platforms corresponding to the local may all be private clouds, and the cloud platform corresponding to the remote may be a public cloud or a hybrid cloud, so that the user may access the remote public cloud and/or the hybrid cloud through the local private cloud. Certainly, the cloud platforms corresponding to the local region may be public clouds, and the cloud platform corresponding to the remote region may be a public cloud or a mixed cloud, so that the user may access the public clouds and/or the mixed clouds in other regions through the public clouds in the region. Further, the cloud platform corresponding to the local region may include a private cloud or a public cloud, and the cloud platform corresponding to the remote region may be a public cloud or a hybrid cloud.
In addition, the embodiment is to deploy and manage services between different cloud platforms. In order to implement centralized management on services located on different cloud platforms, the management center of this embodiment may be a management center deployed in a single point, that is, only one management center is set in the whole service cross-cloud architecture, and the management center is used to perform unified management on all cloud platforms in the whole service cross-cloud architecture, which is beneficial to reducing hardware cost and facilitating implementation of service data sharing among different cloud platforms.
It should be noted that, in the case that the traffic on all the cloud platforms in the service cross-cloud architecture is not too much, the foregoing centralized management method may be preferentially adopted to perform service management on different cloud platforms, but in the case that the traffic on all the cloud platforms in the service cross-cloud architecture is very large, in order to reduce the load of the management center and avoid causing the downtime of the management center, a management center cluster including 2 or more than 2 management centers may also be set in the entire service cross-cloud architecture in this embodiment. In order to improve the rationality of the location area where the management center is located and reduce communication delay caused by a long communication link, in this embodiment, before the management center cluster is installed, all cloud platforms in a service cross-cloud architecture are classified according to geographical location information to obtain multiple types of cloud platforms, wherein all cloud platforms in each type of cloud platform are closer in geographical location and different types of cloud platforms are farther in geographical location, and after the multiple types of cloud platforms are obtained, corresponding management centers are respectively allocated to each type of cloud platform, so that a corresponding management center cluster is formed. Further, different management centers in the management center cluster of this embodiment may also communicate with each other.
It should be noted that the management center may be located on an independent physical device, and of course, in order to reduce hardware cost, the management center in this embodiment may also be located on a virtual machine or a container in the cloud platform.
It is understood that for any cloud platform, which corresponds to only one hypervisor, the cloud platform includes one or more virtual machines; each virtual machine includes one or more containers, an Open vSwitch, and an agent. As can be seen from the above, each virtual machine in this embodiment may include one or more containers, which is equivalent to deploying each virtual machine into a micro container cloud, so as to implement a layer of overlay on a cloud platform, thereby achieving an effect of decoupling a service network of a customer from an underlying cloud platform, and facilitating subsequent cross-cloud deployment of services.
Further, in order to implement operations such as service migration between different cloud platforms, the service cross-cloud architecture in this embodiment needs to establish a communication connection between hypervisors corresponding to different cloud platforms in advance. The communication connection mode may be a wired connection, such as a fiber optic cable, or a wireless connection.
The management center transmits the management command to a local hypervisor corresponding to the cloud platform where the target virtual machine is located; and the local Open vSwitch in the target virtual machine acquires the management command received by the local hypervisor through a local agent, and transmits the management command to a local corresponding container so as to perform corresponding service management on the container by using the management command.
In this embodiment, when the entire service is provided with a management center cluster including a plurality of management centers across a cloud architecture, if service management needs to be performed on a container in a target virtual machine, a management center corresponding to a cloud platform where the target virtual machine is located transmits a corresponding management command to a local hypervisor corresponding to the cloud platform, and then a local Open vSwitch in the target virtual machine obtains the management command received by the local hypervisor through a local agent, and transmits the management command to a local corresponding container, so as to perform corresponding service management on the container by using the management command.
It can be understood that, in the process that the local Open vSwitch in the target virtual machine obtains the management command received by the local hypervisor through the local agent, a transmission path of the management command is transmitted to the local Open vSwitch through a gateway device, such as vSwitch/vrouter, in the local hypervisor through the local agent.
It should be noted that, in this embodiment, the Open vSwitch switch has multiple functions, which specifically include: and the destination node of the tunnel in the overlay service network is realized, and the tunnel is responsible for communication among the internal containers of the virtual machines and forms a distributed firewall.
In this embodiment, a principle of implementing a tunnel termination point in an overlay service network is shown in fig. 2, an IP outside a virtual machine pair is an IP of the tunnel termination point, an IP of a container is unrelated to an IP of the tunnel termination point, the IP of the container is encapsulated in a load of a tunnel data packet, and a gateway device in a hypervisor cannot sense the IP of the container, thereby implementing an overlay of the service network. In addition, the IP of the container in two different cloud platforms may be under the same two-layer network, or may be different IP segments across three-layer networks.
It will be appreciated that the Open vSwitch is used here, rather than the linux bridge, because the Open vSwitch is more functional than the linux bridge and has comparable performance to the linux bridge. In addition, the linux bridge needs to combine the iptable to realize the firewall function, and the Open vSwitch can realize the firewall function. In addition, in the conventional method, the Open vSwitch is deployed in the hypervisor, but because the hypervisor of the local cloud platform is controlled by a local manufacturer, the Open vSwitch can be deployed on the hypervisor of the remote cloud platform, and the hypervisor of the remote cloud platform is generally controlled by other manufacturers, the local manufacturer cannot deploy the Open vSwitch randomly on the hypervisor, so that overlay tunnels cannot be built on the local and remote ends, and a local and remote large two-layer overlay cannot be formed. In this embodiment, since the Open vswitch is moved up to the virtual machine, a layer of tunnel packet header is added to the packet, so as to increase the length of the packet, thereby causing the Maximum length of the packet to be increased, and in order to adapt to such a change, an MTU value (MTU, Maximum Transmission Unit) that the vswitch/vrutter of the hypervisor layer can support in this embodiment is greater than 1500B.
In the invention, a service cross-cloud architecture comprises a management center, virtual machines on different cloud platforms and a plurality of hypervisors which are distributed on each cloud platform and correspond to each other one by one; a plurality of hypervisors are connected with each other; an agent in each virtual machine is connected with a local Open vSwitch and a hypervisor where the virtual machine is located, and the local Open vSwitch is connected with a container in the virtual machine; when the management center transmits the management command, the management command is sequentially sent to the local corresponding container through the local hypervisor, the local agent and the local Open vSwitch of the target virtual machine. Through the management center, unified deployment and management among different cloud platforms can be achieved, and scheduling of services among cross-cloud resource pools is achieved. Because the invention is based on virtual network configuration, physical equipment does not need to be rented to different cloud platforms, and a container and an Open vSwitch are applied, bottom layer coverage is realized on the cloud platform, a service network is isolated from the bottom layer cloud platform, and specific design and development do not need to be made aiming at the framework, the principle and the specific implementation mode of the bottom layer cloud platform, so that deep cooperation among manufacturers of different cloud platforms is not needed, and therefore, the service cross-cloud architecture can directly realize unified management among different cloud platforms, and the difficulty of service cross-cloud is reduced.
Correspondingly, the embodiment of the invention discloses a business cross-cloud architecture creating method, which is used for creating the business cross-cloud architecture; referring to fig. 3, the method includes:
s11: setting a management center;
in order to implement centralized management on services located on different cloud platforms, the management center of this embodiment may be a management center deployed in a single point, that is, only one management center is set in the whole service cross-cloud architecture, and the management center is used to perform unified management on all cloud platforms in the whole service cross-cloud architecture, which is beneficial to reducing hardware cost and facilitating implementation of service data sharing among different cloud platforms.
It should be noted that, in the case that the traffic on all the cloud platforms in the service cross-cloud architecture is not too much, the foregoing centralized management method may be preferentially adopted to perform service management on different cloud platforms, but in the case that the traffic on all the cloud platforms in the service cross-cloud architecture is very large, in order to reduce the load of the management center and avoid causing the downtime of the management center, a management center cluster including 2 or more than 2 management centers may also be set in the entire service cross-cloud architecture in this embodiment. In order to improve the rationality of the location area where the management center is located and reduce communication delay caused by a long communication link, in this embodiment, before the management center cluster is installed, all cloud platforms in a service cross-cloud architecture are classified according to geographical location information to obtain multiple types of cloud platforms, wherein all cloud platforms in each type of cloud platform are closer in geographical location and different types of cloud platforms are farther in geographical location, and after the multiple types of cloud platforms are obtained, corresponding management centers are respectively allocated to each type of cloud platform, so that a corresponding management center cluster is formed. Further, different management centers in the management center cluster of this embodiment may also communicate with each other.
It should be noted that the management center may be located on an independent physical device, and of course, in order to reduce hardware cost, the management center in this embodiment may also be located on a virtual machine or a container in the cloud platform.
S12: establishing communication connection between hypervisors corresponding to different cloud platforms;
in this embodiment, communication connection is established between hypervisors corresponding to different cloud platforms, so that interaction between the different cloud platforms is facilitated, and a foundation is laid for migration of subsequent services between the different cloud platforms.
S13: configuring each virtual machine in the service cross-cloud architecture through the management center;
in this embodiment, when the entire service is provided with a management center cluster including a plurality of management centers across a cloud architecture, if any virtual machine needs to be configured, the virtual machine may be configured through the management center corresponding to the cloud platform where the virtual machine is located.
The process of configuring any virtual machine by the management center comprises the following steps:
s131: starting the virtual machine, installing an agent in the virtual machine, and configuring the agent to obtain a configured agent;
in this embodiment, starting the virtual machine and the installation agent are both implemented by invoking an API (Application Programming Interface) Interface in the cloud platform. The APIs mentioned here are some common APIs, and are provided by general cloud platform products.
Further, the process of configuring the agent in step S131 may specifically include configuring an IP address of the management center for the agent. That is, the present embodiment configures an IP address of a corresponding management center for an agent in each virtual machine, thereby enabling communication between different management centers and corresponding agents.
S132: and installing an Open vSwitch and a container in the virtual machine by using the configured agent, and then configuring the Open vSwitch.
Further, the process of configuring the Open vSwitch may specifically include: forwarding configuration, configuring access control policy of firewall, configuring IP address of corresponding container and encapsulating the IP address in the Open vSwitch. That is, when the Open vSwitch is configured, the embodiment mainly configures a corresponding forwarding rule and a firewall access control rule for the Open vSwitch, and based on the configured forwarding rule and the firewall access control rule, the ordered restriction on the communication of the Open vSwitch can be realized, so that communication confusion is avoided.
In this embodiment, in order to reduce the security vulnerability risk of the system, the access control policy of the firewall may be set as a multi-layer access control rule, which significantly improves the security compared to a single-layer access control rule, and certainly, in order to avoid an excessively complicated access control process, the number of layers of the multi-layer access control rule is not too large, and the multi-layer access control policy is usually set as a 2-layer, 3-layer or 4-layer access control rule.
Correspondingly, the embodiment of the invention discloses a business cross-cloud architecture management method, which is applied to the business cross-cloud architecture; referring to fig. 4, the method includes:
s21: the management center transmits the management command to a local hypervisor corresponding to the cloud platform where the target virtual machine is located;
the management command in this embodiment is issued by the management center to the target virtual machine according to the instruction of the client and/or the collected event information. Here, the event information is sent by the agent.
S22: and the local Open vSwitch in the target virtual machine acquires the management command received by the local hypervisor through a local agent, and transmits the management command to a local corresponding container so as to perform corresponding service management on the container by using the management command.
In this embodiment, when the entire service is provided with a management center cluster including a plurality of management centers across a cloud architecture, if service management needs to be performed on a container in a target virtual machine, a management center corresponding to a cloud platform where the target virtual machine is located transmits a corresponding management command to a local hypervisor corresponding to the cloud platform, and then a local Open vSwitch in the target virtual machine obtains the management command received by the local hypervisor through a local agent, and transmits the management command to a local corresponding container, so as to perform corresponding service management on the container by using the management command.
Further, in order to ensure that the local agent can timely know whether the management center is working normally, so as to prevent the local agent from being in a situation of passive waiting for a long time, the service may periodically send heartbeat information and event information to the management center across the local agent of any virtual machine in the cloud architecture. Further, in this embodiment, the home agent of any virtual machine may also manage a life cycle of the container corresponding to the home agent.
In this embodiment, the event information may specifically include: network topology change information, and/or state change of a container corresponding to the local agent, and/or state change of a virtual machine where the local agent is located, and the like. The local agent sends the event information to the corresponding management center, so that the management center can timely acquire the change condition of the local network topology, the change condition of the container and the change condition of the virtual machine, and the management center can timely trigger corresponding management operation according to the change conditions of different objects.
Further, in order to enable the local proxy to manage the life cycle of the local container, in this embodiment, a corresponding parameter setting rule may be configured in the local proxy in advance, and the subsequent local proxy may manage the life cycle of the container corresponding to the local proxy according to the parameter setting rule. Of course, considering that once the parameter setting rule is set, the management manner of the container lifecycle by the home agent is also fixed accordingly, which is inconvenient for flexible adjustment in the later period, for this reason, the home agent in this embodiment may also manage the lifecycle of the container corresponding to the home agent according to the management command sent by the management center. The specific content of the management command sent by the management center can be changed in real time, so that the life cycle of the local container can be flexibly managed through the local agent.
The embodiment of the invention discloses a specific service cross-cloud architecture management method, and compared with the previous embodiment, the embodiment further explains and optimizes the technical scheme. Referring to fig. 5, specifically:
s31: the management center transmits the management command to a local hypervisor corresponding to the cloud platform where the target virtual machine is located;
the management command here is a data write command. The management commands may also include other commands with which the corresponding containers are managed accordingly.
S32: the local Open vSwitch in the target virtual machine acquires the management command received by the local hypervisor through a local agent, and transmits the management command to a local corresponding container;
s33: and writing the service data corresponding to the data writing command into the storage equipment corresponding to the container through the container.
Further, step S34 described below may be included.
S34: and migrating the service data corresponding to the data writing command to a storage device corresponding to a preset remote container.
It can be understood that, by using the asynchronous replication technology, the interface of the storage device corresponding to the preset remote container is called, and the data is synchronized to the remote storage device.
In this embodiment, in addition to directly writing the service data into the storage device and backing up the service data at the remote end, service migration can be performed between different cloud platforms. After receiving the migration command in the configured cross-cloud architecture, starting a corresponding migration container, updating the service data to be migrated, the session and the state information of the corresponding migration container into a corresponding storage device of the migration container and a local Open vSwitch, and finally updating the configuration of the corresponding Open vSwitch at a migration point and stopping the migration container, thereby completing the migration process.
Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
The service cross-cloud architecture, the creation method thereof and the management method thereof provided by the invention are described in detail, specific examples are applied in the description to explain the principle and the implementation mode of the invention, and the description of the embodiments is only used for helping to understand the method and the core idea thereof; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention.
Claims (14)
1. A service cross-cloud system is characterized by comprising a management center, virtual machines respectively positioned on different cloud platforms and a plurality of hypervisors respectively corresponding to the cloud platforms one by one; each virtual machine comprises a container, an Open vSwitch and an agent; wherein the content of the first and second substances,
establishing communication connection between hypervisors corresponding to different cloud platforms in advance;
the management center is used for transmitting the management command to a local hypervisor corresponding to the cloud platform where the target virtual machine is located;
the local Open vSwitch in the target virtual machine acquires the management command received by the local hypervisor through a local agent, and transmits the management command to a local corresponding container so as to perform corresponding service management on the container by using the management command;
the Open vSwitch is also responsible for communication between internal containers of the local virtual machines and a termination point of a tunnel in an overlay service network.
2. The business cross-cloud system of claim 1, comprising a management center cluster of N said management centers; wherein N is an integer not less than 2.
3. The business cross-cloud system of claim 1 or 2, wherein the management center is located in a separate physical device or virtual machine or container.
4. A method for creating a service cross-cloud system, for creating a service cross-cloud system according to any one of claims 1 to 3; the method comprises the following steps:
setting a management center;
establishing communication connection between hypervisors corresponding to different cloud platforms;
configuring each virtual machine in the service cross-cloud system through the management center;
the process of configuring any virtual machine by the management center comprises the following steps: starting the virtual machine, installing an agent in the virtual machine, configuring the agent to obtain a configured agent, installing an Open vSwitch and a container in the virtual machine by using the configured agent, and configuring the Open vSwitch.
5. The method of claim 4,
the process of configuring the agent includes: configuring the IP address of the management center for the agent;
the process of configuring the Open vSwitch includes: forwarding configuration, configuring access control policy of firewall, configuring IP address of corresponding container and encapsulating the IP address in the Open vSwitch.
6. The method of claim 5, wherein the configuring the access control policy of the firewall comprises:
and configuring an access control strategy of the distributed firewall, wherein the access control strategy is an access control rule of N layers, and N is more than or equal to 2 and less than or equal to 4.
7. A method for managing a business cross-cloud system, which is applied to the business cross-cloud system according to any one of claims 1 to 3; wherein the method comprises the following steps:
the management center transmits the management command to a local hypervisor corresponding to the cloud platform where the target virtual machine is located;
and the local Open vSwitch in the target virtual machine acquires the management command received by the local hypervisor through a local agent, and transmits the management command to a local corresponding container so as to perform corresponding service management on the container by using the management command.
8. The method of claim 7,
when the management command is a data write command, the process of performing corresponding service management on the container by using the management command includes:
and writing the service data corresponding to the data writing command into the storage equipment corresponding to the container through the container.
9. The method according to claim 8, wherein in the process of writing the service data corresponding to the data write command into the local storage device corresponding to the container through the container, the method further comprises:
and migrating the service data corresponding to the data writing command to a storage device corresponding to a preset remote container.
10. The method according to claim 9, wherein the migrating the service data corresponding to the data write command to the storage device corresponding to the preset remote container includes:
and migrating the service data corresponding to the data writing command to the storage equipment corresponding to the preset remote container by using an asynchronous replication technology.
11. The method of claim 7, further comprising:
and periodically sending heartbeat information and event information to the management center by using the local agent of any virtual machine in the service cross-cloud system, and managing the life cycle of the container corresponding to the local agent.
12. The method of claim 11,
the event information includes:
network topology change information, and/or state change of a container corresponding to the local agent, and/or state change of a virtual machine where the local agent is located;
the process of managing the lifecycle of the container corresponding to the home agent includes:
and managing the life cycle of the container corresponding to the local agent according to a parameter setting rule from the local agent and/or a management command sent by the management center.
13. The method according to claim 11 or 12,
before the management center transmits the management command to the local hypervisor corresponding to the cloud platform where the target virtual machine is located, the method further includes:
and the management center issues a management command according to the event information.
14. The method according to any one of claims 7 to 12,
before the management center transmits the management command to the local hypervisor corresponding to the cloud platform where the target virtual machine is located, the method further includes:
and the management center issues a management command according to the client instruction.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711209025.2A CN107911463B (en) | 2017-11-27 | 2017-11-27 | Business cross-cloud architecture and creation method and management method thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711209025.2A CN107911463B (en) | 2017-11-27 | 2017-11-27 | Business cross-cloud architecture and creation method and management method thereof |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107911463A CN107911463A (en) | 2018-04-13 |
| CN107911463B true CN107911463B (en) | 2021-01-19 |
Family
ID=61848004
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711209025.2A Active CN107911463B (en) | 2017-11-27 | 2017-11-27 | Business cross-cloud architecture and creation method and management method thereof |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107911463B (en) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109445869B (en) * | 2018-09-17 | 2021-11-02 | 山东中创软件商用中间件股份有限公司 | Cross-cloud-adaptive micro-service management method and device and storage medium |
| CN109711795A (en) * | 2018-11-01 | 2019-05-03 | 佛山小易简科技有限公司 | A kind of construction method and system of cloudy collaborative platform |
| CN111130973B (en) * | 2018-11-01 | 2021-09-17 | 深信服科技股份有限公司 | Heterogeneous cloud network intercommunication system and method |
| CN111130974B (en) * | 2018-11-01 | 2022-01-18 | 深信服科技股份有限公司 | Network intercommunication system and method based on multi-cloud environment |
| CN111124659B (en) * | 2018-11-01 | 2023-03-17 | 深信服科技股份有限公司 | Heterogeneous cloud network intercommunication system and method |
| CN111130975B (en) * | 2018-11-01 | 2022-01-18 | 深信服科技股份有限公司 | Hybrid cloud network intercommunication system and method |
| CN111225071B (en) * | 2018-11-23 | 2022-11-22 | 深信服科技股份有限公司 | Cloud platform and cross-cloud platform network intercommunication system and method |
| CN109901922B (en) * | 2019-03-05 | 2021-06-18 | 北京工业大学 | Container cloud resource scheduling optimization method for multi-layer service |
| CN110209498B (en) * | 2019-05-30 | 2021-06-18 | 浙江运达风电股份有限公司 | Cross-available-area resource scheduling method based on private cloud |
| CN111404801B (en) * | 2020-03-27 | 2021-09-28 | 四川虹美智能科技有限公司 | Data processing method, device and system for cross-cloud manufacturer |
| CN111597013A (en) * | 2020-05-20 | 2020-08-28 | 山东汇贸电子口岸有限公司 | Method for building large-scale virtual data center by using containers |
| CN113452592B (en) * | 2021-06-09 | 2022-02-25 | 北京奥星贝斯科技有限公司 | Cross-cloud data access method and device under hybrid cloud architecture |
| CN113656152B (en) * | 2021-08-24 | 2023-07-21 | 上海道客网络科技有限公司 | Local simulation method, system, medium and electronic equipment based on container cloud environment |
| CN114679429B (en) * | 2022-03-29 | 2023-02-03 | 深圳信息职业技术学院 | Service cross-region response method based on multi-cloud container platform |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103092670A (en) * | 2011-11-02 | 2013-05-08 | 佳都新太科技股份有限公司 | Cross-platform virtual computing resource management method under cloud computing environment |
| US9906454B2 (en) * | 2014-09-17 | 2018-02-27 | AppFormix, Inc. | System and method for providing quality of service to data center applications by controlling the rate at which data packets are transmitted |
| CN104468746A (en) * | 2014-11-23 | 2015-03-25 | 国云科技股份有限公司 | Method for realizing distributed virtual networks applicable to cloud platform |
| CN105245373B (en) * | 2015-10-12 | 2017-08-04 | 天津市普迅电力信息技术有限公司 | A kind of container cloud platform system is built and operation method |
| CN108111383B (en) * | 2017-12-26 | 2021-03-19 | 北京航空航天大学 | SDN-based cross-domain container virtual network construction method |
-
2017
- 2017-11-27 CN CN201711209025.2A patent/CN107911463B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN107911463A (en) | 2018-04-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107911463B (en) | Business cross-cloud architecture and creation method and management method thereof | |
| US11665053B2 (en) | Initializing network device and server configurations in a data center | |
| US9137105B2 (en) | Method and system for deploying at least one virtual network on the fly and on demand | |
| EP3422642B1 (en) | Vlan tagging in a virtual environment | |
| RU2382398C2 (en) | Generation of virtual network topology | |
| CN109194502B (en) | Management method of multi-tenant container cloud computing system | |
| CN103930873B (en) | The configuration of the interface based on dynamic strategy for virtualized environment | |
| EP2586160B1 (en) | Distributed virtual network gateways | |
| CN107896191B (en) | Container-based virtual security component cross-cloud system and method | |
| CN106464528B (en) | For the contactless method allocated, medium and the device in communication network | |
| US20140068045A1 (en) | Network system and virtual node migration method | |
| CN106487556B (en) | Service function SF deployment method and device | |
| CN105429938B (en) | Resource allocation method and device | |
| CN102412978A (en) | Method for carrying out network configuration for VM and system thereof | |
| US20130297752A1 (en) | Provisioning network segments based on tenant identity | |
| WO2015172362A1 (en) | Network function virtualization network system, data processing method and device | |
| CN104205757A (en) | Distributed virtual switch architecture for a hybrid cloud | |
| CN103607430A (en) | Network processing method and system, and network control center | |
| CN104584484A (en) | System and method providing policy based data center network automation | |
| CN109587286A (en) | A kind of equipment connection control method and device | |
| WO2017114363A1 (en) | Packet processing method, bng and bng cluster system | |
| CN111064649A (en) | Method and device for realizing binding of layered ports, control equipment and storage medium | |
| CN109445912A (en) | A kind of configuration method of virtual machine, configuration system and SDN controller | |
| CN112602292B (en) | Inter-slice sharing in a 5G core network | |
| CN105227541A (en) | A kind of security strategy dynamic migration method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |