Join Telegram Study Group ▷
Regarding the application of SDN in cloud computing networks, there are currently two main genres, one is the "soft" party represented by VMware, and the other is the "hard" party 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. The physical network is only a pipeline; while the latter refers to the core logic of network virtualization implemented in the physical network (the main edge of the machine) The top switch, or TOR, is only placed on the server or other dedicated devices if the switch cannot be implemented. These two programs have their own merits, and each has its own fans.
It should be specially stated that these scenarios can be done with Cisco's ACI because, in essence, ACI's idea is to use hardware SDN to support network virtualization. If you master SDN switches knowledge well, you are highly possible pass CCIE Routing and Switching Lab exam. However, because many users do not want to use the Cisco ACI for various reasons (such as price is too expensive, vendor lock-in, localization trend, 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).
Scenario 1: Using a hardware SDN switch to access a hardware firewall
Hardware firewalls are used in cloud computing networks, which is common. In particular, corporate private clouds hosted clouds, and even public clouds are also available. Many users have made it clear that I used my hardware firewall very well. You have to let me go to the cloud, I must use my hardware firewall. That problem came. In the traditional network, user data wants to go through the firewall. It is very simple. Connect the firewall to the network exit or configure an ACL to direct the flow. However, in a cloud computing network, it is possible that a firewall is only serving a certain number of users or a group of applications. Even this firewall is built by the user. You cannot physically connect it to the network outlet. Traffic must be directed to a firewall on a cabinet, but this time it is not appropriate to use a traditional ACL because the VM is dynamically generated and the policy may change dynamically. You need to dynamically configure the ACL on the switch. What is the most appropriate to use? There is no doubt that SDN switches, dynamic strategy to follow, is the strength of SDN, the core of Cisco's ACI is a dynamic strategy to follow.
If the tunnel is used in the cloud computing network, the problem will be more troublesome. Because many hardware firewalls do not support the tunnel, there must be another place to terminate the tunnel, and then convert the tunnel to VLAN to the firewall. Who is the most appropriate to do this? There is no doubt that it is the SDN switch that supports the tunnel.
Some people say that firewalls will still be limited by 4K Vlan. In fact, because the tunnel is converted to VLAN, the VLAN here can be unique for each port, and it does not need to be globally unique. Of course, this also requires the switch to support. Sheng's SDN switch can support this demand well.
Scenario 2: Supporting multiple Hypervisor hybrid networking using hardware SDN switches
Said to be multiple hypervisors, in fact, the most are still the hybrid network of VMware and other hypervisors. Because either KVM or Xen, open source cloud platforms or third-party neutral private cloud platforms can support them well, and the cloud platform can fully control these hypervisors. But VMware is a closed source hypervisor, and there is no way to control it as you wish. Many customers have used VMware's old products. Now VPC is hot, whether it is fashionable or really demanding, they all want to support VPC, especially the VPC based on Tunnel Overlay. Some people say that it is easy to do, VMware does not have NSX specifically to do this? Although it provides drivers for OpenStack, NSX is very expensive, the average customer cannot afford or feel uneconomical. These customers want to introduce some open source KVM, XEN, but do not want to discard the previous VMware, but also want these Hypervisors together to form a VPC network. then what should we do?
An effective solution is to use an SDN switch to access a server that uses VMware. The cloud platform calls VMware's interface to configure VMware, uses VLAN to identify the tenant's network, and then converts Vlan to a tunnel on the SDN switch. Traffic is sent to the firewall for filtering, and it can also be done through the SDN switch. The solution has been successfully deployed by one of our industry cloud service provider partners in its industry customers, which have used VMware products extensively. Moreover, we found that there are many private clouds with similar needs. To put it bluntly, we don't want to spend money on NSX, but we want to have some NSX features.
Scenario 3: Deploying Vlan on demand using a hardware SDN switch
This scene is not just a need, some customers don't care, but some customers care. In many small private clouds, VLAN is also used in networking mode. After all, it is easy to deploy and has good performance. However, with VLAN networking, in addition to the scalability is not as good as Tunnel Overlay, it has another small problem because the VM can be easily moved, and each VM is tied to a specific VLAN. When the VM migrates, VLAN also needs to Follow the migration. In the VLAN networking solution, VLAN must be visible to the intermediate physical network, which means that the VLAN configuration on the switch port should be dynamically changed. In order to circumvent this problem, it is now common practice to pre-configure all possible VLANs on all ports of all switches. The problem with this is that all broadcast (such as ARP/DHCP), multicast, and unknown unicast packets are sent to all servers on the entire physical network and are finally discarded in the server. The aspect is wasting bandwidth, and on the other hand, there are potential security issues.
A very simple solution to this problem is to introduce an SDN switch to dynamically configure Vlan as needed.
to sum up
For the application of the SDN switch in the above scenario, summed up in one sentence, it is the use of the best. The real needs are really strange. I have listed some of the commonalities that are easy to understand. There are still some people who can't understand it, and even the requirements that I can't understand are still not listed. In the face of these needs, usually you do not expect to use conventional means to solve, and SDN, may be able to help you, this may be one of the charms of SDN. Of course, the SDN switch mentioned here is not necessarily an OpenFlow switch. More often, by introducing a Cloud Agent in a traditional switch and providing an open API (JSON RPC or REST API), it may be a better grounding gas. The way it is implemented, because it can naturally interface with traditional networks, and does not require any special needs for aggregation and core equipment, this is our valuable experience in thousands of times of practice.
