Difference between revisions of "Heat/Blueprints/Multi Region Support for Heat/The Missing Diagram"
Nachi Ueno (talk | contribs) (→Pros) |
Nachi Ueno (talk | contribs) (→Pros) |
||
Line 21: | Line 21: | ||
* Minimal code churn (only affects one resource type). | * 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). | * Robust against failure of a whole region (available resources remain manageable - you could even use stack adopt to reconstitute the global stack). | ||
− | + | <-- I don't think so. This architecture needs to be both heat in different region working. so It can't say Robust than the other solutions (Nachi) | |
* Same code can support pattern #3, e.g. in the case of a standalone global instance. | * Same code can support pattern #3, e.g. in the case of a standalone global instance. | ||
Latest revision as of 19:08, 6 January 2014
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).
<-- I don't think so. This architecture needs to be both heat in different region working. so It can't say Robust than the other solutions (Nachi)
- 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 standalone Heat instance to handle any regions 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).
<-- I don't think so. This architecture needs to be both heat in different region working. so It can't say Robust than the other solutions (Nachi)
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.