Open Stack

Sorry to chime in but i will throw in another use case for Steven since is
about the HA/ auto-scaling and i think it does match what i asked back in
October.

http://lists.openstack.org/pipermail/openstack-dev/2014-October/049375.html

If you need more info let me know

Dani

On Thu, Apr 2, 2015 at 10:59 AM, Huangtianhua <huangtianhua at huawei.com>
wrote:

> If we replace a autoscaling group member, we can't make sure the attached
> resources keep the same, why not to call the evacuate or rebuild api of
> nova,
> just to add meters for ha(vm state or host state) in ceilometer, and then
> signal to HA resource(such as HARestarter)?
>
> -----邮件原件-----
> 发件人: Steven Hardy [mailto:shardy at redhat.com]
> 发送时间: 2014年12月23日 2:21
> 收件人: openstack-dev at lists.openstack.org
> 主题: [openstack-dev] [heat] Application level HA via Heat
>
> Hi all,
>
> So, lately I've been having various discussions around $subject, and I
> know it's something several folks in our community are interested in, so I
> wanted to get some ideas I've been pondering out there for discussion.
>
> I'll start with a proposal of how we might replace HARestarter with
> AutoScaling group, then give some initial ideas of how we might evolve that
> into something capable of a sort-of active/active failover.
>
> 1. HARestarter replacement.
>
> My position on HARestarter has long been that equivalent functionality
> should be available via AutoScalingGroups of size 1.  Turns out that
> shouldn't be too hard to do:
>
>  resources:
>   server_group:
>     type: OS::Heat::AutoScalingGroup
>     properties:
>       min_size: 1
>       max_size: 1
>       resource:
>         type: ha_server.yaml
>
>   server_replacement_policy:
>     type: OS::Heat::ScalingPolicy
>     properties:
>       # FIXME: this adjustment_type doesn't exist yet
>       adjustment_type: replace_oldest
>       auto_scaling_group_id: {get_resource: server_group}
>       scaling_adjustment: 1
>
> So, currently our ScalingPolicy resource can only support three adjustment
> types, all of which change the group capacity.  AutoScalingGroup already
> supports batched replacements for rolling updates, so if we modify the
> interface to allow a signal to trigger replacement of a group member, then
> the snippet above should be logically equivalent to HARestarter AFAICT.
>
> The steps to do this should be:
>
>  - Standardize the ScalingPolicy-AutoScaling group interface, so
> aynchronous adjustments (e.g signals) between the two resources don't use
> the "adjust" method.
>
>  - Add an option to replace a member to the signal interface of
> AutoScalingGroup
>
>  - Add the new "replace adjustment type to ScalingPolicy
>
> I posted a patch which implements the first step, and the second will be
> required for TripleO, e.g we should be doing it soon.
>
> https://review.openstack.org/#/c/143496/
> https://review.openstack.org/#/c/140781/
>
> 2. A possible next step towards active/active HA failover
>
> The next part is the ability to notify before replacement that a scaling
> action is about to happen (just like we do for LoadBalancer resources
> already) and orchestrate some or all of the following:
>
> - Attempt to quiesce the currently active node (may be impossible if it's
>   in a bad state)
>
> - Detach resources (e.g volumes primarily?) from the current active node,
>   and attach them to the new active node
>
> - Run some config action to activate the new node (e.g run some config
>   script to fsck and mount a volume, then start some application).
>
> The first step is possible by putting a SofwareConfig/SoftwareDeployment
> resource inside ha_server.yaml (using NO_SIGNAL so we don't fail if the
> node is too bricked to respond and specifying DELETE action so it only runs
> when we replace the resource).
>
> The third step is possible either via a script inside the box which polls
> for the volume attachment, or possibly via an update-only software config.
>
> The second step is the missing piece AFAICS.
>
> I've been wondering if we can do something inside a new heat resource,
> which knows what the current "active" member of an ASG is, and gets
> triggered on a "replace" signal to orchestrate e.g deleting and creating a
> VolumeAttachment resource to move a volume between servers.
>
> Something like:
>
>  resources:
>   server_group:
>     type: OS::Heat::AutoScalingGroup
>     properties:
>       min_size: 2
>       max_size: 2
>       resource:
>         type: ha_server.yaml
>
>   server_failover_policy:
>     type: OS::Heat::FailoverPolicy
>     properties:
>       auto_scaling_group_id: {get_resource: server_group}
>       resource:
>         type: OS::Cinder::VolumeAttachment
>         properties:
>             # FIXME: "refs" is a ResourceGroup interface not currently
>             # available in AutoScalingGroup
>             instance_uuid: {get_attr: [server_group, refs, 1]}
>
>   server_replacement_policy:
>     type: OS::Heat::ScalingPolicy
>     properties:
>       # FIXME: this adjustment_type doesn't exist yet
>       adjustment_type: replace_oldest
>       auto_scaling_policy_id: {get_resource: server_failover_policy}
>       scaling_adjustment: 1
>
> By chaining policies like this we could trigger an update on the
> attachment resource (or a nested template via a provider resource
> containing many attachments or other resources) every time the
> ScalingPolicy is triggered.
>
> For the sake of clarity, I've not included the existing stuff like
> ceilometer alarm resources etc above, but hopefully it gets the idea
> accross so we can discuss further, what are peoples thoughts?  I'm quite
> happy to iterate on the idea if folks have suggestions for a better
> interface etc :)
>
> One problem I see with the above approach is you'd have to trigger a
> failover after stack create to get the initial volume attached, still
> pondering ideas on how best to solve that..
>
> Thanks,
>
> Steve
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150403/c667b753/attachment.html>