[Openstack-operators] Case studies on Openstack HA architecture

[Imtiaz Chowdhury]

Hi Openstack operators,

Most Openstack HA deployment use 3 node database cluster, 3 node rabbitMQ 
cluster and 3 Controllers. I am wondering whether there are any studies done 
that show the pros and cons of co-locating database and messaging service with 
the Openstack control services.  In other words, I am very interested in 
learning about advantages and disadvantages, in terms of ease of deployment, 
upgrade and overall API performance, of having 3 all-in-one Openstack 
controller over a more distributed deployment model.

References to any work done in this area will be highly appreciated.

Thanks,
Imtiaz

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [kolla][puppet][openstack-ansible] Better way to run wsgi service.

[Chris Dent]

On Thu, 24 Aug 2017, Jeffrey Zhang wrote:


i propose use uwsgi native http mode[1]. Then one uwsgi
container is enough to run nova-api service. Base one the official
doc, if there is no static resource, uWSGI is recommended to use
as a real http server.


I would consider using uwsgi in uwsgi mode, to run the api server in
a container independently. Using uwsgi mode preserves the capability
of your container (or containers) being anywhere, but is more
performant than http mode.

The relatively new uwsgi stuff on devstack has relatively clean ways
to run uwsgi services under systemd, but does so with unix domain
sockets. This might be a useful guide for writing uwsgi.ini files
for single processes in containers. Some adaptations will be
required.

And then reverse proxy to the container from either nginx or apache2
such that every service is on the same
https://api.mycloud.example.com/ host with the service on a path
prefix: https://api.mycloud.example.com/compute/,
https://api.mycould.example.com/block-storage, etc


--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

[Mohammed Naser]

On Fri, Aug 25, 2017 at 2:56 AM, Jeffrey Zhang  wrote:
> thanks mnaser and sam for the advice.
>
> i think uwsgi + native http is not a good solution, nova. A http
> server + uwsgi is better. So i am imaging that the deployment
> architecture will be like
>
> haproxy --> http server -> uwsgi_nova_api / uwsgi_glance_api etc.
>
> As mnaster said, one http server serve for others uwsgi services.
>
> on the other hand, which following solution is better?
>
> - apache + mod_uwsgi ( not recommended by uwsgi )

Not recommended by them is probably a sign to stay away

> - apache + mode_proxy_uwsgi ( recommended by uwsgi)

This has two advantages.   DevStack at the gate tests using this exact
architecture AFAIK which means that we would less likely run into
issues that were never discovered in testing.

> - nginx + uwsgi

