Open Stack

On 12/27/2013 01:21 PM, Jeffrey Walton wrote:
> I'm setting up another test installation. I'm working on Ubuntu with
> Havana using http://docs.openstack.org/havana/install-guide/install/apt/content/.
>
> According to the OpenStack Installation Guide, the example uses a
> Controller with Keystone, Glance and Nova. Freat job on those
> documents, btw. (See http://postimg.org/image/ct3i150qr/ for a screen
> capture of the page with a logical diagram).
>
> I want to move Keystone to its own virtual machine for segregation
> (this will eventually be a security requirement). I also want to move
> Nova to its own VM (in addition to one VM for a Swift node).
>
> What are the minimum components required for the controller? Does that
> leave Glance, MySQL and RabbitMQ? Can Glance be moved somewhere if
> desired (or must it remain on the controller)?
>
> Sorry about the basic question. I'm still working though examples to
> see what works, what does not, and how I manage to break things ;)

Hi Jeffrey,

We actually originally started off segregating various OpenStack service 
endpoints into their own nodes -- Glance on one, Keystone on another, 
Nova/Cinder on another, etc.

We no longer do that; it just wasn't worth the effort, and it meant a 
whole bunch of wasted resources. There's no real reason to host anything 
other than Swift and the Neutron L3 and DHCP agents on separate VMs or 
nodes. All the other endpoints are stateless and can happily live on the 
same VM/node.

* nova-api-*
* nova-scheduler
* cinder-api
* cinder-scheduler
* keystone-*
* glance-*
* neutron-server
* openstack-dashboard
* apache/nginx/etc
* memcache

All of the above happily live together in a single VM/node, as they are 
all stateless [1] (other than memcache, but memcache just serves for 
caching purposes, not end-state).

You can then put your databases/MQ on another set of nodes, since those 
are the main things that contain state in the system. We personally use 
Percona XtraDB Cluster for MySQL and clustered RabbitMQ, but you are 
free to make whatever choices you want in that arena.

Finally, place the Neutron L3 and DHCP agents on a separate node/VM, as 
these services do manage state in the network namespaces, iptables and 
other utilities.

All the best,
-jay

[1] glance-api is only stateless if you are using a remote/distribute 
data store to back images (like Swift or Ceph). If you use local 
filesystem storage in Glance (not recommended), then glance-api is no 
longer stateless.