[openstack-dev] [Heat] Continue discussing multi-region orchestration

Georgy Okrokvertskhov gokrokvertskhov at mirantis.com
Fri Nov 15 23:07:44 UTC 2013


Hi,

With slight modifications of (2) one can benefit of availability:
1. There should not be a master node. Each heat engine should be able to
act as a master if someone asks it to deploy a template. Current master
engine will be responsible to contact other engines and pass them the same
template and wait for confirmation.
2. Each Heat engine instance receives whole template but deploys only
resources which are designated to engine's zone

This will provide all benefits of availability as all engines will keep a
copy of a template and you can update template by using any heat engine.
For example if heat engine in region 1 is down or whole site 1 is down you
can update a template with new region settings and update it with using
heat engine in region 2.

The multi-region support proposal contains information and proposal for
"what" and "how" but does not describe "why". If we talk just about
multi-region placement support then option (4) works fine. If there is an
intension to build a solution for HA, DR, elastic scalability for spike
loads then we need to keep availability as a part of a design.

Thanks
Georgy





On Fri, Nov 15, 2013 at 1:17 PM, Keith Bray <keith.bray at rackspace.com>wrote:

> The way I view 2 vs. 4 is that 2 is more complicated and you don't gain
> any benefit of availability.  If, in 2, your global heat endpoint is down,
> you can't update the whole stack.  You have to work around it by talking
> to Heat (or the individual service endpoints) in the region that is still
> alive.
>
> 4 is much simpler in that only one Heat instance is involved.  If Heat is
> down, you still have just as bad/good workaround, which is you talk to
> service endpoints in the region that is still available.  If you want to
> use Heat in that region to do it, you can Adopt the resources into a Heat
> stack in that region. I don't see how 2 is "Robust against failure of
> whole region" because if the region on the left part of the picture in 2
> goes down, you can't manage your global stack or any of the resources in
> the left region that are part of that global stack.  All you could manage
> is a subset of resources by manipulating the substack in the right region,
> but you can do this in 4 as well using Adopt.  4 is a simpler starting use
> case and easier (IMO) for a user of the system to digest, and has the HUGE
> advantage of being able to orchestrate deploying resources to multiple
> regions without a service operator having to have Heat setup and installed
> in EVERY region.  This is particular important for a private cloud/heat
> person trying to deploy to public cloud.. If doing so requires the public
> cloud operator have Heat running, then you can't deploy there.  If no Heat
> in that region is required, then you can use your own instance of Heat to
> deploy to any available openstack cloud.  That is a HUGE benefit of 4.
>
> -Keith
>
> On 11/15/13 2:58 PM, "Zane Bitter" <zbitter at redhat.com> wrote:
>
> >On 15/11/13 18:24, Bartosz Górski wrote:
> >> Hi Thomas,
> >>
> >> Each of the two engines will be able to create resources in both
> >>regions.
> >> We do not need to add anything in the heat client.
> >>
> >> Right now when you want to create a new stack (using heat client or
> >> directly API) you need to provide:
> >> - stack name
> >> - template
> >> - parameters (if need)
> >> - tenant
> >> - username
> >> - password
> >> - region name (optional)
> >>
> >> The last four (tenant, username, password and region_name) we will call
> >> default context.
> >> This context is used in Heat to configure all the openstack clients to
> >> other service.
> >> Username, password and tenant is used for authentication.
> >> Region name is use to get appropriate API endpoint from keystone catalog
> >> for other openstack service (like nova).
> >> In case with one region you do not need to specify it because there is
> >> only one endpoint for each service.
> >> In multi-region case we have more than one and region name is used to
> >> get correct one.
> >>
> >> Each nested stack have its own set of openstack clients (nova client,
> >> neutron client, ... etc.) inside the heat engine.
> >> Right now for all of them the default context is used to configure
> >> clients which will be used to create resources.
> >> There is not option to change the default context for now. What I'm
> >> trying to do it to add possibility to define different
> >> context inside the template file. New context can be passed to nested
> >> stack resource to create clients set with different
> >> endpoints to call. Heat engine will get appropriate endpoints from
> >> keystone catalog for specified region name.
> >>
> >> So from heat engine point of view there is not big change in the
> >> workflow. Heat will parse the template, create the
> >> dependencies graph and start creating resources in the same way as
> >> usual. When he will need to created nested
> >> stack with different context he will just use different set of openstack
> >> clients (ex. will call services in other region).
> >>
> >> So to sum up each of the two heat engine will be able to create
> >> resources in both regions if different context will
> >> be specified. If only default context will be used heat will create all
> >> resource in the same region where it is located.
> >
> >So, to be clear, this is option (4) from the diagram I put together here:
> >
> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_H
> >eat/The_Missing_Diagram
> >
> >It's got a couple of major problems:
> >
> >* When a whole region goes down, you can lose access to the Heat
> >instance that was managing still-available resources. This makes it more
> >or less impossible to use Heat to manage a highly-available global
> >application.
> >
> >* Instances have to communicate back to the Heat instance that owns them
> >(e.g. for WaitConditions), and it's not yet clear that this is feasible
> >in general.
> >
> >There are also a number of other things I really don't like about this
> >solution (listed on the wiki page), though reasonable people may disagree.
> >
> >cheers,
> >Zane.
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/788af27c/attachment.html>


More information about the OpenStack-dev mailing list