Jump to: navigation, search

Difference between revisions of "Large Scale SIG/Configure"

(Created page with "The first stage in the Scaling Journey is '''Configure'''. This stage is about fine-tuning configuration options and optimizing the pa...")
 
(10 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
This stage is about fine-tuning configuration options and optimizing the parameters for your OpenStack cluster, so that it can handle additional load. The default values for configuration parameters in OpenStack are not always well-suited for handling scale, and OpenStack documentation does not always indicate which parameters to adjust with scale. This page aims to help answer those early questions.
 
This stage is about fine-tuning configuration options and optimizing the parameters for your OpenStack cluster, so that it can handle additional load. The default values for configuration parameters in OpenStack are not always well-suited for handling scale, and OpenStack documentation does not always indicate which parameters to adjust with scale. This page aims to help answer those early questions.
  
Once your cluster is properly configured to handle scale, you can go to the second stage of the Scaling Journey: [[Large_Scale_SIG/Monitor]].
+
Once your cluster is properly configured to handle scale, you can go to the second stage of the Scaling Journey: [[Large_Scale_SIG/Monitor|Monitor]].
  
 
== FAQ ==
 
== FAQ ==
 +
'''Q: Which OpenStack distributions are recommended for use at large scale?'''
  
'''Q: Which parameters should I adjust before tackling scale ?'''
+
A:  
  
 +
'''Q: Which drivers or backends are recommended for use at large scale?'''
 +
 +
A:
 +
 +
'''Q: Which parameters should I adjust in OpenStack components before tackling scale ?'''
 +
 +
A:
 +
# Number or workers for each service
 +
# DB connection (max_pool_size, max_overflow, etc.)
 +
 +
 +
'''Q: Which parameters should I adjust in RabbitMQ before tackling scale ?'''
 +
 +
A: See [[Large_Scale_Configuration_Rabbit]]
 +
 +
'''Q: Should I use memcached?'''
 +
 +
A: Yes, it will help a lot keystone (memcached will be used to store tokens instead of asking for new tokens on each call)
 +
 +
'''Q: Rabbitmq cluster seems hard to configure, what are the recommendations?'''
 +
 +
A: See [[Large_Scale_Configuration_Rabbit]]
  
 
== Resources ==
 
== Resources ==
* tbd
+
* [[Large_Scale_Configuration_Guidelines]]
 +
* Neutron backends performance comparison: https://thesaitech.wordpress.com/2019/02/15/a-comparative-study-of-openstack-networking-architectures/
 +
* Evaluation of performance before deployment
 +
** https://superuser.openstack.org/articles/collaborations-cross-industries-openstack-neutron-and-discovery-open-science-initiative/
 +
** Enos: https://github.com/BeyondTheClouds/enos and Enoslib: https://gitlab.inria.fr/discovery/enoslib
 +
 
  
 
== Other SIG work on that stage ==
 
== Other SIG work on that stage ==
* tbd
+
* Document better configuration defaults for large scale
 +
** Collect input at https://etherpad.opendev.org/p/large-scale-sig-documentation
 +
** Curate content at [[Large_Scale_Configuration_Guidelines]]
 +
** Push to official doc, pointing back to the guidelines page

Revision as of 15:39, 5 May 2021

The first stage in the Scaling Journey is Configure.

This stage is about fine-tuning configuration options and optimizing the parameters for your OpenStack cluster, so that it can handle additional load. The default values for configuration parameters in OpenStack are not always well-suited for handling scale, and OpenStack documentation does not always indicate which parameters to adjust with scale. This page aims to help answer those early questions.

Once your cluster is properly configured to handle scale, you can go to the second stage of the Scaling Journey: Monitor.

FAQ

Q: Which OpenStack distributions are recommended for use at large scale?

A:

Q: Which drivers or backends are recommended for use at large scale?

A:

Q: Which parameters should I adjust in OpenStack components before tackling scale ?

A:

  1. Number or workers for each service
  2. DB connection (max_pool_size, max_overflow, etc.)


Q: Which parameters should I adjust in RabbitMQ before tackling scale ?

A: See Large_Scale_Configuration_Rabbit

Q: Should I use memcached?

A: Yes, it will help a lot keystone (memcached will be used to store tokens instead of asking for new tokens on each call)

Q: Rabbitmq cluster seems hard to configure, what are the recommendations?

A: See Large_Scale_Configuration_Rabbit

Resources


Other SIG work on that stage