Rackspace   Reference   Architecture   For OpenStack

Rackspace®   Reference   Architecture   for   OpenStack™  Version 11.07.11

Version 11.07.11

SummaryThis   reference   architecture   guide   was   developed   by   Rackspace®   Cloud   Builders   based   on   the company's experiences deploying and supporting OpenStack™ clouds in production. In the spirit of open source, it is meant to share best practices and provide detailed technical information about the logical and physical architecture of a reproducible OpenStack deployment. OpenStack is a collection of open source technologies that provides a massively scalable open source cloud computing platform. Currently OpenStack focuses on two key components: OpenStack Compute, which offers computing power through virtual machine and network management,  and OpenStack Object Storage,  which is software for redundant, scalable object storage capacity. This guide includes network topology and the deployment and installation processes that are tested to work in data centers around the globe. With this document in hand you can determine next steps for building an OpenStack cloud.

Intended AudienceThis document is intended for Rackspace Certified Deployment and Technology partners, cloud service providers, hosting companies and enterprise IT departments wanting to deploy an OpenStack­powered cloud that can be supported by Rackspace in any datacenter.  This document provides the information required to acquire hardware that is the basis for an OpenStack cloud and work with solution partners to 

provision and configure an OpenStack solution. In order to make use of it, you should have some prior knowledge of cloud computing, private cloud management, hardware configuration, network topology, and data center management.

Purpose of Reference ArchitectureA reference architecture contains an identified set of hardware and network configuration that provides a tested reference for implementing a cloud computing solution. It gives a tested template solution for  architecting  a  particular   cloud   solution,   in   this   case   the  open   source  OpenStack  cloud  computing software. It also provides a common set of definitions for terms and vocabulary so the discussion about a template can be focused on implementation details, in order to provide a common working point from which  to  start.   This  Rackspace Reference Architecture for OpenStack  is  a  deployment guide with verified,   tested and designed software,  hardware and network architecture to help build OpenStack deployments that can be supported and run by Rackspace ongoing as the Rackspace® Cloud: Private Edition.

OpenStack™ the ProjectOpenStack,  originally  sponsored  by Rackspace  and NASA, is   free  open source  project   that  allows organizations to build massively scalable public and private clouds. OpenStack is a global collaboration of   developers   and   cloud   computing   technologists   producing   the   ubiquitous   open   source   cloud computing platform for public and private clouds. The project aims to deliver solutions for all types of clouds by being simple to implement, massively scalable, and feature rich. The technology consists of a  series of interrelated projects delivering various components for a cloud infrastructure solution.

About Rackspace® Cloud BuildersRackspace is   the leader  in  the hosting and cloud computing  industry,  managing more  than 65,000 servers   worldwide   with   the   value   proposition   of   exceptional   customer   service,   branded   Fanatical Support®.  The  group   that  provides   specialized  knowledge   in  deploying  and  managing  OpenStack clouds in any data center is Rackspace Cloud Builders. The people working on the Rackspace Cloud Builders team include the founders of the Rackspace Cloud, as well as the team from Anso Labs, the people involved in building NASA's Nebula Cloud. The Rackspace Cloud Builders are actively writing OpenStack software, ready to deploy and support your cloud.

Next ActionsAfter you become familiar with the details in the reference architecture, you can find out how to deploy a  Rackspace  Cloud:  Private  Edition  based on  the   reference  architecture   through Rackspace  Cloud Builders'   deployment   team   or   Certified   Deployment   Partners   by   contacting cloudbuilders@rackspace.com.   If   you   are   interested   in   becoming   a   Certified   Deployment   or Technology   partner   for   reference   implementations,   contact   Scott   Sanchez   at scott.sanchez@rackspace.com.

Terminology,   Acronyms,   and   External ReferencesIn an effort to standardize on definitions for terms, define acronyms, and offer further reading through external references, this document contains standard definitions that you may want to review prior to reading this document. Please refer to the Appendix for a list of terminology and further references.

OpenStack Logical Architecture

OpenStack   serves   both   cloud   users   and   cloud   administrators   through   a   Dashboard   interface   that provides a control panel for issuing command through the API but under the covers. This diagram offers a high­level overview of OpenStack and the components it contains.

The OpenStack architecture consists of three major components: Compute, Storage and Images. Here is a walkthrough of each component in the logical architecture.

OpenStack™ Compute (Nova)OpenStack Compute (code­name Nova)  is open source software designed to provision and manage large networks of virtual machines,  creating a redundant and scalable cloud­computing platform. It provides   the software,  control  panels,  and APIs  required   to  orchestrate  a  cloud,   including running instances, managing networks, and controlling access through users and projects. OpenStack Compute strives to be both hardware and hypervisor agnostic, currently supporting a variety of standard hardware configurations and major hypervisors.

OpenStack™ Object Storage (Swift)OpenStack Object Storage (code­named Swift) is open source software for creating redundant, scalable 

object storage using clusters of standardized servers to store petabytes of accessible data. It is not a file system or real­time data storage system, but rather a long­term storage system for a more permanent type of static data that can be retrieved, leveraged, and then updated if necessary. Primary examples of  data that best fit this type of storage model are virtual machine images, photo storage, email storage and backup archiving. Having no central "brain" or master point of control provides greater scalability, redundancy and permanence.

Objects  are  written   to  multiple  hardware  devices   in   the  data  center,  with   the  OpenStack software responsible for data replication and integrity across the cluster. Storage clusters can scale horizontally by adding new nodes. Should a node fail, OpenStack works to replicate its content from other active nodes.

OpenStack™ Image Service (Glance)OpenStack Image Service (code­named Glance) provides discovery, registration, and delivery services for virtual disk images. The Image Service API server provides a standard REST interface for querying information  about  virtual  disk   images  stored   in  a  variety of  back­end stores,   including OpenStack Object   Storage.   Clients   can   register   new   virtual   disk   images   with   the   Image   Service,   query   for information on publicly available disk images, and use the Image Service's client library for streaming virtual disk images.

A multi­format image registry, OpenStack Image Service allows uploads of private and public images in a variety of formats, including Raw, Machine (kernel/ramdisk outside of image, also known as AMI), VHD (Hyper­V), VDI (VirtualBox), and qcow2 (Qemu/KVM).

All these services are available through a self­service GUI as a web­based dashboard.

Key Features and CapabilitiesThe  OpenStack   cloud   software  provides  many   features   and  offers   strong   capabilities.  This   listing focuses on the enterprise use­cases that work well for this reference architecture.

Feature Description

REST­based OpenStack API Allows web services integration &automation

Brand­able Self­Service Dashboard

Provides   ability   to   administer   cloud   and   provision   instances  on­demand  with   an option to rebrand your site

Tenants (Projects)

Ability to create multiple accounts/projects under a master account/project. Tenants are isolated resource containers forming the principal organizational structure within OpenStack Compute (Nova)

Multi­role support

Role based access controls for user interface and API are supported out of the box. e.g.: Tenant Admin/Cloud Operator: can administer the entire cloud, Tenant User: can only manage allocated resources

Feature Description

Snapshots Allows to preserve disk state of a running instance

Quotas

Ability to assign quotas per tenant/project. There are currently quotas for number of instances which may be launched, total Number of processor cores which may be allocated, Number of volumes which may be created, Total size of all volumes within a  project  as measured  in  GB,  total  number of gigabytes,  and number of publicly accessible floating IPs.

Keypairs Provides secure authentication to your instances

Floating IPs and Fixed IPs

Floating IPs are IP addresses that can be dynamically associated with an instance. This address can be disassociated and associated with another instance at any time. A user can reserve a floating IP for their project.

Fixed IPs are assigned to an instance on creation and stay the same until the instance is explicitly terminated.

Security Groups

Security  groups contain a  named collection of  network access  rules,   like firewall policies.   These   access   rules   specify   which   incoming   network   traffic   should   be delivered to all VM instances in the group, all other incoming traffic being discarded. When launching VM instances, the project manager specifies which security groups it wants to join. It will become a member of these specified security groups when it is launched.

Custom Images Ability to upload custom images (raw disk format support), upload support via API only

VNC Access VNC client using HTML5 (WebSockets, Canvas) with encryption (wss://) support

Image Templates Allows to create new instances on­demand from a golden image

FlavorsInstance types or flavors are resources granted to virtual machines ("instancesÓ) in the cloud. Each flavor has a unique combination of disk space, memory and CPU capacity

Integrated Monitoring &Metering

Uses Ganglia and Nagios, open source monitoring tools that survey all your cloud resources and present all the information graphically

Integrated Image Service

Service for discovering, registering, and retrieving virtual machine images. It has a RESTful API that allows querying of VM image metadata as well as retrieval of the 

Feature Description

actual image. VM images made available through this service can be stored on local file  systems only.  Future option  to   include object­storage systems  like OpenStack Object Storage and other external disk storage systems.

Users   and Projects/Tenants Access

Access to images is limited by project (or tenant), access/secret are per user, keypairs are per user, and quotas are per project (or tenant).

PlanningBecause you have options for on­premise or off­premise hosting with OpenStack reference architecture, your planning process should fit into your normal business operations. However, building a private cloud  may  offer   some   surprising   juxtapositions   from  your  normal   operations.  Let's   explore   these comparisons between traditional infrastructure management and planning and private cloud planning and management.

Building a Private CloudBuilding  a  private  cloud presents  a  shift   from a model  where  everything  is  customized  to one of standardization achieving higher levels of scalability, elasticity with your existing on­premise systems. Planning is tantamount to the success of this build process.

Traditional   management   of   information   technology   conjures   images   of   static   bindings   between processes, applications, and infrastructure, a brittle set of links where breakage occurs often enough to be expected. Change is carefully planned, even with it's own change management systems and processes because   introducing  change  is   risky,  manual,   and  slow.  You also  see  heterogeneous  elements   and processes across silos in business units, divisions, and other organizational structures. Management software executes to the lowest common denominator, which is neither strategic nor elastic and it's certainly not scalable.

With an opposing set of plans, we can examine private cloud management. You can easily envision dynamic   relationships  across   all   layers   of   the   technology   stack  with  a   cloud   in  place.  Change   is constant, expected, and automated with massive standardization and high­level abstraction layers. Your day­to­day is automated; management tools should focus on higher­order tasks, not the mundane.

Hardware SpecificationsThe deployment model in this reference architecture describes the hardware needed for each of the three references: multi­node Compute, private Object Storage, and public Object Storage.

OpenStack™ Cloud System RequirementsThis section describes the system requirements for the reference architecture. These requirements are for building production­ready clouds, able to be supported by Rackspace Cloud Builders.

In this reference architecture, we offer guidance for three deployments: a high­availability Compute deployment, a compact Object Storage deployment offering redundant storage, and an Object Storage deployment with an eye towards adding nodes for additional compute and storage in the future.

Compute   multi­node   deployment  that's   elastic   and   scalable   to   enable   many   compute   nodes   for hundreds or thousands of guest VMs to run concurrently with high availability.

á Object Storage private deployment  (or archiving use­case) that offers a known amount of storage that replicated redundantly, with the proxy/object/container/account services on all machines.

Object Storage public deployment  that offers optional­build out for storage providers who want to improve cost effectiveness in splitting out a proxy layer, and installing account and container servers separately from object servers.

Multi­node Compute Requirements

            POC/Production ready Cloud

Type Description Recommendation

Controller Node(s)

Compute   (Nova) controller software

Dell R415 or Dell R515

Single socket CPU (min. needed)

8GB RAM

Qty: 2, 2.5Ó 15K­RPM 300GB SAS

Ubuntu 11.04, 11.10

R1, LSI RAID Controller

Intel NICs: 2 or more NICs of 1G or greater, based on intended workload

Compute Node(s) Hosts virtual instances Dell C6105

Dual Hex CPU

96GB RAM

Qty:12, 2.5Ó15K­RPM 300GB SAS Drives

2Sleds (4U)

Type Description Recommendation

R10, LSI RAID Controller

Ubuntu 11.04, 11.10

Intel NICs: 2 or more NICs of 1G or greater, based on intended workload

L2 Switch Cabinet Switches Cisco 3500 or 2960G

L3 Switch Aggregate Switch(es) Cisco 4948E or 4948S

iSCSI   External Storage

iSCSI   storage   for Controller Node HA

MD3200i  (storage   amount   dependent   on   amount   required   for  storing images in the Image Service)

Private Object Storage Requirements

Archiving {Private, Write Heavy, Up­to 2 Cabinet (~30 Nodes)}

Type Description Recommendation

Object Storage Node

Object   Storage   account,   container, object servers plus proxy

Dell C2100

Single Quad

8 or 12GB RAM

Qty:12, SATA 3.5Ó 2TB Drives

Qty: 2, SAS 2.5Ó 300GB Drives (internal)

No RAID

Ubuntu 10.04

Intel   1Gb   NICs:   2   or   more   NICs   of   1G   or greater, based on intended workload

L2 Switch Cabinet Switch(es) Cisco 2960G

L3 Switch Aggregate Switch(es) Cisco 4948

Public Object Storage Requirements

            Storage­as­a­Service {Public, Read/Write Heavy, Min 5 cabinets (~75 Nodes)}

            

Type Description Recommendation

Object  Storage Node

Object   Storage   account, container, object servers

Dell C2100

Single Quad

8 or 12GB RAM

Qty:12, SATA 3.5Ó 2TB Drives

Qty: 2, SAS 2.5Ó 300GB Drives (internal)

No RAID

Ubuntu 10.04

Intel 1Gb NICs: 2 or more NICs of 1G or greater, based on intended workload

Object   Proxy Node Object Storage proxy server

Dell R415 or Dell R515

Single socket CPU (min. needed)

8GB RAM

Qty: 2, 3.5Ó 15K­RPM 300GB SAS

Ubuntu 11.04, 11.10

R1, LSI RAID Controller

Intel NICs

L2 Switch Cabinet Switch(es) Cisco 2960G

L3 Switch Aggregate Switch(es)Arista 75xx (preferred)

Cisco Nexus

 

Type Description Recommendation

Bastion Server(BMC Station)

Server   to   securely   access internal cloud

Dell R415 or Dell R515

Single socket CPU (min. needed)

8GB RAM

Qty: 2, 3.5Ó 15K­RPM 300GB SAS

Ubuntu 11.04, 11.10

SSH service

Intel NICs: 2 or more NICs of 1G or greater, based on intended workload

 

Note:  You can estimate  the power and cooling usage by using Dell  Data Center  Capacity planner available   @ http://www.dell.com/content/topics/topic.aspx/global/products/pedge/topics/en/config_calculator?c=us&cs=5%2055&l=en&s=biz  .We recommend to use this tool to plan the appropriate PDU and  provide adequate cooling.

 

SAN as Storage OptionNot available at this time.

Server Preparation for OpenStack DeploymentThe   server   preparation   involves   racking,   stacking,   and   cabling   the   servers   and   network   devices according to the deployment guide. Your hardware deployment partner performs this function.

Network Design

OpenStack™ Network ModelOpenStack provides a number of network models to choose from when designing a deployment; all are described   below.   However,   for   this   reference   architecture,   the   High   Availability   DHCP   model   is described in more detail than the full list.

Flat Network Model – A network administrator specifies a subnet from which all the virtual machines 

pulls IP addresses from a pool of available fixed addresses.

Flat DHCP Network Model – The server that runs nova­network is a gateway to the compute nodes running virtual machines.

VLAN Model – The server running virtual machines (a compute node) creates a VLAN and a bridge for each project or tenant, and users access their VMs through a special VPN that must be created.

High­Availability FlatDHCP Model  (the Rackspace Cloud Builders Default)  ­ Each compute host does Network Address Translation (NAT),  DHCP, and acts  as a  gateway for  all  of   its  own virtual machines.

Rackspace   Cloud   Builders   deploy   a   High   Availability   FlatDHCP   networking   model   provided   by OpenStack. This network model requires that the nova­network software is installed and configured on each server that is running nova­compute. The purpose of spreading the network service across multiple servers   is   to   localize  the  failure  domain  to  each nova­compute node.   In  a  scenario  where a  nova­compute server is taken offline for any reason including maintenance, only the virtual instances on that server will be affected. All other instances in the private cloud will continue to serve traffic through their own network service. This is depicted in the example below.

Figure 3 High­Availability DHCP Networking Model

IP Addressing and NAT for OpenStack™ DeploymentThis   section   describes   the   types  of   networks   you  need   to   configure   to   work   with   an   OpenStack deployment.   These contain best practices for both conserving network resources and ensuring that network administrators understand the needs for networks and public IP addresses for accessing the APIs and VMs as necessary. It offers recommendations and required minimum sizes.

Management Network (RFC1918 IP Range, not publicly routable)

This network is utilized for all inter­server communications within the cloud infrastructure.

Recommended size: 255 IPs (CIDR /24)

Public Network (Publicly routable IP range)

This network is utilized for providing Public IP accessibility to the API endpoints within the cloud infrastructure.

inimum size: 8 IPs (CIDR /29)

VM Network (RFC1918 IP Range, not publicly routable)

This network is utilized for providing primary IP addresses to the cloud instances.

>Recommended size: 1024 IPs (CIDR /22)

Storage Network (RFC1918 IP Range, not publicly routable)

This network is utilized for all inter­server communications within the Object Storage infrastructure.

Recommended size: 255 IPs (CIDR /24)

Floating IP network (Publicly routable IP Range)

This network is utilized for providing Public IP accessibility to selected cloud instances.

Minimum size: 16 IPs (CIDR /28) OpenStack Software Specifications &Deployment

This section describes the software versions and combinations that work for the feature set included with this reference architecture.

Physical DeploymentNote: A bastion host, installed behind appropriate site specific security systems, will be used to access the   solution   to  perform ongoing  OpenStack  software   installation,  Ongoing operations   support   and troubleshooting.

Deployment DiagramsThis section provides diagrams of logical and physical deployment descriptions.

Compute Logical Architecture Diagram

Figure 4 Compute Logical Architecture

Controller Nodes HA:

Option   1:   Cluster   setup   w/   iSCSI   DAS   (Dell   MD3200i)   and   Coro   Sync.  (Recommended)

Option 2: Cluster Setup w/ DRBD

Networking Options:

Option1 (Recommended): Pair of bonded NICs (for redundancy) that would support Corp. and Mgmt. networks via VLAN tagging. Another pair of bonded NICS to support Public and VMnet via VLAN tagging. – Total 4 physical NIC cards

Option 2: Take Corp. and Mgmt. networks and combine them into one network. Still need 2 NICs and bonded. 1 VLAN instead of separate VLANs

Option 3: Every single network gets 2 bonded physical NICs – Total 8 NICs

L3 Switch: 4948 E or 4948 S switch (depending on what's available)

L2 Switch: 3500 or 2960G (depending on what's available)

Server Configurations:

Compute Nodes (Rule of Thumb): 4 to 8 GB RAM and 1 Spindle Per Core

Compute Node: Dell C6105, 2 Sleds, Qty:12 2.5Ó 300GB SAS Hard Drives, 96GB RAM, Dual Hex Proc – Total 4U space for 2 Sleds

Controller Node: Dell 415 or 515, 8 to 12 GB RAM, Single Socket, Qty: 2 SAS 300GB Hard drives

Compute Physical Architecture Diagram (2cabinet layout)

Figure 5 Compute Physical Architecture (Two Cabinets)

The Image Service, Glance, stores the initial Image, and for reference, the image size is displayed in MB for Linux­based images, and the sizes of Windows images are displayed in GB.

For true high availability (HA) and more Image Service storage, use external storage such as DAS as referenced above.

Compute Physical Architecture Diagram (multi­cabinet layout)

Figure 6 Compute Logical Architecture (Multiple Cabinets)

All nodes in each cabinet connect to respective cabinet switches.

Only two controller nodes and one storage array are required for entire configuration.

Use DRBD for No DAS configuration.

Object Storage Logical Architecture Diagram

Figure 7 Object Storage Logical Architecture

Object  Storage Private  Storage  (or  Archiving use­case)  –  Two Cabinet  Physical Architecture

Figure 8 Object Storage Physical Architecture (Two Cabinets)

Link speeds are for illustration purposes only; actual network links vary based on application specific needs.

All storage nodes connect to respective L2 switches in the cabinet

MLAG: multi chassis link aggregation.

All services (Object, Storage, Account and proxy) run on the Storage node in this implementation.

Object Storage Public Storage – Multiple Cabinet Physical Architecture

Figure 9 Object Storage for Public Use (Multiple Cabinets)

Link speeds are for illustration purposes only; actual network links vary based on application specific needs.

All storage nodes connect to respective L2 switches in the cabinet

MLAG: multi chassis link aggregation

Note that Proxy nodes are setup as a separate entity from the storage node to allow for better scalability in   this   architecture.  This   implementation   allows   for  maximum scalability   of   the   environment   and optimum performance

Object,  Storage  and Account  services  run  on  the  Storage node  in   this   implementation  with  Proxy service running on proxy node.

OpenStack   Software   Specifications   and DeploymentThis section lists the specific software required and the packages built for installing the software.

OpenStack Software PackagesHere is a list of the software packages expected for this implementation.

Type Description Version Comments

Nova­compute Compute   node Current Essex Milestone KVM Hypervisor

Type Description Version Comments

hypervisor driver

Nova­network Network services Current Essex MilestoneMulti­node   FlatDHCP   or Multi­node   VLAN preferred

Glance Image Registry and Delivery service Current Essex Milestone

With   Keystone   integration for   authentication   and private and public images

Keystone Authentication Service

Frozen   Compatibility Version

Will   be   frozen   at compatibility   version   until official release

OpenStack­dashboard Django/mod_wsgi dashboard

Version   compatible   with current Essex milestone

With   Keystone authentication

Python­novaclient ÒnovaÓ   command line tool

Version   compatible   with current Essex Milestone Offers scripting support

Django­OpenStack Dashboard   Django support

Current Essex Milestone  

Nova­scheduler Compute scheduling service Current Essex Milestone Simple   and   Random 

schedulers provided

Nova­novnc NoVNC Dashboard Component

From   a   branch   at github.com/sleepsonthefloor/nova­novnc

For   Keystone   token­based authentication

OpenStack­compute Base   nova   client library

Version   compatible   with current Essex milestone  

OpenStack x Nova   API extensions

Bundled   extensions   to   the base   API   to   enable Dashboard feature set

 

Deployment Tools &MethodologyDeployment of   initial  configuration   is  based on  individual  customer questionnaires   filled  out  after initial  contact.  These questionnaires collect   information such as VLAN ordering,  network interface 

bonding configuration, and IP address ranges. Rackspace Cloud Builders then uses this configuration information to pre­seed data for a deployment using the Crowbar installation tool.

Crowbar   is   an  open   source  cloud  deployment   framework  originally  developed  by  Dell   to   support OpenStack and Hadoop powered solutions.  The Crowbar  tool  provides  many deployment  services, including device discovery, PXE bootstrap services, DHCP, DNS, NTP, Nagios, Ganglia, and ongoing configuration management using a standalone Opscode Chef server.

Once information about network topology is added to Dell Crowbar, services can be configured from the integrated web front­end.

Software Installation &Configuration OptionsSoftware   installation   and   configuration   will   be   implemented   using   Dell   Crowbar.   Crowbar   is   a powerful deployment tool that bundles Opscode's Chef configuration management software, OpenStack software packages provided by Rackspace Cloud Builders, and Open Source monitoring provided by Nagios and Ganglia. Once initial network data has been pre­seeded, network proposals can be generated and accepted from the Dell Crowbar web management tool.  These proposals should be generated in accordance with the information gathered as part of the pre­engagement questionnaire.

Implementation VerificationTo complete the building of a reference cloud, the implementation is tested with a test harness.

Hardware Installation ChecklistRefer to the OpenStack Hardware Installation Guide for detailed step­by­step installation process. The Guide is available to qualified solution partners. The following list offers the items you must complete 

in order to help ensure hardware installation is completed correctly.

All cables are tested and performing properly.

Equipment placement is accurate to the final floor plan.

Cables are laid in accordance with the physical cable diagram.

Network devices are configured for proper routing and VLAN access according to the deployment guide.

All vendor defined stand­alone diagnostics are run and the results are documented.

All documents relating to the installation are collected and categorized, including original hardware orders, bills of lading, receipts, receiving inventory, and installation and test certifications.

Proper installation cleanup is performed.

OpenStack Implementation ChecklistRefer to the OpenStack Software Installation Guide for a detailed step­by­step installation process. The Guide is available to qualified solution partners.

Monitoring OpenStackSpecific   monitoring   is   available   through   the   reference   architecture.  The  major   areas   of   focus   for monitoring   are   to   help   ensure   availability   according   to   the   Service   Level   Agreements   in   your organization. Also capacity monitoring offers alerts when capacity is about to be reached. The network availability and throughput are monitored as well  as monitoring any network breaches through the perimeter security already planned.

Rackspace   Cloud   Builders   employ   Nagios   and   Ganglia   to   provide   additional   status   monitoring, performance data gathering and alerting.  Nagios   is   the primary agent   for  alerting  and node status monitoring.  Ganglia  has  performance  monitoring  add­ins   that  directly   ties   in  with   the  OpenStack integration.  Configure  Nagios   to   create   alerts   from Ganglia.   If   you   sign­up   for  Rackspace  Cloud Operations   support,  Rackspace   specialist   for  OpenStack  deployment  will   help  you   configure  your system for appropriate monitoring.

Securing OpenStackAn OpenStack cloud is using perimeter security on networks and traffic as well as controlling access by assigning security groups.

Perimeter SecurityBy default,  there are several networks set up as part of an OpenStack installation.    These networks include:

A private management network for monitoring, PXE boot, and Compute intercommunications

A private network for exposing API endpoints

A VM network for private VM IPs

A public network for VM floating IPs

Typically, the private and management networks are isolated from the Internet.  Should it be desirable to connect these networks to the Internet or to internal enterprise networks, network administrators should set up VLANs and layer 3 ACLs.  In addition, it is possible to set up routing and/or public NAT to the API endpoints per the security policy of the organization.

By default, no services are listening on the public network or on the VM network (with the exception of dnsmasq   in   the  case  of   a  FlatDHCP configuration).   Ideally,  VM­net   traffic   is   configured  on   the firewall to allow outbound Internet access through a NAT pool, but firewall rules can be put in place at the firewall as necessary.

Inbound traffic is designed to be unfiltered, with access controls via API using floating IP addresses and security groups.  Floating IP addresses are implemented (in the multi­node configuration) by static 1:1 NAT from the public IP to the private VM­net IP on the hypervisor running the instance.   This allows the ability to apply a public IP on a VM through API interaction. Security groups, detailed in the next section, control your firewalls on inbound traffic.

Security GroupsSecurity groups are used to programmatically apply IP table rules to interfaces that are exposed to the public   Internet   via   floating   IPs.   By  default,   no   traffic   is   allowed   to   IP   addresses  made  publicly accessible via floating IP API.  To allow access to public services, simple IP table rules can be saved as a set, and later referenced to apply rules to virtual machines.  These sets are called security groups.

For example, a "mysql server" security group could be created to allow traffic from 0.0.0.0/0 to port 3306/tcp.   By associating a new VM instance with this security group, global Internet access to the mysql service would be allowed.  A VM instance can belong to zero or more security groups, with the rules applying cumulatively.

Security groups can allow incoming port ranges from specific CIDR ranges over both TCP and UDP.  In addition to TCP and UDP, ICMP can be enabled or disabled on a CIDR basis, although without the ability to specify subtype.

Maintenance & UpgradesThe  following  table  describes   the  maintenance and  change management  available   from Rackspace Cloud Builders.

Here are the corresponding support models on a spectrum of Rackspace involvement in day­to­day maintenance and support.

  Type of Change Change   Control Board Members Testing Advance Notice

1Major architectural modifications. Examples include:

Lead

Customer Service Lead

Required 20 business Days

System architecture

Interfaces with other systems

Services provided by system

Security Representative

Chief Architect

Development Lead

2

Engineering changes. Examples include:

System upgrades

Physical relocation

Logical (network) relocation

Hardware upgrades

Changes to security controls

Lead

Customer Service Lead

Security Representative

Development Lead

Discretion of Change control board

Minimum 10 business Days, 15 business days preferable

3

Minor changes. Examples include:

Vulnerability patches

Security fixes

Minor configuration changes for service restoration

Replacement of failed/failing components with spares

Lead

Customer Service Lead

Unit Testing unless required by security or need for service restoration

Minimum 3 business Days, 5 days preferable.

Appendix

TerminologyCompute

OpenStack Compute is a compute service that provides server capacity in the cloud. Compute Servers come   in   different   flavors   of   memory,   disk   space,   and  CPU,   and   can   be   provisioned   in   minutes.  Interactions with Compute Servers can occur programmatically via the OpenStack Compute API or the Dashboard.

Nova

Project name for the Compute service that provisions and manages large networks of virtual machines, creating a redundant and scalable cloud computing platform.

Swift

Project  name for   the Object  Storage software  that  creates   redundant,  scalable  object   storage using clusters of standardized servers to store petabytes of accessible data. Swift is used as an inexpensive bulk storage system for programmatic object storage.

Glance

Project name for the Image Service software, which is the main image repository piece of OpenStack, it  is the place where you will be uploading your images as well as the place from which they will be consumed by the rest of the OpenStack system.

Keystone

Project name for the Identity service software, which offers an integrated identity management system for OpenStack. Initially using token­based authentication, but eventually supporting plug­in modules for   identity   storage   (LDAP,   DB,   file,   PAM,   Active   Directory,   etc...),   protocols   (SAML,   OAUTH, OpenID, etc...)

Server

A server is a virtual machine instance in the compute system. Flavor and image are requisite elements  when creating a server.

Flavor

Flavor is an available hardware configuration for a server. Each flavor has a unique combination of disk space, memory capacity and priority for CPU time.

Image

Images are your templates for creating new VMs. The project under OpenStack that stores the available images is called Glance.

Rabbit MQ

Provides robust messaging for applications. It is completely open source and based on open standard protocols.

MySQL

Datastore that stores build­time and run­time state for a cloud infrastructure.

Swift Storage Node

The node that runs Account, Container, and Object services.

Swift Proxy Node

The Swift node that runs Proxy services and accepts incoming API requests.

Swift Ring

The Swift Ring is a set of mappings of OpenStack Object Storage data to physical devices.

Keypairs

These are simple ssh keys and are your credentials for accessing any running instances. Keypairs are added and managed using the Keypairs section of the user dashboard.

Security Groups

Security groups at this time exist mostly as tags for the servers and can be consumed via the meta­data API via a simple curl command. Security groups can be specified as part of the "personality" of an instance.

External Referenceshttp://openstack.org/

http://docs.openstack.org/

https://github.com/dellcloudedge/crowbar

http://ganglia.info/

http://www.nagios.com/

http://www.drbd.org/

http://www.corosync.org/

DISCLAIMER

This document is for informational purposes only and is provided ÒAS IS.Ó  The information set forth in the document is intended as a guide and not as a step­by­step process, and does not represent an  assessment  of   any  specific  compliance  with   laws  or   regulations  or   constitute   advice.  We strongly recommend that you engage additional expertise in order to further evaluate applicable requirements for your specific environment.

RACKSPACE MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, AS TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS DOCUMENT AND RESERVES THE RIGHT TO MAKE CHANGES TO SPECIFICATIONS AND PRODUCT/SERVICES   DESCRIPTION   AT   ANY   TIME   WITHOUT   NOTICE.   RACKSPACE RESERVES   THE   RIGHT   TO   DISCONTINUE   OR   MAKE   CHANGES   TO   ITS   SERVICES OFFERINGS   AT   ANY   TIME   WITHOUT   NOTICE.   USERS   MUST   TAKE   FULL RESPONSIBILITY   FOR   APPLICATION   OF   ANY   SERVICES   AND/OR   PROCESSES MENTIONED HEREIN.   EXCEPT AS SET FORTH IN A SEPARATE WRITTEN AGREEMENT SIGNED BY AUTHORIZED SIGNATORIES OF BOTH PARTIES, RACKSPACE ASSUMES NO LIABILITY   WHATSOEVER,   AND   DISCLAIMS   ANY   EXPRESS   OR   IMPLIED   WARRANTY, RELATING   TO   ITS   SERVICES   INCLUDING,   BUT   NOT   LIMITED   TO,   THE   IMPLIED WARRANTY   OF   MERCHANTABILITY,   FITNESS   FOR   A   PARTICULAR   PURPOSE,   AND NONINFRINGEMENT.

ALTHOUGH PART OF  THIS  DOCUMENTATION EXPLAINS HOW RACKSPACE SERVICES 

MAY WORK WITH THIRD PARTY PRODUCTS, THE INFORMATION CONTAINED IN THIS DOCUMENT IS NOT DESIGNED TO WORK WITH ALL SCENARIOS. ANY USE OR CHANGES TO THIRD PARTY PRODUCTS AND/OR CONFIGURATIONS SHOULD BE MADE AT THE DISCRETION OF YOUR ADMINISTRATORS AND SUBJECT TO THE APPLICABLE TERMS AND CONDITIONS OF SUCH THIRD PARTY. RACKSPACE DOES NOT PROVIDE TECHNICAL SUPPORT   FOR   THIRD   PARTY   PRODUCTS,   OTHER   THAN   SPECIFIED   IN   A   SEPARATE WRITTEN AGREEMENT SIGNED BY AUTHORIZED SIGNATORIES OF BOTH PARTIES, AND RACKSPACE ACCEPTS NO RESPONSIBILITY FOR THIRD­PARTY PRODUCTS.

Except as expressly provided in any written license agreement from Rackspace, the furnishing of this document   does   not   give   you   any   license   to   patents,   trademarks,   copyrights,   or   other   intellectual property.

Rackspace, Rackspace logo, Fanatical Support, and other Rackspace marks mentioned in this document are either registered service marks or service marks of Rackspace US, Inc. in the United States and/or other  countries.  OpenStack and  OpenStack  logo are  either   registered   trademarks  or   trademarks  of OpenStack, LLC in the United States and/or other countries. 

All other product names and trademarks used in this document are for identification purposes only to refer to either the entities claiming the marks and names or their products, and are property of their respective owners.  We do not intend our use or display of other companies' tradenames, trademarks, or service  marks   to   imply   a   relationship  with,   or   endorsement   or   sponsorship  of   us   by,   these  other companies.

The Use of the word PARTNER

The use of the word "partner" does not imply a partnership relationship between Rackspace and any other company.

© 2011 Rackspace US, Inc.  All rights reserved.