Talking About Operation and Maintenance Under SDN Architecture (2)

images
SPOTO Cisco Dumps
Talking About Operation and Maintenance Under SDN Architecture (2)

SDN Operation and Maintenance Tools Change

In the traditional network operation and maintenance, the operation and maintenance rules and regulations have been set so many, the operation and maintenance personnel can actually do so much, for different manufacturers of hardware devices to knock different command lines, there are problems to check the log, write failure report. The main feature of the SDN network is clustering and adopting virtual software network data streams, which are easily presented in a graphical manner, facilitating the online service and the maintenance of later content. Then SDN is so bullish, do you need an operation and maintenance tool? The answer is of course no.

In the SDN system, there is a separate central controller and upper application layer. The forwarding layer is only used as the lowest-level data forwarding. The service is arranged in the controller. The controller is a pure software system. This system can implement external API docking. DevOps came in handy.

DevOps facilitates communication and collaboration between developers, operations teams and infrastructure professionals to enable unified and automated IT development, implementation and management. At the same time, SDN allows engineers to apply software control to network elements, centrally managing and configuring large amounts of virtual and physical infrastructure.

 SDN meets NetDevops

DevOps (a combination of Development and Operations) is a collective term for a set of processes, methods, and systems that facilitate communication, collaboration, and integration between development (application/software engineering), technology operations, and quality assurance (QA) departments. It is a culture, movement or convention that values communication and cooperation between Software Developers (Dev) and IT Operations Technicians (Ops). By automating the process of "software delivery" and "architectural change", it is faster, more frequent, and more reliable to build, test, and release software. Its emergence has made the software industry increasingly aware that development and operations must work closely together to deliver software products and services on time.

 DevOps and automation network requirements

DevOps leverages the componentization of applications in small applets (or microservices) that can be distributed across a range of data center resources (ie public or private). Containers (for example, Docker) are becoming a popular way to quickly introduce new microservices.

Microservices and DevOps applications need to quickly configure computing and storage network resources to run quickly, scale as needed, execute with high reliability and secure services. The network needs management tools to meet the needs of development and automation—reducing downtime and processing complexity without the need to send Opex data.

The network is responsible for quickly configuring the appropriate resources for DevOps applications and playing a key role in protecting and managing these fast-migrating applications. However, the agility and rapid change requirements of microservices challenge the capabilities of traditional networks. The decomposition of the application means that there are too many moving parts of the manual network - so network automation is crucial. The ability to pre-test network resources using DevOps is important to reduce application deployment time (for example, returning to repair network issues). Basic ideal: Developers don't have to worry about network resources, including IP addresses or firewall rules.

 SDN, DevOps and the place where automation meets

A software-defined network optimizes the development and automation of the network, enabling IT organizations deploying complex applications to quickly deliver network resources and services, including security policies. SDN supports centralized management of the network and shifts the (manual) configuration challenges from personnel to technology, reducing operational costs.

The SDN-based network can automatically detect traffic changes and select path data obtained through the network according to the application type, quality of service, and security rules. Software control plane management and hidden network complexity can make 10,000 switches look like one. SDN can instruct the network to provide services consistent with its associated applications and support rapid deployment of a large number of new applications and microservices.

SDN provides the ability to automate network processes to quickly deliver network/secure resources to DevOps applications. It can reduce operational costs by moving the (manual) configuration challenge from people to technology. Many ultra-large-scale cloud providers - including Google, Apple, Facebook and Microsoft - have deployed SDN technology to help automate the configuration and management of their networks. IT leaders should consider deploying SDN to meet the changing needs of their DevOps team and related applications.

Talk about SDN operation and maintenance work, SDN has so many advantages, then the operation and maintenance work will be very easy? SDN operation and maintenance work mainly includes two aspects, one is daily operation and maintenance, and the other is engineering projects. The daily operation and maintenance work is similar to the traditional network operation and maintenance, on-duty monitoring, first- and second-line fault resolution, and communication with various departments.

The focus is on cross-sectoral communication. Traditional network operation and maintenance because many devices and functions are bundled with each other, the related function functions are not open to the outside world, and only the device suppliers themselves are clear. Therefore, operation and maintenance is often a closed department, and there will not be too much intersection with development. But after entering the era of SDN, the operation and maintenance will involve many departments, such as testing, research and development. At this time, the operation and maintenance are no longer closed. Need to look at this position from a new perspective, you need to interact with the network engineers in the development department and testing department in advance. This is also in line with the requirements of DevOps. That is, in order to deliver software products and services on time, development and operations must work closely together.

The tools used in SDN operation and maintenance are similar to traditional network operation and maintenance, mainly Cacti, Smokeping, Nagios, and Zabbix. But now more open source, open source can promote the development of SDN and network technology. O&M engineers can learn more about the network. For the network to have more autonomy, engineers can also do secondary development on open source software according to their own needs. More traditional closed operation and maintenance greatly reduces network operation and maintenance costs and improves operation and maintenance efficiency.

SDN Automation Operation and Maintenance

Operation and maintenance include three stages: alarm monitoring, change, and troubleshooting. Before introducing the alarm, talk about the SLO and SLI that the operation and maintenance personnel need to care about. Second, it will briefly analyze monitoring, analysis, change and troubleshooting.

 Operation and maintenance service quality design

