Communication method and system for converting on-cloud unicast to under-cloud multicast, and storage medium
By deploying multiple multicast gateways and load balancers, and combining them with the VRRP protocol to monitor health status, high availability of cloud unicast to on-premises multicast communication was achieved, solving the problem of low communication availability in existing technologies.
Patent Information
- Application Number
- CN202510931179.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-07
- Publication Date
- 2025-11-04
AI Technical Summary
The availability of cloud-based unicast to on-premises multicast communication is low and prone to failure and unavailability.
Deploy at least two multicast gateways, each communicating with the switch via an SRIOV network interface card. Use load balancing and VRRP protocols to monitor the health status of the gateways and switches. When an anomaly occurs, switch unicast traffic to the normal multicast gateway to form a virtual switch to improve availability.
When the multicast gateway, SRIOV network card, or switch fails, it can forward unicast traffic from the cloud to multicast traffic on the ground, significantly improving the availability of communication.
Smart Images

Figure CN120896838A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of data distribution, in particular to a communication method for converting cloud-side unicast to cloud-side multicast, a device and a storage medium. BACKGROUND
[0002] Multicast is a network communication technology that allows a multicast source to send the same message to multiple recipients, which is mainly used in the fields of video and audio broadcasting, financial data distribution, online gaming, etc.
[0003] In order to achieve flexibility, scalability and reliability of services, many large enterprises gradually migrate services deployed on physical servers to virtual machines in the cloud. It takes a certain amount of time to complete all service migrations, and during this process, there is a need for communication between cloud-side virtual machines and cloud-side physical servers, including cloud-side unicast to cloud-side multicast communication, specifically: For multicast communication, a large amount of performance of cloud-side virtual switches is consumed in the process of multicasting replicated messages, so as shown in Figure 1 Cloud-side virtual machines and cloud-side physical servers usually use a multicast gateway to implement multicast communication, which is configured with two network cards: one cloud-side virtual card connected to a cloud-side virtual switch (unicast communication with cloud-side virtual machines is allowed); and one SR-IOV physical network card (Single Root I / O Virtualization, a network interface card that supports hardware-assisted virtualization), which allows a single physical network card to be directly shared by multiple virtual machines in a virtualized environment) directly connected to a cloud-side switch (multicast communication with cloud-side physical servers is allowed).
[0004] When a cloud-side virtual machine needs to communicate with a cloud-side server via multicast, a unicast-to-multicast mapping rule is first configured in the multicast gateway, for example Figure 1 In the example, the multicast gateway listens to the UDP protocol 8000 port (multicast services are transmitted using the UDP protocol), and forwards unicast traffic to the multicast IP address 239.1.1.1 (i.e., when the multicast gateway receives unicast traffic from the cloud-side virtual machine with the UDP protocol port number 8000, it processes the traffic and maps it to multicast traffic with the multicast IP address 239.1.1.1, which is sent to the cloud-side physical server via the SRIOV network card).
[0005] Of course, there are many other use cases for the above cloud-side unicast to cloud-side multicast communication, which are not limited to service migration.
[0006] However, according to the use results, the current cloud-side unicast to cloud-side multicast communication method has low availability, i.e., it is prone to failure and is not available. SUMMARY
[0007] In view of the defects in the prior art, the technical problem solved by the application is: how to improve the availability when unicasting on the cloud is converted to multicasting under the cloud, and a method is provided.
[0008] To achieve the above object, in a first aspect, the embodiments of the application provide a communication method for unicasting on the cloud to multicasting under the cloud, which comprises the following steps: At least two multicast gateways are deployed, each of which communicates with a switch through an SRIOV network card, and the switch communicates with a terminal under the cloud. When an abnormal multicast gateway is monitored, the unicast traffic of the abnormal multicast gateway is sent to a normal multicast gateway; the multicast gateway abnormality includes: multicast gateway failure or communication link interruption between the SRIOV network card of the multicast gateway and the switch.
[0009] In combination with the first aspect, in an implementation mode, the process of distributing unicast traffic to each multicast gateway comprises: distributing unicast traffic to each multicast gateway in a load balancing manner.
[0010] In combination with the first aspect, in an implementation mode, the process of determining multicast gateway failure comprises: sending a multicast gateway health check message to the multicast gateway and obtaining a multicast gateway response message; determining the multicast gateway that does not receive the multicast gateway response message as a failed multicast gateway, and determining the multicast gateway that receives the multicast gateway response message as a normal multicast gateway.
[0011] In combination with the first aspect, in an implementation mode, the process of determining communication link interruption between the SRIOV network card of the multicast gateway and the switch comprises: the multicast gateway sends a switch health check message to the switch communicating therewith through the SRIOV network card, and obtains a switch response message; when the switch response message is not received, it is determined that the communication link between the SRIOV network card and the switch is interrupted; when the switch response message is received, it is determined that the communication link between the SRIOV network card and the switch is not interrupted.
[0012] In combination with the first aspect, in an implementation mode, the process of sending unicast traffic of an abnormal multicast gateway to a normal multicast gateway comprises: the multicast gateway with communication link interruption between the SRIOV network card and the switch refuses to reply the multicast gateway response message.
[0013] In combination with the first aspect, in an implementation mode, the method further comprises the following steps: forming a virtual switch for each multicast gateway communicating switch.
[0014] In combination with the first aspect, in an implementation, the process of forming the virtual switch by the switches in communication with the multicast gateways comprises: configuring each switch to be stacked, and configuring a VRRP on the interface of the network card of the switch in communication with the multicast gateway.
[0015] In combination with the first aspect, in an implementation, the process of communication between the multicast gateway and the virtual switch comprises: selecting one switch as the master switch by the virtual switch according to the VRRP, and configuring a virtual IP address; For the multicast gateway directly connected with the master switch, the information sent by the multicast gateway directly reaches the master switch. For the multicast gateway not directly connected with the master switch, the information sent by the multicast gateway first reaches the switch directly connected with the multicast gateway, and then reaches the master switch through the interconnection line stacked between the standby switch and the master switch. When the master switch fails, the interconnection line stacked between the master switch and the standby switch is interrupted, and the virtual switch reselects one switch as the new master switch according to the VRRP.
[0016] In the second aspect, the embodiments of the present application provide a communication system for converting unicast on cloud to multicast on cloud, which comprises a load balancer and at least two multicast gateways; the load balancer is in communication with each multicast gateway respectively, each multicast gateway is in communication with one switch through an SRIOV network card, and all the switches form the virtual switch according to any one of claims 6 to 8. The load balancer is used for: distributing unicast traffic to each multicast gateway; sending a multicast gateway health check message to each multicast gateway, and requesting a reply of a multicast gateway reply message from the multicast gateway; determining the multicast gateway receiving the multicast gateway reply message as a normal multicast gateway, and determining the multicast gateway not receiving the multicast gateway reply message as an abnormal multicast gateway; and sending the unicast traffic of the abnormal multicast gateway to the normal multicast gateway; The multicast gateway is used for: sending multicast traffic to the switch through the SRIOV network card; sending a switch health check message to the switch in communication with the multicast gateway through the SRIOV network card, and requesting a reply of a switch reply message; when the switch reply message is received, determining that the communication link between the SRIOV network card and the switch is not interrupted; and when the switch reply message is not received, determining that the communication link between the SRIOV network card and the switch is interrupted; replying the multicast gateway reply message to the load balancer, and refusing to reply the multicast gateway health check message when the communication link between the SRIOV network card and the switch is interrupted; The virtual switch is used for: sending multicast traffic to the under-cloud terminal; The communication process of the multicast gateway and the virtual switch according to claim 8, and the multicast gateway.
[0017] In a third aspect, the embodiments of the present application provide a computer readable storage medium, and the storage medium stores a communication program for converting cloud-side unicast to under-cloud multicast, and the computer program is executed to implement the method in the first aspect.
[0018] Compared with the prior art, the present application has the following advantages: The present application is provided with multiple multicast gateways, when the multicast gateway is abnormal, the unicast traffic of the cloud-side virtual machine can be forwarded to other normal multicast gateways; the abnormal conditions of the multicast gateway include the failure of the multicast gateway, or the communication link interruption between the SRIOV network card of the multicast gateway and the switch (the communication link interruption represents the failure of the SRIOV network card or the switch).
[0019] Therefore, compared with the single multicast gateway in the prior art, the present application can normally convert the cloud-side unicast traffic to the under-cloud multicast traffic when the multicast gateway, the SRIOV network card or the switch fails, and the availability is significantly improved. BRIEF DESCRIPTION OF DRAWINGS
[0020] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.
[0021] Figure 1 The working principle diagram of the communication system for converting cloud-side unicast to under-cloud multicast in the prior art; Fig. 2 is a working principle diagram of the communication system for converting cloud-side unicast to under-cloud multicast in the embodiments of the present application; Figure 3 The flowchart of the health check of the communication system for converting cloud-side unicast to under-cloud multicast in the embodiments of the present application; Figure 4 The flowchart of the communication between the multicast gateway and the virtual switch in the embodiments of the present application. DETAILED DESCRIPTION
[0022] To make the purposes, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.
[0023] The flowchart shown in the drawings is only an example and does not necessarily include all contents and operations / steps, nor does it necessarily need to be executed in the order described. For example, some operations / steps can be further decomposed, combined, or partially merged, so the actual execution order can be changed according to actual situations.
[0024] To make the purposes, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.
[0025] The applicant has found that the reason why the availability of the existing cloud unicast-to-cloud multicast communication mode is low is as follows: (1) Single multicast gateway failure causes communication link interruption.
[0026] (2) SRIOV network card failure. Usually, a physical network card uses a Bond mode (i.e., a mode of binding multiple network cards as one logical network card) to handle single physical network card abnormalities. However, the SRIOV technology of the physical network card cannot be used simultaneously with the Bond technology, so the SRIOV network card failure will directly cause communication link interruption.
[0027] (3) Switch failure. One SRIOV network card can only be connected to one physical switch, and the switch failure directly causes communication link interruption.
[0028] Therefore, in a first aspect, the embodiments of the present application provide a cloud unicast-to-cloud multicast communication method. The steps of the method include: Figure 2 As shown in FIG. 1, at least two multicast gateways using SRIOV network cards are deployed (the specific number is set according to the actual situation, the more the number, the higher the availability, but the cost is also higher), and the cloud virtual machine distributes unicast traffic to each multicast gateway. The connection mode of the multicast gateway and the cloud device can be the same as that of the prior art, that is, each multicast gateway communicates with one switch through the SRIOV network card, and the switch communicates with the cloud terminal (physical server).
[0029] When the multicast gateway abnormality is monitored, the cloud virtual machine sends the unicast traffic of the abnormal multicast gateway to the normal multicast gateway. The multicast gateway abnormality includes multicast gateway failure or communication link interruption between the SRIOV network card of the multicast gateway and the switch.
[0030] Therefore, it can be known that the application is provided with multiple multicast gateways, when the multicast gateway is abnormal, the unicast traffic of the virtual machine on the cloud can be forwarded to other normal multicast gateways; the abnormal condition of the multicast gateway includes the multicast gateway failure or the communication link interruption between the SRIOV network card of the multicast gateway and the switch (the communication link interruption represents the SRIOV network card or the switch failure).
[0031] Therefore, compared with the single multicast gateway in the prior art, the application can normally convert the unicast traffic on the cloud to the multicast traffic under the cloud when the multicast gateway, the SRIOV network card or the switch fails, and the availability is significantly improved.
[0032] In an embodiment, the process that the virtual machine on the cloud distributes the unicast traffic to each multicast gateway includes: distributing the unicast traffic to each multicast gateway through the load balancing, and the process can be realized through the load balancer, as shown in FIG. 2.
[0033] In an embodiment, the process of determining the multicast gateway failure includes: as shown in FIG. 3, sending the multicast gateway health check message to the multicast gateway in real time and obtaining the multicast gateway response message, the health message is the ICMP (Internet Control Message Protocol) detection message; determining the multicast gateway that does not receive the multicast gateway response message as the failed multicast gateway and determining the multicast gateway that receives the multicast gateway response message as the normal multicast gateway. Figure 3
[0034] On this basis, the process that the virtual machine on the cloud sends the unicast traffic of the abnormal multicast gateway to the normal multicast gateway includes: the load balancer on the cloud forwards the unicast traffic originally sent to the failed multicast gateway to the normal multicast gateway.
[0035] Further, the process of determining the communication link interruption between the SRIOV network card of the multicast gateway and the switch includes: as shown in FIG. 5, the multicast gateway sends the switch health check message to the switch in real time through the SRIOV network card, and obtains the switch response message; when the switch response message is not received, it is determined that the communication link between the SRIOV network card and the switch is interrupted, and when the switch response message is received, it is determined that the communication link between the SRIOV network card and the switch is not interrupted. Figure 3
[0036] On this basis, the process that the virtual machine on the cloud sends the unicast traffic of the abnormal multicast gateway to the normal multicast gateway includes: the multicast gateway that the communication link between the SRIOV network card and the switch is interrupted refuses to reply the multicast gateway response message, at this time, the virtual machine on the cloud will determine that the multicast gateway is failed, and then enters the process of handling the multicast gateway failure.
[0037] In an embodiment, the method further comprises the following steps: referring to Figure 2 As shown in the figure, the switches in communication with each multicast gateway form a virtual switch, and the specific process comprises: configuring each switch to be stacked, and configuring a VRRP (Virtual Router Redundancy Protocol) on the network card interface of the switch in communication with the multicast gateway. In this way, several switches are combined to form a virtual switch device, and the IP address of the virtual switch device is used as the default gateway of the user to realize communication with the external network; when an abnormality occurs in the switch device member, the VRRP mechanism can elect a new switch device to bear the data flow, thereby ensuring reliable communication of the network.
[0038] On this basis, referring to Figure 4 As shown in the figure, the communication process of the multicast gateway and the virtual switch comprises: the virtual switch selects one switch as a master switch according to the VRRP, and configures a virtual IP address. For the multicast gateway directly connected to the master switch, the information (flow and check message) sent by the multicast gateway directly reaches the master switch. For the multicast gateway not directly connected to the master switch, the information sent by the multicast gateway first reaches the switch (i.e. the standby switch) directly connected to it, and then reaches the master switch through the interconnection line stacked between the standby switch and the master switch.
[0039] When the master switch fails, the interconnection line stacked between the master switch and the standby switch is interrupted, and the virtual switch will reselect one switch as a new master switch according to the VRRP. At this time, the information sent by the multicast gateway directly connected to the original master switch cannot reach the new master switch due to the interruption of the interconnection line, so the multicast gateway directly connected to the original master switch cannot receive the switch response message.
[0040] In a second aspect, the embodiments of the present application also provide a communication system for converting unicast on the cloud to multicast under the cloud, referring to Figure 1 As shown in the figure, the system comprises: a load balancer arranged on the cloud, at least two multicast gateways arranged on physical servers in the cloud, the load balancer being in communication with each multicast gateway, and each multicast gateway being in communication with a switch through an SRIOV network card, all the switches forming the above-mentioned virtual switch (stacked and added with VRRP).
[0041] The load balancer is used to: (1) distribute unicast flow of the virtual machine on the cloud to each multicast gateway; (2) send multicast gateway health check messages to each multicast gateway in real time, and request the multicast gateway to return multicast gateway response messages; (3) Determine the multicast gateway that receives the multicast gateway response message as the normal multicast gateway, and determine the multicast gateway that does not receive the multicast gateway response message as the abnormal multicast gateway; send the unicast traffic of the abnormal multicast gateway to the normal multicast gateway.
[0042] Multicast gateways are used for: (1) Send multicast traffic to the switch via the SRIOV network card; (2) Send switch health check messages to the switch it communicates with in real time through the SRIOV network card, and request a reply from the switch response message; (3) When a response message is received from the switch, it is determined that the communication link between the SRIOV network card and the switch is not interrupted; when no response message is received from the switch, it is determined that the communication link between the SRIOV network card and the switch is interrupted. (4) Reply to the load balancer with a multicast gateway response message. When the communication link between the SRIOV network card and the switch is interrupted, refuse to reply to the multicast gateway health check message.
[0043] Virtual switches are used for: (1) Send multicast traffic to the cloud terminal.
[0044] (2) Communicate with the multicast gateway in accordance with the above communication process between the multicast gateway and the virtual switch.
[0045] The following example, using two multicast gateway members, illustrates the specific workflow of the above system.
[0046] See Figure 2 As shown, a multicast gateway cluster is formed by deploying multicast gateway members 1 and 2 on physical services 1 and 2 in the cloud, and a cloud load balancer is configured to ensure that unicast traffic sent by virtual machines in the cloud can be evenly sent to multicast gateway members 1 and 2.
[0047] The physical network cards of physical servers 1 and 2 in the cloud are connected to switches 1 and 2 respectively. Switches 1 and 2 are configured to stack, and VRRP is configured on the direct connection ports of the physical network cards of physical servers 1 and 2 on the switches.
[0048] See Figure 3 As shown, health check 1 (ICMP probe message, which can be used to determine whether the destination IP address is reachable) is configured on the cloud load balancer to the multicast gateway member, and health check 2 is configured on the multicast gateway member to the switch virtual IP address.
[0049] Normally, the health check 1 and 2 can be passed smoothly, and the cloud load balancer sends the unicast traffic from the cloud virtual machine to each multicast gateway member, and then the multicast gateway member converts the received unicast to multicast according to the pre-configured unicast-to-multicast rule and transmits the multicast to the physical server under the cloud through the SRIOV network card.
[0050] When an abnormal situation occurs, the high-availability switching will be performed according to the following manner to ensure the multicast communication between the cloud virtual machine and the physical server under the cloud: 1. When the multicast gateway forwarding program is abnormal, the health check 1 sent by the cloud load balancer to the multicast member will fail (no response can be obtained), and the cloud load balancer considers that the multicast member whose health check 1 fails is unhealthy, and automatically switches the unicast packet originally transmitted to the unhealthy multicast gateway member to the other multicast gateway member currently in a healthy state, thereby realizing the abnormal switching of the multicast gateway traffic.
[0051] Referring to Figure 3 If the multicast gateway member 1 forwarding program is abnormal, the health check 1 sent by the load balancer to the multicast gateway member 1 fails, and the health check 1 sent to the multicast gateway member 2 is still effective, at this time, the load balancer considers that the multicast gateway member 1 is unhealthy, and the multicast gateway member 2 is healthy, so the load balancer switches the packet originally transmitted to the multicast gateway member 1 to the multicast gateway member 2, thereby completing the traffic switching under the abnormal situation of the multicast gateway forwarding.
[0052] 2. When the SRIOV network card of the multicast gateway is abnormal, the health check 2 sent by the multicast gateway member to the virtual IP address of the switch fails, and the multicast gateway member whose health check 2 fails finds that it is abnormal in connection with the switch, and automatically configures a rule to reject the health check 1 sent by the cloud load balancer to itself, so that the health check 1 fails, and when the cloud load balancer finds that the health check 1 of the member fails, it considers that the member is unhealthy, thereby switching the unicast packet originally transmitted to the member to the other multicast gateway member currently in a healthy state, thereby realizing the abnormal switching of the multicast gateway traffic.
[0053] Referring to Figure 3 If the SRIOV network card of the multicast gateway member 1 is abnormal, the health check 2 sent to the virtual IP address of the switch fails, and when the multicast gateway member 1 finds that it cannot communicate with the switch, it automatically configures a rule to reject the health check 1 sent by the cloud load balancer to itself, thereby triggering the health check 1 of itself to fail, and the load balancer considers that the multicast gateway member 1 is unhealthy, and the multicast gateway member 2 is healthy, so the load balancer switches the packet originally transmitted to the multicast gateway member 1 to the multicast gateway member 2, thereby completing the traffic switching under the abnormal situation of the SRIOV network card of the multicast gateway.
[0054] 3. Normally, according to the VRRP protocol, one switch is selected as the master switch to configure a virtual IP address, at this time, the health check 2 sent by the multicast gateway member directly connected to the master switch is directly answered by the master switch, and the health check 2 sent by the multicast gateway member directly connected to the standby switch first reaches the standby switch directly connected, and then reaches the master switch through the interconnection line of the switch stack, and is answered by the master switch.
[0055] Referring to Figure 4 If the switch 1 is the VRRP master switch, the virtual IP address is configured on the switch 1, the health check 2 sent by the multicast gateway member 1 is directly answered by the switch 1, and the health check 2 sent by the multicast gateway member 2 reaches the switch 2 and then reaches the switch 1 through the interconnection line of the switch stack, and is answered by the switch 1.
[0056] When the switch is abnormal, the interconnection line of the switch stack is interrupted, the master is reselected according to the VRRP protocol, at this time, only the health check 2 sent by the multicast gateway member directly connected to the master switch can obtain a response, the multicast gateway member that cannot obtain a response considers that the health check 2 is invalid, the multicast gateway member discovers that it is abnormal in connection with the switch, and automatically configures a rule to reject the health check 1 sent by the cloud load balancer to itself, when the cloud load balancer discovers that the health check 1 of the member is invalid, considers that the member is unhealthy, and thus switches the unicast message originally forwarded to the member to the other multicast gateway member currently in a healthy state, to realize abnormal switching of multicast gateway traffic.
[0057] Referring to Figure 4 If the switch 1 is abnormal, the interconnection line between the switches 1 and 2 is interrupted, and the switch 2 is the master switch after re-election, at this time, the switch 2 cannot answer the health check 2 sent by the multicast gateway member 1, and can answer the health check 2 sent by the multicast gateway member 2, the multicast gateway 1 discovers that it cannot be connected to the switch, and automatically configures a rule to reject the health check 1 sent by the cloud load balancer to itself, triggers the health check 1 of itself to be invalid, the load balancer considers that the multicast gateway member 1 is unhealthy, and the multicast gateway member 2 is healthy, so the load balancer switches the message originally forwarded to the multicast gateway member 1 to the multicast gateway member 2, to complete the traffic switching under the abnormal condition of the multicast gateway directly connected physical switch.
[0058] In a third aspect, the embodiments of the present application also provide a computer readable storage medium.
[0059] The computer readable storage medium of the present application stores a cloud unicast to cloud multicast communication program, wherein when the cloud unicast to cloud multicast communication program is executed by a processor, the steps of the cloud unicast to cloud multicast communication method are realized.
[0060] The method implemented when the communication procedure of converting cloud-side unicast to cloud-side groupcast is executed can refer to each embodiment of the communication method of converting cloud-side unicast to cloud-side groupcast of the present application, which will not be repeated here.
[0061] It should be noted that the above sequence numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.
[0062] The terms "comprise", "have" and "include" and any variations thereof in the specification and claims of the present application and the above drawings are intended to cover not exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but can optionally include steps or units not listed, or can optionally include other steps or units inherent to the process, method, product or device. The terms "first", "second" and "third" and the like descriptions are used to distinguish different objects, and do not represent the order or limit the types of "first", "second" and "third".
[0063] In the description of the embodiments of the present application, "exemplary", "for example", "for instance" or the like is used to represent an example, illustration or description. Any embodiment or design scheme described as "exemplary", "for example" or "for instance" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. In fact, the words "exemplary", "for example" or "for instance" are intended to present the relevant concept in a specific way.
[0064] In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in the text only describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B can mean that A exists alone, A and B exist together, and B exists alone, and in addition, "multiple" in the description of the embodiments of the present application means two or more than two.
[0065] In some flows described in the embodiments of the present application, a plurality of operations or steps are included, which appear in a specific order, but it should be understood that these operations or steps can be executed or executed in parallel without the order in which they appear in the embodiments of the present application, and the serial number of the operation is only used to distinguish different operations, and the serial number itself does not represent any execution order. In addition, these flows can include more or fewer operations, and these operations or steps can be executed in sequence or in parallel, and these operations or steps can be combined.
[0066] Through the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned example method can be realized by means of software and a necessary general hardware platform, of course, it can also be realized by hardware, but in many cases, the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a ROM / RAM, a magnetic disk, or an optical disc) as described above, and includes a plurality of instructions for causing a terminal device to execute the methods described in the various embodiments of the present application.
[0067] The above is only a specific implementation of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited thereto, and any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed by the embodiments of the present application, and these modifications or replacements should be covered within the protection scope of the embodiments of the present application. Therefore, the protection scope of the embodiments of the present application should be subject to the protection scope of the claims.
Claims
1. A communication method for converting unicast from the cloud to multicast on the ground, characterized in that, The method includes the following steps: Deploy at least two multicast gateways. Each multicast gateway communicates with one switch via an SRIOV network card. The switch communicates with the on-premises terminal. Distribute unicast traffic to each multicast gateway; when a multicast gateway malfunction is detected, send the unicast traffic of the malfunctioning multicast gateway to the normal multicast gateway; multicast gateway malfunctions include: multicast gateway failure, or interruption of the communication link between the multicast gateway's SRIOV network card and the switch.
2. The cloud-to-on-premises multicast communication method as described in claim 1, characterized in that, The process of distributing unicast traffic to each multicast gateway includes: distributing unicast traffic to each multicast gateway through load balancing.
3. The cloud-to-on-premises multicast communication method as described in claim 1, characterized in that, The process for determining multicast gateway failure includes: sending a multicast gateway health check message to the multicast gateway and obtaining a multicast gateway response message; determining multicast gateways that do not receive a multicast gateway response message as faulty multicast gateways, and determining multicast gateways that receive a multicast gateway response message as normal multicast gateways.
4. The cloud-to-on-premises multicast communication method as described in claim 1, characterized in that, The process for determining the interruption of the communication link between the multicast gateway's SRIOV network card and the switch includes: the multicast gateway sending a switch health check message to the switch it is communicating with through the SRIOV network card and obtaining a switch response message; if no switch response message is received, it is determined that the communication link between the SRIOV network card and the switch is interrupted; if a switch response message is received, it is determined that the communication link between the SRIOV network card and the switch is not interrupted.
5. The cloud-to-on-premises multicast communication method as described in claim 4, characterized in that, The process of sending unicast traffic from an abnormal multicast gateway to a normal multicast gateway includes: the multicast gateway whose communication link between the SRIOV network card and the switch is interrupted refuses to reply to the multicast gateway response message.
6. The cloud-to-on-premises multicast communication method as described in claim 1, characterized in that, The method also includes the following step: forming a virtual switch for each multicast gateway communication switch.
7. The cloud-to-on-premises multicast communication method as described in claim 6, characterized in that, The process of forming a virtual switch by communicating with each multicast gateway includes: configuring and stacking each switch, and configuring VRRP on the network card interface of the switch communicating with the multicast gateway.
8. The cloud-to-on-premises multicast communication method as described in claim 7, characterized in that, The communication process between the multicast gateway and the virtual switch includes: the virtual switch selects one switch as the master switch according to VRRP and configures a virtual IP address; For a multicast gateway that is directly connected to the main switch, the information sent by the multicast gateway directly reaches the main switch. For a multicast gateway that is not directly connected to the main switch, the information sent by the multicast gateway first reaches the switch directly connected to it, and then reaches the main switch through the interconnection lines stacked between the backup switch and the main switch. When the primary switch fails, the stacked interconnection lines between the primary and backup switches are interrupted, and the virtual switch will reselect a switch as the new primary switch according to VRRP.
9. A communication system for converting unicast from the cloud to multicast from the cloud, characterized in that: The system includes a load balancer and at least two multicast gateways; the load balancer communicates with each multicast gateway, and each multicast gateway communicates with a switch via an SRIOV network card, and all switches form a virtual switch as described in any one of claims 6 to 8. Load balancers are used for: Distribute unicast traffic evenly to each multicast gateway; Send a multicast gateway health check message to each multicast gateway and request the multicast gateway to reply with a multicast gateway response message; Multicast gateways that receive multicast gateway response messages are identified as normal multicast gateways, while multicast gateways that do not receive multicast gateway response messages are identified as abnormal multicast gateways. Send the unicast traffic of the abnormal multicast gateway to the normal multicast gateway; Multicast gateways are used for: Send multicast traffic to the switch via SRIOV network card; The SRIOV network card sends a switch health check message to the switch it communicates with and requests a reply message from the switch. Upon receiving the switch's response message, it is confirmed that the communication link between the SRIOV network card and the switch is not interrupted; If no response message is received from the switch, it is determined that the communication link between the SRIOV network card and the switch is interrupted. When the communication link between the SRIOV network card and the switch is interrupted, the SRIOV network card replies to the multicast gateway response message and refuses to reply to the multicast gateway health check message. Virtual switches are used for: Send multicast traffic to the on-premises terminal; According to the communication process between the multicast gateway and the virtual switch as described in claim 8, communication is performed with the multicast gateway.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a communication program for converting cloud unicast to cloud multicast, wherein when the cloud unicast to cloud multicast communication program is executed, it implements the steps of the communication method for converting cloud unicast to cloud multicast as described in any one of claims 1 to 8.