The new demands that have stretched traditional networks

Bloggers have always believed in one thing: any innovation at the bottom of the internet is top-down. The rise of SDN is not due to the fact that Martin Casado's brain hole is open to control and forward plane separation. But because some applications from the top of the Internet require centralized control over network equipment, the best way to centralize control is precisely the separation of control and forwarding planes.

In this article, bloggers will list rigid requirements that are less readily achievable in traditional networks. In future articles, bloggers will begin to analyze how SDN meets these rigid requirements. Welcome to all the schools of contention, check the leak vacancy.

Rigid demand one: Save money! Save money! Save money!

The overhead of a traditional network is roughly divided into two parts: purchase cost and operating cost. Purchase cost = equipment itself + after-sales service. Those well-known manufacturers of network equipment and after-sales service are clearly marked. The problem is, we bought the equipment, why do we have after-sales service? The reason is that the traditional network equipment is more complex, especially the software protocol stack above it. What to do if you encounter problems? After-sales service to solve.

The irony is that the price of after-sales service is often much more expensive than the equipment itself, which makes bloggers quite puzzled. If you do not buy after-sales service, the price of the equipment itself? Pure hardware is already the price of cabbage, the value is the hardware above the software protocol stack. Decomposition here, we have seen the problem: because of this complex software stack, we spend more money to buy hardware equipment, also because of this complex protocol stack, we even need to spend more money to buy so-called after-sales service.

For operators, this software protocol stack may have the meaning of existence, topology is changeable, neighbor relationship is complex, need some complex distributed protocol support veneer. But for the data center, the protocol stack becomes very chicken. The simplest, plan the VLAN, run two layers. Slightly more complicated, running between the leaf and the Spine routing protocol +ecmp. The configuration has the template, the variable parameter is OK. So simple requirements, do not need that complex stack of stacks, why do we still spend that part of the money?

Again, the cost of running a traditional network. The biggest cost is to hire an OPS team. In the IT department of a large enterprise, there was once an important parameter for measuring the degree of automation of an enterprise's infrastructure called "Administrator/Every thousand Servers". Bloggers believe that the management of a traditional network is a very troublesome thing as long as a friend who has operated on a traditional switch admits that managing a legacy web is a hassle: any need for a top-level application requires protracted reconfiguration of VLAN,IP addresses, routing protocols, and ACLs, Any network failure requires the administrator to log in each switch to check the configuration and various show, but also every day to stare at a variety of monitoring system to check the bandwidth, see delay. This is a technical work, otherwise the CCIE will not be so high. As a result, the cost of operating the network becomes expensive because of its complexity.

There are also the costs of SDN and traditional networks that can't be bypassed, such as electricity bills, which bloggers have skipped. Split the overhead of traditional networks, let's look at how SDN is ideally suited to help customers save money: The switch still needs it, but the protocol stack above the switch is not needed. It used to be n switches n stacks, and now it is 1 controllers of n switches. After-sales service, still need. New technology well, somebody has to teach a teacher. The drapery team is likely to shrink significantly in the SDN world because there is only one controller that does not require too many administrators. It seems that in theory, SDN does save money, and it's all about stacks and operations.

Bloggers have not yet seen the companies that claim to have deployed SDN to disclose exactly how much they have saved. I guess some companies might complain: after we deployed SDN, we spent more money! Bloggers attributed the possible reasons to 1) the Non-pure SDN scheme and 2) new research and development costs, which will be analyzed in detail in future articles.

Rigidity requirement two: multi-tenancy and elastic calculation (multi-tenancy & Elastic Computing)

Since the concept of multi-tenancy and elastic computing has been implemented by Amazon EC2, both public and private clouds are expected to emulate, making it a rigid requirement. However, this requirement can be difficult for traditional networks. The difficulty is two, the first is how to achieve the separation between multi-tenancy. In traditional networks, two-tier VLANs and three-tier subnets are the most common ways to isolate tenants. Each new tenant is added, and the network administrator assigns the VLAN to it manually, assigning an IP address. In a traditional network, this process is often in days. After the advent of EC2, people have become accustomed to the machine in minutes, the network. Helpless is not every family is Amazon, this kind of platform can not be built up casually.

The second difficulty comes from elastic computing, where each tenant can request, log off, and move a virtual machine at any time, depending on the load. This rigid demand is a product of VMware's range of products, as well as the orchestration systems represented by OpenStack and Cloudstack. But these systems are only managing servers, and the physical network is irrelevant to them. When a virtual machine is migrated from one host to another, the physical network sometimes has to be adjusted accordingly (such as reconfiguring the VLAN) to enable a seamless migration of virtual machines.

No one chooses to manually log in to each switch to complete the above configuration modifications. Centralized control of network devices becomes the only option. SDN is also driven by this rigid demand, and is beginning to enter people's horizons at full speed.

Rigidity requirement Three: Application multi-level deployment and Network service chain (multi-tier application & Service chaining)

I'm just calling this the last straw of the camel that killed the traditional network. Today's online services have become very complex, the kind of a Web server plus a database server architecture may only be seen in the demo phase. A more realistic architecture might look like this: The front end is the firewall, then load balancer assigns traffic to multiple Web servers, multiple application servers handle complex business logic, multiple database servers are responsible for querying and inserting records and backing up each other, There is an ACL between the Web server and the database that denies both direct communication.

This is just half the entire business chain, and the network traffic that is returned may go through another completely different business chain. Using the traditional network to achieve the above business chain is a disaster. With each additional link added to the business chain, each additional entry or access control added to the server means that the network administrator is very careful to configure the appropriate network devices based on the network location of each server. The complexity of the business logic to this extent, the traditional network management method has been completely unable to adapt. While SDN and NFV (Network function Virtualization) have many inherent advantages in solving such problems, bloggers will discuss them in detail in future articles.

In this connection, three of the rigid requirements to accelerate the disruption of traditional networks have been summed up. It is worth noting that these three just need until the mobile internet and big data in full swing today only began to appear so urgent. Bloggers still want to emphasize that the advent of SDN is entirely due to the need for upper-level applications and is a top-down process. This article omits a lot of other rigid requirements, such as security, fast route recovery, real-time network monitoring, and so on. Not because they are unimportant, but because they are not a direct cause of the development of Sdn.

transferred from : http://www.jianshu.com/p/7342f5dd3d78

The new demands that have stretched traditional networks