Jump to: navigation, search

Difference between revisions of "Heat/Blueprints/Multi Region Support for Heat"

Line 73: Line 73:
 
[[File:Template flow.png|800x419px|framed|center|Template flow]]
 
[[File:Template flow.png|800x419px|framed|center|Template flow]]
  
−
==== Challenges & Solutions ====
+
==== Challenges & Problems ====
  
 
{| class="wikitable"
 
{| class="wikitable"

Revision as of 13:30, 31 July 2013

--bartosz-gorski (talk) 23:51, 15 July 2013 (UTC)

Overview

Introduction

Most of enterprises are focusing on Multi-cloud (using both private and public clouds) as enterprise cloud strategy. They will not completely migrate to Service Provider's cloud (public cloud). They will still keep their mission critical information assets to their premise or collocation space (private cloud).

Our goal is to create Hybrid-cloud (combination of public and private cloud). Creating Hybrid-cloud requires:

  • Seamless operation among heterogeneous environment
  • End-to-end automatic provisioning based on system template (VM, network, topology)
  • Unified control and monitoring
    • Multi-Hypervisor including bare-metal
    • Multi-Region control
    • Secure network access via Internet (VPN connection)
Hybrid-cloud

Requirements

Requirements for Heat:

  • mapping between Regions and API endpoints
  • mapping between Regions and Images
  • specifying region for resource
  • support for VPN as resource
  • support dependencies between resource in different regions
  • horizon interface for Heat with multi regions

Goal

Multi region first use case

First Use Case Scenario (no dependencies)

We have two regions (East and West) with separate OpenStack installations. We want to use Heat with multi region support to create in both regions:

  • Quantum Network
  • Quantum Subnet
    • 10.1.0.0/24 in East
    • 10.2.0.0/24 in West
  • Router
    • Router Interface for created subnet
    • Router Gateway for external network
  • VPN Service for created router
    • IKE Policy
    • IPsec Policy
    • VPN Connection
  • Server connected to created subnet

Created servers should be able to see each other using local IP address.

First_Use_Case.template - template file for it in appendix.

Second Use Case Scenario (with dependencies)

Similar to the first use case but creation of the second server depends on the first one. We want to deploy web service (ex. wordpress) on two servers. One server with application (ex. apache and wordpress) and second server with database (ex. mysql server). Befor creating server with application we need to know the IP address of the server with database so we need to wait until it will be created.

Second_Use_Case.template - template file for it in appendix.

Architecture

Overview

Components Diagram

Description:

  • more than one region (for example two: East and West)
  • separate OpenStack installation (Nova, Glance, Swift, Neutron and Cinder) in each region
  • one Keystone service for all regions
  • one Horizon with multi region support

Stack Launch Flow

Multi region template (master template) is the main template file that is sent to the heat engine in one of the available regions. It consists of two types of resources:

  • local resource (resource without specified context) - can be a single resource or nested stack and it will be created with default context (with the same region, project and user credentails that master template was launched).
  • remote resource (with specified context) - can be only a nested stack and it will be created by sending the template to appopriate heat engine in specified region.
Template flow

Challenges & Problems

Challenge Solution
How to avoid single point of failure?  ?
What is the better way to pass template file for nested stack than url to file?  ?
What should happen if one of the region fails?  ?

What needs to be done

Heat

Engine

VPN support

Blueprint for VPaaS support

Context as Resource

Property Description
name User friendly name of the context
description Context description.
project_name Name of the keystone project.
region_name Name of the region.
heat_endpoint URL to the Heat API in specified region. If not provided Heat will query keystone service to get it.
username Username of the keystone account.
password Password for provided username. 
...
"Resources" : {
    ...
    "MyContext": {
        "Type": "OS::Cloud::Context",
        "Properties": {
            "name": "My context",
            "descirption": "My new context description",
            "project_name" : "demo",
            "region_name" : "RegionOne",
            "username" : { "Ref" : "Username" },
            "password" : { "Ref" : "Password" }
        }
    },
    ...
}
...

Nested Stack

Property Description Implementation
Context Context which will be used to create nested stack Not started
TemplateURL Url address to nested stack tempalte file Done
TimeoutInMinutes Creation timeout in minutes Done
Parameters Values for nested stack parameters Done 
...
"Resources" : {
    ...
    "NewStackTemplate": {
        "Type": "AWS::CloudFormation::Stack",
        "Properties": {
            "TemplateURL": "https://raw.github.com/openstack/heat-templates/master/cfn/NestedStack.template",
            "Parameters": {
                "ParameterName1" : "Value1",
                "ParameterName2" : "Value2",
                "ParameterName3" : "Value3",
                ...
            }
        }
    },
    ...
}
...

UI

Existing UI views:


What about views for nested stack?

Horizon support for multi regions

Dropbox will appear only if more than one region is available in keystone catalog.

Dependencies & References

Appendix

Templates

  • First_Use_Case.template
  • Second_USe_Case.template
NTTI3
Retrieved from "https://wiki.openstack.org/w/index.php?title=Heat/Blueprints/Multi_Region_Support_for_Heat&oldid=27302"