<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 29 September 2014 23:28, Erik McCormick <span dir="ltr"><<a href="mailto:emccormick@cirrusseven.com" target="_blank">emccormick@cirrusseven.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The architecture I intended to deploy was this:</div><div><br></div><div>2 HAProxy nodes to load balance active / active APIs and Horizon</div><div>2 HAProxy nodes to load balance a Galera Mysql cluster</div><div>2 Control nodes with all API services</div><div>3 Galera / MySQL nodes</div><div>3 MongoDB nodes running replica sets for Ceilometer</div><div>2 Neutron Nodes running Active / Passive L3/DHCP/LBaaS agents (hopefully active active L3 in Juno)</div><div>3 Ceph-Mon nodes</div><div>3 Ceph-OSD nodes (hosting Cinder, Glance, and potentially instance storage)</div><div>X number of compute nodes depending on the requirement</div><div><br></div><div>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?</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>I would recommend ensuring that:</div><div><br></div><div>1) ceph-mon's and ceph-osd's are not hosted on the same server - they both demand plenty of cpu cycles</div><div>2) ceilometer's storage into mongodb is demanding, so it's best to ensure that mongodb is on different storage to galera</div><div>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</div><div>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</div><div>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)</div><div>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</div><div><br></div><div>HTH,</div><div><br></div><div>Jesse</div></div></div></div>