Difference between revisions of "Auto-scaling SIG/Theory of Auto-Scaling"
Joseph Davis (talk | contribs) (Initial framework) |
Joseph Davis (talk | contribs) (→Theory of Auto-Scaling: components) |
||
Line 42: | Line 42: | ||
@enduml | @enduml | ||
+ | |||
+ | == Components of Auto-Scaling == | ||
+ | |||
+ | OpenStack offers a rich set of services to build, manage, orchestrate, and provision a cloud. This gives administrators some choices in how to best serve their customer's needs. | ||
+ | |||
+ | * Scaling units - There are a number of components that can be controlled with Auto-Scaling. | ||
+ | ** Compute Host | ||
+ | ** VM running on a Compute Host | ||
+ | ** Container running on a Compute Host | ||
+ | ** Network Attached Storage | ||
+ | ** Virtual Network Functions | ||
+ | * Monitoring Service | ||
+ | ** [https://wiki.openstack.org/wiki/Monasca Monasca] | ||
+ | ** [https://wiki.openstack.org/wiki/Telemetry Ceilometer from the Telemetry project] | ||
+ | * Alarming Service | ||
+ | ** Monasca has a built in alarm thresholding service and notification service | ||
+ | ** [https://wiki.openstack.org/wiki/Telemetry Aodh from the Telemetry project] | ||
+ | * Decision Services - There are a number of services in OpenStack that can interpret metrics and alarms based on configured logic and produce commands to Orchestration Engines | ||
+ | ** Congress | ||
+ | ** Heat | ||
+ | ** Tacker | ||
+ | ** Vitrage | ||
+ | ** Watcher | ||
+ | * Orchestration Engines | ||
+ | ** Heat | ||
+ | ** Senlin is a clustering engine for OpenStack, and can orchestrate auto-scaling | ||
+ | ** [https://wiki.openstack.org/wiki/Tacker Tacker] | ||
== Considerations and Guidelines == | == Considerations and Guidelines == | ||
Line 48: | Line 75: | ||
* Don't expect instantaneous scaling (see above) | * Don't expect instantaneous scaling (see above) | ||
* Be aware of where the logic for scaling is (alarm thresholds, decision services) | * Be aware of where the logic for scaling is (alarm thresholds, decision services) | ||
+ | |||
+ | |||
+ | === Anecdotes and Stories === |
Revision as of 23:07, 15 May 2019
Contents
Theory of Auto-Scaling
General Description
<fill in>
Conceptual Diagram
If you prefer PlantUML
@startuml
cloud Cloud\n {
rectangle host as "Host" { } rectangle host2 as "Host" { agent VM agent VM2 as "VM" agent Container agent Container2 as "Container" }
}
agent MS as "Monitoring Service" agent DS as "Decision Services\n(Clustering,\nOptimization,\nRoot Cause)" agent Heat as "Orchestration \nEngine"
host -down-> MS VM -down-> MS Container -down-> MS : "Metric \nSamples"
MS -down-> DS : "Alarms" MS -down-> Heat : "Alarms"
DS -right-> Heat : "Scaling Commands"
Heat -up-> host : "Orchestration" Heat -up-> VM2 : "Orchestration" Heat -up-> Container2 : "Orchestration"
@enduml
Components of Auto-Scaling
OpenStack offers a rich set of services to build, manage, orchestrate, and provision a cloud. This gives administrators some choices in how to best serve their customer's needs.
- Scaling units - There are a number of components that can be controlled with Auto-Scaling.
- Compute Host
- VM running on a Compute Host
- Container running on a Compute Host
- Network Attached Storage
- Virtual Network Functions
- Monitoring Service
- Alarming Service
- Monasca has a built in alarm thresholding service and notification service
- Aodh from the Telemetry project
- Decision Services - There are a number of services in OpenStack that can interpret metrics and alarms based on configured logic and produce commands to Orchestration Engines
- Congress
- Heat
- Tacker
- Vitrage
- Watcher
- Orchestration Engines
- Heat
- Senlin is a clustering engine for OpenStack, and can orchestrate auto-scaling
- Tacker
Considerations and Guidelines
- Monitoring takes resources, plan accordingly
- Avoid scaling too quickly or too often
- Don't expect instantaneous scaling (see above)
- Be aware of where the logic for scaling is (alarm thresholds, decision services)