Example Compute Installation Architectures OpenStack architecture consists of these major components: Compute, Object Storage, Identity, and Images. A common Identity component provides authentication for users to have access to these components. The Image service stores and serves images to run virtual machines. Compute uses a shared-nothing, messaging-based architecture. While very flexible, the fact that you can install each nova- service on an independent server means there are many possible methods for installing OpenStack Compute. The only co-dependency between possible multi-node installations is that the Dashboard must be installed on a server running the nova-api service. Here are the types of installation architectures for OpenStack Compute with the Image and Identity Services: Single node, Compute-only: Only one server runs all nova- services and also drives all the virtual instances. Use this configuration only for trying out OpenStack Compute, or for development purposes. Two nodes, Compute-only: A cloud controller node runs the nova- services except for nova-compute, and a compute node runs nova-compute. A client computer is likely needed to bundle images and interfacing to the servers, but a client is not required. Use this configuration for proof of concepts or development environments. Multiple nodes, Compute-only: You can add more compute nodes to the two node installation by simply installing nova-compute on an additional server and copying a nova.conf file to the added node. This would result in a multiple node installation. You can also add a volume controller and a network controller as additional nodes in a more complex multiple node installation. A minimum of 4 nodes is best for running multiple virtual instances that require a lot of processing power. This is an illustration of one possible multiple server installation of OpenStack Compute; virtual server networking in the cluster may vary. An alternative architecture would be to add more messaging servers if you notice a lot of back up in the messaging queue causing performance problems. In that case you would add an additional RabbitMQ server in addition to or instead of scaling up the database server. Your installation can run any nova- service on any server as long as the nova.conf is configured to point to the RabbitMQ server and the server can send messages to the server. Multiple installation architectures are possible, here is another example illustration.