Posts written by Walter Bentley
Since the initial launch of the OpenStack Innovation Center back in July of 2015, much work has been done. Wanted to take a moment to share the current status and some details about its next phases. If you are unfamiliar with OSIC, let me start off with some very quick background information.
Rackspace Private Cloud (RPC) powered by OpenStack has done a great job incorporating and enabling many of the great capabilities natively found within Cinder. With RPC, you gain the ability to leverage either Cinder nodes (commodity hardware using ephemeral storage exposing that storage as Block storage to your cloud) or to connect your OpenStack cloud directly to a shared storage solution via Cinder integration drivers. This is where our friends at NetApp come into play. Rackspace and NetApp have formed a unique relationship to improve the Cinder shared storage capability within OpenStack. These two teams worked together to create a repeatable, approved, and tested process to integrate NetApp storage solutions into Rackspace Private Cloud footprints within a Rackspace datacenter or at the customer's datacenter.
So you have spent months convincing your leadership to go with OpenStack. Finally the keys of the cloud are turned over to you as the Cloud Operator, and you then look over at your co-workers and say “now what”. The next set of phrases normally are something like: Now how do we best administer this cloud? Cloud is suppose to be easier, right?
Through the course of technology, infrastructure and application monitoring have changed positions. Not so long ago, monitoring was an afterthought when rolling out your new application or standing up your new rack of servers. More recently, I have observed monitoring to be one of the first considerations, to the point where it is actually in the initial project plan.
This evolution, while late in my mind, is the right direction…not just for the System Admin who gets the 2AM email alert or the application owner who on a monthly basis sadly report to his leadership 97% SLA on his app. Truly knowing how your application is affecting your infrastructure is one of the keys to a successful cloud.
With monitoring now being in an elevated position, that then leaves you to think: what should I use for monitoring? While there are plenty of software solutions in the market, many of which solve for different problems.
Last week I had the privilege to attend the OpenStack Super Bowl, aka the OpenStack Summit, in Vancouver. It was incredible just to be around so many other folks who also believe strongly in OpenStack.
As the look and feel of the cloud evolves, matures, and hedges toward main stream adoption, the Solution Architects, Developers, and Infrastructure engineers of Enterprises face the challenge to determine what technologies to consume. Should I go with something that requires vendor licensing? Or should I look to Open Source technologies, such as OpenStack? Then if you do decide that OpenStack solves for your technology needs, how best could someone layout its pros and cons to their senior leadership.
Those of us who have ever had to stand in front of their Director/CTO/CIO and figuratively 'fight' for a particular technology/product completely understands that this task is not for the meek of heart. I can remember very vividly holding index cards in my hands with bullet points, as I was attempting to lay out all the reasons why OpenStack should be the company's next major infrastructure shift. Being prepared for this conversation is critical to the overall enterprises architecture, so you need to articulate clearly why OpenStack is the best choice. You can never be too prepared. There will always be questions that you as a technology advocate, will not even think of. In my opinion, being prepared is key. So let’s start on our technology layer cake.
Recently I had the pleasure of hosting a webinar covering the Evolution of OpenStack. No matter how many times I review the history of OpenStack, I manage to learn something new. Just the idea that multiple companies, with distinct unique ideas can come together to make what I consider to be a super platform is amazing. Whether you think OpenStack is ready for prime time or not, it is hard to deny the power and disruptive nature it has in the current cloud market.
While this blog post may seem trivial on the surface, it does pack some very interesting information on how very flexible the Rackspace Cloud Files product can be. While executing another customer project, the age old question of: “Where are we going to put the database backups?” was raised. Back in the day this question only really had one solution. In the current age of the cloud, you have a few options. Since I like to live life on the edge…I raised my hand and said Cloud Files.
For those of you not familiar with Cloud Files, the easiest way to describe it is shared Object Storage. In OpenStack lingo, you could also call it shared Swift. Cloud Files is an API enabled Object storage capability found on the Rackspace Public cloud platform. In this post, we will walk you thru how easy it is to store something as simple as database backups in Cloud Files using simple automation, fronted by Ansible of course (my orchestration drug of choice). I promise this post will be short and sweet.
So after being asked to do what I considered to be a easy thing, I soon realized that it was not :(. Rather it was easy to do, just not easy to automate doing it. Figured others could benefit from my discoveries. Before getting started, please note these instructions are for RHEL, Fedora and CentOS. Some minor modifications would be needed to accommodate Ubuntu, but the same concepts apply.
In the newest release of the Rackspace Private Cloud (RPC v9.0), we made changes to the reference architecture for improved stability. These changes included a different approach for deploying the cloud internally, which may also interest anyone looking into running the Rackspace private cloud. The decision to use Ansible going forward was based on two major thoughts: ease of deployment and flexible configuration. Ansible made it very easy for Rackspace to simplify the overall deployment and give users the ability to reconfigure the deployment as needed to fit their environments. Are you familiar with Ansible? If yes…skip the next paragraph and if not, please read on.
Recently I embarked on a customer project where they wanted to dynamically create (automate) a complete application stack, starting from the base server provisioning all the way up to the application deployment. One piece of the puzzle, previously seen as something to be done manually but now considered as part of the stack, is load balancers and any configurations related to load balancing.
There was an earlier blog post from Jesse Keating on Rolling Deployments with Ansible and Cloud Load Balancers, which also covered automating creating load balancers with Ansible. The major difference with this post is adding in the additional capability to not only create the load balancer but, also a DNS record to associate with it, enable SSL termination and adding an SSL certificate to that load balancer.
One of the HOTest new projects released within the previous release of OpenStack is the Heat project. Described as a main line project part of the OpenStack Orchestration program because Heat alone is not the complete orchestration capability being developed by the community, my gut tells me we have more projects based on orchestration coming soon. Setting some base ground work on what Heat provides capability wise is important. This is covered in two quick topics, what is orchestration and what is a stack?