Talking about SDN and cloud network

Summary: SDN Software Defined Networking 1 What is SDN What is SDN? This question seems to have been a controversial issue since the inception of SDN. The official explanation of SDN proposes three characteristics of SDN: centralized management, separation of control and forwarding, and open API. It can be said that as long as it meets the three characteristics of SDN, it is SDN.

SDN Software Defined Networking

1 What is SDN

What is SDN? This question seems to have been a controversial issue since the inception of SDN. The official explanation of SDN proposes three characteristics of SDN: centralized management, separation of control and forwarding, and open API. It can be said that as long as it meets the three characteristics of SDN, it is SDN. SDN is an idea, an idea. SDN is a new way of thinking when we architect our network.

Three characteristics of SDN:

centralized management

and unified management entry. For example, if I have 100 switches, for the configuration management of 100 switches, there is no need to configure switches one by one, and 100 switches can be configured through a unified controller. This is centralized management.

Controlling Forwarding Separation

In SDN networks, what SDN expects is that switches should be "dumb" enough. The function of the switch should be just match & action. The neighbor subsystem, ACL rules, routing, gateway and other functions should be completed on the switch, but on the controller. Of course it is also an ideal situation. This is where most of the products that claim to be SDN cloud networks do it. In the dragon flow cloud network of openstack, in fact, some functions of the neighbor subsystem and gateway are implemented on the SDN controller, the main purpose is to solve the distribution of east-west traffic and reduce the fault domain. In the cloud network of dragon flow, there are still many traditional cloud network implementations.

open API

In the SDN architecture, open APIs become northbound interfaces. The configuration of switches in traditional networks is basically CLI configuration or Netconf configuration, and it is difficult to control the network through software through such a configuration interface. For our software developers, if we can program the network, we need a unified and open API to call. This is also the core idea of ​​SDN for programmable networks.

2What are the benefits of SDN? In fact, many people have asked me

this question, what are the benefits of SDN? Some people will directly ask, will the performance of the SDN network be improved by 30%? After using SDN, will there be many new network functions? My point of view is that the proposal of SDN is not a network revolution, but a network development. In the process of building a cloud network, the greatest benefit that SDN brings to us is that the cost of network functions realized through SDN will be much lower than that of traditional networks. This cost mainly refers to these aspects: development cycle, network complexity, architectural integrity, network IO path length, and redundant coupling.

We have long considered integrating cloud networks with third-party security products to provide a more secure cloud network. Security manufacturers only need to make the original security products into instances and run them in the cloud network. But the biggest question is cloud network, how to divert traffic to virtualized security products? In order to divert traffic, we need to create more VLANs and bridges, and third-party security vendors also need to identify the migration logs of our instances and adjust the rules with the migration. We also need to open many APIs that should not have been opened. (Provide vlan, bridge creation, log filtering). In the end, the plan was terminated because the cost was too high. Our overall network architecture has undergone a lot of changes. At the same time, the IO path of the network has nearly doubled, and the development cycle is expected to take two quarters. More importantly, there should not be so many cross-development projects for integration projects with third parties. Process. Later, our SDN cloud network was finally developed. The work of diversion is concentrated on the SDN controller, and the overall network architecture is basically unchanged. The network IO path has not changed. Even if the instance is migrated, our SDN controller can recognize it, and there is no need for a third-party security vendor to monitor log events. The realization of such a function can be completed in a month. This is the biggest benefit of SDN. Of course, this is related to the technical implementation details of SDN cloud network. In the future, I will write an introduction article about Pingo SDN cloud network to talk about this aspect.

Traditional cloud network

1 Traditional cloud network

Traditional cloud network: The traditional network components provided by the network protocol stack based on the Linux kernel realize the basic functions of the cloud network. For example, the security group is implemented with the iptables that comes with Linux, the subnet isolation is implemented with the Vlan that comes with Linux, the address translation is implemented with the NAT that comes with Linux, the traffic control is implemented with the TC that comes with Linux, and the routing function is used. Linux's own route table implementation and so on. With some network planning, use one or two servers as network nodes (egress core routers of the cloud network). Finally, cooperate with the scheduling capabilities of the cloud. This is how traditional cloud networks are built.