I like this a lot, however, for applications such as Keystone, they
sometimes rely on Apache for some features (such as Federation:
https://docs.openstack.org/keystone/latest/advanced-topics/federation/configure_federation.html#configure-apache-to-use-a-federation-capable-authentication-method)

However, Apache has done a lot of improvements in terms of catching up
to nginx and if using an MPM worker such as mpm_event, you would end
up with a very similar architecture and performance.

>
> So the question is why community choose apache rather than nginx?
>
> [0] http://uwsgi-docs.readthedocs.io/en/latest/Apache.html
>
>
> On Fri, Aug 25, 2017 at 5:32 AM, Sam Yaple  wrote:
>>
>> I have been running api services behind uwsgi in http mode from Newton
>> forward. I recently switched to the uwsgi+nginx model with 2 containers
>> since I was having wierd issues with things that I couldn't track down.
>> Mainly after I started using keystone with ldap. There would be timeouts and
>> message-to-long type errors that all went away with nginx.
>>
>> Additionally, running with HTTPS was measurably faster with nginx proxying
>> to a uwsgi socket.
>>
>> This was just my experience with it, if you do want to switch to
>> uwsgi+http make sure you do thorough testing of all the components or you
>> may be left with a component that just won't work with your model.
>>
>>
>> On Thu, Aug 24, 2017 at 12:29 PM, Mohammed Naser 
>> wrote:
>>>
>>> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang 
>>> wrote:
>>> > We are moving to deploy service via WSGI[0].
>>> >
>>> > There are two recommended ways.
>>> >
>>> > - apache + mod_wsgi
>>> > - nginx + uwsgi
>>> >
>>> > later one is more better.
>>> >
>>> > For traditional deployment, it is easy to implement. Use one
>>> > uwsgi progress to launch all wsgi services ( nova-api,cinder-api ,
>>> > etc).
>>> > Then one nginx process to forward the http require into uwsgi server.
>>> >
>>> > But kolla is running one process in one container. If we use
>>> > the recommended solution, we have to use two container to run
>>> > nova-api container. and it will generate lots of containers.
>>> > like: nginx-nova-api, uwsig-nova-api.
>>> >
>>> > i propose use uwsgi native http mode[1]. Then one uwsgi
>>> > container is enough to run nova-api service. Base one the official
>>> > doc, if there is no static resource, uWSGI is recommended to use
>>> > as a real http server.
>>> >
>>> > So how about this?
>>>
>>> I think this is an interesting approach.  At the moment, the Puppet
>>> modules currently allow deploying for services using mod_wsgi.
>>> Personally, I don't think that relying on the HTTP support of uWSGI is
>>> very favorable.   It is quite difficult to configure and 'get right'
>>> and it leaves a lot to be desired (for example, federated auth relies
>>> on Apache modules which would make this nearly impossible).
>>>
>>> Given that the current OpenStack testing infrastructure proxies to
>>> UWSGI, I think it would be best if that approach is taken.  This way,
>>> a container (or whatever service) would expose a UWSGI API, which you
>>> can connect whichever web server that you need.
>>>
>>> In the case of Kolla, the `httpd` container would be similar to what
>>> the `haproxy` is.  In the case of Puppet, I can imagine this being
>>> something to be managed by the user (with some helpers in there).  I
>>> think it would be interesting to add the tripleo folks on their
>>> opinion here as consumers of the Puppet modules.
>>>
>>> >
>>> >
>>> > [0]
>>> > https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
>>> > [1]
>>> >
>>> > http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-use-uwsgi-s-http-capabilities-in-production
>>> >
>>> > --
>>> > Regards,
>>> > Jeffrey Zhang
>>> > Blog: http://xcodest.me
>>> >
>>> > ___
>>> > OpenStack-operators mailing list
>>> > OpenStack-operators@lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>> >
>>>
>>> 

Re: [Openstack-operators] [openstack-dev] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

[Jeffrey Zhang]

thanks mnaser and sam for the advice.

i think uwsgi + native http is not a good solution, nova. A http
server + uwsgi is better. So i am imaging that the deployment
architecture will be like

haproxy --> http server -> uwsgi_nova_api / uwsgi_glance_api etc.

As mnaster said, one http server serve for others uwsgi services.

on the other hand, which following solution is better?

- apache + mod_uwsgi ( not recommended by uwsgi )
- apache + mode_proxy_uwsgi ( recommended by uwsgi)
- nginx + uwsgi

So the question is why community choose apache rather than nginx?

[0] http://uwsgi-docs.readthedocs.io/en/latest/Apache.html


On Fri, Aug 25, 2017 at 5:32 AM, Sam Yaple  wrote:

> I have been running api services behind uwsgi in http mode from Newton
> forward. I recently switched to the uwsgi+nginx model with 2 containers
> since I was having wierd issues with things that I couldn't track down.
> Mainly after I started using keystone with ldap. There would be timeouts
> and message-to-long type errors that all went away with nginx.
>
> Additionally, running with HTTPS was measurably faster with nginx proxying
> to a uwsgi socket.
>
> This was just my experience with it, if you do want to switch to
> uwsgi+http make sure you do thorough testing of all the components or you
> may be left with a component that just won't work with your model.
>
>
> On Thu, Aug 24, 2017 at 12:29 PM, Mohammed Naser 
> wrote:
>
>> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang 
>> wrote:
>> > We are moving to deploy service via WSGI[0].
>> >
>> > There are two recommended ways.
>> >
>> > - apache + mod_wsgi
>> > - nginx + uwsgi
>> >
>> > later one is more better.
>> >
>> > For traditional deployment, it is easy to implement. Use one
>> > uwsgi progress to launch all wsgi services ( nova-api,cinder-api , etc).
>> > Then one nginx process to forward the http require into uwsgi server.
>> >
>> > But kolla is running one process in one container. If we use
>> > the recommended solution, we have to use two container to run
>> > nova-api container. and it will generate lots of containers.
>> > like: nginx-nova-api, uwsig-nova-api.
>> >
>> > i propose use uwsgi native http mode[1]. Then one uwsgi
>> > container is enough to run nova-api service. Base one the official
>> > doc, if there is no static resource, uWSGI is recommended to use
>> > as a real http server.
>> >
>> > So how about this?
>>
>> I think this is an interesting approach.  At the moment, the Puppet
>> modules currently allow deploying for services using mod_wsgi.
>> Personally, I don't think that relying on the HTTP support of uWSGI is
>> very favorable.   It is quite difficult to configure and 'get right'
>> and it leaves a lot to be desired (for example, federated auth relies
>> on Apache modules which would make this nearly impossible).
>>
>> Given that the current OpenStack testing infrastructure proxies to
>> UWSGI, I think it would be best if that approach is taken.  This way,
>> a container (or whatever service) would expose a UWSGI API, which you
>> can connect whichever web server that you need.
>>
>> In the case of Kolla, the `httpd` container would be similar to what
>> the `haproxy` is.  In the case of Puppet, I can imagine this being
>> something to be managed by the user (with some helpers in there).  I
>> think it would be interesting to add the tripleo folks on their
>> opinion here as consumers of the Puppet modules.
>>
>> >
>> >
>> > [0] https://governance.openstack.org/tc/goals/pike/deploy-api-in
>> -wsgi.html
>> > [1]
>> > http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i-u
>> se-uwsgi-s-http-capabilities-in-production
>> >
>> > --
>> > Regards,
>> > Jeffrey Zhang
>> > Blog: http://xcodest.me
>> >
>> > ___
>> > OpenStack-operators mailing list
>> > OpenStack-operators@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators