rackspace
DESCRIPTION
rackspaceTRANSCRIPT
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 OpenStackpowered 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 [email protected]. If you are interested in becoming a Certified Deployment or Technology partner for reference implementations, contact Scott Sanchez at [email protected].
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 highlevel 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 (codename Nova) is open source software designed to provision and manage large networks of virtual machines, creating a redundant and scalable cloudcomputing 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 (codenamed 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 realtime data storage system, but rather a longterm 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 (codenamed 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 backend 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 multiformat 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 (HyperV), VDI (VirtualBox), and qcow2 (Qemu/KVM).
All these services are available through a selfservice GUI as a webbased dashboard.
Key Features and CapabilitiesThe OpenStack cloud software provides many features and offers strong capabilities. This listing focuses on the enterprise usecases that work well for this reference architecture.
Feature Description
RESTbased OpenStack API Allows web services integration &automation
Brandable SelfService Dashboard
Provides ability to administer cloud and provision instances ondemand 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)
Multirole 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 ondemand 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 objectstorage 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 onpremise or offpremise 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 onpremise 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 highlevel abstraction layers. Your daytoday is automated; management tools should focus on higherorder tasks, not the mundane.
Hardware SpecificationsThe deployment model in this reference architecture describes the hardware needed for each of the three references: multinode 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 productionready clouds, able to be supported by Rackspace Cloud Builders.
In this reference architecture, we offer guidance for three deployments: a highavailability 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 multinode 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 usecase) 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 optionalbuild 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.
Multinode 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Ó 15KRPM 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Ó15KRPM 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, Upto 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
StorageasaService {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Ó 15KRPM 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Ó 15KRPM 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 novanetwork 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.
HighAvailability 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 novanetwork software is installed and configured on each server that is running novacompute. The purpose of spreading the network service across multiple servers is to localize the failure domain to each novacompute node. In a scenario where a novacompute 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 HighAvailability 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 interserver 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 interserver 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 Linuxbased 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 (multicabinet 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 usecase) – 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
Novacompute Compute node Current Essex Milestone KVM Hypervisor
Type Description Version Comments
hypervisor driver
Novanetwork Network services Current Essex MilestoneMultinode FlatDHCP or Multinode 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
OpenStackdashboard Django/mod_wsgi dashboard
Version compatible with current Essex milestone
With Keystone authentication
Pythonnovaclient ÒnovaÓ command line tool
Version compatible with current Essex Milestone Offers scripting support
DjangoOpenStack Dashboard Django support
Current Essex Milestone
Novascheduler Compute scheduling service Current Essex Milestone Simple and Random
schedulers provided
Novanovnc NoVNC Dashboard Component
From a branch at github.com/sleepsonthefloor/novanovnc
For Keystone tokenbased authentication
OpenStackcompute 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 preseed 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 frontend.
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 preseeded, 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 preengagement 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 stepbystep 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 standalone 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 stepbystep 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 addins that directly ties in with the OpenStack integration. Configure Nagios to create alerts from Ganglia. If you signup 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, VMnet 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 multinode configuration) by static 1:1 NAT from the public IP to the private VMnet 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 daytoday 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 tokenbased authentication, but eventually supporting plugin 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 buildtime and runtime 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 metadata 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 stepbystep 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 THIRDPARTY 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.