Cisco Blogs


Cisco Blog > Open at Cisco

Growing Up Open Source

Growing Up Open Source

I guess I got tired of waiting around for someone else to do it for me?” ~ Young Frank Walker.
tomorrowland

 

This quote was taken from the Movie “Tomorrowland.” This was the innocent response young Frank Walker gave when asked why he built a jet pack. I couldn’t find a better description to answer the common question, “How did Open Source Software come to existence?”

 Open Source reflects an open-mind. It does not only describe a type of software license, it is bigger than that, it is a culture. One way we can understand this culture, is to observe and recognize it through its impact on an individual’s life, and that’s what this post is about.

Twenty years ago, in my teenage years, I got struck by cupid’s arrow, for the internet. A network with the power to connect the world, is too strong to miss. It wasn’t long before I sacrificed a sound system capable of playing the nastiest rap tunes that were so dear to me, to buy a computer, get on the internet bandwagon.

Just like every other teenage kid, my jaw dropped every time I came across news of how teenagers can break security of sophisticated systems from their bedrooms, I was intrigued, wanted to begin but not sure where to go? I headed down to where these genius teenagers would hang out, the IRC chat rooms of EFNet.

On these chat rooms, lots of ambiguous technical terms were continuously scrolling, the one that caught my eyes, ended with the letter X (Linux).. It took me some time to realize that LinuX is not really a hacking tool, it is nothing but an Operating System.

slackware

Completely clueless but extremely determined, my mission in life was installing Slackware Linux on my Desktop. Bear in mind, that was 1994, so installing Linux was not as easy as today, I remember holding 3 floppy disks, not knowing what to do with them, one had the Kernel, one had the Master boot record and one with the Shell. After nights on end of head banging, “Linux” was installed, only with a black terminal and a blinking cursor. A 13 year old kid could not be happier.

Ten years later (2004), I found myself responsible for securing the network of an Internet Service Provider, serving thousands of subscribers. Such a responsibility was never going to be possible for a young guy of my age, without the Open Source exposure of my teenage years. That time, the challenge was different, but the solution was the same. Find a way to stop Denial of Service attacks on the network, without paying top dollar for fancy solutions.

The IRC world of Open Source enthusiasts turned into serious business, I found myself sitting in meetings with Executives, explaining why our internet gateway was receiving millions of malicious packets, filling our pipes, and how I came across an ‘experimental’ piece of software with a funny name (Zazu), to stop these attacks. As you would expect, Zazu is Open Source. The author and I collaborated to modify it and ultimately ended up with a solution that was tailored to our needs.

Fast forward again, ten years later (2015), where Open Source has gone mainstream. The culture is expanding into new frontiers. Check out OPNFV (Open Platform for NFV). This is not your common Open Source project, it’s not about writing code, it’s about system-integration, but in an Open Source fashion.

The Linux foundation is working with Network Operators and Vendors on OPNFV, a community-driven effort to integrate NFV and SDN projects.

Cisco is heavily involved in OPNFV and other Open Source initiatives like Opendaylight, Openstack…etc. The Cisco team of contributors and I attended the OPNFV first Summit in San Francisco (November 2015), we gave different presentations on different projects, My presentation was to demonstrate a use-case of how building a fancy cloud-based service is no longer a daunting task, using Open Source components included in OPNFV.

OPNFV produced their first release (Arno) as a lab-ready reference platform that integrated Openstack, Opendaylight and OVS, Previously, that required a complex setup that takes weeks or even months. These are big projects that require lots of integration work. They also offer easy programmable interfaces (REST APIs) that the community can leverage to build valuable applications. The second release of OPNFV is called (Brahmaputra).

During the OPNFV Summit, It was particularly interesting to see the cross-vendor collaboration. Ignoring commercial or technical competitiveness, I saw people from competing vendors sit together to discuss progress, hack code, and practice slides. I found this spirit to be too good to miss, so I signed up to one of the OPNFV projects (Functest) and I am happy to be back to the IRC-style meetings that I used to enjoy 20 years ago.

In conclusion, over the span of 20 years, It is obvious that Open Source was and still is the major contributor to my career development, no matter how different my scope is, whether a child’s play, a network operator or a product vendor. Open Source culture finds a way to get involved, solve problems, encourage collaboration and networking between people and bits/bytes.

Curious about getting started in Open Source. Here is  great example from OPNFV.

OS chart

Guest Blog by:

Ahmed Maged,
Cisco Engineer

Keep the conversation going on Twitter!  @amaged

 

* https://en.wikipedia.org/wiki/Hacker_%28term%29#Hacker_definition_controversy

Tags: , , , , , ,

OpenStack Summit – Vote Now Speaking Sessions and Topics

You know the drill. It’s one of the great things about the OpenStack Summit. Unlike most other conferences, where organizers single-handedly set the agenda based on what they think you want to hear, the OpenStack Summit agenda is based on what you actually want to hear.

