Understanding OpenStack Hypervisor Management with Rackspace

If you're confused about the differences between OpenStack and virtualization, you're not alone. They are indeed different, and this post will describe how, review some practical ‘good fit’ use cases for OpenStack, and finally dispel a few myths about this growing open source cloud platform. To get started, a few basics: Virtualization has its roots in partitioning, which divides a single physical server into multiple logical servers. By providing a logical view of computing resources, rather than a physical view, it's possible to do a couple of very useful things: allow you to "trick" your operating systems into thinking that a group of servers is a single pool of computing resources, and allow you to run multiple operating systems simultaneously on a single machine. Once the physical server is divided, each logical server can run an operating system and applications independently. Virtualization offers redundancy and high availability built into the infrastructure, but is time consuming to add capacity to increase performance output. Getting more performance means “scaling up” or “vertical scaling” by adding more memory and processors to make the physical hypervisors perform better — but you can only add so much until you have maxed out your server hardware capacity. Cloud computing, on the other hand, changes the focus from consuming hardware to consuming shared resources as-a-service. OpenStack is an open source software used to create private and public clouds; i.e. the delivery of consumable services rather than the hardware itself. Cloud computing is attractive for several reasons, not least of which is its utility model of paying for only what you use and being able to spin up or down more resources very quickly. Because virtualization has been around for decades, it offers detailed reference architectures and common practices; OpenStack, on the other hand, offers great flexibility, but with that flexibility comes additional responsibility: you must tell it what you want it to do. For cloud in general, reference architectures and common practices are still being crafted. Operating OpenStack also requires a different infrastructure philosophy: embracing DevOps, the practice of operations and development engineers working together from design through the development process to production support. The goal of DevOps is the creation of a culture and environment where building, testing, and releasing software happens faster and more reliably.

More differences:

• Cloud resources are agnostic and disposable, while virtualization demands the care, feeding and nurturing of virtual machines. With OpenStack, you can say goodbye to rebuild and redeploy.
• Cloud offers the ability to automate what used to be manual functions — right out of the box.
• Cloud enables true self-service, freeing up your expensive resources to focus on delivering business value. Cloud lets your users provision what they need, when they need it.
• The cloud ecosystem was designed with and for end users. 

Use case personas

For those still evaluating cloud in general, or if you're not sure if OpenStack would be the right fit for your business needs, below is a short list of use case personas proven to be a successful fit for OpenStack:

• running an e-commerce platform that needs to be scalable and customer facing;
• running multi-tier distributed applications (workloads);
• running open source development tools as part of CI/CD pipeline;
• utilizing agile methodologies as an application development method;
• exposing customer facing API’s that need to be scale based on load;
• seeking to migrate legacy applications to a cloud platform and
• embarking on an organizational IT transformation looking to deploy greenfield applications.

A few more things to keep in mind as you weigh your options:

• OpenStack is NOT a hypervisor. It is a "hypervisor manager" intended to remove the worry over hardware and its management.
• Flexibility is power — the amount of flexibility OpenStack has to offer from a design and deployment aspect is the power all infrastructure admins want and need.
• Advancement through automation — you can only reap the full benefits OpenStack has to offer if you automate as much as possible.

Myth-busting OpenStack Finally, I would like to dispel a few myths about OpenStack I have heard over the years, many of which relate directly back to some of the functionality that exists on virtualization platforms today. Myth: OpenStack does not support virtual machine, or VM, migration. Facts:

• Within OpenStack, the project Nova has the capability to migrate or evacuate instances from a compute host via KVM (the suggested hypervisor).
• The specific Nova component responsible for handling this is the Nova Scheduler.
• May incur two-second blip during migration.

Myth: There is no functionality to equally consume resources across your cloud within OpenStack. Facts:

• As mentioned previously, OpenStack does have an instance migration capability — but it is not an automatic intelligent task; one would have to build automation to handle this task or execute manually.
• Cloud verses steady state compute: applications designed for disposable dynamic resources, aka the cloud, would not be affected by losing a compute node and/or instances.

Myth: All OpenStack storage solutions are not distributed. Facts:

• One of the very advanced features and projects within the OpenStack ecosystem is Cinder, which provides the capability to define multiple backends for block storage volumes. Each of those backends can point to either local ephemeral storage or a shared storage device.
• Those backends can also be defined as volume types; in turn Nova is volume type-aware.

Myth: OpenStack is not hypervisor health aware. Facts:

• OpenStack solely utilizes the service model, i.e, every component is treated as a service.  That means OpenStack is health aware of all the services running within its ecosystem.
• If a compute node or instance fails, OpenStack will NOT try to restart it; the service would be marked as ‘down’ and requests will continue to be handled by the other resources (remember cloud is all about disposable resources).

Myth: There is no solution within OpenStack to recover your data. Facts:

• Half true. Through OpenStack projects such as Cinder and Swift, you can seamlessly integrate many different external storage devices.
• But, OpenStack handles data preservation via a distributed model — important data should NOT be stored on ephemeral local storage and rather stored on some flavor of shared storage (ie EMC, NetApp, Pure)… which would be a highly available solution.

Myth: In OpenStack, if you lose a compute node, your application fails. Facts:

• OpenStack has safeguards that can be put in place to handle compute node failures.
  • The Nova scheduler component manages the distribution of instances across multiple compute nodes; see it as a balancing of resources.
  • OpenStack provides several mechanisms to accomplish this, depending on their exact needs. Examples includes:
    • ServerGroupAntiAffinityFilter filter
    • Availability zones

To succeed with OpenStack, you need assistance from certified experts who know how to architect, secure, monitor, patch and upgrade OpenStack clouds. Rackspace OpenStack Private Cloud is the answer. We blend technology and automation plus human experts to deliver ongoing architecture, security and 24x7x365 operations backed by 1,000+ OpenStack experts. Learn more about the basics of OpenStack here.