![\"horizon-grizzly-screenshot\"](\"http:\/\/rmohan.com\/wp-content\/uploads\/2014\/09\/horizon-grizzly-screenshot.jpg\")
<\/a><\/p>\nhe interface has user screens for:<\/p>\n
Quota and usage information
\nInstances to operate cloud virtual machines
\nVolume management to control creation, deletion and connectivity to block storage
\nImage and snapshot to upload and control virtual images, which are used to backup and boot new instances
\nAccess and security to manage keypairs and security groups (firewall rules)
\nIn addition to the user screens, it also provides an interface for cloud operators. The operator interface sees across the entire cloud and adds some configuration focused screens such as:<\/p>\n
Flavors to define service catalog offerings of CPU, memory and boot disk storage
\nProjects to provide logical groups of user accounts
\nUsers to administer user accounts
\nSystem Info to view services running in the cloud and quotas applied to projects
\nThe Grizzly edition of Horizon adds a few new features as well as significant refactoring to the user experience:<\/p>\n
Networking (see the new network topology diagrams)
\nDirect image upload to Glance
\nSupport for flavor extra specs
\nMigrate instances to other compute hosts
\nUser experience improvements
\nThe Horizon 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).<\/p>\n
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\u2019s 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 not be customer accessible).<\/p>\n
Compute
\nNova 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. Among Nova more prominent features are:<\/p>\n
Starting, resizing, stopping and querying virtual machines (\u201cinstances\u201d)
\nAssigning and removing public IP addresses
\nAttaching and detaching block storage
\nAdding, modifying and deleting security groups
\nShow instance consoles
\nSnapshot running instances
\nThere are several changes to the architecture in this release. These changes include the depreciation of nova-network and nova-volume as well as the decoupling of nova-compute from the database (through the no-compute-db feature). All of these changes are all optional (the old code is still available to be used), but are slated to disappear soon.<\/p>\n
Below is a list of these processes and their functions:<\/p>\n
nova-api is a family of daemons (nova-api, nova-api-os-compute, nova-api-ec2, nova-api-metadata or nova-api-all) that accept and respond to end user compute API calls. It supports OpenStack Compute API, Amazon\u2019s 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). Different daemons allow Nova to implement different APIs (Amazon EC2, OpenStack Compute, Metadata) or combination of APIs (nova-api starts both the EC2 and OpenStack APIs).
\nThe nova-compute process is primarily a worker daemon that creates and terminates virtual machine instances via hypervisor\u2019s APIs (XenAPI for XenServer\/XCP, libvirt for KVM or QEMU, VMwareAPI for VMware, etc.). New to the Grizzly release is the return of Hyper-V (thanks to the Cloudbase Solutions guys for the comment). 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 through nova-conductor. Please note that the use of nova-conductor is optional in this release, but does greatly increase security.
\nThe nova-scheduler process is conceptually the simplest piece of code in OpenStack Nova: take a virtual machine instance request from the queue and determines where it should run (specifically, which compute server host it should run on). In practice, it is now one of the most complex.
\nA new service called nova-conductor has been added to this release. It mediates access to the database for other daemons (only nova-compute in this release) to provide greater security.
\nThe queue provides a central hub for passing messages between daemons. This is usually implemented with RabbitMQ today, but could be any AMPQ message queue (such as Apache Qpid), or Zero MQ.
\nThe SQL database stores most of the build-time and run-time 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.
\nNova also provides console services to allow end users to access their virtual instance\u2019s console through a proxy. This involves several daemons (nova-console, nova-xvpvncproxy, nova-spicehtml5proxy and nova-consoleauth).
\nNova 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.<\/p>\n
Object Store
\nOpenStack\u2019s Object Store (\u201cSwift\u201d) is designed to provide large scale storage of data that is accessible via APIs. Unlike a traditional file server, it is completely distributed, storing multiple copies of each object to achieve greater availability and scalability. Swift provides the following user functionality:<\/p>\n
Stores and retrieves objects (files)
\nSets and modifies metadata on objects (tags)
\nVersions objects
\nServe static web pages and objects via HTTP. In fact, the diagrams in this blog post are being served out of Rackspace\u2019s Swift service.
\nThe swift architecture is very distributed to prevent any single point of failure as well as to scale horizontally. It includes the following components:<\/p>\n
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.
\nAccount servers manage accounts defined with the object storage service.
\nContainer servers manage a mapping of containers (i.e folders) within the object store service.
\nObject servers manage actual objects (i.e. files) on the storage nodes.
\nThere are also a number of periodic process 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 for the object store service is handled through configurable WSGI middleware (which will usually be Keystone).<\/p>\n
To learn more about Swift, head over to the SwiftStack website and read their OpenStack Swift Architecture.<\/p>\n
Image Store
\nOpenStack Image Store centralizes virtual images for users and other cloud services:<\/p>\n
Stores public and private images that users can utilize to start instances
\nUsers can query and list available images for use
\nDelivers images to Nova to start instances
\nSnapshots from running instances can be stored so that virtual machines can be backed
\nThe Glance architecture has stayed relatively stable since the Cactus release.<\/p>\n
glance-api accepts Image API calls for image discovery, image retrieval and image storage.
\nglance-registry stores, processes and retrieves metadata about images (size, type, etc.).
\nA database to store the image metadata. Like Nova, you can choose your database depending on your preference (but most people use MySQL or SQlite).
\nA 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.
\nThere are also a number of periodic process 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.<\/p>\n
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.<\/p>\n
Identity
\nKeystone provides a single point of integration for OpenStack policy, catalog, token and authentication:<\/p>\n
Authenticate users and issue tokens for access to services
\nStore users and tenants for a role-based access control (RBAC)
\nProvides a catalog of the services (and their API endpoints) in the cloud
\nCreate policies across users and services
\nArchitecturally, Keystone is very simple:<\/p>\n
keystone handles API requests as well as providing configurable catalog, policy, token and identity services.
\nEach 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).
\nMost people will use this as a point of customization for their current authentication services.<\/p>\n
Network
\nQuantum provides \u201cnetwork connectivity as a service\u201d between interface devices
\nmanaged by other OpenStack services (most likely Nova). It allows users to:<\/p>\n
Users can create their own networks and then attach server interfaces to them
\nPluggable backend architecture lets users take advantage of commodity gear or vendor supported equipment
\nExtensions allow additional network services like load balancing
\nLike many of the OpenStack services, Quantum is highly configurable due to it\u2019s
\nplug-in architecture. These plug-ins accommodate different networking equipment
\nand software. As such, the architecture and deployment can vary dramatically.<\/p>\n
quantum-server accepts API requests and then routes them to the
\nappropriate quantum plugin for action.
\nQuantum plugins and agents perform the actual work such as plugging and
\nunplugging ports, creating networks or subnets and IP addressing. These
\nplugins and agents differ depending on the vendor and technologies used in the
\nparticular cloud. Quantum ships with plugins and agents for: Cisco virtual and
\nphysical switches, Nicira NVP product, NEC OpenFlow products, Open vSwitch,
\nLinux bridging and the Ryu Network Operating System. Midokua also provides a plug-in for Quantum integration. The common agents are L3 (layer 3), DHCP (dynamic host IP addressing) and vendor specific plug-in agent(s).
\nMost Quantum installations will also make use of a messaging queue to route
\ninformation between the quantum-server and various agents as well as a
\ndatabase to store networking state for particular plugins.
\nQuantum will interact mainly with Nova, where it will provide networks and
\nconnectivity for its instances. Florian Otel has written very thorough article on implementing Open vSwitch is you are looking for an example of Quantum in action.<\/p>\n
Block Storage
\nCinder separates out the persistent block storage functionality that was
\npreviously part of Openstack Compute (in the form of nova-volume) into it\u2019s own
\nservice. The OpenStack Block Storage API allows for manipulation of volumes,
\nvolume types (similar to compute flavors) and volume snapshots:<\/p>\n
Create, modify and delete volumes
\nSnapshot or backup volumes
\nQuery volume status and metadata
\nIt\u2019s architecture follows the Quantum model, which provides for a northbound API and vendor plugins underneath it.<\/p>\n
cinder-api accepts API requests and routes them to cinder-volume
\nfor action.
\ncinder-volume acts upon the requests by reading or writing to the
\nCinder database to maintain state, interacting with other processes (like
\ncinder-scheduler) through a message queue and directly upon block
\nstorage providing hardware or software. It can interact with a variety of
\nstorage providers through a driver architecture. Currently, there are included drivers for IBM (Xiv, Storwize and SVC), SolidFire, Scality, Coraid appliances, RADOS block storage (Ceph), Sheepdog, NetApp, Windows Server 2012 iSCSI, HP (Lefthand and 3PAR), Nexenta appliances, Huawei (T series and Dorado storage systems), Zadara VPSA, Red Hat\u2019s GlusterFS, EMC (VNX and VMAX arrays), Xen and linux iSCSI.
\nMuch like nova-scheduler, the cinder-scheduler daemon picks the optimal
\nblock storage provider node to create the volume on.
\ncinder-backup is a new service that backs up the data from a volume (not a full snapshot) to a backend service. Currently, the only shipping backend service is Swift.
\nCinder deployments will also make use of a messaging queue to route
\ninformation between the cinder processes as well as a database to store volume state.
\nLike Quantum, Cinder will mainly interact with Nova, providing volumes for its
\ninstances.<\/p>\n
Future Projects
\nIn the next version of OpenStack (\u201cHavana\u201d which is due in the Fall of 2013), two new projects will be brought into the fold:<\/p>\n
Ceilometer is a metering project. The project offers metering information and the ability to code more ways to know what has happened on an OpenStack cloud. While it provides metering, it is not a billing project. A full billing solution requires metering, rating, and billing. Metering lets you know what actions have taken place, rating enables pricing and line items, and billing gathers the line items to create a bill to send to the consumer and collect payment. For users that also want a billing package, BillingStack is another open source project that provides payment gateway and other billing features. Ceilometer is available as a preview now.
\nHeat provides a REST API to orchestrate multiple cloud applications implementing standards such as AWS CloudFormation.
\nLooking beyond the \u201cHavana\u201d release, OpenStack is slated to see the addition of two more projects in the Spring of 2014 (for the newly named \u201cIcehouse\u201d release):<\/p>\n
Reddwarf is a database as a service offering that provides MySQL databases within OpenVZ containers upon demand.
\nIronic is the aptly named project that uses OpenStack to deploy bare metal servers instead of virtualized cloud instances.
\nThere are also a number of related but unofficial projects:<\/p>\n
Moniker that provides DNS-as-a-service for OpenStack
\nMarconi which is a message queueing service
\nSavanna to provision Hadoop clusters on OpenStack
\nMurano that allows a non-experienced user to deploy reliable Windows based environments
\nConvection is a task or workflow service to execute command sequences or long running jobs<\/p>\n","protected":false},"excerpt":{"rendered":"
As OpenStack has continued to mature, it has become more complicated in some ways but radically simplified in others. From a deployers view, each service has become easier to deploy with more sensible defaults and the proliferations of cloud distributions. However, the architects view of OpenStack has actually gotten more complicated \u2013 new services have […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[],"_links":{"self":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/3606"}],"collection":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3606"}],"version-history":[{"count":6,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/3606\/revisions"}],"predecessor-version":[{"id":3618,"href":"https:\/\/mohan.sg\/index.php?rest_route=\/wp\/v2\/posts\/3606\/revisions\/3618"}],"wp:attachment":[{"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3606"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3606"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mohan.sg\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3606"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"openstack-1\"](\"http:\/\/rmohan.com\/wp-content\/uploads\/2014\/09\/openstack-1.jpg\")
<\/a><\/p>\n![\"openstack_havana_conceptual_arch\"](\"http:\/\/rmohan.com\/wp-content\/uploads\/2014\/09\/openstack_havana_conceptual_arch.png\")
<\/a><\/p>\n![\"openstack-arch-grizzly-conceptual-v2\"](\"http:\/\/rmohan.com\/wp-content\/uploads\/2014\/09\/openstack-arch-grizzly-conceptual-v2.jpg\")
<\/a><\/p>\n![\"openstack-arch-grizzly-logical-v2\"](\"http:\/\/rmohan.com\/wp-content\/uploads\/2014\/09\/openstack-arch-grizzly-logical-v2.jpg\")
<\/a><\/p>\n