Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

made inline code for essex arch

  • Loading branch information...
commit f1c511be84b17809a037fb8aed5f9703a8553090 1 parent 40ad6b3
@slashk authored
View
14 _posts/2012-02-21-revisit-openstack-architecture-diablo.markdown
@@ -65,11 +65,11 @@ From a network architecture point of view, this service will need to customer ac
Not much has really changed with Nova's architecture. They have added a few new helper services for EC2 compatibility and console services.
-* nova-api accepts and responds to end user compute and volume API calls. It supports OpenStack 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). In the Essex release, nova-api has been modularized, allowing for implementers to run only specific APIs.
-* 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 persistent 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](http://ceph.newdream.net/).
-* 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).
-* The nova-schedule 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).
+* `nova-api` accepts and responds to end user compute and volume API calls. It supports OpenStack 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). In the Essex release, nova-api has been modularized, allowing for implementers to run only specific APIs.
+* 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 persistent 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](http://ceph.newdream.net/).
+* The `nova-networ`k 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).
+* The `nova-schedule` 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).
* The queue provides a central hub for passing messages between daemons. This is usually implemented with [RabbitMQ](http://www.rabbitmq.com/) today, but could be any AMPQ message queue (such as [Apache Qpid](http://qpid.apache.org/)).
* The 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.
@@ -93,8 +93,8 @@ Authentication is handled through configurable WSGI middleware (which will usual
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.)
+* `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, I have shown the most likely configuration (using Swift 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.
Please sign in to comment.
Something went wrong with that request. Please try again.