RSS
Логотип
Баннер в шапке 1
Баннер в шапке 2

Cisco SDN

Product
Developers: Cisco Systems
Technology: SDN Software-Defined Network Software-defined networks,  Data processing centers are technologies for DPC

Content

The strategy of Cisco SDN for the data processing centers (DPC) costs on three foundations in a type:

  • the infrastructure focused on applications (Application Centric Infrastructure, ACI);
  • programmable factory;
  • programmable network.

Such approach extending advantages of programmability and automation to all line of the Cisco switches Nexus gives to our customers the chance to select that option of implementation most of which of all corresponds their IT and to business objectives. Let's consider each of the support of strategy of Cisco SDN for DPC mentioned above.

ACI

ACI is the flagman offer of Cisco in the field of SDN and the most full-function SDN solution in the industry. Using the model the politician focused on applications ACI provides the automated, integrated configuring of the basic and imposed networks, configuring of services of L4-L7 levels in an extensive partner ecosystem and also remote measurement of different parameters for the current serviceability check at the level of applications. The open, flexible and safe solution with such complex opportunities provides to customers of advantage which any other SDN solution is not capable to provide. The report of IDC company on what benefits are received as a result by customers can serve as the proof.

Programmable factory

The programmable factory provides scalability and simplification of the organization of the imposed VXLAN networks. Besides, it opens a way to application of all line of Nexus for obtaining benefits of SDN.

Virtual networks of VXLAN purchased considerable popularity in the industry for many reasons, including, owing to their advantages over such traditional technologies as VLAN and Spanning Tree. Here and more effective use of bandwidth thanks to the Equal Cost Multi Pathing (ECMP) protocol, and big theoretical scalability (16 million segments), and the big flexibility reached thanks to application of overlay model which allows creation of multi-user (multi tenant) of cloud networks. With growth of popularity of VXLAN networks also the need for the solution of two key problems grows: implementations of the standardized approach to scaling of VXLAN networks and simplification of their configuring and management of them.

For the standardized scaling of VXLAN Cisco networks implemented support of the managing Multipoint BGP EVPN plane on the Nexus switches. Why it is so important? The matter is that the initial VXLAN specification (RFC 7348) relied on the multi-address mechanism of avalanche mailing and studying (flood-and-learn) without the managing plane for a number of key functions (detection of the VTEP nodes and determination of availability terminal a host computers). It is not the most effective approach. The committee of IETF as the standardized managing plane for overlays of VXLAN developed MP BGP EVPN Control Plane technology for overcoming its restrictions. Thereby it was succeeded to reduce mailing traffic volume in the imposed network and to achieve bigger scalability and efficiency.

For the solution of the second problem (i.e. for simplification of configuring and management) Cisco submitted the Virtual Topology System (VTS) system — a new solution which automates configuring of the imposed networks, simplifying deployment of cloud services. Thanks to automation and close integration with such means of harmonization from third-party producers as OpenStack and VMWare VCenter, VTS simplifies configuring and management both for physical, and for virtual tasks, eliminating need for intensive manual adjustment of network.

Programmable network

The programmability of infrastructure has huge value because it promotes automation which, in turn, promotes increase in speed that is need practically for any business dealing with digital revolution. With development of programmability of Cisco implements more and more opportunities in Nexus line. Sreli them such functions as the open programmable interfaces API (Programmable Open APIs), integration with means of DevOps and the automation equipment of third-party producers, development tools of user applications and the Bash command. Input of set of these functions in the structure of NX-OS facilitated implementation of programmable networks. Let's look how the customer can use it.

Not so long ago small part of the customers operating very big networks began to change the operational processes. Their networks became more and more as the number of users (that is unsurprising) and, respectively, servers grew. When growth rates of number of servers once again accelerated, customers understood that they have three opportunities: employ one more army of system administrators, give the acting administrators overtime work or begin to deploy in a new way servers and manage them.

The majority (though not all) were inclined to the third option, and here automation became opening: the automation equipment of deployment of servers and management of them helped system administrators and their employers to scale business. They began to pay attention to such indicator as number of the servers managed by one administrator. This ratio became sharp to increase (in certain cases by several orders).

With implementation of automation and approach of other changes concerning the culture of production, processes, etc. in some companies noticed that administrators manage not tens and hundreds, but thousands of servers any more. Then experiments using DevOps began. In process of convergence of the mentioned elements cooperation of different divisions gradually amplified, and exchange of "skill secrets" as a result began. So, for example, some system administrators saw effect of use of such tools as Puppet and Chef for automation of server tasks, and they had a desire to use the same means in network. In other cases experts on Linux and fans of the command interpreter Bash began to use these commands for configuring and diagnostics and networks, and servers. The third needed the API interfaces which allowed to take the most detailed information for its postprocessing and use by scripts and other tools.

In other words, there was a need for increase in number of network components, available to programming. Though these processes happened only in some companies, many components attracted interest of quite extensive circle of customers. When it occurred, Cisco began to increase functionality of programming in the Nexus switches.

So, three whales: infrastructure of ACI, programmable factory and programmable network — provide a wide range of possibilities which help our customers to solve the most various problems which they should face.