Difference between revisions of "Large Scale SIG/ScaleUp"
m |
|||
| Line 15: | Line 15: | ||
== Resources == | == Resources == | ||
| − | * | + | * A curated collection of [[Large_Scale_Scaling_Stories|scaling stories]], as we collect them |
== Other SIG work on that stage == | == Other SIG work on that stage == | ||
| − | * | + | * Collecting scaling stories |
| + | ** Submit scaling stories on https://etherpad.openstack.org/p/scaling-stories | ||
| + | ** Curate them on [[Large_Scale_Scaling_Stories]] | ||
Revision as of 13:51, 24 November 2020
The third stage in the Scaling Journey is Scale Up.
As you monitor your cluster at scale, you will see that it hits scaling limits within one cluster. All hope is not lost, though! There are things you can put in place push back how much a single cluster can handle, before having to resort to setting up a more complex deployment configuration. This page aims to help answer those questions.
Once you are past that stage, you are ready to proceed to the final stage of the Scaling Journey: Scale Out.
FAQ
Q: How many compute nodes can a typical OpenStack cluster contain ?
A: ...
Q: RabbitMQ is clearly my bottleneck, is there a way to reconfigure that part to handle more scale?
Resources
- A curated collection of scaling stories, as we collect them
Other SIG work on that stage
- Collecting scaling stories
- Submit scaling stories on https://etherpad.openstack.org/p/scaling-stories
- Curate them on Large_Scale_Scaling_Stories
