Category Archives: Cloud

OpenStack Primer

The OpenStack submit has ended here in Texas so I decided to write a high-level overview of the OpenStack platform. Many of my customers and readers have inquired about OpenStack as the discussion around Cloud in a lot of organizations starts to heat up. So what is OpenStack? Why would I want to use OpenStack? These are some of the questions I will attempt to answer. However, I want to add a disclaimer here. I’m not an OpenStack guru and this was just as much as learning exercise for me as I hope it will be for you.

Introduction and History

OpenStack was a collection of open source technologies that formed a cloud computing framework that created large pools of compute, networking and storage resources that are centrally managed by a Dashboard while empowering users to provision resources. It also has a command line interpreter and large collection of APIs which makes is highly customizable when it comes to meeting the needs of an organization. As an open technology that goal of OpenStack was to promote collaboration between developers and partners in the spirit of transparency.

OpenStack started back in 2010. It was created by Rackspace and NASA as an answer to Amazon’s AWS public cloud offering. It was a combination of NASA’s Nebula Computing Platform and Rackspace’s Cloud Files Platform.

Organizational Overview

OpenStack is maintained by a Board of Directors, Technical Committee, and a User Committee. Known as the OpenStack Foundation. The goal of the OpenStack Foundation is to promote, maintain, and serve the entire ecosystem. Contributions can come in the form of individual developers, Manufacture development and Documentation. Each area performs a key role in the development of OpenStack and making sure the product goes through a proper development cycle.

OpenStack has a fairly simple release name format. The release names are in alphabetical order which makes it easier to determine the version and the release date. The development cycles are typically around 6 months. There release cycle is pretty straightforward.

Planning & Design: Lasts around 4-weeks with the final revision approved at the design summit

Implementation: This is when the rubber hits the road and the coding begins and the creation of the documentation. The implementation is broken up into iterations

Release Candidates: Testing and bug fixes are addressed at this stage. No more features are added after RC1 or Release Candidate 1.

Release Day: The last release candidates are published

Here is a link to the latest releases.

OpenStack Components

OpenStack is a modular platform that is manages compute, networking and storage components within the cloud infrastructure. This modular design allows for flexibility and the mobility of your application(s) using exposed APIs. These components in the OpenStack lingo are known as “Projects”. Each project has a team leader who responsible for the overall development and interoperability with vendors and partners. Projects are broken down into several terms which describes their roles in the overall process. OpenStack uses has developed a nomenclature that describes a projects status within the OpenStack organization. This link shows the project types.

OpenStack Requirements

The following is needed to build an OpenStack environment.

Host Operating System (Windows, Linux, VMware, etc.): A host operating system is needed for the compute platform. That can be a bare metal instance or a more commonly a virtualization platform like VMware, Hyper-V or KVM. And that brings me to one biggest misconceptions about OpenStack. OpenStack is not a replacement for your Hypervisor. OpenStack is a Cloud Frameworks that ties everything together into a cloud framework. You still need a host operating system.

Database Service: Like most software nowadays, a database backend is needed to power the OpenStack engine. The Database service is powered by MySQL.

Requires a Message Queuing (IMQ) Service: Message Queuing the process that allows a group of application components to form a much larger application. Without a message queuing service OpenStack components would not be able to communicate and scale. Making each component or project a separate independent application. RabbitMQ, Qpid, and ZeroMQ are the supported IMQ services.

Networking (Layer 2 and Layer 3): This is a no brainer. Without networking your users wouldn’t be able to gain access to applications or services.

Key Services:

OpenStack is made up of several key services which at a minimum are needed to deploy a OpenStack cloud environment.

  1. Compute Services (Nova)
  2. Networking Services (Nova or Neutron)
  3. Storage (Cinder or SWIFT)
  4. Identity Services (Keystone)
  5. Image Services (Glance)

Each of these services are building blocks for an OpenStack deployment. Let’s explore each of these and get a better understanding how each works.

Nova

