CCIE Evolving Technologies – Cloud Performance and Reliability

February 8, 2017 at 2:39 pm

Evolving

Here is my latest installment in the complimentary CCIE Evolving Technologies training that all candidates must master for any CCIE written exam.

CCIE Evolving Technologies – Cloud Performance

Cloud technologies can cause great enhancements in the performance of your enterprise IT needs, or, they can cause nightmares. Understand that due to virtualization, contention for cloud resources, if not properly managed (especially in multitenant environments) can make performance unacceptable.

There are numerous public cloud providers who sell cloud server instances, typically by the hour and priced based on the memory (DRAM) size of the instance. In such an environment, an 8 Gbyte instance might cost roughly eight times as much as a 1 Gbyte instance. Other resources, such as CPUs, are scaled and priced according to the memory size.

The result can be a consistent price/performance ratio, with some discounts to encourage the use of larger systems. Some providers allow you to pay a premium for a larger allotment of CPU resources (a “high-CPU instance”). Other resource usage may also be monetized, such as network throughput and storage.

Cloud technologies provide the unique ability for dynamic capacity allocation. Companies can increase server instances as needed, in reaction to real load. This can also be done automatically via the cloud API, based on metrics from performance monitoring software. A small business or start-up can grow from a single small instance to thousands, without a detailed capacity planning study as would be expected in enterprise environments.

Storage in the cloud can be an area of concern since when compared to local disk, performance can vary considerably. As a result, some storage services allow an IOPS rate to be purchased when reliable performance is desired.

Fortunately, OS virtualization features great enhancements in performance. Have you ever virtualized Windows, providing the bare minimum of required RAM and witnessed it outperform tradition systems installs with dramatically more RAM. This is an excellent aspect of cloud computing.

CCIE Evolving Technologies – Cloud Reliability

While cloud performance is quite tricky and can be a risk or great reward, reliability thanks to the cloud, tends to be a much more reward based proposition.

Contingency planning efforts for continuity of operations and disaster recovery are concerned with designing and implementing cloud architectures that provide run-time reliability, operational resiliency, and automated recovery when interruptions are encountered, regardless of origin.

The technologies features in IT clouds today help ensure this and include:

  • Resource Pooling
  • Resource Reservation
  • Hypervisor Clustering
  • Redundant Storage

While these technologies address basic failover and availability demands, more specialized and complex approaches include:

  • Dynamic Failure Detection and Recovery
  • Zero Downtime

These help establish resilient cloud architectures that act as pillars for enterprise cloud solutions.

CCENT ICND1 100-105 Exam Cram Premium Edition and Practice Test

Evolving Technologies – Scripting

January 2, 2017 at 5:00 pm

scripting

Network management tools often create more frustration for network engineers than problem they can solve. This is true for a number of reasons, including:

  • Many of them are difficult to install and maintain
  • They are often proprietary and support only a single vendor
  • They often lack scalability and reliability

As a result, many engineers give up and instead rely on the command-line interface (CLI) to manage individual switches. An increasing number of network engineers stretch the limitations of those tools by writing scripts in TCL, Perl, Python or other languages.

Of course these engineers are not writing sophisticated software, just scripts that allow them to scale certain tasks, such as reconfiguring multiple switches using a screen scraping of CLI commands.

Scripting is a critical component of many Software Defined Networking (SND) implementations – including that of Cisco Systems with the Application Centric Infrastructure (ACI).

We know that in this technology, Cisco likes to use REST as the Northbound API. Yet Cisco engineers prefer to use Python instead of sending plain vanilla REST calls. This is because Python allows the parsing of command line options and configurations. Of course it is possible to use Python with sample scripts to turn XML into REST calls, but this approach requires formatting the XML configuration files according to the ACI object model. This results in scripts that are shared requiring administrators to have knowledge of this ACI object model.

The Python SDK for ACI permits the creation of scripts with configuration files and command line options that anyone skilled in networking can use. The ACI SDK provides models that enable you to perform all the operations that the Cisco ACI fabric offers with several advantages:

  • Python can parse configuration files in whichever format you prefer
  • The SDK APIs can be identical over time, while the specific format of the XML object model can change
  • You can perform more sophisticated conditional operations, string manipulations, etc

Evolving Technologies – Northbound vs. Southbound Protocols

December 26, 2016 at 8:02 pm

This is another post from my ongoing series here at AJSNetworking regarding Evolving Technologies. This addresses the Evolving Technologies section of the CCIE Written Exams. The complete list of topics and my previous posts can be found here:

Free Evolving Technologies Training!

I think the best way to get a handle on the location of the Northbound and Southbound protocols  is to actually see them in relation to the other components. Remember, when we say network programmability, you should think Software Defined Networking (SDN). Figure 1 below makes this clear:

 Figure 1Evolving

Notice the “Northbound” APIs (protocols) communicate between your network management station running its network apps and the SDN controller. The “Southbound” APIs occur between the controller and the actual network devices themselves.

Northbound APIs

For the Northbound APIs, Cisco likes to use REST-based APIs. What is a REST-based API? A REST API, or an API that is RESTful (adheres to the constraints of REST) follows six constraints:

  • Client-Server – exists to maximize the portability of server-side functions to other platforms. This means that completely different applications, even in different languages, can use the same functions in a REST API.
  • Stateless – all state is kept client-side. The server does not retain any record of client state; results in a much more efficient SDN controller
  • Caching – just like cookies in your web browser. It is a good idea for the client to maintain a local copy of information that is commonly used; this improves performance and scalability.
  • Layered System – a REST API must be built in a way that a client interacts with it’s neighbor and does not need to see “beyond” that neighbor.
  • Uniform Interface – no matter the information retrieved, the method by which it is presented is always consistent.
  • Code-on-Demand – to transmit working code inside an API call.

A REST API is often just a Web server that accepts HTTP POSTs, GETs. These requests typically contain standard elements like XML, JSON, SOAP, or others.

Southbound APIs

What is common for the Southbound APIs? Cisco loves to keep it simple with the Command Line Interface (CLI) and Simple Network Management Protocol (SNMP).

Certainly the most well-known Southbound API is OpenFlow, but obviously there are other options available and in development. The Network Configuration Protocol (NetConf) uses Extensible Markup Language (XML) to communicate with the switches and routers to install and make configuration changes. Lisp, also promoted by ONF, is available to support flow mapping. In addition, there are more established networking protocols finding ways to run in an SDN environment, such as OSPF, MPLS, BGP, and IS-IS.