In traditional network operation and maintenance, network engineers pay attention to SLA, but as an operation and maintenance person, they will pay attention to SLO and SLI. We need to find out what the quality of service indicators are and set goals based on the indicators. SLI is a carefully defined measurement indicator that determines what to measure based on different system characteristics. SLI determination is a very complex process. SLI should answer what is the indicator to be measured, how the system state is when measuring, how to summarize the measurement indicators, whether the measurement index can describe the quality of service, and the reliability of the measurement index. The main focus is on performance, availability, quality, internal metrics, and factors. The SLO (Service Level Objective) specifies the desired state of the functionality provided by the service. The SLO should contain all the information that describes what the service should offer. The service provider uses it to specify the expected state of the system; the developer writes the code to implement; the customer relies on the SLO for business judgment. Not mentioned in the SLO, what happens if the target does not reach? Network latency, packet loss rate, and end-to-end can be used as metrics. We use this metric to develop an SLO.

The SLA is a contract involving both parties and both parties must agree to and abide by the contract. When it is necessary to provide external services, SLA is a very important quality of service signal, requiring simultaneous intervention by both the product and the legal department.

 Monitoring alarms

SDN can perform whiter box monitoring, that is, monitor the performance status of the system by monitoring the internal performance indicators of the system. From the southbound interface, SDN only needs to monitor a few protocols, and the monitoring is relatively simple, and it can be changed with the API changes in the face of business changes. The main complexity is concentrated on the control plane and service orchestration. The monitoring industry mainly focuses on the control plane robustness, user service status and consistency of control forwarding. In large networks, a large number of path calculations and re-optimizations due to underlying link failures require timely control and fast response. The web interface for the end user will in turn require real-time response and analysis of various request and configuration changes.

The monitoring and alarm design in the operation and maintenance system usually starts from the bottom layer and is designed from top to bottom, followed by storage, function module development, upper alarm channel and user side. From the way of collection, it is necessary to choose whether to adopt centralized or decentralized according to the network architecture. If there are more forwarding nodes in the network, then centralized mode cannot be used in this case. It is necessary to develop different regional distribution collections, including storage, according to their own business distribution points. Deploy central storage and distributed storage. After the collection is collected, it will be synchronized to the central storage in real time. At the same time, it needs to be backed up after being stored locally.

The function module collects the original data at the bottom layer and performs an intermediate layer from the monitoring alarm to the alarm channel according to the rules of the original system. This allows network administrators to make custom rules based on their own network conditions.

After getting the raw data, how to better display the data and synchronize the useful information in real time. Real-time alarms in SDN are not only forwarded at the bottom of the traditional network. Now it can monitor the service system and network elements in real time (the stability of the operating system). After the alarm information is available, it can be classified before the next alarm analysis can be performed.

 Log statistical analysis

Log statistical analysis, most of the companies now use ELK to analyze. The software can be developed differently according to its own business.

The log includes the entire SDN system. From the upper control system, the middle operating system, storage, service orchestration, the underlying forwarding network element, and the final underlying transmission. In the traditional network, the operation and maintenance personnel will not care, and will only care about network equipment.

 Traffic statistics analysis

Now network management systems and operation and maintenance personnel pay attention to device traffic and port traffic. SDN needs to pay attention to the entire link port, and more importantly, traffic. The biggest feature of SDN is that it can be associated with the business system and can view all service-related traffic information through the operation and maintenance system.

 Change

In a traditional network, it is difficult to have a unified configuration template due to the different needs of the service and the network. Various temporary configurations are set up on different devices. Today's network maintenance personnel are afraid to delete the settings of the previous operation and maintenance personnel. Over time, changes in people, equipment, and demand can cause a disconnect between configuration and actual conditions. SDN basically got rid of the device configuration problem. Infrastructure data can be implemented on the GUI through self-discovery and initial definition. The service data is implemented through the GUI and the API. When the software is upgraded, the front-end and back-end of the control plane, the service orchestration, and the components of the underlying controller can be upgraded separately or uniformly and have no obvious impact on forwarding.

 Automated troubleshooting

SDN troubleshooting is more combined with Devops and solved by software. A good fault handling system is capable of self-healing and correlation analysis. When multiple warnings occur, how to make these warnings automatically correlate and then generate a really useful one. The self-healing of the fault is that after the association, the fault can be self-healing without human intervention.




Cisco Pass Report View More >

CCIE RS Written
Oct 22, 2018
CCIE RS Written
CCIE RS Written
Oct 21, 2018
CCIE RS Written
CCIE RS Written
Oct 20, 2018
CCIE RS Written
CCIE RS Written
Oct 19, 2018
CCIE RS Written
CCIE Wireless Lab
Oct 19, 2018
CCIE Wireless Lab
CCIE RS Written
Oct 19, 2018
CCIE RS Written
CCIE RS Written
Oct 18, 2018
CCIE RS Written
CCIE Data Center Written
Oct 18, 2018
CCIE Data Center Written
CCIE RS Written
Oct 18, 2018
CCIE RS Written
CCIE RS Written
Oct 17, 2018
CCIE RS Written