Jump to: navigation, search

Heat/Blueprints/Multi Region Support for Heat/The Missing Diagram

< Heat‎ | Blueprints/Multi Region Support for Heat
Revision as of 20:31, 15 November 2013 by Zaneb (talk | contribs) (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...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

The Missing Whiteboard Diagram

This diagram shows the possible options for multi-region support in Heat.

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.

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.
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.