Curious about containers? Intrigued by NFV? Wondering what’s next on the Neutron roadOpenStack Austinmap? Tell them with your votes. Go to the OpenStack Foundation page and choose the sessions that are most interesting to you.It’s easy, it’s fun, and there is no limit to how many sessions you can vote for.*

But here’s the catch: The Foundation received more than 1,200 talk submissions this time. 1,200!!!

Do you have time to read through them all?

Of course not.

Read More »

Tags: , , , ,

What You Missed at OpenStack Tokyo

IMG_1015IMG_1165IMG_1024IMG_0977

What You Missed at OpenStack Summit

The OpenStack community gathered in Tokyo for the 12th-Liberty release of the OpenStack platform. The Foundation reported over 5,000 attended the conference–50% for the first time. Attendees were from across the globe with 46% from APAC and 38% from North America. Job roles varied and included developers (28%), user/operators (25%), manager/architects (19%), sales/marketing (11%), and CxOs (10%).

OpenStack has entered the post-excitement phase, which may appear slow-moving, but reflects deeper customer engagement and a focus on the operationalization of OpenStack. Hundreds of interesting sessions were presented by community members and recorded for those who could not be there.  Check out the OpenStack Foundation Summit site for the full schedule.  Common themes included overcoming the complexity of configuring, deploying and maintaining OpenStack; retaining workload flexibility; and various approaches to manageability, scalability and extensibility. Having the Summit in Japan was an opportunity to highlight Asia-based users of OpenStack, including Kirin Brewing, Yahoo Japan, NEC, NTT Resonant, GMO Internet, CyberAgent, and Rakuten.

Below are links to the strategic and technical sessions presented on Cisco solutions at the Summit.

OpenStack Summit Sponsored Sessions:
Migrating Enterprise Applications to OpenStack
Bringing Enterprise Grade OpenStack Clouds Online Faster
Panel on Real-World Solutions for Network Function Virtualization
OpenStack: Changing the Face of Service Delivery

OpenStack Summit Technical Sessions:
Finally FDE: OpenStack Full Disk Encryption and Missing Pieces
Monitoring Docker Containers and Dockerized Applications
Neutron Firewall-as-a-Service Roadmap
OpenStack Consumption Models: Three User Perspectives
Containers Are Hot, But How Do They Network?
Kolla: Ansible Deployment + OpenStack in Docker Containers = Operator Bliss
Let’s Talk Roadmap: OpenStack Style
Ceilometer + Monasca = Ceilosca
OpenStack Federation Panel: Past, Present and Future

vBrownBag Tech Talks:
Addressing DHCP and DNS Scalability in Neutron
Multiple Ceph Storage Clusters with OpenStack
Cisco Application Centric Infrastructure and OpenStack
Best Practices for TDD Ansible and OpenStack Deployment
Nova Solver Scheduler: Optimization and Scale for OpenStack Cloud
Scalable and Reliable OpenStack Deployments on FlexPod
Troubleshooting RabbitMQ and Its Stability Improvement
Kubernetes on OpenStack
Cache Affinity Solutions for VNF/Cloud Workloads
Gluon: A Networking Service Beyond Neutron
Network Segmentation in the Cloud
Cisco UCS and Red Hat OpenStack to Streamline Deployment
Accelerate POC to Production with OpenStack on FlexPod

For more information on OpenStack at Cisco, visit www.cisco.com/go/openstack and mark your calendars for the next OpenStack Summit April 25-29 in Austin, Texas.

Tags: , , , , ,

Ceilometer + Monasca = Ceilosca

Integrating Monasca and Ceilometer seemed like a very good idea from the start. It would integrate all the OpenStack resources notifications and metrics as well as provide a unified storage layer for Monitoring and Metering, simplifying deployment at scale as well as opening the door for new solutions that weren’t possible before.

So the team set out to make it real. The implementation was carried on a three months period and all the code, unit tests and load simulator are open-source and available in the official OpenStack repo at: https://github.com/openstack/monasca-ceilometer

You can also find a replay of the presentation given at the OpenStack Summit in Tokyo: https://www.youtube.com/watch?v=5-IvVwIoCzM

There are at least two aspects that made this “marriage” titillating:

  1. Ceilometer substantially collects metrics for all the OpenStack resources that Monasca does not currently collect today.
  2. Ceilometer biggest issue is scalability and performance and that is where Monasca excels.

So, we embarked in this experiment and found a neat way to integrate the two services. The first part was the ingestion. Ceilometer has two main types of agents:

  1. Notification, a.k.a. Push model agent
  2. Central/Compute, a.k.a. Pull model agent.

Our integration with Monasca was trying to address all the cases and support both the Push and Pull model. The Compute Agent is probably the part where there is the most overlap with the Monasca Agent that is capable of polling from libvirt or other virtualization layers. We decided to extend the Publisher code in Ceilometer to integrate with Monasca client and send the “measurements” to the Monasca API.

Current Ceilometer architecture:

 

ceilmeter_arch

 

