Availability zone support

Kapil Thangavelu kapil.thangavelu at canonical.com
Fri Jun 13 14:45:20 UTC 2014


On Fri, Jun 13, 2014 at 12:23 AM, Andrew Wilkins <
andrew.wilkins at 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. 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.

-k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140613/22d33141/attachment.html>


More information about the Juju-dev mailing list