Nova is a control plane or management layer for the compute environment. Your instance will run on top of Nova. Under Nova is your hyper-visor environment. Most hyper-visors (as I mentioned earlier) are supported including VMware, Hyper-V, and KVM. For each Hypervisor instance there is a corresponding Nova instance. So the hypervisor acts as the data layer and Nova would be the management layer.  This is an important distinction to understand going forward. For those with a Cisco background understand a control and data plane. Think of the control plan as the management layer and the data plane as the data layer in a Nova Compute environment.

Nova Networking

Nova comes with the standard networking components. From L2/L3 connectivity, DHCP services and VLANs. Networks can range from the simple flat networks to a multi-VLAN network gives most organizations flexibility they need in an OpenStack deployment. Nova runs into some scalability issues in larger deployments and that is were Neutron come into play.

Neutron Networking

Neutron is a software defined networking platform which designed for larger organizations and service providers. As mentioned before, Nova has some inebriate scalability limits which could cause challenges for large OpenStack deployments. One of the biggest was the 4096 VLAN limitations which for most organization is more than enough but it’s could be a challenge in larger service providers. It also didn’t do well from an interoperability standpoint outside of the OpenStack environment. Finally, the code base for Nova was becoming by far the largest projects and it quickly made sense to create a separate project to handle networking.

Neutron introduced support for advanced features like stretch and overlay VLANs. This opened the door for third parity plugins which allowed for seamless integration with networks outside of the OpenStack ecosystem. Some of the newer topologies introduced were VXLANs and GRE.

Keystone

Keystone is OpenStack’s Identity Service. Identity Services provide a means to authentic and authorize users in a OpenStack Cloud environment. These users can be users accessing a specific application or service. The OpenStack identity service uses a token based system as a way to authorize a user to a specific set of resources. Keystone can be standalone or has the ability to integrate with Microsoft Active Directory.

Glance

If you are familiar with any Hypervisor platform than virtual machine images. This is where OpenStack Glance comes into the picture. Images allow you to create prebuilt Virtual Machines templates for rapid deployment of Virtual Machine guests. Glance can manage images at a global or ternate level depending on the use case. Images are typically stored in a dedicated volume which can be stored locally or in the public cloud like AWS.

CINDER

Cinder is the OpenStack is a block storage platform. Its comparable to AWS’s Elastic Block Storage volumes and are persistent when an instance (Virtual Machine) is terminated (Unlike ephemeral storage which is deleted when an instance is terminated). A lot of storage vendors are contributing to the Cinder platform allowing for growth of features and functionality.

Cinder attaches and detaches volumes using iSCSI. A wide variety of features are available including Snapshots and Cloning. The feature list of Cinder will continue to grow as the project matures and better integration with manufactures like NetApp, EMC and others.

SWIFT

Swift is OpenStack object storage projects. It is similar to Amazon S3 protocol. Object storage allows applications to access web objects which makes accessing data a whole lot simpler for developers. Swift has been around since the beginning of OpenStack and can be used as a standalone product. Swift can leverage commodity servers and disk drives (JBODs) and create a distributed storage environment that is highly saleable. RAID is not needed in a SWIFT deployment but instead leverages a three replica or erasure coding data protection schemes. Three replica or object copy is pretty straightforward. There are three copies of object in the object storage environment which can be across three data centers. This is effective but also presents a lot of overhead. Erasure coding removed some of the overhead by striping the data across data centers like RAID 5 does to disk drives. This is far more efficient from a capacity standpoint. For more info on object storage please check out my post here.

Whew! That was a lot of information! As you can see, OpenStack is a very complex and extensive solution. We just barely scratched the surface. Each of these areas could be easily a week long course. My goal was to get you familiar with the terminology and understand at a high-level how OpenStack works. I personally believe as the technology matures we’ll see more adoption. At this time large organizations and service providers are the most likely candidates. Smaller shops just don’t have the time or the expertise to put in OpenStack.

How to build a Private Cloud in Seven Steps

