Contents
Training would take 2.5 months self paced, (5) 2 week periods with a user group meeting, or 40 hours instructor led with 40 hours of self paced lab time.
Prerequisites
Associate guide training
Associate guide virtualbox scripted install completed and running
OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a data center, all managed through a dashboard that gives administrators control while empowering users to provision resources through a web interface.
Cloud computing provides users with access to a shared collection of computing resources: networks for transfer, servers for storage, and applications or services for completing tasks.
The compelling features of a cloud are:
On-demand self-service: Users can automatically provision needed computing capabilities, such as server time and network storage, without requiring human interaction with each service provider.
Network access: Any computing capabilities are available over the network. Many different devices are allowed access through standardized mechanisms.
Resource pooling: Multiple users can access clouds that serve other consumers according to demand.
Elasticity: Provisioning is rapid and scales out or is based on need.
Metered or measured service: Cloud systems can optimize and control resource use at the level that is appropriate for the service. Services include storage, processing, bandwidth, and active user accounts. Monitoring and reporting of resource usage provides transparency for both the provider and consumer of the utilized service.
Cloud computing offers different service models depending on the capabilities a consumer may require.
SaaS: Software-as-a-Service. Provides the consumer the ability to use the software in a cloud environment, such as web-based email for example.
PaaS: Platform-as-a-Service. Provides the consumer the ability to deploy applications through a programming language or tools supported by the cloud platform provider. An example of Platform-as-a-service is an Eclipse/Java programming platform provided with no downloads required.
IaaS: Infrastructure-as-a-Service. Provides infrastructure such as computer instances, network connections, and storage so that people can run any software or operating system.
Terms such as public cloud or private cloud refer to the deployment model for the cloud. A private cloud operates for a single organization, but can be managed on-premise or off-premise. A public cloud has an infrastructure that is available to the general public or a large industry group and is likely owned by a cloud services company.
Clouds can also be described as hybrid. A hybrid cloud can be a deployment model, as a composition of both public and private clouds, or a hybrid model for cloud computing may involve both virtual and physical servers.
Cloud computing can help with large-scale computing needs or can lead consolidation efforts by virtualizing servers to make more use of existing hardware and potentially release old hardware from service. Cloud computing is also used for collaboration because of its high availability through networked computers. Productivity suites for word processing, number crunching, and email communications, and more are also available through cloud computing. Cloud computing also avails additional storage to the cloud user, avoiding the need for additional hard drives on each user's desktop and enabling access to huge data storage capacity online in the cloud.
When you explore OpenStack and see what it means technically, you can see its reach and impact on the entire world.
OpenStack is an open source software for building private and public clouds which delivers a massively scalable cloud operating system.
| OpenStack is backed up by a global community of technologists, developers, researchers, corporations and cloud computing experts. |  |
OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter. It is all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface.
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
feature rich.
To check out more information on OpenStack visit http://goo.gl/Ye9DFT
OpenStack Foundation:
The OpenStack Foundation, established September 2012, is an independent body providing shared resources to help achieve the OpenStack Mission by protecting, empowering, and promoting OpenStack software and the community around it. This includes users, developers and the entire ecosystem. For more information visit http://goo.gl/3uvmNX.
Who's behind OpenStack?
Founded by Rackspace Hosting and NASA, OpenStack has grown to be a global software community of developers collaborating on a standard and massively scalable open source cloud operating system. The OpenStack Foundation promotes the development, distribution and adoption of the OpenStack cloud operating system. As the independent home for OpenStack, the Foundation has already attracted more than 7,000 individual members from 100 countries and 850 different organizations. It has also secured more than $10 million in funding and is ready to fulfill the OpenStack mission of becoming the ubiquitous cloud computing platform. Checkout http://goo.gl/BZHJKdfor more on the same.
The goal of the OpenStack Foundation is to serve developers, users, and the entire ecosystem by providing a set of shared resources to grow the footprint of public and private OpenStack clouds, enable technology vendors targeting the platform and assist developers in producing the best cloud software in the industry.
Who uses OpenStack?
Corporations, service providers, VARS, SMBs, researchers, and global data centers looking to deploy large-scale cloud deployments for private or public clouds leveraging the support and resulting technology of a global open source community. This is just three years into OpenStack, it's new, it's yet to mature and has immense possibilities. How do I say that? All these ‘buzz words’ will fall into a properly solved jigsaw puzzle as you go through this article.
It's Open Source:
All of the code for OpenStack is freely available under the Apache 2.0 license. Anyone can run it, build on it, or submit changes back to the project. This open development model is one of the best ways to foster badly-needed cloud standards, remove the fear of proprietary lock-in for cloud customers, and create a large ecosystem that spans cloud providers.
Who it's for:
Enterprises, service providers, government and academic institutions with physical hardware that would like to build a public or private cloud.
How it's being used today:
Organizations like CERN, Cisco WebEx, DreamHost, eBay, The Gap, HP, MercadoLibre, NASA, PayPal, Rackspace and University of Melbourne have deployed OpenStack clouds to achieve control, business agility and cost savings without the licensing fees and terms of proprietary software. For complete user stories visit http://goo.gl/aF4lsL, this should give you a good idea about the importance of OpenStack.
Project history and releases overview.
OpenStack is a cloud computing project that provides an Infrastructure-as-a-Service (IaaS). It is free open source software released under the terms of the Apache License. The project is managed by the OpenStack Foundation, a non-profit corporate entity established in September 2012 to promote OpenStack software and its community.
More than 200 companies joined the project, among which are AMD, Brocade Communications Systems, Canonical, Cisco, Dell, EMC, Ericsson, Groupe Bull, HP, IBM, Inktank, Intel, NEC, Rackspace Hosting, Red Hat, SUSE Linux, VMware, and Yahoo!
The technology consists of a series of interrelated projects that control pools of processing, storage, and networking resources throughout a data center, all managed through a dashboard that gives administrators control while empowering its users to provision resources through a web interface.
The OpenStack community collaborates around a six-month, time-based release cycle with frequent development milestones. During the planning phase of each release, the community gathers for the OpenStack Design Summit to facilitate developer working sessions and assemble plans.
In July 2010 Rackspace Hosting and NASA jointly launched an open-source cloud-software initiative known as OpenStack. The OpenStack project intended to help organizations which offer cloud-computing services running on standard hardware. The first official release, code-named Austin, appeared four months later, with plans to release regular updates of the software every few months. The early code came from the NASA Nebula platform and from the Rackspace Cloud Files platform. In July 2011, Ubuntu Linux developers adopted OpenStack.
OpenStack Releases
| Release Name | Release Date | Included Components |
| Austin | 21 October 2010 | Nova, Swift |
| Bexar | 3 February 2011 | Nova, Glance, Swift |
| Cactus | 15 April 2011 | Nova, Glance, Swift |
| Diablo | 22 September 2011 | Nova, Glance, Swift |
| Essex | 5 April 2012 | Nova, Glance, Swift, Horizon, Keystone |
| Folsom | 27 September 2012 | Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder |
| Grizzly | 4 April 2013 | Nova, Glance, Swift, Horizon, Keystone, Quantum, Cinder |
| Havana | 17 October 2013 | Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder |
| Icehouse | April 2014 | Nova, Glance, Swift, Horizon, Keystone, Neutron, Cinder, (More to be added) |
Some OpenStack users include:
PayPal / eBay
NASA
CERN
Yahoo!
Rackspace Cloud
HP Public Cloud
MercadoLibre.com
AT&T
KT (formerly Korea Telecom)
Deutsche Telekom
Wikimedia Labs
Hostalia of Telef nica Group
SUSE Cloud solution
Red Hat OpenShift PaaS solution
Zadara Storage
Mint Services
GridCentric
OpenStack is a true and innovative open standard. For more user stories, see http://goo.gl/aF4lsL.
Release Cycle
OpenStack is based on a coordinated 6-month release cycle with frequent development milestones. You can find a link to the current development release schedule here. The Release Cycle is made of four major stages:
The creation of OpenStack took an estimated 249 years of effort (COCOMO model).
In a nutshell, OpenStack has:
64,396 commits made by 1,128 contributors, with its first commit made in May, 2010.
908,491 lines of code. OpenStack is written mostly in Python with an average number of source code comments.
A code base with a long source history.
Increasing Y-O-Y commits.
A very large development team comprised of people from around the world.
For an overview of OpenStack refer to http://www.openstack.org or http://goo.gl/4q7nVI. Common questions and answers are also covered here.
Core Projects Overview
Let's take a dive into some of the technical aspects of OpenStack. Its scalability and flexibility are just some of the awesome features that make it a rock-solid cloud computing platform. The OpenStack core projects serve the community and its demands.
Being a cloud computing platform, OpenStack consists of many core and incubated projects which makes it really good as an IaaS cloud computing platform/Operating System. The following points are the main components necessary to call it an OpenStack Cloud.
OpenStack has a modular architecture with various code names for its components. OpenStack has several shared services that span the three pillars of compute, storage and networking, making it easier to implement and operate your cloud. These services - including identity, image management and a web interface - integrate the OpenStack components with each other as well as external systems to provide a unified experience for users as they interact with different cloud resources.
The OpenStack cloud operating system enables enterprises and service providers to offer on-demand computing resources, by provisioning and managing large networks of virtual machines. Compute resources are accessible via APIs for developers building cloud applications and via web interfaces for administrators and users. The compute architecture is designed to scale horizontally on standard hardware.
OpenStack Compute (Nova) is a cloud computing fabric controller (the main part of an IaaS system). It is written in Python and uses many external libraries such as Eventlet (for concurrent programming), Kombu (for AMQP communication), and SQLAlchemy (for database access). Nova's architecture is designed to scale horizontally on standard hardware with no proprietary hardware or software requirements and provide the ability to integrate with legacy systems and third party technologies. It is designed to manage and automate pools of computer resources and can work with widely available virtualization technologies, as well as bare metal and high-performance computing (HPC) configurations. KVM and XenServer are available choices for hypervisor technology, together with Hyper-V and Linux container technology such as LXC. In addition to different hypervisors, OpenStack runs on ARM.
Popular Use Cases:
Service providers offering an IaaS compute platform or services higher up the stack
IT departments acting as cloud service providers for business units and project teams
Processing big data with tools like Hadoop
Scaling compute up and down to meet demand for web resources and applications
High-performance computing (HPC) environments processing diverse and intensive workloads
In addition to traditional enterprise-class storage technology, many organizations now have a variety of storage needs with varying performance and price requirements. OpenStack has support for both Object Storage and Block Storage, with many deployment options for each depending on the use case.
OpenStack Object Storage (Swift) is a scalable redundant storage system. Objects and files are written to multiple disk drives spread throughout servers in the data center, with the OpenStack software responsible for ensuring data replication and integrity across the cluster. Storage clusters scale horizontally simply by adding new servers. Should a server or hard drive fail, OpenStack replicates its content from other active nodes to new locations in the cluster. Because OpenStack uses software logic to ensure data replication and distribution across different devices, inexpensive commodity hard drives and servers can be used.
Object Storage is ideal for cost effective, scale-out storage. It provides a fully distributed, API-accessible storage platform that can be integrated directly into applications or used for backup, archiving and data retention. Block Storage allows block devices to be exposed and connected to compute instances for expanded storage, better performance and integration with enterprise storage platforms, such as NetApp, Nexenta and SolidFire.
A few details on OpenStack’s Object Storage
OpenStack provides redundant, scalable object storage using clusters of standardized servers capable of storing petabytes of data
Object Storage is not a traditional file system, but rather a distributed storage system for static data such as virtual machine images, photo storage, email storage, backups and archives. Having no central "brain" or master point of control provides greater scalability, redundancy and durability.
Objects and files are written to multiple disk drives spread throughout servers in the data center, with the OpenStack software responsible for ensuring data replication and integrity across the cluster.
Storage clusters scale horizontally simply by adding new servers. Should a server or hard drive fail, OpenStack replicates its content from other active nodes to new locations in the cluster. Because OpenStack uses software logic to ensure data replication and distribution across different devices, inexpensive commodity hard drives and servers can be used in lieu of more expensive equipment.
OpenStack Block Storage (Cinder) provides persistent block level storage devices for use with OpenStack compute instances. The block storage system manages the creation, attaching and detaching of the block devices to servers. Block storage volumes are fully integrated into OpenStack Compute and the Dashboard allowing for cloud users to manage their own storage needs. In addition to local Linux server storage, it can use storage platforms including Ceph, CloudByte, Coraid, EMC (VMAX and VNX), GlusterFS, IBM Storage (Storwize family, SAN Volume Controller, and XIV Storage System), Linux LIO, NetApp, Nexenta, Scality, SolidFire and HP (Store Virtual and StoreServ 3Par families). Block storage is appropriate for performance sensitive scenarios such as database storage, expandable file systems, or providing a server with access to raw block level storage. Snapshot management provides powerful functionality for backing up data stored on block storage volumes. Snapshots can be restored or used to create a new block storage volume.
A few points on OpenStack Block Storage:
OpenStack provides persistent block level storage devices for use with OpenStack compute instances.
The block storage system manages the creation, attaching and detaching of the block devices to servers. Block storage volumes are fully integrated into OpenStack Compute and the Dashboard allowing for cloud users to manage their own storage needs.
In addition to using simple Linux server storage, it has unified storage support for numerous storage platforms including Ceph, NetApp, Nexenta, SolidFire, and Zadara.
Block storage is appropriate for performance sensitive scenarios such as database storage, expandable file systems, or providing a server with access to raw block level storage.
Snapshot management provides powerful functionality for backing up data stored on block storage volumes. Snapshots can be restored or used to create a new block storage volume.
Today's data center networks contain more devices than ever before. From servers, network equipment, storage systems and security appliances, many of which are further divided into virtual machines and virtual networks. The number of IP addresses, routing configurations and security rules can quickly grow into the millions. Traditional network management techniques fall short of providing a truly scalable, automated approach to managing these next-generation networks. At the same time, users expect more control and flexibility with quicker provisioning.
OpenStack Networking is a pluggable, scalable and API-driven system for managing networks and IP addresses. Like other aspects of the cloud operating system, it can be used by administrators and users to increase the value of existing data center assets. OpenStack Networking ensures the network will not be the bottleneck or limiting factor in a cloud deployment and gives users real self-service, even over their network configurations.
OpenStack Networking (Neutron, formerly Quantum) is a system for managing networks and IP addresses. Like other aspects of the cloud operating system, it can be used by administrators and users to increase the value of existing data center assets. OpenStack Networking ensures the network will not be the bottleneck or limiting factor in a cloud deployment and gives users real self-service, even over their network configurations.
OpenStack Neutron provides networking models for different applications or user groups. Standard models include flat networks or VLANs for separation of servers and traffic. OpenStack Networking manages IP addresses, allowing for dedicated static IPs or DHCP. Floating IPs allow traffic to be dynamically re routed to any of your compute resources, which allows you to redirect traffic during maintenance or in the case of failure. Users can create their own networks, control traffic and connect servers and devices to one or more networks. Administrators can take advantage of software-defined networking (SDN) technology like OpenFlow to allow for high levels of multi-tenancy and massive scale. OpenStack Networking has an extension framework allowing additional network services, such as intrusion detection systems (IDS), load balancing, firewalls and virtual private networks (VPN) to be deployed and managed.
Networking Capabilities
OpenStack provides flexible networking models to suit the needs of different applications or user groups. Standard models include flat networks or VLANs for separation of servers and traffic.
OpenStack Networking manages IP addresses, allowing for dedicated static IPs or DHCP. Floating IPs allow traffic to be dynamically re-routed to any of your compute resources, which allows you to redirect traffic during maintenance or in the case of failure.
Users can create their own networks, control traffic and connect servers and devices to one or more networks.
The pluggable backend architecture lets users take advantage of commodity gear or advanced networking services from supported vendors.
Administrators can take advantage of software-defined networking (SDN) technology like OpenFlow to allow for high levels of multi-tenancy and massive scale.
OpenStack Networking has an extension framework allowing additional network services, such as intrusion detection systems (IDS), load balancing, firewalls and virtual private networks (VPN) to be deployed and managed.
OpenStack Dashboard (Horizon) provides administrators and users a graphical interface to access, provision and automate cloud-based resources. The design allows for third party products and services, such as billing, monitoring and additional management tools. Service providers and other commercial vendors can customize the dashboard with their own brand.
The dashboard is just one way to interact with OpenStack resources. Developers can automate access or build tools to manage their resources using the native OpenStack API or the EC2 compatibility API.
OpenStack Identity (Keystone) provides a central directory of users mapped to the OpenStack services they can access. It acts as a common authentication system across the cloud operating system and can integrate with existing backend directory services like LDAP. It supports multiple forms of authentication including standard username and password credentials, token-based systems, and Amazon Web Services log in credentials such as those used for EC2.
Additionally, the catalog provides a query-able list of all of the services deployed in an OpenStack cloud in a single registry. Users and third-party tools can programmatically determine which resources they can access.
The OpenStack Identity Service enables administrators to:
Configure centralized policies across users and systems
Create users and tenants and define permissions for compute, storage, and networking resources by using role-based access control (RBAC) features
Integrate with an existing directory, like LDAP, to provide a single source of authentication across the enterprise
The OpenStack Identity Service enables users to:
List the services to which they have access
Make API requests
Log into the web dashboard to create resources owned by their account
OpenStack Image Service (Glance) provides discovery, registration and delivery services for disk and server images. Stored images can be used as a template. They can also be used to store and catalog an unlimited number of backups. The Image Service can store disk and server images in a variety of back-ends, including OpenStack Object Storage. The Image Service API provides a standard REST interface for querying information about disk images and lets clients stream the images to new servers.
Capabilities of the Image Service include:
Administrators can create base templates from which their users can start new compute instances
Users can choose from available images, or create their own from existing servers
Snapshots can also be stored in the Image Service so that virtual machines can be backed up quickly
A multi-format image registry, the 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)
qcow2 (Qemu/KVM)
VMDK (VMWare)
OVF (VMWare, others)
To checkout the complete list of Core and Incubated projects under OpenStack check out OpenStack’s Launchpad Project Page here : http://goo.gl/ka4SrV
OpenStack APIs are compatible with Amazon EC2 and Amazon S3 and thus client applications written for Amazon Web Services can be used with OpenStack with minimal porting effort.
Governance
OpenStack is governed by a non-profit foundation and its board of directors, a technical committee and a user committee.
The foundation's stated mission is by providing shared resources to help achieve the OpenStack Mission by Protecting, Empowering, and Promoting OpenStack software and the community around it, including users, developers and the entire ecosystem. Though, it has little to do with the development of the software, which is managed by the technical committee - an elected group that represents the contributors to the project, and has oversight on all technical matters.
Conceptual Architecture
The OpenStack project as a whole is designed to deliver a massively scalable cloud operating system. To achieve this, each of the constituent services are designed to work together to provide a complete Infrastructure-as-a-Service (IaaS). This integration is facilitated through public application programming interfaces (APIs) that each service offers (and in turn can consume). While these APIs allow each of the services to use another service, it also allows an implementer to switch out any service as long as they maintain the API. These are (mostly) the same APIs that are available to end users of the cloud.
Conceptually, you can picture the relationships between the services as so:
Dashboard ("Horizon") provides a web front end to the other OpenStack services
Compute ("Nova") stores and retrieves virtual disks ("images") and associated metadata in Image ("Glance")
Network ("Neutron") provides virtual networking for Compute.
Block Storage ("Cinder") provides storage volumes for Compute.
Image ("Glance") can store the actual virtual disk files in the Object Store("Swift")
All the services authenticate with Identity ("Keystone")
This is a stylized and simplified view of the architecture, assuming that the implementer is using all of the services together in the most common configuration. It also only shows the "operator" side of the cloud -- it does not picture how consumers of the cloud may actually use it. For example, many users will access object storage heavily (and directly).
Logical Architecture
This picture is consistent with the conceptual architecture above:
End users can interact through a common web interface (Horizon) or directly to each service through their API
All services authenticate through a common source (facilitated through keystone)
Individual services interact with each other through their public APIs (except where privileged administrator commands are necessary)
In the sections below, we'll delve into the architecture for each of the services.
Dashboard
Horizon is a modular Django web application that provides an end user and administrator interface to OpenStack services.
As with most web applications, the architecture is fairly simple:
Horizon is usually deployed via mod_wsgi in Apache. The code itself is separated into a reusable python module with most of the logic (interactions with various OpenStack APIs) and presentation (to make it easily customizable for different sites).
A database (configurable as to which one) which relies mostly on the other services for data. It also stores very little data of its own.
From a network architecture point of view, this service will need to be customer accessible as well as be able to talk to each service's public APIs. If you wish to use the administrator functionality (i.e. for other services), it will also need connectivity to their Admin API endpoints (which should be non-customer accessible).
Compute
Nova is the most complicated and distributed component of OpenStack. A large number of processes cooperate to turn end user API requests into running virtual machines. Below is a list of these processes and their functions:
nova-api accepts and responds to end user compute API calls. It supports OpenStack Compute API, Amazon's EC2 API and a special Admin API (for privileged users to perform administrative actions). It also initiates most of the orchestration activities (such as running an instance) as well as enforces some policy (mostly quota checks).
The nova-compute process is primarily a worker daemon that creates and terminates virtual machine instances via hypervisor's APIs (XenAPI for XenServer/XCP, libvirt for KVM or QEMU, VMwareAPI for VMware, etc.). The process by which it does so is fairly complex but the basics are simple: accept actions from the queue and then perform a series of system commands (like launching a KVM instance) to carry them out while updating state in the database.
nova-volume manages the creation, attaching and detaching of z volumes to compute instances (similar functionality to Amazon’s Elastic Block Storage). It can use volumes from a variety of providers such as iSCSI or Rados Block Device in Ceph. A new OpenStack project, Cinder, will eventually replace nova-volume functionality. In the Folsom release, nova-volume and the Block Storage service will have similar functionality.
The nova-network worker daemon is very similar to nova-compute and nova-volume. It accepts networking tasks from the queue and then performs tasks to manipulate the network (such as setting up bridging interfaces or changing iptables rules). This functionality is being migrated to Neutron, a separate OpenStack project. In the Folsom release, much of the functionality will be duplicated between nova-network and Neutron.
The nova-schedule process is conceptually the simplest piece of code in OpenStack Nova: it takes a virtual machine instance request from the queue and determines where it should run (specifically, which compute server host it should run on).
The queue provides a central hub for passing messages between daemons. This is usually implemented with RabbitMQ today, but could be any AMQP message queue (such as Apache Qpid). New to the Folsom release is support for Zero MQ.
The SQL database stores most of the build-time and runtime state for a cloud infrastructure. This includes the instance types that are available for use, instances in use, networks available and projects. Theoretically, OpenStack Nova can support any database supported by SQL-Alchemy but the only databases currently being widely used are SQLite3 (only appropriate for test and development work), MySQL and PostgreSQL.
Nova also provides console services to allow end users to access their virtual instance's console through a proxy. This involves several daemons (nova-console, nova-novncproxy and nova-consoleauth).
Nova interacts with many other OpenStack services: Keystone for authentication, Glance for images and Horizon for web interface. The Glance interactions are central. The API process can upload and query Glance while nova-compute will download images for use in launching images.
Object Store
The swift architecture is very distributed to prevent any single point of failure as well as to scale horizontally. It includes the following components:
Proxy server (swift-proxy-server) accepts incoming requests via the OpenStack Object API or just raw HTTP. It accepts files to upload, modifications to metadata or container creation. In addition, it will also serve files or container listing to web browsers. The proxy server may utilize an optional cache (usually deployed with memcache) to improve performance.
Account servers manage accounts defined with the object storage service.
Container servers manage a mapping of containers (i.e folders) within the object store service.
Object servers manage actual objects (i.e. files) on the storage nodes.
There are also a number of periodic processes which run to perform housekeeping tasks on the large data store. The most important of these is the replication services, which ensures consistency and availability through the cluster. Other periodic processes include auditors, updaters and reapers.
Authentication is handled through configurable WSGI middleware (which will usually be Keystone).
Image Store
The Glance architecture has stayed relatively stable since the Cactus release. The biggest architectural change has been the addition of authentication, which was added in the Diablo release. Just as a quick reminder, Glance has four main parts to it:
glance-api accepts Image API calls for image discovery, image retrieval and image storage.
glance-registry stores, processes and retrieves metadata about images (size, type, etc.).
A database to store the image metadata. Like Nova, you can choose your database depending on your preference (but most people use MySQL or SQLite).
A storage repository for the actual image files. In the diagram above, Swift is shown as the image repository, but this is configurable. In addition to Swift, Glance supports normal filesystems, RADOS block devices, Amazon S3 and HTTP. Be aware that some of these choices are limited to read-only usage.
There are also a number of periodic processes which run on Glance to support caching. The most important of these is the replication services, which ensures consistency and availability through the cluster. Other periodic processes include auditors, updaters and reapers.
As you can see from the diagram in the Conceptual Architecture section, Glance serves a central role to the overall IaaS picture. It accepts API requests for images (or image metadata) from end users or Nova components and can store its disk files in the object storage service, Swift.
Identity
Keystone provides a single point of integration for OpenStack policy, catalog, token and authentication.
Keystone handles API requests as well as providing configurable catalog, policy, token and identity services.
Each Keystone function has a pluggable backend which allows different ways to use the particular service. Most support standard backends like LDAP or SQL, as well as Key Value Stores (KVS).
Most people will use this as a point of customization for their current authentication services.
Network
Neutron provides "network connectivity as a service" between interface devices managed by other OpenStack services (most likely Nova). The service works by allowing users to create their own networks and then attach interfaces to them. Like many of the OpenStack services, Neutron is highly configurable due to its plug-in architecture. These plug-ins accommodate different networking equipment and software. As such, the architecture and deployment can vary dramatically. In the above architecture, a simple Linux networking plug-in is shown.
neutron-server accepts API requests and then routes them to the appropriate Neutron plug-in for action.
Neutron plug-ins and agents perform the actual actions such as plugging and unplugging ports, creating networks or subnets and IP addressing. These plug-ins and agents differ depending on the vendor and technologies used in the particular cloud. Neutron ships with plug-ins and agents for: Cisco virtual and physical switches, NEC OpenFlow products, Open vSwitch, Linux bridging, the Ryu Network Operating System, and VMware NSX.
The common agents are L3 (layer 3), DHCP (dynamic host IP addressing) and the specific plug-in agent.
Most Neutron installations will also make use of a messaging queue to route information between the neutron-server and various agents as well as a database to store networking state for particular plug-ins.
Neutron will interact mainly with Nova, where it will provide networks and connectivity for its instances.
Block Storage
Cinder separates out the persistent block storage functionality that was previously part of OpenStack Compute (in the form of nova-volume) into its own service. The OpenStack Block Storage API allows for manipulation of volumes, volume types (similar to compute flavors) and volume snapshots.
cinder-api accepts API requests and routes them to cinder-volume for action.
cinder-volume acts upon the requests by reading or writing to the Cinder database to maintain state, interacting with other processes (like cinder-scheduler) through a message queue and directly upon block storage providing hardware or software. It can interact with a variety of storage providers through a driver architecture. Currently, there are drivers for IBM, SolidFire, NetApp, Nexenta, Zadara, linux iSCSI and other storage providers.
Much like nova-scheduler, the cinder-scheduler daemon picks the optimal block storage provider node to create the volume on.
Cinder deployments will also make use of a messaging queue to route information between the cinder processes as well as a database to store volume state.
Like Neutron, Cinder will mainly interact with Nova, providing volumes for its instances.
More Content To be Added ...
OpenStack Compute gives you a tool to orchestrate a cloud, including running instances, managing networks, and controlling access to the cloud through users and projects. The underlying open source project's name is Nova, and it provides the software that can control an Infrastructure-as-a-Service (IaaS) cloud computing platform. It is similar in scope to Amazon EC2 and Rackspace Cloud Servers. OpenStack Compute does not include any virtualization software; rather it defines drivers that interact with underlying virtualization mechanisms that run on your host operating system, and exposes functionality over a web-based API.
Hypervisors
OpenStack Compute requires a hypervisor and Compute controls the hypervisors through an API server. The process for selecting a hypervisor usually means prioritizing and making decisions based on budget and resource constraints as well as the inevitable list of supported features and required technical specifications. The majority of development is done with the KVM and Xen-based hypervisors. Refer to http://wiki.openstack.org/HypervisorSupportMatrix http://goo.gl/n7AXnC for a detailed list of features and support across the hypervisors.
With OpenStack Compute, you can orchestrate clouds using multiple hypervisors in different zones. The types of virtualization standards that may be used with Compute include:
KVM- Kernel-based Virtual Machine (visit http://goo.gl/70dvRb)
LXC- Linux Containers (through libvirt) (visit http://goo.gl/Ous3ly)
QEMU- Quick EMUlator (visit http://goo.gl/WWV9lL)
UML- User Mode Linux (visit http://goo.gl/4HAkJj)
VMWare vSphere4.1 update 1 and newer (visit http://goo.gl/0DBeo5)
Xen- Xen, Citrix XenServer and Xen Cloud Platform (XCP) (visit http://goo.gl/yXP9t1)
Bare Metal- Provisions physical hardware via pluggable sub-drivers. (visit http://goo.gl/exfeSg)
Users and Tenants (Projects)
The OpenStack Compute system is designed to be used by many
different cloud computing consumers or customers, basically
tenants on a shared system, using role-based access assignments.
Roles control the actions that a user is allowed to perform. In
the default configuration, most actions do not require a
particular role, but this is configurable by the system
administrator editing the appropriate policy.json
file that
maintains the rules. For example, a rule can be defined so that
a user cannot allocate a public IP without the admin role. A
user's access to particular images is limited by tenant, but the
username and password are assigned per user. Key pairs granting
access to an instance are enabled per user, but quotas to
control resource consumption across available hardware resources
are per tenant.
While the original EC2 API supports users, OpenStack Compute adds the concept of tenants. Tenants are isolated resource containers forming the principal organizational structure within the Compute service. They consist of a separate VLAN, volumes, instances, images, keys, and users. A user can specify which tenant he or she wishes to be known as by appending :project_id to his or her access key. If no tenant is specified in the API request, Compute attempts to use a tenant with the same ID as the user
For tenants, quota controls are available to limit the:
Number of volumes which may be created
Total size of all volumes within a project as measured in GB
Number of instances which may be launched
Number of processor cores which may be allocated
Floating IP addresses (assigned to any instance when it launches so the instance has the same publicly accessible IP addresses)
Fixed IP addresses (assigned to the same instance each time it boots, publicly or privately accessible, typically private for management purposes)
Images and Instances
This introduction provides a high level overview of what images and instances are and description of the life-cycle of a typical virtual system within the cloud. There are many ways to configure the details of an OpenStack cloud and many ways to implement a virtual system within that cloud. These configuration details as well as the specific command-line utilities and API calls to perform the actions described are presented in the Image Management and Volume Management chapters.
Images are disk images which are templates for virtual machine file systems. The OpenStack Image Service is responsible for the storage and management of images within OpenStack.
Instances are the individual virtual machines running on physical compute nodes. The OpenStack Compute service manages instances. Any number of instances maybe started from the same image. Each instance is run from a copy of the base image so runtime changes made by an instance do not change the image it is based on. Snapshots of running instances may be taken which create a new image based on the current disk state of a particular instance.
When starting an instance a set of virtual resources known as a flavor must be selected. Flavors define how many virtual CPUs an instance has and the amount of RAM and size of its ephemeral disks. OpenStack provides a number of predefined flavors which cloud administrators may edit or add to. Users must select from the set of available flavors defined on their cloud.
Additional resources such as persistent volume storage and public IP address may be added to and removed from running instances. The examples below show the cinder-volume service which provide persistent block storage as opposed to the ephemeral storage provided by the instance flavor.
Here is an example of the life cycle of a typical virtual system within an OpenStack cloud to illustrate these concepts.
Initial State
Images and Instances
The following diagram shows the system state prior to
launching an instance. The image store fronted by the Image
Service has some number of predefined images. In the
cloud, there is an available compute node with available vCPU,
memory and local disk resources. Plus there are a number of
predefined volumes in the
cinder-volume service.
Figure 2.1. Base image state with no running instances
Launching an instance
To launch an instance, the user selects an image, a flavor,
and other optional attributes. In this case the selected
flavor provides a root volume (as all flavors do) labeled vda in
the diagram and additional ephemeral storage labeled vdb in the
diagram. The user has also opted to map a volume from the
cinder-volume
store to the third virtual disk, vdc, on this
instance.
Figure 2.2. Instance creation from image and run time state
The OpenStack system copies the base image from the image
store to local disk which is used as the first disk of the
instance (vda). Having small images will result in faster start
up of your instances as less data needs to be copied across the
network. The system also creates a new empty disk image to
present as the second disk (vdb). Be aware that the second disk
is an empty disk with an emphemeral life as it is destroyed when
you delete the instance. The compute node attaches to the
requested cinder-volume
using iSCSI and maps this to the third
disk (vdc) as requested. The vCPU and memory resources are
provisioned and the instance is booted from the first drive. The
instance runs and changes data on the disks indicated in red in
the diagram.
There are many possible variations in the details of the scenario, particularly in terms of what the backing storage is and the network protocols used to attach and move storage. One variant worth mentioning here is that the ephemeral storage used for volumes vda and vdb in this example may be backed by network storage rather than local disk. The details are left for later chapters.
End State
Once the instance has served its purpose and is deleted all state is reclaimed, except the persistent volume. The ephemeral storage is purged. Memory and vCPU resources are released. And of course the image has remained unchanged throughout.
Figure 2.3. End state of image and volume after instance exits
Once you launch a VM in OpenStack, there's something more going on in the background. To understand what's happening behind the dashboard, lets take a deeper dive into OpenStack’s VM provisioning. For launching a VM, you can either use the command-line interfaces or the OpenStack dashboard.
