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.
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
