[Openstack-operators] Architecture Opinions

Jesse Pretorius jesse.pretorius at gmail.com
Tue Sep 30 13:06:16 UTC 2014

On 29 September 2014 23:28, Erik McCormick <emccormick at cirrusseven.com>

> The architecture I intended to deploy was this:
> 2 HAProxy nodes to load balance active / active APIs and Horizon
> 2 HAProxy nodes to load balance a Galera Mysql cluster
> 2 Control nodes with all API services
> 3 Galera / MySQL nodes
> 3 MongoDB nodes running replica sets for Ceilometer
> 2 Neutron Nodes running Active / Passive L3/DHCP/LBaaS agents (hopefully
> active active L3 in Juno)
> 3 Ceph-Mon nodes
> 3 Ceph-OSD nodes (hosting Cinder, Glance, and potentially instance storage)
> X number of compute nodes depending on the requirement
> The reference architectures I'm seeing out of Redhat and Mirantis among
> others seem to like putting all of the above eggs except the Storage into 3
> identical baskets. This just feels bad and painful to me and like it would
> lead to very badly performing everything. Am I totally just stuck in the
> past with how I'm thinking of setting all this up?

Depending on the size of your deployment, it's safe enough to combine
almost everything. It does also depend on the hardware you have available.

I would recommend ensuring that:

1) ceph-mon's and ceph-osd's are not hosted on the same server - they both
demand plenty of cpu cycles
2) ceilometer's storage into mongodb is demanding, so it's best to ensure
that mongodb is on different storage to galera
3) neutron's l3 agent active/passive configuration works just fine - it's
probably best to keep them on their own servers in order to handle the
appropriate throughput required
4) ceph-osd's should not run on your compute or OpenStack controller nodes
- kvm/osd contention on the cpu will cause all sort of odd issues
5) instance storage on ceph doesn't work very well if you're trying to use
the kernel module or cephfs - make sure you're using ceph volumes as the
underlying storage (I believe this has been patched in for Juno)
6) neutron has the ability to include proper ha for dhcp agents - we
currently (in a Grizzly environment) have a script that creates a DHCP
service on every network, but I believe that beyond Grizzly the HA story
has been sorted out


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140930/dea40084/attachment.html>

More information about the OpenStack-operators mailing list