Here are the seven steps in building a private cloud: Consolidation, Virtualization, Standardization, Service Levels, Automation, Orchestration, and Chargeback/Showback. Each or these key areas need to be achieved before you can move to a private cloud. As a CIO or IT Director, it’s important to take a step-by-step approach, however, before you jump in. It’s a good idea to perform a cloud enablement assessment of you environment to get an idea where you are at from an organization and infrastructure standpoint before you move towards you goal of a private cloud.

 

  1. Consolidation: Consolidation has also been around for a long time. It started with the move to centralized storage in the 1990’s. Both Storage Area Networks (SAN) and Network Attach Storage (NAS) started gaining momentum as a way for an organization to scale storage based on the needs of the business and not be confined to a single server. That followed a move in the server technology towards blade severs and then multicore CPU technology a few years later created an environment for dense compute in a relatively small form factor. This stage for server virtualization to take off which will cover in the next section. Last but not least, there was a move to 10Gb Ethernet networks (and now 40Gb and 100Gb) that allows for the consolidation of several 1Gb Ethernet connections with different protocols on a single wire. Cisco calls this the unified fabric. All of these need to be in place.

 

  1. Virtualization: Like consolidation, we have seen virtualization take off in the last 10 years. It’s now pretty common to see some sort of virtualization in place. Server Virtualization was the first to become adopted last decade with VMware. With most applications now supporting server virtualization there really isn’t a reason not to virtualize unless there’s unique requirement. With that said, server virtualization is a critical step in the process in moving towards the internal cloud and getting your environment as close to 100% will help in that process. Virtualization is not just confined to servers. Both network and storage now support some kind of virtualization. Software Defined Networking (SDN) elevated the network and makes it better suited for the automation and orchestration phase. Both Cisco ACI and VMware NSX are players in this space. That goes for storage as well. Software Defined Storage (SDS) technologies allow you to abstract the hardware allowing for unified management and functionality. I see both of these continuing to evolve in the coming years.

 

  1. Standardization: You can’t have a cloud strategy without standards in place. This is a critical step and is where a lot of organizations get tripped up. What are standards? Standards are any formal documentation that describes a process within an IT organization. Standards can document a procedure or could define a group of strategic vendors. Either way, standards bring predictability into the organization and prevent “one offs” in the data center.

 

  1. Service Levels: A Service Level Agreement (SLA) is an agreement that defines a group of metrics that measures the service that an IT department provides to an application owner, business unit or department. The metrics are typically uptime, response time, performance benchmarks and a change management process for planned outages. Like standards, these need to be in place.

 

  1. Automation: Automation at some level as been around in IT and the data center for years. Scripting has been the tool of choice for systems administrations to automate repetitive tasks. This freed up time to focus on higher-level tasks like project orientated work. In a private cloud this is taken to a new level. Automation at a large scale is a key but can be challenge to deploy at a large scale. The automation products you use and how it’s deployed will all depend on the standards that your organization developed and your underlying architecture.

 

  1. Orchestration: Once automation is complete, it sets the stage for the Orchestration phase. Orchestration is the ability to provision resources based on requests from the business using a self-service model. However, before that takes place a service catalog needs to be created with defined workflows. Again, this will be dependent the standards your organization has in place and the underlying architecture. Standardization on a few vendors will help in the integration and deployment process. Cisco, VMware, and other have developed orchestration. Automation and orchestration tools are typically coupled together.

 

  1. Charge Back/Show Back: This seems like a pipe dream for most IT Managers and CIOs but it’s an import step in the overall cloud strategy. The chargeback model is pretty straightforward. It is typically employed by hosting providers that charge tenants a monthly fee for resource consumption and has been around for sometime. But there has been some momentum outside of the service provider space to make IT as a profit center in the corporate enterprise. This can be an aggressive goal if IT hasn’t operated in such a role and typically results in a massive shift in thinking for the organization. The showback model tends to work better for most enterprise environments and it simpler to implement but it sill has it’s own set of challenges. The showback model allows for IT to tack resource consumption in a monetary format. This allows IT to justify costs for budgetary purposes and show who is consuming the most resources in the enterprise.

 

Technology is only a piece to the private cloud puzzle. People, process, and unfortunately politics also play a big role. Find out what the goals are of the organization and see how a move towards a private cloud will help address those challenges. Once those are defined you can approach from a technology perspective.