Do you know the application scenarios of SDN switches in cloud computing networks

Fancy Wang 0929 2021

SDN technology has been developed for several years, and cloud computing has a longer history. The combination of the two has become a killer application of SDN. It has been hot in the past two years. Some well-known consulting companies have reported on the increasing market of SDN year by year. The share argument also mainly refers to the application of SDN in cloud computing networks.

Regarding the application of SDN in cloud computing networks, there are currently two main schools, one is the "soft" school represented by VMware, and the other is the "hard" school represented by Cisco. The former mainly means that the core logic of the entire network virtualization solution is implemented on the Hypervisor in the server, and the physical network is just a pipeline; while the latter means that the core logic of network virtualization is implemented in the physical network (mainly edge machines). Top switch, namely TOR), only the parts that the switch can't realize are put in the server or other special equipment. Each of these two programs has its own merits, and each has its own fans.

But the world has never been unipolar, nor bipolar, but multipolar. There are many unconventional needs in the real network. These needs can not be solved by these two solutions, or even though they can be solved. , But not optimal, including difficulty in implementation, performance and price. As a practitioner who has used hardware SDN for a long time to provide users with solutions, I would like to introduce how hardware SDN switches in the real world can solve some specific scenario requirements in cloud computing networks, whether public cloud or private cloud. You may encounter it, private clouds (including managed clouds) are mostly, because customized requirements are more common in private clouds.

It should be noted that these scenarios here can be achieved with Cisco's ACI, because in essence, the idea of ACI is to use hardware SDN to support network virtualization. However, because many users do not want to use Cisco ACI for various reasons (such as too expensive, vendor lock-in, localization trends, etc.), they need another solution (I am not saying that ACI is not good, on the contrary, purely from a technical point of view , I personally appreciate ACI).

Cloud computing network's customization requirements for SDN controllers and switches

Many people have some misunderstandings about the application of SDN switches in cloud computing networks. There are two typical misunderstandings. One is that someone always asks, which controller are you using? Can it be connected to OpenDayLight/Ryu/ONOS? The other is that you just need to get an SDN switch. Support cloud computing network scenarios, no matter which SDN switch of which manufacturer. The reason for these two misunderstandings is that many people have not understood that SDN means application-related customization, thinking that just holding a common thing can be used to build a cloud computing network. As a specific SDN scenario, the controller of the cloud computing network is usually designed specifically for the cloud computing scenario. It has a single function to fulfill the requirements of the cloud computing network. There may even be no explicit controller, but hidden In the cloud platform (such as directly implementing the code logic in OpenStack Neutron Server). The controller in this scenario cannot be used as a general-purpose SDN controller. Conversely, the general-purpose SDN controller cannot be directly used in cloud computing network scenarios. As for why the second question is a misunderstanding, it is easy to understand. Even the controller needs to be customized for cloud computing scenarios, not to mention SDN switches. Therefore, it is not just that an SDN switch can be used to support cloud computing network scenarios, but special in-depth customization is required.

Scenario 1: Use hardware SDN switches to improve performance

In this scenario, users use Tunnel Overlay to deploy network virtualization. However, because the operation of vSwitch on the Tunnel (VxLAN or NvGRE) has a relatively large impact on performance (low throughput, large delay, large jitter, the specific impact depends on each company's implementation and optimization), so this At this time, you can use the SDN TOR switch to perform tunnel offload, and offload the tunnel operations that have a large impact on performance to the SDN TOR switch. All other operations remain unchanged in the server. Logically, the SDN TOR switch can be considered as an extension of vSwitch. If you go further, you can also put the distributed east-west L3 Gateway on the SDN TOR, so that SDN TOR is deeply involved in network virtualization.

Not all users agree with this model, but some people like it. At present, we have deployed this scenario in several small and medium private clouds and a well-known IDC cloud. The greatest help to these clouds is excellent performance and stability. The data flow is shown in the figure below.

Scenario 2: Use a hardware SDN switch to connect to a physical server

In the understanding of many people, all servers in the cloud computing data center are virtualized. In fact, this understanding is far from the truth. Not only are there a large number of physical servers in many public and private clouds, but even some Physical servers in the cloud also account for the bulk. The vast majority of the clouds that I have come into contact with really have a large number of customer practices, basically have this demand. There are also many reasons. Some of the existing old servers do not have virtualization capabilities, some are that customers want to run some very resource-consuming applications, the performance of using virtual machines is too poor or the performance is unpredictable, and some are that some of the customers’ servers are customized. Some of the servers are for security reasons, and they don’t want to share with others physically, while others are users who bring their own servers and don’t want the cloud service provider to move them at all. need.

For this requirement, if you use Vlan networking, it is relatively easy to get it, and you can barely do without an SDN switch, because if you want to isolate, you can configure Vlan directly on a common switch. But once the Tunnel is used, the problem arises. Where is the Tunnel VTEP configuration? Some people say that you can just set up a virtual machine on the server, and then install vSwitch. Of course you can do it, but the performance is impaired, which is not what the customer wants. It is equivalent to deceiving customers; some people say that a special vSwitch is designed to be installed on the server. This is definitely OK in theory, but the workload is large (not only the workload of designing this vSwitch, but also the cloud platform control Workload), most people can't handle it. What's more, if the user's own device doesn't want you to move it at all, neither of these two methods will work.

For this scenario, many professional network virtualization solution providers, including VMware, generally use a hardware SDN switch as a VTEP Gateway to connect these physical servers to the virtual network. Nothing needs to be done. Moreover, this scenario has another important requirement for the SDN switch as the VTEP Gateway, which is currently not available for all switches using a certain big-name switching chip. That is, the switch is required to support both Tunnel bridging and It supports Tunnel Routing (otherwise it cannot be a distributed L3 Gateway). The current switch using this big-name chip can only support the former, but not the latter. Cisco's ACI can support the latter because they use a chip of their own. Of course, the chips behind the chip provider are said to solve this problem.