Essentials of OpenStack Administration Part 4: Cloud Design, Software-Defined Networking and Storage

Start exploring Essentials of OpenStack Administration by downloading the free sample chapter today. DOWNLOAD NOW

There are a number of open source cloud solutions such as Eucalyptus, OpenQRM, OpenNebula, and of course, OpenStack. These implementations typically share some design concepts, and services, which we’ll cover in this article — part of our ongoing series from The Linux Foundation’s Essentials of OpenStack Administration course. Download the full sample chapter now.

Design Concepts

First, cloud platforms are expected to grow: platform providers must be able to add resources at any time, with little hassle and with no downtime.

Cloud platforms also have a special interest in providing open APIs (Application Program Interfaces): this brings third-party developers, which in turn bring more users. Publicly available and well-documented APIs make this easier by the order of magnitudes.

Open APIs also ensure a basic level of flexibility and transparency, among other things making it easier for companies to decide for or against a specific platform.

RESTful interfaces are accessible via the ubiquitous HTTP protocol, making them readily scalable. It’s also easy to write software that communicates using them. Plus, many cloud platforms and providers use REST, so programmers developing for one will find it relatively easy to do it for another.

Software-Defined Networking

Historically, the networking infrastructure has been a relatively static component of data centers. Even simple things like IP address provisioning are typically manual, error-prone affairs. Modern DCs (data centers) rely on advanced functions like VLANs or trunking, but they still happen on the networking level and require manual switch configuration.

We have established that cloud platforms require end users to configure networking, such as IP address requests, private networks, and gateway access. The cloud requires this to be flexible and open, hence the term software-defined networking, or SDN.

Software-defined networking is an area of OpenStack with a lot of attention and change. The goal of software-defined networking, or SDN, is to completely manage my network from within OpenStack. There are two general approaches to deploying SDN. One is to use the existing switch architecture. The OpenStack software then uses proprietary code to make a request to the switch. The other manner of SDN implementation is to replace the control plane of the switch with open software. This solution would mean that end-to-end the communication would be open and transparent. As well, there would be no vendor lock with a particular switch manufacturer.

A similar concept is network function virtualization (NFV). Where SDN is virtualization of the network and separation of control and data plane, NFV is the virtualization of historic appliances such as routers, firewalls load balancers, and accelerators. These would be functions, then, that exist in a particular virtual machine. Some customers, such as telephone companies, can then deploy these services as virtual machines, removing the need for multiple different proprietary implementations.

Software-Defined Storage

In conventional setups, storage is typically designed around SANs (storage area networks) or SAN-like software constructs. Like conventional networking, these are often difficult and expensive to scale, and, as such, are unsuited to cloud environments.

Storage is a central part of clouds, and (you guessed it!), it must be provided to the user in fully automated fashion. Once again, the best way to achieve this is to introduce an abstraction layer in the software, a layer that needs to be scalable and fully integrated with both the cloud platform itself and the underlying storage hardware.

Flexible storage is another area essential for a cloud provider. Historically the solution was a SAN. A storage-area network uses proprietary hardware and tends to be expensive. Cloud providers are looking towards Ceph which allows for distributed access to commodity hardware across the network. Ceph uses standard network connections and allows for parallel access of thousands of clients. Without a single point of failure, it is becoming the default choice for back end storage.

In part 5 of this series, we’ll delve more into the OpenStack project: its open source community, release cycles, and use cases.

The Essentials of OpenStack Administration course teaches you everything you need to know to create and manage private and public clouds with OpenStack. Download a sample chapter today!

Read the other articles in the series:

Essentials of OpenStack Administration Part 1: Cloud Fundamentals

Essentials of OpenStack Administration Part 2: The Problem With Conventional Data Centers

Essentials of OpenStack Administration Part 3: Existing Cloud Solutions

Essentials of OpenStack Administration Part 5: OpenStack Releases and Use Cases