We spend too much time talking about OpenStack.
That may seem like a surprising statement, considering the resources and energy Rackspace devotes to the OpenStack project and to our offerings built around this open cloud platform.
Rackspace has more engineers and operators talking and thinking about OpenStack than anyone in the world. Our team of OpenStack experts spend much of their time figuring out how to make OpenStack better for our customers and for the community.
We do this because we believe end users should be spending less time talking about OpenStack and more time thinking about what they want to build with it. If we do our job right, OpenStack itself should be the least interesting part of the OpenStack experience for our customers.
The reality, though, is that too many users still spend valuable time and resources worrying about how to operate their OpenStack clouds, diverting resources towards the minutiae of performing upgrades, trying to scale OpenStack and learning how to troubleshoot RabbitMQ.
While it might make sense for some to operate their own OpenStack cloud or deploy a distribution or product, for most users this is an undifferentiated task that can slow down rather than enable business.
We’re seeing a steady stream of users come to Rackspace who had previously taken the Do-It-Yourself route, only to realize along the way that being a cloud provider wasn’t in their core competency. Others come to us after using a distribution that made it easy to deploy an OpenStack product on day one but did little to help beyond that.
The Rackspace position on cloud computing is simple and consistent: users should be able to consume the cloud service, public or private, to build and run applications, but without the burden of operating the cloud infrastructure itself. The benefits of consuming resources and focusing on building applications are well understood by users of the Rackspace public cloud and of other public clouds, like Amazon Web Services.
Users don’t ask us or Amazon for instructions on how to upgrade our public clouds, or worry about how we tune resources. They instead assume an available infrastructure with services they can leverage, without having to manage. We believe private clouds should run the same way, with users who get a public cloud experience in a single-tenant infrastructure.
Leave The Operations to Us
Building and operating a cloud so our customers don’t have to means we architect and deploy not only the OpenStack services but all the other services around it, making it an enterprise grade platform.
This includes using tools that allow Rackspace to deploy a cloud, monitor for and troubleshoot issues, scale as user demands grow and upgrade as new releases become available. It also means integrating our clouds with tools that allow Rackspace to leverage the expertise that comes with managing the world’s largest public and private clouds.
One example is how we enable logging and monitoring in our Rackspace Private Cloud, a fully managed solution that can be deployed in any data center in the world. For logging, we deploy a dedicated host running the popular ELK stack with each private cloud instance.
We use Rsyslog to forward logs from every host running OpenStack services to the ELK server. Since every OpenStack project produces their own logs, it’s much more efficient to aggregate log collection locally for each RPC instance, instead of funneling them all directly to a central Rackspace logging server.
For monitoring, we leverage the Rackspace Cloud Monitoring service for our customers’ RPC implementations. Rackspace Cloud Monitoring is a home-grown service we’ve used for years to monitor our public cloud.
By extending this monitoring capability to Rackspace Private Clouds, users can take advantage of all the accumulated expertise that comes from monitoring the largest OpenStack public cloud in existence, and apply that expertise to monitoring our customers’ private cloud instances.
The Rackspace Cloud Monitoring service uses both a local agent-based monitor (agent software deployed on each physical node) as well as global (remote HTTP) checks. These checks are executed from designated polling systems in different Rackspace data centers and test the availability of core OpenStack services by running against a publically accessible endpoint.
Local monitoring is performed by the Cloud Monitoring agent, which is installed as part of the RPC deployment. The local agents connect to Cloud Monitoring instances in Rackspace data centers using Transport Layer Security to push up collected metrics.
The agents are packaged with (and trust only) a single root CA certificate directly under Rackspace control. Metric data is analyzed by the Cloud Monitoring service to trigger any defined alerts/alarm notifications and workflow (including automatic generation of tickets for the RPC Support team).
Integrating this cloud monitoring service with our public cloud and with RPC implementations hosted in Rackspace data centers is not exceedingly difficult. More challenging is integrating monitoring with RPC instances running in customer data centers or in a third party colocation facility.
But that’s precisely what we’ve done.
The sample network architecture above illustrates how an on-premise or colocation hosted private cloud deployment can be connected to Rackspace data centers. This effectively extends our Cloud Monitoring service to our customers’ clouds and most importantly, enables our Rackspace engineers to be true extensions of our customers’ IT staffs.
There is of course much more to operating a cloud than logging and monitoring. And certainly more to just being able to run a cloud software such as OpenStack. As I argued in an earlier blog post:
The choice for most users is to gamble, learning by trial and error, with a distribution vendor or inexperienced managed cloud vendor, or trusting a partner who has a proven track record with operating OpenStack clouds at scale.
Rackspace believes users should be able to consume cloud service, public or private, to build and run applications while being relieved of the burden of operating the cloud infrastructure itself.