In my previous February 2015 blog post, I reviewed a new plugin for the OpenStack Neutron service plugin environment enabling customers to leverage the hardware platform ASR 1000. At that point the plugin was based on the Icehouse OpenStack version with limited feature support. Over the last several months we have been continuing the work on later OpenStack versions and introduced several new features.
Before we go into further details on these new features let’s go over the basics of the plugin and the limitations it tries to solve. When we introduced the ASR plugin for Icehouse, we were addressing the following limitations with the reference OpenStack software L3 implementation.. In such deployments, Layer 3 functionality is realized with a linux namespace router on the network node (may that be Neutron or the older nova network services). The default reference implementation is based on IPTables, which has certain limitations when it comes to Layer 3 entries (both routing and IP translations). For a typical deployment this limitation is around 10000 entries.
With the dynamic, scalable and on-demand requirements of larger cloud environments these limitations are easily hit when running an OpenStack based cloud. With these limitations in mind we developed an OpenStack plugin to support the Aggregation Services Router (or short ASR1000). The ASR1000 offers scale numbers well beyond those of software based IPTables (for further details on the scale numbers refer to the ASR1000 data sheet. By solving this one limitation we introduced several other advantages to a cloud environment a software router couldn’t offer. The ASR1000 is configured in a redundant pair offering First Hop Redundancy Protocol (FHRP) support, here we leverage the Hot-Standby Redundancy Protocol (HSRP) In addition to the resiliency advantage, the ASR1000 also provides a modular approach to offering hardware scale. Not only do we now have redundancy for the VMs gateway but also for the hardware that is used (multiple route processors, multiple forwarding engines and multiple 10G interfaces for port-channels).
For the Liberty release version of this plugin, we introduced some critical new features that enrich the ASR1000 plugin and offer more flexibility and deployment options for scalable and reliable OpenStack clouds.
These features include Heartbeat, Multi-region and cfg-agent HA support. Below a brief overview of the different features.
- Hearbeat introduces a way to handle both ASR1000 hardware and cfg-agent failures. A sync mechanism is used to continuously verify the ASR1000 is still available and responding. In case of a failure, the config agent maintains a state that is continuously updated between Unknown, Active or Dead. This feature is used to assure that the ASRs are always configured correctly even after a failure.
- A Multi-Region OpenStack environment consists of multiple, often geographically apart, OpenStack entities managed by the same Keystone service. The ASR1K plugin provides a way to share L3 capabilities across regions while leveraging independent neutron services.
- Many OpenStack environments are designed with high-availability in mind. The ASR1K platform and the plugin offer many different HA capabilities, amongst the newly added support for cfg_agent HA in a controller HA environment. Here, each controller is running its own agent in a Active/Hot-Standby manner. One Agent is responsible for the configuration of one ASR1K endpoint. In case of a failure of one of the agents, the endpoint gets rescheduled onto a different agent in the controller HA cluster.
We will highlight these in a solution like environment in an upcoming blog post. For more information feel free to reach out to openstack-asr1k-plugin@cisco.com.
Will you remember me when you rich and famous?
You go Sebby!!!!
Anna