2 Problems with traditional cloud networks

1) The network services of the network nodes are too concentrated and are prone to single point of failure.

2) The traffic from east, west, north and south is mixed, and the network quality is not high.

3) The network functions of the traditional Linux network protocol stack are seriously bundled and resource consumption is serious.

4) The subnet of Vlan is isolated and the number is insufficient.

5) The horizontal expansion ability is poor, and the network scale is difficult to expand.

6) The performance is swallowed vertically, which is limited by the order of network nodes.

In order to solve these problems of traditional networks, in fact, many enterprises and open source organizations have also made a lot of efforts. In the final analysis, the most important thing is to sink the business functions of network nodes to computing nodes (distributed virtualized network). Of course there are other issues, which are not exposed so quickly.

3 The Road to OpenStack Cloud Network

Some time ago I read "The Road to High Availability and Distributed OpenStack Network" http://www.infoq.com/cn/presentations/lead-to-high-availability-and-distributed-openstack -network. I got a lot of inspiration and deeply realized that the road to cloud networking is indeed difficult and tortuous. I compared the development path of Openstack and Pingo's SDN cloud network and made some analysis. As shown below:



　　Comparison of Openstack's Network Road and Bingo SDN

An admission condition for a mature commercial cloud network is high availability. Openstack implements HA in the Neutron L3HA release. However, in the subsequent versions, due to architectural conflicts, the HA in the versions of Neutron L2POP &ARP Respondar, DVR, and Dragon Flow will not be compatible. The development road of Openstack can be summed up by sinking network functions (FW, Gateway, NAT, ROUTE, DHCP, etc.) on network nodes to computing nodes. It is also to improve the disaster recovery capability of the network. It is undeniable that Openstack is a successful product. At present, many cloud vendors also implement their own clouds on the basis of Openstack. SDN's cloud network

The proposal of SDN has indeed given us a lot of new ideas. The first idea is: if the cloud network is realized through SDN, can it solve the problems that are difficult to solve by the traditional cloud network? For a new technology, we must have enough tolerance. Our approach is to implement a cloud network with the same functions as a traditional cloud network through SDN, without requiring SDN to break through performance and create new functions. Unlike Dragon Flow, we do not use SDN for some functions, but all network functions are implemented through SDN. This idea is indeed a bit crazy, but there is absolutely no problem with feasibility.

1 We made some requirements for SDN

1) Get rid of network nodes.

2) Do not use the network components that come with the Linux network protocol stack.

3) The computing node uses Openvswitch as a distributed virtual switch.

4) Using the SDN controller, all cloud network business functions are concentrated in the SDN controller.

5) The communication between the SDN controller and the Openvswitch uses the OpenFlow protocol.

6) The SDN controller cluster is highly available.

During the development process, we deeply realized the power of SDN. Not only have we fulfilled the requirements we set out, we have also brought a lot of new network features through SDN. Hidden distributed virtualization gateway, instance migration rules do not need to be reconfigured, network functions can be hot-swapped, superposition of network services will not increase IO paths, network visualization, ARP preprocessing and ARP prefilling, etc. All network functions are in the SDN controller, all network rules are automatically timed out on demand, and the controller cluster is highly available. Later, I will share with you the network functions of Bingo SDN.

We did encounter many problems during the development of SDN cloud network. For example, the Openflow protocol does not support some network functions, there are some bugs in Openvswitch, the new connection performance of the SDN network is low, the SDN controller cluster is highly available, and so on. In the end, we still break through these problems, and I will share with you the problems and solutions encountered by Bingo SDN in the future.

It is undeniable that the cloud network of SDN is indeed a feasible and correct development path. SDN gives us more room for cloud network development.

This article is transferred from d1net (reproduced)

Copyright statement: The content of this article is contributed by Internet users, and this community does not own the ownership and does not assume relevant legal responsibilities. If you find any content suspected of plagiarism in this community, please send an email to: [email protected] to report and provide relevant evidence. Once verified, this community will immediately delete the allegedly infringing content.