Openstack reference architecture using Cisco UCS hardware platform

There are many vendors to chose from when selecting your hardware for a complete Openstack deployment (example list of data center friendly networking vendors to look at ). And to make it even more difficult you need to think about all spectrum of vendors like networking, storage and compute.

In one of my previous posts (How to estimate hardware requirements for your private Openstack deployment) I tried to demonstrate an example hardware recommendation for an Openstack deployment. Today we are going to look at this topic once again but exploring the Cisco UCS product line instead.

The data below are taken from the Cisco PDF white paper Red Hat Openstack Architecture on Cisco UCS platform from the DesignZone for Cloud Automation Solution section on Cisco site (http://www.cisco.com/c/en/us/solutions/enterprise/data-center-designs-cloud-computing/could_automation.html).

Openstack on Cisco UCS hardware platform

Cisco is no longer only a networking vendor. With the UCS they offer as well computer platform where you can put together a server with specific hard drive size,  mount of RAM or type of CPU, interconnection card etc. An example configuration taken from the Cisco document above:

That means if we put togheter the UCS servers and the Cisco Nexus switches and Openstack software we can build a simple POC like this one:

In the white paper we can actually find a full list of hardware if you would like to build it yourself.

How to estimate hardware requirements for your private Openstack deployment

I've found this little tool on the Mirantis web page: http://www.mirantis.com/openstack-services/bom-calculator/. You  can play with it to estimate how much hardware (and money as well :)) you need to build your own private Openstack cloud infrastructure. It gives as well as an overview about potential vendors and theirs hardware.

Simple example

Top 10 data center network vendor list

In previous post was saw how handful the Gartner magic quadrants can be when learning and researching particular technology or industry trend:

• New 2012 Gartner Magic Quadrant for Cloud Infrastructure as a Service (Iaas)
• Rackspace and Brocade pushing ADX platform

Below is an another comparison chart, this time targeting vendor network equipment in data centers.

By the way I was investigating this because of the networks vendor selection on this cloud hardware deployment calculator (How to estimate hardware requirements for your private Openstack deployment ) : Dell, Cisco, HP, Arista, Juniper, Brocade.

Openstack auto provisioning with Puppet and razor

To build and operate big Openstack infrastructure solutions you have to be able to deploy and provision quickly and effectively many new servers.

This is not definitive list but as a simple task you will need to make sure that all your servers have the right OS version, all dependency packages are installed and finally that the right Openstack code (projects like nova, cinder, etc) are deployed  This list is only as very simple example what you need to think about. As a demonstration in this blog I wanted to show an example how this can be achieved with a Puppet razor tool.

Problem

How to provision and configure Openstack servers.

Analysis and results description

Openstack+puppet+razor: all details of how to run this can be found here: http://wiki.debian.org/OpenStackRazorHowto

References

1. http://puppetlabs.com/blog/introducing-razor-a-next-generation-provisioning-solution/
2. http://wiki.debian.org/OpenStackRazorHowto
3. http://purevirtual.eu/2012/07/02/how-to-get-started-with-razor-and-puppet-part-1/

Redhat application deployment automaton with Puppet module and F5

I have found this youtube video [1] on the the Puppet channel. It is an interesting presentation about the day to day issues the folks from Redhat run into when developing, managing and deploying new code for customer facing sites they host.

On of the things they mention that was difficult for them and why the started this project were:

• Lack of a cross functional team who could understand the whole architecture.
• People tend to have a limited understanding of other areas that they don't work in; Examples are SysAdmin about NetAdmin, NetAdmin about Develpers etc.
• On new depoyment a difficulties to find a team/person who can take an ownership of an issue as the problem may be above the area of their own expertise.
• Diverse and inconsistencies dev, staging and production systems.

To solve the problem they decided to refactor the architecture and automate as much as it was possible. The video [1] shows what issues they run into and how they solved it with a help of Puppet module they created and the F5 load balancer.

In short a message they convey in the presentation is: automate, standardize, and automate once again.

References

1. Managing F5 LTM with Puppet - Matthew Carpenter and Bret McMillan of Red Hat
2. http://www.youtube.com/user/PuppetLabsInc