"expected-redundancy=3" ? I don't have amazing ideas here, mostly because we need services that are really being used with lots of units. If you only have 3 units of a service, then it really doesn't matter. I think having a decent first step of this, and then we can drive the rest from concrete use cases. (I'm trying to deploy 100 units of X, and I really want it spread over only 3 AZ's.) I personally don't know what people want, and I can only theorize from use cases that may not actually be borne out in reality.
John =:-> On Mon, Jun 16, 2014 at 6:00 AM, Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > 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 > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
