Calgary RHCE

A linux and open source technology blog.

Connect

Getting the most performance out of Openstack, and NFV

By Leave a Comment

By now, most IT staff has either had a chance to deploy OpenStack, or at least are familiar with what it is and what benefits it offers. We’ve moved past the installer race, the fragmentation of “as-a-service” components, and endless TCO calculators. The ecosystem and community has reached a maturity stage where the media and industry alike are calling OpenStack “boring“. Don’t be fooled, all of these are good things. They’re a product of fast-paced innovation seeing a settling of opinions and decision making. OpenStack has reached a maturity point that Linux also hit earlier on in its journey. As linux was (and still is) an incredibly capable and cost-effective option for an OS, OpenStack is also an incredibly capable and cost-effective option for private or public cloud. But now what? What’s next? The answer is deeper and more efficient capability, addressing more edge use-cases, and general polish and integration of all the development that’s happened to date. The low-hanging-fruit development is over, we’re deeper into the less exciting and less headline grabbing work; maximizing the assets as much as we can.

There’s been a lot of blog traffic regarding tips and tricks, technologies to consider for different use-cases, etc. Given the recent explosion in NFV development and adoption, I’ll highlight the ones that I think provide the most benefit in the area to try and cut down on the amount of reading needing to be done. Here we go:

  1. Getting the most out of your instances. This is a great summary on the options available to maximize function and performance of OpenStack instances.
  2. Helpful deployment and operations management tips. These are great suggestions on working smartly with new deployments, and maintaining them throughout the lifecycle.
  3. Operations must-have: dynamic ansible inventory for TripleO. If you’re doing ad-hoc maintenance on your cloud outside of tripleo, you’d be silly to not use ansible and its dynamic inventory.

NFV specific material:

  1. What OSP technologies should I look at to help scale and tune for network intensive workloads?
  2. Now that we know what technologies are available, if I have “x” workload, which options should I tune?
  3. OVS-DPDK with multi-queue, and further NFV performance tuning:
  4. Tuning for zero packet loss in Red Hat OpenStack Platform, 3 part series:

If you have any questions, or come across anything else that you think should be added – let me know! Happy management and tuning.

Calgary OpenStack and other Meetup.com groups

By Leave a Comment

I’m a little late on this post, but last week we had an excellent presentation on OpenStack installers. Specifically, TripleO. Chris J from Red Hat gave us a good outline of TripleO’s capabilities, and kept it pretty upstream. For the presentation slide deck, see here. The group tries to keep it as vendor neutral as possible which is nice. There were a lot of questions and feedback, this is probably a topic worth going into in a little more detail, or perhaps doing some hackfest demo’ing!

Triple O by Chris J.

There’s been quite an uptick in our local OpenStack meetup group lately, it’s been fun to see and get involved with. Both this group, as well as our Red Hat User Group has brought in some high profile and very talented open source folks who’ve presented and shared their knowledge with us.

The OpenStack meetup groups across Canada have come together and created a Slack channel for easier communication and sharing among its members. If you’re interested in joining the channel, drop a comment or send me an email for an invite!

Comparing OpenStack installers

By 1 Comment

Building on a previous post, I promised I’d do a comparison of open source OpenStack installers. Choosing an installer requires more thought than most people think, as the choices are vast, and each installer offers different strengths, benefits, and trade-offs. Depending on your environment’s purpose and intended result, it would be wise to align your needs with the installers’ capabilities and limitations. Here they are:

OpenStack installerProsCons
packstack- Very easy to use
- Can get OpenStack installed in approx. 20-30 minutes
- Only one host required
- Answer-file driven, easy portability and backup of configuration
- No need for an installation host
- Fire and forget install		- No support for multiple controllers, or high availability
- Cannot provision systems from scratch (no baremetal deployment, requires installed OS)
- No API for automation or customization
- No ongoing lifecycle management (fire and forget install)
Foreman (staypuft)- GUI interface
- Supports high availability
- Discover baremetal hosts for provisioning
- Re-use of existing open source tools (foreman)
- Fire and forget install		- No ability for pre-provisioned hosts or gold images
- No flexibility of controller or compute roles
- No ongoing lifecycle management (fire and forget install)
openstack-ansible- Easy to use, slightly more complex than packstack, but still very easily consumable
- Can get OpenStack installed in approx. 45-60 minutes
- Uses linux containers for deployment
- Offers flexible environment configuration		- Minimum 5 hosts required
Fuel- GUI interface, CLI available
- Supports high availability
- Discover baremetal hosts for provisioning
- Flexible environment configuration (controller, compute, storage)
- Offers scaling of the environment, patching, and upgrades
- Highly extensible and interoperable		- Predominantly developed by one vendor, raises question of community diversity, sustainability, and rate of innovation
TripleO- Very capable CLI, and API
- Supports high availability
- Discover baremetal hosts for provisioning
- Flexible environment configuration (controller, compute, storage), with composable roles on the horizon
- Supports deployment of services into containers
- Offers scaling of the environment, patching, and upgrades
- Highly extensible and interoperable
- Based on existing OpenStack components, benefits from high-innovation rate in core OpenStack components as well as installer community innovation		- Most complex tool in the comparison, high learning curve
- No GUI currently available (slated for future release)

Now of course, this is just one man’s opinion, and this comparison may be outdated a week after it’s posted. But, generally speaking, these are the installers to look at and align your requirements with when you’re considering an install. For my OpenStack needs, my requirements can be summarized in one statement, while my use-cases can be summarized in two:

  • Requirement: My installer needs to have a strong community surrounding it. Both to anticipate and deliver the features my customers want, but also to continue to maximize the value of my OpenStack investment throughout its lifecycle and be supportive and responsive to my needs (which may or may not be the next cool and shiny thing to work on).
  • Use Case 1: Brainless, quick and easy installation to get OpenStack up and running in the shortest amount of time possible, with the least amount of resources required.
  • Use Case 2: Highly capable, fully featured deployment options, and long-term lifecycle management to manage clouds for years to come.

For use case #1, it doesn’t get any more brainless than packstack. Packstack is my installer of choice when doing basic proof of concepts or demos. I only need one host, or possibly two if I want to add another compute node. After doing a standard OS installation, a packstack all-in-one deployment is literally one command and I’m off and running 20 minutes later. I don’t need to know jack squat about OpenStack, or what my needs are, or setup and configure any other infrastructure or software.

For use case #2, my installer of choice is TripleO. The complexity is a concern, but that’s not an uncommon trait for software that’s highly innovative and one which incorporates changes frequently. I’m going to need to learn about OpenStack to understand how to manage it, there’s no avoiding that piece, it might as well start at installation time. Also, TripleO is appealing because it’s OpenStack on OpenStack (OOO). The project value is multiplied by the existing innovation rate of OpenStack and also by not being tied to any one vendor. TripleO will be around long after the vendor wars are settled, because it’s lifecycle is directly tied to OpenStack itself.

Because packstack is so easy, I’ll let you run with that one on your own. For the next part in this series, I’ll show a virtual home lab environment for an OpenStack installation, and do an install of TripleO. Lastly, and finally, I’ll show an example 9 node HA deployment with Ceph.

For Red Hat customers, Red Hat publishes a comprehensive installer best practices and supportability matrix to help you decide.