Difference between revisions of "Heat/Blueprints/Multi Region Support for Heat/The Missing Diagram"
(Created page with "unframed|The Missing Whiteboard Diagram This diagram shows the possible options for multi-region support in Heat. == Region Silos == This is the c...") |
|||
Line 25: | Line 25: | ||
===== Cons ===== | ===== Cons ===== | ||
* The user has to split their deployment into templates containing resources in only one region. | * The user has to split their deployment into templates containing resources in only one region. | ||
+ | * The user would have to run a separate standalone Heat instance for every region not providing a Heat service. | ||
== Master Orchestrator == | == Master Orchestrator == | ||
Line 46: | Line 47: | ||
* Consistent across resource types. | * Consistent across resource types. | ||
* Allows the user to construct their templates in any way they like. | * Allows the user to construct their templates in any way they like. | ||
+ | * Works even if Heat is not provided in every region. | ||
===== Cons ===== | ===== Cons ===== |
Revision as of 22:44, 15 November 2013
This diagram shows the possible options for multi-region support in Heat.
Contents
Region Silos
This is the current situation. Independent instances of Heat run in each region. It is up to the user to co-ordinate between stacks in different regions.
Pros
- Simple.
- Robust against failure of a whole region.
Cons
- Where orchestration crosses regions, users must manage it themselves. We invented Heat so folks wouldn't have to do that.
Stack-based Multi-region
Independent instances of Heat runs in each region. When creating an OS::Heat::Stack resource (but only this type of resource), the user can specify a region. In this case, python-heatclient is used to connect to Heat in the appropriate region and create the substack.
Pros
- Minimal code churn (only affects one resource type).
- Robust against failure of a whole region (available resources remain manageable - you could even use stack adopt to reconstitute the global stack).
- Same code can support pattern #3, e.g. in the case of a standalone global instance.
Cons
- The user has to split their deployment into templates containing resources in only one region.
- The user would have to run a separate standalone Heat instance for every region not providing a Heat service.
Master Orchestrator
Independent instances of Heat runs in each region. In addition, there is a global Heat instance that crosses regions, and can create nested stacks in each of the regional Heat instances.
Pros
- Minimal code churn (only affects one resource type).
- Robust against failure of a whole region (available resources remain manageable).
Cons
- Requires an extra Heat deployment that doesn't really belong anywhere in particular.
- The user has to split their deployment into templates containing resources in only one region.
- The global Heat has to run different code to the regional Heats.
Multi-Region resources
Independent instances of Heat runs in each region. However, the resources they manage may be in any region, regardless of the resource type.
Pros
- Consistent across resource types.
- Allows the user to construct their templates in any way they like.
- Works even if Heat is not provided in every region.
Cons
- Failure of the region containing the Heat stack leaves other resources unmanageable.
- Getting instances to connect back to Heat may not even be possible.
- Templates can be a confusing hodge-podge of resources in different regions.
- Many relationships expressible within a single template are not actually possible.
Global Orchestrator
One global instance of Heat runs across all regions, and can manage resources in any region.
Pros
- Consistent across resource types.
- Allows the user to construct their templates in any way they like.
Cons
- We'd have to turn Heat into a highly-available global service, which is insanely difficult.
- Templates can be a confusing hodge-podge of resources in different regions.
- Many relationships expressible within a single template are not actually possible.