Join Telegram Study Group ▷
SDN has been developed for several years, and cloud computing has longer history. The combination of the two is a killer application of SDN. It has been hot in the past two years. Some well-known consulting companies have increased the market of SDN year by year. The assertion of share mainly refers to the application of SDN in cloud computing networks.
But the world has never been unipolar, nor bipolar, but multipolar. There are many unconventional needs in the real network. These requirements cannot be solved by these two schemes, or even if they can solve them, but not optimal, including implementation difficulty, performance, and price. As a long-term use of hardware SDN to provide solutions for users, I would like to introduce how real-world hardware SDN switches can solve the specific scenarios in some cloud computing networks, whether public or private. It is likely that private clouds (including hosted clouds) will be encountered, as customized requirements are more common in private clouds.
Customization requirements for SDN controllers and switches in cloud computing networks
Many people have some misunderstandings about the application of SDN switches in cloud computing networks. SDN switches will help you acquire CCIE Routing and Switching certification.There are two typical misunderstandings. One is well known, which controller is the controller you use? Can you connect with OpenDayLight/Ryu/NOS? The other is that you only need to take one SDN switch. Support cloud computing network scenarios, no matter which vendor's SDN switch. The reason for these two misunderstandings is that many people still don't understand that SDN means application-related customization, thinking that they can do cloud computing networks with a common thing. As a specific SDN scenario, the cloud computing network is usually designed specifically for the cloud computing scenario.
The function is single, that is, the requirements of the cloud computing network are completed, and even the explicit controller may not be 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 universal SDN controller cannot be directly used in a cloud computing network scenario. As for why the second question is misunderstood, 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 a random SDN switch that can support cloud computing network scenarios but requires special deep customization. For example, our Shengke Network (Suzhou) Co., Ltd has designed the corresponding controller and switch functions specifically for this scenario.
Scenario 1: Using hardware SDN switches to improve performance
In this scenario, the user deploys network virtualization using Tunnel Overlay. However, because the operation of the switch to the tunnel (VxLAN or NvGRE) has a large impact on performance (low throughput, large delay, large jitter, the specific impact depends on the implementation and optimization of each company), so this when the switch can be performed by means of SDN TOR offload tunnel, the relatively large impact on performance to offload the tunnel operation SDN TOR switches, all the other operations in the server maintained constant, can be considered logically vSwitch SDN TOR switch is extended. Still further, if, things may be distributed to the L3 Gateway also placed on the SDN TOR, so deep SDN TOR tantamount participate in the network virtualization.
Not all users recognize this model, but some people like it. At present, we have deployed this scenario in several small and medium-sized private clouds and a famous IDC cloud. The biggest help for these clouds is excellent performance and stability. The data flow is shown in the figure below.
Scenario 2: Using a hardware SDN switch to access a physical server
In the understanding of many people, all the servers in the cloud computing data center are virtualized. In fact, this understanding is far from the truth. Not only in many public and private clouds, but there are also a large number of physical servers, and some even exist. The physical servers in the cloud also account for the bulk. The vast majority of the clouds I have come across really have a lot of customer practices, and basically, have this need. There are also many reasons. Some existing servers have no virtualization capabilities. Some customers have to run some very resource-intensive applications. The performance of virtual machines is too poor, or the performance is unpredictable. Some of the clients' servers are customized. Servers, some for security reasons, do not want to share with others physically, and others are users with their own servers, do not want cloud service providers to move, etc., the overall reason is strange, but all customers are real demand.
For this demand, if you use VLAN networking, it is still relatively easy to get, you can barely use SDN switches, because to do isolation, directly configure VLAN on the ordinary switch. But once the tunnel is used, the problem comes. Where is the Tunnel VTEP configuration? Some people say that you can only have one virtual machine on the server, and then install the vSwitch, which of course can be done, but the performance is not damaged, not the customer hopes. It is equivalent to deceiving customers; others say that a special switch is designed to be installed on the server, so it is theoretically OK, but the workload is large (not only the workload of designing this vSwitch but also the control of the cloud platform). The amount of work), the average person can't make it. What's more, if the user's own device does not want you to move, these two methods will not work. For this scenario, many professional network virtualization solution providers, including VMware, generally use a hardware SDN switch as the VTEP Gateway to connect these physical servers to the virtual network. The physical server does not. Need to do anything. Moreover, this scenario has a more important requirement for the SDN switch as a VTEP Gateway. It is not available to all switches currently using a large-scale switch chip, that is, the switch needs to support both tunnel bridging and Support Tunnel Routing (otherwise it can't be a distributed L3 Gateway). The switch that currently uses the big chip can only support the former and cannot support the latter. Cisco's ACI can support the latter because they use their own chip. Of course, the chip behind the chip provider is said to solve this problem.
Shengke's SDN switches use self-developed switch chips and support Tunnel bridging & routing from the first generation of chips. Currently, SDN switches for this scenario have been deployed in large numbers and will be deployed in multiple public clouds. The scenario architecture is shown in the following figure (Note: The SDN control protocol may not be OpenFlow or a proprietary protocol)