This brought two distinct advantages to the solution: the first is that we can integrate with any of the Ceilometer agents out of the box, so we can integrate data from all the data sources that Ceilometer supports now and in the future; the second is that we remove the RabbitMQ re-publishing of Samples.

This latter aspect is particularly problematic in large deployments. RabbitMQ clustering has some limitations around the 20M-mark load; this can slow down the queue performance and impact other services relying on the queue. In the Ceilosca case the samples are sent as “measurements” directly to the Monasca API, which stores them into Kafka. This allows for a different publishing rate from the storage rate increasing performance and optimization at the distinct layers.

Ceilosca Architecture:

ceilostica_arch

The Monasca Publisher in the Ceilometer agent also leverages another important aspect in publishing to Monasca, batching. The Monasca Publisher for Ceilometer has three parameters that can be set to control the batching behavior and performance:

  1. Batch count. This allows specifying how many messages are buffered and sent at in one http request to the Monasca. The Monasca API accepts “measurements” from different “metrics” without having to aggregate them and this is a huge performance boost.
  2. Batch timeout. This specifies the max time to wait before committing to the batch. Usually this is helpful in the case your message bus is only handling events and not polling, which means it is rare to get a huge amount in a short window of time.
  3. Batch checking interval. This dictates the frequency when the publisher is checking on the batch size and timeout to understand when is time to make the API POST request. Clearly this has to be carefully set to avoid repeated useless checks but cannot be too large to excessively delay the “measurements” publishing.

In several of our tests we found out the batch of 1000 messages and a timeout of 15s with a polling interval of 5s is a good compromise for a mix of Central Agent loads and OpenStack Notifications.

Deployment

We all know that deploying and running OpenStack services is not the easiest thing on Earth. For this reason we wanted to move away from sophisticated deployments and make sure the deployment was well understood and one command deployment. We wanted that everybody was able to get Ceilosca to run either on a single VM (or box), so we thought to leverage DevStack…. We know, DevStack is for development and not for scale and performance testing, but guess what; if it scales in DevStack it will scale everywhere else. Hmm, not sure you should keep this statement.

What we needed next was a deployment script; a single unified script to install everything and have it running. Fortunately, both Monasca and DevStack had already deployment scripts that we could run and leverage, the only difference? Monasca uses Ansible and DevStack uses bash … so; we created a new bash script that installs devstack and then runs ansible to deploy Monasca on top of Devstack and that did the trick. Once you download the repo just go and execute:

/deployer/ceilosca.sh

and (depending on your env) after some time you will get a full DevStack with Ceilosca in it and you are: Ready to GO!

The Devstack+Ceilosca+Monasca is the environment where we run all the tests and we had it running both on virtual machines and baremetals.

Note, we now have a complete DevStack plugin for Monasca.

Tests

As we mentioned before the tests were running on DevStack. This is to make sure that the tests are repeatable from anyone that is interested in running them. Clearly DevStack brought some restrictions that we had to deal with it. Moreover, some of us decided to run these tests in OpenStack VM and that made it even more challenging … (hey, we may even try stuff on containers later on, maybe using Kolla…). I will post the results of the these tests in 2 separate blogs relating to Private and Public Cloud.

Conclusions

Ceilosca turned out to be a significant improvement over Ceilometer both during data ingestion as well as querying. The performance gain is quite staggering going from 2x to 4x in ingestion speed and throughput as well as 11x to 18x in querying. These are the main takeaways from the extensive testing we performed:

  1. Ceilometer has an exponential performance degradation that is directly proportional to the number of tenants and resources.
  2. Ceilometer has open-ended queries that do not force the requestor to have a query params like tenant_id and time interval. This has been mitigated with the introduction of limits at the Liberty release but still the API could be significantly improved for performance.
  3. Ceilosca has very efficient batching capabilities across the entire workflow and it is configurable based on cloud deployment specific needs. Ceilosca also can select the metadata to be preserved and the one to be discarded. This is a high value feature.
  4. Monasca API are nearly twice as fast than Ceilosca implementing Ceilometer V2 API. For users that do not need backward compatibility we recommend to consume the data directly from Monasca.

Team

Cisco: Fabio Giannetti, Ken Owens, Srinivas Sakhamuri, Pauline Yeung, Steven Irvin

HP: Roland Hockmuth, Dan Dyer, Atul Aggarway, Jenny Wei, Putta Challa, Rohit Jaisway

Tags: , , , ,

Interacting with Metapod from the OpenStack CLI (or Building your OpenStack CLI VM)

Back in September 2014 Cisco acquired private OpenStack cloud service company Metacloud (http://newsroom.cisco.com/press-release-content?articleId=1489587). Initially known as Cisco OpenStack Private Cloud (COPC) and now known as Cisco Metapod®. Cisco Metapod represents one of most robust and scalable OpenStack-as-a-Service or On-Premise Public Cloud Experience offering in the market. With the agility and vision of a startup, the stability and expertise of Cisco, this is a solution and a service that helps businesses with the adoption of the agile/mode 2 or cloud native applications. Read More »

Tags: , , ,