On Fri, Jun 13, 2014 at 10:45 PM, Kapil Thangavelu <
kapil.thangav...@canonical.com> wrote:
>
>
>
> On Fri, Jun 13, 2014 at 12:23 AM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> Hi all,
>>
>> I'm pleased to say that availability zone support for AWS and OpenStack
>> has now landed on trunk, and will be available in 1.19.4. I'll write a blog
>> post and maybe even some docs about it, but for now here's a brief
>> description how you can use this feature.
>>
>> FYI: not all OpenStacks are created equal. Yours may not support
>> availability zones. HP's revamped HP Cloud offering does offer several
>> availability zones in the US West region.
>>
>> Explicit AZs
>> =========
>>
>> When bootstrapping or adding a machine, you can specify the availability
>> zone explicitly as a placement directive. e.g.
>>
>> juju bootstrap --to zone=us-east-1b
>> juju add-machine zone=us-east-1c
>>
>>
>
>> Automatic AZ spread
>> ================
>>
>> TL;DR: "juju deploy -n 10 <service>" will automatically and uniformly
>> distribute the units to instances spread across the AZs within the region.
>> Assuming the charm and service being charmed is well written, then you
>> should be able to rest assured that IaaS downtime will not affect your
>> application.
>>
>> When adding machines without an AZ explicitly specified, or when adding
>> units to a service, the ec2 and openstack providers will now automatically
>> spread instances across all available AZs in the region. The spread is
>> based on density of instance "distribution groups".
>>
>> State servers compose a distribution group: when doing "juju
>> ensure-availability", state servers will be spread across AZs. Each
>> deployed service (e.g. mysql, redis, whatever) composes a separate
>> distribution group; the AZ spread of one service does not affect the AZ
>> spread of another service.
>>
>>
>
> Awesome, that's a pretty nice and simple abstraction.
>
> Two caveats to be aware of, This potentially can cause an issue with our
> ongoing work for vpc support as subnets are bound to azs, but i may have
> azs without subnets in them.
>
Thanks for the heads up. That sounds like we'd want a network constraint
that filters the usable AZs. Shouldn't be too difficult.
Also there are diminishing returns on azs, ie. most people don't use more
> than three for an app, even though they may have up to 5 available to them
> in a region. maximal az usage actually increases app likelihood of dealing
> with az outage or network partition. As noted privately, some services will
> still want explicit placement instead of implicit.
>
Fair point. We may need to add some kind of constraint to set the maximum
spread. This may also be useful as a means of pinning an entire service to
an AZ. Something like:
juju deploy myservice --to zone=us-east-1b --constraints max-spread=0
(not really sure how to model the spread; % perhaps isn't all that useful,
and a number of zones doesn't make much sense for the abstraction)
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
