In the context of applying SDN switches in various scenarios, a concise yet flexible summary is often used. The SDN switch discussed here does not necessarily have to be an OpenFlow-based one. More commonly, a Cloud Agent is integrated into traditional switches. Offering an open API—such as JSON-RPC or REST API—can be a more practical approach for achieving seamless integration.
SDN technology has been around for several years, and cloud computing has an even longer history. Their combination represents a powerful application of SDN, which has gained significant attention over the past two years. Leading consulting firms have consistently reported growing market interest in SDN. This growth primarily reflects the application of SDN within cloud computing networks.
When it comes to SDN in cloud environments, there are generally two main approaches. One is the "soft" approach, exemplified by VMware, where the core logic of network virtualization is implemented on the hypervisor within the server, making the physical network just a simple data path. The other is the "hard" approach, represented by Cisco, where the network virtualization logic is embedded in the physical network, typically at the top-of-rack (TOR) switch. In cases where this isn't feasible, the logic may be placed on dedicated devices. Each approach has its own advantages and a loyal user base.
However, the real world is not unipolar or bipolar—it's multipolar. There are many unconventional requirements in actual networks that these two methods might not fully address, or if they do, they may not be optimal in terms of implementation complexity, performance, or cost. As a provider of hardware-based SDN solutions, we aim to demonstrate how real-world hardware SDN switches can tackle specific use cases in both public and private cloud environments. Private clouds, in particular, often involve more customized needs.
It should be noted that Cisco’s ACI can handle these scenarios, as its design fundamentally relies on hardware SDN to support network virtualization. However, many users choose not to adopt ACI due to factors like high costs, vendor lock-in, or a preference for local solutions. While I personally appreciate ACI from a technical standpoint, the need for alternative solutions remains valid.
**Customization Needs for SDN Controllers and Switches in Cloud Environments**
There are common misconceptions about how SDN switches are used in cloud computing. Two typical misunderstandings are: first, some people ask which controller is used and whether it can integrate with OpenDayLight, Ryu, or ONOS. Second, others believe any SDN switch can support cloud networking regardless of the vendor. These misunderstandings stem from a lack of understanding that SDN involves application-specific customization. Unlike generic tools, cloud networking is often designed specifically for its use case, with limited functionality and sometimes even a hidden controller embedded directly into the cloud platform, such as in OpenStack Neutron Server. Therefore, a general-purpose SDN controller is not suitable for cloud environments, and neither is a generic SDN switch. Customization is essential. For example, Shengke Networks has developed tailored controllers and switches specifically for cloud networking scenarios.
**Scenario 1: Using Hardware SDN Switches to Improve Performance**
In this scenario, network virtualization is deployed using Tunnel Overlay. However, the vSwitch handling tunnel operations (like VxLAN or NvGRE) can significantly impact performance, leading to low throughput, high latency, and jitter. To mitigate this, hardware SDN TOR switches can offload the most performance-sensitive tasks, allowing the rest of the operations to remain on the server. In essence, the SDN TOR switch acts as an extension of the vSwitch. Going further, distributed functions can be moved to the L3 Gateway on the SDN TOR, enabling deeper participation in network virtualization.
We've successfully implemented this in several small and medium-sized private clouds and a well-known IDC cloud. The key benefit has been improved performance and stability, as shown in the diagram below.
[Image: Analysis of the role of SDN switches in cloud computing networks in different scenarios]
**Scenario 2: Using a Hardware SDN Switch to Connect Physical Servers**
Many people assume all servers in cloud data centers are virtualized, but this is far from the truth. A significant number of physical servers exist in both public and private clouds. Some servers lack virtualization capabilities, while others run resource-heavy applications where VM performance is unreliable. Additionally, some customers prefer physical isolation for security or custom reasons. All these are real and valid demands.
To connect these physical servers to the virtual network, VLANs can work, but when tunnels are involved, challenges arise. Configuring VTEP on the server becomes complex and impacts performance. An alternative is using a hardware SDN switch as a VTEP Gateway, allowing physical servers to join the virtual network without changes. This setup requires the switch to support both tunnel bridging and routing, which is why many modern switches fall short. Cisco ACI supports this, but other solutions are also emerging. Shengke Networks’ SDN switches support both features from the first generation, and have been widely deployed in public clouds.
[Image: Analysis of the role of SDN switches in cloud computing networks in different scenarios]
**Scenario 3: Using a Hardware SDN Switch to Connect a Hardware Firewall**
Hardware firewalls are common in cloud environments, especially in corporate and hosted clouds. Many users insist on using their own hardware firewalls. In traditional networks, connecting a firewall is straightforward, but in cloud environments, dynamic policies and VM mobility make it challenging. SDN switches excel in dynamically configuring ACLs, making them ideal for this scenario. If tunnels are used, the SDN switch must also terminate the tunnel and convert it to VLAN for the firewall. Shengke’s SDN switches support this efficiently, allowing unique VLANs per port without global uniqueness.
**Scenario 4: Supporting Hybrid Networking with Multiple Hypervisors**
Supporting multiple hypervisors, particularly VMware alongside KVM or Xen, is a common challenge. VMware’s NSX offers tunnel-based VPC support, but it is expensive and not always practical. A viable solution is using an SDN switch to connect VMware servers, allowing the cloud platform to manage VLANs and convert them to tunnels. This approach has been successfully implemented in industry clouds, meeting customer demand for NSX-like features without the high cost.
[Image: Analysis of the role of SDN switches in cloud computing networks in different scenarios]
**Scenario 5: On-Demand VLAN Deployment Using Hardware SDN Switches**
While not a critical requirement for all, some customers value dynamic VLAN deployment. Traditional VLAN setups require pre-configured ports, leading to inefficient broadcast traffic and potential security risks. An SDN switch can dynamically configure VLANs as needed, improving efficiency and security. This is a simple yet effective solution for managing network flexibility in smaller private clouds.
Solar AC Cable
SOWELLSOLAR
TUV SUD PPP58216 PV07AC-F
3X** mm² 450/750V UV. Res
-40℃~90℃ Zhejiang Sowell Electric Co. Ltd
flame-retardant
irradiation XLPE insulated and sheathed AC cable for Solar
Energy Lighting Power Generation.
Tinned copper AC CABLE
Sowell Electric CO., LTD. , https://www.sowellsolar.com